.. _jp_process_submitting_patches: パッチの投稿: カーネルにコードを入れるための必須ガイド ====================================================== .. note:: このドキュメントは :ref:`Documentation/process/submitting-patches.rst ` の日本語訳です。 免責事項: :ref:`translations_ja_JP_disclaimer` .. warning:: **UNDER CONSTRUCTION!!** この文書は翻訳更新の作業中です。最新の内容は原文を参照してください。 Linux カーネルへ変更を投稿したい個人や企業にとって、もし「仕組み」に 慣れていなければ、そのプロセスは時に気後れするものでしょう。 このテキストは、あなたの変更が受け入れられる可能性を大きく高めるための 提案を集めたものです。 この文書には、比較的簡潔な形式で多数の提案が含まれています。 カーネル開発プロセスの仕組みに関する詳細は Documentation/process/development-process.rst を参照してください。 また、コードを投稿する前に確認すべき項目の一覧として Documentation/process/submit-checklist.rst を読んでください。 デバイスツリーバインディングのパッチについては、 Documentation/devicetree/bindings/submitting-patches.rst を読んでください。 この文書は、パッチ作成に ``git`` を使う前提で書かれています。 もし ``git`` に不慣れであれば、使い方を学ぶことを強く勧めます。 それにより、カーネル開発者として、また一般的にも、あなたの作業は ずっと楽になるでしょう。 いくつかのサブシステムやメンテナツリーには、各々のワークフローや 期待事項に関する追加情報があります。次を参照してください: Documentation/process/maintainer-handbooks.rst. 現在のソースツリーを入手する ---------------------------- もし手元に最新のカーネルソースのリポジトリがなければ、``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") を 参照してください。 .. TODO: Convert to file-local cross-reference when the destination is translated. 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 個程度までにして、レビューと統合を待ってください。 変更のスタイルを確認する ------------------------ パッチに基本的なスタイル違反がないか確認してください。詳細は Documentation/process/coding-style.rst を参照してください。 これを怠ると、単にレビューアの時間を無駄にするだけでなく、 パッチはおそらく読まれもせずに却下されます。 大きな例外が 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 です。彼のメールアドレスは です。Linus は大量のメールを 受け取っており、現時点では彼に直接届くパッチはごくわずかなので、 通常は彼にメールを送ることを極力避けてください。 悪用可能なセキュリティバグを修正するパッチがあるなら、 そのパッチを security@kernel.org に送ってください。深刻なバグに ついては、ディストリビュータがユーザーにパッチを配布できるよう、 短期間の embargo が検討される場合があります。そのような場合、 そのパッチを公開メーリングリストに送るべきではありません。 Documentation/process/security-bugs.rst も参照してください。 リリース済みカーネルの深刻なバグを修正するパッチは、次のような行を パッチの sign-off 欄に入れることで、stable メンテナへ向けてください:: Cc: stable@vger.kernel.org これはメールの受信者ではないことに注意してください。また、 この文書に加えて Documentation/process/stable-kernel-rules.rst も 読んでください。 変更がユーザーランドとカーネルのインターフェースに影響する場合は、 MAINTAINERS ファイルに記載されている MAN-PAGES メンテナに man-pages パッチ、少なくとも変更の通知を送って、情報が マニュアルページに反映されるようにしてください。ユーザー空間 API の 変更は、linux-api@vger.kernel.org にも Cc してください。