Subject: Re: NetBSD without MMU ?
To: None <firstname.lastname@example.org, email@example.com>
From: Justin Wojdacki <firstname.lastname@example.org>
Date: 04/12/2002 12:53:42
"Greg A. Woods" wrote:
> [ 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?
Well, you're assuming that BSD or Linux is the intended operating
system for the platform. There are other operating systems out there.
However, more and more people seem to be interested in BSD or Linux,
without understanding what it's hardware requirements are. Get a
couple of clueless marketing people shooting off their mouths, and
you've got an engineering headache. And, to make it better, possibly
an engineering headache for the part vendor, not the customer, as the
customer can make it a condition of the sale that the vendor get BSD
or Linux running on the hardware, in exchange for buying millions of
Yeah, it's a mess. But if you're a chip company, software is fluff
that's thrown in to finish a deal right? :)
> > 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! ;-)
The threads library is actually a fairly recent development there. You
can have multiple programs in memory at the same time, based on their
memory model (PIC tricks basically), as long as they're well written,
but there are some obvious restrictions on what those apps can do, and
there's a fair amount of porting work for any large program.
Every once in a while, I get tempted to try to start a uCNetBSD
project. And then I put down the crack pipe. :)
email@example.com (408) 350-5032
Communications Processors Group -- Analog Devices