[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mach emulation

From: Ad Buijsen
Subject: Re: Mach emulation
Date: Mon, 13 Nov 2000 12:05:29 +0100 (CET)

On 12 Nov, Farid Hajji wrote:

> The point is actually, that the _implementation_ of the Hurd is tightly
> coupled to Mach and as such would have to be completely redone for any
> new ukernel/libmom. But the _ideas_ and _semantics_ of the Hurd (I'm
> referring here to the servers, their external interfaces as specified
> in the .defs and their libraries) are generic enough for a large number
> of underlying virtual machines (be they ukernels, libmom-abstractions,
> guest OSes...). The Hurd is a multi-server OS-personality with some
> unique features like translators. As such, it can (should?) be
> (re)implemented as independently of any ukernel as possible. That's
> the reason I'm suggesting a complete reimplementation of its components
> (despite the amount of work involved).

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

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

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.

And talking of portability: even "clean" ports to L4 will give rise to
portability issues between x86 and alpha.

> begin_provocative_statement();
>   The main difficulty I'm seeing here, is that most of us already know
>   too much of the Hurd source code, being biased towards the existing
>   implementation. It's relatively hard to step back, and throw all the
>   familiar code/features/functions overboard and restart thinking about
>   what the Hurd is _really_ about. It may seem paradox, but IMO we need
>   people knowing what the Hurd is able to do and how the servers are
>   supposed to interact, but not being involved too much with the actual
>   source code of the more "obscure" parts of it like libports.
> end_provocative_statement();

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).

  Ad Buijsen

P.S. I will be very busy this week, so don't be alarmed if I am late in

reply via email to

[Prev in Thread] Current Thread [Next in Thread]