Re: Linus replies

[Richard Braun]

On Wed, May 10, 2006 at 10:10:47PM -0400, Donnie Jones wrote:
> Hello,
> 
> Rebuttal from Linus' post:
> ***
> "The fundamental result of access space separation is that you can't share 
> data structures. That means that you can't share locking, it means that 
> you must copy any shared data, and that in turn means that you have a much 
> harder time handling coherency. All your algorithms basically end up being 
> distributed algorithms.

Copying data isn't strictly necessary, but sharing data between two
processes with IPC is of course more complicated than having only one
address space, mainly because of security concerns.

> And anybody who tells you that distributed algorithms are "simpler" is 
> just so full of sh*t that it's not even funny.

Right.

> Microkernels are much harder to write and maintain exactly because of this 
> issue. You can do simple things easily - and in particular, you can do 
> things where the information only passes in one direction quite easily, 
> but anythign else is much much harder, because there is no "shared state" 
> (by design). And in the absense of shared state, you have a hell of a lot 
> of problems trying to make any decision that spans more than one entity in 
> the system.

That's where the Hurd slightly differs from what is said here: the
problem about a "decision that spans more than one entity" is the
interface between those entities. Within a monolithic kernel, these
interfaces can easily change since it is internal to the kernel (except
of course system calls and interface with userland processes). With a
multiserver microkernel, they must be very carefully designed so that
services implemented on top of the microkernel can evolve with very few
changes to the interface (the best case being extension only, without
any modification on the existing interface). With a well designed
microkernel, only core components (mostly VM, scheduler and possibly
drivers) are really bound to the microkernel architecture. Once you
have those interfaces, as the Hurd mostly does, it becomes easier to
change and maintain the core components as long as the interface remains
more or less the same.

> And I'm not just saying that. This is a fact. It's a fact that has been 
> shown in practice over and over again, not just in kernels. But it's been 
> shown in operating systems too - and not just once. The whole 
> "microkernels are simpler" argument is just bull, and it is clearly shown 
> to be bull by the fact that whenever you compare the speed of development 
> of a microkernel and a traditional kernel, the traditional kernel wins. By 
> a huge amount, too.

This comparison is quite stupid IMHO, since the simple fact that the
number of developers is really not the same is the real issue about
the speed of development. Microkernels are not simpler, they are
more complicated. But they allow simpler development of new components,
and this is clearly true on the Hurd, since using software like the
well known glibc or gdb helps a *lot* when debugging new translators
(even if glibc and gdb sometimes have bugs too, which makes debugging
a little harder ;-)).

> The whole argument that microkernels are somehow "more secure" or "more 
> stable" is also total crap. The fact that each individual piece is simple 
> and secure does not make the aggregate either simple or secure."
> ***

Well, I completely disagree on that. Microkernels are more secure
because accesses to objects and services is always controlled the same
way, so the code that makes checks is easy to maintain and keep secure.
The use of libraries like libtrivfs on the Hurd also makes check
points similar, with the same advantage, which means that, overall, there
are only a few critical points where security checks are done, which
is a huge advantage compared to the many system call entry points in
a traditional kernel.

Concerning stability, excluding the kernel and critical services, any
process can crash without crashing the system. The issue concerns
processes that hang, and makes related processes hang too, but there
are solutions to that as well.

> Could someone refute these statements for me?  Or do you agree with Linus' 
> that microkernels are actually not easier to maintain?

I hope this gives you some answers. Microkernels may not be easier to
maintain, I agree with Marco when he says this depends on the microkernel,
but on the Hurd, and hopefully ngHurd, new components will be simple
and easy to develop, which is one of the goals of the Hurd.

-- 
Richard Braun

signature.asc
Description: Digital signature