Re: Fluke

[Roland McGrath]

> Next week, I will be joining the L4 team at Karlsruhe for the summer.
> The plan is to try to port the Hurd to the L4 architecture.

That's fabulous!

> My initial impression is that this will mostly consist of finding the
> appropriate IPC primitives, i.e. layering a subset of the Mach IPC API
> onto L4.  

I wouldn't expect (or want) a subset of the Mach API literally speaking.
But yes, dealing with IPC issues is one of the biggest chunks of work and
one that is necessary for anything else to start working at all.

> I remember that you said that someone had started a port of the Hurd to
> the Fluke microkernel developed at Utah.  

I'm pretty sure I never said that.  That never happened, though I would
have liked to have done it.  One thing that I did work on at Utah was
layering on top of Fluke IPC a higher-level object/RPC interface with
semantics based on the Hurd's libports and the subset of Mach IPC semantics
that are essential to the Hurd design.  That is, the same kind of thing
with Fluke IPC that you need to do with L4 IPC.  Fluke is more similar to
L4 than to Mach in its handling of references, so the issues for
implementing timely object destruction (i.e. no-senders notification) are
probably similar.  Fluke is more like Mach than like L4 in how IPC
rendezvous works, though; so there are many issues with L4 that I did not
have with Fluke.

> Could you share some of those experiences with us and perhaps any code
> that is relevant and still lying around?

I could dig up the old code and documents from Utah, but I don't think it's
really useful.  The particular implementation tactics were specific to the
details of Fluke IPC.  Having thought about the issues a lot in general, I
can certainly contribute to figuring out how to attack the problems on L4.

I can get into more detail when I feel like typing more.