TheStateofKernelTesting定期发布新内核，但是内核是如何进行深度测试的却不是很了解。所以在这里我可以提前告诉大家，kernelbackbone可能没有经过全面测试，可能稳定的内核比较少。..那么那里发生了什么？稳定内核真的稳定吗？恰好今年9月份在洛杉矶举办了一个BOF（birdsofafeather）会议。DhavalGinal和SashaLevin组织了一次关于内核测试的相关讨论。我们一起去看看吧。由于大多数BoF与会者来自主要的Linux发行商，Giani在会议开始时提出了一个问题：“你对稳定的内核做了多少测试？你只是在测试自己分发内核然后向后移植一些安全和其他相关的东西吗？”来自稳定内核的修复？是否总是忽略稳定内核的测试？对于这个问题的答案，他自己半开玩笑的建议：可以把测试留给用户。除了上面的半开玩笑的建议之外，大多数人都同意，除了简单的构建引导测试之外，目前对稳定内核的测试非常少。那么这种现象是如何造成的呢？内核测试的困境***点：开发者很难知道选择什么样的上游内核进行测试。linux-nexttree、stablekernel、kernelmainline（主线）不断变化，很难做到稳定测试。但大家一致认为，在代码发布之前发现代码中的错误仍然很有价值，因此该发行版的一些开发人员尝试测试-rc1内核。这样一来，如果发现bug，在release前修复，看起来不错，但是要做好就需要很多时间和机器。另外，测试时使用哪个版本的内核配置也会使这个问题的复杂度加倍。第二点：内核测试耗费了大量的人力物力。有人举了一个形象的例子，红帽公司（RedHat）需要花一年的时间来稳定RHEL选择的内核版本。粗略估计有300个工程师来做这件事，也就是说一个公司需要花费300人年来测试和稳定一个内核（这里译者还是要感谢REDHAT）。另外，在驱动中，通常驱动的自检例程应该由内核开发者编写，但是要将单个测试变成更广泛使用的东西需要花费大量的时间和精力，而驱动作者根本没有加个自检程序的时候，所以大部分驱动都没有自检程序。在很多情况下，正是由于这个原因，代码质量很差。因此，现有的大部分自检程序可能都在子系统中，并且已经过良好的测试。这些测试用例能发现的大部分错误，主要与开发者自己运行的硬件架构不同有关。例如，这就是发现ARM相关错误的方式。第三点：开机测试（boottesting）占上游内核测试的大部分，占用开发者较多的精力，所以最新发布的内核肯定可以启动。具有特殊硬件的人会测试他们的驱动程序，因此大多数驱动程序错误都可以通过此测试找到。由于Ftrace、调度器和内存管理应用广泛，测试相对充分。除了以上组件，其他一些非核心或者内核中不常用的功能可能没有那么多功能测试。第四点：内核测试的门槛比较高，比如环境设备和知识储备。对于一些想要测试驱动的人来说，他可能无法接触到相应的硬件，即使有硬件，他也需要对设备的工作原理有深入的了解。理想情况下，驱动程序作者应该测试这些设备，在大多数情况下他们会这样做。但是这个解决方案仍然不完美。第五点：测试覆盖面不全面，测试环节单一。因为尽管驱动程序作者试图确保驱动程序在他的测试用例下正确工作，但他们有不同的动机。如果请他来做这个，测试可能会比较全面，而如果他只是为了让自己的硬件能够正常工作，那么测试可能不会太全面，相应的文档也基本没有。第六点：需要制定测试指南和帮助文档。比如我们还需要找到一些可能在内核测试中引入的性能回归，但是如果我们只是做一些“随机性能测试”（randomperformancetesting），是很难发现性能下降的，所以我们需要开发一些性能测试指南使得一些apples-to-apples（苹果对苹果，翻译为同类型比较）比较测试可以进行。再比如，像MelGorman的MMTests作为“kbench”性能测试套件的基础，似乎有些参与者并不熟悉这个测试套件，所以MMTests需要更好的文档来帮助用户理解它。第七点：内核测试的另一个难点是内核配置的数量非常多。稳定版内核发布时，可能有100个补丁，但是任何测试套件都不可能执行很多次来测试这些补丁，那么测试稳定版的意义何在？综上所述，在所有这些测试工作中，最大的问题是资源，我们需要更多的人和更多的机器，以便更早地发现和修复错误。企业是怎么做到的？让我们把话题转回稳定核心。如果我们能够阻止所有可能的bug被引入内核，那么主线内核（mainline）无疑是最好的，我们不需要任何稳定的分支（stabletrees）。当然，现实是残酷的，***是不可能的，所以我们还是需要stable分支，但是发行版真的会用stable分支吗？让我们一一来看。企业例子之一（RedHat）RedHat有一个大型测试实验室，有6000多台各种机器分布在世界各地。该实验室使用Beaker并测试了许多不同的内核配置。目前内核测试主要集中在三个RHEL内核和两个Fedora内核。未来，他们计划添加一些主线版本内核。在RedHat内部，不同的团队专注于他们感兴趣的驱动程序，例如存储团队测试各种存储设备，RDMA团队测试RDMA类型的硬件。因此，对于RedHat，他们只从稳定树中挑选一些修复程序。RHEL每个次要版本的内核都有80,000-100,000个补丁，但所有这些补丁都来自上游而不是稳定分支。RHEL内核团队会查看稳定分支和最新的主线内核，然后寻找必要的补丁。至于相应的测试，则取决于这些补丁应用到哪个子系统；一些子系统在补丁可追溯性方面做得很好，而另一些则不然。对于稳定内核的使用，一般RedHat只是将其编译出来，用它来与RHEL内核进行对比测试，判断这些错误是来自上游还是RHEL引入的。企业示例二（SUSE和Ubuntu）再看看SUSE，他们确实在构建一个稳定的内核，但他们只是为了cherry-pickpatches。他们考虑过将稳定的内核测试添加到SUSE的测试网格中，但尚不清楚这会给公司带来什么价值。Ubuntu的情况类似：除了构建稳定的内核外，他们不会正式测试它们。企业示例3（Linaro）Linaro目前正在为Google开发一个稳定的内核项目，使用内核自测试（kernelself-tests，缩写kselftest）和Linux测试项目（LinuxTestProject，缩写LTP）。对于每个稳定版本。自检测试确实会发现错误，但编写这些自检测试的人可能不是引入大多数错误的人。所以自测只是一个开始，显然Linaro还需要加入更多的测试。所以一般情况下，版本发布者一般只关心合并到稳定版中的修复是否正确，而只是把稳定版中的修复提取出来放到自己的内核中进行测试。对稳定内核本身的测试非常有限。于是有人建议Linux基金会可以和Canonical、SUSE、RedHat等公司组成一个合作项目，大家贡献一部分机器，组成一个测试套件来测试稳定的内核。持续改进测试示例1：0-Day内核测试服务（0-Daykerneltestservice）。这个服务不仅仅是构建和启动测试（build-and-boottests），还包括一些性能测试。kernelci.org项目还在很多不同的硬件上进行构建和引导测试，这些非常有价值，但他们没有进行任何真正的功能测试。当然，事情肯定会越来越好。不是每个人都说“聊胜于无”。示例2：LTP（Linux测试项目）。它可以测试很多东西，但也有很多地方它没有测试。它会被一些发行版使用，并且肯定会在其中发现一些错误，但很明显我们需要更多更好的测试套件。示例3：性能测试（基准测试）和模糊测试（fuzzing）。还讨论了稳定内核的模糊测试。对上游内核进行模糊测试是最好的选择，因为问题的所有修复都在那里，但它仍然可以在发行版的内核中找到问题。目前syzkallerfuzzer可以针对发现的问题自动生成小的测试用例，大家也认为应该将这些加入自测测试集。虽然已经提到一些错误只出现在KernelAddressSanitizer（简称KASAN）下，但在未配置KASAN的内核上运行时可以简单地跳过这些测试。内核除了通过测试发现bug，还需要更多的性能测试来发现性能退化。有人提到MelGorman的MMTests可以作为“kbench”性能测试套件的基础，但是这个套件对应的文档比较稀少，所以我们需要在内核文档目录下建立一个测试套件目录作为开始，但任何复杂的性能测试显然都需要更深入的文档。示例4：基线编号（单个编号）。有人提出，如果我们做一个性能测试，然后给出一个基准数字，我们可以根据这个数字来判断性能是否下降（比如BogoMips背后的想法），当然其他人会质疑是否存在这样的测试系统.示例5：自测。越来越多的自我测试被添加到主线内核中，但稳定的内核并没有从中受益。有些人正在使用较旧的内核进行最新的自测，因此建议也许自测本身应该移植到稳定的内核树上。示例6：神经网络训练。随着BoF的结束，Levin要求发行版的维护者将他们正在使用的补丁推送到稳定分支中。一般发行版中的问题也必须存在于稳定的内核中。他最近训练神经网络来识别稳定内核补丁的努力引来了一些笑声，但他说结果“出奇的好”。内核测试的其他一些声音稳定内核的维护者GregKroah-Hartman没有参加BoF，但实际上对BoF讨论的内容很感兴趣。所以当Levin在第二天的小型会议上总结BoF讨论的结果时，Greg给出了他的一些评论。首先，正如Levin所说，大家在BoF上提出了很多观点，但都没有相应的解决方案。有人建议应该为kernelci.org项目贡献更多的硬件，Kroah-Hartman希望看到更多的功能测试。其他人建议让Linaro和kernelci.org一起工作会更好。关于移植自检，Kroah-Hartman并不反对这个想法，只要他们在有问题的内核上工作即可。他还同意，如果发行版将补丁放在稳定树上就好了，他提到Fedora和Debian在这方面做得很好。另一位与会者表示，发行版通常会在与上游内核做好工作之前尽快为用户快速修复问题。Kroah-Hartman表示，如果上游内核没有修复bug，他就不会在稳定内核中修复，这样一方面上游内核和稳定内核是“bug兼容的”，另一方面另一方面，它也给那些制造商一些修复它的压力。结论毫无疑问，我们需要更多的内核测试，但应该采取什么形式，由谁来进行，目前还不清楚。如果幸运的话，在不久的将来这方面会有一些进展，这也意味着我们可能会更早地发现错误。当然，黑客攻击是不可能的，但是我们都希望减少内核中的错误，对吧？还有一点，大家对上游内核（upstream）的热情要比稳定内核（stable）高很多，所以对稳定内核的测试肯定还是会少一些，所以稳定内核的“稳定性”就大打折扣了.
