Re: [9fans] linux stats in last year from linuxcon

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

On Mon, Sep 21, 2009 at 7:33 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > > "We're getting bloated and huge. Yes, it's a problem," said Torvalds."
> >
> > So may be Tanenbaum was right, after all, there's a reason we make
> > things modular.
>
> rob, presotto, ken and phil did not agree with tanenbaum's
> ideas about modular kernels.
>
> this was a direct response to ast many years ago.  it was
> hard to dig up when i did so in 2006.  perhaps someone
> has a better link:
>
>   - Microkernels are the way to go
>        False unless your only goal is to get papers published.
>        Plan 9's kernel is a fraction of the size of any microkernel
>        we know and offers more functionality and comparable
>        or often better performance.
>
>
This does not mean they were saying microkernels can't be done well :-).  At
least I hope not, because there's a few counterexamples out there.

L4 based systems are quite impressive, though their idea of a microkernel is
a bit more like an advanced hypervisor, but more for something along the
lines of paravirtualization.  QNX is another good example of a microkernel
that works quite well in practice.

If by microkernel you mean Mach, and hopefully no one does anymore, then
you're pretty much dead on ;-).

Even the latest versions of Minix really aren't too shabby and still
microkernel based.  (small memory footprint, decent functionality, lots of
Unix stuff work on it, and they have an interesting choice of compilers.)

Are these systems more complex to reason about though?   Probably :-).  But
when you've only got 7 system calls (per the original L4 specifications I've
read over) you don't really have a lot to debug.  Just gotta make sure you
chose the correct primitives to compose all the software you need to write
on the system.

I think, in that sense, Plan 9 and some microkernels are pretty similar.

Dave


> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 2674 bytes --]