Why a microkernel? (long)
Michel de Montpellier
I know very little about Mach and Hurd, but I would like to make some
comments. To be brief, I am not a computer scientist, just a Linux user,
and an electronic engineer (which has included installing minimum
Linux's on embedded systems based on i386 or ARM/XScale, or writing code
for our hardware to work on various operating systems).
I will not enter really in the debate: is a microkernel better than a
monolithic one, rather I will list what I would expect from a good OS:
- allow me to do what I want with the hardware (possibly after asking
the user for agreement)
- allow me to have very short interrupt and timer latencies (this can
many times remove the need for big memories in the devices). Of course,
not all drivers can have the maximum priority, but I would like to say
sometimes "now I am acquiring so this driver needs the full priority
even if it freezes the computer". Presently this can be done with hard
real-time extensions such as Linux-RTAI (free) or Windows+RTX
(expensive), but these are patches "outside the OS".
- have the device drivers to work without any change even after
upgrading the OS
- load or unload the drivers when desired
This made the old MS-DOS (with Turbo Pascal for example) a great OS for
the electronic engineers! However, too much limitated.
Windows is not too bad: drivers written for MS-DOS would work with
Win3.11, those for Win98 still work with WinXP. But the latency is often
a big problem, so many devices made for MS-DOS cannot work anymore. And
another huge problem is that you have to pay for the driver SDK for each
version.
Linux is good in that it is portable, and also configurable (there are
even versions with low latency, like Monta Vista). But the BIG problem
is that you have to rewrite the driver for almost each version of the
kernel, sometimes even for changes in the last digit of the version.
So why a microkernel? If this means that each part can be easily
modified, unloaded and reloaded, that's cool. But this can also be done
with run-time loadable modules like in Linux or Windows (except that in
Windows you often have to reboot the PC, I don't really understand why).
If this means all the drivers run in user mode (that is, without any
priviledge), I may not be so sure about it. If the driver for a USB
printer is in user mode, of course there is no problem. But many drivers
(network, hard disk,...) need to react quickly to interrupts, but
interrupts happen in kernel mode, and processors like i386 take a long
time to switch the context, so this would just not be very efficient:
safe, but unefficient. But true enough, many drivers can run in
user-mode, all they need is access to some I/O port or physical memory area.
I read that Hurd runs on top of Mach, and that Mach is a microkernel
based on Linux 2.0, and I am really afraid when I look at the list of
devices supported by Mach (see configuration flags:
http://www.gnu.org/software/hurd/gnumach-doc/mach_2.html#SEC9 ).
This was supposed to be a microkernel, why do you need a driver for a
parallel-cable Iomega ZIP drive? Why anyway do you need any hardware
driver, apart from configuring the CPU, the RAM, or the timer?
If a microkernel is to be used, I would expect that it does nothing more
than managing memory and processes. I would expect the boot loader to
take care of transfering the microkernel and a few programs from a hard
disk or netword address to somewhere in the memory. I would not even
expect the microkernel to know about hard disks: knowing how to redirect
interrupts quickly and to configure DMA controllers should be sufficient.
On the other hand, if the system is to be efficient, everything critical
task has to run in kernel-mode (ring 0 on i386), of course this is not
as safe in case there is a bug in the driver (but usually the driver
code in kernel-mode can be kept quite small), but this can work smoothly
if the kernel is able to load and unload modules, like Linux or Windows.
On Windows XP, if you write a driver, the user who loads it gets a
message explaining that he is about to include in the kernel something
not validated by Microsoft, but he can agree and proceed.
The problem with Linux is than for many reasons, it is almost always
impossible to reuse a pre-compiled module: some obscure function may
have changed its name or its list of parameters, not to say anything
about the various versions of the C compiler or the way the kernel can
reject a module compiled for another kernel without even trying to load
it, just after checking for the ID. This is really what makes Linux so
"monolithic": if I build a new PCI board, I can provide a driver for
Windows, but not for Linux except in source code, which means almost
nobody will be able to install it, and unless it is someday included in
the mainstream kernel this means nobody will use my PCI board with Linux.
However, this is not really a surprise: there is no documentation about
the Linux kernel, most programmers have to dig in the source code to
figure out how to do something, or to read Alessandro Rubini's books
(the closest thing to an official documentation, unfortunately the
kernel evolves without any care for the programmers who have based their
work on Rubini's books). So no wonder it is more difficult than for
Windows, where Microsoft tells you the list of functions that you may
use in a driver. Without a good documentation, Mach/Hurd will not do
anything better than Linux in this regard. This is even sure in case,
like Linux, someone decides someday to change the name of the function
for mapping physical memory areas, for example.
Michel de Montpellier (France)
Electronic engineer
(physicist in another life)
lap
> and that Mach is a microkernel
> based on Linux 2.0
Huh ?
I know little about Mach (yet), but this sounds strange to me.
LaP
Michel de Montpellier
http://www.gnu.org/software/hurd/gnumach.html :
GNU Mach is used as the default microkernel in the GNU/Hurd system. It
is compatible with other popular Mach distributions. The device drivers
for block devices and network cards are taken from Linux 2.0.x kernel
versions, and so a broad range of common hardware is supported.
However, the Linux device drivers have been improved greatly since the
2.0.x version, and a new version of GNU Mach based on the OSKit library
is being worked on, which uses newer drivers and in general has cleaner
machine specific support code.
Michel
Melinda Shore
Michel de Montpellier <mju...@camembertfree.fr> wrote:
>GNU Mach is used as the default microkernel in the GNU/Hurd system. It
>is compatible with other popular Mach distributions. The device drivers
>for block devices and network cards are taken from Linux 2.0.x kernel
>versions, and so a broad range of common hardware is supported.
I haven't followed what's been going on with Gnu and Mach,
but device drivers are generally considered to be outside
the core OS services and if that's the basis for saying that
Gnu Mach is "based" on Linux then the statement would not be
correct.
--
Melinda Shore - Software longa, hardware brevis - sh...@panix.com
Attacking Bushonomics is too easy, like shooting a lame duck
-- Sebastian Mallaby
Robert Kaiser
sh...@panix.com (Melinda Shore) writes:
> In article <43c8096b$0$18185$636a...@news.free.fr>,
> Michel de Montpellier <mju...@camembertfree.fr> wrote:
>>GNU Mach is used as the default microkernel in the GNU/Hurd system. It
>>is compatible with other popular Mach distributions. The device drivers
>>for block devices and network cards are taken from Linux 2.0.x kernel
>>versions, and so a broad range of common hardware is supported.
>
> I haven't followed what's been going on with Gnu and Mach,
> but device drivers are generally considered to be outside
> the core OS services and if that's the basis for saying that
> Gnu Mach is "based" on Linux then the statement would not be
> correct.
"Core OS services" is not necessarily identical with "kernel".
In a microkernel system, drivers are usually outside of the kernel
(the kernel being the part of the software that runs in privileged
mode). The core OS services would be the collection of services
that an application program needs. For any UNIX kind of API this would
probably include drivers for block and character devices, but there
is no need to run these drivers in privileged mode.
Rob
--
Robert Kaiser email: rkaiser AT sysgo DOT com
SYSGO AG http://www.elinos.com
Klein-Winternheim / Germany http://www.sysgo.com
Melinda Shore
Robert Kaiser <bitb...@invalid-domain-see-sig.nil306-1.cs.fh-wiesbaden.de> wrote:
>"Core OS services" is not necessarily identical with "kernel".
In a microkernel, it is. The point is, though, that having
adopted some Linux drivers for Gnu Mach doesn't mean that
it's now a Linux-based kernel. In fact, it would be
exceedingly unlikely for a Linux something to be called
Mach, at least by the people working on it. I just checked
the Gnu Hurd web page, which says:
It is compatible with other popular Mach distributions.
The device drivers for block devices and network cards
are taken from Linux 2.0.x kernel versions.
That seems pretty clear to me. It's not Linux and it's not
Linux-based.
--
Melinda Shore - Software longa, hardware brevis - sh...@panix.com
Prouder than ever to be a member of the reality-based community.
Robert Kaiser
sh...@panix.com (Melinda Shore) writes:
> In article <dqfnd3$a9a$2...@dagobert.sysgo.com>,
> Robert Kaiser <bitb...@invalid-domain-see-sig.nil306-1.cs.fh-wiesbaden.de> wrote:
>>"Core OS services" is not necessarily identical with "kernel".
>
> In a microkernel, it is.
Maybe we have different ideas about the meaning of "Core OS Services", then.
To my understanding, things like file systems, network/file/device
access are core OS services in the sense that every application program
expects these to be provided by the OS, but these services are not
(or should not be) part of any microkernel.
> The point is, though, that having
> adopted some Linux drivers for Gnu Mach doesn't mean that
> it's now a Linux-based kernel.
Of course! No argument about that.
lap
> is compatible with other popular Mach distributions. The device drivers
> for block devices and network cards are taken from Linux 2.0.x kernel
> versions, and so a broad range of common hardware is supported.
ok I didn't know that. But anyway, Gnu Mach is not the only
Mach running. There is, say, Apple Mach, which is the micro
kernel of their XNU Kernel, used in Mac OS X. Does it use
Linux code also ?
LaP