Subject: Re: NetBSD without MMU ?
To: None <netbsd-ports@netbsd.org>
From: Toru Nishimura <locore32@gaea.ocn.ne.jp>
List: netbsd-ports
Date: 04/12/2002 10:33:21
Pierre Merlin <pierre.merlin@clarus-networks.fr> writes:

> Can NetBSD run with no MMU support (say, on  MPC860) ?

I think MPC860 has "MMU,"  in a sense just like as MIPS
processor does.

Many have been thinking of small/embeded system could be
competitive enough if it was shaved off small fraction of hardware
to make it up "cheaper."  However, the rationale has been getting
defunct.  Face on the facts; equipping TCP/IP protocol stack is
mandatory and vast majority of applications depend on socket
API.  Because of that, many RTOS/uKernel approach for TCP/IP
stack and API by porting 4BSD stack including the entire
framework behind it.  It's amusing to see 'struct proc,' 'struct user,'
'struct vm' references in some of them even though they reclaim
thread/task oriented single address space OS.  All this is simply
to make such that porting work less painful.  It's ironic to see that
not neglectable size of computer industry has been making money
to port TCP/IP and applications in their own ways, repeatedly,
so far, and it's likely to continue on.

Having VM results in memory saving at run time.  It provides a more
efficient and, more imporatantly, versatile way to manage memory
demands.  With the growing popularity of memory hogging (Internet)
applications (more memory is necessary anyway to do it), imposing
poor memory management scheme is less attractive and technically
obsolute.  So, it'd be better to think "forward."

Similar argument would make sense in having FP machinary.  To
make your product competive it's important to choose luxury
"capable" hardwares in less price.  You can buy it judging the design,
the performance, or the skill of making a good deal for superior
hardware.  It seems the right way to go.

Toru Nishimura