linux内核测试_Linux内核测试的生命周期

linux内核测试

在针对Linux内核的持续集成测试中 ，我写了关于“ 持续内核集成” （CKI）项目及其更改内核开发人员和维护人员工作方式的使命。 本文深入探讨了该项目的更多技术方面以及所有部分如何组合在一起。

一切始于变化

内核中每一项令人兴奋的功能，改进和错误都始于开发人员提出的更改。 这些更改将出现在不同内核存储库的大量邮件列表中。 一些存储库关注内核中的某些子系统，例如存储或网络，而其他存储库关注内核的广泛方面。 当开发人员向内核提出更改或补丁集或维护人员对存储库本身进行更改时，CKI项目便会付诸行动。

CKI项目维护用于监视这些补丁集并采取措施的触发器。 诸如Patchwork之类的软件项目通过将多个补丁贡献整合为单个补丁系列，使此过程变得更加容易。 该系列作为一个整体通过CKI系统旅行，并允许发布有关该系列的单个报告。

其他触发器监视存储库中的更改。 当内核维护人员合并补丁集，还原补丁或创建新标签时，就会发生这种情况。 测试这些关键的更改可确保开发人员始终具有坚实的基准，可以用作编写新补丁的基础。

所有这些更改都进入了GitLab管道，并经过了多个阶段和多个系统。

准备构建

一切始于使源代码准备好进行编译。 这需要克隆存储库，应用开发人员建议的补丁集，并生成内核配置文件。 这些配置文件具有成千上万个用于打开或关闭功能的选项，并且配置文件在不同的系统体系结构之间差异非常大。 例如，一个相当标准的x86_64系统的配置文件中可能有很多选项，但是s390x系统（IBM zSeries大型机）的选项可能要少得多。 在该大型机上，某些选项可能有意义，但在消费类笔记本电脑上没有用处。

内核向前移动并转换为源工件。 该工件包含整个存储库（已应用补丁）以及编译所需的所有内核配置文件。 上游内核继续作为压缩包运行，而Red Hat内核成为下一步的源RPM。

成堆的编译

编译内核会将源代码转换为计算机可以启动和使用的内容。 配置文件描述了要构建的内容，内核中的脚本描述了如何构建它，系统上的工具（例如GCC和glibc）完成了构建。 此过程需要一段时间才能完成，但是CKI项目需要针对四种体系结构Swift完成：aarch64（64位ARM），ppc64le（POWER），s390x（IBM zSeries）和x86_64。 重要的是，我们必须快速编译内核，以便使积压工作易于管理，并且开发人员可以及时收到反馈。

添加更多的CPU可以大大提高速度，但是每个系统都有其局限性。 CKI项目在OpenShift部署中编译容器内的内核； 尽管OpenShift可以实现大量的可伸缩性，但部署中仍然有有限数量的可用CPU。 CKI团队分配了20个虚拟CPU来编译每个内核。 涉及到四个体系结构，这可以扩展到80个CPU！

另一个提高速度的方法来自名为ccache的工具。 内核开发进展Swift，但是即使在多个发行版之间，大量内核仍保持不变。 ccache工具在磁盘上进行编译时会缓存已构建的对象（整个内核的一小部分）。 稍后再进行另一个内核编译时，ccache会查找以前看到的内核的未更改部分。 Ccache从磁盘中提取缓存的对象并重新使用它。 这样可以加快编译速度并降低总体CPU使用率。 现在，耗时20分钟的内核在不到几分钟的时间内就冲向了终点线。

测试时间

大型测试框架（例如Linux测试项目 （LTP））包含大量测试，这些测试在内核中寻找麻烦的回归。 其中一些回归可能会回滚关键的安全修复程序，并且进行了测试以确保这些改进仍保留在内核中。

测试完成后，关键的一步仍然是：报告。 内核开发人员和维护人员需要一份简明的报告，以准确告知他们哪些有效，哪些无效以及如何获取更多信息。 每个CKI报告都包含有关所使用的源代码，编译参数和测试输出的详细信息。 该信息可帮助开发人员知道从哪里开始寻找解决问题的方法。 此外，它还可以帮助维护人员在漏洞进入内核存储库之前知道何时需要保留补丁集以进行其他查看。

摘要

CKI项目团队通过向内核开发人员和维护人员提供及时，自动的反馈，努力防止错误进入Linux内核。 这项工作通过发现容易导致内核错误，安全性问题和性能问题的低落果实，使他们的工作更加轻松。

---

要了解更多信息，您可以参加9月9日至11日在葡萄牙里斯本举行的Linux Plumbers Conference之后的 9月12日至13日举行的CKI Hackfest 。

翻译自: https://opensource.com/article/19/8/linux-kernel-testing

linux内核测试