[linux-elitists] ME roadshow

Mike Touloumtzis miket@bluemug.com
Sun Sep 3 19:21:44 PDT 2000


On Wed, Aug 30, 2000 at 11:43:19AM -0700, Eugene Leitl wrote:
> 
> Paul J Collins writes:
> 
>  > QNX's kernel does not provide the variety of services that a
>  > Unix-style kernel does.  It provides three basic services: process
> 
> Well, maybe we don't need a complete country fair in a kernel.

Speaking as someone whose job involves porting Linux to embedded-type
(well, consumer-electronics-type) devices, I strongly believe that the
"Linux kernel is full of desktop bloat" argument doesn't have legs.

Think instead of the fact that Linux lets you blur the artificial
boundaries between product categories like "PDA", "desktop", and "server".
When I go traveling, I can not only use dialup access with my Linux
laptop, I can also run a DHCP server on my PCMCIA ethernet card and let a
friend piggyback on my connection using IP masquerade.  If I want to bring
a little hub along, I can get everyone in the conference room online.
I can use FreeS/WAN to give all of them access to our corporate network
via a VPN, and proxy DNS so that they see our internal namespace.  I can
use network filtering to reduce that risk that someone breaks into my
PC or any of the others while I'm online.

You don't get these things with one of those little 10KB TCP/IP stacks
written in Forth.  You also don't get a stack that can handle the range
of hardware optimizations from a dumb-ass NE2K to a sophisticated
gigabit Ethernet card whose programmable firmware is practically a
separate computer.  And this is just networking--parallels exist for
other subsystems.

To return to small-scale systems, who's to say that I don't want to be
able to the above fancy networking with my PDA?  The reaction I get from
a lot of people when I describe a scenario like the above is "wow, it's
like your laptop is a _server_".  I largely blame MS for encouraging the
silly, rigid PDA/PalmPC/client/server way of thinking, although they're
not the only ones.

> 
> I would probably implement a kernel as a rudimentary VM, preferably
> with good hardware support.
> 

The really interesting thing to me about the "Unix kernel vs. microkernel"
Torvald/Tanenbaum debate is that Linus's decision holds up much _better_
now than when he first made it (and the "Unix is 30 year old technology"
arguments are correspondingly weaker).  Back then, Linus's most compelling
argument was that Unix kernels offer inherent parallelism in situations in
which "pure" microkernels are inherently single-threaded.  People often
equate threadedness, microkernels, and multi-CPU parallelism without
thinking about the fact that Unix kernels (since they are essentially
privileged libraries rather than priveleged processes) inherently
allow all processes to act in parallel, while the "privileged process
for filesystem, networking, etc." model requires you to come up with
complicated resource-pooling strategies (e.g. pooling of thread stacks
in each server) to get the same parallelism.

Since 1991, one of the biggest trends in CPU performance has been the
increasing importance of the cache and TLB.  This means that the best
way to get really high-performance behavior for your kernel code is to
map it into each process's address space--what Linux does with modules.
It sounds like QNX does this for core kernel components, but if you follow
this argument to its logical conclusion, you'll say "hmm, anything we
implement as an out-of-kernel server is going to thrash the cache and TLB,
and will suck performance-wise, so let's just move it all into loadable
modules."  Of course, you still want stuff like Apache outside the kernel
for reasons of security and robustness, but anything that needs to take
advantage of highly asynchronous hardware behavior should be in there.

So, in a nutshell, using process/address space boundaries as privilege
boundaries is just a bad idea on modern hardware.  I wish these
points were better understood by Linux advocates at large.  I often
come across people making apologies for the Unix kernel design rather
than portraying it as the most up-to-date (and continually reassessed)
technology there is.

miket





More information about the linux-elitists mailing list