From: torvalds@transmeta.com (Linus Torvalds)
Newsgroups: comp.os.linux.advocacy
Subject: Re: Linux vs Minix
Date: 22 Dec 1997 07:48:45 GMT

In article <67kpke$s02@examiner.concentric.net>,
 <greeder@concentric.net> wrote:

>In <67cimd$ol5$1@palladium.transmeta.com>, torvalds@transmeta.com (Linus
>Torvalds) writes:
>
>>People have later made "real" 386 versions of minix with more advanced
>>memory subsystems available, but while they were better than not having
>>it, they really never were very good.  The basic minix design was so
>>fundamentally flawed by a really bad microkernel implementation that it
>>never really got off the ground.
>
>Anyway, having just read Ast's book I am intrieged by your
>comment about Minix's "fundamentaly flawed micro kernel".
>I myself could see several possible improvments.  In your
>opinion, what were Minix's flaws and how were they
>addressed in Linux??

The minix microkernel implementation is essentially single-threaded (and
fundamentally so, partly due to the message passing primitives - they
couldn't queue a message), which means that once you have multiple
kernel services depending on each others you end up having to be _very_
careful about deadlocks.  What was supposed to be a simple system
becomes a nightmare of call graphs..

For example, this makes handling paging rather nasty.  Imagine doing a
large "write()" call, and the systems needs more memory for buffers.  So
it wants to write out a few pages to disk.  Sadly, the filesystem server
is already busy doing the write, and due to its single-threaded nature
you're now dead-locked.

So to avoid all circular dependencies, at least the original minix had
very strict static rules (processes couldn't grow at run-time, for
example, and you obviously couldn't take page faults etc).  These
limitations were still true in the i386-minix that I used, but at least
the 32-bit issues made the system much more pleasant in other ways.

I think some of the minix patches tried to work around some of these
problems, but basically the system was never very well designed.  Last
time I brought this up, ast still considered multithreaded servers just
a "small performance issue", rather than a major fundamental thing.

As to how these kinds of problems are addressed in Linux, the answer is
simple: the above kind of problem is not an issue in a traditional
monolithic kernel.  It's a fundamental flaw in microkernels - although
it can be (reasonable easily assuming a good design) handled by making
the servers re-entrant which is something that Minix never did as far as
I know.

In a monolithic system the kernel is quite naturally multi-threaded
without any added special logic (in fact, much special logic is needed
to _protect_ regions that aren't naturally re-entrant - which is a lot
better than the opposite approach because it forces people to be very
aware of when they aren't re-entrant).

The reason ast didn't want to make minix servers re-entrant was that he
felt that it wasn't all that important (total BS, imnsho) and that it
makes the system more complex (quite true).  The fact that the lack of
re-entrancy made the system almost useless for real work seems to not
have been an issue.

To me, microkernel people are these shifty used car salesmen: they
promise great systems, but the end result always seems to have most of
the corners cut.  They seem to offer one of "speed", "simplicity" and
"stability", but never a combination of all three.  QNX seems to be the
best of the lot by far, and even QNX seems to be mainly a special-
purpose system.

			Linus