L4Mach or Refactor Hurd Servers?

[Ian Duggan]

Hi,

I've pored over all the documentation and am getting into the source code for
the relative bits. I've come to a decision point and am interested in some
feedback from the list.

I'm trying to decide between implementing something like L4Mach or
reimplementing the Hurd servers to use L4 tasks directly, complete ripping out
the notions of Mach.

The advantages of an L4Mach are that less of the Hurd code would have to change.
It seems from looking at things that the Hurd is very much aligned with Mach
programming style. Notions of asynchronous IPC and ports and port rights are in
the Hurd. L4 doesn't have these things. From looking through the code, it looks
as if various parts of the Hurd use "mach.h" directly too, rather than having
this stuff hidden within a library.

The advantages of the second option are likely to be speed and general code
improvement. The question here is whether or not we would want to try to retain
the ability to use mach and L4 kernels from the same codebase. The way things
look right now, it doesn't look like that would be easy to do in a flexible/high
performance manner. It also seems to me that all the levels of abstraction in
the Hurd can get in the way two, such as in the recent question about slow disk
access on the Hurd.

As it stands, we will have to implement libports as an L4 task and will
essentially be creating an L4Mach anyway.

Questions: Is it a good thing that the Hurd follows the Mach idea of ports for
IPC so closely? Doesn't that limit it to certain types of microkernel? Is there
a more general notion of IPC that we could use that would allow more flexibility
in the choice of the underlying microkernel?

It seems to me that libports marries the Hurd to a Mach style microkernel.

-- Ian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ian Duggan                    ian@ianduggan.net
                              http://www.ianduggan.net