内核持续集成（CKI）项目旨在防止错误进入Linux内核。在Linux内核的持续集成测试中，我介绍了持续内核集成(CKI)项目及其使命：改变内核开发人员和维护人员的工作方式。本文深入探讨了该项目的一些技术方面以及所有部分如何组合在一起。内核中的每一个令人兴奋的特性、改进和错误都始于开发人员提出的更改。这些更改出现在各种内核存储库的众多邮件列表中。一些存储库专注于内核中的某些子系统，例如存储或网络，而其他存储库则专注于内核的更多方面。当开发人员向内核提出更改或补丁集时，或者当维护人员对存储库本身进行更改时，CKI项目就会生效。CKI项目维护的触发器用于监视这些补丁集并对其采取行动。Patchwork等软件项目通过将多个补丁贡献整合到一个补丁系列中，使这个过程变得更加容易。补丁系列作为一个整体通过CKI系统，并且可以为该系列发布单个报告。其他触发器可以观察存储库的变化。当内核维护者合并补丁集、还原补丁或创建新标签时触发。测试这些关键更改可确保开发人员始终拥有可靠的基线，他们可以将其用作编写新补丁的基础。所有这些更改都进入GitLabCI管道并通过多个阶段和系统。准备构建从准备编译源代码开始。这需要克隆存储库、应用开发人员建议的补丁集并生成内核配置文件。这些配置文件有数千个用于打开或关闭功能的选项，并且不同系统架构之间的配置文件差异很大。例如，相当标准的x86_64系统在其配置文件中可能有许多可用选项，但s390x系统（IBMzSeries大型机）的选项可能少得多。某些选项在该大型机上可能有意义，但在消费类笔记本电脑上则毫无意义。内核进一步转化为源代码工件。该工件包含整个存储库（已打补丁）和编译所需的所有内核配置文件。上游内核被打包为tarball，RedHat的内核被生成为下一步的源RPM包。编译内核堆栈将源代码转换为计算机可以启动和使用的代码。配置文件描述构建什么，内核中的脚本描述如何构建它，系统上的工具（如GCC和glibc）进行构建。这个过程需要一段时间才能完成，但CKI项目需要针对四种架构快速完成：aarch64（64位ARM）、ppc64le（POWER）、s390x（IBMzSeries）和x86_64。重要的是我们要快速编译内核，这样才不会出现工作积压，开发人员也能及时收到反馈。添加更多CPU可以大大提高速度，但每个系统都有其局限性。CKI项目在OpenShift的部署环境中的容器内编译内核；尽管OpenShift可以实现高扩展性，但部署环境中可用的CPU数量仍然有限。CKI团队分配了20个虚拟CPU来编译每个内核。涉及四种架构，最多可增加80个CPU！另一个速度提升来自ccache工具。内核开发进展迅速，但即使在不同版本之间，内核的大部分内容也保持不变。ccache工具在编译期间将构建的对象（整个内核的一小部分）缓存在磁盘上。当稍后进行另一个内核编译时，ccache会查找先前看到的内核的未更改部分。ccache将从磁盘中获取缓存的对象并重新使用它。这加快了编译速度并降低了总体CPU使用率。一个需要20分钟编译的内核现在只需不到几分钟即可完成。测试时间内核进入最后一步：在真实硬件上进行测试。每个核心都使用Beaker在其原生架构上启动，并开始进行大量测试以发现问题。一些测试寻找简单的问题，例如容器问题或启动时的错误消息。其他测试深入到各种内核子系统，以发现系统调用、内存分配和线程方面的回归。大型测试框架，如Linux测试项目(LTP)，包含大量测试，用于查找内核中有问题的回归。其中一些回归可能会回滚关键的安全修复程序，并进行测试以确保这些改进保留在内核中。测试完成后，关键的一步仍然是：报告。内核开发人员和维护人员需要一份简明的报告，准确地告诉他们哪些有效，哪些无效，以及从哪里获得更多信息。每个CKI报告都包含所用源代码、编译参数和测试输出的详细信息。此信息可帮助开发人员了解从哪里开始寻找问题的解决方案。此外，它还可以帮助维护人员了解在漏洞进入内核存储库之前何时需要保留补丁集以供额外查看。总结CKI项目团队通过向内核开发人员和维护人员提供及时、自动的反馈，努力防止错误进入Linux内核。这项工作通过发现导致内核错误、安全问题和性能问题的容易发现的问题，使他们的工作更轻松。
