[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: status of l4-hurd

From: Farid Hajji
Subject: Re: status of l4-hurd
Date: Mon, 27 Aug 2001 16:34:00 +0200 (CEST)

Welcome Jeroen,

> I'm interested in porting hurd to L4. I'm busy reading L4 papers and the
> mailinglist archive and I will soon start playing with L4. If I understand
> everything correct, we first need to replace the *.defs with *.idl and=20
> generate the stubs with flick. After that we need a libpthreads for mach
> and L4 (or does that already exist?). Then it's time to design a kernel
> abstraction layer/virtual kernel or how you like to name it. Porting hurd
> to that layer and write the L4 layer code seems like one of the last steps.
yes, this is exactly what should be done in order to port the Hurd to L4
(or, more exactly, to a VK that would use L4 as one possible backend).

> 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.
The second way is comparable the the current mach/hurd sysdeps in glibc
and since L4 (or VK) are leaner than Mach, we'd probably need even more
sysdeps code to reach the same target. I'd prefer that we try the first
method and try to port glibc in such a way as it would use the POSIX
emulation library like it uses e.g. Linux syscalls internally (think of
the POSIX emulation library as simulating a traditional monolithic
kernel. We may even provide a syscall() "trap" library function in
POSIX to make it appear as say Linux, {Net,Open,Free}BSD.

This is just an idea right now. In the meantime, I'd suggest that we
use OSKit's libc (and other components) while running under L4. OSKit
has its limitations too, but you'll have at least something to get started.

> Is there already any work done in
> one of these areas?
There is no working code yet. Marcus ported flick to the Hurd (there's
a debian package) so that you could try rigt now to either compile
the *.defs directly or write some simple (toy) client/servers with
IDL on top of Mach.

I'm playing with flick right now, and will try IDL4, as soon as it is
publicly released (even if it is only beta). I'd also like to try
http://os.inf.tu-dresden.de/~ra3/DICE/ but I didn't have the time to
do it yet. Right now, I'm working mostly with pencil and paper [both
virtual ;-)], trying to figure out how the interfaces should look like.

If you have some ideas, please contribute!

> Jeroen Dekkers


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]