Re: status of l4-hurd

[Farid Hajji]

> > > Glibc needs also be ported if I'm right.
> > This is a tough one. It depends on the way we're going to follow. If we
> > base everything on top of VK, then we'd need a POSIX emulation library
> > that would probably be outside of glibc (for max. portability). Should
> > we do it the glibc way, we'd need to write VK(?) or L4 sysdeps in glibc.
> 
> I think the VK interface sounds interesting, it sounds like a daunting
> task to define it though, what would be the best way to go about it ?
It _is_ daunting, as you've guessed!

The biggest (psychological) problem is to step back first and avoid thinking
in current Hurd-ish terms. This is not easy at all.

Just one example: The Hurd uses ports, port classes, libports and message
demultiplexing for its IPC. This may be good in the Mach case, but it
probably doesn't belong there. All this IPC-helping stuff should be the
domain of IDL-stubs/skeletons and would be implemented differently on
Mach, on L4 (on any VK). I'm trying to redo the Hurd by abandoning the
ports semantics completely, but this unfortunatly also means that most
of the (IPC) code can't be reused. This is exactly what weighs so much...

What belongs to a VK? One idea would be to assume that L4 represents
an ideal VK and that we should try to target the Hurd towards a L4-ish
VK. This is _not_ a good idea, because L4 is simply too slim at all.
It's probably safe to assume a somewhat more comfortable VK, e.g. one
that provides system-(cluster?) wide VM and synchroneous message passing.
At the moment, I even assume that a VK provides pthreads API to access
the native threads; therefore I'd suggest that the new Hurd code (including
the IPC skeletons) use that pthreads API right from the start. I also
assume a device access mechanism comparable to Mach's, though I'm not
sure about this yet (it's not so problematic for the Hurd, because its
hidden in only a few places, e.g. storeio and therefore easy to change
once the device API stabilizes somewhat).

> Is the layer between the Hurd and mach defined anywhere ? 
No, not at a single place. Currently, there is _no_ layer between
the Hurd and Mach; the Hurd (and glibc) use mach calls directly,
whenever they are needed. An important portion of Mach syscalls
include mach_msg_send() and mach_msg_recv() that are generated
by MIG and you'll find Mach calls scattered almost everywhere
trough the Hurd and glibc Mach/Hurd sysdeps sources.

> I imagine it would be take a lot of refining to get right.
Oh yes, that's absolutely true. But it's really interesting as well!

> Glenn

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.