Re: L4 instead of gnumach?

[Erik Verbruggen]

*long explanation alert*


Ok, I think the L4 stuff needs a bit of background. Special for Niels: I
started doing a Sparc port, but there were some problems which are
similair to those that the Alpha port has, so that's why I react.

(oh, and I have an Alpha, so I'm also interested in the Alpha port :)

On Mon, Oct 30, 2000 at 11:04:02AM +0100, Niels Möller wrote:

> (I believe managing send rights is a sane way to deal with security in
> a complex system. So I don't think it is good enough to just try to
> change the HURD's model to fit L4; after all, one of the points of
> the Hurd-L4 thing is to make the HURD less dependent on particular
> micro-kernels. To do that, one need to identify the features that are
> essential to the HURD, and find out the best way to get them on each
> kernel one is interested in).

This is precisely the problem with GNUMach, and why I've made little
progress in porting HURD to any microkernel on Sparc. The Sparc I have
has SBus as primary bus, so no ISA/PCI or other PC bus. For this I tried
to disable *all* the device drivers (not the service, but the drivers
itself). This is not trivial, because there are actually two sets of
drivers: the Linux ones and the Mach native ones. The other thing I did
is seperating and cleaning up the header files and directory structure.
Note: this is in my private copy, and I don't know if I will ever commit
it to CVS. You might see this as basic research on how GNUMach works
(ie: what depends on what, where is what and how does it fit/work
together).

Now we have the Alpha team which is also porting HURD on some
microkernel. Their specific problem is that the drivers which are
currently in GNUMach are quite outdated and have poor Alpha support.
I've followed the changes to the GNUMach CVS repository, and there
appears to be very no work on drivers. This is understandable: it works
well, also on my PC.

So, for any port to be done, the drivers do need work. Along the way I
(and obviously others) stumbled across the L4 family, which has one eye
catching difference: it is *far* more modularized than GNUMach. One of
the consequences is that there are no device drivers in L4. Those should
be an add-on service, just like HURD is an add-on service.

Now my opinion is that GNUMach would improve if the driver portion would
be removed and made a seperate service. One consequence is that GNUMach
needs to be modified to support more servers.

So for porting there is the actual kernel left. The question is quite
simple: is it better to modify GNUMach to run on Alpha, or take L4
(which runs on Alpha and has SMP support) and implement something like a
GNUMach server? The answer is quite hard, and I don't know it.

To conclude: What I'd like and plan to do is to seperate the drivers
from GNUMach to simplify porting. For Alpha this means that they can use
this driver service, but still have to write the GNUMach server. For
Intel this means updated drivers. For Sparc this means that I have the
choice of porting GNUMach or porting L4, depending on how the work on
Alpha goes. This is also where my programming effort goes to at the
moment.

Well, I think that's all.

Erik.
--
Erik J. Verbruggen, ejv@cs.kun.nl, Daneel on IRC,
room A5005 science faculty KUN, phone: +31-24-3652229