Minix vs. Linux && Microkernel vs Monolithic kernel
源起:
在阅读 Linux的《Just For Fun》第十章 Minix vs Linux中有一段话
The theory behind the microkernel is that operating systems are complicated. So you try to get some of the complexity out by modularizing it a lot. The tenet of the microkernel approach is that the kernel, which is the core of the core of the core, should do as little as possible. Its main function is to communicate. All the different things that the computer offers are services that are available through the microkernel communications channels. In the microkernel approach, you’re supposed to split up the problem space so much that none of it is complex.
I thought this was stupid. Yes, it makes every single piece simple. But the interactions make it far more complex than it would be if many of the services were included in the kernel itself, as they are in Linux. Think of your brain. Every single piece is simple, but the interactions between the pieces make for a highly complex system. It’s the whole-is-bigger-than-the-parts problem. If you take a problem and split it in half and say that the halves are half as complicated, you’re ignoring the fact that you have to add in the complication of communication between the two halves.The theory behind the microkernel was that you split the kernel into fifty independent parts, and each of the parts is a fiftieth of the complexity. But then everybody ignores the fact that the communication among the parts is actually more complicated than the original system was-never mind the fact that the parts are still not trivial.
That’s the biggest argument against microkernels. The simplicity you try to reach is a false simplicity.
Linux started out much smaller and much, much simpler. It didn’t enforce modularity, so you could do a lot of things more straightforwardly than you ever could with Minix. One of the original problems I had with Minix was that if you had five different programs running at the same time and they all want to read five different files, the tasks would be serialized. In other words, you would have five different processes sending requests to the file system: “Can I please Read From File X? The file system daemon that handles reading takes one of them and sends it back, then takes the next one and sends it back, and so on.
Under Linux, which is a monolithic kernel, you have five different processes that each do a system call to the kernel. The kernel has to be very careful that they don’t get: confused with each other, but it very naturally scales up to any number of processes doing whatever they want. It makes Linux much faster and more efficient.
简单解释下:关于linux跟minix的恩怨情仇可以去自行补充或者看《just for fun》。主要就是linux 关于宏内核跟微内核的个人比较,还有就是两个系统的性质不同。我简单提炼一下就是针对微内核的优点linux并不需要,linux是完全free&open的开源软件,minix前期购买磁片可以获得源码,主要开发还是掌握在少数人手里后期开源,linux没有什么必要的版本节点。有足够的人(全球的聪明的开发者参与)有足够的时间慢慢打磨调优,对每一个模块有足够多的测试和验证。对开发效率这个点没有kpi没有产品人员在屁股后面催。这群人本来就是geek到骨子里的人,性能才是他们的G点。为了开发效率,牺牲性能我觉的如果是我我也不会妥协。
当时没理解,做了标记,然后回过头抽时间对宏内核和微内核的资料搜索学习了下 这里整理下。说实话以前我真不知道这东西,个人感觉更多的是设计理念的派系之分,因层次不够对大佬们现在只能仰望,大佬们华山论剑,自己做好一个吃瓜群众就好。学习为主,不扯蛋发表个人意见了
介绍
宏内核
宏内核(英语:Monolithic kernel),也译为集成式内核、单体式内核,一种操作系统内核架构,此架构的特性是整个内核程序是一个单一二进制可执行文件,在内核态以监管者模式(Supervisor Mode)来运行。相对于其他类型的操作系统架构,如微内核架构或混合内核架构等,这些内核会定义出一个高端的虚拟接口,由该接口来涵盖描述整个计算机硬件,这些描述会集合成一组硬件描述用词,有时还会附加一些系统调用,如此可以用一个或多个模块来实现各种操作系统服务,如进程管理、并发(Concurrency)控制、存储器管理等。
宏内核被视作为运行在单一地址空间的单一的进程,内核提供的所有服务,都以特权模式,在这个大型的内核地址空间中运作,这个地址空间被称为内核态(kernel space)。它通常是以单一静态二进制文件的方式被存储在磁盘,或是高速缓存上,在引导之后被加载存储器中的内核态,开始运作。
它的优点是设计简单。在内核之中的通信成本很小,内核可以直接调用内核态内的函数,跟用户态的应用程序调用函数一样,因此它的性能很好。在1980年代之前,所有的操作系统都采用这个方式实现;即使到了现在,主要的操作系统也多采用这个方式。
微内核的支持者认为,宏内核的移植性不佳,即使有的宏内核将其运作从整体性运作拆分成几个服务模块,并让各模块各自运作,其操作系统的代码依然是高度紧密的,很难修改成其他类型的操作系统架构。此外,所有的模块也都在同一块定址空间内运行,倘若某个模块有错误、瑕疵(Bug),运行时就会损及整个操作系统运作。反过来,如果整块性架构的操作系统在开发设计时相当完善,并经测试验证后具有高度可靠性,则操作系统内的各软件组件因具有高度紧密性,如此在系统的低级运作上将格外有效率。
现在多数采行整块性架构设计的操作系统,如OpenVMS、Linux、FreeBSD、以及Solaris等,都已经能在运作运行阶段中,以动态方式来加载(Load)、卸载(Unload)可执行的模块,不过这些模块是属于二进制代码的层次,或称映像层次,而非内核架构的层次。即使宏内核进行模块化转化,也不会与微内核或混合内核架构的内核产生区分上的混淆,因为微内核、混合内核的模块是属于系统架构的层次。
就实务上,动态加载/卸载模块的作法,等于是用一种较简易的方式来弹性管控运行中的操作系统内核,若没有动态加载/卸载机制,操作系统的内核想要进行任何的调整、变换,都必须重启才能达成。因此模块化是必然且必要的,如此才能让内核功效轻松地扩展、延伸,此外也能适时减轻硬件的运行运作负担。
另外,有些整块性操作系统为了让它的内核态达到最小化,也会运用动态加载/卸载机制来达成此一目标。
微内核
在信息学中,微内核(英语:Microkernel,μ-kernel),又称为微核心,是一种内核的设计架构,由一群尽可能将数量最小化的软件程序组成,它们负责提供、实现一个操作系统所需要的各种机制与功能。这些最基础的机制,包括了底层地址空间管理,线程管理,与行程间通信(IPC)。
微核心的设计理念,是将系统服务的实现,与系统的基本操作规则区分开来。它实现的方式,是将核心功能模块化,划分成几个独立的行程,各自运行,这些行程被称为服务(service)。所有的服务行程,都运行在不同的地址空间。只有需要绝对特权的行程,才能在具特权的运行模式下运行,其余的行程则在用户空间运行。
这样的设计,使内核中最核心的功能,设计上变的更简单。需要特权的行程,只有基本的线程管理,内存管理和进程间通信等,这个部分,由一个简单的硬件抽象层与关键的系统调用组成。其余的服务行程,则移至用户空间。
让服务各自独立,可以减少系统之间的耦合度,易于实现与调试,也可增进可移植性。它可以避免单一组件失效,而造成整个系统崩溃,内核只需要重启这个组件,不致于影响其他服务器的功能,使系统稳定度增加。同时,操作系统也可以视需要,抽换或新增某些服务行程,使功能更有弹性。
因为所有服务行程都各自在不同地址空间运行,因此在微核心架构下,不能像宏内核一样直接进行函数调用。在微核心架构下,要创建一个行程间通信机制,通过消息传递的机制来让服务行程间相互交换消息,调用彼此的服务,以及完成同步。采用主从式架构,使得它在分布式系统中有特别的优势,因为远程系统与本地行程间,可以采用同一套行程间通信机制。
但是因为行程间通信耗费的资源与时间,比简单的函数调用还多;通常又会涉及到核心空间到用户空间的环境切换(context switch)。这使得消息传递有延迟,以及传输量(throughput)受限的问题,因此微核心在通信宽容度不足下,可能出现性能不佳的问题。
就代码数量来看,一般来说,因为功能简化,微核心使用的代码比集成式核心更少,其源代码通常小于10,000行。例如,MINIX 3的源代码少于6,000行[1]。更少的代码,也代表更少的潜藏程序bug,对于重视安全性的人来说会较为偏好。
比较
当然还有一种混合内核
个人碎语:
两种主要的内核其实是设计模式之分。更多是取舍问题。这种肯定没有对错之分。宏内核是耦合性更高一点,但是性能确实强一些(这个具体指标想测也没得办法)。微内核更容易迁移跟扩展,但是也牺牲了部分性能。这跟编写代码过程中的项目架构很有类同的地方。计算机编程开发个人认为是实用主义至上。在不同的场景下用不同的方案。没有标准答案才是最有意思的地方吧!
参考资料:
https://zh.wikipedia.org/wiki/%E5%86%85%E6%A0%B8
https://zh.wikipedia.org/wiki/%E6%95%B4%E5%A1%8A%E6%80%A7%E6%A0%B8%E5%BF%83
https://zh.wikipedia.org/wiki/%E5%BE%AE%E5%85%A7%E6%A0%B8
https://blog.csdn.net/dingdongnigetou/article/details/22673021
https://blog.csdn.net/freejs/article/details/84187750
https://blog.csdn.net/GenuineMonster/article/details/82877582
https://zhuanlan.zhihu.com/p/53612117