On 04-Apr-98 Jason Thorpe wrote:

>> I think I just figured that out.  It's the allocation/deallocation of USPACE,
>> which has moved from a vmspace mapping to a kmem allocation, making the new
>> vfork() possible.  Correct?
>
> No.  The new vfork() was made possible by sharing the "struct vmspace".

Ah, but that sharing was made possible by moving the USPACE allocation out of
the vmspace.

Where and how the USPACE is allocated/deallocated is what I was confused about
in the message before the above citation.  In the above citation I had spotted
the relevant lines in the code.

The point in the above was, cpu_wait() being a null #define in the i386 port's
<machine/cpu.h> doesn't matter, because that isn't where the USPACE stuff is
deallocated anyway.  So the deallocation _is_ being done, contrary to what I had
previously thought.

I was just a wee tad dense in my wording, there.

>> By the way, are you aware of any user programs that have had to be modified
>> to work with this shared vmspace vfork()?  David Brownlee keeps telling me he
>> saw a flurry of commits on the source-changes mailing list to that effect. 
>> But I don't see anything about it in CHANGES for -current (as of yesterday).
>
> There were several programs in the tree, and a bug in the C library, that
> violated the traditional "vfork rules" (which have existed since the
> vfork in 3BSD, but which we got away with since 4.4BSD's vfork didn't
> have the address space sharing semantics).

I've dredged out the source-changes archive.

I now have changes for these programs:

  [x]install, mount, make, gcc;
  apply, tn3270, vacation, window, ypserv.

The fix in general is to use _exit() instead of exit().  For gcc, there's an
additional fix to #include <unistd.h> and use the Real vfork().

The C library bug is in popen().


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 04-Apr-98
Time: 20:33:04

This message was sent by XFMail
----------------------------------