I also beleive that having an MMU-less option for the NetBSD kernel would
be a neat trick, and I also think that fork() as well as mmap() could be
layered over a non-virtual memory management system.

According to userspace threads implementations for vfork() and the like,
libpth is great but I think only a GPL released version exists, there
may be other BSD licenced thread libraries though... mit and unproven
pthreads have been dissapointing a bit when I tried them...

I have some code I wrote for an MMU-less kernel a while ago, including
a memory management system... One thing though is that it's made for
32-bit systems, most of which support MMU features. The architecture
it was to run on consisted of m68k (68000-68010) which act fine with
32-bit addressing being 16-bit pseudo 32-bit, but probably is an
exception. 68030 and up work fine with current NetBSD though.

An MMU-less memory management system usually implies that requested
memory for allocation must really be contigious, often slowing down
the system if memory fragmentation is to be avoided for long uptimes...
Basically a main page allocator manages pages, and general purpose
allocation functions use 7-8 pools of pages to handle smaller
requests... The arch-dependant init code would simply fill in the
main free pages pool linked list (each node having a pointer to an
actual 4096 or 8192 block of memory, so that multiple allocated pages,
contigious, have no header whatsoever)... the general allocator
using pools simply prepares any newly requested page into blocks with
headers...

A few reasons why running a NetBSD kernel on those would be great:

- Standard UNIX API already implemented suitable for C development
- Great non-bloated, full libc implementing the standards properly,
  with MD5 support, etc (unlike glibc, although this is not really
  kernel-dependant)
- Ideal, solid scheduler for most application requirements
- Portable bus layer with portable driver codebase, this means
  that very few code would actually need to be written for each
  new MMU-less architecture it would run on, once uvm or replacement
  standard API is written to interface with arch-dependant init code

So there would still be quite a few adventages in using a NetBSD
kernel on say, 68000 for instance, where init(8) could be rewritten
if required, to start the critical processes for an embedded system,
and the requirement for multi-user would be minimal... As of course
no real protection is possible unless running a virtual machine,
making multi-user features almost useless.

A remaining possible challenge would probably be to perform proper
memory addressing and pointer arithmetic on certain architectures
though, surely.

Matt