[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why GNU Mach is so different?

From: Farid Hajji
Subject: Re: Why GNU Mach is so different?
Date: Sun, 30 Dec 2001 16:09:57 +0100 (CET)

> Now, I am reading (and studing) all docs that I could find about CMU 
> Mach UX e US, OSF e Utah Mach . I read old massages from lists too and I 
> strange that many important stuffs in research and others implementation 
> (like NORMA IPC, SMP, RT, ports...) are missing in the official 
> distibution (CVS). Why? Will be need to develop this stuffs again?
NORMA IPC Version 1 is currently only present in CMU Mach 3.0 and RTMach.
RTMach itself is availabe from NTT/Keio (please look at the-hurd-links.html
for the link) as a drop-in port for FreeBSD.

Support for NORMAv1 was dropped when the Open Group started to work
on NORMAv2. Unfortunately, they never publicly released that code,
so you'll have to study their whitepapers and try to reimplement
this yourself.

The question is rather if you should do so. I did quite a lot of
experiments with a cluster of Mach machines running NORMAv1 with
XMM; the reason being to continue the development on task migration
and load distribution started by Dejan Milojicic. This proved harder
that I expected in the first place and after discussing the issue
of (Mach-based) distributed memory management with people working
in the field; it became clear, that Mach sementics were _still_
too bloated to provide reliable TM+LD support.

This was also one of the main reasons for moving research towards
L4 and other lighter microkernels. Mach research seems to have
"stalled" in the last, say, 5 years, and we've learned quite a
lot from the Mach experiment. I wouldn't want to discourage you
from diving into Mach; its just that Mach is not at the "bleeding
edge" of research anymore (at least not mainstream).

> I want to work with distributed systems and clusters until the finish of 
> my course (college). I know that many work are being done with L4, but 
> in my understanding, when someone say that L4 is "working in process", I 
> see in Mach work done with many tests, researches and results waiting to 
> be improved and used.
I wouldn't buy the argument that Mach is finished wether L4 is WiP.
RTMach for example is still being actively developed and SMP support
is present and maintained in some (alas non-opensourced) Machs.

OTOH, L4 is stable enough to be used for real-world experiments:
Just look at the L4Linux emulation server, L4-Fiasco, L4Ka(Hazelnut),
L4/MIPS etc... kernels. They are all excellent and can be used
right now for experiments. The imminent release of the upcoming
new L4-API (Version 4) will also contribute to help boost L4-based
development further.

If you're really interested in clusters, distributed shared memory,
transparent cluster-wide IPC, task migration, load distribution,
crash resilience and recovery etc..., you may be much better served
by using L4 rather than Mach: IPC ist more reliable, since it's
not buffered by the kernel (think of crash-recovery of single
nodes w.r.t. checkpointing); NORMA-like semantics can be implemented
in user-land IPC servers, memory management was always (as in Mach)
the domain of user-land pagers, schedulers can also be user-land,...
More important though is the small amount of task/thread state that
needs to be transferred in the case of task migration. Without
ports redirection and all this having to be done in the kernel...

More on this, if you're interested.

> Others thoughts that I had, are about the Corba (I read something and 
> nothing more), modules for devices drives (like linux); those things are 
> better implemented on kernel or is possible on user space?
Regarding CORBA: The only part of it that we'll need in the Hurd
right now, is a good IDL stub generator that could replace MIG.
The path right now looks like we're needing to switch to flick
IDL compiler and change the *.defs with *.idl(s). Then, we could
use e.g. DICE or IDL4 to generate stubs for L4 instead of Mach.
Other CORBA stuff looks currently like unnecessary overhead to me.

The dream of uKernel developers is of course to move device
drivers outside the ukernel. The idea is to have user-land
device driver tasks that will serve interrupts etc... on
the one side and requests from an OS entity on the other side.

You _can_ write device drivers in userland, both for Mach and
for L4 (it's easier for L4). The point is not, that you can
do so, but if you could cannibalize e.g. the large Linux
driver codebase. One effort to do this was the OSKit which
you should really examine more closly. The OSKit is being
used both in the oskit-mach effort as well as in the L4
community. Another approach is (still-to-be-released) L4Env
environment, where it should be possible to drop the source
code of Linux drivers into a framework so that it integrates
in the L4 user-land tasks.

> I know that some ideas can be wrong... after some mounths trying 
> contribute to GNU/Hurd, I concluded that more study about OS is 
> necessary before I try something.... but I keep trying...

Happy hacking!

> valeu
> cavani


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]