Talk:Microkernel/Archive 1

Archive 1

Online reference

I STILL don't know which template to invoke, so I apologize in advance. This article was directly quoted in another article at the following web page: http://lowendmac.com/musings/05/1214.html --JohnDBuell 17:06, 15 December 2005 (UTC)

Quote

Is this quote true?

"However, the total amount of effort in maintaining any kernel code is sufficiently high that the improvements in maintainablity generated by a microkernel architecture are marginal."

It seems to me that maintainability trades off with performance. Maintainability does not trade with the microkernel design, unless you're trying to pretzel the code into giving unnaturally good performance.

That quote seems a little NPOV, especially considering I run an OS using the Mach microkernel -- Darwin. While I know Darwin is not pure microkernel (other parts of the kernel share address space with Mach), it does not seem to have an adverse effect on kernel maintainability.

(I would have to say, "no" regarding that quote, having used QNX and written drivers for it. The QNX kernel changes very little from year to year, while new drivers and services are added regularly. For example, FireWire and USB support were added with no kernel changes.

I've recently updated the QNX article to add some material on QNX's technology, which has some subtle design features that have escaped the academic microkernel authors. One thing that's very clear about microkernels - the initial design really matters. If you get that wrong, the project never recovers. If you get it right, you don't have to change the kernel much thereafter. --Nagle 06:45, 6 March 2006 (UTC))

Loose references to Mach in the article

Hi Guys, this is my first comment in such a discussion list. So, sorry if i did it wrong.

I've noticed that the article has some loose references to the Mach system. Later I've discovered that the information under the article about Mach was meged to the Microkernel one. So, probably those references remained out of context.

Regards,

Giulliano

I tried getting them all when I merged, but I'm sure I missed a few. Thanks. --71.241.136.108 07:04, 22 March 2006 (UTC)

The "Microkernel servers" section needs a rewrite in more generic terms. Now the references to Mach are gone, but the Mach approach remains, as if the only one. The description of "ports" is entirely Mach-specific. Not all microkernels do their interprocess communication through the file system; many don't even have a file system inside the kernel. --Nagle 07:55, 22 March 2006 (UTC)

Yes, that section does need that work. In my move, I assumed the introductory material on Mach was the paradigm for all microkernels. --71.241.136.108 16:19, 22 March 2006 (UTC)

Thanks. We may need more "compare and contrast" material. Some elements are common to all microkernels, and some aren't. Then there's the terminology problem. As I mentioned above under "Hypervisors", the same concepts appear in different systems under totally different names. A good goal for Wikipedia articles in areas like that is to talk about the concepts in a unified way, while pointing out the differences between implementations. That's useful to readers. It's tough getting such an overview from vendor literature. --Nagle 18:22, 22 March 2006 (UTC)

I agree. I hope the article is in a form that people would be willing and could easily contribute such material. I don't even think the "Dinosaur book" has good information on microkernels, and there are no textbooks on microkernels. --71.241.136.108 20:27, 22 March 2006 (UTC)

There's Tanenbaum and Woodhull's "Minix 3" book. But really, the best available material on how to design a good microkernel is the documentation for QNX. That's not widely distributed, and it's not heavy on the theory. Getting scheduler and interprocess communication right is absolutely critical to performance. Most of the academic microkernels don't get it right, but QNX does, which is why QNX is used successfully in time-critical real-time systems. Yet about the only reference to this I can give is 'install QNX, start up "help", and look under "synchronous message passing".' I've written a little on this in the QNX article. --Nagle 06:09, 25 March 2006 (UTC)

Kernel code size

For example Linux 2.6 contains about 2.5 million lines of source code in the kernel (of about 30 million in total), while Windows XP is estimated at twice that.

What about ReactOS? It would be interesting to compare different implementations of the NT kernel. - Sikon 15:57, 28 August 2006 (UTC)

Edits by User:Uncle G

Uncle G (talk · contribs) has been adding {{citeneeded}} and {{original research}} tags all over the Microkernel article. The first time he did this, I added cites for most of his tags, and removed the ones where you could find a cite by following nearby links. Then he added even more such tags. This I reverted as vandalism. What do others think? Do we need still more citations? --John Nagle 15:35, 11 July 2006 (UTC)

• Untrue. You added no citations. You simply removed the tags with edit summaries saying that you had added citations when in fact you had not. Here is one such edit where you did this. This article requires citations. It is not exempt from the Wikipedia:Verifiability and Wikipedia:No original research policies any more than any other article is. There is a lot of analysis and discussion in this article that needs to be sourced. That you consider the requesting of cited sources, on an article that cited no sources at all, to be "vandalism" indicates that you have completely the wrong idea. Please familiarize yourself with the policies and with Wikipedia:Cite sources. Uncle G 16:41, 11 July 2006 (UTC)

Even in the diff you quote, I added two citations, as the record shows. I also removed some material there for which I couldn't immediate find a citation. This explicitly answered all your complaints, as the diff makes clear. The article as a whole has dozens of citations. I'm not happy with the "security" section, which does need cites and a rewrite, so I left your tag on that one.

As a specific example of improper use of a {{citationneeded}}, see your edit to the section on "Kernel bloat". The actual numbers on the sizes of various operating systems are given in the article Source lines of code, in a table, and there's a source for that table (Tenenbaum's book) in that article. Even after I'd added that citation, you put a {{citationneeded}} tag back in. You need to follow the links and read the linked articles before inserting tags demanding citations. Thanks. --John Nagle 17:09, 11 July 2006 (UTC)

The references section is still a mess because of the vandalism, but we'll deal with that. --John Nagle 20:42, 11 July 2006 (UTC)

Still, I agree with John Nagle that {{original research}} is unwarranted: there are piles of literature on these topics out there. Therefore I am replacing the last two such occurences (in sections Performance and Security) with {{citations needed}}. DomQ 09:52, 9 January 2007 (UTC)

Advantages/disadvantage contradiction?

The article says:

However, part of the system state is lost with the failing server, and it is generally difficult to continue execution of applications, or even of other servers with a fresh copy. For example, if a server responsible for TCP/IP connections is restarted, applications could be told the connection was "lost" and reconnect to the new instance of the server.

That sounds like a contradiction to me. Can anyone explain/correct? -- Beland 19:19, 21 March 2007 (UTC)

Article perspective

