>And as you say, USPACE never has been in the vmspace:  I misread the meaning of
>"per-process address space".
>
>What in fact WAS preventing vmspace sharing and the Real vfork(), all these
>years?


This is second or third hand, so take this with a very large grain of
salt;-- and if Jason says differently, beleive him, not me.

One thing we had to change in NetBSD just before "real vfork()" was
activate_pmap and deactivate_pmap().  On some architectures, and with
a Mach-style VM interface, these can have some rather hairy
interaction with the kernel-stack (which, you will recall, was
historically glommed into the u-area in rather disgusting ways.
The last vestiges of that were part of what had to go.).

On mips, the issues has to do with a software-managed TLB miss handler
and using a TLB-mapped kernelstack (to get a stack redzone, to warn
about stack under/overflow).  For a mix of historical, debugging, and
performance reasons we used a fixed kseg2 (TLB mapped, not direct)
virtual address range for the kernel stack.

On vax it has to do with vax-specific architectural coupling between
the `hardware process context' and ldpctxt/savepctxt instructions, and
the current kernel stack pointer.

On other architectures it isnt even a noticeable issue.

The VM system I'm still most intimately familiar with handled these
issues um, somewhat differently from either Mach, or Chuck's new UVM,
or (from what little I've read) the FreeBSD VM system.