パッチの投稿: カーネルにコードを入れるための必須ガイド¶
Warning
UNDER CONSTRUCTION!!
この文書は翻訳更新の作業中です。最新の内容は原文を参照してください。
Linux カーネルへ変更を投稿したい個人や企業にとって、もし「仕組み」に 慣れていなければ、そのプロセスは時に気後れするものでしょう。 このテキストは、あなたの変更が受け入れられる可能性を大きく高めるための 提案を集めたものです。
この文書には、比較的簡潔な形式で多数の提案が含まれています。 カーネル開発プロセスの仕組みに関する詳細は A guide to the Kernel Development Process を参照してください。 また、コードを投稿する前に確認すべき項目の一覧として Linux Kernel patch submission checklist を読んでください。 デバイスツリーバインディングのパッチについては、 Submitting Devicetree (DT) binding patches を読んでください。
この文書は、パッチ作成に git を使う前提で書かれています。
もし git に不慣れであれば、使い方を学ぶことを強く勧めます。
それにより、カーネル開発者として、また一般的にも、あなたの作業は
ずっと楽になるでしょう。
いくつかのサブシステムやメンテナツリーには、各々のワークフローや 期待事項に関する追加情報があります。次を参照してください: Subsystem and maintainer tree specific development process notes.
現在のソースツリーを入手する¶
もし手元に最新のカーネルソースのリポジトリがなければ、git を使って取得して
ください。まずは mainline のリポジトリから始めるのがよいでしょう。これは
次のようにして取得できます:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
ただし、直接 mainline のツリーを対象に作業すればよいとは限らないことに注意 してください。多くのサブシステムのメンテナはそれぞれ独自のツリーを運用しており、 そのツリーに対して作成されたパッチを見たいと考えています。該当サブシステムの ツリーは MAINTAINERS ファイル内の T: エントリを参照して見つけてください。 そこに掲載されていない場合は、メンテナに問い合わせてください。
変更内容を記述する¶
まず問題点を記べてください。あなたのパッチが 1 行のバグ修正であっても、 5000 行の新機能であっても、それを行う動機となった根本的な問題が 必ずあるはずです。レビューアが、修正すべき問題がたしかに存在し、冒頭の 段落の続きを読むべきだと納得できるように書いてください。
次にユーザーから見える影響を記述してください。クラッシュやロックアップは 分かりやすいですが、すべてのバグがそこまで露骨とは限りません。 たとえコードレビュー中に見つかった問題であっても、ユーザーに どのような影響があり得るかを記述してください。 Linux の多くの環境は、上流から特定のパッチだけを取り込む二次的な 安定版ツリーや、ベンダー／製品固有のツリーのカーネルで動いています。 したがって、変更を適切に下流へ流す助けになる情報（発生条件、dmesg の抜粋、クラッシュ内容、性能劣化、レイテンシのスパイク、 ロックアップ等）があれば記載してください。
次に最適化とトレードオフを定量的に示してください。パフォーマンス、 メモリ消費量、スタックフットプリント、バイナリサイズの改善を主張する 場合は、それを裏付ける数値を記載してください。 また、目に見えないコストについても記述してください。多くの場合、 最適化は CPU・メモリ・可読性の間でのトレードオフとなります。 ヒューリスティクスの場合は、異なるワークロード間でのトレードオフと なります。レビューアがコストとメリットを比較検討できるよう、 最適化に伴って想定されるデメリットも記述してください。
問題点の明確化が済んだら、実際にどのような対策を講じているかを技術的に 詳しく説明してください。コードが意図したとおりに動作していることを レビューアが確認できるよう、変更内容を平易な言葉で書き下すことが重要です。
パッチ説明を Linux のソースコード管理システム git の
「コミットログ」としてそのまま取り込める形で書けば、メンテナは
助かります。詳細は原文の該当節 (“The canonical patch format”) を
参照してください。
1 つのパッチでは 1 つの問題だけを解決してください。記述が長くなり 始めたら、パッチを分割すべきサインです。詳細は 変更を分割する を 参照してください。
パッチまたはパッチシリーズを投稿／再投稿する際は、その完全な 説明と、それを正当化する理由を含めてください。単に「これはパッチ （シリーズ）のバージョン N です」とだけ書くのは避けてください。 サブシステムメンテナが以前のパッチバージョンや参照先 URL をさかのぼって パッチ記述を探し、それをパッチに補うことを期待してはいけません。 つまり、パッチ（シリーズ）とその説明は、それだけで完結しているべき です。これはメンテナとレビューアの双方に有益です。レビューアの 中には、以前のパッチバージョンを受け取っていない人もいるでしょう。
変更内容は、あたかもコードベースに対してその振る舞いを変えるように 命令するかの如く、（訳補: 英語の）命令形で記述してください。たとえば、 “[This patch] makes xyzzy do frotz” や “[I] changed xyzzy to do frotz” のような言い回しを避け、 “make xyzzy do frotz” のように書いてください。
特定のコミットに言及したい場合に、コミットの SHA-1 ID だけを 書くのは避けてください。レビューアがそれが何についてのものかを 把握しやすいよう、コミットの 1 行要約も含めてください。例:
Commit e21d2170f36602ae2708 ("video: remove unnecessary
platform_set_drvdata()") removed the unnecessary
platform_set_drvdata(), but left the variable "dev" unused,
delete it.
また、SHA-1 ID は少なくとも先頭 12 文字を使うようにしてください。 カーネルのリポジトリには非常に多くのオブジェクトがあるため、 それより短い ID では衝突が現実問題となります。6 文字の ID が今現在 衝突しないからといって、5 年後もそうであるとは限らないことを念頭に 置いてください。
変更に関連する議論や、その背景情報が Web 上で参照できる場合は、 それを指す ‘Link:’ タグを追加してください。過去のメーリングリスト での議論や、Web に記録された何かに由来するパッチならば、 それを示してください。
メーリングリストのアーカイブへリンクする場合は、できれば lore.kernel.org
のメッセージアーカイブサービスを使ってください。リンク URL を作るには、
そのメッセージの Message-ID ヘッダの内容から、前後の山括弧を取り除いた
ものを使います。例:
Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI
実際にリンクが機能し、該当するメッセージを指していることを 確認してください。
ただし、外部リソースを見なくても説明が理解できるようにするよう努めてください。 メーリングリストのアーカイブやバグへの URL を示すだけでなく、 投稿されたパッチに至った議論のポイントも要約してください。
パッチがバグを修正するものであれば、メーリングリストのアーカイブや
公開バグトラッカー上の報告を指す URL を付けて、Closes: タグを
使ってください。例:
Closes: https://example.com/issues/1234
このようなタグ付きのコミットが適用されたとき、自動的に issue を 閉じるバグトラッカーもあります。メーリングリストを監視している ボットの中には、そのようなタグを追跡して一定の動作を行うものも あります。ただし、非公開バグトラッカーの（訳補: 部外者が）閲覧できない URL は禁止です。
パッチが特定のコミットに含まれるバグを修正するもの、たとえば
git bisect で問題を見つけたものの場合には、SHA-1 ID の
先頭少なくとも 12 文字と 1 行要約を含めて ‘Fixes:’ タグを
使ってください。タグを複数行に分割してはいけません。タグは
解析スクリプトを単純にするため、「75 桁で折り返す」規則の
例外です。例:
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
git log や git show の出力を上の形式で整形させるには、
次の git config 設定が使えます:
[core]
abbrev = 12
[pretty]
fixes = Fixes: %h ("%s")
呼び出し例:
$ git log -1 --pretty=fixes 54a4f0239f2e
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
変更を分割する¶
各 論理的な変更 は、個別のパッチに分けてください。
たとえば、単一のドライバに対する変更にバグ修正と性能改善の 両方が含まれるなら、それらは 2 つ以上のパッチに分けてください。 変更に API の更新と、その新しい API を使う新しいドライバが 含まれるなら、それらは 2 つのパッチに分けてください。
一方、多数のファイルに対して単一の変更を行う場合は、それらを 1 つのパッチにまとめてください。つまり、1 つの論理的な変更は 1 つのパッチに含めるべきです。
覚えておくべき点は、各パッチがレビューアに理解しやすく、 検証できる変更であるべきだということです。各パッチは、 それ自体の妥当性で正当化できなければなりません。
変更を完成させるために、あるパッチが別のパッチに依存するなら、 それでも構いません。単に、パッチの説明に “this patch depends on patch X” と記してください。
変更を一連のパッチに分ける際は、シリーズ中の各パッチを
適用した後でも、カーネルが正しくビルドされ、正常に動作することを
特に注意して確認してください。問題の追跡に git bisect を
使う開発者は、あなたのパッチシリーズを任意の地点で分割する
ことがあります。途中でバグを持ち込めば、彼らに感謝されることは
ないでしょう。
パッチセットをこれ以上小さくできないなら、一度に投稿するのは 15 個程度までにして、レビューと統合を待ってください。
変更のスタイルを確認する¶
パッチに基本的なスタイル違反がないか確認してください。詳細は Linux kernel coding style を参照してください。 これを怠ると、単にレビューアの時間を無駄にするだけでなく、 パッチはおそらく読まれもせずに却下されます。
大きな例外が 1 つあります。コードをあるファイルから別の ファイルへ移動する場合です。このときは、コードを移動する その同じパッチの中で、移動したコードを一切変更してはいけません。 そうすることで、コードの移動という行為と、あなたの変更とを 明確に区別できます。これは実際の差分のレビューを大いに助け、 ツールがコード自体の履歴をより適切に追跡できるようにします。
提出前に、パッチスタイルチェッカー
(scripts/checkpatch.pl) でパッチを確認してください。
ただし、スタイルチェッカーは指針として見るべきであり、
人間の判断に取って代わるものではないことに注意してください。
違反があっても、その方がコードの見栄えがよいなら、
そのままにしておくのが最善でしょう。
チェッカーは 3 つのレベルで報告します:
ERROR: 間違っている可能性が非常に高いもの
WARNING: 慎重なレビューを要するもの
CHECK: 検討を要するもの
パッチに残した違反については、すべて理由を説明できなければ なりません。
パッチの宛先を選択する¶
各パッチでは、そのコードを保守する適切なサブシステムメンテナと
メーリングリストを、必ず Cc に入れてください。誰がその
メンテナかは、MAINTAINERS ファイルとソースコードの改訂履歴を
調べて確認してください。この段階では scripts/get_maintainer.pl
が非常に役立ちます（パッチへのパスを引数として
scripts/get_maintainer.pl に渡してください）。作業中の
サブシステムのメンテナが見つからない場合は、Andrew Morton
(akpm@linux-foundation.org) が最後の手段となるメンテナです。
すべてのパッチでは、デフォルトで linux-kernel@vger.kernel.org を 使うべきですが、このリストの流量が多いため、目を通さなくなった 開発者も少なくありません。とはいえ、無関係なメーリングリストや 無関係な人々にスパムを送らないでください。
カーネル関連のメーリングリストの多くは kernel.org で運営されており、 その一覧は https://subspace.kernel.org で確認できます。ただし、 他所で運営されているカーネル関連のメーリングリストもあります。
Linux カーネルに採用されるすべての変更の最終的な裁定者は Linus Torvalds です。彼のメールアドレスは <torvalds@linux-foundation.org> です。Linus は大量のメールを 受け取っており、現時点では彼に直接届くパッチはごくわずかなので、 通常は彼にメールを送ることを極力避けてください。
悪用可能なセキュリティバグを修正するパッチがあるなら、 そのパッチを security@kernel.org に送ってください。深刻なバグに ついては、ディストリビュータがユーザーにパッチを配布できるよう、 短期間の embargo が検討される場合があります。そのような場合、 そのパッチを公開メーリングリストに送るべきではありません。 Security bugs も参照してください。
リリース済みカーネルの深刻なバグを修正するパッチは、次のような行を パッチの sign-off 欄に入れることで、stable メンテナへ向けてください:
Cc: stable@vger.kernel.org
これはメールの受信者ではないことに注意してください。また、 この文書に加えて Everything you ever wanted to know about Linux -stable releases も 読んでください。
変更がユーザーランドとカーネルのインターフェースに影響する場合は、 MAINTAINERS ファイルに記載されている MAN-PAGES メンテナに man-pages パッチ、少なくとも変更の通知を送って、情報が マニュアルページに反映されるようにしてください。ユーザー空間 API の 変更は、linux-api@vger.kernel.org にも Cc してください。