Eugene Leitl writes:
> On Wed, 3 Jan 2001, Robert S. Thau wrote:
>
> > Unfortunately, the worst thing about the Minix book is probably Minix
> > itself, with its microkernel architecture, which was the academic fad
> > at the time it was written, but has fallen out of vogue for some
> > pretty good reasons. (It's very hard to write a microkernel which
> > doesn't run into performance problems, and Minix in particular has
> > bottlenecks like the infamous single-threaded filesystem which you
> > need a major overhaul to fix).
>
> Nanokernels are not worthwhile because they're hard to write?
> That's hardly a valid reason for a True Programmer(tm). I haven't
> heard about performance problems of QNX, and L4/FIASCO is not
> doing to shabbily in comparision to RTLinux (ask google).
Well, perhaps I should have said, "It's very hard to write a
microkernel *Unix*...", but I thought that was clear from context.
At any rate, the '80s style microkernel approach typified by Minix is
a bad way to implement the Unix API because it is more work than the
alternatives, and generally performs worse. Remember, that approach
was not about shrinking the size of the total OS per se, but rather
about moving the components of the OS (filesystems, device drivers,
etc.) into separate address spaces that communicated by message
passing, so that you could run, say, a suspect device driver while
limiting the amount of damage it could do to the rest of the system.
The point wasn't to gain performance. In fact, proponents of this
approach (at least the honest ones) were up front about the inevitable
performance cost due to extra context switches (which would have
been simple procedure calls in a monolithic kernel) --- but believed
that the cost could be minimized, and the extra flexibility would be
worth it.
QNX has managed to make this approach work, in its niche, in part by
multithreading the filesystem (unlike Minix) --- which is what makes
it interesting. But a lot of very smart people have tried and failed.
As to L4, I thought their Posix support was through L4Linux, which is
Linux itself, modified to use L4 as a hardware-abstraction layer; a
single body of code which runs in one kernel address space, with no
internal message passing --- so it's not a microkernel OS in the same
since that Minix is. That's what the DROPS folks seem to be using, at
any rate. But perhaps google's doing something different?
> The advantages of tiny kernels and small contexts are obvious,
Which has nothing to do with the aspects of Minix that I was
criticizing --- the microkernel design doesn't make Minix as a whole
smaller, just slower.
> as realtime and QoS plus small memory footprint are going to be
> needed in the near future. Memory will move into the CPU module,
> ultimatively becoming embedded, and we will have multiple CPUs in
> a single desktop, with a fast packet switched interconnect.
Is your desktop CPU-bound these days? Mine isn't... it spends most of
its time waiting for something, typically the network.
rst
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:17:56 PDT