IMHO, the article seems to be written from a very anti-MK perspective. The system is more stable "in theory" (but not, presumably, in practice), the file abstraction does not work with restartable servers (so therefore having separate servers must be the wrong approach (and getting rid of an abstraction that doesn't work is out of the question)), and you have to use (obviously horribly complicated) database techniques, etc. Not to mention that microkernels "generally underperform" and even "sometimes dramatically". At the least, I think whoever makes that sort of claims should be able to back them up. Really the only thing I would keep is the list of MK-based operating systems. The rest should be wiped out, and the article restarted. But please keep the article, maybe downgrade to a stub, and save the trouble of undeleting it later. magetoo 22:04, 20 November 2005 (UTC)

I'm going to try to rewrite this, a little at a time. I agree it needs work. Please watch and let me know what you think. --Nagle 03:15, 7 March 2006 (UTC)

The original discussion in the article probably deserves being preserved and kept alonside the helpful technical information you're contributing. Note the article's condition from 20 Noveember, 2005 is much different than now. --71.161.197.151 03:48, 7 March 2006 (UTC)

I've done some rework; about 2/3 of the original material is still there, although I've added subheads and moved it around. I took out the section on "UNIX programs being constructed out of little components with pipes", which really isn't relevant to the microkernel issue. I left in the negative comments on microkernel performance; although I don't generally agree with them, they are conventional wisdom.

Is there anything from November 2005 that needs to come back?

What I'm trying to do here, as someone who's worked with and on microkernels, is to clarify how we got to where we are, why microkernels have problems, and how those problems can be solved.

The style now seems a little choppy. --Nagle 05:02, 7 March 2006 (UTC)

The Unix commentary was useful to explaining the ideological (as opposed to technical) motivations for microkernels. Its inclusion may have been a result of the article's Mach-bias. I'm going to bring back some of it. --65.19.87.53 05:09, 16 March 2006 (UTC)

Today's rearrangement isn't bad, but now the first paragraph of "Background" needs work. A good introductory background paragraph is needed.

The UNIX pipe issue is interesting. Actually, UNIX pipes are a good example of how not to do interprocess communication. You can make one-way pipelines with them, but that's about it. They're badly matched to client-server communication, because they're unidirectional. Classic microkernel design mistake: "What the application needs is a subroutine call. What the operating system usually provides is an I/O operation". The single most important feature of a microkernel is a good mechanism for local client/server communication.

Pipes in UNIX work the way they do because, in PDP-11 UNIX, often only one program could fit in the machine at a time, and pipes were real files, 4K long, treated as circular buffers. When you only have 256K of memory on the machine, you have to make some compromises.

Have another go at "Background", please. If you're stuck after a few days, I'll take a look at it again. --Nagle 06:27, 16 March 2006 (UTC)

Minor revert to change QNX-related interprocess communication note from "performing quite favorably" back to "incurring some extra copying costs", for a more Wikipedia:Neutral point of view. Personally, as a QNX programmer, I'd agree with "performing quite favorably", but that's an opinion. --Nagle 08:42, 17 March 2006 (UTC)

The performance anti-bias has been here for a long time now, I think it ought to be rectified. As was stated, the article seems very anti-MK biased, while MKs like coyotos are addressing many of the IPC-related performance concerns that people have been fighting with. Also, as a side note, the note in the QNX article about QNX 'proving that microkernels will always be outperformed by monokernels' needs to be removed. QNX does implement good synchronous IPC for real-time applications, but justifying any of this would require a treatment on scheduling strategies. Also, while QNX does strict copying for IPC, L4 and lately coyotos (which adopted many L4 strategies for performance) use either registers or in the case of coyotos a sort of 'dedicated sharing buffer' whose ownership is passed back and forth, however only doing this when a capability is called which requires I/O. In fact, I think most of the references to mach (which is widely known in the MK community for its 'let's write in everything for everyone' approach is notorious for security holes and even more widely known for its award winning lack of performance) with more information on capability based MKs and L4. Caps/L4 represent a more accurate view of MK paradigms and the advantages of microkernels than does mach. Mach was designed to be replace monokernels in systems without modification, and as such is practically a monokernel itself. Yes, it deserves mentioning as it is an example of a microkernel, however because it strays so far from MK theory it should NOT be the prime example. Final note, singularity may merit a mention, however it uses self-modifying code which greatly limits its portability (pipelining issues with SMC, and SMC/executable data structures are pretty worthless on RISC), not to mention the fact that as far as I know, MS never really did anything with it. --24.98.124.237 11:55, 9 December 2006 (UTC)Haplo

Hi, guys. A lot has changed since November 2005, it seems. The fact that my own comments don't even make any sense anymore proves that, I think. I just want to thank you all for improving the article to the point where it's actually pretty interesting to read. Thanks! -- magetoo 15:24, 21 January 2007 (UTC)

As said by 24.98.124.237 on December 06, there's still need to discuss MK based on capability-based addressing.--BMF81 13:02, 16 July 2007 (UTC)

Relationship with hypervisors

This article and the hypervisor article ought to say more about each other's subjects. IBM's VM and Xen are really microkernels. (Not sure about Parallels Workstation). Also, what Xen calls "paravirtualization", Parallels calls a "hypercall", and IBM VM calls a "DIAGNOSE code" are all really the same thing, a system call to the operating system below.

Nope, neither VM nor Xen are microkernels, they are hypervisors. And para-virtualization isn't the same as a hypercall (although it tends to employ hypercalls). I have added a brief explanation of the similarities with hypervisors at the beginning (and will remove the nonsense about KeyKOS (neither widely deployed nor ever to my knowledge on IBM mainframes) and VM (not a microkernel). Heiser 01:56, 6 August 2007 (UTC)

Actually, KeyKOS did run on IBM mainframes (the 370 family).

Drivers

I've moved this material from Performance (where it didn't fit at all) into a separate section, also removed a lot of irrelevant material. I'm highly sceptical about the claim that MTS had user-level drivers, if someone really thinks this is true they should provide a reference. (The web page linked from the MTS article contains no indication of this. And it's credibility isn't very high anyway, given the blatantly incorrect claim that this was the first operating virtual-memory system.)

That dubious claim about user-level drivers in MTS has been tagged for two weeks without a response. Unless someone comes up with some indication of its veracity, I'll remove it, as I strongly suspect that it is wrong. Heiser 04:44, 25 August 2007 (UTC)

Before deleting "irrelevant material", it is helpful to read up on the subject. I've cited the paper on the Michigan Terminal System from the 1972 Spring Joint Computer Conference. "Using this technique it was possible to completely rewrite and install the DSR (Device Service Routine) for magnetic tapes without any time on a dedicated machine; all development was done under regular production MTS without any adverse effects on the rest of the system." I actually have a hard copy of those proceedings, but you could have found that with Google. The key to this was that IBM I/O channels supported the concept of giving an application restricted control of a peripheral. For example, a program might be limited to certain disk cylinders. --John Nagle 07:21, 25 August 2007 (UTC)

All I asked was for backing up that claim (eg the MTS wikipedia page contains nothing about it). Thanks for adding the reference. However, it isn't fair to say that it could be found with Google. The title yes, but not the actual paper -- in fact, I looked around a fair bit and couldn't find it. Probably requires a physical trip to the library. The 1975 paper in Proceedings of the IEEE is easier to obtain, but doesn't explicitly state that drivers are user level (although reading it one suspects that they are). Anyway, thanks for adding this useful info. Heiser 06:42, 26 August 2007 (UTC)

Inter-process communication

I've re-written the last paragraph, as it didn't make too much sense. However, I feel that the references to UNIX sockets and POSIX IPC are completely irrelevant to this page and should be removed. Heiser 01:18, 6 August 2007 (UTC)

I've revised the sync/async discussion and removed the irrelevant Unix/Posix stuff Heiser 17:10, 5 October 2007 (UTC)

Cleanup required?

The article was tagged with "cleanup" since July last year. It has undergone massive revisions since. I have now removed the cleanup tag. If someone thinks that further cleanup is required I suggest they are more specific. Heiser 00:58, 10 October 2007 (UTC)

What's "dubious"

I'm removing the "dubious" tag in the performance section, as I don't see what the issue is with this perfectly obvious statement. Heiser (talk) 22:03, 9 April 2008 (UTC)

For one thing, the actual paper cited [1] doesn't say that. In fact, in section 2.1, the cited paper says that "grafting" extra functionality onto a monolithic kernel can be 6 to 80 times worse than L4 interprocess commmunication. --John Nagle (talk) 00:55, 10 April 2008 (UTC)

For one thing, the paper you link isn't the paper cited in that paragraph of the article. What you linked is a paper from HotOS'97, the one cited is from the Sep'96 issue of CACM.

That paper doesn't explicitly state it either, for the simple reason that it's totally obvious. The explanation is actually given in the article: two mode switches (monolithic kernel) vs four mode switches and two context switches. 2*A is always less than 4*A+2*B for positive A, B. It's so obvious that even Tanenbaum (Modern OS, 3rd ed) doesn't bother to state it explicitly. The closest I could find is the sentence "the main problem with this approach, and with microkernels in general, is the perfromance hit all the extra context switches cause."

The other part is also obvious: the kernel always has access to all memory, hence a monolithic system can directly access client buffers. In a microkernel system, the client buffer is in a different address space than the server, and not normally accessible.

So I'm really at a loss what's "dubious" here. Whoever put that tag there in the first place obviously has problems with the most basic OS concepts.

Heiser (talk) 01:38, 14 April 2008 (UTC)

Motivations

I'm just doing some revision for an OS subject, and as far as accessibility goes, I found it hard to work out why you would chose to implement a system with microkernels. After reading through the article it seems that security is the main reason, but it took me a while to work that out and I can't tell if there are any other advantages. Motivations/advantages should at least be mentioned in the introduction and possibly have its own section if there are enough. —Preceding unsigned comment added by 128.250.99.115 (talk) 01:43, 11 June 2008 (UTC)

Performance Section

I've recently done some work on the IPC section which had the effect of getting rid of the tags there. Now the only tagged section is performance. However, this needs a more significant overhauld, essentially a re-write IMHO. It contains some outright nonsense. This is probably going to be a couple of full days' work, so I'm not sure when I'll find the time. However, before doing so I wanted to ensure I'm not stepping on someone's toes. -- Gernot Heiser 3:35, 6 June 2007 (UTC)

As threatened I've re-written the performance section. I removed a lot of irrelevant stuff (a microkernel has no device drivers and therefore doesn't page to disk, that's the job of user-level servers; the Unix pipe/sockets stuff is totally irrelevant, and that QNX choses simplicity over performance isn't relevant here either). Heiser 06:06, 6 August 2007 (UTC)

User 134.96.184.219 has (without discussion) replaced my careful "the proof is still in the pudding" statement by the unsubstantiated claim that QNX and Integrity are "high-performance multi-server systems". I'd like to see proof of that. Just because they are used commercially, doesn't mean they are "high-performance" (in the sense that they have essentially the same performance as single-server systems). Furthermore, those systems exhibit very coarse granularity (according to the "Servers" section, QNX as a server for "file systems"). Such coarse granularity proves very little.

To my knowledge of the literature, a demonstration of a high-performance multi-server system is still outstanding. The closest to my knowledge was the IBM SawMill project, but that died before delivering something that could be properly analysed. Heiser 09:45, 11 August 2007 (UTC)

I'm working now on multi-server (microkernel) OS, we're made some tests with it, on amd64 and I can told that context switch time is about 800 nanoseconds between threads within one task and about 1200 nanoseconds between tasks. (amd64 with 1.6Ghz). With appropriate design (for example, make a direct connection with drivers and filesystem) you can reject many context switches. Like example - in our project call like write, mmap (file) going directly to the filesystem, but open is coming via VFS service. Saying more - this time can be compared with time taken for hardware interaction. In addition we're should count time used for interaction within monolithic kernel - this is more than time used for context switch. I don't want to said that monolithic system performance the same in general case, I want to say that it will be the same in some cases. Anyway, microkernel and multi-server systems will be slowly sometimes, and will be the same sometimes - all depends on OS design. General problem is a TLB flush, and extra copying overhead - this can be partially solved. Well, if you interested in this discussion I can give you a link to our project (no, I don't want to write article about this project) (project is GPLed). Somn256 —Preceding undated comment was added at 12:03, 3 February 2009 (UTC).

POV on performance

I think the performance part is way too hard on microkernels. According to the section microkernels cannot be as fast as monolithic kernels, which is impossible to prove and considering that L4 doesn't have any way near the same problems of first generation microkernels at best doubtful. There are also some references to commercial operating system servers, which is somewhat off-topic (though related) in a microkernel article. —Preceding unsigned comment added by 83.89.16.99 (talk) 22:11, 24 March 2009 (UTC)

Maybe a bit harsh, but in line with the facts (and this is a microkernel fan speaking). I know of no serious published performance analysis that shows a multi-server microkernel-based system to perform at about the same level as a well-tuned monolithic system (correct me if I'm wrong). However, the successful deplopyment of OKL4 on (very performance-critical) mobile-phone handsets, and particularly the Motorola Evoke, are increasing evidence that good performance is achievable. heiser (talk) 04:37, 18 April 2009 (UTC)

The QNX people claim: Rigorous application of this rule to dividing the functionality between the kernel and external processes destroys the myth that a microkernel OS must incur higher runtime overhead than a monolithic kernel OS. Given the work done between context switches (implicit in a message pass), and the very quick context-switch times that result from the simplified kernel, the time spent performing context switches becomes "lost in the noise" of the work done to service the requests communicated by the message passing between the processes that make up the OS..[2]. The "microkernels have terrible overhead" story is mostly from Mach and its derivatives. (Mach started life as a BSD kernel, and trying to cut it down to a microkernel didn't work out very well.) Microkernels do more copying than monolithic kernels, but in modern CPUs, copying of recently-used data is cheap, because it's in cache. (Mach tried to avoid copying by moving blocks from one data space to another via the MMU. This is usually a lose on modern CPUs; for most copies the cache invalidation required creates more memory overhead than a straight copy would.) Current thinking on this subject seems to be that cache-awareness is more important than copy-avoidance.[3]. --John Nagle (talk) 16:17, 18 April 2009 (UTC)

Right, and I have written similar things myself. However, claims by microkernel vendors aren't the same as independent analysis. If you asked someone like Linus, he'd likely claim the exact opposite. Neither side has any hard facts to back up their claims AFAIK. The best that can probably be said at this time is that the increasing deployments seem to indicate that there isn't an inherent performance problem.

Btw, the Pingali et al presentation you linked to only confirms that a highly performance-tuned implementation needs to be adapted to the memory hierarchy. Note that their use of the term "kernel" doesn't refer to an OS kernel, but what numerical analysts call "math kernels", low-level subroutines, such as the Livermoore Fortran kernels or the Intel Math kernel library (MKL). — heiser (talk) 01:47, 19 April 2009 (UTC)

Image improvement

• The kernel should be at the bottom of the diagram, since it is the "low level" code.
• Shouldn't the thick white arrows should be labelled "IPC" as well? It's not clear what the dotted black arrow is supposed to connect, as one of its endpoints is floating between objects.
• There should be more than one server represented.
• It would be useful to put functional labels on the various boxes or subsections thereof, such as "web browser", "network device server", "filesystem server", "scheduler", "memory management", etc.
• Adding actual system hardware components as separate boxes "below" the kernel would illustrate that applications cannot talk directly to the hardware, but that their access is mediated by the servers and kernel.

-- Beland 20:36, 21 March 2007 (UTC)

I've replaced the image with a more suitable one, in line with rewriting the initial paragraphs. Heiser 23:41, 5 August 2007 (UTC)

I put the old image farther down in the article, simply because it matches the style of the images in articles such as Monolithic kernel and Exokernel. It would probably be good for them to be standardized- it's easy to tell the difference between structures when you're looking at the diagrams side by side. Ideally, the diagrams on the mentioned articles ought to be changed to look like the new one here, but it hasn't happened yet. 130.101.100.104 (talk) 15:35, 7 December 2007 (UTC)

I'm sorry, but this image adds nothing but confusion.

What is it supposed to show? My interpretation of this image (does anyone read it differently?) is that most data exchange is between the kernel and servers, and there is much less between the servers and "software". And what is "software" anyway? The kernel is software, so are "servers", so what does "software" refer to? Even if "software" was replaced by "applications", the image simply sends the wrong message.

In a reasonably-designed microkernel system (and this includes at least L4, QNX and Integrity) there is in fact very little data transfer between the kernel and anything else. The kernel for the most part simply acts as a message-passing engine, i.e. passes data between user-land address spaces. I suspect that the author of the image had the misconception that I/O happens inside the kernel (thus demonstrating that they don't understand microkernels). Microkernel I/O happens in user-level device drivers (which constitute a subset of the "servers").

The image is technically highly faulty and misleading and should be removed.

-- Heiser (talk) 07:36, 8 December 2007 (UTC)

I undid the change as per reasoning above. FWIW, the diagrams on the monolithic kernel and exokernel pages are pretty nonsensical too.

-- Heiser (talk) 05:06, 11 December 2007 (UTC)

I tried to work out those diagrams but i dont think three different diagrams helps. Mayby a joined diagram for all the pages like http://commons.wikimedia.org/wiki/Image:OS-structure2.svg But that is bretty bad currently broken by arrow stating and especially the so called hybrid kernel. If those would get fixed it would be nice. But isn't it hard to try to add a one monolith diagram to apply all monolith kernel's, one microkernel for all microkernels etc? Shouldn't those just tell what is the difference, so those would support the text? Not being 100% accurate for every kernel what we have? Golftheman (talk) 16:30, 20 July 2008 (UTC)

This diagram isn't an improvement either. For one, having the kernel on top and apps on the bottom is counter-intuitive and just the opposite of what everyone is used to (check any OS textbook). But worse, it obscures the basic information, which is that there isn't really a difference between apps and "OS servers". Calling the "servers" part of the OS may be a useful architectural abstraction, but it is neither necessary nor always useful. For example, in many embedded systems this distinction makes little sense. Heiser (talk) 07:23, 21 July 2008 (UTC)

Ok, now there's a new diagram, which adds a comparison to "hybrid kernels" (which really is just a PR term, so I'm uncertain of the benefits of this). However, that new diagram shows for each the microkernel and hybrid kernel stacks two different boxes labelled "application", one besides servers and one on top (implying some abstraction level). This doesn't make sense to me. Heiser (talk) 00:36, 22 July 2008 (UTC)

In what sense is 'hybrid kernel' a PR term? The two most popular 'hybrid kernels' are NT (Windows) and XNU (Mac OS), yet I can find no marketing material that describes either of them as such. One or both are, however, described as 'hybrid kernels' in various acadmic papers and presentations. This does not look to me like a 'PR term', but rather like a useful classification of kernels that are largely or even entirely monolithic, but the designs of which resemble or are derived from microkernels. This is certainly a useful classification, as many such operating systems exist.Linjesyv (talk) 11:39, 1 June 2009 (UTC)

Apparently I've catched a full bus... but I'm still not getting you people. Can anyone of you that really know about kernels, microkernels, monolithic kernels, exokernels and i-dont-know-what-more-kernels make a good diagram, that has no errors and it's clear for everybody and just put it on every single article that concern kernels?? I rather keep in all articles a wrong image, than in every single one that we go to find a different diagram, making everything so confusing. An encyclopedia that doesn't has basic standards it's a lame encyclopedia. So who is with me?? Khullah (talk) 06:40, 20 October 2008 (UTC)

The most likely explanation is that it ain't that easy. A diagram to represent such non-tangible things as software is always an abstraction. A diagram that compares two things focusses on the difference and abstracts other aspects. This implies that the more things you want to compare, the more difficult it gets to express this in a simple picture, because you can't abstract away enough detail.

The various concepts you want to compare in a single picture also focus on abstracting different things. For example, monolithic kernels and microkernels are abstractions focussing on OS structure, and that's what needs to happen in a diagrammatic representation, as is done in the present diagram. (It is also done in the one you tried to replace it with, but, unfortunately, incorrectly.) Exokernel is an abstraction that focusses on resource management, an exokernel is in fact quite similar to a hypervisor (but with a microkernel-ish minimality requirement).

You can draw a diagram that contrasts the difference between a microkernel and an exokernel, or one that contrasts an exokernel and a hypervisor, or a hypervisor and a microkernel, but a single diagram comparing everything is likely to be over-simplistic to the point of being useless, too complex to understand, or incorrect. Which doesn't mean one shouldn't try — I'd welcome it if someone comes up with a good one. I just don't have much hope. heiser (talk) 02:56, 25 October 2008 (UTC)

Ok Heiser, that was the kind of answer I wanted - from someone who knows about it. I can see now the situation, but I think there's a way. I agree that it is an abstraction, but that's what are diagrams for. And we can make them in every way we want.

What I am thinking is a diagram that has diagrams. The big diagram contains the different paradigms of the question - as you mentioned: OS structure, resource management, etc. Within the small diagrams would be the actual comparison of kernels. Do you think it would be possible? Khullah (talk) 03:17, 21 November 2008 (UTC)

Feel free to try. Let me only suggest that whatever you come up with you don't simply dump into the article but put it up for discussion. heiser (talk) 00:58, 22 November 2008 (UTC)

Ok, no problem. But first let's discuss what it will be. What paradigms are? What's to tell in each one?? Khullah (talk) 17:17, 6 December 2008 (UTC)

Where is OS9?

2 things I find a bit odd with the article, there is no mention of OS-9 the first microkernel OS that I saw actually working and very successful commercially as a RTOS and in the embedded field in the latter half of the 80s and early 90s, much more so than QNX in the 80 in particular, and in discussions on microkernels in the 80s usually the first product mentioned. Has the definition of the term changed so much that OS-9 is no longer considered one?

Secondly some of the paragraphs are wrong or misleading

"This growth continued for several decades, resulting in kernels with millions of lines of source code. As a result of this growth, kernels were more prone to bugs and became increasingly difficult to maintain."

Unix came into being in the early 70s, the first unixlike microkernel osses (os9 et al) hit the market at the end of that decade and the early 80s, hardly "decades". This and other parts of the page ignore that the less powerful computers of the day and other modularisation benefits apart from security had a big impact on the ideas and development of microkernels. reiknir (talk) 18:19, 21 August 2009 (UTC)

I don't know much about OS 9, but from the OS9 article it seems pretty obvious that it isn't a microkernel, but in fact a lean Unix-like system. For example, it seems that device drivers and file systems are part of the kernel, as in traditional Unix systems. According to the (generally-accpeted) definition of a microkernel given in the article, a microkernel doesn't run code in kernel mode that could run in user mode, and this would make OS 9 a monolithic kernel. heiser (talk) 07:18, 22 August 2009 (UTC)

Where on the OS9 page does it say that drivers are in the kernel? According to this article not even the I/O subsystem is in the kernel thus the drivers are definitely not on the kernel either, in fact the description of the Atomic kernel reads more like the nano and picokernel discussions I read about in the late 90s, and in fact this picture of a full v3 kernel (non atomic) describes a microkernel one with all IO separate from the kernel, so does the accompanying sales blurb. —Preceding unsigned comment added by Reiknir (talk • contribs) 20:49, 22 August 2009 (UTC)

OS - small programs called servers

"This allows the operating system to be built from a number of small programs called servers" We need a more details on this. Anyone? Amberved (talk) 15:42, 21 March 2008 (UTC)

Mayby this would help http://www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf The monolith kernel is the OS, but the microkernel structure is the OS where it is sliced to parts and those parts what are off from kernel, are running in protected mode in userland, and those are called as "OS servers" too. And applications connects to these servers what then does their task and delivers the job forward as needed. The OS services (or servers) does not need to be mistaken to application programs what are services or daemonds on software system, like INIT, Apache, Cron etc. 213.130.236.207 (talk) 18:14, 4 November 2008 (UTC)

There is few errors on the articcle. The supervisor mode is not same as kernel mode. The supervisor mode can be extended to user space as well. These OS server are running in the supervisor mode, but on the user space and not on the kernel space. The article error is it does false conclusion that supervisor mode and kernel space are same thing. It can be found on the link what is offered on top of this post. "We believe that many of these problems can be traced back to design decisions made 40 or 50 years ago. In particular, the early designers’ goal of putting speed above all else led to monolithic designs with the entire operating system running as a single binary program in kernel mode."This clearly says that the OS was designed originally to work as single binary on kernel mode. The OS is the monolithic kernel alone. Then later it is clearly said that new OS design was to build it up with microkernel and moved OS servers to user space what are all running in protected threads as supervisor mode. "In our view, the only way to improve operating system reliability is to get rid of the model of the operating system as one gigantic program running in kernel mode, with every line of code capable of compromising or bringing down the system. Nearly all the operating system functionality, and especially all the device drivers, have to be moved to user-mode processes, leaving only a tiny microkernel running in kernel mode." and "What is required is splitting the core of the operating system functionality—including the file system, process management, and graphics—into multiple processes, putting each device driver in a separate process, and very tightly controlling what each component can do." It is very clear that the microkernel is one part of the OS, while it and the servers together build up the OS, what is separeted to kernel and user space. While the original and still used monolithic OS is just one kernel in kernel space. Who should fix these errors on the article? 62.165.184.109 (talk) 14:41, 27 August 2009 (UTC)

Sorry, but you are mistaken. "supervisor" and "kernel" mode are the same thing, so is "privileged" mode. The opposite is "user" or "unprivileged" mode. The terms are used interchangeably, and different processor manufacturers use different terms. The distinction is whether you have full access to hardware resources or not. Some architectures have more than two modes, eg x86 has 4 "rings", but this is not relevant to the discussion at hand (and the intermediate privilege levels are rarely used). The kernel runs in the most privileged and apps in the least privileged model. OS servers normally run in user mode, just like apps.

It is true that the OS (the software that provides system services to aps) is more than the kernel, that's the whole point. In the microkernel case, the kernel part is kept to a minimum, and provides only mechanisms, all the services and policies are implemented at user level. But note also that even in a "monolithic" OS like Linux or Windows, some services are implemented at user level. In Unix or Linux systems these are called "demons". -- heiser (talk) 22:46, 27 August 2009 (UTC)

Missing historical information

Are microkernels a product of fortuitousness? There is no information about RC 4000 or Hydra, to put an example. —Preceding unsigned comment added by 201.230.251.217 (talk) 04:45, 23 October 2009 (UTC)

Misleading, wrong, no references, prejudiced

1.) core references not relevant to text content. 2.) My copy of Lion's and Tannebaum's Operating System Design don't delve into kernel issues, Minix 1.0 ran on a PC-XT. 3.) The maintainer seems prejudiced in insisting that a microkernel can only be a "boutique operating system" in contrast to "smallest unit of functional operating system" (typically scheduler). "Mach is used as the default microkernel in the GNU/Hurd system. It is compatible with other popular Mach distributions. The device drivers for block devices and network cards are"... included. 4a.) I developed on alternate Windows: 3.51, 5.0, and 7.0. The authors understanding of Windows structure shows he is "not smarter than a fifth grader" (the kindest epithet I could think of). NTOSKRNL.EXE through NTDLL.DLL runs Windows Native Mode in protected mode. We forked NT5 code for XBox, which runs DirectX over the microkernel. 4b.) Admittedly Microsoft "fixes" things by writing "spaghetti code"; the graphics subsystem was user mode until it was moved into the kernel. And starting with NT4, Microsoft started moving copy protection and security into Ntoskrnl. Still basically a microkernel architecture as Windows can boot and function without Win32 subsystem and Win32 subsystem can host applications without Windows (e.g. WINE). 5.) Minix, NetBSD, and Windows CE run on processors without user/supervisor or MMUs. (Hardware Memory Management is not compliant with RISC Architecture per se). The use of processor being in privileged mode of using privileged memory is as relevant as your dismissing Intel's intermediate security levels. Many ARM implementations use Software Virtual Memory Management. 6.) Duh! but OS9 was developed for MC6809 processor which does not have a supervisor mode. 7.) You forgot lots of stuff, like VxWorks (on my DSL modem/router with the mil-std-1750A 16-bit processor). The QNX task scheduler is so small it fits in cache, I suppose since its always active it can be forgiven for "hogging" cache. Like MACH, QNX can swap out all its drivers and continue running. 8.) When "thrifty" customers want to reuse their hardware, microkernel systems, like Mach based BSD or Windows (cleaned up with Nlite or Embedded Toolkit) will run on fewer RAM and storage resources. Shjacks45 (talk) 17:00, 21 March 2010 (UTC)

