Microkernels (was: A niche for the Hurd - multi-core systems)

[olafBuddenhagen]

Hi,

On Mon, Nov 17, 2008 at 12:39:30AM +0000, Zheng Da wrote:
> On Wed, Nov 12, 2008 at 1:18 PM, <olafBuddenhagen@gmx.net> wrote:

> I am quite curious: why did porting to the modern microkernels fail?

Well, it's a long story, and I don't understand all the details myself.
I'll try to give a very rough summary.

The original L4 (Pistachio) turned out unsuitable, because it totally
lacks any capability support in the kernel. Implementing it in user
space proved not feasible.

L4ng and L4.sec add some kind of capability support, by extending the
mapping idea from memory to other kernel objects, including
communication channels. One of the problems here was that the
hierarchical mapping system is quite different from the copy semantics
normally used in capability systems. (It was never finally concluded
though whether the lack of copy semantics is a problem for the Hurd...)

There were some other problems as well. I remember some talk about an
identify operation on capabilities, and about endpoints. There was also
something about kernel memory management.

It is not clear whether it would have been possible to implement the
Hurd on L4ng or L4.sec nevertheless; but it was quite clear by then that
it would have required quite a lot of fiddling to implement our desired
semantics -- leaving us in a similar situation as with Mach...

Anyways, by that time Shapiro managed to convince Marcus that Coyotos
would probably be a better foundation, because of the specific problems
described above, as well as the general observation that the Coyotos
group has years and years of experience with such capability designs,
while it's totally new ground for the L4 folks.

But Coyotos as it turned out has other fundamental problems regarding
our goals: The constructor mechanismm helps putting users out of
control, thus being in direct contradiction to the GNU philosophy. Also
Coyotos avoids any self-management of scarce system resources by the
applications -- while this was indeed one of the main ideas behind
Hurd/L4. And the persistency approach doesn't really make sense for a
general purpose system like the Hurd.

> then come a question: what kind of microkernel does Hurd need?

That's the core of the problem: we do not really know ourselfs...

The point is that microkernel design is very tightly coupled with the
design of the rest of the system, which is precisely why a kernel
created in another context is never likely to be really what we need.

Viengoos probably comes as close to an answer as we get -- after all, it
is the conclusion (well, Neal's conclusion at least) from what we
learned in the attempts with other kernels...

> > In any case, IMHO we have much more pressing issues than Mach's
> > shortcomings presently, and thus I don't consider work on new
> > microkernels the highest priority right now... (Definitely
> > interesting though.)
> 
> but I think at least some bugs in Mach should be fixed.

Yes of course! I didn't mean ignoring the microkernel alltogether. I
meant that IMHO the Hurd on Mach should remain the main focus for now --
which obviously implies fixing the less fundamental problems in Mach.

-antrik-