微内核与巨内核

http://meta.slashdot.org/story/12/10/11/0030249/linus-torvalds-answers-your-questions

http://yarchive.net/comp/microkernels.html

Linus vs. Tanenbaum 译文http://www.simplemind.info/technolife/projects/linus-tanenbaum.html

Monolithic vs. Micro-kernel architecture 

by NoNeeeed

Has there ever been a time in the development of the Linux Kernel where you've wished you'd gone the Hurd-style micro-kernel route espoused by the like of Tannenbaum, or do you feel that from an architectural standpoint Linux has benefited from having a monolithic design?

Linux has been massively more successful than Hurd, but I wonder how much of that is down to intrinsic technical superiority of its approach, and how much to the lack of a central driving force supported by a community of committed developers? It always seemed like the Hurd model should have allowed more people to be involved, but that has never seemed to be the case.  

Linus:  I think microkernels are stupid. They push the problem space into *communication*, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix. They also lead to horrible extra complexity as you then have to fight the microkernel model, and make up new ways to avoid the extra communication latencies etc. Hurd is a great example of this kind of suckiness, where people made up whole new memory mapping models just because the normal "just make a quick system call within the same context" model had been broken by the microkernel model.

Btw, it's not just microkernels. Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. Microkernels had one such ideology, there have been others. It's all BS. The fact is, reality is complicated, and not amenable to the "one large idea" model of problem solving. The only way that problems get solved in real life is with a lot of hard work on getting the details right. Not by some over-arching ideology that somehow magically makes things work. 

Linus在其文章“Linux的边界”中，对微内核有以下论述:

当我开始编写Linux内核时，学术界对和如何编写可移植系统有一个共识，他们通常认为明智的选择就是必须用微内核样式（microkernel一style）的体系。 
在如Llnu调内核这样的“整体内核”（monoliihic kernel） 中，内存被分为用户空间和内核空间。内核空间是用以存放内核代码以及内核级别操作的内存。内核操作包括调度、进程管理、信号、设备输入／输出、分页和转换等。这些都是其他程序赖以运行的关键操作。由于内核代码含有与低层硬件的交互作用功能， 
所以整体内核看起来似乎只能局限于某一特定的体系。 
微内核是只在较有限的形式下完成较少操作的一个集合，如进程间通信、有限的进程管理与调度，以及一些低级别的输入／输出等。由于许多系统特性被划分给了用户空间，因此微内核似乎与硬件关系不大。微内核体系基本上只是对进程控制、内存分配、资源分配等细节的一种抽象方式，要将它移入另一类芯片只需做 
很小的改动。 
因此,1991年当我开始编写Linux时，人们都认为只有微内核方法可以解决可移植性。因为它在当时是计算机科学家研究的宠儿。 
然而，我是个固执、讲求实际的人，当时我对微内核的看法是： 
1．仍处于实验阶段； 
2．比整体内核复杂得多； 
3．运行速度明显地比整体内核慢。 
由于运算速度对于现实世界中的操作系统意味着一切，所以，当时许许多多的科研经费都花在了对微内核的最优化检测上，看它是否运行得如同正常内核一样快。令人好笑的是，如果你真正读一读那些论文的话，你就会发现，研究人员应用在微内核上的最优化技巧，事实上可以很容易地应用到传统内核上以加快其运行速度。 

实际上，这使我觉得微内核方案就像是一个自欺欺人的方案，目的是获取更多的研究经费。我并不是说这些研究人员诚心要欺骗，也许他们只是愚昧，或者是搞错了。我说的这些都是我的真实感受。这种不诚实来自了当时笼罩在研究领域的强大压力，迫使人们致力于微内核方面的研究。在计算机科学实验室里，你要么在研究微内核，要么就根本不是在研究内核。所以大家都在被迫表现出这种不诚实，甚至包括设计Windows NT的人们。即使NT工作小组的人员知道最终的结果不是采用微内核方案，他们也不得不迎合这一思想。 
值得庆幸的是，我没有受到追随微内核的压力。芬兰赫尔辛基大学从60年代未起一直从事操作系统的研究，他们不再把操作系统内核视为一个研究焦点。从某些方面说这是正确的。操作系统的基础，也就是Linux内核的扩展的基础。早在70年代初就已被人们了解得很清楚，这之后的任何事都是某种程度上的自我满足的练习。 
如果你想编写出具有可移植性的代码，那么你不必非要靠建立一个抽象层才能实现代码的可移植。相反，你只需要编程时聪明一点就可以到达目的。基本上可以这样说，想方设法使微内核可移植是浪费时间。这好比使用方型轮胎来研制一种超高速的汽车。一味地将内核中的一件事单独提取出来，盲目地追求其速度，其相应
的效果只能是适得其反。 
当然，微内核的研究并不局限于上述努力，但问题的大部分就是目的上的不同。很多微内核研究的目的是针对某个理想化的理论而设计的，以求这种设计能够跨跃任何可能的体系，从而实现可移植性。我井没有想在Linux上实现这么虚幻的目标。我感兴趣的是在现实的系统上实现可移植性，而不是在理论的系统上。