At a glance

You actually confused the point of a creating a microkernel (speed and power). The real differences between a microkernel such as Mach or the L4 kernels and a monolithic kernel like the Linux kernel is the structure, not the size. Monolithic refers to all in one file and that it will sit somewhere within user space, kernel space and system space. Microkernel refers to each part of the kernel remaining separate as small kernel parts that act together. Notably the NT kernel used by Windows and the NT clone used by ReactOS are actually Hybrid-kernels using a monolithic style core and two user libraries and two kernel-parts for hardware abstractions. Also a Hybrid-kernel XNU can be found in Mac OSX and all versions of Darwin (a version of Open SUSE) Pleas edit. —Preceding unsigned comment added by Thelinuxman (talk • contribs) 00:49, 15 June 2010 (UTC)

Too much L4?

There's quite a bit of material about L4 in the article, which is a research OS used by almost nobody. L4 is interesting, but not that notable. --John Nagle 16:33, 6 October 2007 (UTC)

Used by almost nobody?

L4 (in the OKL4 version) is commercially supported and deployed, running in 10s of millions of mobile phones. Its also used for teaching in many universities (incl it seems just about every Korean university).

Not noteworthy?

L4 has defined the state of the art in microkernels for the last 15 years, and is continuing to do so. Can you name one innovation in microkernels in the last 15 years that didn't originate in L4?

