[Top][All Lists]

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

Re: L4Hurd at Sourceforge

From: Farid Hajji
Subject: Re: L4Hurd at Sourceforge
Date: Tue, 23 Oct 2001 01:55:13 +0200 (CEST)

Hi Ian,

> I have created a new project at sourceforge called "l4hurd" aimed at
> getting the Hurd to run using the L4 microkernel.
>       http://www.sourceforge.net/projects/l4hurd
> The project has been approved, and I am in the process of putting
> together an initial CVS setup for us to work from.
that is great! Thanks for starting the project here. So at least we can
start hacking ;-)

> I need some input as to how to arrange the modules, as well as which of
> the many L4 variants out there to use. My current thinking is that we
> aim to use the fiasco microkernel. Comments?
Hmmm... personally, I'd prefer that we start with Hazelnut. It's smaller
and you can build it without oskit/oskit10 support at all. I've played
both with fiasco and hazelnut, but I've found that using the environment
of hazelnut on my {Open,Net,Free}BSD systems is somewhat easier.

BTW, both L4 implementations are very good, and as long as we keep using
X.0 (X.1, V2) APIs, we should probably try to keep in sync with both.
Someone may also be willing to play with L4/MIPS or other implementations ;)

> My thoughts for the modules are:
> 1) Fiasco Module
>    CVSROOT/fiasco/l4      (l4 module from dresden)
>           /fiasco/oskit   (oskit module from dresden)
>           /fiasco/oskit10 (oskit10 module from dresden)
Why? I suppose that we'll use dresden's modules unmodified and let the
maintainers support Fiasco directly. We'll just have to submit patches
(if we happen to find some) and I'm sure that Michael and others would
glady apply them if they make sense for them. The same holds for Hazelnut
(or any successors).

  "Do not meddle in the affairs of [L4] wizards..."    ;-)

> 2) Hurd Module
>    CVSROOT/hurd   (Hurd from official CVS)
> This would allow us to track development against fiasco and the Hurd on
> the import branches for these modules.
Here again, we _could_ do that, but it may be IMHO better to branch
off a l4-hurd branch at savannah directly.

I don't expect a lot of changes in the beginning, because we must first
try to put the foundations in place (like the pager, support libraries,
IDL4/DICE/<whatever> IDL generator(s), device driver framework etc.,
before we can start modifying the Hurd (and glibc!!!) sources themselves.

The changes to the Hurd sources will heavily depend upon the available
base infrastructure. If we manage to approach Mach somewhat (but not as
far as Michael and Sven's Mach/L3) and implement a port-rights server
task that mimics Mach's port rights somewhat, the changes to the Hurd
sources could be very small [of course, this would be just the beginning].
If it proves difficult to do so, we'll probably need more flexibility
with the Hurd sources.

To summarize: I don't see any reason to import the Hurd sources right
now into l4hurd CVS, because I don't expect that we will modify them
any time soon.

And don't forget glibc! Currently, it's part of the Hurd, if you like
it or not ;-)

> Questions:
> 1) Is the fiasco kernel the right choice here? We can easily add other
> L4 microkernels as modules.
As already said: Personally, I've found the build environment for
hazelnut on *BSDs much easier than fiasco's, but both are excellent.
Other implementations are possible as well.

I'd suggest that we restrict ourselves to the APIs (C-Bindings)
that are common in at least fiasco and hazelnut for now. Best way
to ensure this would be to compile (and test!) with both kernels

If the L4 people could provide us with a coherent view of the current
(and upcoming) APIs and C-Bindings, that would be _great_! (hint, hint!)

> 2) Having multiple oskits in the fiasco modules is annoying. How far is
> fiasco from being able to use a single oskit version?
Do we have to use oskit at all? If so, I'd prefer that its use be
purely optional, e.g. for single (non-essential) user-level tasks
like a pager, device driver [framework] etc. I do like OSKit, but
only as long as I can choose to use single libraries to bootstrap

> 3) Is this the correct way to setup CVS? Are there any other
> suggestions?
Why not start along the TODO list, putting only additional (new)
stuff to CVS, e.g. like this:

   vk-l4/             # virtual kernel, l4-backend

   vk-l4/oskit/       # mixins w.r.t. the _newest_ OSKit from Utah!
   vk-l4/gcc/         # specs and other modifications to gcc, if needed.
   vk-l4/private/include  # includes, idls and libs used internally
   vk-l4/private/idl      # by the vk-l4 components
   vk-l4/private/lib      # not exported to OS personalities.

   # Here only the public interfaces of vk-l4:
   vk-l4/include/     # includes needed by vk-l4 users (OS personalities)
   vk-l4/idl/         # IDL files (like our *.defs) used by OS personalities
   vk-l4/lib/         # libraries used by vk-l4 based OS personalities

   # Now for the guts of VK/L4:
   vk-l4/pager/       # our new general purpose L4 pager, probably UVM based.
   vk-l4/drivers/     # the driver framework Michael Hohmuth talked about
   vk-l4/nameserver/  # naming service (a.k.a. rendez-vous, port-manager...)

   # Here come the OS personalities using VK/L4:
   l4hurd/            # Changes for the Hurd multiserver w.r.t. savannah.
   l4linux/           # Changes to L4Linux to adapt it to new vk-l4 framework
   l4bsd/             # Anyone interested to port NetBSD to vk-l4? ;-)
   l4<whatever>/      # some other OS personality using vk-l4

This way, we'd incrementally contribute code to a general purpose
infrastructure on top of L4 upon which we could not only base the
Hurd, but also other single servers (L4Linux, L4BSD<vaporware right now>,...)

What do you think?

> --Ian


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]