Re: GNU Mach on L4

[Farid Hajji]

> GNU Mach have i386-specific parts.  Why not replacing i386-specific with L4
> specific and thus make a new architecture for GNU Mach.  Then the real
> microkernel will be L4, and all other tasks will see GNU Mach (and L4 if
> they want to).  This is the cheapest porting of Hurd on L4 (development
> time, debugging, maintainance).  After that we can play L4 and GNU Mach
> simultaneously and gradually move to pure L4.
Wow, a hybrid Mach/L4 is an interesting idea! I'll have to look more closely
at Mach's sources first, before giving a qualified statement about practi-
bility.

Currently, the consensus was that we need to implement Mach's API, at least
as used by the Hurd, on top of L4 with the help of a Mach emulation task
that will (mainly) hold port rights and provide for asynchroneous
notifications. This Mach task (machemu) would be comparable in spirit to
the Lites server that contains most of the 4.4 BSD-Lite kernel. However,
it is believed that machemu would be much easier to implement than Lites,
because Mach itself is much lighter than a BSD-Kernel (less to implement
and easier/cleaner interfaces).

If we could find a way to integrate most of Mach's (machine idenpendent)
code into machemu, and provide a libmachemu library that would link
L4 apps against machemu (just like the Lites emulator library links
against (calls) the Lites server), then we could provide a Mach API to
native L4 tasks and this would be the first step towards porting the
Hurd to L4.

The idea to link L4 with the current Mach sources, could well lead to
this kind of (hybrid) machemu we're looking for.

> Yes, it will be slow:)
The machemu-approach would be slow too. L4's main advantage is that
it tries to minimize the number of cache flushes by using extremly
lightweight thread/task switching and IPC mechanisms. Everyting
Mach-like would give up this advantage. Frankly, I assume that as
long as we stick to Mach-like semantics (especially asynch
notifications/messages), the performance penalty would be so high
that moving away from Mach would not be profitable in the long run.

It may be (IMHO) better, to optimize Mach's IPC mechanisms, even if this
means dropping asynchroneoucy. I'm not actively researching on L4 vs.
Mach performance comparisons, so I can't provide you with papers for
or against this approach. It's just an unqualified wild guess here.

<personal note>
Personally, I'm involved with Mach (and recently with L4 too), because
I'm interested in building clusters of loosely-coupled workstations that
provide for dynamic task migration and load distribution in an appliation
transparent way (ideally robust against DoS attacks). Mach was a good
choice to start with, because of NORMA/IPC and XMM/External Pagers
(unfortunately not present in gnumach/Utah Mach4) and building on top
of Dr. Dejan Milojicic's work on task migration (which he dropped later
because of inherent limitations of Mach). L4 was nice and sweet, and
provided a practical framework to start SMP-work on top of it.
</personal note>

Do you have more concrete plans or ideas 'bout this hybrid Mach/L4 thingy?
I'd love to hear more about it; as it looks very promising new idea.

Regards,

-Farid.

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