Subject: Re: NetBSD without MMU ?
To: email@example.com, , <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 04/12/2002 14:02:12
[ 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; <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>