Re: Fw: Mach, a but choise ?
> I don't know if this is the right place to ask, but what better place than
> the one where the creators are, so I've been following the development of
> The Hurd for a while now, and read as much about the subject as I've been
> able to find on the Web. From what I 'd read so far I concluded that Mach
> was I wonderful idea to base an OS on, despite opinions (like Linus,s saying
> it was idealistic and very slow). The best article I 've read is Doctor
> Dobb's site insightful explanation of the system, ... just to know that RMS
> himself had admited basing Hurd on the Mach microkernel was a mistake. Did
> he mean, the mistake being the time they lost waiting for the release of
> Mach to free software or was he speaking about Mach being a "technical
> mistake" ?
Every microkernel-based OS faces the problem of communication costs between
tasks. If you move OS functionality outside the kernel, client A needs
to send a message to Server B and Server B often needs to answer back
with another message. Message passing is normally done through the
microkernel for security reasons. Now consider the number of context-
switches that are needed:
monolithic microkernel
client -> kernel client -> ukernel
kernel -> client ukernel -> server
[ server -> kernel?
kernel -> server? ]
server -> ukernel
ukernel -> client
=> 2 context switches => 4 [or 6] context switches
[ if server can't answer
directly ]
In any case, a monolithic system will be faster, especially if the
programs use many syscalls.
If you must choose between monolithic and mikrokernel approaches,
you generally not only consider speed (although that is important too),
but also flexibility. On a microkernel, you can run many OS personalities,
even at the same time. You can replace single components without having
to worry (much) about the stability of the whole system. You can even
distribute the whole system to a multicomputer (a 'collective')... There's
another side effect of this: Since more code is running in user-space,
the amount of trusted kernel-code is reduced, thus greatly reducing the
number of panic()s opportunities.
So microkernels _are_ a good way to provide for more flexible systems,
even if they often incur more overhead that monolithic kernels.
If you must choose between misc. microkernels, the perspective changes:
Mach is a ukernel with a rich set of semantics. Therefore it is bloated
and not so small than a ukernel should be. They are other microkernels
that are much smaller and that provide for faster context switches.
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.
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: