Re: L4Mach or Refactor Hurd Servers?

[Farid Hajji]

> I'm trying to decide between implementing something like L4Mach or
> reimplementing the Hurd servers to use L4 tasks directly, complete ripping out
> the notions of Mach.
You should read
  "Steps Towards Porting a Unix Single Server to the L3 Microkernel"
by Michael Hohmuth and Sven Rudolph, April 9, 1996 (!). I don't have
the URL handy; just look at the Dresden L4 site for the exact location.

Basically, it proved difficult to emulate the complete Mach API. If you
want to implement L4Mach, it will most likely provide just a subset of
Mach, so that we can get the Hurd up and running (in a first step).

The most difficult issue is IMO how you want to handle asynch. IPC,
especially the notifying mechanism. In the Hurd, you need at various
parts to detect/receive something called "dead port notification".
Emulating this on top of L4 (with or without the help of a L4Mach
server) may be difficult, but I'm not sure yet.

> The advantages of an L4Mach are that less of the Hurd code would have to 
> change.
> It seems from looking at things that the Hurd is very much aligned with Mach
> programming style. Notions of asynchronous IPC and ports and port rights are 
> in
> the Hurd. L4 doesn't have these things. From looking through the code, it 
> looks
> as if various parts of the Hurd use "mach.h" directly too, rather than having
> this stuff hidden within a library.
Hmmm... actually, the Hurd's sources look like they need mach.h a lot, but
this is not necessarily the truth. What the Hurd needs is quite a limited
subset of Mach primitives. Take VM as example: The vm_*() interface is
pretty much generic and could be implemented as an L4 pager. This includes
also things like page COW, remapping etc... There's nothing inherently
Mach here. Getting the device interface right (master_device_port_t,
open_device() etc...) can also be achieved through a device driver framework
of some kind. To put it shortly: There's no need to change the vm_*() and
device driver API in the Hurd. This can be taken care of outside of the
Hurd by what I used to informally call VK/L4.

The harder part of the port would be proper handling of the IPC stuff.
Frist of all, I'd strongly advocate that all IPC in the Hurd be routed
through MiG, avoiding any direct IPC call. After all, the biggest part
of the Hurd's IPC is RPC, and RPC-code should be dealt with by a proper
stub generator like MIG or Flick. If done correctly, it may be possible
to get portable IPC just by changing the stub generator's backend (say:
flick uses Mach-3 and L4 backends).

The real question is what kind of IPC semantics are required to be
implemented by the stub generator(s). It can be as simple as L4's,
or as complex as Mach. It may also lie somewhere in-between.

As already said: things like dead port notification and stuff that
depends upon asynch. IPC could turn out to be quite hard (and even
inefficient) to implement in an L4-based stub generator backend.
I don't know wether it will be so, but if it is, _then_ you should
take a closer look at those features, trying to replace them with
simpler semantics.

> As it stands, we will have to implement libports as an L4 task and will
> essentially be creating an L4Mach anyway.
As far as the port rights (a.k.a. capabilities) are concerned, yes.
We'll need a capabilities server task in the L4 port of the Hurd.

Concerning asynch ports, it _may_ be possible to store/buffer the
message contents in a messagebox-server, somewhat emulating what
Mach does internally. This may be necessary in a first step, _if_
we can't figure out a better way to implement some MIG features.
However, I doubt that this would be necessary. From a performance
point of view, a messagebox-server is an absolute no-no. You'll be
copying data much more often than absolutely needed and in terms
of context switches, it will certainly be _slower_ that Mach!

> Questions: Is it a good thing that the Hurd follows the Mach idea of ports for
> IPC so closely? Doesn't that limit it to certain types of microkernel? Is 
> there
> a more general notion of IPC that we could use that would allow more 
> flexibility
> in the choice of the underlying microkernel?
This is the most important question regarting the port. If the Hurd had
been designed with other microkernels in mind, it would have certainly
been more restrictive on its use of mach-specific IPC-ism. The "best"
design would have evolved around generic RPCs, as implemented by a
stub generator, restricting the use to simplest sychchroneous call/
responses. This would have been possible with MIG as well.

The reason why the Hurd's design looks so involved, lies in the way,
how Mach works. Under Mach, you must obtain and hand out port rights.
Because MIG failed to provide a completely transparent handling of this
mechanism, port-rights semantics leaked out of the generated stubs into
the Hurd codebase (mostly in libports, where they are kept in classes
and buckets).

> It seems to me that libports marries the Hurd to a Mach style microkernel.
Right.

> -- Ian

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.