Re: Mach emulation

[Ad Buijsen]

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

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.

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