Re: Mach, a but choise ?
> First of all, thank you for helping this newbie, your explanation have been
> very clear to me, there are still two questions I would like to ask about
> what you say of Mach offering more services than The Hurd really needs.
>
There are many Mach versions available out there, gnumach being just one
of them. I don't know of any Mach standard that all Mach implementations
are required to implement. It _seems_ that the most "canonical" recent
Mach is osfmk (see: http://www.mklinux.org/). There are variants of Mach
that do real-time (like rtmach from keio/rtt) and yet other Mach variants
provide NORMA-2 (unfortunately not released to the public by the OSF).
What kind of features are missing (or not working) from Gnumach?
- norma/xmm
- support for multiprocessors (rudimentary present, but not working (?))
- real-time extensions
- ledgers
> first: is all this extra-functionality still present in the GNU version of
> Mach the Hurd currently uses or has it been removed for the sake of resource
> consumption ?
AFAIK, the Hurd uses/requires quite a lot of Mach semantics/functionality.
Fortunately, the Hurd doesn't rely on _specific_ features of gnumach, that
are not available elsewhere. I suspect that the Hurd could run on top
of other Mach(s) as well [say: on a NeXT workstion and other Mach platforms].
Mach-functionality that is not needed by the Hurd is so small, that it
wouldn't make sense to be removed from gnumach. There is not much to
win to do so: The memory footprint won't be reduced enough like what is
done in L4 and the system won't be faster either.
> second: if it hasn't been removed, is it just because the complexity of the
> whole microkernel doesn't allow it without compromising cleanliness or
> stability?
Well, it would be always possible to remove some features from gnumach,
if someone had enough expertise, time and patience to do it. But I would
strongly advocate against it: There are other systems (OS-Servers) that
run on top of one version or more versions of Mach. Removing core
functionality from gnumach would prevent those OS-Servers forever from
running in gnumach (say: you couldn't run them inside the Hurd!).
Consider one example: The Lites OS-Server is able to execute FreeBSD
binaries that don't need to be recompiled. Lites runs on top of Utah's
Mach4 (therefore most probably also on top of gnumach), rtmach and
other Mach's. Now imagine that you're running the Hurd on gnumach,
settrans FreeBSD partitions (with /hurd/ufs) somewhere and boot Lites
by running a simple task. Now you could use the FreeBSD system directly
inside of the Hurd without need for recompiling. You could even run
the Hurd _and_ FreeBSD/Lites at the same time (using different VCs)...
Lites is not the only possible OS-server that could run on top of
Mach/gnumach. Other OS-server are possible too, and they would probably
use some kind of Mach system that strongly resembles gnumach.
You know that Roland McGrath started the oskit-mach in an attempt to
get a cleaner Mach kernel for the Hurd. oskit-mach is basically gnumach
without linux-2.0 drivers, linking against OSKit (with the linux-2.2
drivers). I think that oskit-mach will continue to provide the original
gnumach external behaviour (at least as far as Mach is concerned).
> > One good example of such a lean ukernel is L4 and some people on l4-hurd
> > are trying to figure out how to port the Hurd to it. The main philosophy
> > of L4 is to provide only an absolute minimal set of services (as opposed
> > to Mach). In doing so, the memory footprint of L4 is _much_ slower than
> > that of Mach. The main advantage of this is that a context switch in L4
> > doesn't flush the processor cache, therefore providing for very fast IPC.
>
> One more thing, if it's not to much to ask, do you know a place where I
> could find more information on the L4 microkenel alternative ?
As far as the Hurd is concerned, L4 is not yet an alternative,
but how about helping?
http://mail.gnu.org/mailman/listinfo/l4-hurd
http://mail.gnu.org/pipermail/l4-hurd/
http://www.l4ka.org/
http://www.l4ka.org/docs/
http://www.l4ka.org/docs/l4-86-x0.ps
http://www.l4ka.org/faq
http://www.l4ka.org/projects/chacmos/
http://www.cse.unsw.edu.au/~disy/L4/MIPS/l4uman.ps.gz
http://os.inf.tu-dresden.de/L4/
http://os.inf.tu-dresden.de/L4/l4faq.html
http://os.inf.tu-dresden.de/L4/LinuxOnL4/
http://os.inf.tu-dresden.de/drops/
http://os.inf.tu-dresden.de/fiasco/
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/
Regards,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
Reply to: