ubuntu16.04 查看内核，升级内核，删除内核，切换内核


1:查看内核列表
sudo dpkg --get-selections |grep linux-image


linux-image-4.4.0-21-generic
install
linux-image-4.4.0-66-generic deinstall
linux-image-4.4.0-70-generic 
deinstall
linux-image-4.4.0-71-generic 
install
linux-image-4.4.0-72-generic 
install





2:查看当前使用的内核
uname -r

4.4.0-21-generic



3:升级/安装内核

sudo apt-get install linux-image-4.4.0-75-generic



3:删除内核

tip：删除当前版本重启会使用低一级的已安装内核，　如果是最后一个内核版本删除之后重启会进入ＢＩＯＳ界面
sudo apt-get remove linux-image-4.4.0-75-generic



4:切换内核
参考：http://blog.csdn.net/u011304615/article/details/70920171

宏内核：简单来说，就是把很多东西都集成进内核，例如linux内核，除了最基本的进程、线程管理、内存管理外，文件系统，驱动，网络协议等等都在内核里面。优点是效率高。缺点是稳定性差，开发过程中的bug经常会导致整个系统挂掉。做驱动开发的应该经常有按电源键强行关机的经历。
微内核：内核中只有最基本的调度、内存管理。驱动、文件系统等都是用户态的守护进程去实现的。优点是超级稳定，驱动等的错误只会导致相应进程死掉，不会导致整个系统都崩溃，做驱动开发时，发现错误，只需要kill掉进程，修正后重启进程就行了，比较方便。缺点是效率低。典型代表QNX，QNX的文件系统是跑在用户态的进程，称为resmgr的东西，是订阅发布机制，文件系统的错误只会导致这个守护进程挂掉。不过数据吞吐量就比较不乐观了




操作系统内核可能是微内核，也可能是单内核（后者有时称之为宏内核Macrokernel）。按照类似封装的形式，这些术语定义如下：

单内核：也称为宏内核。将内核从整体上作为一个大过程实现，并同时运行在一个单独的地址空间。所有的内核服务都在一个地址空间运行，相互之间直接调用函数，简单高效。微内核：功能被划分成独立的过程，过程间通过IPC进行通信。模块化程度高，一个服务失效不会影响另外一个服务。Linux是一个单内核结构，同时又吸收了微内核的优点：模块化设计，支持动态装载内核模块。Linux还避免了微内核设计上的缺陷，让一切都运行在内核态，直接调用函数，无需消息传递。

Linux大部分都是单内核的。

微内核（Microkernel kernel）――在微内核中，大部分内核都作为单独的进程在特权状态下运行，他们通过消息传递进行通讯。在典型情况下，每个概念模块都有一个进程。因此，假如在设计中有一个系统调用模块，那么就必然有一个相应的进程来接收系统调用，并和能够执行系统调用的其他进程（或模块）通讯以完成所需任务。

在这些设计中，微内核部分经常只但是是个消息转发站：当系统调用模块要给文档系统模块发送消息时，消息直接通过内核转发。这种方式有助于实现模块间的隔离。（某些时候，模块也能够直接给其他模块传递消息。）在一些微内核的设计中，更多的功能，如I/O等，也都被封装在内核中了。但是最根本的思想还是要保持微内核尽量小，这样只需要把微内核本身进行移植就能够完成将整个内核移植到新的平台上。其他模块都只依赖于微内核或其他模块，并不直接直接依赖硬件。

微内核设计的一个长处是在不影响系统其他部分的情况下，用更高效的实现代替现有文档系统模块的工作将会更加容易。我们甚至能够在系统运行时将研发出的新系统模块或需要替换现有模块的模块直接而且迅速的加入系统。另外一个长处是无需的模块将不会被加载到内存中，因此微内核就能够更有效的利用内存。

-----------------------------------------------------------------------------------------------------------------------------------------------

单内核（Monolithic kernel）――单内核是个很大的进程。他的内部又能够被分为若干模块（或是层次或其他）。但是在运行的时候，他是个单独的二进制大映象。其模块间的通讯是通过直接调用其他模块中的函数实现的，而不是消息传递。

单内核的支持者声称微内核的消息传递开销引起了效率的损失。微内核的支持者则认为因此而增加的内核设计的灵活性和可维护性能够弥补任何损失。

我并不想讨论这些问题，但必须说明很有趣的一点是，这种争论经常会令人想到前几年CPU领域中RISC和CISC的斗争。现代的成功CPU设计中包含了任何这两种技术，就像Linux内核是微内核和单一内核的混合产物相同。Linux内核基本上是单一的，但是他并不是个纯粹的集成内核。前面一章所介绍的内核模块系统将微内核的许多长处引入到Linux的单内核设计中。（顺便提一下，我考虑过一种有趣的情况，就是Linux的内核模块系统能够将系统内核转化成为简单的不传递消息的微内核设计。虽然我并不赞成，但是他仍然是个有趣的想法。）