Heiser 00:35, 7 October 2007 (UTC)

Also, the article says that the design of QNX IPC follows that of L4. Actually, QNX dates from the 1980s, and L4 from the 1990s, so it's the other way round. --John Nagle (talk) 00:59, 10 April 2008 (UTC)

QNX was around longer than L4, but fast IPC was pioneered by Liedtke and L4. At the time, L4's IPC was five times faster than QNX's (see Table 2 in [Liedtke 93], note that it was still called L3 then, but it's really L4). Presumably, QNX has learned from L4 in the 15 years since. The description of QNX IPC in the QNX page (not invoking the scheduler) is exactly the scheme introduced by Liedtke under the name "direct context switch" in the 1993 SOSP paper, as one of several mechanisms to make IPC fast. It was considered novel enough to be accepted in the most prestigeous OS conference. Heiser (talk) 01:25, 14 April 2008 (UTC)

I agree there is far too much L4 stuff. The article reads like an advertisement for L4. I don't dispute that L4 is notable and significant, but there is a big disparity between its prominence in the article versus in the real world. How about we add some other systems such as ThreadX, µC/OS-II, eCOS, Keil RTX etc. (I'm not entirely sure that all of these qualify as microkernels). We could also just use references rather than naming L4 specifically in every instance. --Ozhiker (talk) 03:02, 25 October 2010 (UTC)

