[[279338]]

內核持續集成（CKI）項目旨在防止錯誤進入 Linux 內核。

在 Linux 內核的持續集成測試 一文中，我介紹了 內核持續集成Continuous Kernel Integration（CKI）項目及其使命：改變內核開發人員和維護人員的工作方式。本文深入探討了該項目的某些技術方面，以及這所有的部分是如何組合在一起的。

從一次更改開始

內核中每一項令人興奮的功能、改進和錯誤都始于開發人員提出的更改。這些更改出現在各個內核存儲庫的大量郵件列表中。一些存儲庫關注內核中的某些子系統，例如存儲或網絡，而其它存儲庫關注內核的更多方面。 當開發人員向內核提出更改或補丁集時，或者維護者在存儲庫本身中進行更改時，CKI 項目就會付諸行動。

CKI 項目維護的觸發器用于監視這些補丁集并采取措施。諸如 Patchwork 之類的軟件項目通過將多個補丁貢獻整合為單個補丁系列，使此過程變得更加容易。補丁系列作為一個整體歷經 CKI 系統，并可以針對該系列發布單個報告。

其他觸發器可以監視存儲庫中的更改。當內核維護人員合并補丁集、還原補丁或創建新標簽時，就會觸發。測試這些關鍵的更改可確保開發人員始終具有堅實的基線，可以用作編寫新補丁的基礎。

所有這些更改都會進入 GitLab CI 管道，并歷經多個階段和多個系統。

準備構建

首先要準備好要編譯的源代碼。這需要克隆存儲庫、打上開發人員建議的補丁集，并生成內核配置文件。這些配置文件具有成千上萬個用于打開或關閉功能的選項，并且配置文件在不同的系統體系結構之間差異非常大。 例如，一個相當標準的 x86_64 系統在其配置文件中可能有很多可用選項，但是 s390x 系統（IBM zSeries 大型機）的選項可能要少得多。在該大型機上，某些選項可能有意義，但在消費類筆記本電腦上沒有任何作用。

內核進一步轉換為源代碼工件。該工件包含整個存儲庫（已打上補丁）以及編譯所需的所有內核配置文件。 上游內核會打包成壓縮包，而 Red Hat 的內核會生成下一步所用的源代碼 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 Test Project（LTP），包含了大量測試，這些測試在內核中尋找麻煩的回歸問題。其中一些回歸問題可能會回滾關鍵的安全修復程序，并且進行測試以確保這些改進仍保留在內核中。

測試完成后，關鍵的一步仍然是：報告。內核開發人員和維護人員需要一份簡明的報告，準確地告訴他們哪些有效、哪些無效以及如何獲取更多信息。每個 CKI 報告都包含所用源代碼、編譯參數和測試輸出的詳細信息。該信息可幫助開發人員知道從哪里開始尋找解決問題的方法。此外，它還可以幫助維護人員在漏洞進入內核存儲庫之前知道何時需要保留補丁集以進行其他查看。

總結

CKI 項目團隊通過向內核開發人員和維護人員提供及時、自動的反饋，努力防止錯誤進入 Linux 內核。這項工作通過發現導致內核錯誤、安全性問題和性能問題等易于找到的問題，使他們的工作更加輕松。