为什么Linux必然是单内核的呢？一个方面是历史的原因：在Linus的观点看来，通过把内核以单一的方式进行组织并在最初始的空间中运行是相当容易的事情。这种决策避免了有关消息传递体系结构，计算模块装载方式等方面的相关工作。（内核模块系统在随后的几年中又进行了不断地改进。）

另外一个原因是充足的研发时间的结果。Linux既没有研发时间的限制，也没有深受市场压力的发行进度。任何的限制只有并但是分的对内核的修改和扩充。内核的单一设计在内部实现了充分的模块化，在这种条件下的修改或增加都并不怎么困难。而且问题还在于没有必要为了追求尚未证实的可维护性的微小增长而重写Linux的内核。（Linus曾多次特别强调了如下的观点：为了这点利益而损耗速度是不值得的。）后面章节中的部分内容将周详的重新考虑充足研发时间的效果。

假如Linux是纯微内核设计，那么向其他体系结构上的移植将会比较容易。实际上，有一些微内核，如Mach微内核，就已成功的证实了这种可移植性的长处。实际的情况是，Linux内核的移植虽然不是很简单，但也绝不是不可能的：大约的数字是，向一个全新的体系结构上的典型的移植工作需要 30,000到 60,000行代码，再加上不到20,000行的驱动程式代码。（并不是任何的移植都需要新的驱动程式代码。）粗略的计算一下，我估计一个典型的移植平均需要50,000行代码。这对于一个程式员或最多一个程式小组来说是力所能及的，能够在一年之内完成。虽然这比微内核的移植需要更多的代码，但是
 Linux的支持者将会提出，这样的Linux内核移植版本比微内核更能够有效的利用底层硬件，因而移植过程中的额外工作是能够从系统性能的提高上得到补偿的。

这种特别设计的权衡也不是很轻松就能够达到的，单内核的实现策略公然违背了传统的看法，后者认为微内核是未来发展的趋势。但是由于单一模式（大部分情况下）在Linux中运行状态良好，而且内核移植相对来说比较困难，但没有明显地阻碍程式员团体的工作，他们已热情高涨地把内核成功的移植到了现存的大部分实际系统中，更不用说类似掌上型电脑的一些看起来很不实际的目标了。只要Linux的众多特点仍然值得移植，新的移植版本就会不断涌现。

所有的Unix内核都同宗同源，并且提供相同的API，现代的Unix内核存在许多设计上的相似之处。Unix内核几乎毫无例外的都是一个不可分割的静态可执行块（文件）。也就是说，它们必须以完整、单独的可执行块的形式在一个单独的地址空间中运行。

Unix内核几乎都需要硬件系统提供页机制以管理内存。这种页机制可以加强内存空间的保护，并保证每个进程都可以运行于不同的虚地址空间上。

单内核与微内核设计之比较

操作系统内核可以分为两大设计阵营：单内核和微内核（第三阵营外内核，主要用在科研系统中，但也逐渐在现实世界中壮大起来）。

单内核是两大阵营中一种较为简单的设计，在1980年之前，所有的内核都设计成单内核。所谓单内核就是把它从整体上作为一个单独的大过程来实现，并同时运行在一个单独的地址空间。因此，这样的内核通常以单个静态二进制文件的形式存放于磁盘。所有内核服务都在这样的一个大内核空间中运行。内核之间的通信是微不足道的，因为大家都运行在内核态，并身处同一地址空间：内核可以直接调用函数，这与用户空间没有什么区别。这种模式的支持者认为单模块具有简单和高性能的特点。大多数Unix系统都设计为单模块。

另一方面，微内核并不作为一个单独的大过程来实现。相反，微内核的功能被划分为独立的过程，每个过程叫做一个服务器。理想情况下，只有强烈请求特权服务的服务器才运行在特权模式下，其他服务器都运行在用户空间。不过，所有的服务器都保持独立并运行在各自的地址空间。因此，就不可能像单模块内核那样直接调用函数，而是通过消息传递处理微内核通信：系统采用了进程间通信(IPC)机制，因此，各种服务器之间通过IPC机制互通消息，互换“服务”。服务器的各自独立有效地避免了一个服务器的失效祸及另一个。

同样，模块化的系统允许一个服务器为了另一个服务器而换出。因为IPC机制的开销比函数调用多，又因为会涉及内核空间到用户空间的上下文切换，因此，消息传递需要一定的周期，而单内核中简单的函数调用没有这些开销。基于此，付之于实际的微内核系统让大部分或全部服务器位于内核，这样，就可以直接调用函数，消除频繁的上下文切换。Windows NT内核和Mach（Mac OS X的组成部分）是微内核的典型实例。不管是Windows NT还是Mac OS X，都在其新近版本中不让任何微内核服务器运行在用户空间，这违背了微内核设计的初衷。

Linux是一个单内核，也就是说，Linux内核运行在单独的内核地址空间。不过，Linux汲取了微内核的精华：其引以为豪的是模块化设计、抢占式内核、支持内核线程以及动态装载内核模块的能力。不仅如此，Linux还避其微内核设计上性能损失的缺陷，让所有事情都运行在内核态，直接调用函数，无需消息传递。至今，Linux是模块化的、多线程的以及内核本身可调度的操作系统。实用主义再次占了上风。

