Re: Mach emulation

[Niels Möller]

Farid Hajji <address@hidden> writes:

> Sorry, I thought it was obvious. We've got a trade-off between efficiency
> and abstraction from kernel services here. This makes the design and
> specification of libmom so hard.
> 
> If you want the Hurd to be fast, you _need_ to reduce the code path between
> the Hurd and the ukernel to a minimum. But that means having to access the
> kernel right there where and when it is needed, and that is in the servers,
> clients, glibc...

I don't agree at all. The Hurd's and glibc's notion of most
abstractions are inherently "fatter" than those provided by L4. For
instance threads (Hurd uses cthreads or pthreads, which are more
powerful), ipc (hurd security is different from L4 security), I know
too little about the vm and task features but I suspect you have
differences there as well.

That means that there *has* to be some code somewhere that implements
the Hurd's notions of ipc, tasks, etc on top of the features provided
by the microkernel. No matter how you organize things, that work has
to be done somewhere and it won't magically be going away.

Now, there are two paths:

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.

>From a performance point of view, there's *no* difference (as long as
we're talking about having L4 beneath). The difference disappears at
link time! (Or more precicely, it disappears at link time for
functions doing real work, and at preprocessor time for "functions"
that can be implemented as macros expanding to L4 calls).

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.

> Most other kernels, like Mach, also provide similar abstractions _and_
> services, but are more than likely more "featureful" than L4. In this
> case, libmom-mach would implement the basic functions in a rather
> straightforward manner, just by using the more "powerful" syscalls
> (and abstractions?) of Mach.

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.

Or consider threads, and look at your "guest-os" idea. If the guest-os
provides real pthreads, and libmom just offers L4-like threads, you
will end up with using pthreads implemented on top of libmom's L4-like
threads, which in turn are implemented on top of the systems native
pthreads! Ok, now you'll say that you'll include pthreads in libmom,
at least conceptially, and that's great. I just want to argue that the
same applies to most or all L4 features, not just its threads.

/Niels