Re: project died?

[Farid Hajji]

Hi Zeno,

> Are you still working on l4-hurd?
> There hasn't been any traffic on this list in 2001!
> If it has died, I'll put that on the web page,
> together with a link to the archive, so that other
> people can continue the work some time in the future...
I'm not aware of anyone working on l4-hurd right now.
There were some useful comments and suggestions that
could be used as a starting point, but at least the
following problems stopped us. I guess that there
will be no progress here, until these problems are
solved:

1. We need a libpthreads that is able to multiplex
   user-level threads to kernel (native-) threads.
   Such a library should ideally have at least a
   mach (cthreads (?)) and L4 back-end.

   At a first shot, a libpthreads that maps user-level
   threads to kernel-threads 1:1 would be sufficient
   to get started, but due to the severe limitations
   of L4 on the number of threads per task and the
   proliferous use of threads in the Hurd, we'll need
   an n:m (n >= m) mapping anyway very soon.

2. The Hurd needs to be ported to this libpthreads,
   by replacing calls to cthreads with standard
   pthread calls.

   This is yet another reason, why the needed libpthreads
   should have a mach backend besides an L4 backend.

3. Okuji suggested to start porting by implementing
   a Mach server (mach-task) and a mach emulation
   library in L4, so that the Hurd servers can link
   against libmachemu and access mach-task for thinks
   like port-rights, device-access, ...

   This approach is similar to the Lites/Mach and
   L4Linux/Fiasco methods and it looks very promising.

4. There were some toughts about gcc specs, to get
   started, but I'm not aware of any progress there.

5. I experimented with L4 toy servers under Hazelnut and
   misc. C libraries like OSKit's minimal and regular libc's.
   Since glibc was not ported yet to L4 (how should it be?!
   L4 is extremely far from a POSIX-like kernel, even further
   away than Mach), there is some kind of chicken-and-egg
   problem here.

   To overcome this situation, I started (privatly) by
   ripping glibc apart, moving the mach sysdeps into a
   separate libmachemu.a and the hurd sysdeps into a
   libhurd.a library. The rest of glibc looks very portable
   and can be replaced by other vanilla C libraries,
   e.g. OSKit's.

   The advantage of extracting the mach/hurd sysdeps from
   glibc is that it is no more necessary to port the whole
   glibc to a foreign environment like L4 (or a Lites-based
   system). One obvious use is running the Hurd under
   keio/rtmach (a Lites environment provinding support for
   FreeBSD-binaries as well as native (RT-)Mach support)
   or other Mach environments where a non-glibc C library
   is already in place. This is just a first step towards L4,
   of course.

6. Even if we succeeded in providing Mach-compatibility through
   mach-task + emulation library, this would be only the first
   step towards true porting. The first big problem would be to
   define a replacement for port-rights in L4. port-rights would
   be first hold in mach-task, and maybe then in a port-rights
   L4 task, but this could soon become a bottleneck (or not, it's
   hard to tell on hypothetical systems!).

   A more distributed approach to port-rights could be called for,
   but that would mean changing the interfaces (.defs) of the
   Hurd servers, so that the rights are distributed and checked
   across all involved parties (no more central "trusted" server).
   This is all very theoretic and far away right now.

7. On the L4-side, there are some caveats too: The X.0 API is still
   subject to changes and the l4-hackers and l4ka people are probably
   working on new improved interfaces, including SMP support. It would
   be necessary for the l4-hurd project to closely follow the developments
   there.

8. Some lessons could be learned from the SawMill project
   http://www.research.ibm.com/sawmill/ as well, since they
   are also trying to build a multiserver (starting from L4Linux)
   on Lava. The Hurd, being a multisever too, could steal/borrow
   some ideas, mostly concerning the L4 backend, from SawMill.

If and when the first problems (mainly libpthreads and [g]libc/l4) are
solved, the l4-hurd project could be revided ;-).

Regards,

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