Re: Hurd on Minix3 or other kernels?

[Marcus Brinkmann]

At Wed, 16 Nov 2005 16:43:21 -0500,
"B. Douglas Hilton" <address@hidden> wrote:
> It was always my hope that Hurd would become more microkernel neutral 
> than really specified for one in particular. Look at the problems 
> getting Mach unhooked for instance.

There really is not so big a problem unhooking Mach.  The problem is
what to hook on to it as a replacement :)

Microkernel neutrality is a tempting, but suspicious goal.  We are
certainly making some steps into this direction, but here is something
to consider:

There are not so many different microkernels around.  L4 and EROS are
converging.  If there is only one or two microkernels, what does
microkernel neutrality actually mean?  Neutral with regards to _what_?

The L4 work showed that if abstractions are done carelessly, they can
greatly reduce performance.  See for example "Stub code performance is
becoming important", Haeberlen et al.

Persistence can reduce application complexity.  Is persistence a
microkernel attribute or not?  Let me suggest that the answer is no,
it is not, but that this doesn't help us: You still need to decide
whether you can assume that the systems is persistent or not.  Such
decisions have a much bigger impact than the microkernel API.

I am unsure if memory management can be abstracted successfully.  This
is one of the main differences between EROS and L4.  This would affect
the I/O interfaces.  The same remark applies to resource management in
general.

This is the "negative" side.  On the plus side, I was able to simplify
the Hurd's capability and RPC model, and the result is a much simpler
libports (libhurd-cap-server), and even that is still too complex: I
have already simplified it even further by removing cancellation.

So, we are certainly making some headway in reducing the Hurd's
dependencies.

Last but not least: Many of the improvements we have worked out for
the redesign can just as well be applied to the Hurd on Mach.  They
probably will not be as effective on Mach, because the synergetic
effects will be missing.  For example, you can structure the code of
the Hurd on Mach so as to assume synchronous message transfer.  I
think you can even enforce this restriction by setting the message
buffer length for each port to 0.  The system will probably become
slower by that, but the structural development would head in the right
direction.  There are a few places in the Hurd where asynchronous
transfer is assumed, but those can be fixed.

> A while back, when I was reading about the recent release of Minix3, I 
> had this probably stupid thought that porting the Hurd to the Minix3 
> kernel might be advantageous for academic purposes at least. I realize 
> that the L4/Hurd effort is sailing into some extremely advanced areas 
> and is all about fixing the performance and other problems stemming 
> mostly from the Mach legacy, and thats cool, but it looks like the 
> usability horizon for L4/Hurd is speeding away into the future.

I guess that's a challenge for us to prove you wrong :)

We are attacking issues at many fronts.  The microkernel discussion is
just one of them.  The discussion of EROS has indeed inspired some new
ideas, which I consider to be independent of the actual microkernel to
be used.  One is persistence.  One is increased security (like
removing the dependency on user IDs for low-level authentication).

One of the "defining" features of the Hurd are translators.  It turns
out that there are some serious problems with translators.  So, some
work will have to go into analyzing these problems and looking for
ways to salvage the ideas behind translators without compromising the
other goals.

All these are challenges in the current Hurd design.  Which of these
we want to address or not has yet to be determined.  However, these
are challenges which exist irregardless of the microkernel chosen!

Unforuntately, I have not looked at the Minix3 interfaces, so I can't
tell how feasible it is to port the Hurd to it.

Thanks,
Marcus