当Linus和其他内核开发者设计Linux内核时，他们并没有完全彻底地与Unix诀别。他们充分地认识到，不能忽视Unix的底蕴（特别是 Unix的 API）。而由于Linux并没有基于某种特定的Unix，Linus和他的伙伴们对每个特定的问题都可以选择已知最理想的解决方案—在有些时候，当然也可以创造一些新的方案。以下是对Linux内核与Unix各种变体的内核特点所作的分析比较：

·Linux支持动态加载内核模块。尽管Linux内核也是单内核，可是允许在需要的时候动态地卸除和加载部分内核代码。

·Linux支持对称多处理（SMP）机制，尽管许多Unix的变体也支持SMP，但传统的Unix并不支持这种机制。

·Linux内核可以抢占（preemptive）。与传统的Unix不同，Linux内核具有允许在内核运行的任务优先执行的能力。在其他各种Unix产品中，只有Solaris和IRIX支持抢占，但是大多数传统的Unix内核不支持抢占。

·Linux对线程支持的实现比较有意思：内核并不区分线程和其他的一般进程。对于内核来说，所有的进程都一样—只不过其中的一些共享资源而已。

·Linux提供具有设备类的面向对象的设备模型、热插拔事件，以及用户空间的设备文件系统（sysfs）。

·Linux忽略了一些被认为是设计得很拙劣的Unix特性，像STREAMS，它还忽略了那些实际上已经根本不会使用的过时标准。

·Linux体现了自由这个词的精髓。现有的Linux特性集就是Linux公开开发模型自由发展的结果。如果一个特性没有任何价值或者创意很差，没有任何人会被迫去实现它。相反的，在Linux的发展过程中已经形成了一种值得称赞的务实态度：任何改变都要针对现实中确实存在的问题，经过完善的设计并有正确简洁的实现。于是，许多其他现代Unix系统包含的特性，如内核换页机制，都被毫不迟疑的引入进来。

不管Linux和Unix有多大的不同，它身上都深深地打上了Unix烙印

------------------------------------------------------------------------------------------------------------------------------------------

以下是摘自wiki的一段关于宏内核的介绍



 

宏内核有时也称单内核，原文为英文的Monolithic kernel。

宏内核是操作系统内核架构的一种，此架构的特性是整个内核程序都是以内核空间（Kernel Space）的身份及监管者模式（Supervisor Mode）来运行。相对于其他类型的操作系统架构，如微内核架构或混内核架构等，这些内核会定义出一个高级的虚拟接口，由该接口来涵盖描述整个计算机硬件，这些描述会集合成一组硬件描述用词，有时还会附加一些系统调用，如此可以用一个或多个模块来实现各种操作系统服务，如进程管理、共时（Concurrency）控制、存储器管理等。

即使有的宏内核将其运作从整体性运作拆分成几个服务模块，并让各模块各自运作，其操作系统的代码依然是高度紧密的，很难修改成其他类型的操作系统架构。此外，所有的模块也都在同一块寻址空间内运行，倘若某个模块有错误、瑕疵（Bug），运行时就会损及整个操作系统运作。反过来，如果宏内核架构的操作系统在开发设计时相当完善，并经测试验证后具有高度可靠性，则操作系统内的各软件组件因具有高度紧密性，如此在系统的低级运作上将格外有效率。

 

可加载性的模块

 

现在多数采行宏内核架构设计的操作系统，如OpenVMS、Linux、FreeBSD、以及Solaris等，都已经能在运作运行阶段中，以动态方式来加载（Load）、卸载（Unload）可运行的模块，不过这些模块是属于二进制代码的层次，或称镜像层次，而非内核架构的层次。即使宏内核进行模块化转化，也不会与微内核或混内核架构的内核产生区分上的混淆，因为微内核、混内核的模块是属于系统架构的层次。

就实务上，动态加载/卸载模块的作法，等于是用一种较简易的方式来弹性管控运行中的操作系统内核，若没有动态加载/卸载机制，操作系统的内核想要进行任何的调整、变换，都必须重新开机才能达成。因此模块化是必然且必要的，如此才能让内核功效轻松地扩展、延伸，此外也能适时减轻硬件的运行运作负担。

另外，有些整块性操作系统为了让它的内核空间达到最小化，也会运用动态加载/卸载机制来达成此一目标。


操作系统内核可能是微内核，也可能是单内核（后者有时称之为宏内核Macrokernel）。按照类似封装的形式，这些术语定义如下：

单内核：也称为宏内核。将内核从整体上作为一个大过程实现，并同时运行在一个单独的地址空间。所有的内核服务都在一个地址空间运行，相互之间直接调用函数，简单高效。微内核：功能被划分成独立的过程，过程间通过IPC进行通信。模块化程度高，一个服务失效不会影响另外一个服务。Linux是一个单内核结构，同时又吸收了微内核的优点：模块化设计，支持动态装载内核模块。Linux还避免了微内核设计上的缺陷，让一切都运行在内核态，直接调用函数，无需消息传递。

