从Linux2.4到2.6内核开发中的改进 （1）

期待已久的 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 内核中。