[ On Friday, April 12, 2002 at 08:57:35 (-0400), Todd Vierling wrote: ]
> Subject: Re: NetBSD without MMU ?
>
> Then it's not NetBSD, is it?  :)
> 
> (The no-MMU requests that have come in are specifically wanting the bulk of
> NetBSD's kernel codebase for various reasons.)

If it has the same system calls, and much the same behaviour from a
network peer's point of view, and if it can transparently use the same
on-disk filesystems, and runs much of the same user-land code, who'd
know any different?  :-)

> Most programs don't need fork(2) per se.  vfork(2) and its inverted
> companion daemon(3) (which can be implemented in a way other than using
> fork()+_exit()) are enough for nearly all programs.

Many of the programs I care about really do need a proper fork(), and
unfortunately even some of the ones I think I would care about in an
embedded systems world would need something a bit better than just
swapping to implement fork(), unless I could have threads.... (i.e. I'd
want parent and child processes resident at the same time to reduce
context switching between parent and child to a minimum).  I guess that
means a minumum of base/segment register support.

At bare minimum I'd also want my development environment to have full
hardware segment protection, or a simulator with such capabilities and
which could run at real time.....

In the end I must agree that just using a modern CPU with full hardware
paging MMU support (i.e. something NetBSD can easily run on or be ported
to today) seems like it would always be a good engineering decision
regardless of whether it increased the per-unit costs of some device
with an embedded processor by some fraction.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>