Linuxカーネルの継続的インテグレーションテスト 、Continuous Kernel Integration（CKI）プロジェクトと、カーネル開発者とメンテナの作業方法を変更するというその使命について書きました。この記事では、プロジェクトのより技術的な側面のいくつかと、すべての要素がどのように組み合わされているかについて詳しく説明します。
カーネルのすべてのエキサイティングな機能、改善、およびバグは、開発者によって提案された変更から始まります。これらの変更は、さまざまなカーネルリポジトリの無数のメーリングリストに表示されます。一部のリポジトリは、ストレージやネットワークなど、カーネル内の特定のサブシステムに焦点を当てていますが、他のリポジトリは、カーネルの幅広い側面に焦点を当てています。 CKIプロジェクトは、開発者がカーネルに変更またはパッチセットを提案したとき、またはメンテナがリポジトリ自体に変更を加えたときに実行に移されます。
CKIプロジェクトは、これらのパッチセットを監視してアクションを実行するトリガーを維持します。パッチワークなどのソフトウェアプロジェクトは、複数のパッチの貢献を単一のパッチシリーズにまとめることにより、このプロセスをはるかに簡単にします。このシリーズは、CKIシステムを1つの単位として移動し、シリーズに関する単一のレポートを公開できます。
他のトリガーは、リポジトリの変更を監視します。これは、カーネルメンテナがパッチセットをマージしたり、パッチを元に戻したり、新しいタグを作成したりするときに発生します。これらの重要な変更をテストすることで、開発者は常に新しいパッチを作成するための基盤として使用できる確実なベースラインを確保できます。
これらの変更はすべてGitLabパイプラインに反映され、複数のステージと複数のシステムを通過します。
すべては、コンパイル時にソースを準備することから始まります。これには、リポジトリのクローンを作成し、開発者が提案したパッチセットを適用し、カーネル構成ファイルを生成する必要があります。これらの構成ファイルには、機能をオンまたはオフにする何千ものオプションがあり、構成ファイルはシステムアーキテクチャごとに大きく異なります。たとえば、かなり標準的なx86_64システムでは、構成ファイルで多数のオプションを使用できますが、s390xシステム（IBM zSeriesメインフレーム）では、オプションがはるかに少ない可能性があります。一部のオプションはそのメインフレームでは意味があるかもしれませんが、消費者向けラップトップでは目的がありません。
カーネルは前進し、ソースアーティファクトに変換されます。アーティファクトには、パッチが適用されたリポジトリ全体と、コンパイルに必要なすべてのカーネル構成ファイルが含まれています。アップストリームカーネルはtarballとして進み、RedHatカーネルは次のステップのソースRPMになります。
カーネルをコンパイルすると、ソースコードがコンピューターが起動して使用できるものに変わります。構成ファイルは何をビルドするかを記述し、カーネルのスクリプトはそれをビルドする方法を記述し、システム上のツール（GCCやglibcなど）がビルドを行います。このプロセスは完了するまでに時間がかかりますが、CKIプロジェクトでは、aarch64（64ビットARM）、ppc64le（POWER）、s390x（IBM zSeries）、およびx86_64の4つのアーキテクチャーで迅速に実行する必要があります。バックログを管理しやすくし、開発者が迅速なフィードバックを受け取ることができるように、カーネルを迅速にコンパイルすることが重要です。
CPUを追加すると、速度が大幅に向上しますが、すべてのシステムに制限があります。 CKIプロジェクトは、OpenShiftデプロイメントのコンテナー内でカーネルをコンパイルします。 OpenShiftは大量のスケーラビリティーを可能にしますが、デプロイメントにはまだ限られた数のCPUが使用可能です。 CKIチームは、各カーネルをコンパイルするために20個の仮想CPUを割り当てます。 4つのアーキテクチャが関係しているため、これは80個のCPUに膨れ上がります！
もう1つの速度の向上は、ccacheと呼ばれるツールによるものです。カーネル開発は迅速に進みますが、複数のリリース間でも大量のカーネルは変更されません。 ccacheツールは、コンパイル中にビルドされたオブジェクト（カーネル全体の小さな部分）をディスクにキャッシュします。後で別のカーネルコンパイルが行われると、ccacheは以前に見たカーネルの変更されていない部分を探します。 Ccacheは、キャッシュされたオブジェクトをディスクからプルして再利用します。これにより、コンパイルが高速化され、全体的なCPU使用率が低下します。コンパイルに20分かかったカーネルは、数分以内にフィニッシュラインに到達します。
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース：RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか？
- 最新のLinux記事
カーネルは最後のステップである実際のハードウェアでのテストに移ります。各カーネルはBeakerを使用してネイティブアーキテクチャで起動し、無数のテストが問題を見つけるためにカーネルを突っ込み始めます。一部のテストでは、コンテナの問題や起動時のエラーメッセージなど、単純な問題を探します。他のテストでは、さまざまなカーネルサブシステムを深く掘り下げて、システムコール、メモリ割り当て、およびスレッド化のリグレッションを見つけます。
Linux Test Project（LTP）などの大規模なテストフレームワークには、カーネルの厄介なリグレッションを探す大量のテストが含まれています。これらのリグレッションの一部は重要なセキュリティ修正をロールバックする可能性があり、それらの改善がカーネルに残っていることを確認するためのテストがあります。
テストが終了しても、重要なステップが1つ残っています。それはレポートです。カーネルの開発者とメンテナは、何が機能し、何が機能しなかったか、そしてより多くの情報を取得する方法を正確に伝える簡潔なレポートを必要としています。各CKIレポートには、使用されているソースコード、コンパイルパラメータ、およびテスト出力に関する詳細が含まれています。その情報は、開発者が問題の修正をどこから始めればよいかを知るのに役立ちます。また、バグがカーネルリポジトリに侵入する前に、パッチセットを保持して別の外観を確認する必要がある時期をメンテナが知るのに役立ちます。
CKIプロジェクトチームは、カーネル開発者とメンテナにタイムリーで自動化されたフィードバックを提供することにより、バグがLinuxカーネルに侵入するのを防ぐよう努めています。この作業は、カーネルのバグ、セキュリティの問題、およびパフォーマンスの問題につながる、手に負えない成果を見つけることで、彼らの仕事を容易にします。
詳細については、9月12〜13日にポルトガルのリスボンで開催されるLinux配管工会議に続くCKIハックフェストに参加できます。