Re: NetBSD without MMU ?

[woods%weird.com@localhost (Greg A. Woods)]

[ On Friday, April 12, 2002 at 11:24:43 (-0700), Justin Wojdacki wrote: ]
> Subject: Re: NetBSD without MMU ?
>
> As dumb as it may sound, there are cases where a couple of cents (US)
> per chip can make a difference in whether or not a sale is made (note
> that I'm talking about volumes in the 1e6's of chips).

Even with millions of units sold will the additional engineering costs
required to get a system complex enough to need something like a NetBSD
kernel, and whatever application code will be used, running reliabily on
an MMU-less system, not vastly outweigh the few cents per chip savings?

(obvioulsy there's a break-even point after which the savings are real,
but if we're talking about millions of units and pennies per unit, then
that's not a trivial back of the envelope calculation!  ;-)

> Also, MMU's can
> make task switches (and even basic operation) less predictable, as the
> time to perform an operation can vary by a larger margin now. That can
> be bad in a system where you need lots of performance, but can't
> afford large delays (large is a relative term here). So companies may
> want processors such as the MMU-less MIPS variants, or at very least
> be able to avoid using the MMU if their cpu already has one.

Note that I did carefully qualify my desire for an MMU with hardware
page protection explicitly in the development (and testing) environment.
Certainly some applications can fair well without hardware page
protection in production, and if that means you can run a slower (and
thus potentially much cheaper) CPU and get the same performance, then
that's a good choice for those particular applications.

> Of course, then their customers come around demanding *BSD or Linux
> running on hardware that doesn't support those operating systems. ;)

Well, whether any given company faced with this choice is able to factor
in the costs of porting NetBSD to their platforms is a lot harder to
generalise....  :-)

> uCLinux "solves" the problem by not implementing fork() but instead
> forcing you to use vfork()/(exec() or _exit()) pairs to emulate
> fork().

I hope there's a decent user-level threads implementation then!  ;-)

-- 
                                                                Greg A. Woods

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