关于宏微内核的有感

╰半夏微凉° 2023-06-20 06:42 15阅读 0赞

今天有一点点空闲时间，开始看Robert Love 的Linux 内核设计与实现。

作者说着说着提到了宏微内核，然后提到微内核的原理，和该原理不实用。

这我就不感苟同。我认为，懒惰和愚蠢永远不能成为实用的理由。

作者提到win7和以后的操作系统，微软似乎又回到宏内核思路去了，这里我想有两个原因，一个是微软人才凋敝，没几个还理解当年NT是怎么开发出来的，为什么winxp依然是这个星球上最先进的操作系统;另一个原因是阿三掌舵的微软，早已不是当年那个事事严谨的微软件。

我不明白，人们为什么会把落后当作进步的理由。

另外，作者完全没有搞清楚到底什么是微内核。

很早以前，我记得我那个时代的是人是讲良心的。

记得有一本书，也是老外写的，叫windows 95内幕，还有一本叫wdm驱动开发，好象。

作者反复强调的是API，他不怕得罪人，向当年的NT团队提出的置疑：为什么某些win32PAI和kernelAPI不能兼容window95，他还举出几个例子，完全从技术上没有问题，完全是微软内部的研发团队，自行其是，把技术置于需求之上。

当年的NT是XP是成功的，特别是XP。这是让那些不思进取的搞宏内核的人shut up的最好例证。

同样，今天的微软一个破windows10，完全玩不转，正是微软越来越不堪的写照 。试问今天的微软，还有几个人了解微内核？早把前辈的荣光忘得一干二净。反倒让linux这种相对落后的操作系统笑话。

============================================

Robert Love 提到了内个点来定义微内核，这里我一点点来解释他错在哪里。他提到：（1）以msg代替调用; （2）每个 消息的服务者，是一个内核服务进程，然后该进程运行于用户态，这样的坏处显而易见，连内存都用的不是内核的公共内存，内核的每次调用，都要进行地址转换，还要从Ring3切到Ring0。

然后他就结束了他的抱怨，给了个结论，现在人们更使用了。甚至边微软都越活越完蛋了：不玩消息了，改直接调用了。也全都 放到内核去了。

这样真是误人子弟啊。懒怠与实用是两个层次的概念，你不能在2维空间说3维空间的行为不实用。

\-----------------------------------

我想起什么就说什么吧。

1. 作者只提到运行时的问题。操作系统最难难在哪里呢？与世间万物一样，进化最难。为什么linux现在进化极基困难？微内核不仅不提，还以落后的宏内核为容。宏内核落后在哪里？最大的问题是不利于大规模开发团队分工，和理解眼前的用户需求的满足。更不要说进化了。牵一发动全身，结果是只有几十年的老油条才能控制linux的进化，但是老油条一定是事事向后坐的。哪个老家伙还有心进取呢？结果就成了老鼠会。是这微内核要解决的本质问题，不在操作系统运行后，这是本末倒置。

这真是误人子弟啊。

宏内核，只是从客观上保证了系统的整体性，但对系统的外在表现性，是灾难;对系统的进化是大灾难。

这种东西 ，早晚会被淘汰的。

2. 微内核最重要的不是运行时的状态，而是内核级API，或者是被这些API封装的内核消息。这些消息，未必是IPC消息。

搞内核的人，当然，不止是内核程序员，是个程序员就不喜欢向外公开API，因为API的服务函数是极为难以编写的。更不是要内核级API。我为什么说winxp以后，微软开发的都是垃圾？因为其内核API完全失控了。一家公司到这个程度 ，说明程序员团队集体的良心都失去了。

3. 为什么内核级API是如此重要？因为API相当于你对调用方的承诺，是起码的良心。也是可以实现第三方管理和用户至上的体现。

任何一种产品，只要是象java 那样，只是为程序员自己服务，一定会把开发团队搞成老鼠会。

4. 所以，微内核最最重要的特征是各服务模块间的API化。

5. API化之后，才是服务模块的分解。然后是到了编译时。

也就是说，前面我说的API化设计时，Robert Love只提到了运行时，先假定那个东西 存在，然后再讲歪理邪说，我这里从设计时先提到一个基本概念。设计时第二个概念是服务模块的独立性。

这二者，为编译和链接以及集成时的二进制集成的前提。也就是说，每个子开发团队，不需要得到其它团队的代码，就可以编译和发布自己的输出 。

这一步，为是否为微内核的最最重要的考核指标。而不是在运行时。

为什么强调二进制构建，而不是全代码构建？这是一个管理问题。复杂系统的开发过程的管理问题。

研发人员是有能力，但这种能力也必须要控制才能形成合力。这不是一两句话能说清的，但一个重要的表征就是是否API化和服务化，以及服务的二进制集成过程的能力。

6. 作者提到实用，我们最后当然也要讲运行时。

微内核最被作者诟病的是运行时效率。他说效率的问题来自于服务运行于用户态，切换带来了效率的问题。

这个只能说这作者非常之狭隘。

微内核没有必要运行在内核之外。这里作者犯了一系列的起码的先入为主的错误。

例如，微内核，为什么带保证操作系统的稳定？他认为是因为两点，一点是消息机制，一种内核服务运行于用户态，无法直接破坏内核。

这又是一系列错误。微软一开始是用消息，但消息可以用向量表来代替。消息为什么带来稳定？是因为消息分派器如果发现消息无人服务，可以将该消息吞掉，而调用方只是没有收到回应消息，不什么挂死内核线程。但向量表也能实现这样的效果。初始化时，为所有的空向量的服务方一侧赋一个默认的空操作的服务函数即可。但调用的效率是极高的。因为没有了消息分派器。

第二，谁说服务要在用户态？服务完全可以在内核态，这不是微内核的本质因素。服务如果在内核态，有一个要求是内核也是多线程的。我想这个地方，仁者见仁，智者见智，有人认为内核绝对不能多线程，但这显然是不成立的。这也就是微内核的微的一个重要来源。也就是说这个多线程架构，才是真正的调度内核，也就是微内核的名称的由来。

说到这可能读完的读者就清楚，我说的含义了：消息可以用向量表来代替调用方和服务方。并不一定需要消息分派器;服务方的二进制动态库，是各团队开发出来的，但共同运行于内核，并且有自己的线程。所以，才不能因为自己的死掉，害死微内核。内存也是大家一起共用的。 windows xp就是这样构建的。

读到这，就没有必要写下去了。作者后面的一系列假设都是在他错误的定义上。他把重点完全放在了自己的认知上。他忘了微内核是多线程的，也就是内核中还有一个微内核，他没有提大规模团队开发，没有提内核API。他把消息也完全给写死了，消息不是那么实现的。还要他要求微内核要将所有的服务扔外面去，他的混乱在于，他是站在内核是宏内核的角度去说微内核。