Linux大部分都是单内核的。

微内核（Microkernel kernel）――在微内核中，大部分内核都作为单独的进程在特权状态下运行，他们通过消息传递进行通讯。在典型情况下，每个概念模块都有一个进程。因此，假如在设计中有一个系统调用模块，那么就必然有一个相应的进程来接收系统调用，并和能够执行系统调用的其他进程（或模块）通讯以完成所需任务。

在这些设计中，微内核部分经常只但是是个消息转发站：当系统调用模块要给文档系统模块发送消息时，消息直接通过内核转发。这种方式有助于实现模块间的隔离。（某些时候，模块也能够直接给其他模块传递消息。）在一些微内核的设计中，更多的功能，如I/O等，也都被封装在内核中了。但是最根本的思想还是要保持微内核尽量小，这样只需要把微内核本身进行移植就能够完成将整个内核移植到新的平台上。其他模块都只依赖于微内核或其他模块，并不直接直接依赖硬件。

微内核设计的一个长处是在不影响系统其他部分的情况下，用更高效的实现代替现有文档系统模块的工作将会更加容易。我们甚至能够在系统运行时将研发出的新系统模块或需要替换现有模块的模块直接而且迅速的加入系统。另外一个长处是无需的模块将不会被加载到内存中，因此微内核就能够更有效的利用内存。

-----------------------------------------------------------------------------------------------------------------------------------------------

单内核（Monolithic kernel）――单内核是个很大的进程。他的内部又能够被分为若干模块（或是层次或其他）。但是在运行的时候，他是个单独的二进制大映象。其模块间的通讯是通过直接调用其他模块中的函数实现的，而不是消息传递。

单内核的支持者声称微内核的消息传递开销引起了效率的损失。微内核的支持者则认为因此而增加的内核设计的灵活性和可维护性能够弥补任何损失。

我并不想讨论这些问题，但必须说明很有趣的一点是，这种争论经常会令人想到前几年CPU领域中RISC和CISC的斗争。现代的成功CPU设计中包含了任何这两种技术，就像Linux内核是微内核和单一内核的混合产物相同。Linux内核基本上是单一的，但是他并不是个纯粹的集成内核。前面一章所介绍的内核模块系统将微内核的许多长处引入到Linux的单内核设计中。（顺便提一下，我考虑过一种有趣的情况，就是Linux的内核模块系统能够将系统内核转化成为简单的不传递消息的微内核设计。虽然我并不赞成，但是他仍然是个有趣的想法。）

为什么Linux必然是单内核的呢？一个方面是历史的原因：在Linus的观点看来，通过把内核以单一的方式进行组织并在最初始的空间中运行是相当容易的事情。这种决策避免了有关消息传递体系结构，计算模块装载方式等方面的相关工作。（内核模块系统在随后的几年中又进行了不断地改进。）

另外一个原因是充足的研发时间的结果。Linux既没有研发时间的限制，也没有深受市场压力的发行进度。任何的限制只有并但是分的对内核的修改和扩充。内核的单一设计在内部实现了充分的模块化，在这种条件下的修改或增加都并不怎么困难。而且问题还在于没有必要为了追求尚未证实的可维护性的微小增长而重写Linux的内核。（Linus曾多次特别强调了如下的观点：为了这点利益而损耗速度是不值得的。）后面章节中的部分内容将周详的重新考虑充足研发时间的效果。

假如Linux是纯微内核设计，那么向其他体系结构上的移植将会比较容易。实际上，有一些微内核，如Mach微内核，就已成功的证实了这种可移植性的长处。实际的情况是，Linux内核的移植虽然不是很简单，但也绝不是不可能的：大约的数字是，向一个全新的体系结构上的典型的移植工作需要 30,000到 60,000行代码，再加上不到20,000行的驱动程式代码。（并不是任何的移植都需要新的驱动程式代码。）粗略的计算一下，我估计一个典型的移植平均需要50,000行代码。这对于一个程式员或最多一个程式小组来说是力所能及的，能够在一年之内完成。虽然这比微内核的移植需要更多的代码，但是
 Linux的支持者将会提出，这样的Linux内核移植版本比微内核更能够有效的利用底层硬件，因而移植过程中的额外工作是能够从系统性能的提高上得到补偿的。

这种特别设计的权衡也不是很轻松就能够达到的，单内核的实现策略公然违背了传统的看法，后者认为微内核是未来发展的趋势。但是由于单一模式（大部分情况下）在Linux中运行状态良好，而且内核移植相对来说比较困难，但没有明显地阻碍程式员团体的工作，他们已热情高涨地把内核成功的移植到了现存的大部分实际系统中，更不用说类似掌上型电脑的一些看起来很不实际的目标了。只要Linux的众多特点仍然值得移植，新的移植版本就会不断涌现。

所有的Unix内核都同宗同源，并且提供相同的API，现代的Unix内核存在许多设计上的相似之处。Unix内核几乎毫无例外的都是一个不可分割的静态可执行块（文件）。也就是说，它们必须以完整、单独的可执行块的形式在一个单独的地址空间中运行。

