Re: Mach emulation

[Farid Hajji]

gernot>> Sure, you can emulate Mach IPC on L4. You can emulate Mach tasks on
gernot>> L4. And you can then, once things are working, try to eliminate some
gernot>> of the redundant code. My point is, it will be too late then, as too
gernot>> much of the hurd code base will be dependent on Mach abstractions.
okuji>   If you are right, Hurd is good for nothing. I suspect that you
okuji> haven't read the source code actually.
Let's admit it, the Hurd _is_ already completely dependend on Mach
abstractions. l4-mach won't do us any harm right now and is actually
a good idea/experiment to get more insight in the requirements of
a new libmom and in the use of L4 (most of us on l4-hurd are pretty
new to L4, right?).

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

If doing l4-mach on the way helps us understand what is needed and how
to do it, then by all means, let's do it. It's all a matter of taste,
available time and ability. Personally, I like the idea of a kernel
emulator library/server a la Lites/Mach from an architectural point
of view. Practically, I think that it is better to redo the Hurd
components in a bottom-up manner, building/designing libmom at the
same time. But I admit that I'm not sure which approach is better.

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();

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