Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Torvalds on the Microkernel Debate

ScuttleMonkey posted more than 8 years ago | from the never-met-a-pointer-i-could-trust dept.

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

Sorry! There are no comments related to the filter you selected.

Linus Quote (5, Informative)

AnalystX (633807) | more than 8 years ago | (#15299124)

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

Re:Linus Quote (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15299159)

No no.. Here is what linus actually said:

"WTF crawled up your *** this time Tannenbaum? You're like a bloody ambulance. Whhaaaaaaa, your kernel desing is wrong, whaaaaaaaa."

Re:Linus Quote - "not arguing against it at all" (5, Informative)

j-stroy (640921) | more than 8 years ago | (#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."

Re:Linus Quote - "not arguing against it at all" (4, Interesting)

ultranova (717540) | more than 8 years ago | (#15299274)

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

Individual pieces aren't really any simpler either. In fact, if you want your kernel to scale, to work well with lots of processes, you are going to run into a simple problem: multitasking.

Consider a filesystem driver in a monolithic kernel. If a dozen or so processes are all doing filesystem calls, then, assuming proper locking and in-kernel pre-emption, there's no problem - each process that executes the call enters kernel mode and starts executing the relevant kernel code immediately. If you have a multiprocessor machine, they could even be executing the calls simultaneously. If the processes have different priorities, those priorities will affect the CPU time they get when processing the call too, just as they should.

Now consider a microkernel. The filesystem driver is a separate server process. Executing a system call means sending a message to that server and waiting for an answer. Now, what happens if the server is already executing another call ? The calling process blocks, possibly for a long time if there's lots of other requests queued up. This is an especially fun situation if the calling process has a higher priority than some CPU-consuming process, which in turn has a higher priority than the filesystem server. But, even if there are no other queued requests, and the server is ready and waiting, there's no guarantee that it will be scheduled for execution next, so latencies will be higher on average than on a monolithic kernel even in the best case.

Sure, there are ways around this. The server could be multi-threaded, for example. But how many threads should it spawn ? And how much system resources are they going to waste ? A monolithic kernel has none of these problems.

I don't know if a microkernel is better than monolithic kernel, but it sure isn't simpler - not if you want performance or scalability from it, but if you don't, then a monolithic kernel can be made pretty simple too...

Re:Linus Quote - "not arguing against it at all" (4, Interesting)

Hast (24833) | more than 8 years ago | (#15299322)

assuming proper locking and in-kernel pre-emption, there's no problem - each process that executes the call enters kernel mode and starts executing the relevant kernel code immediately. If you have a multiprocessor machine, they could even be executing the calls simultaneously.

That's a pretty big assumption. Or rather, you have basically taken all the hard parts of doing shared code and said "Let's hope someone else already solved this for us".

The filesystem driver is a separate server process. Executing a system call means sending a message to that server and waiting for an answer. Now, what happens if the server is already executing another call ? The calling process blocks, possibly for a long time if there's lots of other requests queued up.

Sooooo, it's easy to have someone else handle the multi-process bits in a monolithic design. But when it comes to writing services for microkernels suddenly everyone is an idiot?

Besides, as Linus pointed out, when data is going one way microkernels are easy. And in the case of file systems that is really the case. Sure multiple processes can access it at once, but the time scale on handling the incoming signals is extremely fast compared to waiting for data from disk. Only a really, *really* incompetent idiot would write such a server which blocked until the read was finished.

Re:Linus Quote - "not arguing against it at all" (2, Interesting)

Sique (173459) | more than 8 years ago | (#15299331)

In the end it boils down to the old question centralisation vs. local autonomy. Centralisation is fine for keeping state, it is fine for enforcing a thoroughly similar approach to everything, it helps with 'single points of contact'. Local autonomy helps with less administrational effort, with clearly defined information paths and with clear responsibilities, thus with keeping problems locally.

Both approaches have their merits, and in the real world you will never see a purely central organisation or a purely localized organisation. Every organisation is somehow swinging between both extrema, going more central at one point "to leverage synergies and increase efficiency", or is starting outsourcing and reorganizing itself into profit centers, to "overcome bureaucracy, to clearly define responsibilities and to cut down on administrational spending".

The limits are given by the speed information is created, sent and decoded within the different organisational paths. An increase in Inter Process Communication speed will help with a more modularized microkernel approach, an increase in number and complexity of concurrent requests demands a more centralized kernel.

In the end it boils down to the fact, that transactions have to be atomar operations, either being executed completely or rolled back completely if not finished. Centralized systems are inherently transactional, especially if they are executing tasks sequentially. The limit is given with the numbers of transactions that can be executed per time unit. Parallel execution demands operations to be as independent of each other as possible, thus increasing design efforts, but once the task is (nearly) interlock free, a modularized approach helps with faster, better maintenable code.

Distributed not that hard. (3, Interesting)

Inoshiro (71693) | more than 8 years ago | (#15299283)

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

I think you're looking at this the wrong way around.

There has been a lot of research into this over the past 40 years, ever since Dijkstra first talked about coordination on a really big scale in the THE operating system. Any decent CS program has a class on distributed programming. Any decent SW architect can break down these different parts of the OS into weakly-connected pieces that communicate via a message passing interface (check out this comment [slashdot.org] by a guy talking about how Dragonfly BSD does this).

It's obvious that breaking something like your process dispatcher into a set of processes or threads is silly, but that can be easily separated from the core context switcher. Most device driver bottom halves live fine as a userland process (each with a message-passing interface to their top-halves).

If you're compiling for an embedded system, I'm sure you could even entirely remove the interface via some #define magic; only debug designs could actually have things in separate address spaces.

The point I'm trying to make is: yes, you can access these fancy data structures inside the same address space, but you still have to serialize the access, otherwise your kernel could get into a strange state. If you mapped out the state diagram of your kernel, you'd want the transistions to be explicit and synchronized.

Once you introduce the abstraction that does this, how much harder is it to make that work between processes as well as between threads in the kernel? How much of a benefit do you gain by not having random poorly-written chunks pissing over memory?

How about security benefits from state-machine breakdowns being controlled and sectioned off from the rest of the machine? A buffer overflow is just a clever way of breaking a state diagram and adding your own state where you have control over the IP; by being in a separate address space, that poorly written module can't interact with the rest of the system to give elevated privileges for the attacker (unless, of course, they find flaws in more of the state machines and can chain them all together, which is highly unlikely!).

Clearly there is a security benefit as much as there is a consistency benefit. Provably correct systems will always be better.

Re:Distributed not that hard. (0)

Anonymous Coward | more than 8 years ago | (#15299301)

Ahah! You must be that 'full of sh!t' individual Linus alluded to. Thanks for stopping in and proving him correct!

Re:Distributed not that hard. (0)

Anonymous Coward | more than 8 years ago | (#15299317)

It's pathetic the number of cock suckers in here backing up Linus in supporting an obsolete kernel design,

Re:Distributed not that hard. (4, Interesting)

Gorshkov (932507) | more than 8 years ago | (#15299344)

Provably correct systems will always be better.

Well, I could certainly argue THAT one.

Years ago, I was a lead analyst on an IV&V for the shutdown system for a nuclear reactor - specifically, Darlington II in Ontario, Canada.

This was the first time Ontario Hydro wanted to use a computer system for shutdown, instead of the old sensor-relay thingie. This made AECB (Atomic Energy Control Board) rather nervous, as you can understand, so they mandated the IV&V.

I forget his first name - but Parnas from Queen's University in Kingston had developed a calculus to prove the correctness of a programme. It was susinct, it was precice, it was elegant, and it worked wonderfully.

ummmmm ..... well, kind of. About 3/4 of the way through the process, I asked a question that nobody else had thought of.

OK, so we prove that the programme is correct, and it'll do what it's supposed to do .... but how long will it take?

You see, everybody had kinda/sorta forgot that this particular programme not only had to be correct, but it had to tell you that the reactor was gonna melt down BEFORE it did, not a week afterwards.

The point is, that there is often much more involved in whether or not a programme (or operating system) is usefull than it's "correctness"

Re:Distributed not that hard. (2, Insightful)

Schraegstrichpunkt (931443) | more than 8 years ago | (#15299390)

The point is, that there is often much more involved in whether or not a programme (or operating system) is usefull than it's "correctness"

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.

Re:Distributed not that hard. (3, Informative)

Gorshkov (932507) | more than 8 years ago | (#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?

Re:Distributed not that hard. (2, Interesting)

drgonzo59 (747139) | more than 8 years ago | (#15299425)

Tovarisch Gorshkov, to prove that the program is correct ("covert channel analysis" and such.) might take up to a year and that is only if there are less than 10k lines of code and no more, but that doesn't mean that the program will _run_ slow. The time and methods used to prove correctness don't necessarily say anything about the speed of the program during runtime.

So correct systems will always be better, because you know it is correct and you know the limits (want it to run faster -- just buy faster hardware ). On the other hand, if the program hasn't been been proved to work correctly, even though it might be blazingly fast, one day it might just stop working and your control rods will end up being stuck half way through, all because there is a "off-by-one" error in some stupid serial driver or something like that...

Your definition?? (1)

Khyber (864651) | more than 8 years ago | (#15299363)

And what is your definition of a "Traditional Kernel?" If you wanna get really technical, start looking back at ENIAC and UNIVAC, from the '50s/60s.

Re:Your definition?? (1)

Schraegstrichpunkt (931443) | more than 8 years ago | (#15299432)

Quiet, heretic! We refuse to get all caught up in your technical mumbo-jumbo; We're here to defend the traditional definition of kernel... facts be damned!

Re:Linus Quote - "not arguing against it at all" (0)

Anonymous Coward | more than 8 years ago | (#15299413)

"The fundamental result of access space separation is that you can't share data structures."

That's not true. You can share parts of your address space if you want to. Of course the trouble is that if you share bits of your internal state in a writeable way, anyone who can modify it can also screw it up.

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

This could also be due to a general difference of philosophy and not just the kernel style issue. Worse is better. [wikipedia.org]

Re:Linus Quote - "not arguing against it at all" (3, Insightful)

exa (27197) | more than 8 years ago | (#15299426)

Distributed algorithms are of course difficult to implement with a f***ed up language like C.

Here, it seems, the means justify the ends. Linus basically says "I won't take any challenges".

Linus tells me that we can never write a proper scalable OS for a NUMA machine, or a modular system that can serve well to parallel I/O systems and the like. I highly disagree.

Because these things are not pipe dreams, they have been done. IBM guys have made amazingly abstract and modular OS stuff and they've been using them for years, so I think it's rather pathetic to say that there is only one true path to OS implementation. Why not admit that it is the only path that you have any experience in?

Re:Linus Quote (0, Redundant)

Arker (91948) | more than 8 years ago | (#15299163)

Looks like an interesting thread. Sadly their server is smoking already. I'll check it out in the morning.

Re:Linus Quote (1)

NoNickNameForMe (884862) | more than 8 years ago | (#15299193)

If this isn't selective quoting, I don't know what is. Please quote the rest of his comments. Basically he said that it's good for the simple case, but it falls flat for the more complex situations where pipes (and by analogy, microkernels) won't work well because there is multi-way interaction between the modules.

Re:Linus Quote (1)

AnalystX (633807) | more than 8 years ago | (#15299206)

All quoting is selective quoting. That's why it's called a quote. Not only that, I pointed out that it was my favorite quote. If I quoted something else, it would no longer be my favorite quote.

Re:Linus Quote (1)

Stormwatch (703920) | more than 8 years ago | (#15299260)

Wait, wait, you've read TFA? Around here that's called "cheating"!

Shared memory? (1)

hackwrench (573697) | more than 8 years ago | (#15299412)

So how does giving each program its own memory space, but having chunks of memory mapped into multiple memory spaces fit into the scheme of things? I'm confused!

Re:Linus Quote (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15299440)

My favorite Linus quote:
I also claim that Slashdot people usually are smelly and eat their boogers, and have an IQ slightly lower than my daughters pet hamster (that's "hamster" without a "p", btw, for any slashdot posters out there. Try to follow me, ok?).
-- Linux [kerneltrap.org]

Just do it! (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15299130)

So there's a performance hit, right? Computers are fast enough enough these days, right? That's what the Java folks have foisting on us all along. Or, wait, isn't Java fast as or faster than C++? Performance doesn't matter if you can disguise the slow load times with a "time warp" (i.e. splash screen, lazy loading)? WHO'S LYING?

Re:Just do it! (1)

Vyvyan Basterd (972007) | more than 8 years ago | (#15299144)

As fast as C++ would be a fairly lame goal for a kernel.

Re:Just do it! (1)

WindBourne (631190) | more than 8 years ago | (#15299397)

and yet, BEOS showed that C++ was blazing fast for a kernel.

2nd post dildos! (-1, Troll)

Asshat_Nazi (946431) | more than 8 years ago | (#15299131)

Ever had sex with a muslim? I hope not, otherwise you're going to burn in hell!

niggers..

Not unexpected... (4, Informative)

Cryptnotic (154382) | more than 8 years ago | (#15299133)

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.

Re:Not unexpected... (1)

drmerope (771119) | more than 8 years ago | (#15299302)

But he fails to discuss the one area where message passing makes a certain amount of sense. Even a single computer is beginning to look more like a distributed system today: SMP is becoming increasingly common. In these situations communication and coordination is often costly. The trouble with a monolithic kernel comes in precisely what it makes easy: sharing memory and data structures--the very sort of thing that if not done very carefully destroys SMP performance, e.g., by cache-line stumping.

Taking a hybrid approach where a kernel thread runs on each CPU begins to make a certain amount of sense. Message passing becomes an analog to the interprocessor IPI messaging and shared memory bus-locked instructions.

In other words: microkernel concepts (not implementation) become a discipline that helps you avoid doing seemingly simple things that are actually quite cycle-time expensive.

Naturally though it isn't right to call this new idea "microkernel" it isn't subsystem partitioning per se. It is definitely a hybrid idea.

Yes Hyrbid kernels can be more than marketing hype. On that point Linus is definitely just being an attention-whore by making a sweeping generalization.

pfff (4, Funny)

Umbral Blot (737704) | more than 8 years ago | (#15299142)

pfff, Linus, what would he know?

Re:pfff (1)

jounihat (884616) | more than 8 years ago | (#15299253)

Yea, you said it. Who is this Linus guy, anyway? I bet he hasn't done a bit _real_ OS kernel programming.

Let me be the first to say... (0)

Anonymous Coward | more than 8 years ago | (#15299151)

That's SOOO 1992!

Obvious (0, Troll)

Scott Swezey (678347) | more than 8 years ago | (#15299165)

Forgive me if I am wrong, but doesn't windows have a bloated kernel? (I really know nothing about the internals of computers... but it would seem like this makes sense) Obviously it would seem that windows isn't so great when it comes to stability or security... So, lets learn from what windows did wrong, and break things down to small parts that are easier to work with, more secure, and everything everyone else voting for the micro kernel idea said.

Anyways, what do the Ubtuntu guys have to say about this? They seem to be doing pretty well...

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#15299178)

a brilliant troll. this will come off nicely.

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#15299199)

Please forgive my spelling, English is my first language.

Apparently this is not the case. I have reviewed your comment, and it seems that Talkingoutofyourarse-ese is your first language.

Really, is there any point to making comments like this when you freely acknowledge that you haven't got a clue what the fuck you are talking about?

Re:Obvious (1, Offtopic)

spacecowboy420 (450426) | more than 8 years ago | (#15299208)

Ok, I don't normally do this, but dude - either you're an idiot, or a troll.

http://en.wikipedia.org/wiki/Linux/ [wikipedia.org]

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#15299255)

do what? reply out of context?

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#15299398)

Parent is at -1, maybe you should lower your threshold.

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#15299210)

No, Windows NT, 2000, XP etc all have a hybrid kernel, based off the very successful Windows NT kernel.

Mac OS X also uses a hybrid kernel based parly off the Mach kernel and partly from the FreeBSD kernel.

The windows kernel is surprisingly advanced technologically. It's not the bloated patched up QBasic mess that people assume. The problem with windows is not the kernel, but Microsoft's management of the software development cycle and lack of vision.

Re:Obvious (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15299371)

The windows kernel is surprisingly advanced technologically. It's not the bloated patched up QBasic mess that people assume. The problem with windows is not the kernel, but Microsoft's management of the software development cycle and lack of vision.

Sorry, but I have to ask. You speak as though you worked at MS. I worked at HP in 1994. At that time, the group next to me ported NT to the PA-RISC. While I was not part of that group, I got to look over the code and talk to several of the engineers who did it. And I can tell you, that it was total crap. Not a little bit, but honest to god total crap. It became one of the bigger jokes to go an look through the code and see what was there. They had obvious buffer overflows, uninitialized pointers, etc issues in a number of areas. The press, and people like you, were pushing coders from there as being good to great and it was obvious that they had a number a idiots on their kernel.

While I did not go through the kernel (just examined a few files), the porters did. They pointed out how archiac it was, as well as badly coded.

The truth was that it was fully ported to the pa. But HP never offered it, because it was so bad, that there was no way that it was going to be stable. So, what exactly do you (and press members) base your assement of windows on? Why do you state that it is advanced tech? What frame of reference do you base it on? Or are you just trolling here?

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#15299265)

I must disagree with you. And I might add that M$ LookOUT is another example of how bloated software causes all kinds of security issues. It becomes obvious the OS X kernel is the way to go.

However we run into the problem of free (as in freedom, not beer) software developers only developing to scratch an itch. Mind you - it is entirely their right to do so! Just as it is their right to download music - after all this is most certainly not piracy!

I think you will find though that the underlying issue is that C, and if coding at a higher level Perl, is far superior to, say, Java or .Net. When coding it makes far better sense to code in the fastest language possible.

Overall we should listen to Linux Trovalds as he is the only person ever to have coded a kernel and invented the concept of free software - an amazing feat that was never previously accomplished, and quite possibly may never be accomplished again in our lifetime. This makes him the best and only authority on the matter which means that if anyone disagrees they are obviously not very intelligent.

Re:Obvious (0)

Anonymous Coward | more than 8 years ago | (#15299290)

"Overall we should listen to Linux Trovalds as he is the only person ever to have coded a kernel and invented the concept of free software - an amazing feat that was never previously accomplished, and quite possibly may never be accomplished again in our lifetime. This makes him the best and only authority on the matter which means that if anyone disagrees they are obviously not very intelligent."
 
 


Hey Linus, how you doin..? It's been a while since we heard from you.

Re:Obvious (1)

Skreems (598317) | more than 8 years ago | (#15299281)

Ok... but Linux is a monolithic kernel system as well. The security and (now outdated) stability concerns in Windows had to do with things going on in user space, more than inside the kernel itself. Are there ANY widely used microkernel systems today? I can't think of any... and from what Linus was saying in the article, there's a damn good reason for that fact.

Re:Obvious (5, Insightful)

ichin4 (878990) | more than 8 years ago | (#15299284)

You are forgiven for being wrong, but not for spouting off nonsense despite knowing that you don't know what you're talking about, apparently applying the principal "if my argument involves M$ doing the wrong thing, it must be right".

While neither NT nor Mac OS X are true microkernels, the architecture of both is strongly inspired by microkernel ideas. Like Linus, the developers of these kernels recognized the practical difficulties involved in making full-on microkernels work, but unlike Linus, instead of throwing in the towel completely and doing full-on monolithic kernels, they created cleanly seperated layers interacting via well-defined interfaces whenever they practically could.

If you talk to kernel programmers, most will express a high degree of respect for the NT kernel, which is based on the DEC VMS kernel. It mostly the poor design of systems that sit on top of the kernel that has earned Windows its reputation.

Re:Obvious (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15299445)

If you ever actually _coded_ anything in the NT Kernel you'd be eating your words. NT is a mess. A microkernel that turned into a monolith out of necessity. And it's _hardly_ clean in there [[shudder]].

Code talks (5, Insightful)

microbee (682094) | more than 8 years ago | (#15299168)

The whole discussion of micro-kernel vs monolithic kernel is totally pointless. All popular OS kernels are monolithic. We can get back to the debate when we have a working fast microkernel in the market that is actually competitive.

Linus is a pragmatist. He didn't write Linux for academic purpose. He wanted it to work.

But you can always prove him wrong by showing him the code, and I bet he'd be glad to accept he was wrong.

Re:Code talks (1)

MacTenchi (104785) | more than 8 years ago | (#15299221)

You're forgetting Mac OS X is microkernel-based (on Mach BSD). Or maybe you don't consider it popular?

It's not really a microkernel. (3, Insightful)

r00t (33219) | more than 8 years ago | (#15299276)

By today's standards, Mach is not much of a microkernel. Mach has been disowned by microkernel proponents because it was so big and nasty.

MacOS has that sharing address space with the monolithic BSD kernel. So a semi-microkernel and a monolithic kernel are firmly bolted together. That's only a microkernel if your degree is in marketing.

Re:Code talks (1)

zbrimhall (741562) | more than 8 years ago | (#15299227)

The Darwin kernel? But I suppose you'd argue that it isn't fast, or it isn't popular, or it isn't competitive.

This is admittedly an area in which I have only a general understanding.

Re:Code talks (2, Informative)

microbee (682094) | more than 8 years ago | (#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 (4, Informative)

moosesocks (264553) | more than 8 years ago | (#15299234)

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.

Re:Code talks (5, Interesting)

microbee (682094) | more than 8 years ago | (#15299249)

"Hybrid" kernel? Sorry, I just don't buy this terminology (as Linus put it, it's purely marketing).

Windows NT is monolithic. So is OS X. Anyone claims it to be microkernel please show me the proof other than "it is based on Mach".

Re:Code talks (1)

JPriest (547211) | more than 8 years ago | (#15299349)

A microkernel places everything in user space, if you have a kernel that does some things in the kernel address space (memory management, disk I/O etc.) and some things in user space (audio, drivers etc.) then it would then be considered "hybrid". I believe OSX and NT are both hybrid.

Re:Code talks (1)

Bacon Bits (926911) | more than 8 years ago | (#15299408)

Drivers run in kernel mode. That why they're able to cause bluescreen errors. Only kernel mode errors (or hardware errors) cause blue screen errors. For the curious: Architecture of the Windows NT operating system line [wikipedia.org] . It's a lengthy read, but there are numerous microkernel and monlithic aspects of WinNT.

Re:Code talks (1)

Cyno (85911) | more than 8 years ago | (#15299417)

Oh oh...

Linux has a userspace filesystem. Does that make it a Hybrid too?

hehe

What you may be experiencing right now is popularly known as Cognitive Dissonance [wikipedia.org] , or the difference between marketing and reality. :)

Re:Code talks (0)

Anonymous Coward | more than 8 years ago | (#15299427)

Linux has a userspace filesystem. Does that make it a Hybrid too?

That's just one example. How about the graphcis drivers (X)? The one thing that gets the blame for almost all BSOD's on Windows, because Windows has graphics drivers in kernel space. Then there is libusb (USB in userspace), the tun/tap userspace network interface, and probably even more that I forgot about.

Hybrid kernels??? (3, Informative)

r00t (33219) | more than 8 years ago | (#15299269)

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.

Re:Hybrid kernels??? (5, Interesting)

jackjeff (955699) | more than 8 years ago | (#15299394)

Depends on what you mean by Micro Kernel and Monolithic.

True, the kernel of MacOS/X - Darwin, aka XNU, for performance reasons run the Mach and BSD layer both in superuser space to minimize the lattency.

Maybe this is what you call a hybrid kernel: http://en.wikipedia.org/wiki/Hybrid_kernel [wikipedia.org]

You may call XNU whatever you wish but the fact remains:
- it's not a monolithic kernel by design
- it has Mach in it and Mach is some sort of microkernel. Maybe it does not reach "today's" standards of being called a microkernel but it was a very popular microkernel before.

So maybe the things running on top of Mach ( http://developer.apple.com/documentation/Darwin/Co nceptual/KernelProgramming/index.html [apple.com] ) are conceptually "different" from what the services of microkernel should be, and they do share indeed the address space, but this is very very very different from the architecture of a traditional monolithic kernel such as Linux

This guy ( http://sekhon.berkeley.edu/macosx/intel.html [berkeley.edu] ) recently tested some stats software on his Mac running OS X and Linux, and found out that indeed MacOS X had performance issues, very likely due to the architecture of the kernel.

There's even a rumor that says that since Avie Tevanian left Apple ( http://www.neoseeker.com/news/story/5553/ [neoseeker.com] ), some guys are now working for removing the Mach microkernel and migrate to a full BSD kernel in the next release of the operating system.

And now my personal touch. I agree with Linus when he says that having small components doing simple parts on their sides and putting them together with pipes and so on, is somehow the UNIX way and is attracting (too lazy to find the quote). However as he demonstrates later, distributed computing is not easy, and there's also the boundray crossing issue. I guess he has a point when he says this is a problem for performance and the difficulty on designing the system... So if performance is what you indeed expect from a kernel, then you must stop dreaming of a clean-centralized good software architecture like those we have for our high oo-oriented software.

But the truth is that, although developing a monolithic kernel is an easier task to do from scratch than a microkernel, I guess the entry ticket (learning curve) for a monolithic kernel developes is more expensive. The main reason being, "things ARE NOT separated". Anyone, anywhere in the kernel could be modifying the state of that thing, for non obvious reason, even if there's a comment that says "please don't do that" or it shoulld not be the case etc.... Microkernel can obviouisly provide some kind of protection and introspections to these things, but have always hurt performances to do so.

Now it has everything to do on what you expect. Linux has many many many developpers and obviously can afford having a monolithic design that changes every now and then and you may prefer a kernel that goes fast than one whose code is clearn, well organized and easy to read. But the corrolary of that observation is that for the same reasons, grep, cat, cut, find, sort, or whatever unix tools you use with pipes and redirection are similarly a cleaner but YET INEFFICIANT design. However, it's been proven (with time) to be a good idea..

I think things that are "low level" will be bound to have a poor spagehtti software architecture because performance matters and the code is smaller.. but the higher level you go, the less performance matters, and the more code maintenance and evolutivity matters... Everything is a tradeof: good design practice depends on the type of problems your software tackles.

That said, it does not mean no progress can be made in kernel developments. Linux already uses a somewhat different C language (gcc additions). Maybe some issues concerning "cleanliness" could be addressed with language enforced statements rather than comments in the code and willingness of other developpers not to do crap. Some sort of oo oriented but fairly low level language might or might not help. No C++ flame war, please... maybe it could be a totally new language created for the purpose. I know the I/O kit in XNU (macos x kernel) is a somewhate "light" version of C++. But it lets you have "private" variables (that a memory overrun could kill anyway) and some kind of class arborescence, which for drivers, provide some flexibility and make it possible for a developper to write some driver by combining via inheritance and composition existing components, rather than copy/paste the code of a similar stuff and re-write from scractch.. that said, i don't like the copy/paste method "a priori", but arguablty it could have better performances :)

Re:Code talks (0)

Anonymous Coward | more than 8 years ago | (#15299295)

If you're going to twist words so hard that Windows is included as a hybrid, then Linux itself becomes hybrid. It has filesystems in userspace (FUSE), device drivers in userspace (anything that talks via USB), device management in userspace (udev) a GUI in userspace (X11, which is more microkernel-ish than Windows). Even with all these, it is a monolithic kernel.

And it's pretty easy to see how popular NetWare, ReactOS, and BeOS are at the moment. Even the page you linked to states that XNU (the core of Mac OS X) is not a microkernel, but a hybrid. There are no popular microkernel-based systems.

Some things simply cannot be easily broken down. Kernels are one of these. As Linux is split up into more userspace programs, a limit will be reached when such splitting simply does not become possible. And Linux will still be considered a macrokernel.

Re:Code talks (0)

Anonymous Coward | more than 8 years ago | (#15299296)

Uh, no offense but I don't think OS X counts since it's whole kernel runs as single mach process...

Re:Code talks (5, Interesting)

Stephen Williams (23750) | more than 8 years ago | (#15299299)

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

Not necessarily. Despite being a monolithic design, Linux is pretty modular. Device drivers, filesystems, network add-ons etc. are separate enough from the core of the kernel that they don't even need to be statically linked into it, but can be loaded as modules into a running kernel, as I'm sure you know.

It's not a microkernel approach because all the modules are loaded into the kernel's address space. They're bits of extra functionality that are dynamically grafted to the monolithic kernel image, so to speak. Nevertheless, it's still a modular approach to kernel design.

-Stephen

Re:Code talks (1)

earnest murderer (888716) | more than 8 years ago | (#15299348)

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 or a hybrid kernel.

Exactly, Linus doesn't know what he's talking about. He should know better than to be posing as some kind of credible source. Someone should write him an e-mail and let him know that he should have defered to someone more knowledgeable.

it could very well be true. I don't know enough to comment.

Sure enough.

Re:Code talks (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15299248)

Three letters: Q N X.

Small, fast, real-time. http://en.wikipedia.org/wiki/QNX [wikipedia.org]

Say what?! (0, Redundant)

Inoshiro (71693) | more than 8 years ago | (#15299252)

"All popular OS kernels are monolithic."

I must've skipped into a parallel world where Windows XP, Windows 2000, and Windows 2003 were not somehow based on the microkernel NT Exective.

Windows is monolithic (2, Informative)

microbee (682094) | more than 8 years ago | (#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.

Re:Windows is monolithic (2, Funny)

Mostly a lurker (634878) | more than 8 years ago | (#15299291)

So, are Microsoft's problems with Windows Vista because it is based on a micro, a monolithic, or a hybrid kernel?

Re:Windows is monolithic (1)

jcr (53032) | more than 8 years ago | (#15299319)

Microsoft's problems with Vista are management problems. They're completely orthogonal to the style of their kernel.

-jcr

Re:Windows is monolithic (4, Funny)

Vo0k (760020) | more than 8 years ago | (#15299358)

Because it's based on a huge, monstrous monolithic microkernel.

Re:Windows is monolithic (1)

AnalystX (633807) | more than 8 years ago | (#15299320)

http://www.microsoft.com/library/media/1033/techne t/images/archive/ntwrkstn/evaluate/featfunc/f0af_b ig.gif [microsoft.com]

That's funny. Microsoft has one of it's layers labeled "Microkernel." I guess it's a hybrid OS after all.

Re:Windows is monolithic (1)

microbee (682094) | more than 8 years ago | (#15299335)

Not sure what that "microkernel" piece actually means, but it's absolutely a picture of monolithic kernel. All those I/O manager, process manager, virtual memory manager, etc, are all running in one piece in the kernel.

Re:Windows is monolithic (2, Informative)

AnalystX (633807) | more than 8 years ago | (#15299386)

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.

New definition of "microkernel" (1)

Schraegstrichpunkt (931443) | more than 8 years ago | (#15299439)

I propose a new definition of "microkernel": If it's too big to fit in your CPU cache, or it has any sort of "network transparency" crap built into it, then it's monolithic kernel.

Re:Say what?! (1)

teknomage1 (854522) | more than 8 years ago | (#15299315)

More likely you think you're living in a paralel world where MS lived up to it's marketing hype that NT would be a microkernel.

Re:Code talks (3, Insightful)

SanityInAnarchy (655584) | more than 8 years ago | (#15299287)

The whole discussion of micro-kernel vs monolithic kernel is totally pointless. All popular OS kernels are monolithic.

The whole discussion of Windows vs anything else is totally pointless. All popular OSes are Windows.

Linus is a pragmatist. He didn't write Linux for academic purpose. He wanted it to work.

That's true, and that's a good point. However, it's much easier to start a project if you already have some good people, even if the code is entirely from scratch. Therefore, making the point in a place like the kernel development lists is a good idea, because that's a good place to recruit people.

Certainly in the case of OSes, there really isn't much of an opportunity for something like Linux to emerge from one person's efforts. As far as I can tell, Linux originally worked because enough people were interested in helping him early on in a hobby, doing things like sending him an actual copy of the POSIX specs, and he was mostly able to get it to where it actually duplicated Minix's functionality, and exceeded it in some cases.

In fact, there was such a shortage of good OSes for this machine that really, Linux succeeded because it wasn't Minix and wasn't DOS. In fact, one has to wonder -- could an open Minix have done what Linux did? It's possible that, given all the programmers who eventually decided to work on Linux, the problems with microkernels could've been solved. Similarly, if all the programmers working on Linux suddenly decided to do a microkernel, it would succeed and it would replace Linux.

But, that isn't going to happen. Not all at once, and probably not ever, unless it can be done incrementally.

Re:Code talks (1)

strider44 (650833) | more than 8 years ago | (#15299456)

The whole discussion of Windows vs anything else is totally pointless. All popular OSes are Windows.

I like it how millions upon millions of installations isn't counted as "popular".

Re:Code talks (-1, Offtopic)

Detritus (11846) | more than 8 years ago | (#15299288)

Shit is the breakfast of champions. 7 trillion flies can't be wrong.

Popularity does not imply quality or elegance. Debating the merits of Windows vs. Linux vs. BSD is like holding a beauty contest at a leper colony.

Re:Code talks (0)

Anonymous Coward | more than 8 years ago | (#15299450)

hahaha. i must remember that one..!

Re:Code talks -- but some code flies! (1)

drgonzo59 (747139) | more than 8 years ago | (#15299380)

So then let me ask you this: Would you get on a plane that is flown by Linus' latest 2.6 monolithic kernel? Could it be because a bug in one of the hundreds of drivers might lock up the system and you'll crash and die?

Most of the critical RT operating systems will have some kind of a ukernel architecture. velOSity is one such ukernel, it is used by the INTEGRITY OS made by Green Hills. The next time you fly on the plane it will probably be a ukernel that will make sure you land safely, not a monolithic blob that makes it impossible to mathematically prove security policies, which you would want in real important situations.

Linus will obviously defend his architecture choice. I don't see him all of the sudden deciding that ukernels are in any way "better", it is like having Microsoft opening the source code for Windows.

Back in the day the main argument was performance -- the cost of context switches. Today with machines that are probably 10x or 20x faster, context switches won't be such a big hit. So Linus had to come up with some other explanation -- "hard to code". The argument that there are no "real" OSes with microkernels today doesn't hold either.

Linus is a pragmatist. He didn't write Linux for academic purpose. He wanted it to work. I don't know but an OS that flies thousands of people over the Atlantic every day without a crash is called a "working" OS in my book. And that OS is probably a ukernel.

Re:Code talks (1)

Net_Wakker (576655) | more than 8 years ago | (#15299389)

Go check http://www.qnx.com/ [qnx.com] to see a true microkernelarchitecture. Very nice, very fast RTOS.

Crap (0)

Anonymous Coward | more than 8 years ago | (#15299177)

10 messages posted and TFA is already /.ed

Now that would be nice (2, Funny)

Bombula (670389) | more than 8 years ago | (#15299190)

can the callee look at and change the callers state as if it were its own

Any chance we could do this with my long distance phone service?

Re:Now that would be nice (1)

Bombula (670389) | more than 8 years ago | (#15299370)

What ogre modded this down? It's funny, people. Laugh.

slashdotted, pastebin copy of interview (5, Informative)

gigel (817544) | more than 8 years ago | (#15299191)

comments i liked (3, Insightful)

bariswheel (854806) | more than 8 years ago | (#15299201)

"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. He goes on to say, "It's ludicrous how microkernel proponents claim that their system is "simpler" than a traditional kernel. It's not. It's much much more complicated, exactly because of the barriers that it has raised between data structures." He states that the most fundamental issue is the sharing of 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?"

A lot of work (1)

El_Muerte_TDS (592157) | more than 8 years ago | (#15299204)

I'm pretty sure it's a shit load of work to port the linux kernel to become a micro kernel. Anyway got the spare time to do that?
PS, besides porting all parts of the kernel you first need to redesign the kernel so it can cope with the micro kernel idea (and structural limitations).

As soon as GNU Hurd is mature we'll have a drop-in replacement (right?).

Microkernels and the future of hardware (4, Insightful)

SigNick (670060) | more than 8 years ago | (#15299262)

I think Linus hit the spot by pointing out that the future of home computing is going to to focus on parallel processing - it's 2006 and all my computers, including my LAPTOP, are dual-processor systems.

By 2010 I suspect at least desktops are 4-CPU systems and as the numbers of cores increase one of the large drawbacks of microkernels raises it's ugly head: microkernels turn simple locking algorithms into distributed computing-style algorithms.

Every game developer tells us how difficult it is to write multi-threaded code for even our monolithic operating systems (Windows, Linux, OSX). In microkernels you constantly have to worry how to share data with other threads as you can't trust them to give even correct pointers! If you would explicitly trust them, then a single failure at any driver or module would bring down the whole system - just like in monolithic kernels but with a performance penalty that scales nicely with the number of cores. What's even worse is that at a multi-core environment you'll have to be very, very careful when designing and implementing the distribution algorithms or a simple user-space program could easily crash the system or gain superuser privileges.

Re:Microkernels and the future of hardware (4, Interesting)

ingenthr (34535) | more than 8 years ago | (#15299324)

Don't take C's poor support for threading and tools to build/debug threaded code to mean that writing threaded code isn't possible. Other platforms and languages have taken threads to great extremes for many years, and I'm not necessarily referring to anything Unix (or from Sun).

This reminds me of the story (but I don't know how true it is) that in the early days of Fortran, the quicksort algorithm was widely understood but considered to be too complicated to implement. Now 2nd year computer science students implement it as a homework project. Threads could be considered similar. Anyone who has written a servlet is implicitly writing multithreaded code and you can very easily/quickly write reliable and safe threaded code in a number of modern languages without having to get into the details C forces you into. It's the mix of pass-by-reference and pass-by-value with only a bit of syntactical sugar that creates the problems, not the concepts of parallelism.

On the other hand, I agree with you that we'll see increased parallelism driving increases in computing capabilities in the coming years. It was mathematically proven some time ago, but Amdahl's law is now officially giving way to Gustafson's law [wikipedia.org] (more on John Gustafson here [sun.com] ). Since software codes are sufficiently complex these days (even the most simple of modern programs can make use of parallelism-- just think of anything that touches a network), it's those platforms that exploit this feature which stand to deliver the best benefits to it's users.

Linus not that far for true... (3, Interesting)

Anonymous Coward | more than 8 years ago | (#15299285)

Hi folks,

        I worked two years for a society that was developing its own micro-kernel system, for embedded targets. I was involved in system programing and adaptation of the whole compiler tools, based on GCC chain.
        Linus is right: basic problem is address space sharing, and if you want to implement memory protection, you rapidly falls into address space fragmentation problem.
        The main advantage of the system I worked on wasn't really its micro-kernel architecture, but the fact that its design allowed to suppress most of glue code that is needed between a C++ program and a more classic system.
        In my opinion, micro-kernel architecture has the same advantage and drawbacks that so-called "object-oriented" programing scheme : it is somewhat intellectually seducive for presentations but it is just a tool.
        It would certainly be intersting for Linux to provide the dynamic link management specificities of a micro-kernel system, for instance to allow someone to quickly modify IP stack for its own purpose, but should the whole system being design that way ? I am not sure.
        If you want to have an idea of the problem encountered with programing for these systems, one can look at the history of the AmigaOS, which have a design very close to a micro-kernel one.

This really wouldn't be an argument (2, Funny)

Anonymous Coward | more than 8 years ago | (#15299289)


If the Linux kernel had have been coded using Forth.

Just saying.

Re:This really wouldn't be an argument (1)

Vo0k (760020) | more than 8 years ago | (#15299318)

yup. no kernel - no argument.

Re:This really wouldn't be an argument (1)

PietjeJantje (917584) | more than 8 years ago | (#15299405)

OMG as a Windows freak I'd settle for the "monolithic" kernel, why settle for anything sounding smaller?
This all sounds very interesting, when is Linux for Windows coming out and will I be able to patch it using Visual Basic? I'd like to add some cool skins and then submit it to the project.

in other news (3, Insightful)

convolvatron (176505) | more than 8 years ago | (#15299307)

abstraction and state isolation considered harmful

Re:in other news (1)

I Like Pudding (323363) | more than 8 years ago | (#15299395)

Nice troll. Kernel programming is not program programming. It is programming a program to run programs. The cost of additional complexity in a kernel is a couple orders of magnitude higher than your run of the mill php app. What is good for the goose is not necessarily good for the kernel.

Entire comment (5, Insightful)

Futurepower(R) (558542) | more than 8 years ago | (#15299351)



Name: Linus Torvalds (torvalds AT osdl.org) 5/9/06

___________________

_Arthur (Arthur_ AT sympatico.ca) on 5/9/06 wrote:

I found that distinction between microkernels and "monolithic" kernels useful: With microkernels, when you call a system service, a "message" is generated to be handled by the kernel *task*, to be dispatched to the proper handler (task). There is likely to be at least 2 levels of task-switching (and ring-level switching) in a microkernel call.

___________________


I don't think you should focus on implementation details.

For example, the task-switching could be basically hidden by hardware, and a "ukernel task switch" is not necessarily the same as a traditional task switch, because you may have things - hardware or software conventions - that basically might turn it into something that acts more like a normal subroutine call.

To make a stupid analogy: a function call is certainly "more expensive" than a straight jump (because the function call implies the setup for returning, and the return itself). But you can optimize certain function calls into plain jumps - and it's such a common optimization that it has a name of its own ("tailcall conversion").

In a similar manner, those task switches for the system call have very specific semantics, so it's possible to do them as less than "real" task-switches.

So I wouldn't focus on them, since they aren't necessarily even the biggest performance problem of an ukernel.

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

Even for a monolithic kernel, the answer is a very emphatic no when you cross from user space into kernel space. Obviously the user space program cannot change kernel state, but it is equally true that the kernel cannot just consider user space to be equivalent to its own data structures (it might use the exact same physical instructions, but it cannot trust the user pointers, which means that in practice, they are totally different things from kernel pointers).

That's another example of where "implementation" doesn't much matter, this time in the reverse sense. When a kernel accesses user space, the actual implementation of that - depending on hw concepts and implementation - may be exactly the same as when it accesses its own data structures: a normal "load" or "store". But despite that identical low-level implementation, there are high-level issues that radically differ.

And that separation of "access space" is a really big deal. I say "access space", because it really is something conceptually different from "address space". The two parts may even "share" the address space (in a monolithic kernel they normally do), and that has huge advantages (no TLB issues etc), but there are issues that means that you end up having protection differences or simply semantic differences between the accesses.

(Where one common example of "semantic" difference might be that one "access space" might take a page fault, while another one is guaranteed to be pinned down - this has some really huge issues for locking around the access, and for dead-lock avoidance etc etc).

So in a traditional kernel, you usually would share the address space, but you'd have protection issues and some semantic differences that mean that the kernel and user space can't access each other freely. And that makes for some really big issues, but a traditional kernel very much tries to minimize them. And most importantly, a traditional kernel shares the access space across all the basic system calls, so that user/kernel difference is the only access space boundary.

Now, the real problem with split access spaces is not the performance issue (which does exist), but the much higher complexity issue. It's ludicrous how micro- kernel proponents claim that their system is "simpler" than a traditional kernel. It's not. It's much much more complicated, exactly because of the barriers that it has raised between data structures.

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. And the argument that you can "just reload" a failed service and not take the whole system down is equally flawed.

Anybody who has ever done distributed programming should know by now that when one node goes down, often the rest comes down too. It's not always true (but neither is it always true that a crash in a kernel driver would bring the whole system down for a monolithic kernel), but it's true enough if there is any kind of mutual dependencies, and coherency issues.

And in an operating system, there are damn few things that don't have coherency issues. If there weren't any coherency issues, it wouldn't be in the kernel in the first place!

(In contrast, if you do distributed physics calculations, and one node goes down, you can usually just re-assign another node to do the same calculation over again from the beginning. That is not true if you have a really distributed system and you didn't even know where the data was coming from or where it was going).

As to the whole "hybrid kernel" thing - it's just marketing. It's "oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let's use a cool name and try to imply that it has all the PR advantages that that other system has"

Linus

Tanenbaum on microkernels (4, Informative)

Anonymous MadCoe (613739) | more than 8 years ago | (#15299354)

Here is some good readign amterial, maybe people should read and _understand_ it before posting on the subject..

This does not mean you have to agree with the guy.

http://www.computer.org/portal/site/computer/menui tem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pN ame=computer_level1_article&TheCat=1005&path=compu ter/homepage/0506&file=cover1.xml&xsl=article.xsl& [computer.org]

http://vig.prenhall.com/catalog/academic/product/0 ,1144,0131429388,00.html [prenhall.com]

I would love to hear about an example (1)

Paul Crowley (837) | more than 8 years ago | (#15299396)

IANAKH (I am not a kernel hacker)

I'd love to hear some examples. It would be nice to see an example where something that's easy in a monolithic kernel is difficult in a microkernel. See, I imagine this bunch of distinct services all happily calling each other for what they need; I'd like to know more about how the need for complex distributed algorithms arises.

I want a microkernel implementation (1)

BumpyCarrot (775949) | more than 8 years ago | (#15299418)

But I also want the Loch Ness Monster to exist and assist me in my conquest of Mars.

Quite simply, just look at HURD. Didn't they finish the initial work involved in porting to the L4 kernel before starting to pursue the Coyotos kernel?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?