> (The Mbufs are no problem, I ported the first public BSD network code to
>  the old Atari-ST and MBUFS were easy to port, reinventing select, 
>  fork and signal without the sources was much more challenging, as
>  was NFS).

A whirlwind tour through the networking code reveals a lot of checking for
allocation failures which I'm sure weren't present in NET2, so things have
definitely improved.  (I did *not* want the mbuf allocation routine to take
it upon itself to panic on failure.)  I didn't find select all that hard,
and fortunately I already had fork and signal equivalents (plus, I was
porting the actual Sun NFS code, so that part was easy).

> It think it depends which functionality he wants to port.
> The process stuff will be the worst (at least on non-segmented CPU's),
> and fork() will be a royal pain (at expensive like hell). 

OMAGIC binaries are still supported (impure text); just strip out
support for all other executable formats, add an on-the-fly relocator,
and you're done (says someone not actually planning on doing the
work... ;-).  (Of course, the linker probably doesn't know how to
build OMAGIC binaries.)  I think implementing the necessary vm_ calls
might be fairly easy, but it'll require a lot of detailed study to
figure out which ones can be empty and which have to do some kind of
real work.  Any gimmicks that depend on multiple mappings (like
constant-address u areas) are out.

> Security between user and supervisor mode gets reduced to what the CPU
> has.

Since anyone doing a multi-user system nowadays without VM would have
to be criminally insane, I'm assuming that this is for some kind of
dedicated hardware, like an automatic floor-waxer or possibly a router
or other piece of network hardware (considering the domain of the original
questioner).  In that case, security is handy for debugging but not
mandatory for the running system.

However, if the hardware isn't already chosen and built, I think I'd
have to argue for reconsidering the decision to go with an MMU-free
CPU.  I haven't priced CPUs in a long time, but I *think* you can get
embedded-class CPUs with MMUs at reasonably cheap prices, and you'll
shave months off of your development time, months which will be spent
*not* adding customer-desirable functionality but getting around the
lack of coder-desirable functionality.  MMU protection also makes it
less likely that you'll have undebuggable crashes at customer sites
when a buggy application (gasp!) smashes some vital kernel code...