Re: Mach emulation

[Farid Hajji]

> 1. You make a "libmom" that is minimal and resembles L4. The Hurd
>    servers have to do the work to map Hurd features on to L4 features. 
> 2. You make a libmom that has an API close to features needed by the
>    Hurd, and does the work to map Hurd features onto L4.
As you pointed out, we're facing an important design decision here:
Should we implement/emulate the features that the current implementation
of the Hurd relies upon in libmom, or should we rethink/redesign the
Hurd so that it uses less powerful abstractions than those provided by
mach?

If we want to achieve early results, Okuji's l4-mach + libmachemu seems
the best way to go and I'd support this approach. If we want to obtain
speed, it seems necessary to reevaluate the requirements that the Hurd
poses to an underlying ukernel/libmom (and IMO to the C library was well,
but you're free to disagree here).

> However, (2) is a much better design because it allows you to
> implement libmom efficiently on micro kernels that are not similar to
> L4. And as I said before, (1) seems pointless to, it provides no real
> advantage over using L4 directly. I can't stop you from doing it, of
> course, but I believe it will be a waste of hacking time.
I didn't made up my mind yet and I really appreciate your comments.
There's no point in starting an implementation that is doomed to
fail due to poor design.

For the time being, I'd suggest to try l4-mach + libmachemu, because
that would save us from heavily modifying the Hurd's sources. Even
mach_*() syscalls and -types could be provided by libmachemu now.
However, I'd reluctantly modify the Hurd sources now to use a "fat"
libmom, which would just be a substitute for Mach abstractions in
the first place. If we stick to the current Hurd implementation (and
I guess that we'll have to), we could as well emulate Mach directly
rather than hiding it in libmom.

> That's impossible if the libmom calls used by the Hurd basically are
> L4 calls. Consider port rights (or whatever port-right-like
> abstraction that is the Right Thing for the Hurd). With a libmom like
> (2), they could be mapped directly onto Mach. With a libmom like (1),
> you end up using only the subset of Mach calls that resembles L4
> (because that's what is available through the libmom API), and
> *emulating* port rights the same way it is done on top of L4. That
> will be much much slower.
This is one of the basic problems we're facing here. Port-rights are
obviously needed by the current Hurd implementation and they should
obviously be implemented in some way. They _could_ of course be added
to libmom and used throughout the Hurd. libmom-mach would map them
directly to mach port rights, libmom-l4 would use a capabilities-server
or another (distributed) approach to implement them. So far, using libmom
for this seems reasonable, as it shields port-rights abstractions from
every Hurd server and glibc.

OTOH, there are reasons that would speak against adding port-rights
to libmom, some of them obvious, some of them more subtle. port-rights
are used in the Hurd because they are trusted entities and because they
are implicitely passed by mach in ipc calls. For this reason, they
are quickly generated, transferred and (implicitely) checked. If we
keep using port-rights extensively like this, we'll have to provide
a substitute to them that would IMO not be so fast than what Mach
provides natively. The net result could as well be slower than with
mach, because we're assuming that a powerful abstraction would be
efficiently implemented in every libmom-{*} version.

Now imagine that we designed a "fat" libmom with port-rights and that
we then recognize that libmom-l4 can't even deliver mach speed because
of the port-rights overhead that is used everywhere. What then? We
would be forced to think about _different_ authentication mechanisms
and rewrite everthing again from scratch. If OTOH the port-rights
were implemented separately from libmom, their implementation could
be changed independently from libmom and their _use_ in the Hurd servers
would become more apparent.

Of course, we can't guess without testing if libmom-with-port-rights-l4
would be slower than libmom-with-port-rights-mach, so I may be wrong.
I just want to keep our options open, just in case this happens.

-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.