Re: Mach on L4

[Farid Hajji]

> > 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.
That's a good idea and it has the big advantage, that we could start
right now rewriting individual Hurd components on top of, say POSIX.
As a *BSD-guy, I'm not very familiar with Linux internals, so I'll
have to figure out what you mean with "architecture-dependent part"
by diving in Linux's sources ;-). I'm acquainted to FreeBSD und NetBSD
internals though, so I can roughly imagine what you mean here.

> 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.
Yes, I've got the idea.

> Some ad-hoc rules for your portability layer:
> 
> - Use synchronous RPC and an IDL.  Don't use message passing directly.
OK.

> - Don't assume your basic RPC mechanism can transfer system-object handles 
>   (handles for threads, address spaces, etc.).
I understand the rationale behind this. It seems like this will be quite
hard to enforce though. Okay, I'll try to come up with a basic model.
I'd need help here though (suggestions, ideas, 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.
That's sensible. Most kernels and ukernels I know share quite a big
amount of such abstractions. That would be probably easy to abstract.

> - 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.
AFAIK, the Hurd's ABI is identical to glibc's ABI, as far as normal
tasks/"processes" are concerned. Some of glibc's POSIX emulation
(the <glibc>/sysdeps/*) is implemented by RPC-ing Hurd servers,
mostly indirectly by calling Hurd support libraries. This is right
now transparent to applications (we don't support Linux binary compat.
yet in the Hurd). => The Hurd ABI is not an issue here.

Of course, glibc's Hurd sysdeps would have to be touched in some way.
I'm not yet sure how, but as you seem to infer, that would soon become
apparent while refactoring the first Hurd key components.

> 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. ;-)
Agreed. That's a very good idea.

> > 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.
Great, I'm patiently waiting... ;-).

Thanks for your help,

-Farid.

~/.plan: pondering about the first practical steps of Hurd refactoring,
then getting back to l4-hurd with a proposal-draft.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.