Re: Mach on L4

[Farid Hajji]

> > The Mach/L4 with associated Mach emulation library Okuji and I were
> > thinking about are closely modelled after Lites and its emulation
> > code. 
> 
> I don't understand that remark.  Can you go into a bit of more detail?
> What is Lites' emulation code like?
I simply meant that Mach/L4 would consist of an L4 task running a Mach
server and an emulation library mapped into the address space of every
"mach task" that would translate mach syscalls to RPCs into the Mach
server. This would be exactly the architecture of Lites/Mach:
  Mach server         <-> Lites server
  transparent Library <-> Emulation library

> > Porting Mach to L4 is certainly no easy task (no pun intended). Just
> > as you described, some issues like e.g. VM and Tasks/Threads could be
> > in theory possible; [...]
> 
> Please note that L4's virtual-memory--management interface is very
> different from L3's (much more low-level).  We do have a library that
> implements L3's data space concept on top of L4, though, and that
> might be used to implement Mach's memory management.
Yes, that's true.

> > Porting MIG or writing a new stub generator looks more intimidating
> > though but the L4Ka people are currently experimenting with an IDL4
> > compiler if I got that right.
> 
> For our Mach-IPC-on-L3 project, we just the unmodified MIG and
> emulated everything MIG-generated stubs need.
> 
> Yes, using a different IDL compiler with a MIG frontend is an option,
> but I guess that the Hurd uses many Mach-isms such as sending port
> rights for various Mach-kernel resources that one would end up
> emulating anyway.
Unfortunately, you're absolutely right here. We need quite a big
subset of MIG, and vm_map() etc... are needed too. Hmmm... oh well.

> BTW, we at TU Dresden also have an IDL-compiler project -- DICE --,
> and I think right now it is more advanced than Karlsruhe's IDL4.  Have
> a look at <URL:http://os.inf.tu-dresden.de/~ra3/DICE/>.
Thanks for the hint. I'll have a look at DICE asap.

> > What makes this project difficult is the lack of experienced hackers
> > right now: Some people are somewhat acquainted to Mach and others
> > may have enough L4 knowledge, but finding people with expertise in
> > both areas is quite difficult.
> 
> This might be an argument in favor of getting rid of all Mach
> dependencies quickly, without going through Mach emulation first.
> 
> 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. The
more I think about it, the more sense it makes. You're the first
one to suggest exactly this approach independently. That's quite
an incentive to have a second try at it.

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

Do you have a list of already published virtual uKernel definitions
that we could base libvk-definitions on? Of course, this is a moving
target, but I'd prefer to rely on experienced uK researchers here ;)

> > That would be great! The more example code we can study, the better.
> > If you could make your work available, this would help us tremendously.
> 
> OK, I made it available at
> <URL:ftp://ftp.inf.tu-dresden.de/pub/os/L3/devel/l3-mach_emul.tar.gz>.
> 
> This code makes use of some L3 libraries.  This shouldn't be a problem
> for you (you don't want to *run* this code, do you?), but you can
> still find the libraries in
> <URL:ftp://ftp.inf.tu-dresden.de/pub/os/L3/devel/libl3-980130.tar.gz>.
Great, thank you very much! That's really interesting code.

> If I find some time, I will add a collection of introductory
> documentation to the generic L4 webpages at
> <URL:http://os.inf.tu-dresden.de/L4/>.
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.

Thanks for your help!

-Farid (currently diving in L4 internals and playing with misc.
L4-thread manipulations...)

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