Re: Would Hurd be able to become a distributed OS?
> I read Distributed operating systems
> Andrew S. Tanenbaum
> Prentice-Hall Internat. 1995
> ISBN 0-13-219908-4
>
> It has some chapters about Mach, comparing to Amoeba as Microkernel and
> and Chorus.
It is a nice introductory book I've read some years ago and the chapter
about Mach reflects what researchers were thinking on microkernels
in general at that time. The focus shifted somewhat to ukernels with
a slim interface, moving as much as possible into user-land.
The biggest problem with Mach w.r.t newer ukernels is that applications
running on top of it often require interaction with the kernel, resulting
in a lot of time-consuming context switches (app1 <-> mach <-> app2).
Due to the overhead of the async comm interface of Mach, each context
switch inevitably flushes the CPU cache almost completely, penalizing
the communicating apps even more. (The other problem being the size of
Mach, prohibiting simple porting to other architectures and using it
inside embedded systems).
To alleviated this problem, ukernels with a slim interface were designed
and some of them implemented. On of the hottest current ukernels is L4.
This ukernel is not only small (only approx 64k on x86 for the nucleus
including a kernel-debugger, 140k for the rmgr and 10k for the sigma0
pager), but also extremely fast when it comes to IPC costs as well as
thread-switching overhead. This is the main reason, why it is desirable
to move to L4 in the future.
> Mach is a big problem. Wouldn't be a way to slim Mach and move all the
> drivers to userland? Mach is naturally a big big microkernel due to its
> rich interface. Then integrating NORMA an alike could be easier as
> general maintenance and improvement would.
oskit-mach is a first shot at moving the linux device drivers outside
of the mach source tree. They are maintained by the Flux oskit group
and should be integrated in oskit-mach through oskit interfaces.
Yet, the drivers would still remain in kernel-land, and that is one
of the big problems with Mach.
One way to move the drivers into user-land is to have Mach notify a
"driver-server" each time an interrupt from a device occurs and have
that "driver-server" handle that interrupt like any other kind of
IPC message (that is: asynchronouusly). There are other issues related
with this like access to the i/o ports (on x86) or to the address
of memory-mapped devices. At least two problems occur here if you want
to reuse existing driver code:
1. Latency while handling incoming interrupts:
[ Some physical devices require immediate attention when they send
an interrupt (e.g. getting data from a latch register or something
similar). If the interrupt is trapped by mach, then redirected as
a message to an ipc port of some device driver server which should
then wait being scheduled etc..., a lot of time would pass before
the interrupt is handled. ]
2. Existing code often assume that it has supervisor-rights on the
machine (like calling e.g. CLI/STI or performing protected
instructions or assuming that it is running in an implicit
thread-safe environment). I wouldn't bet that all current linux
drivers can be used without change here, though I may be dead wrong.
BTW, L4 does not provide in-kernel device drivers like Mach. Here, you
must write the drivers in user-land from the very beginning. The interrupts
are being delivered by L4 to a user-written server that waits on incoming
IPC messages like any other L4 client program. From the viewpoint of the
"driver-server", the messages seem to come from a phantom thread...
Implementing distributed features a la NORMA in L4 would be IMO easier
than in Mach, mainly because you'll have to do it in user-land from
the very beginning. If a reimplementation of NORMA-like interfaces in
L4 is the solution to the performance and other problems of distributed
systems must still be examined.
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: