Re: Mach emulation

[Farid Hajji]

> I agree that the Hurd should be re-implemented, but I disagree with the
> idea of a libmom.  If you want true kernel independence you will need
> to design a very general set of abstractions; this will take a lot of
> effort and the result will be slow and bloated.  I find this
> inacceptable.
On the contrary. Libmom is not supposed to provide a fat interface on
top of ukernels. Actually, libmom should only provide the absolute
minimum services that a new ukernel like L4 is providing. Everything
that goes beyond that should be implemented on top of libmom. A well-
designed libmom and a libmom-retargeted Hurd would even be easily
back-ported to Mach or whatever system you want, because that would mean
relying on a minimal set of features nearly all kernel provide.

> If, on the other hand, you design libmom to be close to L4, you will
> end up with a relatively thin layer between the kernel and the Hurd
> itself, but the cost will still be > 0.  Also, a port of such a libmom
> to a microkernel that differs significantly from L4 may well be a
> nightmare.
Why not use L4-API directly and forget about libmom? Well, first of
all, a very important portion of the Hurd relies on IPC, tasks, memory
regions and (unfortunately) kernel-protected capabilities. If we used
L4-API directly, a port of the Hurd to another system or ukernel would
be much harder than just provide another libmom-{other-kernel}. The cost
would be > 0 in some cases, but in the L4 case, libmom may well map
nearly 1:1 to the L4-API and nothing prevents us from implementing
libmom calls as simple macros to L4 functions/abstractions.

> So, libmom will not give you much of a win in terms of portability
> while resulting in a loss of performance (and of effort that could be
> spent elsewhere).  At least, that's how I see it.
Even if you dislike the idea of libmom, please think of the consequences
of using directly L4 calls everywehre in the Hurd. A port to L4 may
then be made, but a later port to other systems would be much harder.
What we (presumably) win now, we'll lose on the long term.

> And talking of portability: even "clean" ports to L4 will give rise to
> portability issues between x86 and alpha.
That is always a problem and I'm aware of that too, because I'd also like
to see the Hurd run on top of SPARC, MIPS and alpha. This is one more reason
to not rely directly upon L4-API, which could well depend on the target
architecture (when it comes to the format of descriptors, syscalls etc.),
but to isolate such differences behind a [thin] libmom API.

> Yes.  What we need is a formal description of the Hurd to work from,
> resulting in clean-room implementation (if that _is_ what it is called).
Yes, you're absolutely right! This is the reason I'm right now respecifying
auth (followed by proc) from scratch, planning to look at the other components
in more detail later. A clean-room implementation may well be necessary,
considering the amount of work that would be needed to clean up that
Mach dependency mess everywhere. I'm also keeping in mind, that the new
Hurd should also run as a distributed system on a multicomputer sometime
in the future. Only a redesign that takes this into account from the very
beginning would guarantee success here.

As Okuji put it, the problem with a total redesign and reimplementation,
is that it is a tremendous amount of work that would not lead to a working
system in short time. Many potential contributors could be put off by
having to work on single components, not seeing any running system within
a long period of time. That's why I'm not opposed to l4-mach approach
as an intermediary step. But even then, we must spend some time on
serious thinking (and implementing) of a cleaner Hurd system.

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.