Linuxカーネルはどのようにテストされますか？

Linuxカーネルの開発者は、コードをローカルで、そしてコミットした後にどのようにテストしますか？彼らはある種の単体テストを使用して、自動化を構築していますか？テスト計画？

Linuxカーネルは、コミュニティテストに重点を置いています。

通常、開発者は提出する前に独自のコードをテストします。また、多くの場合、開発者はLinusのカーネルの開発バージョン、または作業に関連するプロジェクトに他の不安定/開発ツリーの1つを使用します。これは、彼らが自分たちの変更と他の人の変更の両方をテストしていることを意味します。

正式なテスト計画はそれほど多くない傾向がありますが、機能が上流のツリーにマージされる前に、追加のテストが求められる場合があります。

Deanが指摘したように、自動テスト、Linuxテストプロジェクト、カーネル自動テスト（概要）もあります。

開発者は多くの場合、変更をテストすることを目的とした自動テストも作成しますが、これらのアドホックテストを集中的に収集する（よく使用される）メカニズムがあるかどうかはわかりません。

もちろん、カーネルのどの領域が変更されるかに大きく依存します。新しいネットワークドライバーに対して行うテストは、コアスケジューリングアルゴリズムを置き換えるときに行うテストとはかなり異なります。

当然、カーネル自体とそのパーツはリリース前にテストされますが、これらのテストは基本的な機能のみを対象としています。Linuxカーネルのテストを実行するいくつかのテストシステムがあります。

Linuxテストプロジェクト（LTP）は、Linuxの信頼性と安定性を検証するテストスイートをオープンソースコミュニティに提供します。LTPテストスイートには、Linuxカーネルと関連機能をテストするためのツールのコレクションが含まれています。https://github.com/linux-test-project/ltp

自動テスト -完全に自動化されたテストのためのフレームワーク。これは、主にLinuxカーネルをテストするために設計されていますが、新しいハードウェアの認定、仮想化テスト、およびLinuxプラットフォームでのその他の一般的なユーザー空間プログラムテストなど、他の多くの目的に役立ちます。これは、GPLに基づくオープンソースプロジェクトであり、Google、IBM、Red Hat、その他多くの組織を含む多くの組織によって使用および開発されています。http://autotest.github.io/

また、いくつかの主要なGNU / Linux配布会社によって開発された認証システムもあります。これらのシステムは通常、ハードウェアとの互換性について完全なGNU / Linuxディストリビューションをチェックします。Novell、Red Hat、Oracle、Canonical、Googleによって開発された認定システムがあります。

Linuxカーネルの動的分析のためのシステムもあります。

Kmemleakは、Linuxカーネルに含まれているメモリリークディテクタです。孤立したオブジェクトは解放されず、/ sys / kernel / debug / kmemleakを介してのみ報告されるという違いはありますが、トレースガベージコレクターと同様の方法でカーネルメモリリークの可能性を検出する方法を提供します。

Kmemcheckは、動的に割り当てられた（つまり、kmalloc（）を使用して）メモリーへのすべての読み取りと書き込みをトラップします。以前に書き込まれていないメモリアドレスが読み取られると、メッセージがカーネルログに出力されます。Linuxカーネルの一部でもあります

フォールトインジェクションフレームワーク（Linuxカーネルに含まれています）を使用すると、エラーや例外をアプリケーションのロジックに注入して、システムのカバレッジとフォールトトレランスを向上させることができます。

Linuxカーネルの開発者は、コードをローカルで、そしてコミットした後にどのようにテストしますか？

彼らはある種の単体テストを使用して、自動化を構築していますか？

古典的な言葉で言えば、違います。

例：Ingo Molnarは次のワークロードを実行しています：1.構成オプションのランダムセットを使用して新しいカーネルを構築します2.起動します3. goto 1

すべてのビルド失敗、ブート失敗、BUGまたはランタイム警告が処理されます。24時間年中無休。いくつかのボックスを掛けると、かなり多くの問題が明らかになります。

テスト計画？

番号。

中央テスト施設があるという誤解があるかもしれませんが、ありません。誰もが彼の望むことをします。

