l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mach emulation


From: OKUJI Yoshinori
Subject: Re: Mach emulation
Date: Wed, 15 Nov 2000 08:48:36 +0900

From: Farid Hajji <address@hidden>
Subject: Re: Mach emulation
Date: Tue, 14 Nov 2000 23:28:40 +0100

> Why not use L4-API directly and forget about libmom? Well, first of
> all, a very important portion of the Hurd relies on IPC, tasks, memory
> regions and (unfortunately) kernel-protected capabilities. If we used
> L4-API directly, a port of the Hurd to another system or ukernel would
> be much harder than just provide another libmom-{other-kernel}. The cost
> would be > 0 in some cases, but in the L4 case, libmom may well map
> nearly 1:1 to the L4-API and nothing prevents us from implementing
> libmom calls as simple macros to L4 functions/abstractions.

  If you construct MOM interfaces this way, I won't call the library
libmom. The idea behind libmom is that it could make it possible to
optimize Hurd for different microkernels (hopefully as fast as
native implementations), while Hurd itself is independent of any
microkernel interface. That is, libmom *must* be as fast as the
current implementation even on Mach.

  If you write libmom just as a wrapper for L4 API, it wouldnt' be
fast on other microkernels but L4. Rather, what you aim at is a
library analogous with libmachuser in glibc.

> a long period of time. That's why I'm not opposed to l4-mach approach
> as an intermediary step. But even then, we must spend some time on
> serious thinking (and implementing) of a cleaner Hurd system.

  Definitely.

Okuji



reply via email to

[Prev in Thread] Current Thread [Next in Thread]