Forgot your password?
typodupeerror

Torvalds on the Microkernel Debate 607

Posted by ScuttleMonkey
from the never-met-a-pointer-i-could-trust dept.
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)?'"
This discussion has been archived. No new comments can be posted.

Torvalds on the Microkernel Debate

Comments Filter:
  • Linus Quote (Score:5, Informative)

    by AnalystX (633807) on Wednesday May 10, 2006 @02:37AM (#15299124) Journal
    This my favorite Linus quote from that whole thread:

    "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)

    by Cryptnotic (154382) * on Wednesday May 10, 2006 @02:41AM (#15299133) Homepage
    He basically continues his previous argument that monolithic kernels are more efficient and easier to implement. Microkernels may seem simpler, but they have complexity in implementing all but the simple tasks. Microkernels have a more marketable name. "Microkernel" just sounds more advanced than "monolithic". He finishes off with the observation that the term "hybrid kernel" is a trick to grab marketing buzz from the microkernel side of things.
  • by j-stroy (640921) on Wednesday May 10, 2006 @02:49AM (#15299161)
    Linus FTFA:

    "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)

    by Anonymous Coward on Wednesday May 10, 2006 @02:57AM (#15299182)
    Quick slashdoteffect there, that forum is already down. Anyhow.. mirror: http://www.mirrordot.org/stories/3f6b22ec7a7cffcf2 847b92cd5dec7e7/index.html [mirrordot.org]
  • by gigel (817544) on Wednesday May 10, 2006 @02:59AM (#15299191)
  • by Anonymous Coward on Wednesday May 10, 2006 @02:59AM (#15299196)
  • Re:Code talks (Score:3, Informative)

    by microbee (682094) on Wednesday May 10, 2006 @03:11AM (#15299231)
    A couple more things to mention.

    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)

    by moosesocks (264553) on Wednesday May 10, 2006 @03:12AM (#15299234) Homepage
    HUH??

    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.
  • by microbee (682094) on Wednesday May 10, 2006 @03:21AM (#15299258)
    Buy a copy of Windows Internals and educate yourself. Specifically, page 36: Is Windows a Microkernel-Based System?

    Windows and Linux are not THAT different as far as kernel architecture is concerned.
  • already been done (Score:3, Informative)

    by sentientbrendan (316150) on Wednesday May 10, 2006 @03:22AM (#15299264)
  • Hybrid kernels??? (Score:4, Informative)

    by r00t (33219) on Wednesday May 10, 2006 @03:24AM (#15299269) Journal
    That would be monolithic+marketing.

    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.
  • by AnalystX (633807) on Wednesday May 10, 2006 @04:06AM (#15299386) Journal
    Perhaps you'll get more out of this instead: The Win32 Subsystem (what makes it Windows) is clearly running in user mode.

    http://www.microsoft.com/resources/documentation/w indowsnt/4/workstation/reskit/en-us/archi.mspx?mfr =true [microsoft.com]

    Also, Microsoft admits that microkernels are more dependable and show their research here:

    http://research.microsoft.com/research/pubs/view.a spx?type=technical+report&id=989 [microsoft.com]

    If you decide to look at the PDF, you can go straight to page 7 for the kernel architecture.
  • by Gorshkov (932507) <admgorshkov&yahoo,com> on Wednesday May 10, 2006 @04:26AM (#15299429)
    Sort of. In the scanerio you describe, the program was, in fact, not proved to be correct because the people who did the proof failed to take into account the real requirements for the system.

    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?

  • by jsse (254124) on Wednesday May 10, 2006 @04:46AM (#15299484) Homepage Journal
    I don't want to repost this old debate that I believe every geeks should have read it; but since nobody post it yet. I repost it for anybody who haven't read about this famous debate between Linus and Prof. Tanenbaum on microkernel.

    Linus vs. Tanenbaum - "Linux is obsolete" Jan,1992 [fluidsignal.com]

    (Save your mod point for someone who really need them thanks!)
  • by microbee (682094) on Wednesday May 10, 2006 @05:39AM (#15299614)
    Please, let's end this "Windows NT is microkernel" myth once and for all. Since most people don't actually know what a microkernel is, I'd quote some "authoritative" sources on this issue.

    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)

    by ajs318 (655362) <sd_resp2NO@SPAMearthshod.co.uk> on Wednesday May 10, 2006 @07:52AM (#15299925)
    Whilst microkernels are a lovely idea in theory, they don't deliver in practice. There is already a bottleneck between user space and kernel space and this will impact upon performance. No matter what you are trying to do, the slowest part of the process will always determine the maximum rate at which you can do it.

    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.
  • by Gorshkov (932507) <admgorshkov&yahoo,com> on Wednesday May 10, 2006 @08:19AM (#15299988)
    Today most of the software that is used to fly planes (both fighter jets and passenger) is based on a microkernel architecture. So microkernels are not just lab toys, real and mission critical systems are run by microkernel architectures.

    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 .... for MOST things, telling somebody that theyr'e going to take a 10-20% hit off the top before they do ANYTHING, compared to the alternatives, is going to get you nothing but doors slammed in your face

    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 .... disingenuous, and again, wrong.

    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 ..... and the SYSTEM still has 2.6 million lines of code.

    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)

    by diegocgteleline.es (653730) on Wednesday May 10, 2006 @08:39AM (#15300080)
    Let's ask Apple what thinks about all this: "Advanced Synchronization in Mac OS X: Extending Unix to SMP and Real-Time" [usenix.org]:

    "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."
  • by r00t (33219) on Wednesday May 10, 2006 @12:03PM (#15301552) Journal
    I worked on a commercial microkernel OS.

    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)

    by ichin4 (878990) on Wednesday May 10, 2006 @01:58PM (#15302553)

    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.

  • by jelle (14827) on Wednesday May 10, 2006 @03:18PM (#15303229) Homepage
    You choose for that filesystem call to wait forever.

    Try

    mount -o soft compy2:/share /mnt/compy2

    or

    mount -o intr compy2:/share /mnt/compy2

    instead

    man 8 mount
  • Re:Obvious (Score:3, Informative)

    by cecom (698048) on Wednesday May 10, 2006 @05:23PM (#15304237) Homepage Journal
    We see this misconception way too often. Modular design, well defined interfaces, etc. have nothing to do with a microkernel. You can apply those excellent design principles in a monolithic kernel, you can even apply them in regular applications :-) The one distinguishing feature of a microkernel is the separation of address spaces of its components.

...when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. - Fred Brooks, Jr.

Working...