The GNU/Hurd home page says, "The Hurd is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux)". Over time, however, this may change.
In a recent thread, Farid Hajji offered an update no the Hurd/L4 port. The goal here is to replace the aging Mach microkernel with the newer L4 microkernel. The effort is still in the early stages, Farid describing it so far as a "skeleton project". Current efforts use the Hazelnut implementation (v2), though the plan is to use Pistachio (v4) when it's ready, adding 64bit support.
More details can be found in Farid's email. Read on...
From: Farid Hajji
Subject: Re: Roadmap?
Date: Fri, 19 Apr 2002 09:55:46 +0200 (CEST)
> Note that I didn't say anything on L4, as it is hard for me to assess
> how much work is being done there, because the L4 work probably can't
> just be started, but must be planned carefully. I can see that some
> planning has been done, but one of the people working on it would have
> to comment on the status.
Status of the Hurd/L4 port:
1. Ian set up a project at savannah:
Currently only skeleton project, but new code will eventually
be submitted there.
2. We'll code against the new L4 Version 4 specification.
That spec has not yet been released, but a preliminary experimental
spec. has been approved by the L4 community:
Espen is still coding the Pistachio kernel, which will implement
the Version 4 API.
In the mean time, most of us use Hazelnut
for tests and to get acquainted to L4 principles and (old) APIs.
3. We'll most likely use some kind of RPC generator as a replacement
to MIG. One of the stub generators is IDL4:
Anybody interested in playing with IDL4 and Hazelnut is strongly
encouraged to do so. Write some stand-alone (root-)tasks that
IPC each other via IDL4 stubs and please post the code of those
toy programs to savannah. We need to test IDL4 w.r.t. the current
RPC model used in the Hurd, but also in standard synchroneous IPC.
4. Thread support: The new L4 X.2 (and most likely Version 4) specify
an unlimited number of native L4 threads, as well as the API to
access them. Jeroen is working on a pthreads implementation for
glibc (ask him for status) and it will be necessary to connect
glibc-pthreads to L4 threads in the sysdeps.
The issue of M:N multiplexing threading library is no longer
a problem for X.2 or Version 4. For Hazelnut, we'll have to
live with a limited number of native threads for the moment.
5. VM-Support: L4 provides a very different memory model than Mach
(recursive pagers). Two approaches are possible here:
5.1: Redesign the Hurd to use the L4 memory model
5.2: Emulate Mach's VM API with an L4 memory server task.
5.1. seems unrealistic at the moment, so we'll start with 5.2.
I'm investigating NetBSD's UVM, which is an improvement to Mach-VM
and BSD-VM as implementation for the L4 memory server task. UVM
is now also part of OSKit, though not as actual as in NetBSD-CURRENT,
which I'm playing with right now.
6. Driver Support: Two models are being investigated:
6.1: OSKit drivers
6.2: L4Env (http://os.inf.tu-dresden.de/L4/bib.html#l4env)
We're waiting for a release of L4Env.
It's not yet clear wether we should stick to Mach's device API
or if the oskit-mach people are considering a totally new approach.
Basically, the drivers must be implemented in user-space (L4 API
sends INTs to driver threads through IPC, much like in Mach).
As Wolfgang said, nothing will happen unless we get more volunteers
to help. There are some time constraints (like, we're waiting for
Pistachio etc...), but a lot of things can already be done right
now by people with some spare time ;-).
Farid Hajji -- Unix Systems and Network Admin
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.