Re: Mach emulation

[Gernot Heiser]

On Sun, 12 Nov 2000 05:04:26 +0100, Farid Hajji <address@hidden> wrote,

farid.hajji> If we want a small chance to keep some of the current Hurd code,
farid.hajji> it is necessary to port either glibc to L4 (anyone with enough
farid.hajji> glibc _and_ L4 expertise out there?) _or_ extract the hurd-ish

Any L4-based OS project is faced with this problem. Dresden (Fiasco)
is using the OSkit. We tried using that, but found that it was too
much tied to x86 to be useful to us (on the MIPS). (In fact, we wasted
quite a bit of time until we dumped it.) We had looked at glibc before
but people found it dragged in too much other stuff. The IBM Watson
SawMill project is going to release their sources under GPL shortly,
but I'm not sure what they are using for a C library. Chances are that
it'll again be tied to x86.

We're working on something that'll be (at least) 64-bit clean and
Intel-free, but no guarantees as to when we'll have something that's
complete enough to be useful for others (and I'm not sure how
Mungi-free it'll be). Porting libraries isn't considered sexy...

farid.hajji> g> I'd be keen to see it done. I'd be happy to help, mostly by
farid.hajji> g> supervising/supporting local L4-literate student(s) working on
farid.hajji> g> it. We're producing 1-2 dozen students a year who have written 
a small
farid.hajji> g> OS on top of L4 (see http://www.cse.unsw.edu.au/~cs9242). I've
farid.hajji> g> actually offered Hurd/L4 as a honours thesis topic here. So far 
no
farid.hajji> g> bites, but doing it as part of a world-wide open-source project 
might
farid.hajji> g> help attracting a good hacker.
farid.hajji> Would you be willing to help us in this current critical stage of
farid.hajji> redesign? We need a capable systems architect with L4 background
farid.hajji> that is also willing to coordinate our efforts. No-one on l4-hurd
farid.hajji> volunteered yet to manage the project (which is no surprise at this
farid.hajji> early stage of brainstorming).

I'm happy to help, but I don't think I want to manage a second OS
project (besides mungi.org).

farid.hajji> BTW, we're currently needing a L4-HOWTO. Your L4 User
farid.hajji> Manual is great, but we also need a small collection of
farid.hajji> root_tasks (code) exercising the L4-API. This would
farid.hajji> greatly help L4 novices on this list. Among others, we
farid.hajji> need:

Thanks for the comments on the L4 User Manual, but I know its
limitations. Its focus is far too narrow, mostly concerned with
exercising some limited functionality of some system calls.

The L4/MIPS source tree contains some testing code for all syscalls,
but that's fairly unreadable and pretty useless as a tutorial. Some of
my COMP9242 lecture notes might be more useful...

I'd be happy to supply answers for a FAQ (I know, our existing FAQ
contains virtually nothing ;-) but preferably not maintain it.

farid.hajji>   * an intro to sigma0 (e.g. how to read-only map the kernel info 
page
farid.hajji>     (clock!) into the root_task; how to exercise the sigma0 rpc 
protocol
farid.hajji>     in general etc. How to remap memory on demand (vmremap())....),
farid.hajji>   * an intro to rmgr (e.g. how to obtain resources from rmgr like 
interrupts,
farid.hajji>     memory pages etc. What is the rmgr protocol and how can it be 
used?)
farid.hajji>   * more explanations about thread scheduling and synchronization 
(e.g.
farid.hajji>     how to suspend/resume a thread from outside [other prio? 
timeslice?
farid.hajji>     external preempter (what that is, code?)?]? how to synchronize 
threads
farid.hajji>     [on ipc_receive(), joining, condition variables?].
farid.hajji>   * more code of the possible IPC calls (short, long messages, 
timeout
farid.hajji>     receive etc...).
farid.hajji>   * thoughts (and toy code!) on how to implement user-land device 
driver
farid.hajji>     servers/tasks on top of L4.

I can supply answers to most questions of this kind (just not at this
moment ;-). However, I have personally only used L4/MIPS. The rmgr is
only available at present for Intel. However, it's mostly for
multiplexing a machine between different OS personalities and not
really part of L4.

Also, it has to be understood that the L4 API is a moving target (L4
is still a target of research). Different kernels implement different
versions of the API. L4KA is presently the most up-to-date one, but
there are two more stages of API changes under discussion. L4/Alpha is
likely to stay close to current (unless my student Daniel gets hired
away...)

Usage examples can, of course, also be found in other systems built on
top of L4. SawMill and Mungi are both close to release (Mungi within a
month I hope - but I've said that before).

Gernot


Gernot Heiser                ,--_|\   School of Computer Sci. & Engin.
Phone:  +61 2 9385 5156     /      \  The University of NSW
Fax:    +61 2 9385 5533     \_,--._*  UNSW SYDNEY NSW 2052, Australia
E-mail: address@hidden        v   http://www.cse.unsw.edu.au/~gernot