[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: Mach independence

From: Farid Hajji
Subject: Re: Re: Mach independence
Date: Sun, 2 Dec 2001 21:42:37 +0100 (CET)

Hi Ondrej,

> I suppose that's the point of L4. Features needed by Hurd must be
> implemented in the mk abstraction layer of Hurd. Do you think there
> are some areas that are not easy to be implemented efficiently on L4
> ?
please look at recent archives of l4-hurd for the current status.

> If your goal is layer very similar to some subset of the Mach API
> (i.e. Mach emulation in fact)
> then it is only matter of writing some typedefs, constants, wrapper
> routines/macros, 
> putting them into a few header files and replacing all Mach stuff
> with them. 
> Seems easy but it has to be done and I was just wondering if somebody
> actually plans this or not.
As already discussed on l4-hurd, writing a complete (or btw. even a
partial) mach emulation may not be the best solution. Some things
in VK/L4 will emulate certain aspects of Mach behaviour quite closely,
then again, others may not.

One good example is how to implement vm_*() functions in VK/L4: The
consensus for now seems to be that we need a user-land pager running
on top of L4 which will serve pages through a yet-to-be-agreed-upon
protocol. This protocol will be implemented with IDL stubs and a
support library would then provide vm_*() calls to client tasks on
one side and RPC the pager on the other side. At the moment, I'm
advocating that we implement this pager using NetBSD's UVM kernelpager.
So, if we have this pager, calls to Mach's VM (and idirectly to its
default pager) will simply be rerouted thru this vm-library. The
consequence is that no changes to the Hurd code base will be necessary
(at least for VM stuff).

Another example are device drivers. We (l4-hurd) are investigating
two alternatives: OSKit maintained drivers and the L4Env environment
that must still be released by Dresden University. In any case, it
will be probably easy to provide glue code that will mimick Mach's
device framework dev_*() functions. Here again, I expect no necessary
changes to the Hurd's codebase.

The most difficult part in the l4-hurd port right now is how to
map Mach IPC to L4 IPC. Mach IPC is basically asynchroneous, whereas
L4 IPC is synchroneous. Current status in the discussion on l4-hurd
is this:

Most of the Hurd calls can be made synchroneous. There is _mostly_
no need for asynch. communications (I'd suspect in more than 95%
of the cases, but that is more of a wild guess than anything else).
This portion of synchroneous calls can be implemented quite straigtfully
by an IDL compiler which will convert *.idl files to L4-IPC. At least
two such IDL compilers for L4 exist and for Mach, we have flick-1.x,
which also supports L4 as backend. So the Hurd people will need to
first migrate from MIG to, say Flick/Mach and provide IDL files instead
of the current MiG *.defs. Then we can hook in one of the L4 IDL compilers
to generate the synchroneous IPC stuff.

The current problem with IPC is how to obtain no-senders notifications
in an L4 environment: In the Hurd, the servers (or more exactly, the
stubs) need to know when a port is dead a.k.a. when it can be sure
that no clients will ever send an IPC down this port, so that it can
clean up resources. The obvious scenario is when a task dies and so
a translator will have to release all open fileresources of this task.
There is no such mechanism in L4, so it will have to be implemented as
a user-level task (basically, a task-server that 'owns' the tasks it
creates and than will provide for notifications upon tasks deaths
to registered clients).

Once we've sorted out those things, changes to the Hurd codebase will
be needed (but only then). Those changes would be mostly cosmetic in
nature, (calling vk_*() functions instead of mach_*()), as well as
using a hopefully portable IDL compilers for normal IPC.

The issue of Pthreads vs. Cthreads will then also have to be dealt with.
I expect that future versions of L4 will provide enough native threads
so that a 1:1 pthreads library can be used rather directly. Sure, things
like signal handling in glibc will have to be coordinated with this L4-
pthreads environment, but we're not yet ready for this.

BTW, the L4 people are currently in the process of specifying a new
API revision of L4 (Version 4) which will also provide a standardized
set of C-Bindings and other improvements.

l4-hurd is very far from dead :-)

> Ondrej



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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]