response 1 of 15:

Sep 18 15:11 UTC 2006

For background, see the famous Tanenbaum-Torvalds online debate from 1992, 
where computer science professor and microkernel advocate Andy Tanenbaum 
collides head-on with brash young computer science student and monolithic 
Linux kernel designer Linus Torvalds.  Transcripts can be found at various 
places on the web, e.g. here:
http://people.fluidsignal.com/~luferbu/misc/Linus_vs_Tanenbaum.html

response 3 of 15:

Sep 18 20:35 UTC 2006

I am, of course, assuming that this question was not specifically directed
at Remmers, but generally at anyone who can answer.

1. The difference between the two depends on how the system is divided up
between what is commonly termed "kernel space" and "userspace". Kernel space
(and its associated mode) is privileged and can do anything on the system;
userspace is limited to a basic subset of functions, and different userspace
programs are isolated from each other.

2. Monolithic kernels attempt to place "as much as possible" in the
(priviledged) kernel, for reasons of simplicity and performance: In general,
it is much easier to design a monolithic kernel than a microkernel, and, for
technical reasons, their performance tends to be better.

3. The ideal microkernel would place the minimum amount of system functions
in kernel space, with everything else in userspace. Typical subsystems which
microkernels abstract into userspace include filesystems (for storing data)
ande networking drivers. Many advocates of monolithic kernels object to the
fact that the interfaces between microkernels and drivers (the latter in
userspace) tend to be complex, causing poor performance.

Almost all Unix implementations are monolithic kernels; the only prominent
counter-examples are QNX (a Unix-like OS for real time systems) and Minix (a
pedagogic, minimalist Unix-clone, and the inspiration for (the monolithic)
Linux).

The difficulty of designing microkernels has led some teams to design "hybrid
kernels"; their detractors consider this term to mean "We wanted to design
a microkernel, but we had so many problems that we ended up with a monolithic
kernel". Windows NT, and its descendants Win2K and XP, are hybrid kernels.

4. A distinction must be drawn between microkernels, and monolithic kernels
which use kernel modules implemented in separate files. In these systems, which
include Linux and Windows NT, the kernel modules share kernelspace with the
monolithic kernel; it is, conversely, also possible to design a microkernel,
implemented as a single file, in which the microkernel part of the file is in
kernel space, and the rest of the file resides in userspace.

response 5 of 15:

Sep 18 21:02 UTC 2006

Some advantages of microkernels (as touted by their advocates) include
stability and security: a serious bug in any part of a monolithic kernel can
cause a kernel panic (also known as a Blue Screen of Death, Guru Meditation,
or system crash), but, a bug in a userspace filesystem driver causes only that
driver to fail; one need only fix the bug in that driver and restart it.
However, it must be noticed that whether a system uses a microkernel or not,
if a filesystem crashes in the middle of writing your data, your data is still
liable to be munged (a hackerish term for "munged [sic] until no good".)

response 7 of 15:

Sep 19 21:11 UTC 2006

I think his point is there's no real advantage to the microkernel in 
practice.  Most of the time, if a device driver crashes, the system is 
going down anyway.  It doesn't matter if it causes a kernel panic or 
not.

An example is Windows 2000.  Display drivers run outside of the kernel, 
in a different process space.  In theory, that means that if the 
display driver crashes, the machine can keep running.  In reality, if 
the display driver crashes in Windows, you're not going to have a lot 
of options other than hitting the big red switch.

response 9 of 15:

Sep 20 04:22 UTC 2006

The advantage of the protected domain model of the microkernel varies
depending on the target application environment.  For something like Windows,
it can rightly be seen to have very little benefit.  On the other hand, if
my microkernel is running my nuclear reactor, and the logging filesystem dies
because of a dead disk, I'd rather it kept running and kept the cooling tower
going regardless.

Another approach is to structure the kernel as you would a microkernel, and
then implement it as a monolithic kernel.  Microkernels give a nice
conceptual model for thinking about how to structure an operating system; if
for nothing else, this gives them value.

response 11 of 15:

Sep 20 23:34 UTC 2006

Regarding #8; The whole point of the journal is integrity, as David points
out.  You have something akin to transactions; your write doesn't succeed
unless the transaction succeeds.  If your power goes out half-way through a
write, the write call won't have returned yet anyway and the program should
never have assumed it was successful.  Of course, this implies that
application programs detect failures and act in a sane way, not just the
filesystem.

response 13 of 15:

Sep 22 17:37 UTC 2006

That reminds me of a quote from Dave Presotto, back when he was at Bell Labs.
With respect to why Plan 9 wasn't a microkernel, he said something along the
lines of, "Because in order to implement a microkernel, you have to have a
brain the size of a planet, and we only have egos that big."

I thought it was funny.

response 15 of 15:

Oct 8 03:31 UTC 2006

There's nothing wrong with having preferences, and of course, one part of
the equation that's often overlooked is what the purpose of the system under
construction is?  If your goal is to do real-world work, then you have some
sort of cost/benefit metric (not necessarily economic in nature) which is
going to heavily influence your design.  Ie, it might be a lot easier to get
a monolithic program together that's only a few Kloc to run your cheap
consumer electronics gadget: it wouldn't justify the hoops one has to jump
through to write a teeny microkernel from scratch.  You might be able to
verify and reason about the 2k of code that runs your kid's speak and spell
a lot easier than one could verify and reason about a microkernel.
Similarily, if a life depends on it, you might find that it makes more sense
to enforce separation of boundaries to minimize the chances of one part of
the system crashing and taking down, say, a nuclear reactor or smoke
detector or car's braking system, and that might best be implemented as a
microkernel.  Or, you might be writing a research system to push the
boundaries of operating systems research.  In that sense, monolithic kernels
have more or less been done.  Again, the real answer is that there is no
right or wrong.  It all boils down to what you need to accomplish.