[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: project died?
From: |
Farid Hajji |
Subject: |
Re: project died? |
Date: |
Sun, 18 Feb 2001 19:33:48 +0100 |
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.
- project died?, Zeno Gantner, 2001/02/18
- Re: project died?,
Farid Hajji <=