ツリー内ツール

カーネルでテストツールを見つけるには、次の方法があります。

• make help すべてのターゲットを読み取ります
• ツール/テストの下を見る

v4.0では、これは私を導きます：

• tools / testing / selftestsの下のkselftest。で実行しmake kselftestます。ビルド済みのカーネルをすでに実行している必要があります。参照：Documentation / kselftest.txt、https：//kselftest.wiki.kernel.org/

• tools / testing / ktestの下のktest。参照：http://elinux.org/Ktest、http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• の静的アナライザーセクションにはmake help、次のようなターゲットが含まれています。

  • checkstack：Perl：Linuxソースのcheckstack.plは何をしますか？
  • coccicheckCoccinelle（askbで言及）

カーネルCI

https://kernelci.org/は、カーネルテストをより自動化して可視化することを目的としたプロジェクトです。

ビルドおよびブートテストのみを実行しているようです（ブートが機能したことを自動的にテストするTODO方法ソースはhttps://github.com/kernelci/にあるはずです）。

Linaroは、多くの大企業からの貢献により、プロジェクトのメインのメンテナーであるようです：https : //kernelci.org/sponsors/

リナロ溶岩

http://www.linaro.org/initiatives/lava/は、開発ボードの立ち上げとLinuxカーネルに重点を置いたCIシステムのように見えます。

ARM LISA

https://github.com/ARM-software/lisa

詳細はわかりませんが、ARMとApacheライセンスによるものなので、一見の価値があります。

デモ：https : //www.youtube.com/watch?v=yXZzzUEngiU

ステップデバッガー

実際には単体テストではありませんが、テストが失敗し始めると役立つ場合があります。

• QEMU + GDB：https : //stackoverflow.com/a/42316607/895245
• KGDB：https ://stackoverflow.com/a/44226360/895245

私自身のQEMU + Buildroot + Pythonセットアップ

：私はまた、開発のしやすさに焦点を当てたが、私は同様にそれにいくつかの簡単なテスト機能を追加することになったのセットアップを開始しましたhttps://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -レポ

他のすべての設定を詳細に分析したわけではありませんが、私の設定よりはるかに多くのことを行う可能性がありますが、私の設定は多くのドキュメントと自動化を備えているため、すぐに使い始めるのは非常に簡単だと思います。

カーネルテストを自動化するのは簡単ではありません。ほとんどのLinux開発者は、adobriyanが述べたように、自分でテストを行います。

ただし、Linuxカーネルのデバッグに役立つものがいくつかあります。

• kexec： BIOSに戻らずに別のカーネルをメモリに入れて再起動し、失敗した場合は再起動できるシステムコール。
• dmesg：間違いなく、カーネルの起動中に何が起こったか、それが機能するかどうかについての情報を探す場所です。
• カーネルインストルメンテーション： printk（およびカーネルが何を出力したかを（マイクロ秒の精度で）確認できる 'CONFIG_PRINTK_TIME'と呼​​ばれるオプション）に加えて、カーネル構成では、多くのトレーサーをオンにして、何をデバッグできるかを指定できます。起こっている。

次に、開発者は通常、他の人にパッチをレビューしてもらいます。パッチがローカルで見直され、他のものに干渉しないことが確認され、パッチが何も壊さずにLinusの最新のカーネルで動作するようにテストされると、パッチは上流にプッシュされます。

編集： これは、パッチがカーネルに統合される前にパッチが通過するプロセスを詳しく説明した素晴らしいビデオです。

上記/以下のポイントに加えて、機能テスト、ハードウェア認定テスト、およびLinuxカーネルのパフォーマンステストに重点を置いています。

多くのテストが実際にスクリプト、静的コード分析ツール、コードレビューなどを介して行われます。これは、アプリケーションの何かを壊すバグをキャッチするのに非常に効率的です。

スパース – Linuxカーネルの障害を検出するために設計されたオープンソースツール。

Coccinelleは、Cコードで必要な一致と変換を指定するための言語SmPL（セマンティックパッチ言語）を提供するマッチングおよび変換エンジンを実行する別のプログラムです。

