Linux内核测试现状揭秘

 内核测试的现状

新的内核总是会定期发布出来，但是其实大家并不是十分了解内核是如何被深入测试的。那么这里可以提前告诉大家，内核主干有可能并没有做过充分的测试，而稳定内核可能会更少。。。 So what is going on there? Is stable kernel really stable? 刚好今年9月在洛杉矶举办的《Linux Plumbers Conference》有一个BOF(birds of a feather)会议，Dhaval Ginal和Sasha Levin组织了一个关于内核测试的相关讨论，让我们一起去看看。

由于大部分BoF的参会人员来自各个主要的Linux发行商，所以Giani开场的时候提了一个问题：“大家对于稳定内核(stable kernels)都做过了多少测试呢?大家是不是都是仅仅测试自己发行的内核然后再从稳定内核中backport一些安全以及其他相关的修复呢?对于稳定内核的测试从来都是置之不理呢?“ 对于这个问题的答案么，他自己半开玩笑的建议：可以将测试留给了用户。除了上面这个半开玩笑的建议以外，大多数人都一致认为：目前对于稳定内核，除了简单的构建-启动测试以外，几乎很少有其他方面的测试。那么这个现象是如何造成的呢?

内核测试的困境

第一点：开发者很难知道该去选择什么样的上游内核(upstream kernel)来测试。linux-next tree和稳定内核以及内核主线(mainline)都是在不断地变化着，要想做到稳定测试是一件很难的事情。但是大家又都一致同意，能在代码发布出来之前，发现其中的BUG还是很有价值的，所以一些发行版的研发人员就尝试测试-rc1的内核。这样做的话，如果bug被发现，它们将在发布前就被修正，这样看起来是不错的，但是这样需要非常多的时间和机器去做好这件事。另外，测试时使用的哪个版本的内核配置，也会使这个问题的复杂度翻倍。

第二点：内核测试消耗大量的人力物力。有人举了一个生动的例子，红帽(RedHat)需要花费一年的时间去稳定RHEL选定的内核版本。而粗略估计有300个工程师去做这个事情，这也就是意味着一个公司需要花费了300个人年去测试和稳固一个内核(译者在此处还是要感谢一下REDHAT)。此外，在驱动程序中，通常驱动的自检程序是应该由内核开发人员编写，但将个人的测试变成可以更广泛使用的东西需要很多时间和精力，而驱动的作者根本没有时间去添加一个自检程序，所以驱动大多数是没有自检程序的。在许多情况下，正是由于这个原因，导致代码质量很差。因此，现有的大部分自检程序可能都是在子系统中并已经做了很好测试，这些测试用例还能发现的大部分的错误主要发生在与开发者自己运行的硬件架构不同有关，比如ARM相关的错误就是这样被发现的。

第三点：启动测试(boot testing)占了上游内核测试的大头，占据了开发者更多的精力，所以最新发布的内核肯定可以启动起来的。拥有特殊硬件的人会测试他们的驱动，所以通过这一测试也可以发现大部分驱动的bug。像Ftrace、调度器和内存管理由于使用的很广泛，所以他们的测试也比较充分。除了以上这些组件以外，内核中其他的一些非核心或者不是被普遍使用的功能就可能没有那么多的功能测试了。

第四点：内核测试门槛较高，如环境设备和知识储备。对于一些想要测试驱动程序的人来说，他可能没法获得相应的硬件，即使有硬件，他还需要深入了解设备是如何工作的。理想情况下，驱动程序的作者应该测试这些设备，而大部分情况下也确实是这样。不过这个解决方案仍然不是完美的。

第五点：测试覆盖不全面，测试方面单一。因为虽然驱动作者试图确保在他的测试用例下驱动程序是正确工作的，但是他们有着不同的动机，如果他被雇佣做这个事情那么可能测试会比较全面，而如果他仅仅是为了让他自己的硬件可以正常工作，那么可能测试不会太全面，同时相应的文档也基本没有。

第六点：需要制定测试指南和帮助文档。例如，在内核测试中我们还需要发现一些可能引入的性能退化(performance regressions)，但是如果仅仅是做一些”随机性能测试“(random performance testing)，这是很难发现性能退化的，因此我们需要制定一些性能测试指南，以便可以进行一些苹果对苹果(apples-to-apples，译为同类型的比较)的对比测试。再如，就像Mel Gorman的MMTests作为“kbench”这一性能测试套件的基础，貌似有些与会者对这个测试套件不熟悉，所以MMTests需要有更好的文档来帮助使用者去了解它。

第七点：进行内核测试的另一个困难是要内核配置的数量非常庞大。当稳定的内核被发布的时候，它可能有100个补丁，但任何测试套件都不可能执行许多次去测试这些补丁，那么测试稳定版本的意义到底是什么呢?

总结一下，在所有的这些测试工作中，最大问题就是资源，我们需要更多的人和更多的机器，从而可以更早地发现和修复错误。

企业是如何做的

我们再把话题切回到稳定内核。如果我们可以阻止所有可能的bug引入到内核，那么主线内核(mainline)无疑是完美的，我们也就不需要什么稳定分支了(stable trees)。当然现实是残酷的，完美也是不可能的，所以我们仍然需要稳定分支，但是发行版真的会使用稳定分支么?让我们一个一个看过去。

企业例子之一(红帽)

红帽有一个大型测试实验室，有6000多台各种各样的机器分布在世界各地。实验室使用Beaker并测试了大量不同的内核配置，目前内核测试主要集中在三个RHEL内核和两个Fedora内核上，未来他们会计划添加一些主线版本的内核。在红帽内部，不同的团队专注于他们感兴趣的驱动，比如存储团队在测试各种存储设备，而RDMA团队在测试RDMA类型的硬件。所以，对于红帽而言，他们只从稳定的树上去挑选(cherry-pick)一些修复的补丁。 RHEL的每个小版本内核都有8-10万个补丁，但是所有的这些补丁都来自上游而不是稳定分支。RHEL内核团队会查看稳定的分支和最新的主线内核，然后寻找有必要使用的补丁。至于对应的测试则取决于这些补丁是应用于哪一个子系统; 一些子系统在补丁追溯方面做得很好，而其他子系统则较差。对于稳定内核的使用，一般Red Hat只是编译了一下并用它来和RHEL内核做对比测试，以确定这些错误是来自上游还是在RHEL中引入的。

企业例子之二(SUSE和Ubuntu)

再看看SUSE，他们确实在构建稳定内核，但他们仅仅是为了挑选(cherry-pick)补丁。他们有考虑将稳定的内核测试添加到SUSE的测试网格(testing grid)中，但大家还不清楚它会对公司带来什么样的价值。Ubuntu面对的情况也是类似的：他们除了建立稳定的内核以外，并没有对它们进行正式的测试。

企业例子之三(Linaro)

（编辑：ASP站长网）