Slashdot Mirror
The Great Microkernel Debate Continues
ficken writes "The great conversation about micro vs. monolithic kernel is still alive and well. Andy Tanenbaum weighs in with another article about the virtues of microkernels. From the article: 'Over the years there have been endless postings on forums such as Slashdot about how microkernels are slow, how microkernels are hard to program, how they aren't in use commercially, and a lot of other nonsense. Virtually all of these postings have come from people who don't have a clue what a microkernel is or what one can do. I think it would raise the level of discussion if people making such postings would first try a microkernel-based operating system and then make postings like "I tried an OS based on a microkernel and I observed X, Y, and Z first hand." Has a lot more credibility.'"
And the date at the bottom of the article is "12 May 2006". The same article has been linked from slashdot before too. We really haven't argued about this for a while...
QNX. www.qnx.com. Best OS ever. Very long life support (qnx 4.x last patch was issued 17yrs after it was released). Now it is free for non-commercial use, with source.
You are partially correct. The mach kernel is one of the first implementations of microkernels. OS X is derived from this as well as the mklinux experiment of the late 90s. But just like the difference between CISC and RISC processors has been on a collision course, monolithic and microkernels have picked the best features of the other. OS X is based on the XNU kernel. A mach/monolithic hybrid. The performance of pure microkernels was just never up to the task.
while you are quite correct the question becomes why should the CPU handle those instructions? It is like USB 2.0 versus firewire 400. Firewire while "slower" burst rate has a higher steady rate precisely because it offloads some instructions.
SCSI, firewire are examples of good tech working for you. The CPU should output instructions to devices smart enough to be able to work on their own. Leaving more cycles available to do things that actually matter.
i thought once I was found, but it was only a dream.
If you read the article, Tannenbaum reminds everyone of how Microsoft paid Ken Brown to write a book accusing Linus of stealing the Minix microkernel. FTFA:
Kevin Smith on Prince
OS X, strictly speaking, is a hybrid kernel. Essentially, NeXT mashed together Carnegie Mellon's microkernel Mach with BSD (a monolithic kernel) - yielding the overwhelmingly originally named XNU kernel. (X is Not Unix). So in short - yes , OS X is a microkernel based OS, but is just as much a monolithic kernel based OS.
The secret to creativity is knowing how to hide your sources. - Albert Einstein
Actually, there is no microkernel in OS X. Everything in the operating system runs in the same kernel address space. Although individual subsystems within OS X can talk to each other with Mach messages (and also user space) they can also see each other's memory. Also, the VFS subsystem system and the network stack were lifted direct from BSD (although as of 10.4 they are much modified).
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
The only reason this debate is going on is because CPUs do not have the concept of modules. If they did, then each module would not be able to crash the rest of the modules.
If you wonder how to do modules without sacrificing the flat address space, it's quite easy: In most CPU designs, each page descriptor has a user/supervisor bit which defines if the contents of a page are accessible by the other pages. Instead of this bit, CPUs must use the target address to look up module information from another table. In other words, the CPU must maintain a map of addresses to modules, and use this map to provide security access.
This design is not as slow as it initially might seem. Modern CPUs are very fast, and they already contain many such maps: the Translation Lookaside Buffer, the Global Descriptor Table cache, the Local Descriptor Table cache, Victim Caches, Trace Caches, you name it.
Since the Vrije Universiteit Comp-Sci webserver has buckled under the firepower of the fully armed and operational Slashdot Effect, those who want to RTFA can go to Archive.org's Wayback Machine ...
'cause TFA was written in May 2006.
http://web.archive.org/web/*/http://www.cs.vu.nl/~ast/reliable-os/
o/~ Join us now and share the software
Calling Xen a microkernel is wrong. Yes, it provides "isolation", and it has that in common with microkernel, but isolation is not something that was invented by microkernels, so i don't see why we should call "microkernel" to anything that provides isolation. AFAIK Xen doesn't provide a way to create subprocesses to run functionality on it, it doesn't provive a real "message passing system"...i'd call it "virtual hardware", but not "microkernel".
Depends. Ever hear of FUSE? It's been showing up in quite a few distros for the capabilities it buys by running outside of kernel space. It's become so important, that it has been ported to BSD, Solaris, and Mac OS X.
What does it do? Why, it's a monolithic driver that provides an interface to support userspace filesystem drivers. i.e. A microkernel in practice, if not in definition. Ergo, the grandparent's point about a slow migration.
Javascript + Nintendo DSi = DSiCade
You can download it yourself here:
http://memo5.dyndns.org/Sites/Lisa/softs/othersofts.html
umm, wrong....
Loadable modules have nothing to do with micro/monolithic design. In a micro kernel those modules would have their own memory space, their own pid like identifier assigned by the monitor, and be doing all their communication with the rest of the kernel via some IPC process.
When you load a module in Linux, it lives in the same memory space as the rest of the kernel and can freely exchange data with the rest of the kernel via writing directly shared data structures. Modules don't give you a less monolithic kernel, what the do is allow you to determine what the monolith looks like at run time instead of compile time.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Well, let's consider a few virtualization platforms.
VMware ESX Server's "vmkernel" is supposed to be a custom microkernel that happens to use drivers from Linux (all device drivers run inside the vmkernel). Guest OSes (including the Linux-based service console used to manage the server) run on top of the vmkernel and access all hardware though it.
The Xen hypervisor does less than VMware's vmkernel; it loads a "dom0" guest that manages the system and performs I/O. With few exceptions, this guest is the only guest that directly interfaces with hardware. The hypervisor manages memory, schedules the CPU, and manages communication between guests.
Microsoft's Hyper-V appears to operate in a similar fashion to Xen.
In the case of Xen and Hyper-V, it's still different than a microkernel; the guest instance that is performing I/O is still a monolithic kernel - usually Linux with Xen and currently Windows 2008 with Hyper-V.
In all three systems, you've got one special guest that handles important system functions and one kernel handling I/O (be it a guest as in Xen/Hyper-V or be it the vmkernel in VMware). There's no "filesystem" process/VM, no "network driver" process/VM, etc.
He mentions them because they meet his design goal: they are highly-reliable operating systems used in mission-critical applications. (Here, "mission" might be, "Bombing the fuck out of people.") He is building his case that it's easier to design a bullet-proof OS using a microkernel, as opposed to a monolithic kernel.
And he's right. If your goal is reliability and security, a microkernel is a better design. Both goals rely on limiting the amount of time (and the amount of code) spent in kernel space. "Process isolation" is the mantra.
NeXTStep was a hybrid kernel. It was *almost* a microkernel (based on Mach). And, it was *highly* usable. It had the most usable UI in the industry, and still does in its current reincarnation as OS-X.
I think microkernels still have legs.
Microsoft is to software what Budweiser is to beer.
Depends. Ever hear of FUSE? It's been showing up in quite a few distros for the capabilities it buys by running outside of kernel space. It's become so important, that it has been ported to BSD, Solaris, and Mac OS X.
What does it do? Why, it's a monolithic driver that provides an interface to support userspace filesystem drivers. i.e. A microkernel in practice, if not in definition. Ergo, the grandparent's point about a slow migration.
Unfortunately, the problem with FUSE is that it's painfully slow. And yes, I do know what I'm talking about, having written drivers for it myself.
BTW, why the hell would it be the compiler's job to handle IPC? Shouldn't it the job of whatever is behind the OS API?
The compiler doesn't really handle IPC: what happens is that the compiler (or rather the loader) verifies that the programs are type- and memory-safe before allowing them to run. Then they are all loaded into a single memory space so that IPC is trivial. It's a neat concept, although not the first time it has been implemented (see an OS called 'JX').
He asserted that x86 architechture was doomed to extinction. Yet the majority of the -planet- uses an x86 machine of some sort as of 2008.
*sigh* That old chestnut.
Every x86 processor for the last decade, whether from intel, AMD or VIA is a superscalar, out-of-order, register-rich RISC internally with a layer that decodes x86 op codes and translates them into the native RISC code. The Transmeta chips were RISC/VLIW internally and could emulate any instruction set by loading the translation code at power-up.
Stick Men
I doubt Andy would be so interested in the Hurd, he is very much the message-passing fan. He also doesn't like the GPL.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
There are quite a few. FreeRTOS, eCos, RTEMS, AvrX etc, some of them commercially quite successful. The proprietary counterparts like Nucleus are definitely very successful and in wide use.
What, you have never heard of them ? Well, there are other widely used computing platforms besides personal computers.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!