Re: Mach on L4 (was Re: SawMill Multiserver vs. the Hurd)

[Farid Hajji]

Hi Michael,

> > I won't object against implementing the mach server and associated
> > emulation library (Okuji's idea), at least implementing the subset
> > of the Mach-API used in the Hurd. 
> In 1996, Sven Rudolph and I worked on something similar: A Mach
> emulation library for the L3 microkernel, a predecessor of L4.  We
> craved for a Unix environment on top of L3, and our goal was to port
> Lites, a BSD single server for Mach, to L3.
>
> We documented our findings in a term paper (I think it has been cited
> in this forum before; see
> <URL:http://os.inf.tu-dresden.de/~hohmuth/prj/lites-on-l3/>).
I just finished reading beleg.ps and Jean Wolter's
  http://www.inf.tu-dresden.de/IBDR/lsbs/L3/UNIX-Emulation/techreport.html
Sorry for the delay.

The Mach/L4 with associated Mach emulation library Okuji and I were
thinking about are closely modelled after Lites and its emulation
code. Actually, I'm using FreeBSD/Lites/{CMU-Mach,RTMach} as a
development enviroment for Mach-based tests and switched only some
years ago to GNU Hurd/GNUmach as yet another Mach environment. I'm
therefore acquainted to Lites (source code and Helander's thesis)
which led to the idea of implementing (a subset of) Mach on top of L4
and put the Hurd on top of this (what a show...).

I was actually thinking along similar lines than what you described
in beleg.ps, so reading that paper was quite easy and yielded some
expected (and some less expected) results.

> Back then, our conclusion was that emulating Mach is very complex, and
> porting a monolithic Unix kernel to the microkernel interface is
> easier than transforming a Mach server to an L4 server.  Later in '96,
> I and others went on to create L4Linux, a port of monolithic Linux on
> top of L4.
Porting Mach to L4 is certainly no easy task (no pun intended). Just
as you described, some issues like e.g. VM and Tasks/Threads could be
in theory possible; asynch messages and port rights could be queued
and device drivers would hook up on Mach's dev*() API. Porting MIG or
writing a new stub generator looks more intimidating though but the
L4Ka people are currently experimenting with an IDL4 compiler if I got
that right. What makes this project difficult is the lack of
experienced hackers right now: Some people are somewhat acquainted to
Mach and others may have enough L4 knowledge, but finding people with
expertise in both areas is quite difficult.

> That's why I liked the idea someone brought up on this mailing list
> some weeks ago: Instead of starting to port the Hurd to L4, first port
> Mach (a ``monolithic kernel'') to L4, and quickly get the Hurd up and
> running on top of L4 using the resulting L4-Mach server.  Later, strip
> the Mach server and/or reduce Hurd's dependencies to it to create a
> lean system.
That's exactly the idea.

> That said, however: Anyone who wants to start a new Mach-emulation
> library might want to take a look at our L3 work.  We have a small
> library that provides a subset of Mach' IPC primitives on top of L3
> IPC, and we also support simple `mig'-generated stubs.  It is probably
> impossible to get our software up and running on an L3 or L4 system
> nowadays, but it might still be interesting to have a look at it.  I'd
> be happy to make our source code available upon request.  Currently,
> the code is BSD-licensed.
That would be great! The more example code we can study, the better.
If you could make your work available, this would help us tremendously.

BTW, do you have some teaching material about L4-API like sample
root tasks, libraries etc (besides L4Linux)? This could help L4-newbies
to get started more rapidly.

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.