Re: Hurd questions

[Marcus Brinkmann]

At Sun, 9 May 2004 14:27:19 +0200,
Farid Hajji wrote:
> > Has Hurd different levels?
> >         1- A generic part which doesn't change.
> >         2- A different part that changes to interact with different 
> > microkernels.
> 
> If it had, we would already have a working Hurd/L4 implementation.
> Hurd was intimately tied to the Mach API when it was first conceived,
> perhaps because Mach was the only microkernel back then.

This claim has been dismissed before, let me do it one more time.  The
source code is intimately tied to Mach, but conceptually, the Hurd is
not at all tied to Mach.  This is proven by our Hurd-on-L4 design
which makes very little changes to the Hurd conceptually.

There are a couple of errors in the Hurd design which have been caused
by certain Mach idiosyncrasies, but we have rectified them in our
design.

> The goal of
> the Hurd/L4 project is exactly that: trying to build layers in the
> Hurd.

This is simply not true.  The Hurd is already mostly layered right.
We add a layer below the current microkernel level, though.

> An upper layer would be uKernel agnostic, and the other would
> interact with the microkernel (be it Mach, L4 or some kind of virtual
> machine). Doing this is difficult and requires a lot of thought, because
> we've got to use different paradigms in the IPC model.

There are just way too many details that spill into the interface
definitions.  If you look at the Hurd interfaces, they are barebone
RPC interfaces.  So, the paradigms of the current microkernel you are
using will have an effect deep down at the core of the Hurd - it's
unavoidable.  For complex data types - arbitrary length strings,
memory maps - you are facing a hard microkernel dependency, which
affects at least some of the RPC interfaces in a very direct sense.

There will always be parts you have to redesign with every
microkernel.  There are parts you _want_ to redesign to take
performance advantages.  For example, the I/O path, ie how memory is
exchanged.

So, the myths is that the Hurd is designed around Mach, but the truth
is that the Hurd is designed around an abstract RPC mechanism that is
a subset of Mach.  I have clarified this in my capability library by
using a generic term, and by simplifying the abstract RPC mechanism
even more (to allow better optimization).

If you want, look at the Hurd's libports and my libhurd-cap-server,
which is in CVS for quite some time now.  If you look at the public
interface, you will find that my library is significantly simpler from
the outlook.  But if you take another look at how libports is actually
used in the Hurd, you will find that the subset of libports I
implemented in libhurd-cap-server is the only thing the Hurd really
needs in its servers - the other libports features were only needed to
cope with Mach specific details in some rare situations.

> > If they don't want to cooperate, then we should make our own work.
> 
> The group at Karlsruhe (the L4::Pistachio creators) and the rest
> of the L4 community is not only cooperating with us, they are
> extremely helpful. I'm pretty sure that they would be more than
> happy to see a Hurd/L4 version spring into existence, if only
> to make measurements and publish papers about it ;-).

Unfortunately, such things don't spring ;)

> > Should we make the hurd run on different microkernels or make especific 
> > microkernels for the hurd? What is better?
> 
> Hmmm, that's an interesting question.

I think it's useless (sorry for the contraction of the argument, but I
think that if you look carefully at the design document we wrote, you
will agree).

Thanks,
Marcus