今天有一点点空闲时间,开始看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。他把消息也完全给写死了,消息不是那么实现的。还要他要求微内核要将所有的服务扔外面去,他的混乱在于,他是站在内核是宏内核的角度去说微内核。