在Linux 内核的持续集成测试一文中，我介绍了持续内核集成 (CKI) 项目及其改变内核开发者和维护者工作方式的使命。本文深入探讨了该项目的一些更技术性的方面，以及所有部分如何协同工作。
一切始于一项变更
内核中每一个令人兴奋的功能、改进和错误都始于开发者提出的变更。这些变更出现在各种内核代码库的邮件列表中。一些代码库专注于内核中的特定子系统，例如存储或网络，而另一些代码库则专注于内核的广泛方面。当开发者向内核提出变更或补丁集，或者当维护者在代码库本身中进行更改时，CKI 项目便会开始运作。
CKI 项目维护着监控这些补丁集并采取行动的触发器。诸如 Patchwork 等软件项目通过将多补丁贡献整理成单个补丁系列，使此过程变得更加容易。此系列作为一个单元在 CKI 系统中传递，并允许发布关于该系列的单个报告。
其他触发器会监视代码库的更改。当内核维护者合并补丁集、还原补丁或创建新标签时，会发生这种情况。测试这些关键更改可确保开发者始终拥有可靠的基线，以用作编写新补丁的基础。
所有这些更改都进入 GitLab 管道，并经过多个阶段和多个系统。
准备构建
一切都从准备好编译源代码开始。这需要克隆代码库，应用开发者提出的补丁集，并生成内核配置文件。这些配置文件有数千个选项，用于打开或关闭功能，并且不同系统架构之间的配置文件差异巨大。例如，一个相当标准的 x86_64 系统可能在其配置文件中有很多可用选项，但 s390x 系统（IBM zSeries 大型机）可能选项少得多。某些选项在大型机上可能很有意义，但在消费级笔记本电脑上则毫无用处。
内核向前发展并转换为源工件。该工件包含整个代码库，其中应用了补丁，以及编译所需的所有内核配置文件。上游内核以 tarball 形式继续前进，而红帽内核则成为下一步的源 RPM。
大量的编译
编译内核将源代码转换为计算机可以启动和使用的东西。配置文件描述了要构建的内容，内核中的脚本描述了如何构建它，而系统上的工具（如 GCC 和 glibc）则执行构建。此过程需要一段时间才能完成，但 CKI 项目需要为四种架构快速完成：aarch64（64 位 ARM）、ppc64le（POWER）、s390x（IBM zSeries）和 x86_64。快速编译内核非常重要，这样我们才能使我们的积压工作量可控，并且开发者能够及时收到反馈。
增加更多 CPU 可以显著提高速度，但每个系统都有其限制。CKI 项目在 OpenShift 部署中的容器内编译内核；尽管 OpenShift 允许进行大量扩展，但部署仍然具有有限数量的可用 CPU。CKI 团队为编译每个内核分配了 20 个虚拟 CPU。由于涉及四种架构，这会膨胀到 80 个 CPU！
另一个速度提升来自一个名为 ccache 的工具。内核开发进展迅速，但即使在多个版本之间，内核的大部分内容仍然保持不变。ccache 工具在磁盘上的编译期间缓存构建对象（整个内核的小部分）。当稍后进行另一个内核编译时，ccache 会查找它以前看到的内核的未更改部分。Ccache 从磁盘中提取缓存的对象并重复使用它。这可以加快编译速度并降低总体 CPU 使用率。以前需要 20 分钟才能编译完成的内核现在可以在几分钟内快速完成。
测试时间
内核进入最后一步：在真实硬件上进行测试。每个内核都使用 Beaker 在其本机架构上启动，并且无数的测试开始探测它以查找问题。一些测试寻找简单的问题，例如容器问题或启动时的错误消息。其他测试深入研究各种内核子系统，以查找系统调用、内存分配和线程处理方面的回归。
大型测试框架，例如 Linux 测试项目 (LTP)，包含大量用于查找内核中麻烦的回归的测试。其中一些回归可能会回滚关键的安全修复程序，并且有测试来确保这些改进保留在内核中。
当测试完成时，还剩下一个关键步骤：报告。内核开发者和维护者需要一份简明的报告，告诉他们哪些工作正常，哪些工作不正常，以及如何获取更多信息。每个 CKI 报告都包含有关使用的源代码、编译参数和测试输出的详细信息。这些信息帮助开发者知道从哪里开始查找以修复问题。此外，它还有助于维护者知道何时需要暂停补丁集以进行进一步查看，以防止错误进入其内核代码库。
总结
CKI 项目团队致力于通过向内核开发者和维护者提供及时的自动化反馈来防止错误进入 Linux 内核。这项工作通过查找导致内核错误、安全问题和性能问题的唾手可得的成果，使他们的工作更加轻松。
要了解更多信息，您可以参加 9 月 12 日至 13 日在葡萄牙里斯本举行的 CKI Hackfest，紧随 9 月 9 日至 11 日的 Linux Plumbers Conference 之后。
2 条评论