Torvalds on the Microkernel Debate 607
diegocgteleline.es writes "Linus Torvalds has chimed in on the recently flamed-up (again) micro vs monolithic kernel, but this time with an interesting and unexpected point of view. From the article: 'The real issue, and it's really fundamental, is the issue of sharing address spaces. Nothing else really matters. Everything else ends up flowing from that fundamental question: do you share the address space with the caller or put in slightly different terms: can the callee look at and change the callers state as if it were its own (and the other way around)?'"
Linus Quote (Score:5, Informative)
"In the UNIX world, we're very used to the notion of having
many small programs that do one thing, and do it well. And
then connecting those programs with pipes, and solving
often quite complicated problems with simple and independent
building blocks. And this is considered good programming.
That's the microkernel approach. It's undeniably a really
good approach, and it makes it easy to do some complex
things using a few basic building blocks. I'm not arguing
against it at all."
Not unexpected... (Score:5, Informative)
Re:Linus Quote - "not arguing against it at all" (Score:5, Informative)
"The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms.
And anybody who tells you that distributed algorithms are "simpler" is just so full of sh*t that it's not even funny.
Microkernels are much harder to write and maintain exactly because of this issue. You can do simple things easily - and in particular, you can do things where the information only passes in one direction quite easily, but anythign else is much much harder, because there is no "shared state" (by design). And in the absense of shared state, you have a hell of a lot of problems trying to make any decision that spans more than one entity in the system.
And I'm not just saying that. This is a fact. It's a fact that has been shown in practice over and over again, not just in kernels. But it's been shown in operating systems too - and not just once. The whole "microkernels are simpler" argument is just bull, and it is clearly shown to be bull by the fact that whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins. By a huge amount, too.
The whole argument that microkernels are somehow "more secure" or "more stable" is also total crap. The fact that each individual piece is simple and secure does not make the aggregate either simple or secure."
Mirror (Score:4, Informative)
slashdotted, pastebin copy of interview (Score:5, Informative)
In case you missed it the first time around (Score:1, Informative)
Re:Code talks (Score:3, Informative)
1. Windows has some essential system services running in the user space, such as Win32 environment (csrss.exe). But if it dies, you are pretty much hosed anyways. It doesn't necessarily make the system more stable in any meaningful way by running stuff in user space. Windows even had GDI in user space before, and later moved into the kernel for performance reasons, and GDI in user space didn't provide more stability.
2. Linux kernel 2.6 now has support for user space filesystems. So it's already possible to have a user space filesystem running under a monolithic kernel.
The fact is, microkernel proponents have not delivered. In reality people who tried those ideas have mostly abandoned them (see 1) because the gain couldn't justify the loss. We don't build our systems just on nice theory.
Re:Code talks (Score:4, Informative)
Get your facts straight.
Every popular Operating System developed in the past 15 years (and then some) apart from Linux has been either a microkernel [wikipedia.org] or a hybrid kernel [wikipedia.org].
Mach, upon which Darwin and OS X are based is a microkernel. OSX and Darwin borrow some monolithic-esque features, but not quite enough to make them hybrids it would seem...
Windows NT, NetWare, ReactOS and BeOS are all Hybrid kernels. This model seems to be the most popular right now, and seems to be a reasonable compromise...
The only thing that's left are the old big-iron Unices, Solaris, MS-DOS, and Linux. In other words, Linux is the only major player left using a monolithic kernel. I don't know enough about computer science to properly make an argument one way or another, but it would see that monolithic kernels have heavily fallen out of favor in the past 15 years.
That said, perhaps a monolithic kernel is better suited to the open-source development process, which would seem counterintuitive at first because it discourages modularization, but who knows.... it could very well be true. I don't know enough to comment.
Windows is monolithic (Score:3, Informative)
Windows and Linux are not THAT different as far as kernel architecture is concerned.
already been done (Score:3, Informative)
Hybrid kernels??? (Score:4, Informative)
MacOS X is no microkernel system. It does have Mach, sure. Mach is arguably not a microkernel by today's standards, and in any case MacOS X has a full BSD kernel bolted onto the Mach kernel. Mach and BSD are sharing address space. In other words, it's not a microkernel.
NT is the same way.
I don't know all that much about NetWare, but I'd never before heard anyone claim it to be a microkernel. It's not terribly popular anyway. (it was, but back then I'm sure it wasn't a microkernel system) ReactOS isn't much yet. BeOS died for unrelated reasons, so we really can't judge.
Monolithic kernels can be very modular. Microkernels can get really convoluted as the developers struggle with the stupid restrictions.
Tanenbaum on microkernels (Score:5, Informative)
This does not mean you have to agree with the guy.
http://www.computer.org/portal/site/computer/menu
http://vig.prenhall.com/catalog/academic/product/
Re:Windows is monolithic (Score:3, Informative)
http://www.microsoft.com/resources/documentation/
Also, Microsoft admits that microkernels are more dependable and show their research here:
http://research.microsoft.com/research/pubs/view.
If you decide to look at the PDF, you can go straight to page 7 for the kernel architecture.
Re:Distributed not that hard. (Score:4, Informative)
If you don't even know your requirements, no methodology to implement those requirements is going to work reliably.
I agree absolutly.
The point I was trying to make - and this is where I see the parallel - is that T seems to be trying to say that microkernel good, monolithic bad based only on elegant design, and theoretical simplicity. No doubt, it appeals to the academic in him (Go figure)
But he is ignoring the "time domain" of an operating system, if you will - it's practicality, it's ability to do usefull work in a reasonable period, and it's usability in the real world - just as Parnas' notation did.
I make no claim as to whether or not Parnas *intended* for his notation to be used for a hard real-time system - I know he was retained as a consultant on the project, but I personally neither saw nor heard of/from him during the entire time. And let me be perfectly clear - his notation was absolutly *gorgeous* and extremly usefull. I, on the other hand, having been the idiot who raised the point in the first place, wound up having to do the timing analysis based on best/worst case sensor timings, and instruction-by-instruction counting of the clock cycles required for each ISR, etc. I plugged the numbers into a programme I wrote for the purpose, and basically did nothing more than an exhaustive analysis of all possible combinations of timings. Not as elegant by far, but what the hell. Who cares if it takes two days to run, if it means you don't have to worry about glowing in the dark?
Linus vs. Tanenbaum - "Linux is obsolete", Jan1992 (Score:3, Informative)
Linus vs. Tanenbaum - "Linux is obsolete" Jan,1992 [fluidsignal.com]
(Save your mod point for someone who really need them thanks!)
Re:Windows is monolithic (Score:5, Informative)
1. From AST (I'd assume you know who he is since you are interested in Linus/microkernel debate): http://www.cs.vu.nl/~ast/brown/followup/ [cs.vu.nl] Read the section "Microkernels Revisited":
I can't resist saying a few words about microkernels. A microkernel is a very small kernel. If the file system runs inside the kernel, it is NOT a microkernel. The microkernel should handle low-level process management, scheduling, interprocess communication, interrupt handling, and the basics of memory management and little else. ... Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0.
2. From Windows Internals, the 4th edition, published by Microsoft Press. Page 36: Windows is similar to most Unix systems in that it's a monolithic operating system in the sense that the bulk of the operating system and device driver code shares the same kernel-mode protected memory space. Can we stop claiming Windows has a microkernel now?
The Thing Is (Score:3, Informative)
Monolithic, Linux/Netware-style modular and so-called hybrid kernels get around this limitation by moving things to the other side of the bottleneck. It makes sense on this basis to put a hardware driver in kernel space. You usually only pass "idealised" data to a driver; the driver generally has to pass a lot more to the device because it isn't ideal. For example, when talking to a filesystem driver, you generally only want to send it the data to stick into some file. The filesystem driver has to do all the donkey work of shunting the heads back and forth and waiting for the right spot of disc to pass under them.
It might be "beautiful" to have as little code as possible situated on one side of the division, but it's most practical to have as little data as possible having to travel through the division.
Re:Distributed not that hard. (Score:3, Informative)
And where did I say that microkernels were unusable? I've personally used QNX and VRTX myself. For small, simple (for the O/s) systems, they're beautifull. As a general purpose coputing platform, they tend not to be.
The speed problem can often be solved just buy getting a faster hardware. The main reason Linus rejected microkernels back in the day was because the cost of context switches was prohibitive. Today hardware is lot faster (roughtly Moore's law), so context switches will be alright on a 3GHz Pentium IV machines while it would not be doable on a 33Mhz machines.
Disingenuous, but wrong. Modern computers do a lot more now, typically, then they did then - and so need faster CPUs for the WORKLOAD. I don't care what the application is
Theoretically you are right. But in practice Linux 2.6 is 6 million lines of code and a typical microkernel is less than 10k. It can already take up to a year to check the correctness of a 8k lines of code microkernel and there will be an exponential demand for resources as the code size increases. So in reality it will not be possible to check the linux kernel for correctness.
Again
Linus has this nice little kernel with 2.6 million lines of code in it
Linus refactors his code so that device drivers, filesystems, etc are outside the kernel, and he has a nice mini-me Linux
What do we have? We STILL have 2.6 million lines of code, but some of them are in the kernel, and the rest of them are OUTSIDE the kernel. SO what magically happens to those bits that were moved out to userland? Did they suddenly become flawless? Of course not - the errors and flaws are still there. Because you do't really CARE about any arbitrary distinction betweeen kernel/userland, do you, as long as you can read from the disk, write to the network, etc. it's the SYSTEM that counts
Secondly, a lot of the things that you're claiming for microkernels - lack of complexity, etc - can be acheived just as simply by how you organise the sorce code FOR the kernel. It used to be called compartmentalisation. Ever hear of it?
Re:Hybrid kernels??? (Score:4, Informative)
"xnu is not a traditional microkernel as its Mach heritage might imply. Over the years various people have tried methods of speeding up microkernels, including collocation (MkLinux), and optimized messaging mechanisms (L4)[microperf]. Since Mac OS X was not intended to work as a multi-server, and a crash of a BSD server was equivalent to a system crash from a user perspective the advantages of protecting Mach from BSD were negligible. Rather than simple collocation, message passing was short circuited by having BSD directly call Mach functions. While the abstractions are maintained within the kernel at source level, the kernel is in fact monolithic. xnu exports both Mach 3.0 and BSD interfaces for userland applications to use. Use of the Mach interface is discouraged except for IPC, and if it is necessary to use a Mach API it should most likely be used indirectly through a system provided wrapper API."
I was a microkernel developer (Score:4, Informative)
The learning curve was very steep. New developers took at least half a year to be productive. A number of people never became productive and had to be fired.
Linux is really clean and tidy compared to that. Even BSD is clean and tidy compared to that microkernel OS.
Separated components tend to get complex interactions. Sharing data can be very awkward, even if you are co-located.
Re:Obvious (Score:3, Informative)
Also can you provide some examples of kernel experts praising the NT kernel for its microkernel properties?
W2K does not have a pure microkernel architecture but what Microsoft refers to as a modified microkernel architecture. As with a pure microkernel architecture, W2K is highly modular. Each system function is managed by just one component of the operating system. The rest of the operating system and all applications access that function through the responsible component using a standard interface. Key system data can only be accessed through the appropriate function. In principle, any module can be removed, upgraded, or replaced without rewriting the entire system or its standard application program interfaces.
William Stallings, "Operating Systems Internals and Design Principals", Fourth Edition, pp. 86-87.
Re:Linus Quote - "not arguing against it at all" (Score:3, Informative)
Try
mount -o soft compy2:/share
or
mount -o intr compy2:/share
instead
man 8 mount
Re:Obvious (Score:3, Informative)