内核比较:从2.4到2.6内核开发中的改进
期待已久的 2.6 内核终于到来了。IBM Linux Technology Center 的 Paul Larson 暗中关注那些让 2.6 成为有史以来最好内核的工具、测试和技术 ―― 从修正控制和回归测试到缺陷追踪和列表保持。经过为期三年的积极开发，新 2.6 Linux 内核最近已经发布了，在这期间，Linux 内核的开发和测试方法发生了一些有趣的变化。当前，开发内核的方法在很多方面与三年前没什么不同。不过，一些关键变化已经使整体的稳定性和质量得到了提高。
源代码管理
历史上，从来没有出现过用于 Linux 内核的正式的源代码管理或修正控制系统。实际上，很多开发者实现了他们自己的修正控制器，但是并没有官方的 Linux CVS 档案库，让 Linus Torvalds 检查加入代码，并让其他人可以由此获得代码。修正控制器的缺乏，常常会使发行版本之间存在“代沟”，没有人真正知道加入了哪些改变，这些改变是否能很好地融合，或者在即将发行的版本中哪些新内容是值得期待的。通常，如果更多的开发者可以像了解他们自己所做的改变一样了解到那些变化，某些问题就可以得到避免。
由于缺乏正式的修正控制器和源代码管理工具，使得很多人提议使用一个名为 BitKeeper 的产品。BitKeeper 是一个源代码控制管理系统，很多内核开发者已经成功地将其应用于他们自己的内核开发工作中。最初的 2.5 内核发布后不久，Linus Torvalds 开始试用 BitKeeper，以确定它是否能满足他的需要。现在，主要的 2.4 和 2.5 内核的 Linux 内核源代码都是用 BitKeeper 来管理的。对大部分可能很少或者根本不关心内核开发的用户来说，这一点看起来可能无关紧要。不过，在一些情况下，用户可以受益于那些由于使用 BitKeeper 而带来的开发 Linux 内核的方法的改变。
使用 BitKeeper 的最大好处之一是补丁的融合。当多个补丁应用于同一基础的代码之上，并且其中一些补丁会对同一部分产生影响时，就可能会出现融合问题。一个好的源代码管理系统可以自动地完成其中一些更为复杂的部分工作，这样可以更快地融合补丁，并使更多的补丁加入到内核中。随着 Linux 内核开发者社区的扩大，非常需要修正控制器来帮助保持对所有改变的追踪。由于每个人都可以将这些改变集成到主要的 Linux 内核中，为保证补丁不会被遗忘并可以方便地融合和管理，BitKeeper 等工具是必不可少的。
非常有必要使用一个实时的、集中的档案库来保存对 Linux 内核的最新更新。每一个被内核接受的改变或者补丁都被作为一个改变集被追踪。终端用户和开发者可以保存他们自己的源文件档案库，并根据需要可以通过一个简单的命令用最新的改变集进行更新。对开发者来说，这意味着可以始终使用最新的代码拷贝。测试人员可以使用这些逻辑的改变集合来确定哪些变化导致了问题的产生，缩短调试所需要的时间。甚至那些希望使用最新内核的用户也可以直接利用实时的、集中的档案库，因为现在一旦他们所需要的部件或缺陷修复加入到内核中，他们就可以马上进行更新。当代码融合到内核时，任何用户都可以提供关于这些代码的即时反馈和缺陷报告。
并行开发
随着 Linux 内核的成长，变得更加复杂，而且吸引更多开发者将注意力集中到内核的特定方面的专门开发上来，出现了另一个开发 Linux 方法的有趣改变。在 2.3 内核版本的开发期间，除了由 Linus Torvalds 发行的主要的一个内核树之外，还有一些其他的内核树。
在 2.5 的开发期间，内核树出现了爆炸式的增长。由于使用源代码管理工具可以保持开发的同步并行进行，这样就可能实现开发的部分并行化。为了让其他人在他们所做的改变被接受之前可以进行测试，有一些开发需要并行化。那些保持自己的树的内核维护者致力于特定的组件和目标，比如内存管理、NUMA 部件、改进扩展性和用于特定体系结构的代码，还有一些树收集并追踪对许多小缺陷的纠正。
这种并行开发模型的优点是，它使得需要进行重大改变的开发者，或者针对一个特定的目标进行大量类似改变的那些开发者可以自由地在一个受控环境中开发，而并不影响其他人所用内核的稳定性。当开发者完成工作后，他们可以发布针对 Linux 内核当前版本的补丁，以实现到此为止他们所完成的改变。这样，社区中的测试人员就可以方便地测试这些改变并提供反馈。当每一部分都被证明是稳定的之后，那些部分可以单独地，或者甚至同时全部地，融合到主要 Linux 内核中。
在实际应用中测试
过去，Linux 内核测试方法围绕开放源代码开发模型进行。由于代码一经发布后就公开给其他开发者进行审查，因此从来没有出现过一个与其他形式的软件开发类似的正式的验证周期。这种方法背后的理论依据是“The Cathedral and the Bazaar”中所谓的“Linus 法则” ，这一法则的内容为“众人的眼光是雪亮的”。换句话说，高力度的审查可以找出大部分真正的大问题。
然而实际上，内核有很多复杂的相互联系。即使进行了足够力度的审查，还是会漏过很多严重的缺陷。此外，最新的内核一经发布，终端用户可以（也经常是） 下载并使用。2.4.0 发布时，社区中很多人都提议进行更有组织的测试，以保证特定测试和代码审查的强度。有组织的测试包括运用测试计划、测试过程中的可重复性等等。使用所有的三种方法比最初只使用两种方法会带来更高的代码质量。
Linux 测试项目
最早对 Linux 开始进行有组织测试的贡献者是 Linux 测试项目 (Linux Test Project，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 法则应该有这样一个结论，有一些缺陷比其他缺陷更容易被发现，因为那些正是持续多日的内核回归测试所发现并处理的那些。在开发周期中和实际发布之前能够每天进行这些测试，这就使那些只关注完整发行版本的测试者可以将精力集中于更严重和耗时的缺陷。
可扩展测试平台
另外一个名为开放源代码开发实验室 (Open Source Development Labs, OSDL) 的团队也为 Linux 测试做出了重要的贡献。2.4 内核发布后不久，OSDL 创建了一个叫做可扩展测试平台 (Scalable Test Platform，STP) 的系统。STP 是一个自动化的测试平台，让开发者和测试者可以运行 OSDL 硬件之上的系统所提供的测试。开发者甚至可以使用这个系统来测试他们自己的针对内核的补丁。可扩展测试平台简化了测试的步骤，因为 STP 可以构建内核、设置测试、运行测试，并收集结果。然后得到结果以进行深入地比较。很多人无法接触大型系统，比如具有 8 个处理器的 SMP 机器，而通过 STP，任何人都可以在像这样的大型系统上运行测试，这个系统 (STP) 的另一个好处就在于此。
追踪缺陷
自从 2.4 发布以来，对 Linux 内核的有组织测试最大的改进之一是缺陷追踪。过去，在 Linux 内核中发现的缺陷会报告给 Linux 内核邮件列表，报告给特定组件或者特定体系的邮件列表，或者直接报告给维护发现缺陷的那部分代码的个人。随着开发和测试 Linux 的人数的增加，这个系统的不足之处很快就暴露了出来。在以前，除非人们对缺陷的报告可以惊人地维持下去，缺陷经常被遗漏、遗忘或者忽略。
现在，OSDL 安装了一个缺陷追踪系统，来报告和追踪 Linux 内核的缺陷。系统经过了配置，这样当某个组件的缺陷被报告时，那个组件的维护者就会得到通知。维护者既可以接受并修复那个缺陷，或重新指定缺陷 （如果最终确定实际上那是内核另外一部分的缺陷），也可以排除它（如果最终确定并不是真正的缺陷，比如错误配置的系统）。报告给邮件列表的缺陷还有丢失的危险，因为越来越多的电子邮件涌向那个列表。然而，在缺陷追踪系统中，始终有对每一个缺陷及其当前状态的记录。
大量信息
在为将来的 2.6 Linux 内核进行开的过程中，除了这些自动化的信息管理方法之外，开放源代码社区的不同成员还收集和追踪了数量惊人的信息。
例如，在 Kernel Newbies 站点上创建了一个
