Linuxカーネルはどのようにテストされていますか？
Linuxカーネル開発者は、ローカルでコードをコミットした後、どのようにコードをテストしますか？彼らは何らかのユニットテストを使用して、自動化を構築していますか？テスト計画？
Linuxカーネルは、コミュニティテストに重点を置いています。
通常、開発者は送信する前に独自のコードをテストし、多くの場合、Linusのカーネルの開発バージョン、または作業に関連するプロジェクトの他の不安定/開発ツリーのいずれかを使用します。これは、彼らがしばしば自分の変更と他の人の変更の両方をテストしていることを意味します。
正式なテスト計画の方法はそれほど多くない傾向がありますが、機能がアップストリームツリーにマージされる前に追加のテストが要求される場合があります。
ディーンが指摘したように、いくつかの自動化されたテスト、 linux test project と kernel autotest （ good overview ）もあります。
開発者は、変更をテストすることを目的とした自動テストを作成することもよくありますが、これらのアドホックテストを集中的に収集する（よく使用される）メカニズムがあるかどうかはわかりません。
もちろん、カーネルのどの領域が変更されるかに大きく依存します。新しいネットワークドライバーに対して行うテストは、コアスケジューリングアルゴリズムを置き換えるときに行うテストとはまったく異なります。
当然、カーネル自体とそのパーツはリリース前にテストされますが、これらのテストは基本的な機能のみを対象としています。 Linuxカーネルのテストを実行するテストシステムがいくつかあります。
Linux Test Project（LTP）は、Linuxの信頼性と安定性を検証するテストスイートをオープンソースコミュニティに提供します。 LTPテストスイートには、Linuxカーネルと関連機能をテストするためのツールのコレクションが含まれています。 https://github.com/linux-test-project/ltp
Autotest-完全に自動化されたテストのためのフレームワーク。主に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カーネルの一部です
Fault Injection Framework（Linuxカーネルに含まれています）により、アプリケーションのロジックにエラーと例外を注入して、システムのより高いカバレッジとフォールトトレランスを実現できます。
Linuxカーネル開発者は、コードをローカルでどのようにテストし、コミットした後にテストしますか？
彼らは何らかのユニットテストを使用して、自動化を構築していますか？
古典的な言葉の意味では、ありません。
例Ingo Molnarは、次のワークロードを実行しています。
すべてのビルドの失敗、ブートの失敗、バグ、またはランタイムの警告が処理されます。 24/7。いくつかのボックスを掛けると、多くの問題を発見できます。
テスト計画？
番号。
中央試験施設があるという誤解があるかもしれませんが、ありません。誰もが望むことをします。
ツリー内ツール
カーネルでテストツールを見つける良い方法は次のとおりです。
make helpおよびすべてのターゲットを読み取ります- tools/testing の下を見てください
V4.0では、これにより次のことができます。
kselftesttools/testing/selftests の下。
make kselftestで実行します。ビルド済みのカーネルを既に実行している必要があります。参照： Documentation/kselftest.txt 、 https://kselftest.wiki.kernel.org/ktesttools/testing/ktest の下。参照： http://elinux.org/Ktest 、 http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest
静的アナライザー
make helpのセクションには、次のようなターゲットが含まれます。checkstack： Perl：Linuxソースのcheckstack.plは何をしますか？coccicheckCoccinelleの場合（言及 by askb ）
カーネルCI
https://kernelci.org/ は、カーネルテストの自動化と可視化を目的としたプロジェクトです。
ビルドとブートのテストのみを行うようです（TODOブートが機能することを自動的にテストする方法Sourceは 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 Licensedによるものなので、一見の価値があります。
デモ： https://www.youtube.com/watch?v=yXZzzUEngi
ステップデバッガー
実際にはユニットテストではありませんが、テストが失敗し始めると役立つ場合があります。
- QEMU + GDB： https://stackoverflow.com/a/42316607/895245
- KGDB： https://stackoverflow.com/a/44226360/895245
自分のQEMU + Buildroot + Python setup
開発の容易さに焦点を当てたセットアップも開始しましたが、いくつかの簡単なテスト機能も追加しました： https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724 ＃test-this-repo
私は他のすべてのセットアップを詳細に分析していませんが、おそらく私のものよりもはるかに多くのことを行いますが、多くのドキュメントと自動化があるため、私のセットアップはすぐに始めるのが非常に簡単だと思います。
カーネルテストの自動化はそれほど簡単ではありません。ほとんどのLinux開発者は、adobriyanが述べたように、自分でテストを行います。
ただし、Linuxカーネルのデバッグに役立つものがいくつかあります。
- kexec：BIOSに戻らずに別のカーネルをメモリに入れて再起動し、失敗した場合は再起動できるシステムコール。
- dmesg：間違いなく、カーネルのブート中に何が起こったのか、それが機能する/機能しないのかに関する情報を探す場所。
- Kernel Instrumentation：printk（および「CONFIG_PRINTK_TIME」と呼ばれる、カーネルが何を出力するかを（マイクロ秒の精度で）確認できるオプション）に加えて、カーネル構成により、多くのトレーサーを有効にして、何が起こっているのかをデバッグすることができます。
その後、開発者は通常、他の人にパッチをレビューしてもらいます。パッチがローカルでレビューされ、他の何かに干渉しないことが確認され、パッチがテストされ、Linusの最新のカーネルで動作するようになります。
Edit：これはニースのビデオです パッチがカーネルに統合される前に通過するプロセスの詳細。
Linuxカーネルの機能テスト、ハードウェア認定テスト、パフォーマンステストに重点を置いた上/下のポイントに加えて。
多くのテストは実際に行われます。実際にはスクリプト、静的コード分析ツール、コードレビューなどであり、バグをキャッチするのに非常に効率的です。
スパース – Linuxカーネルの障害を見つけるために設計されたオープンソースのツール。
Coccinelle は、Cコードで目的の一致および変換を指定するための言語SmPL（セマンティックパッチ言語）を提供する、一致および変換エンジンを実行する別のプログラムです。
checkpatch.plおよびその他のスクリプト -コーディングスタイルの問題は、カーネルソースツリーのDocumentation/CodingStyleファイルにあります。それを読むときに覚えておくべき重要なことは、このスタイルが他のどのスタイルよりも優れているということではなく、単に一貫しているということです。これにより、開発者はコーディングスタイルの問題を簡単に見つけて修正することができます。カーネルソースツリーのスクリプトscripts/checkpatch.plが開発されました。このスクリプトは問題を簡単に指摘することができ、後で問題を指摘してレビュー担当者に時間を浪費させるのではなく、開発者が変更に対して常に実行する必要があります。
またあります：
MMTests 結果を分析するためのベンチマークとスクリプトのコレクションです
https://github.com/gormanm/mmtests
三位一体 Linuxシステムコールファズテスター
http://codemonkey.org.uk/projects/trinity/
また LTP sourceforgeのページはかなり古く、プロジェクトはGitHubに移動しました https://github.com/linux-test-project/ltp
仮想化を使用して、QEMU、VirtualBox、Xenなどの簡単なテスト、および構成と自動化されたテストを実行するスクリプトを使用することを想像します。
自動テストは、多くのランダム構成またはいくつかの特定の構成（特定の問題で機能している場合）のいずれかを試行することによっておそらく行われます。 Linuxには、カーネルからのデバッグデータを監視および記録するための低レベルのツール（dmesgなど）が多数あるため、これも使用されると思います。
私が知っている限り、自動的にパフォーマンス回帰チェックツール（名前はlkp/0 day）がIntelによって実行/資金提供されており、メーリングリストに送信された各有効なパッチをテストし、hackbenchなどの異なるマイクロベンチマークから変更されたスコアをチェックします、fio、unixbench、netperfなど、パフォーマンスの低下/改善があれば、対応するレポートがパッチ作成者とCc関連のメンテナーに直接送信されます。
Linuxカーネルのコンパイルを行い、Linuxバージョン3を使用するAndroid（MarshmallowおよびNougat）の修正をいくつか行いました。Linuxシステムでクロスコンパイルし、エラーを手動でデバッグし、Androidそして、それがループホールに入っていたかどうかを確認します。完全に実行される場合、システム要件に従って完全にコンパイルされていることを意味します。
MotoGカーネルコンパイル用
注：-Linuxカーネルは、システムハードウェアに依存する要件に従って変更されます
一般に、LTPおよびMemtestsが推奨されるツールです。
adobriyanは、Ingoのランダム構成ビルドテストのループに言及しました。これは現在、0日間のテストボット（別名kbuildテストボット）でカバーされています。インフラストラクチャに関する素晴らしい記事がここに提示されています： Kernel Build/boot testing
このセットアップの背後にある考え方は、できるだけ早くエラーを修正できるように、できるだけ早く開発者に通知することです。 （kbuildインフラストラクチャはメンテナーのサブシステムツリーに対してもテストするため、パッチがLinusのツリーに組み込まれる前の場合もあります）