Unix内核几乎都需要硬件系统提供页机制以管理内存。这种页机制可以加强内存空间的保护，并保证每个进程都可以运行于不同的虚地址空间上。

单内核与微内核设计之比较

操作系统内核可以分为两大设计阵营：单内核和微内核（第三阵营外内核，主要用在科研系统中，但也逐渐在现实世界中壮大起来）。

单内核是两大阵营中一种较为简单的设计，在1980年之前，所有的内核都设计成单内核。所谓单内核就是把它从整体上作为一个单独的大过程来实现，并同时运行在一个单独的地址空间。因此，这样的内核通常以单个静态二进制文件的形式存放于磁盘。所有内核服务都在这样的一个大内核空间中运行。内核之间的通信是微不足道的，因为大家都运行在内核态，并身处同一地址空间：内核可以直接调用函数，这与用户空间没有什么区别。这种模式的支持者认为单模块具有简单和高性能的特点。大多数Unix系统都设计为单模块。

另一方面，微内核并不作为一个单独的大过程来实现。相反，微内核的功能被划分为独立的过程，每个过程叫做一个服务器。理想情况下，只有强烈请求特权服务的服务器才运行在特权模式下，其他服务器都运行在用户空间。不过，所有的服务器都保持独立并运行在各自的地址空间。因此，就不可能像单模块内核那样直接调用函数，而是通过消息传递处理微内核通信：系统采用了进程间通信(IPC)机制，因此，各种服务器之间通过IPC机制互通消息，互换“服务”。服务器的各自独立有效地避免了一个服务器的失效祸及另一个。

同样，模块化的系统允许一个服务器为了另一个服务器而换出。因为IPC机制的开销比函数调用多，又因为会涉及内核空间到用户空间的上下文切换，因此，消息传递需要一定的周期，而单内核中简单的函数调用没有这些开销。基于此，付之于实际的微内核系统让大部分或全部服务器位于内核，这样，就可以直接调用函数，消除频繁的上下文切换。Windows NT内核和Mach（Mac OS X的组成部分）是微内核的典型实例。不管是Windows NT还是Mac OS X，都在其新近版本中不让任何微内核服务器运行在用户空间，这违背了微内核设计的初衷。

Linux是一个单内核，也就是说，Linux内核运行在单独的内核地址空间。不过，Linux汲取了微内核的精华：其引以为豪的是模块化设计、抢占式内核、支持内核线程以及动态装载内核模块的能力。不仅如此，Linux还避其微内核设计上性能损失的缺陷，让所有事情都运行在内核态，直接调用函数，无需消息传递。至今，Linux是模块化的、多线程的以及内核本身可调度的操作系统。实用主义再次占了上风。

当Linus和其他内核开发者设计Linux内核时，他们并没有完全彻底地与Unix诀别。他们充分地认识到，不能忽视Unix的底蕴（特别是 Unix的 API）。而由于Linux并没有基于某种特定的Unix，Linus和他的伙伴们对每个特定的问题都可以选择已知最理想的解决方案—在有些时候，当然也可以创造一些新的方案。以下是对Linux内核与Unix各种变体的内核特点所作的分析比较：

·Linux支持动态加载内核模块。尽管Linux内核也是单内核，可是允许在需要的时候动态地卸除和加载部分内核代码。

·Linux支持对称多处理（SMP）机制，尽管许多Unix的变体也支持SMP，但传统的Unix并不支持这种机制。

·Linux内核可以抢占（preemptive）。与传统的Unix不同，Linux内核具有允许在内核运行的任务优先执行的能力。在其他各种Unix产品中，只有Solaris和IRIX支持抢占，但是大多数传统的Unix内核不支持抢占。

·Linux对线程支持的实现比较有意思：内核并不区分线程和其他的一般进程。对于内核来说，所有的进程都一样—只不过其中的一些共享资源而已。

·Linux提供具有设备类的面向对象的设备模型、热插拔事件，以及用户空间的设备文件系统（sysfs）。

·Linux忽略了一些被认为是设计得很拙劣的Unix特性，像STREAMS，它还忽略了那些实际上已经根本不会使用的过时标准。

·Linux体现了自由这个词的精髓。现有的Linux特性集就是Linux公开开发模型自由发展的结果。如果一个特性没有任何价值或者创意很差，没有任何人会被迫去实现它。相反的，在Linux的发展过程中已经形成了一种值得称赞的务实态度：任何改变都要针对现实中确实存在的问题，经过完善的设计并有正确简洁的实现。于是，许多其他现代Unix系统包含的特性，如内核换页机制，都被毫不迟疑的引入进来。

不管Linux和Unix有多大的不同，它身上都深深地打上了Unix烙印

------------------------------------------------------------------------------------------------------------------------------------------

以下是摘自wiki的一段关于宏内核的介绍



 

宏内核有时也称单内核，原文为英文的Monolithic kernel。