Maybe you should check before you write. None of the systems you mention are microkernels, they are unprotected RTOSes (and which one other than ThreadX has real-world significance?) L4 is prominent because it's been defining the state of the art since '93, and almost all microkernel innovation for 15 years has been on L4 (Eros is probably the main exception). It's the only one with a significant research community behind it, there are at least 5 independent active versions (plus several dead ones) and it's been commercially deployed by the billion. Only in the last few years have other innovative microkernels appeared (Barrelfish comes to mind, it is strongly influenced by seL4). Singularity does deserve a mention, but while it's called a microkernel, it uses language-based protection and is as such fundamentally different from what's normally called a microkernel. heiser (talk) 12:22, 30 October 2010 (UTC)

If as you say, those RTOS's don't qualify as Microkernels, then there are some discrepancies that need fixing in this and related articles. ThreadX specifically calls itself a picokernel [4] (p5) - the article says that that term means the same as Microkernel. Also, if they are not microkernels, then which category of kernel are they? (Monolithic, Micro, Exo, Nano, Hybrid) Is another architecture article needed?

BTW: What kind of devices is L4 deployed in by the billion? I've worked in the embedded electronics industry for many years and worked with many different operating systems, and had never heard of it till I read this page, and still haven't come across it elsewhere...

--Ozhiker (talk) 23:49, 26 December 2010 (UTC)

