Re: status of l4-hurd

[Jeroen Dekkers]

On Mon, Aug 27, 2001 at 04:34:00PM +0200, Farid Hajji wrote:
> Welcome Jeroen,
> 
> 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).

I think the way to go is to first port hurd to L4 and after that defining
the VK interface. We should from the start seperate L4 specific code, but
defining the VK (or better, kernel abstraction layer, that's more clear
imho) interface before porting the hurd, so that we can do what we think
seems right at that moment.

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

Porting glibc to L4 is the best option I think. It's possible to do that
from L4Linux to make testing easier. See also Niels his reaction on this
subject.

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

Flick doesn't have all options mig provides, compiling *.defs directly
isn't going to work. Flick is the only IDL compiler which works with
mach afaik.

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

We should keep to the interfaces defined at the moment as much as
possible imho. I don't have any experience with IDL, I'm learning the mig
language first so I understand the currect interfaces, I have already
learned a bit about CORBA IDL too. IDL4 looks very promising, but it's
not available yet.

> If you have some ideas, please contribute!
 
Of course I will do that, I also invite you to join the chat in #hurd at
openprojects.net. My IRC client is always online and if I'm working on
my computer I will look at it from time to time.

Jeroen Dekkers

pgpdBQuKtqITY.pgp
Description: PGP signature