内核是操作系统最基本的部分。它是为众多应用程序提供对计算机硬件的安全访问的一部分软件，这种访问是有限的，并且内核决定一个程序在什么时候对某部分硬件操作多长时间。内核的分类可分为单内核和双内核以及微内核。严格地说，内核并不是计算机系统中必要的组成部分。

内核体系结构

现代操作系统设计中，为减少系统本身的开销，往往将一些与硬件紧密相关的（如中断处理程序、设备驱动程序等）、基本的、公共的、运行频率较高的模块（如时钟管理、进程调度等）以及关键性数据结构独立开来，使之常驻内存，并对他们进行保护。通常把这一部分称之为操作系统的内核。

程序可以直接地被调入计算机中执行，这样的设计说明了设计者不希望提供任何硬件抽象和操作系统的支持，它常见于早期计算机系统的设计中。最终，一些辅助性程序，例如程序加载器和调试器，被设计到机器核心当中，或者固化在只读存储器里。这些变化发生时，操作系统内核的概念就渐渐明晰起来了。

（概述图片来源：）

0.12版本发布一个月以后，在3月，版本号跳到了0.95，反映出系统正变得成熟，不仅如此，直到两年后，也就是1994年3月，具有里程碑意义的1.0.0才完成。

理解linux内核

post-halloween文档的大部分讨论内容是用户需要注意的主要改变，以及需要更新的系统工具（为了利用它们）。关心这一信息人的主要是那些期望提前了解2.6内核中有哪些内容的Linux发行商，还有终端用户，这可以让他们确定为了能利用新部件是否有需要升级的程序。

KernelJanitors项目保持了一个列表，内容是需要修复的较小缺陷和解决方法。这些缺陷解决方法中大部分是由于向内核打较大的补丁时需要改动很多部分代码而导致的，比如有些地方会影响设备驱动程序。那些新近从事内核开发的人开始时的工作可以选择列表中的条目，这样让他们可以通过小项目学习如何编写内核代码，同时有机会为社区做出贡献。

还有，在另一个预发布的项目中，JohnCherry追踪了在对每个已经发布的内核版本进行编译时发现的错误和警告。这些编译统计数字随着时间的流逝一直持续下降，而且，以系统的形式来发布这些结果使得所取得的进展一目了然。在很多情况下，可以像使用KernelJanitors列表一样来利用这些警告和错误消息中的一部分，因为编译错误通常是由小的缺陷引起的，需要一些努力去修复。

最后，还有AndrewMorton的“must-fix”列表。由于他已经被选定为2.6内核发布后的维护者，他运用他的特权概括地列出了那些他认为在最终的2.6内核发布前最迫切需要解决方案的问题。must-fix列表中包含了内核Bugzilla系统中的缺陷，需要完成的部件，以及其他已知的问题，这些问题如不解决将阻碍2.6发布。这一信息可以帮助指明在新内核发布前还需要哪些步骤；对那些关心这一万众期待的2.6内核发布何时能完成的人来说，它还可以提供有价值的信息。

单内核

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

单内核结构在硬件之上定义了一个高阶的抽象界面，应用一组原语

在2.5的开发期间，内核树出现了爆炸式的增长。由于使用源代码管理工具可以保持开发的同步并行进行，这样就可能实现开发的部分并行化。为了让其他人在他们所做的改变被接受之前可以进行测试，有一些开发需要并行化。那些保持自己的树的内核维护者致力于特定的组件和目标，比如内存管理、NUMA部件、改进扩展性和用于特定体系结构的代码，还有一些树收集并追踪对许多小缺陷的纠正。

这种并行开发模型的优点是，它使得需要进行重大改变的开发者，或者针对一个特定的目标进行大量类似改变的那些开发者可以自由地在一个受控环境中开发，而并不影响其他人所用内核的稳定性。当开发者完成工作后，他们可以发布针对Linux内核当前版本的补丁，以实现到此为止他们所完成的改变。这样，社区中的测试人员就可以方便地测试这些改变并提供反馈。当每一部分都被证明是稳定的之后，那些部分可以单独地，或者甚至同时全部地，融合到主要Linux内核中。

（内核结构图相册部分图片来源：）

代码覆盖分析

新工具为内核提供了代码覆盖分析的功能。覆盖分析表明，在一个给定的测试运行时，内核中哪些行代码被执行。更重要的是，覆盖分析提示了内核的哪些部分还根本没有被测试到。这个数据是重要的，因为它指出了需要再编写哪些新测试来测试内核的那些部分，以使内核可以得到更完备的测试。

大量信息