Picokernel is a pure marketing term, it means nothing. In a flat execution model (no distinction between privilege levels) any distinction between "kernel" and "application code" is pure convention, there is no fundamental difference, and everything can interfere with everything else. Therefore it's a meaningless question what kind of a "kernel" an RTOS is. (This is reflected in the conventional term "executive" rather than "kernel" for such RTOSes.)

OKL4 has shipped on well over a billion phones, see L4 microkernel family.

heiser (talk) 17:45, 9 March 2011 (UTC)

Interesting Microkernel discussion

Syllable vs Haiku | Haiku Project. I think it will give us some interesting insights on microkernels. Komitsuki (talk) 14:07, 16 September 2011 (UTC)

No mention of RISC?

I'll go back over the article with a fine-toothed comb but so far I can see no mention of RISC. Despite a lot of specious rubbish published to the contrary, there is and always was a tight relationship between Microkernel architecture and RISC. At the time, everybody thought they were 'the future', but then it turned out there was no net performance gain over monolithic structures, and the price of complex, fast chipsets dropped through the floor effectively ending the whole debate. Microkernels were seen as a very low level way to interface to processor hardware, and possibly a way to make parallel computing easier to implement (and I see somebody has added a mention of Hypervisors in this also earlier, jolly good show). In this way, Microkernels could be seen as being similar in some ways to OpenGL for graphics hardware or OpenCL for parallel architectures. If I have the time and energy I'll dig up references, but they are hard to search on because they are buried in tons and tons of misinterpretations and industry bignoting. I'll see if I can find some of the original papers online and make references to them. If somebody else wants to carry this flag in the meantime please, please be my guest. 118.209.52.145 (talk) 07:11, 5 January 2013 (UTC)

