Re: L4, libmom and the Hurd

[Farid Hajji]

Hi Brent,

[I've CC-ed this to l4-hurd for feedback]

> This seems reasonable.  I'm starting to think that any microkernel
> is going to have to be closely tied to the Hurd sysdeps layers to 
> work.  I'm thinking that the sysdeps stuff *is* the libmom layer
> -- i.e., we shouldn't add another layer of abstraction on top of
> it, except where _required_ to implement certain Mach emulations
> required to achieve the same message-passing semantics (i.e.,
> broadening the RPC's to match the richness of the Mach layer, etc.)

I'm not quite sure... The sysdeps stuff is mainly the implementation
of the familiar Unix/Posix syscalls on top of mach. Of course, we
could add l4 sysdeps which do exactly the same kind of stuff. This
is probably the way to go, but there are two problems:

1. cthreads are not available outside of mach, so someone must add
   pthreads to glibc. The idea to try something else besides glibc
   (like e.g. FreeBSD libc that is also present in OSKit) was that
   pthreads was already there. But how should kernel-threads be
   connected to pthreads? Throught sysdeps/mach, sysdeps/l4, ...?

2. the hurd itself contacts mach in nearly every file, not only
   (cleanly) via glibc/sysdeps. This is unfortunate because we'll
   have to get rid of such dependencies. That's the reason for
   a libvk API.

> Another alternative would be to attack Mach itself, by attempting
> any of the various hacks outlined in the research documents
> (faster IPC, etc.)  I wonder if we could approach L4 speeds or
> if the design of Mach is just too fundamentally flawed.
The main flaw of mach with respect to L4 is its asynchronouus IPC
model. Messages are buffered in the kernel and each IPC requires
copy-in and copy-out operations. Due to this overhead, the hardware
cache of most processors is inevitably flushed (unusable). L4 tries
to keep the IPC overhead to a bare minimum and this is the exact
reason for its performance.

> In practice, the real bottlenecks are most likely in the Hurd
> software itself -- the memory manager is a likely target.
...but only because IPC in mach is so slow. Of course, the Hurd
would have to be optimized while porting to L4. One example is
the kind of message passing between glibc and the misc. servers
and translators:

  Messages could e.g. be passed as opaque data in an L4-IPC call.
Because short messages (registers) transit very quickly through
L4, we should think about what is really transferred between the Hurd
servers and possibly try to reduce the message size to 2 or 3 dword_t
max (more on non x86-platforms, but we should remain portable (?))

  The IPC on hurd/l4 should really be synchronouus in nature, if we
don't want to reimport the old inefficiency of Mach by unnecessary
buffering. Mach emulation may not be the best way to proceed right
now (IMHO).

For my part, I'm slowly thinking that we should get rid of libports
(or re-design it from scratch) or even rewrite the single components
of the Hurd (servers and Unix/Posix emulation library) completely :-(

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