checkpatch.plおよびその他のスクリプト -コーディングスタイルの問題は、カーネルソースツリーのDocumentation / CodingStyleファイルにあります。読むときに覚えておくべき重要なことは、このスタイルが他のどのスタイルよりも優れているということではなく、一貫しているということだけです。これは、開発者がコーディングスタイルの問題を簡単に見つけて修正するのに役立ちます。カーネルソースツリー内のスクリプトscripts / checkpatch.plが開発されました。このスクリプトは問題を簡単に指摘できるので、レビュー担当者が後で問題を指摘して時間を浪費するのではなく、変更について開発者が常に実行する必要があります。

QEMU、VirtualBox、Xenなどの仮想化と、構成と自動化されたテストを実行するためのいくつかのスクリプトを仮想化を使用して想像するでしょう。

自動テストは、多くのランダムな構成またはいくつかの特定の構成（特定の問題で機能している場合）を試すことによっておそらく行われます。Linuxには、カーネルからのデバッグデータを監視および記録するための低レベルのツール（dmesgなど）がたくさんあるので、それも使用されていると思います。

以下もある：

結果を分析するためのベンチマークとスクリプトのコレクションであるMMTests

https://github.com/gormanm/mmtests

LinuxシステムコールファズテスターであるTrinity

http://codemonkey.org.uk/projects/trinity/

また、sourceforgeのLTPページはかなり古くなっており、プロジェクトはGitHub https://github.com/linux-test-project/ltpに移動しました

私の知る限り、Intelが実行/資金調達する自動パフォーマンス回帰チェックツール（名前はlkp / 0日）があり、メーリングリストに送信された有効な各パッチをテストし、hackbenchなどのさまざまなマイクロベンチマークから変更されたスコアをチェックします、fio、unixbench、netperfなど。パフォーマンスの低下/改善があると、対応するレポートがパッチ作成者およびCc関連のメンテナに直接送信されます。

LTPとMemtestは一般的に推奨されるツールです。

adobriyanさんは、ランダム構成ビルドテストのIngoのループに言及しました。これは現在、ほぼゼロデイテストボット（別名kbuildテストボット）でカバーされています。インフラストラクチャに関する優れた記事をここに示します。カーネルのビルド/ブートテスト

この設定の背後にある考えは、開発者にできるだけ早く通知して、エラーをすぐに修正できるようにすることです。（kbuildインフラストラクチャがメンテナのサブシステムツリーに対してもテストするため、パッチがLinusのツリーに組み込まれる前に）

私はLinuxカーネルのコンパイルを行い、Androidバージョン3を使用するAndroid（MarshmallowおよびNougat）のいくつかの変更を行いました。Linuxシステムでクロスコンパイルし、エラーを手動でデバッグしてから、Androidでブートイメージファイルを実行して、それは抜け穴に入っているかどうかでした。完璧に動作する場合は、システム要件に従って完全にコンパイルされていることを意味します。
MotoGカーネルのコンパイル用

注： -Linuxカーネルは、システムハードウェアに依存する要件に従って変更されます

コントリビューターがパッチファイルを送信した後、マージリクエストを行った後、Linuxゲートキーパーはパッチを統合して確認し、パッチを確認します。成功したら、パッチを関連するブランチにマージし、新しいバージョンのリリースを作成します。Linuxテストプロジェクト（https://github.com/linux-test-project/ltp）は、パッチの適用後にカーネルに対して実行するテストシナリオ（テストケース）を提供するメインソースです。これには約2〜4時間かかることがあります。選択したカーネルのファイルシステムがテストされることに注意してください。Ex：Ext4は、EXT3などに対して異なる結果を生成します。

カーネルのテスト手順。

1. リポジトリから最新のカーネルソースを取得します（https://www.kernel.org/またはGithub.com）
2. パッチファイルの適用（Diffツールの使用）
3. 新しいカーネルを構築します。
4. LTPでのテスト手順に対するテスト（https://github.com/linux-test-project/ltp）