在为将来的2.6Linux内核进行开的过程中，除了这些自动化的信息管理方法之外，开放源代码社区的不同成员还收集和追踪了数量惊人的信息。

例如，在KernelNewbies站点上创建了一个状态列表，来保持对已经提出的内核新部件的追踪。这个列表包含了以状态排序的条目，如果它们已经完成了，则说明它们已经包含在哪个内核中，如果还没有完成，则指出还需要多长时间。列表上很多条目的链接指向大型项目的Web站点，或者当条目较小时，链接指向一个解释相应部件的电子邮件信息的拷贝。

应用测试

测试背景

如何编译一个内核

然而实际上，内核有很多复杂的相互联系。即使进行了足够力度的审查，还是会漏过很多严重的缺陷。此外，最新的内核一经发布，终端用户可以（也经常是）下载并使用。2.4.0发布时，社区中很多人都提议进行更有组织的测试，以保证特定测试和代码审查的强度。有组织的测试包括运用测试计划、测试过程中的可重复性等等。使用所有的三种方法比最初只使用两种方法会带来更高的代码质量。

测试项目

最早对Linux开始进行有组织测试的贡献者是Linux测试项目(LinuxTestProject，LTP)。这个项目的目的是通过更有组织的测试方法提高Linux的质量。这个测试项目的一部分是自动测试套件的开发。LTP开发的主要测试套件也叫做Linux测试项目。2.4.0内核发布时，LTP测试套件只有大约100个测试。随着2.4和2.5版本Linux的发展与成熟，LTP测试套件也正在发展和成熟。当前，Linux测试项目包括超过2000个测试，而且这个数字还在增长。

回归测试

在2.5的开发周期中，Linux测试项目所采用的另一个项目是，用LTP测试套件对Linux内核执行持续多日的回归测试。人们用BitKeeper创建了一个实时的、集中的档案库，以随时可以获得Linux内核的快照。在没有使用BitKeeper和快照时，测试人员不得不等到内核发布后才可以开始测试。内核只要发生了改变，测试人员就可以进行测试。

使用自动化工具来执行持续多日的回归测试的另一个优点是，和上一次测试相比变化较小。如果发现了一个新的回归缺陷，通常会容易地检测出这个缺陷可能是哪个改变导致的。

同样，由于是最新的改变，因此它在开发者的脑海中印象还比较深——希望这能让他们更容易地记起并修订相应的代码。或许Linus法则应该有这样一个结论，有一些缺陷比其他缺陷更容易被发现，因为那些正是持续多日的内核回归测试所发现并处理的那些。在开发周期中和实际发布之前能够每天进行这些测试，这就使那些只关注完整发行版本的测试者可以将精力集中于更严重和耗时的缺陷。

测试系统

另外一个名为开放源代码开发实验室(OpenSourceDevelopmentLabs,OSDL)的团队也为Linux测试做出了重要的贡献。2.4内核发布后不久，OSDL创建了一个叫做可扩展测试平台(ScalableTestPlatform，STP)的系统。STP是一个自动化的测试平台，让开发者和测试者可以运行OSDL硬件之上的系统所提供的测试。开发者甚至可以使用这个系统来测试他们自己的针对内核的补丁。可扩展测试平台简化了测试的步骤，因为STP可以构建内核、设置测试、运行测试，并收集结果。然后得到结果以进行深入地比较。很多人无法接触大型系统，比如具有8个处理器的SMP机器，而通过STP，任何人都可以在像这样的大型系统上运行测试，这个系统(STP)的另一个好处就在于此。

追踪缺陷

自从2.4发布以来，对Linux内核的有组织测试最大的改进之一是缺陷追踪。过去，在Linux内核中发现的缺陷会报告给Linux内核邮件列表，报告给特定组件或者特定体系的邮件列表，或者直接报告给维护发现缺陷的那部分代码的个人。随着开发和测试Linux的人数的增加，这个系统的不足之处很快就暴露了出来。在以前，除非人们对缺陷的报告可以惊人地维持下去，缺陷经常被遗漏、遗忘或者忽略。

OSDL安装了一个缺陷追踪系统，来报告和追踪Linux内核的缺陷。系统经过了配置，这样当某个组件的缺陷被报告时，那个组件的维护者就会得到通知。维护者既可以接受并修复那个缺陷，或重新指定缺陷（如果最终确定实际上那是内核另外一部分的缺陷），也可以排除它（如果最终确定并不是真正的缺陷，比如错误配置的系统）。报告给邮件列表的缺陷还有丢失的危险，因为越来越多的电子邮件涌向那个列表。然而，在缺陷追踪系统中，始终有对每一个缺陷及其当前状态的记录。