On Fri, 8 Jun 2001, Toru Nishimura wrote:

: [MiNT] had fork() call behaves as vfork().

This would be bad for a MMU-less NetBSD, as we would only want fork() to
work where it would do the right thing.  That way we don't have suddenly
non-working code.  Instead, we should return ENOSYS for fork(), and make
sure programs use vfork() where appropriate.

: There were certainly many implementations of UNIX-alike in which
: entire system run inside a single address space.  They were mostly
: motivated by necessity to run UNIX-like programs in so-called "embeded
: product" circumstances.

That's precisely the circumstances that are prompting developers to wonder
about porting NetBSD to mmu-less CPUs.  Many popular embedded CPUs still
don't have MMU attachments, and there is a lot of legacy hardware out there
too.  The Amiga 4000's that came with 68EC040s (disabled or buggy MMU) come
to mind.

: W/o proper assistance of memory management hardwares, memory allocator
: easily gets suffered from fragmentation of available memory.  Those
: systems often die miserably due the lack of effective memory garbage
: collecting and relocation.

Right.  Although most mmu-less systems have a per-process pool allocator, so
that memory is not fragmented in small chunks, but only in big pieces (and
typically from the opposite side of memory from .text).  Also in embedded
systems, programs do not stop and restart as frequently as with desktop
boxes.

An interesting sidenote that it's possible to make gcc and ld do some tricks
to make an executable "scatterloadable" (that is, load across fragmented
memory with .text and .data in multiple places).  You can have individual
object files, or even individual functions, with their own text and data
sections, allowing the executable to spew all over memory when loaded.
AmigaOS used this to its advantage when loading programs....

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/