Re: Mach emulation

[Niels Möller]

Gernot Heiser <address@hidden> writes:

> If all you want is hurd running on L4, fine. (But why?)

(There might be some reasons for this; the primary one seems to be
that nobody likes hacking on GNU-mach)

> If what you want is hurd to be _fast_, then its a recipe for disaster.
> 
> Mach sux because it's too big. Any attempt to emulate Mach on top of
> L4 will be just as bad. And migrating drivers out to userland won't
> help.

The problem is that some of the things provided by Mach are needed by
the Hurd, and thus have to be supported in one way or the other. We
may be able to get away from queueing messages in the kernel, but I
think getting away from everything that resembles ports and port
rights would break the Hurd: they're used for just those things that
make the Hurd interesting.

> If this is to make sense, hurd needs to be retargeted directly to L4,
> not some encapsulation of L4. Essentially, hurd will have to be
> directed towards L4 abstractions, rather then Mach abstractions.

One approach that might make sense would be to build a port
abstraction similar to Mach's on top of L4 (but possibly with only
syncronous messages) to get the Hurd servers running. Next, one could
try to optimize the Hurd ipc protocols and make them more L4 friendly,
where needed. For instance, the pager-related ipc:s. With L4 beneath,
we should get a lot more freedom to optimize than with Mach.

> If this project is getting serious I might be able to get one or two
> of my students to help...

One project (which might be useful for any real os built on top of l4,
not just Hurd) is a POSIX thread library that multiplexes user threads
on L4 kernel threads. I'm sure there are others.

/Niels