Re: Mach emulation

[Farid Hajji]

> Some simple wrapper on top of L4 may be useful to help adapt to
> changes in L4, differences between L4-versions, etc. But it's a
> terrible way to get portability across microkernels; if you make a lot
> of L4-specific calls in random Hurd servers, it gets as tied to L4 as
> the current code is to Mach. Or even worse, as L4 is provides a
> lower-level of abstraction.
[please see below]

> For the libmom idea to make any sense to me, a minimal requirement is
> that it ought to be possible to implement it on top of *either* L4 and
> Mach, *without* having to write a L4 emulator on top of Mach or vice
> versa. Including L4-look-alike calls as essential parts in the libmom
> API blows that requirement into very small pieces... Perhaps we're
> talking about different things; the above is what "libmom" means to
> me, and I think that was also the intention with the previous attempt
> to do it. Perhaps the library you envision is more like a
> L4-on-top-of-anything? You're confusing me.
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...

We need to know what kind of services are required from a ukernel in a
very general manner. This set of services should go in libmom and can
then be used everywhere inside the Hurd.

What we're trying to do right now is to _identify_ the abstractions and
services that are provided by every ukernel, preferably natively. L4 is
one of such kernels that provides a (if not minimal, so at least) small
set of abstractions/services which could map 1:1 (mostly) to libmom and
making the implementation of libmom-l4 easy as well as efficient.

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. This isolation applies also to guest-os(es)
etc... My point is that a slim libmom with a minimal set of features
would be very efficient on L4, and still easy to port to Mach, guest-os(es)
and probably other ukernels, remaining very efficient there too.

Some abstractions and functions in certain ukernels are more powerful
than those in L4, so the question arises wether we loose efficiency
by building the Hurd on top of a simplistic libmom, rather than using
those powerful abstractions right away. This is up to a certain limit
certainly true, but not entierely.

Most ukernels I know (I'm not an expert here, so I can be dead wrong)
provide notions of tasks, threads, ipc, VM and hardward-access in a
rather basic way. Other more powerful features are probably often
implemented (or at least defined) in terms of the more primitive
abstractions. If you use the primitive functions directly, you're
more likely to get a fast response from the ukernel. The more powerful
functions would almost always require more CPU cycles to complete,
so they should be avoided, if their only use is to request a primitive
function. Sure, if the more complex operation is often required per
design, it should be used instead of the simple operation, because
that would involve less context switches. We've got a trade-off again.
This reminds one (in a very loose sense) of the RISC vs. CISC decision.
RISC systems are slower because most required Opcodes in a regular
program can be done in very few cycles. More complex operations are
then emulated (are slower) on RISC, but since they occur muss less
frequently, the overall performance is still better.

Then there is the question of portability. You don't need to be
concerned to port a libmom-based Hurd that uses a very small set
of primitive abstractions everywhere to a ukernel that provides
a set of abstractions of similar size. This would be just a matter
of reimplementing libmom (well, mostly). Porting to a more powerful
kernel like Mach would also not be a problem, because you can map
the primitive functions of libmom to some syscall or abstraction in
Mach almost 1:1. OTOH, porting the current Hurd that extensively
uses a "fat" Mach inteface is much more difficult, because we've
got a target system that is so much "weaker" w.r.t. abstractions.

I'm not an expert in ukernels, so I obviously can't foresee what each
ukernel provides or should provide and what ought to go into libmom.
That's why we're talking about this here.

> > Since we'll be using L4 nearly everywhere in the Hurd (IPC, memory,
                        ^^^^
Of course, I've meant libmom, not L4. But libmom-l4 should be able
to map the libmom-calls 1:1 (mostly) to L4 in order to be efficient.

> > drivers, ...),
> 
> I'm not sure that is a good idea. I'd prefer that L4 is used (directly
> or via some wrapper) by libmom and perhaps also by glibc. The rest of
> the Hurd should only use interfaces from libmom and glibc.
s. above.

> > For example, I'm not convinced that we really _need_ port rights or
> > kernel protected capabilities in a redesigned Hurd. Such capabilities
> > could as well be managed by a trusted user-level entity like the auth
> > server. Other abstractions that Mach provides and that are needed by
> > the current Hurd implementation are probably also not necessary in
> > libmom.
> My point is that those things are needed. It's not terribly important
> where they are implemented (on mach, a lot of it is in the kernel, on
> L4 it obviously have to be somewhere else). But it is an important
> feature, and because an efficient implementation of it has to depend
> on the microkernel used, it seems reasonable to make it part of
> libmom.
That's probably necessary up to this point. The problem I'm seeing
with adding port rights to libmom is that they are an "advanced"
feature that is not available on most ukernels and that should be
probably implemented in user-land anyway. But everything that
touches user-land is intimately tied to an OS personality in some
way, so we would be mixing libmom to this (mixing the Hurd "OSI"-Layers).

> Using the auth-server seems suboptimal, as that would probably make
> the authserver an ipc bottle neck. To me, it seems like a better
> approach to have a thread in each task to handle. But perhaps it's
> premature to discuss that.
No absolutely not. I didn't come up with an auth spec yet, because I'm
seeing the problem with the bottleneck too (and for other reasons
as well). I'll write more on this in a separate mail.

> /Niels

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