宏内核是操作系统内核架构的一种，此架构的特性是整个内核程序都是以内核空间（Kernel Space）的身份及监管者模式（Supervisor Mode）来运行。相对于其他类型的操作系统架构，如微内核架构或混内核架构等，这些内核会定义出一个高级的虚拟接口，由该接口来涵盖描述整个计算机硬件，这些描述会集合成一组硬件描述用词，有时还会附加一些系统调用，如此可以用一个或多个模块来实现各种操作系统服务，如进程管理、共时（Concurrency）控制、存储器管理等。

即使有的宏内核将其运作从整体性运作拆分成几个服务模块，并让各模块各自运作，其操作系统的代码依然是高度紧密的，很难修改成其他类型的操作系统架构。此外，所有的模块也都在同一块寻址空间内运行，倘若某个模块有错误、瑕疵（Bug），运行时就会损及整个操作系统运作。反过来，如果宏内核架构的操作系统在开发设计时相当完善，并经测试验证后具有高度可靠性，则操作系统内的各软件组件因具有高度紧密性，如此在系统的低级运作上将格外有效率。

 

可加载性的模块

 

现在多数采行宏内核架构设计的操作系统，如OpenVMS、Linux、FreeBSD、以及Solaris等，都已经能在运作运行阶段中，以动态方式来加载（Load）、卸载（Unload）可运行的模块，不过这些模块是属于二进制代码的层次，或称镜像层次，而非内核架构的层次。即使宏内核进行模块化转化，也不会与微内核或混内核架构的内核产生区分上的混淆，因为微内核、混内核的模块是属于系统架构的层次。

就实务上，动态加载/卸载模块的作法，等于是用一种较简易的方式来弹性管控运行中的操作系统内核，若没有动态加载/卸载机制，操作系统的内核想要进行任何的调整、变换，都必须重新开机才能达成。因此模块化是必然且必要的，如此才能让内核功效轻松地扩展、延伸，此外也能适时减轻硬件的运行运作负担。

另外，有些整块性操作系统为了让它的内核空间达到最小化，也会运用动态加载/卸载机制来达成此一目标。

一、区别
话不多说，先上图

1.宏内核几乎包含了所有功能，微内核之包含了部分
2.宏内核模块依赖较强，例如linux去掉网络，会引发问题，正因为宏内核的这一个缺点，导致了一些问题：例如：要加强安全模块，就要更改所有的模块。
微内核：内核态只保留了最基本的功能：cpu调度，内存管理，进程通信。将文件系统驱动设备放在了外面。
3.宏内核的代码可以用百万来计，微内核可以只有几万，几十万。代码量越大bug越多。
4.微内核的操作系统：windows NT 7 8  ,minix, maxcOS ,WindowsBarrelfish
 宏内核：linux unix
二、微内核的优点
(1) 可伸缩性好,  能适应硬件更新和应用变化

(2) 可移植性好,   所有与具体机器特征相关的代码,全部隔离在微内核中。如果操作系统要移植到不同的硬件平台上, 只需修改微内核中极少量的代码即可

(3) 实时性好,   微内核可以更有效地支持实时处理

(4) 安全可靠性高,   微内核将安全性作为系统内部特性进行设计,对外仅使用少量应用编程接口

(5) 支持分布式系统,  支持多处理机的体系结构  和  高度并行的应用程序

(6) 真正面向对象的操作系统，能显著减小系统开销,  提高系统的正确性、可靠性和易扩展性

鸿蒙内核源码中文注解 >> 精读内核源码,中文注解分析,深挖地基工程,大脑永久记忆,四大源码仓每日同步更新

鸿蒙内核源码分析博客 >> 故事说内核,问答式导读,生活式比喻,表格化说明,图形化展示,主流站点每日同步更新



本篇以一个故事说清楚鸿蒙进程和线程的调度过程.

有个场馆

某地有一个演出场馆，分成室内馆(400平米)和室外馆(4万平米),管理处在室内馆,那是工作人员办公的地方，非工作人员不得进入!

场馆的定位是为本地用户提供舞台表演(统称舞台剧),规定同时只能一个剧上演,但因为生意太好，申请人太多了，所以用馆要先申请->排队->上演.场馆里面有一座永远很准时，不会停的大钟表，每十分钟就自动响一次,场馆里有很多的资源，有篮球，酒馆，小卖部，桌椅，还有演员(人也算资源)，反正就是应有尽有，但是数量有限.

资源由管理处统一管理,这些资源也得先申请才能使用.场地外有个大屏幕,屏幕实时对外公布场馆舞台剧情况,屏幕内容如下:

舞台剧名
			
优先级
			
状态
			
进行中节目
			
就绪节目
		
管理处
			
0
			
正在工作
			
打扫场地卫生
			
无
		
三国演义
			
19
			
已就绪
			
无
			
骂死王朗
		
淘宝直播
			
20
			
已就绪
			
无
			
薇娅9点直播
		
场馆的内部工作也是个剧,只不过它的内部剧,优先级最高.而且注意这里只展示正在和就绪的剧情节目,就绪是指万事俱备,只欠登台表演的意思.

