Re: Mach on L4

[Michael Hohmuth]

Farid Hajji <address@hidden> writes:

> > Just a thought: How about introducing a kernel-abstraction layer to
> > the Hurd first?  As a tactical goal, port the Hurd to Unix as its
> > underlying ``microkernel'' while keeping it working on Mach.  This
> > refactoring should yield a Hurd that can easily be ported to other
> > kernels such as L4, and you don't need people acquainted with both
> > Mach and L4.

> I suggested exactly this approach in point 1. of:
>   http://mail.gnu.org/pipermail/bug-hurd/2000-October/003602.html
> The Hurd/Unix approach would be the libvk-{guest-os} variant. 

[ for the lurker: VK = ``virtual kernel'' ]

> [...]
> So how would a virtual uKernel interface look like, that is general
> enough to encompass L4 (various APIs), Mach and that can be simulated
> on top of some (say Unix-like Guest-OS)? For such a VK to make sense,
> it should probably be as minimalistic as possible (really? Hmmm...).
> I'd prefer not to be L4-biased when defining libvk, but the L4-provided
> abstraction seems very near to the ideal of a VK (the only exception
> would be that we need some vm_*() primitives that would be global
> just like Mach's and unlike L4's).

The kernel-abstraction layer resulting from a the kind of refactoring
I proposed does not have to look like a minimal (virtual) kernel
interface.  I envision more of a portability layer with an interface
similar to that of the Linux kernel's architecture-dependent part
(although hopefully a bit cleaner).  Let's call this KAL
(``kernel-abstraction layer'') for a moment.

Don't try to define KAL's interface at the outset of your project.
Let it grow, refactor regularly.  Just ensure that you use in KAL's
interface only well-understood abstractions and mechanisms that can be
implemented without fuss on all target kernels.

Some ad-hoc rules for your portability layer:

- Use synchronous RPC and an IDL.  Don't use message passing directly.

- Don't assume your basic RPC mechanism can transfer system-object handles 
  (handles for threads, address spaces, etc.).

- Other system-specific abstractions: threads, address spaces, data
  spaces, semaphores.  Either assume a (subset of a) standard
  ubiquitous interface (pthreads) or define your own one.

- Other system-specific mechanisms: atomic memory modification, paging

- If the Hurd has an ABI (as opposed to an IDL-specified interface),
  the portability layer needs a way to specify the ABI.

Don't use any kernel interface such as L4's directly.  Think of L4 as
the ideal low-level mechanism to implement all these abstractions. ;-)

> Quite instructive would be a collection of small root tasks that
> exercise the L4-API in some way. One good example was Karlsruhe's
> ChacmOS but simpler examples would be (even more) useful too.

I think our low-level libraries (for threads, semaphores, and the
likes) will be quite interesting for you, once they have been
released.

Michael
-- 
address@hidden, address@hidden
http://home.pages.de/~hohmuth/