Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site motel6.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!alberta!ubc-vision!uw-beaver!tektronix!reed!motel6!keith
From: keith@motel6.UUCP (Keith Packard)
Newsgroups: net.unix-wizards
Subject: Re: vfork
Message-ID: <177@motel6.UUCP>
Date: Wed, 10-Jul-85 21:19:03 EDT
Article-I.D.: motel6.177
Posted: Wed Jul 10 21:19:03 1985
Date-Received: Sat, 13-Jul-85 10:02:58 EDT
References: <726@wlcrjs.UUCP> <22500003@ima.UUCP>
Reply-To: keith@motel6.UUCP (Keith Packard)
Organization: 5440 SE 41st, Portland, OR
Lines: 30
Summary: 

In article <22500003@ima.UUCP> johnl@ima.UUCP writes:
>
>/* Written  1:22 am  Jul  8, 1985 by thomas@utah-gr in ima:net.unix-wizards */
>> The problem is that the initial design of the Vax (750?) had a flaw that
>> made copy-on-write VERY difficult (impossible?) to do.  So, the vfork
>> kludge was the only workable solution to avoid copying an entire process
>
>No it wasn't -- vfork really has to be chalked up to laziness.  It would
>have been entirely workable to do copy-on-touch in the stack segment (which
>was where the copy-on-write pages didn't work.)  Considering how little
>stack data is read but not written, the performance would have been about
>the same.
>
>On machines like the PDP-11, vfork makes more sense since the segments
>are too big to do practical copy-on-anything.
>
>John Levine, ima!johnl

No, it's not because the segments are too large.  It's because you
must have contiguous physical addressing on the pdp, otherwise
swapping becomes a nightmare (very important on pdp's remember) and
physical i/o becomes impossible (only the cpu goes through the
virtual memory map, not the i/o devices).  many portions of
the kernel depend on contiguous physical addresses of unix
processes; true copy-on-touch demands *real* virtual memory.

keith packard
speaker-to-pdp
...!tektronix!reed!motel6!keith
...!tektronix!azure!keithp