[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mach emulation
From: |
Farid Hajji |
Subject: |
Re: Mach emulation |
Date: |
Sat, 11 Nov 2000 03:21:29 +0100 |
> 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.