Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Inverted Page Tables
Message-ID: <43752@ames.arc.nasa.gov>
Date: 26 Feb 90 20:10:25 GMT
References: <37774@cornell.UUCP>
Sender: usenet@ames.arc.nasa.gov
Distribution: comp
Organization: NASA - Ames Research Center
Lines: 28

In article <37774@cornell.UUCP> huff@cs.cornell.edu (Richard Huff) writes:
>their problems.  The true issue is supporting Copy-On-Write, which 

But suppose that Copy-On-Write *must* be supported.  Maybe IPT still works
well enough.  


>The Unix fork() policy of logically copying the stack is brain dead.  If 
>we had a general create_a_process() facility that allowed you to specify 

This was argued a while back.  It does seem that a lot of cases could be
covered by a general exec function, but many people argued that in practice
every fork() is unhappy in its own way...

>Can anyone name a use for copy-on-write that wasn't designed to fix one 
>of the above two problems (or to support the brain dead policies of 
>fork(), as mentioned above) ?

I guess we are stuck with supporting an efficient fork() with Copy-On-Write,
whether it is "necessary" or not.  Does that make IPT impossible.  I wonder
if every system designer knows?   :-)



  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)604-6117