Re: [Hurd-alpha-devel] Re: L4 instead of gnumach?

[Farid Hajji]

>   If you just want to examine the L4 API, you might just as well use 
> L4Linux; all L4 system calls are available.  There is also a small
> multi-server OS available for L4KA which would make interesting study
> material.
A small multi-server OS for L4Ka? Where? I'm running L4ka's template
root_task inside a hacked up version of bochs and currently trying to
figure out how to create tasks, activate threads and doing simple ipc
between tasks without looking too much at Fiasco. A small multi-server
application on top of L4Ka would be a breeze!

>   The HURD relies heavily on mach: ports are used profusely and threads
> are assumed to be available in bucketloads.  L4 offers nothing like
> ports and the maximum numbers of threads per task is quite limited.
> There are ways to overcome the latter, but the cost (in terms of
> performance) may be prohibitive.  Perhaps a L4 guru can shed some light
> on this matter.
Yeah, that would be good. A libports guru could also help to explain
what is mach-specific (this we can map to L4 ipc) and what is needed
by the hurd.

A pthread library could of course multiplex more pthreads on fewer
kernel threads like is done in solaris. l4ka-x86 currently supports
just 64 threads per task and 128 tasks in total, but this is mainly
due to the format of the uids (task/thread identifiers) bit-layout
(nr of reserved bits for the lthread and task fields). There seems
to be enough reserved space there, so I can in theory imagine that
increasing this limit by one, two or three powers of two may be
possible. But as you put it, a L4 guru should speak here!

>   L4 itself is a work in progress, and I don't think that the API has
> stabilized fully yet.  There are the changes needed for SMP, a tweak
> proposed for supporting user-space debugging and a new and more
> flexible IPC redirection described in a paper (and implemented in
> LAVA?).  We need a sufficiently progressed API to work with, and one
> that is supported by all the "interesting" implementations of L4.
Agreed. I think that the safest way is to use the primitive X0 ABI
spec. currently implemented in L4Ka. Setting up an API for it should
not be that difficult. We even wouldn't have to hammer this API in
stone if we hide all ukernel specific APIs in a libvk-l4 library
that defines a virtual ukernel.

>   Then there is the little matter of pagers and where to put the device
> drivers, how to reuse the ones from Linux and how to preserve at least
> some of the real-time capabilities of the microkernel.
I think that we should follow what the L4 groups at L4-Fiasco and
L4Ka and OSKit/Flux are doing/thinking about this. I'd suggest that
we virtualized the Hurd first and play with the L4 ABI/API a bit,
while these groups work on a concept of supporting device drivers.
Of course, if you have any ideas, please share them with us and with
the L4 folks.

>   On the upside: there is a lot of documentation on L4, and it has been
> tinkered with heavily by several academic groups.  For instance, DROPS
> has sprouted a lot of interesting subprojects, some of which may be of
> use to a HURD/L4.  The important thing here is that cooperation with
> said groups is important. 
Agreed, but we should do our homework first by reducing/eliminating
the mach dependency in the Hurd (probably by a libvk interface as
proposed earlier).

> Maybe they can even be persuaded to help
> porting glibc.
Why not? After the trouble I've encountered just to compile glibc on
FreeBSD (and failing), I'm not that optimistic about it. But there's
a lot of glibc hackers out there who would be glad to help.

>   All in all, I think that getting an implementation of the HURD on L4
> will be a major undertaking, requiring careful study, experimentation
> and planning, and may well need redesign of important parts of the HURD
> to result in something that is as fast as is expected.  Still, it is an
> interesting project.
Please see one of my previous posts on the libvk-* virtualization
proposition. I'd like to do it, but I need a lot of help (and feedback
concerning the VK interfaces). Just a offer ;-)

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.