Re: Roadmap?

[Farid Hajji]

> 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:
     http://savannah.gnu.org/projects/l4hurd/
   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:
     http://l4ka.org/projects/version4/
     http://l4ka.org/documentation/files/l4-x2.pdf
   Espen is still coding the Pistachio kernel, which will implement
   the Version 4 API.

   In the mean time, most of us use Hazelnut
     http://l4ka.org/projects/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:
     http://www.uni-karlsruhe.de/~uhns/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.
     
http://savannah.gnu.org/cgi-bin/viewcvs/non-gnu/l4hurd/memory.html?cvsroot=www.gnu.org
      

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

Regards,

-Farid.

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