Slashdot Mirror
Could Linux Become A Microkernel?
Kris Warkentin writes: "This question is not entirely intended to start a debate about the pros and cons of microkernels vs. monolithic ones. What I would really like to know, however, is how _feasible_ it would be to convert the Linux kernel to a microkernel. I was looking at how the QNX kernel offers only core services like threading, IPC, process creation, memory management, initial interrupt handling, etc. Everything else functions as a process within its own memory space. Linux can be configured so that it is much like this with other things (filesystems, etc.) compiled as modules. The key difference is that all the modules are operating in kernel space. So, the question is, how difficult do you think it would be to devise a communication protocol to let modules function outside of kernel space and merely talk to the kernel? What would be the cost and benefits? Would it be possible to have both types in the same source tree? (say, as a compile option)"
Not in the sense of (from the original article)
it's not - in NT, file systems, drivers for devices such as disk and network controllers, and network protocol implementations run in kernel mode in a fashion similar to the way they function in various UNIX systems.
Some of the Win32 semantics are implemented in the user-mode Win32 subsystem process, but some Win32 calls just get mapped into native NT system calls by the Win32 library.
I'm interested in microkernels for high reliability systems. One of the problems with most operating systems is that a device driver or major subsystem, such as networking or graphics, can crash the kernel. What if each device driver and major subsystem ran in its own address space? The address space would be restricted to the module's code, data and the address space associated with the I/O device. If the module crashed, the microkernel could recover by reloading and restarting the module.
Mea navis aericumbens anguillis abundat
First off, let's face it guys:
This is where RT/Linux, and other Linux pre-emptive microkernels come in. Advantages:
You get the best of both worlds. Minimal redesign, maximum reuse. The whole microkernel argument is old, very old. Linus has gotten Linux to the best it can be as far as soft real-time can be in 2.4. RT/Linux is the microkernel that addresses hard real-time and other size and response time issues. And it is a microkernel, running the main Linux kernel as a regular process. A perfect solution.
In a nutshell, it's impossible to get Linux to do everything without major modifications. There will have to be non-direct kernel implementations to do those unique applications. I really don't see any other way to do it. And besides, I don't see QNX, VxWorks, nor any other RTOS being as flexible as Linux is at doing many other things.
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
The opensource L4 is called fiasco. I don't have the link handy but you can find it on google and I think it's on freshmeat too.
This is my signature. There are many signatures like it but this one is mine..
I'm not sure if both are still worked on. MkLinux was only ever supported under Mac but supposedly you could compile it and run it on x86. I've never done it though.
Taking MkLinux and putting GnuMach under it (I have no idea how involved it is, probably very.) seems like it could be a quick way to get a hurd lite or something similar running. It might be an interesting experiment.
This is my signature. There are many signatures like it but this one is mine..
...as is BeOS, and as should every desktop and server operating system, but that's another rant...
But that's the point! You don't need all that bloat in the kernel. You might argue that unlike some OSes we won't mention, you don't need your GUI in the kernel, and I'd say you were right. But you don't need USB support, file system drivers, device drivers, networking or swapping in there either. That 80% (in the case of QNX it's probably more like 95%) can be implemented in user land.
Or, to turn the argument around: Do you really want to have to reboot to install a new networking protocol? Is it any different from having to reboot to install an application?
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
there is a version of linux running on a microkennel, but it is for the apple.
mklinux
Linux really should become a microkernel, since
it actually easily is outperformed in SMP systems.
In linux, at the time and hopefully forever, just
one CPU can be in the (micro-)kernel at one time.
And the kernel handles, beneath Interrupts, also
the other, un-important, stuff (sorry for my bad
English) like networking, fs etc. which all could
be done by user-space stuff. For example even net
and I/O could easily be done fully by ring-3 stuff
via the IOPL that now per default allows, and not
disallows any more, all currently unused I/O ports
for access by this task. Then the CPU which actually
serves the task does the I/O, and that's why the CPU0
which handles the IRQs branches to the other CPU
serving the I/O task, lets say IDE-PIO, if an IRQ
occured which has to be handled by it.
Microkernel hin und her, but the current kernel image
should get through since I _hate_ those large directories
containing "device drivers" (which for linux really spoken
don't exist) but _do like_ the way where one can choose to
build it into the kernel image or as module. I SAY that
"build into the bzImage" does NOT automatically mean
"included in the (micro-)kernel" !!!
Tnx, Greetings
Mirabilos(TM) openprojects:#icewm
My Karma isn't excellent, damn it! (And
No. In NT 3.5.x, just as in 4.0 and, as far as I know, 5.0^H^H^HW2K, drivers for devices such as disk and network controllers, and network protocol implementations run in kernel mode in a fashion similar to the way they function in various UNIX systems.
Yes, rendering was done in 3.x by sending messages to the Win32 subsystem process...
...but if that's sufficient to make NT a microkernel, then, well, err, umm, Linux - or {Free,Net,Open}BSD, or Solaris, or HP-UX, or AIX, or Digital UNIX, or... - are also microkernels if they're running X; in systems running X, the rendering code runs in "a process within its own memory space", i.e. the X server, in user mode.
BTW, "the GUI" runs, in part, in user mode even on NT 4 - the low-level rendering is done in kernel drivers, but the toolkit - the equivalent of Motif or GTK+ or Qt or... - lives, as far as I know, in user32.dll, which is a library that calls routines in gdi32.dll to get stuff rendered.
user32.dll is, as far as I know, just user-mode library code, as is gdi32.dll; on 3.x, gdi32.dll sent messages to the Win32 subsystem process, and, in 4.x and later, it goes through the kernel driver in at least some cases. (The fact that it's a shared library means that binaries built for 3.x should just continue to work - the ABI for drawing stuff on the screen is, in effect, a bunch of "call routine XXX in this library, with these arguments" items, and the way routine XXX accomplishes that can change from release to release without affecting programs that don't go around the back of the library.)
(user32.dll probably roughly corresponds to your toolkit library or libraries in X, and gdi32.dll probably rougly corresponds to Xlib, although there may be differences.)
Others have mentioned MkLinux, which is a version of Linux which runs on top of the Mach microkernel. By modern standards, Mach isn't so "micro". On my Hurd partition, the gnumach executable weighs in at 726kb compressed, and about 1.6Mb uncompressed. Compare with ntoskrnl.exe, which is 907kb on NT 4.0 enterprise server. Both of these are comparable with the size of an average linux or BSD monolithic kernel, which sit around the megabyte mark uncompressed.
The QNX kernel, on the other hand, is something like 8kb in size, which fits in the cache of a 486. Even the BeOS kernel is only something like 78kb compressed. Not that size is the only concern (so my wife keeps telling me), but in general, the less code that runs in the kernel, the easier it is to say something about how secure it is. Also the easier it is to change things while the system is running.
I hate to sound like Andrew Tanenbaum, but MkLinux and the Hurd are now obsolete too. Mach belongs to the old school of microkernels which were popular 10-15 years ago, but with the benefit of hindsight, we know better. Nowadays, for example, we know that you don't even need to do VM swapping inside the kernel.
There are some projects of note which may result in a product which is cleaner and better designed than Linux. Here are some suggestions:
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});