例如上表中有两个剧都准备好了,排成了一个就绪队列,都等着管理处打扫完卫生后表演,但同时只能演一个剧,而三国演义的优先级更高(场馆规定越小的优先级越高),所以不出意外,下一个表演的节目就是三国演义之骂死王朗.

这里请记住就绪队列,后续会反复的提它,很重要!

表演走什么流程？

用馆者需提交你舞台剧的剧本,剧本可以是玩游戏，拍电视剧,直播电商等等，反正精彩的世界任你书写，场馆内有专人(统称导演)负责跟进你的剧本上演。

剧本由各种各样的场景剧组成(统称节目),比如要拍个水浒传的剧本. 被分成武松打虎,西门和金莲那点破事等等节目剧.申请流程是去管理处先填一张电子节目表,节目表有固定的格式,填完点提交你的工作就完成了,接下来就是导演的事了.

节目表单格式如下.

剧本名称
			
节目章回
			
内容
			
优先级
			
所需资源
			
状态
		
水浒传
			
第18回
			
武松打虎
			
12
			
武松,老虎一只,酒18碗
			
未开始
		
水浒传
			
第28回
			
西门和金莲那点破事
			
2
			
西门庆,金莲,王婆,一个炕
			
未开始
		
水浒传
			
第36回
			
武松拳打蒋门神
			
14
			
武松,蒋门神,猪肉
			
未开始
		
故事写到这里，大家脑子里有个画面了吧，记住这两张表,继续走起。

西门大官人什么时候表演?

场馆都会给每个用馆单位发个标号代表你使用场馆的优先级，剧本中每个场景节目也有优先级,都是0级最高，31级最低，这里比如水浒传优先级为8，西门庆和金莲那点破事节目为2，节目资源是需要两位主角(西门,金莲)和王婆，一个炕等资源，这些资源要向场馆负责人申请好，节目资源申请到位了就可以进入就绪队列.

如果你的剧本里没有一个节目的资源申请到了那对不起您连排号的资格都没有。这里假如水浒传审核通过,并只有西门大官人节目资源申请成功,而管理处卫生打扫完了,以上两个表格的内容将做如下更新

舞台剧名
			
优先级
			
状态
			
进行中节目
			
就绪节目
		
水浒传
			
8
			
正在进行
			
西门和金莲那点破事
			
无
		
三国演义
			
19
			
已就绪
			
无
			
骂死王朗
		
淘宝直播
			
20
			
已就绪
			
无
			
薇娅9点直播
		
注意虽然三国演义先来,但此时水浒传排在三国的前面,是因为它的优先级高,优先级分32级,0最高,31最低.

剧本名称
			
节目章回
			
内容
			
优先级
			
所需资源
			
状态
			
表演位置
		
水浒传
			
第18回
			
武松打虎
			
12
			
武松,老虎一只,酒18碗
			
未开始
			
暂无
		
水浒传
			
第28回
			
西门和金莲那点破事
			
2
			
西门,金莲,王婆,炕一个
			
正在进行
			
西门火急火燎的跑进金莲屋内
		
水浒传
			
第36回
			
武松拳打蒋门神
			
14
			
武松,蒋门神,猪肉
			
未开始
			
暂无
		
注意看表中状态的变化和优先级,一个是剧本的优先级,一个是同一个剧本中节目的优先级.而之前优先级最高的管理处,因为没有其他节目要运行,所以移出了就绪队列.

西门好事被破坏了怎么办了?

场馆会根据节目上的内容把节目演完。每个节目十分钟，时间到了要回去重新排队，如果还是你就可以继续你的表演。但这里经常会有异常情况发生.

比如上级领导给场馆来个电话临时有个更高优先级节目要插进来，没办法西门你的好事要先停止，please stop! 场地要让给别人办事，西门灰溜溜得回就绪队列排队去，但请放心会在你西门退场前会记录下来表演到哪个位置了(比如:西门官人已脱完鞋),以便回来时继续接着表演。高优先级的事处理完后,如果西门的优先级还是最高的就可以继续用场地,会先还原现场演到哪了再继续办事就完了,绝不重复西门前面的准备工作,否则西门绝不答应!

节目表演完所有资源要回收，这个节目从此消亡，如果你剧本里所有节目都表演完了，那你的整个剧本也可以拜拜了,导演回到导演组,又可以去接下一部戏了.

这里还原下西门被场馆紧急电话打断后表的变化是怎样的,如下:

剧本名称
			
优先级
			
状态
			
进行中节目
			
就绪节目
		
管理处
			
0
			
正在工作
			
接听上级电话
			
无
		
水浒传
			
8
			
已就绪
			
无
			
西门和金莲那点破事
		
三国演义
			
19
			
已就绪
			
无
			
骂死王朗
		
淘宝直播
			
20
			
已就绪
			
无
			
薇娅9点直播
		
剧本名称
			
节目章回
			
内容
			
优先级
			
所需资源
			
状态
			
表演位置
		
水浒传
			
第18回
			
武松打虎
			
12
			
武松,老虎一只,酒18碗
			
