Re: Mach emulation

[Niels Möller]

Farid Hajji <address@hidden> writes:

> > To me, this seems quite useless. If the API of the library is very
> > close to L4's, I don't see any point in it. Why not use L4 directly,
> > if that is the level of abstraction that you want?
> We shouldn't use the L4 API directly for portability reasons. First of
> all, L4-API is still in flux and subject to change without notice. Second
> the API _is_ dependant on the target platform L4 is running on.

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.

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.

> Since we'll be using L4 nearly everywhere in the Hurd (IPC, memory,
> 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.

> What does the Hurd really needs from a libmom? I have not finished the
> specification of libmom yet, but to get just an idea:
> 
>   * abstractions: mom_task_t, mom_thread_t, mom_vm_*, ...
>   * ipc calls   : mom_ipc_send(), mom_ipc_receive(), 
>   * hardware    : mom_interrupt(), mom_...() // raw hardware

So far, that sounds about right to me.

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

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.

/Niels