Re: Mach emulation

[Farid Hajji]

> 1. Write a L4 program which emulates Mach. I'd like to call this
> program "l4-mach". This kernel-like program includes device drivers
> and other Mach service routines.
> 
> 2. Modify GNU libc, so that it can emulate Mach system calls, using L4
> system calls and user-level simulators. I don't think binary
> compatibility with Mach is required. Source compatibility is enough.
You're basically suggesting the Lites/Mach approach, right?

If we talk Lites/Mach, then glibc would contain the emulation library
which will eventually (but not always) contact the l4-mach server for
(mostly) state keeping stuff.

The emulation library should only contain the mach syscalls that are
used either directly in the (non-glibc) Hurd code or that are needed
by the hurd sysdeps in glibc itself. Such mach syscalls could cache
some requests and relay the rest to l4-mach.

Mach tasks and threads should then be mapped 1:1 to L4 tasks and threads
(even if their number is severly limited on L4).

I like the idea, because this is a natural way to implement mach
notifications (e.g. of dead ports etc...) on top of L4. Such
notifications could be sent/triggered by l4-mach into the emulation
library of the clients.

What are you thinking about cthreads? Should they be reimplemented in
the emulation library + l4-mach as-is (to keep modifications to the
Hurd sources to a bare minimum), or should we transition the Hurd to
pthreads API first, and write a pthread N:M thread multiplexing library
for Mach and L4 before starting the emulator+l4-mach work?

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.