未开始
			
暂无
		
水浒传
			
第28回
			
西门和金莲那点破事
			
2
			
西门庆,金莲,王婆,一个炕
			
就绪
			
西门官人脱完鞋
		
水浒传
			
第36回
			
武松拳打蒋门神
			
14
			
武松,蒋门神,猪肉
			
未开始
			
暂无
		
表演给谁看呢？

外面那些吃瓜观众啊，群众你我他,游戏公司设计了游戏的剧本，电商公司设计了电商剧本，西门大官人被翻拍了这么多次不就是都爱看嘛,场馆会按你的剧本来表演，当然也可以互动,表演的场景需要观众操作时，观众在外面可以操作，发送指令。想想你玩游戏输入名字登录的场景。场馆里面有三个团队,张大爷团队负责导演组演剧本,王场馆负责场地的使用规划的,李后勤负责搞搞后勤.

张大爷团队做什么的？

上面这些工作都是张大爷团队的工作,接待剧本的导演组,管理剧本清单,指派导演跟进,申请节目资源,调整剧本优先级,控制时间,以使舞台能被公平公正的被调度使用等等

王场馆是做什么的？

看名字能知道负责场地用度的,你想想这么多节目,场地只有这么点,同时只能由一个节目上演,怎么合理的规划才能即公平又效率最大化呢,这就是王场馆的工作,但咱王总也有两把刷子,会给用馆公司感觉到整个场馆都是自己在用,具体不在这个故事里说明,后续有专门讲王场馆如何高效的管理内外场地的故事篇.

李后勤是做什么的？

场馆每天的开业,歇业,场地清理,管理处的对外业务,接听电话,有人闹事了怎么处理,收钱开发票 等等也有很多工作统称为后勤工作要有专门的团队来对接,具体不在这里说明,后续也有专门讲这块的故事.

故事想说什么呢？

故事到底想说什么呢？这就是操作系统的调度机制，熟悉了这个故事就熟悉了鸿蒙系统内核任务调度的工作原理！操作系统就是管理场馆和确保工作人员有序工作的系统解决方案商，外面公司只要提供个剧本，就能按剧本把这台戏演好给广大观众观看。有了这个故事垫底，鸿蒙内核源码分析系列就有了一个非常好的开始基础。

内核和故事的关系映射

故事概念
			
内核概念
			
备注
		
只能一个剧本演
			
单CPU
			
多CPU核指多个剧同时上演
		
剧本
			
程序
			
一个剧本一个负责人跟进,跑起来的程序叫进程
		
导演
			
进程
			
进程负责剧本整个运行过程,是资源管理单元,任务也是一种资源
		
节目
			
线程/任务
			
任务记录节目的整个运行过程,任务是调度的单元
		
西门被打断
			
保存现场
			
本质是保存寄存器(PC,LR,FP,SP)的状态
		
西门继续来
			
恢复现场
			
本质是还原寄存器(PC,LR,FP,SP)的状态
		
表演场地
			
用户空间
			
所有节目都在同一块场地表演
		
管理处
			
内核空间
			
管理处非工作人员不得入内
		
外部场地
			
磁盘空间
			
故事暂未涉及,留在内存故事中讲解
		
节目内容
			
代码段
			
任务涉及的具体代码段
		
管理处的服务
			
系统调用
			
软中断实现,切换至内核栈
		
场馆大钟
			
系统时钟
			
十分钟响一次代表一个节拍(tick)
		
节目20分钟
			
时间片
			
鸿蒙时间片默认 2个tick,20ms
		
上级电话
			
中断
			
硬中断,直接跳到中断处理函数执行
		
表演顺序
			
优先级
			
进程和线程都是32个优先级,[0-31],从高到低
		
张大爷
			
进程/线程管理
			
抢占式调度,优先级高者运行
		
王场馆
			
内存管理
			
虚拟内存,内存分配,缺页置换 ==
		
李后勤
			
异常接管
			
中断,跟踪,异常接管 ==
		
请牢记这个故事

当然还有很多的细节在故事里没有讲到，比如王场馆和李后勤的工作细节，还有后续故事一一拆解.太细不可能真的在一个故事里全面讲完，笔者想说的是框架，架构思维，要先有整体框架再顺藤摸瓜寻细节，层层深入，否则很容易钻进死胡同里出不来。读着读着就放弃了，其实真没那么难。当你摸清了整个底层的运作机制再看上层的应用，就会有了拨开云雾见阳光，神清气爽的感觉。具体的我们在后续的章节里一一展开，用这个故事去理解鸿蒙系统内核调度过程，没毛病，请务必牢记这个故事。

喜欢就请收藏吧

各大站点搜 "鸿蒙内核源码分析" ,快速找到组织.或者更简单的,如图:



鸿蒙内核源码中文注解 >> 精读内核源码,中文注解分析,深挖地基工程,大脑永久记忆,四大源码仓每日同步更新

鸿蒙内核源码分析博客 >> 故事说内核,问答式导读,生活式比喻,表格化说明,图形化展示,主流站点每日同步更新