🚀 go-pugleaf

In article <13801@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>don't think there is any version of Unix which does. But a long time
>ago, an operating system named Multics did some neat things with
>segments. That Unix doesn't use them doesn't mean segments are a
>useless idea.

OK, all you intel hackers, here's a question for you.  This will tell
me very quickly if I want to ever deal with segments or not.  By the
way, my question could be quickly answered if I had a 386 reference
in front of me, but I don't so here goes:

Suppose I use your bloody segments.  I put the stack in one, the data 
in another, and the text in another.  [ Oops, forgot context, this is
the layout for the memory management of Unix process, but could be 
any OS that multi tasks. ]  My questions are

1) How does virtual to physical (page => frame) mapping occur?  Are there
   seperate page tables for each segment, or what?  (I know, dumb
   question).

2) OK, a better question:  suppose my process forks (spawns a child)
   and I would like to set things up as follows:

   o  child gets personal copy of stack.

   o  child gets shared copy of text.

   o  child gets gets shared (with parent) copy of data addresses
      0x01ffff..0xffffff (for example).

   o  child gets personal copy of data addresses 0x1ffffff and above.

   In other words, I want to take the section of memory with virtual
   addresses 0x01ffff to 0xffffff and have that shared.  Can this be
   __easily__ done with the 386 memory management?  Seems like it 
   would be a nice thing to support.  Don't forget, there may be 
   valid data addresses both above and below the segment in question;
   you can't split it into two, have to go to three chunks.

3) And yet another nifty question: can I make the new non-shared
   data segments be copy-on-write?  

4) How about using a segment to catch stack overflow?  Dynamically altering
   segment size?  From user mode? Supervisor mode?  After or during
   allocation?  

Finally, how much is this is handled by software and how much is supported 
by the hardware (directly).

So, waddya say, intel?
-- 
Larry McVoy 	        mcvoy@rsch.wisc.edu, 
      		        {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy

"They're coming soon!  Quad-stated guru-gates!"