Re: Mach emulation

[Farid Hajji]

> > The libmom we're thinking about right now should provide a minimal
> > set of kernel abstractions. I already had in mind to keep libmom
> > as close to L4 as possible, without loosing the potential for
> > portability to other systems/[u]kernels. L4 seems already minimal
> > enough and the biggest part of libmom[-l4] should reflect the L4 ABI
> > as closely as possible (BTW, no clans involved here!).
> 
> 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. Just
think of the misc. formats of descriptors and changing interface of
the syscalls themselves on 32 bit and 64 bit cpus. Then think about
not-yet implemented/specified/standardized versions of L4 for
multiprocessors...

Since we'll be using L4 nearly everywhere in the Hurd (IPC, memory,
drivers, ...), we'll get as dependant on L4 as with the current mach
implementation. Let's at least use generic libmom that hides the L4-API(s).
This libmom (or most parts of it) could well be simple macros/typedefs
w.r.t. L4-API, resulting in no performance-loss at all, while retaining
the possibility to flesh out libmom-{non-l4-api} for yet another porting.

> For a "libmom" to be useful, its API should be closer to the services
> that Hurd servers and programs *need*, and the implementation of
> libmom should be free to do things differently depending on the
> underlying kernel used.
Yes and not. Indeed, libmom should be able to implement its functions/
abstractions differently in libmom-l4, libmom-mach, libmom-{guestos}, ...
while providing a unified set of services to the libmom-retargeted Hurd.
This is what I'm trying to propagate here.

Concerning the services that the Hurd _needs_, we should be more careful.
Of course, we could follow Okuji's idea and provide nearly everything
what Mach provides and what the Hurd in its current implementation needs
(l4-mach and emulation library), but this will mostly reintroduce
Mach's overhead to the new libmom.  So we must cut the current requirements
of the Hurd by redesigning it from scratch (IMHO).

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

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.

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