操作系统内核写后感

  最近用的几个月的时间，大体写了一个简单的微内核的操作系统内核，还是想继续写下去，关于一个简单的内核开发有一些思考。

  首先要选定好语言，我刚开始想用C来写，但是一想现在很多书都是用C来教学写内核的，如果我也用C，那我那容易就由于惯性，把人家的代码抄上了，所以决定用C++来写，但是用C++写的时候，又发现了一些问题，比如无法使用运行时库，对于C++运行时的特性无法使用，甚至全局对象都不构造（也需要运行时库），也就成了C with class，而且写的时候我的思路是，先用C的写法实现一下，没问题了，再用面向对象来写，但是一发不可收拾，当我反应过来的时候，已经很难重写了，所以后来的代码有面向对象的思想，也有C语言的写法，成了两不像，而且此时也很难用C重写，因为一些命令空间，对象等问题，重写起来太麻烦了，非常后悔。如果再给我一次机会，我宁愿选择用C来写。

  还有就是内核的开发过程，我们学习操作系统的时候一般是按各模块来学习的，比如先学内存，然后进程调度，也就是横向的，但是我觉得，这个方式对于理解内核是非常有利，比较友好的，但是对于内核的开发和设计来说并不友好，因为从一个设计者的角度来讲，应该更关注整个系统，各个模块间的关系。所以我觉得对于设计者，不应该从学习内核那种横向的思维，直接划分各个模块，而应该是纵向思维，第一个维度，比如一些命令的实现，如何解析elf文件，如何进入保护模式，如果开启分页，这些东西一百个内核，也就那一种写法，设计者不应该在这上面浪费时间; 往上一个维度，就是各模块内的算法，比如内存的分配算法等，这些一百个内核或许有五十种不同的实现，但其评价标准比较单一，好或不好，最终肯定都采取那种最好的方式。最后一个维度就是各模块间的关系，比如各模块如何通信，系统应更关注安全，还是效率或者其他，这一层一百个内核也许有一百种写法，这才是内核的灵魂，才是设计者要考虑的东西，而不是如何实现命令，如何进行内存分配。

  对于各模块间的关系，不光包括运行时的关系，更包括开发过程中的关系，比如是否为了提高效率，可以允许破坏在源码层面上的封装性。在写这个内核时，遇到地址空间的问题，前面几篇文章已经说过技术问题，现在从设计角度说一下其问题，由于为微内核，所以内存管理和内核（含进程调度，有pcb）是分开的，但是如果要实现独立的地址空间，比如进程地址空间（虚拟地址空间）用页表来维护，那把这个页表交给内存管理系统还是内核来维护呢？ 按理说应该让内核中的pcb来维护，毕竟是身份证嘛，进程相关资源都在这，但是如果交给它来维护，但是申请内存的时候怎么办？假设虚拟地址空间由位图来维护，内核在切换进程的时候，页表确实切换了，也就是地址空间切换了，但是维护虚拟地址空间的位图怎么办？申请内存的根据呀，也得相应改变吧，这叫需要通知内存管理系统，但是通知通过又需要切换，陷入递归，不可取，或者说系统协商好位图的位置（虚拟地址），像栈一样，就在0xc0000000上，比如把位图都映射在虚拟地址0x12345678上，申请或释放内存时内存管理系统直接从这读取位图，但是这个位图必然要由内核来初始化，内存管理系统只能使用，内存管理系统有些名不副实了（但这应该是这几种方法里比较好的一种了）， 如果把这个位图交给内核来维护，就相当于把这个内存管理系统的数据结构暴露给了内核，破坏了模块间的封装;  如果把页表交给内存管理系统来维护呢？这是进程的资源，肯定要与进程一一对应，既然一一对应，也就意味着进程表长度为NR时，内存管理系统也要维护一个长度为NR的数组来维护进程们的虚拟地址空间（位图同样也要对应，破坏封装），这也破坏了源码上的封装（内存管理系统需要知道进程表的长度），而且交给内存管理系统来维护又有许多问题，每次进程切换时要切换地址空间吧。但是地址空间存放于内存管理系统，怎么办呢？内核在切换的时候向内存管理系统请求呗，拿到地址空间再切换，但是切换时又遇到了上面同样的问题，递归了，也不可取。

  所以我觉得，内核设计应该更关注整个系统，模块间的关系，而不是某个模块的算法，在设计，效率，安全等方面作出取舍。

比如对于一个看重设计的内核来说，哪怕一段代码再漂亮，再高效，只要违反设计的初衷，就不会把它合并进来，所以这些才是内核的灵魂。值得讨论和思考的东西。

 

上面关于地址空间交给谁来维护的问题，有上面的思考过程，但没有源码实现过，如果有问题，欢迎指正。