While microkernels and RISC share some common philosophy, the two are completely orthogonal. Neither depends on the other, or has historically influenced the development of the other. There is no reason to refer to RISC in this article. heiser (talk) 01:59, 17 January 2013 (UTC)

QNX lazy scheduling

"As in many cases a thread gets unblocked before the next scheduler invocation, this approach saves significant work. Similar approaches have since been adopted by QNX and MINIX 3." QNX doesn't use the lazy scheduling http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/prog/overview.html#PRIOR — Preceding unsigned comment added by 137.43.182.167 (talk) 16:59, 10 April 2013 (UTC)

Security

This section, while well written for an editorial or a school paper, is not very neutral or objective. This section reads more like a report which is attempting to convince the reader of the better security and stability of micro vs monolithic. I don't see how this section can be repaired as regrettably the entire section leads to prove the thesis of micro's dominance in the security realm. While it states potential "downsides" to micro, the section quickly dismisses them and then goes on to argue micro strengths at great length.

I disagree with the above (anonymous) comment. The basic argument in the article is right: from the security point of view a microkernel-based system (in Liedtke's sense) is an implementation of the principle of least authority (POLA). I have other problems with that section: it is wordy, convoluted and repetitive, and full of irrelevant stuff. It could/should be written in about 1/4 of the words. However, as it's essentially correct I won't bother trying to re-write it myself. Heiser 22:23, 5 August 2007 (UTC)

I have moved an earlier paragraph discussing security issues into this section, where it makes more sense (and corrected it in the process). The rest of the section should be dramatically cut down to a paragraph or two, but I leave this to someone else. Heiser 06:24, 6 August 2007 (UTC)

Thinking about it some more, I propose to really junk most of this stuff, and instead reference more up-to-date security work (kernels with formal API descriptions and proofs of implementation correctness). Heiser 22:51, 6 August 2007 (UTC)

As there were no comments, I've done as proposed. Heiser 00:54, 10 October 2007 (UTC)

I've removed blatantly incorrect (and unsupported by citation) edits by 50.128.184.140 (a presently blocked IP). A TCB is *not* "free to chose which parts of the kernel ti include", any code running in privileged mode is inherently trusted.heiser (talk) 06:53, 2 August 2014 (UTC)

Windows NT and Mac OS microkernels

Sorry, they are not. NT started off as a microkernel design (I believe that's where the "NT" for "New Technology" comes from, using an approach that was only about 25 years old), many core services, including most device drivers, were put back into the kernel for performance reasons. Similarly, Mac OS X (derived from Next) uses what was long ago a virtualised BSD Unix on top of Mach, but due to the poor performance of Mach the BSD kernel was put back into kernel mode, together with Mach. Mac OS X is very much a monolithic kernel, despite using Mach IPC for communication between some userland components. There once was the Darbat project that started replacing Mach by L4 and running Unix as a userland server (i.e. a proper microkernel design, see this semi-informed article, but it never saw the commercial light of day (despite rumours that it was taken much further than our proof of concept). heiser (talk) 05:50, 24 November 2015 (UTC)

Windows NT started out as something of a microkernel; in NT 3.51, the graphics subsystem was outside the kernel. In NT 4, the kernel became much larger as much code from Windows 95 was ported over and put in the kernel.[5]. This was done mostly to make Windows 95 programs work on NT. NT was originally much stricter about many kernel calls than Windows 95, and many applications wouldn't run. [6]. In the end, NT's successor OSs, all the way to Windows 10, were not microkernels. John Nagle (talk) 06:39, 30 November 2015 (UTC)

OP blocked as a sock. --NeilN ^{talk to me} 06:46, 30 November 2015 (UTC)

Something of a microkernel, but with the file system, storage device drivers, networking stack, and networking device drivers running in kernel mode rather than as user-mode servers. Perhaps a bit closer to a microkernel than OS X, with e.g. image activation done by the CSRSS process rather than in-kernel as with OS X, but still not all that microkernelish. (Most UN*Xes have the graphics subsystem outside the kernel with X11; the distinction between a "hybrid kernel" and a monolithic kernel is a bit fuzzy.) Guy Harris (talk) 07:54, 30 November 2015 (UTC)

True. One big problem in OS design is that few systems are good at calling outward; if something in the kernel needs a service, that service usually has to be in the kernel. So either you have a minimal microkernel like L4 or QNX, or a big kernel with file systems and device drivers inside. NT started out halfway in between, but went big-kernel. Anyway, it appears the original post was considered a troll by a now-blocked user, and there's no action required on the article. John Nagle (talk) 08:14, 30 November 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Microkernel. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.minix3.org/
• Added archive https://web.archive.org/web/20050824015422/http://www.qnx.com:80/download/download/8107/QNX_High_Availability_Toolkit.pdf to http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 22:21, 12 September 2016 (UTC)

Works, but the second one should have been done with {{cite web}}, and I made it so. Guy Harris (talk) 02:14, 13 September 2016 (UTC)

AIX is not microkernel based

AIX is not based on a microkernel. The closest commercial server UNIX to a microkernel is tru64, and that's EOLed.

There was quite a bit of discussion about this at www.realworldtech.com, and all the big commercial UNIXes (solaris, hpux, aix, irix) are NOT based on microkernels. — Preceding unsigned comment added by 63.202.185.170 (talk • contribs) 00:55, 26 September 2005 (UTC)

Not a good idea to merge

A microkernel is a specific kind of kernel and worthy of it's own topic.

As i think, it is not a good idea to merge --80.129.215.103 22:02, 1 October 2005 (UTC)

Please, state your reasons. Currently, the Kernel (computer science) article contains all of the contents of this article, thus resulting in redundant information. The Kernel (computer science) article contains, besides the microkernel, a good overview of kernel structures. This article isn't according to wikipedia standards, as it looks like it's part of something else (Kernel (computer science), heh). Having this article to redirect to Kernel (computer science) would be a whole lot cleaner. I would want to suggest to bring the redirect back in place! Any other comments on this? --Anthony Liekens 14:56, 10 October 2005 (UTC)

I would really like to see a merge. The kernel webpage does a much better job of putting microkernels into context, and as of now someone people may not realize the kernel section is superior (or at worst the same)

66.75.49.213 03:50, 31 October 2005 (UTC)

The subject of microkernels has a shelf of its own in my university's library, I should think there is enough material for a separate article. But this article, as it stands now (revision 28046028, as of 2005-11-11), doesn't really add much information that isn't already on the main Kernel article.

And IMHO, the article seems to be written from a very anti-MK perspective. The system is more stable "in theory" (but not, presumably, in practice), the file abstraction does not work with restartable servers (so therefore having separate servers must be the wrong approach (and getting rid of an abstraction that doesn't work is out of the question)), and you have to use (obviously horribly complicated) database techniques, etc. Not to mention that microkernels "generally underperform" and even "sometimes dramatically". At the least, I think whoever makes that sort of claims should be able to back them up.

Really the only thing I would keep is the list of MK-based operating systems. The rest should be wiped out, and the article restarted. But please keep the article, maybe downgrade to a stub, and save the trouble of undeleting it later.

magetoo 22:04, 20 November 2005 (UTC)

I should probably mention that I used some sarcasm in the paragraph above.

Anyway, after looking at the L4 and Mach articles, I'd say there's quite a bit of information in those articles that would find a better home here. It has already been suggested that the L4 article should be cleaned up (and I agree), so moving some things here, at least the very long intro, would seem obvious. (Section "First generation microkernels" entirely and perhaps portions of "A second look".)

-- magetoo 00:53, 21 November 2005 (UTC)

Microkernel needs its own contextualization. Keep it in kernel, keep it here. Microkernel has many issues which simply arent in the non-microkernel world, and it would seriously weigh down the kernel page. Kernels run an operating system. Microkernels run kernels and operating systems. Just because they share the word kernel and lye at the bottom of a stack does not make them the same thing.

-- myren 22:08, 15 December 2005‎ (UTC)

Adding Singularity

Shouldn't Singularity be on the list of microkernels? 7-nov-2005 20:33 CET — Preceding unsigned comment added by 145.53.55.140 (talk • contribs) 19:34, 7 November 2005 (UTC)

I would concur with the addition of Singularity and the merging of the topics until the size of the content dictates otherwise. dru — Preceding unsigned comment added by 12.207.205.105 (talk • contribs) 20:11, 3 December 2005 (UTC)

Please do not merge

The microkernel concept is best discussed as a topic by itself. The microkernel subject is vast and interesting enough to be independent discussion. — Preceding unsigned comment added by 211.169.72.157 (talk • contribs) 13:19, 13 January 2006 (UTC)

Merging with "Kernel" article

A merging of the article "microkernel" with the "kernel" article was proposed because of the possibility of producing "redundant information" between the two. Redundancy did exist at the time of the proposal. Moving the material permanentyl to "kernel" would have resulted in a redirect from "microkernel" and avoidance of such redudancy.

However, many agreed the microkernel concept is "best discussed as a topic by itself" and warranted "independent discussion". One was hesitant to adding material on microkernels to the "kernel" article because it consequently "would seriously weigh down" the latter.

The article originally also had material that slighted microkernels, rather than explaining. Since then, more descriptive material on microkernels found on the L4 kernel and Mach kernel pages has been transferred to the microkernel article. The material at "Kernel" has been moved to the "microkernel" article, and reduandant edits should now be avoided.

The merger has been averted for now, but the article still needs other work. — Preceding unsigned comment added by 71.161.195.151 (talk • contribs) 17:41, 17 February 2006 (UTC)