Resguardo inicial

linux-7.2.3/Documentation/translations/ja_JP/process/howto.rst

@@ -0,0 +1,629 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. Originally contributed by Tsugikazu Shibata
+
+Linux カーネル開発のやり方
+==========================
+
+.. note:: 【訳註】
+   この文書は、
+   Documentation/process/howto.rst
+   の翻訳です。
+   免責条項については、
+   :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、
+   :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。
+
+これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した
+ドキュメントです。ここには Linux カーネル開発者になるための方法とLinux
+カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。
+カーネルプログラミングに関する技術的な項目に関することは何も含めないよ
+うにしていますが、カーネル開発者となるための正しい方向に向かう手助けに
+なります。
+
+もし、このドキュメントのどこかが古くなっていた場合には、このドキュメント
+の最後にリストしたメンテナにパッチを送ってください。
+
+はじめに
+---------
+
+あなたは Linux カーネルの開発者になる方法を学びたいのでしょうか？　そ
+れとも上司から「このデバイスの Linux ドライバを書くように」と言われた
+のかもしれません。この文書の目的は、あなたが踏むべき手順と、コミュニティ
+と一緒にうまく働くヒントを書き下すことで、あなたが知るべき全てのことを
+教えることです。また、このコミュニティがなぜ今うまくまわっているのかと
+いう理由も説明しようと試みています。
+
+カーネルは少量のアーキテクチャ依存部分がアセンブリ言語で書かれている以
+外の大部分は C 言語で書かれています。C言語をよく理解していることはカー
+ネル開発に必要です。低レベルのアーキテクチャ開発をするのでなければ、
+(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要ありません。以下
+の本は、C 言語の十分な知識や何年もの経験に取って代わるものではありませ
+んが、少なくともリファレンスとしては良い本です。
+
+ - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
+ - 『プログラミング言語Ｃ第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
+ - "Practical C Programming" by Steve Oualline [O'Reilly]
+ - 『C実践プログラミング第3版』(Steve Oualline著 望月康司監訳 谷口功訳) [オライリージャパン]
+ - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall]
+ - 『新・詳説 C 言語 H&S リファレンス』 (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク]
+
+カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネル
+は ISO C11 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って
+います。カーネルは標準 C ライブラリに依存しない、自立した C 環境です。
+そのため、C の標準の中で使えないものもあります。特に任意の long long
+の除算や浮動小数点は使えません。カーネルがツールチェインや C 言語拡張
+に置いている前提がどうなっているのかわかりにくいことが時々あり、また、
+残念なことに決定的なリファレンスは存在しません。情報を得るには、gcc の
+info ページ( info gcc )を見てください。
+
+あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
+とに思い出してください。そのコミュニティは、コーディング、スタイル、開
+発手順について高度な標準を持つ、多様な人の集まりです。地理的に分散した
+大規模なチームに対してもっともうまくいくとわかったことをベースにしなが
+ら、これらの標準は長い時間をかけて築かれてきました。これらはきちんと文
+書化されていますから、これらの標準について事前にできるだけたくさ
+ん学んでください。また皆があなたやあなたの会社のやり方に合わせてくれる
+と思わないでください。
+
+法的問題
+--------
+
+Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
+す。ソースツリーのメインディレクトリにある COPYING のファイルを見てく
+ださい。Linux カーネルのライセンスルールとソースコード内の
+`SPDX <https://spdx.org/>`_ 識別子の使い方は
+:ref:`Documentation/process/license-rules.rst <kernel_licensing>`
+に説明されています。
+
+もしライセンスについてさらに質問があれば、
+Linux Kernel メーリングリストに質問するのではなく、どうぞ
+法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
+問題については彼らの声明はあてにするべきではありません。
+
+GPL に関する共通の質問や回答については、以下を参照してください-
+
+	https://www.gnu.org/licenses/gpl-faq.html
+
+ドキュメント
+------------
+
+Linux カーネルソースツリーは幅広い範囲のドキュメントを含んでおり、それ
+らはカーネルコミュニティと会話する方法を学ぶのに非常に貴重なものです。
+新しい機能がカーネルに追加される場合、その機能の使い方について説明した
+新しいドキュメントファイルも追加することを勧めます。
+カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
+変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
+をマニュアルページのメンテナ alx@kernel.org に送り、CC を
+linux-api@vger.kernel.org に送ることを勧めます。
+
+以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
+す-
+
+  :ref:`Documentation/admin-guide/README.rst <readme>`
+    このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
+    configure )し、生成(訳注 build )するために必要なことは何かが書かれ
+    ています。 カーネルに関して初めての人はここからスタートすると良い
+    でしょう。
+
+  :ref:`Documentation/process/changes.rst <changes>`
+    このファイルはカーネルをうまく生成(訳注 build )し、走らせるのに最
+    小限のレベルで必要な数々のソフトウェアパッケージの一覧を示してい
+    ます。
+
+  :ref:`Documentation/process/coding-style.rst <codingstyle>`
+    これは Linux カーネルのコーディングスタイルと背景にある理由を記述
+    しています。全ての新しいコードはこのドキュメントにあるガイドライン
+    に従っていることを期待されています。大部分のメンテナはこれらのルー
+    ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
+    だけをレビューします。
+
+  :ref:`Documentation/process/submitting-patches.rst <codingstyle>`
+    このファイルには、どうやってうまくパッチを作って投稿するかにつ
+    いて非常に詳しく書かれており、以下を含みます (これだけに限らない
+    けれども)
+
+      - Email に含むこと
+      - Email の形式
+      - だれに送るか
+
+    これらのルールに従えばうまくいくことを保証することではありません
+    が (すべてのパッチは内容とスタイルについて精査を受けるので)、
+    ルールに従わなければ間違いなくうまくいかないでしょう。
+
+    この他にパッチを作る方法についてのよくできた記述は-
+
+       "The Perfect Patch"
+		https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+       "Linux kernel patch submission format"
+		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
+
+  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
+    このファイルはカーネルの中に不変の API を持たないことにした意識的
+    な決断の背景にある理由について書かれています。以下のようなことを含
+    んでいます-
+
+      - サブシステムとの間に層を作ること(コンパチビリティのため?)
+      - オペレーティングシステム間のドライバの移植性
+      - カーネルソースツリーの素早い変更を遅らせる(もしくは素早い変更を妨げる)
+
+    このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
+    そして、他のOSでの開発者が Linux に移る時にとても重要です。
+
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
+    もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ
+    のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を
+    支援してください。
+
+  :ref:`Documentation/process/management-style.rst <managementstyle>`
+    このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
+    彼らの手法の背景にある共有されている精神について記述しています。こ
+    れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）
+    重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
+    行動についての多くの誤解や混乱を解消するからです。
+
+  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+    このファイルはどのように stable カーネルのリリースが行われるかのルー
+    ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
+    り入れてもらいたい場合に何をすれば良いかが示されています。
+
+  :Ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
+    カーネル開発に付随する外部ドキュメントのリストです。もしあなたが探
+    しているものがカーネル内のドキュメントでみつからなかった場合、この
+    リストをあたってみてください。
+
+  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
+    パッチとはなにか、パッチをどうやって様々なカーネルの開発ブランチに
+    適用するのかについて正確に記述した良い入門書です。
+
+カーネルはソースコードそのものや、このファイルのようなリストラクチャー
+ドテキストマークアップ(ReST)から自動的に生成可能な多数のドキュメントを
+もっています。これにはカーネル内APIの完全な記述や、正しくロックをかけ
+るための規則などが含まれます。
+
+これら全てのドキュメントを PDF や HTML で生成するには以下を実行します - ::
+
+        make pdfdocs
+        make htmldocs
+
+それぞれメインカーネルのソースディレクトリから実行します。
+
+ReSTマークアップを使ったドキュメントは Documentation/outputに生成され
+ます。Latex とePub 形式で生成するには - ::
+
+        make latexdocs
+        make epubdocs
+
+カーネル開発者になるには
+------------------------
+
+もしあなたが、Linux カーネル開発について何も知らないのならば、
+KernelNewbies プロジェクトを見るべきです
+
+	https://kernelnewbies.org
+
+このサイトには役に立つメーリングリストがあり、基本的なカーネル開発に関
+するほとんどどんな種類の質問もできます (既に回答されているようなことを
+聞く前にまずはアーカイブを調べてください)。またここには、リアルタイム
+で質問を聞くことができる IRC チャネルや、Linuxカーネルの開発に関して学
+ぶのに便利なたくさんの役に立つドキュメントがあります。
+
+Web サイトには、コードの構成、サブシステム、現在存在するプロジェクト
+(ツリーにあるもの無いものの両方)の基本的な管理情報があります。ここには、
+また、カーネルのコンパイルのやり方やパッチの当て方などの間接的な基本情
+報も記述されています。
+
+あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
+ニティに参加して何かすることをさがしているのであれば、Linux kernel
+Janitor's プロジェクトにいけば良いでしょう -
+
+        https://kernelnewbies.org/KernelJanitors
+
+ここはそのようなスタートをするのにうってつけの場所です。ここには、
+Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
+らない、単純な問題のリストが記述されています。このプロジェクトに関わる
+開発者と一緒に作業することで、あなたのパッチを Linuxカーネルツリーに入
+れるための基礎を学ぶことができ、そしてもしあなたがまだアイディアを持っ
+ていない場合には、次にやる仕事の方向性が見えてくるかもしれません。
+
+実際に Linux カーネルのコードについて修正を加える前に、どうやってその
+コードが動作するのかを理解することが必要です。そのためには、特別なツー
+ルの助けを借りてでも、それを直接よく読むことが最良の方法です(ほとんど
+のトリッキーな部分は十分にコメントしてありますから)。そういうツールで
+特におすすめなのは、Linux クロスリファレンスプロジェクトです。これは、
+自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
+できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
+ます -
+
+	https://elixir.bootlin.com/
+
+開発プロセス
+------------
+
+Linux カーネルの開発プロセスは現在幾つかの異なるメインカーネル「ブラン
+チ」と多数のサブシステム毎のカーネルブランチから構成されます。これらの
+ブランチとは -
+
+  - Linus のメインラインツリー
+  - メジャー番号をまたぐ数本の安定版ツリー
+  - サブシステム毎のカーネルツリー
+  - 統合テストのための linux-next カーネルツリー
+
+メインラインツリー
+~~~~~~~~~~~~~~~~~~
+
+メインラインツリーは Linus Torvalds によってメンテナンスされ、
+https://kernel.org のリポジトリに存在します。
+この開発プロセスは以下のとおり -
+
+  - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
+    この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
+    このような差分は通常 linux-next カーネルに数週間含まれてきたパッチです。
+    大きな変更は git(カーネルのソース管理ツール、詳細は
+    http://git-scm.com/ 参照) を使って送るのが好ましいやり方ですが、パッ
+    チファイルの形式のまま送るのでも十分です。
+  - 2週間後 -rc1 カーネルがリリースされ、新しいカーネルを可能な限り堅牢に
+    することに焦点が移ります。この期間のパッチのほとんどは退行を修正する
+    ものとなります。以前から存在していたバグは退行には当たらないため、
+    送るのは重要な修正だけにしてください。
+    新しいドライバ (もしくはファイルシステム) のパッチは
+    -rc1 の後で受け付けられることもあることを覚えておいてください。な
+    ぜなら、変更が独立していて、追加されたコードの外の領域に影響を与え
+    ない限り、退行のリスクは無いからです。-rc1 がリリースされた後、
+    Linus へパッチを送付するのに git を使うこともできますが、パッチは
+    レビューのために、パブリックなメーリングリストへも同時に送る必要が
+    あります。
+  - 新しい -rc は Linus が、最新の git ツリーがテスト目的であれば十分
+    に安定した状態にあると判断したときにリリースされます。目標は毎週新
+    しい -rc カーネルをリリースすることです。
+  - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
+    す。このプロセスはだいたい 6週間継続します。
+
+Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ
+て書いたことをここで言っておくことは価値があります -
+
+        *「カーネルがいつリリースされるかは誰も知りません。なぜなら、
+        これは現実に認識されたバグの状況によりリリースされるのであり、
+        前もって決められた計画によってリリースされるものではないから
+        です。」*
+
+メジャー番号をまたぐ数本の安定版ツリー
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+バージョン番号が3つの数字に分かれているカーネルは -stable カーネルです。
+これには最初の2つのバージョン番号の数字に対応した、
+メジャーメインラインリリースで見つかったセキュリティ問題や
+重大な後戻りに対する比較的小さい重要な修正が含まれます。
+
+メジャー安定版シリーズのそれぞれのリリースは
+バージョン番号の3番目を増加させ、最初の2つの番号は同じ値を保ちます。
+
+これは、開発/実験的バージョンのテストに協力することに興味が無く、最新
+の安定したカーネルを使いたいユーザに推奨するブランチです。
+
+安定版ツリーは"stable" チーム <stable@vger.kernel.org> でメンテされており、
+必要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差
+し迫った問題がなければもう少し長くなることもあります。セキュリティ関
+連の問題の場合はこれに対してだいたいの場合、すぐにリリースがされます。
+
+カーネルツリーに入っている、
+Documentation/process/stable-kernel-rules.rst ファイルにはどのような種
+類の変更が -stable ツリーに受け入れ可能か、またリリースプロセスがどう
+動くかが記述されています。
+
+サブシステム毎のカーネルツリー
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル
+サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに
+公開しています。そのため、自分とは異なる領域のカーネルで何が起きている
+かを他の人が見られるようになっています。開発が早く進んでいる領域では、
+開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問
+されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。
+
+大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や
+quilt シリーズとして公開されているパッチキューも使われています。これら
+のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ
+ています。これらの多くは https://git.kernel.org/ で参照することができま
+す。
+
+提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー
+リングリストで事前にレビューにかけられます（以下の対応するセクションを
+参照）。いくつかのカーネルサブシステムでは、このレビューは patchworkと
+いうツールによって追跡されます。Patchwork は web インターフェイスによっ
+てパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そしてメン
+テナはパッチに対して、レビュー中、受付済み、拒否というようなマークをつ
+けることができます。大部分のこれらの patchwork のサイトは
+https://patchwork.kernel.org/ でリストされています。
+
+統合テストのための linux-next カーネルツリー
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+サブシステムツリーの更新内容がメインラインツリーにマージされる
+前に、それらは統合テストされる必要があります。この目的のため、実質的に
+全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリポジ
+トリが存在します-
+
+       https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
+
+このやり方によって、linux-next は次のマージ機会でどんなものがメイン
+ラインにマージされるか、おおまかな展望を提供します。
+linux-next の実行テストを行う冒険好きなテスターは大いに歓迎されます。
+
+バグレポート
+-------------
+
+メインカーネルソースディレクトリにあるファイル
+'Documentation/admin-guide/reporting-issues.rst'
+は、カーネルバグらしきものの報告の仕方、および、カーネル開発者が問題を
+追跡する際の手がかりとなる情報についての詳細を説明しています。
+
+バグレポートの管理
+-------------------
+
+あなたのハッキングのスキルを訓練する最高の方法のひとつに、他人がレポー
+トしたバグを修正することがあります。あなたがカーネルをより安定化させる
+ことに寄与するということだけでなく、あなたは 現実の問題を修正することを
+学び、自分のスキルも強化でき、また他の開発者があなたの存在に気がつきま
+す。バグを修正することは、多くの開発者の中から自分が功績をあげる最善の
+道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好まな
+いからです。
+
+すでにレポートされたバグの作業をするためには、興味のあるサブシステムを
+見つけ、そのサブシステムのバグの報告先 (多くの場合メーリングリスト、
+稀にバグトラッカー) を MAINTAINERS ファイルで調べてください。
+そのアーカイブで最近の報告を検索し、できそうなものに力を貸してください。
+https://bugzilla.kernel.org でバグ報告を調べようとする人もいるでしょう。
+これは限られた一部のサブシステムのバグ報告と追跡に利用されるとともに、
+とりわけ、カーネル全体に対するバグの登録先となっています。
+
+メーリングリスト
+----------------
+
+上のいくつかのドキュメントで述べていますが、コアカーネル開発者の大部分
+は Linux kernel メーリングリストに参加しています。このリストの登録/脱
+退の方法については以下を参照してください-
+
+	https://subspace.kernel.org/subscribing.html
+
+このメーリングリストのアーカイブは web 上の多数の場所に存在します。こ
+れらのアーカイブを探すにはサーチエンジンを使いましょう。例えば-
+
+	https://lore.kernel.org/linux-kernel/
+
+リストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索
+することを是非やってください。多数の事がすでに詳細に渡って議論されてお
+り、アーカイブにのみ記録されています。
+
+大部分のカーネルサブシステムも自分の個別の開発を実施するメーリングリス
+トを持っています。個々のグループがどんなリストを持っているかは、
+MAINTAINERS ファイルにリストがありますので参照してください。
+
+多くのリストは kernel.org でホストされています。これらの情報は以下にあ
+ります -
+
+	https://subspace.kernel.org
+
+メーリングリストを使う場合、良い行動習慣に従うようにしましょう。少し安っ
+ぽいが、以下の URL は上のリスト(や他のリスト)で会話する場合のシンプル
+なガイドラインを示しています -
+
+	https://subspace.kernel.org/etiquette.html
+
+もし複数の人があなたのメールに返事をした場合、CC: で受ける人のリストは
+だいぶ多くなるでしょう。正当な理由がない限り、CC: リストから誰かを削除
+をしないように、また、メーリングリストのアドレスだけにリプライすること
+のないようにしましょう。1つは送信者から、もう1つはリストからのように、
+メールを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追
+加してこの状態を変えようとしないように。人々はそのようなことは好みませ
+ん。
+
+今までのメールでのやりとりとその間のあなたの発言はそのまま残し、
+"John Kernelhacker wrote ...:" の行をあなたのリプライの先頭行にして、
+メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
+す。
+
+もしパッチをメールに付ける場合は、
+Documentation/process/submitting-patches.rst に提示されているように、そ
+れは プレーンな可読テキストにすることを忘れないようにしましょう。カー
+ネル開発者は 添付や圧縮したパッチを扱いたがりません。彼らはあなたのパッ
+チの行毎にコメントを入れたいので、そうするしかありません。あなたのメー
+ルプログラムが空白やタブを圧縮しないように確認しましょう。最初の良いテ
+ストとしては、自分にメールを送ってみて、そのパッチを自分で当ててみるこ
+とです。もしそれがうまく行かないなら、あなたのメールプログラムを直して
+もらうか、正しく動くように変えるべきです。
+
+何をおいても、他の購読者に対する敬意を表すことを忘れないでください。
+
+コミュニティと共に働くこと
+--------------------------
+
+カーネルコミュニティのゴールは可能なかぎり最高のカーネルを提供すること
+です。あなたがパッチを受け入れてもらうために投稿した場合、それは、技術
+的メリットだけがレビューされます。その際、あなたは何を予想すべきでしょ
+うか?
+
+  - 批判
+  - コメント
+  - 変更の要求
+  - パッチの正当性の証明要求
+  - 沈黙
+
+思い出してください、これはあなたのパッチをカーネルに入れる話です。あな
+たは、あなたのパッチに対する批判とコメントを受け入れるべきで、それらを
+技術的レベルで評価して、パッチを再作成するか、なぜそれらの変更をすべき
+でないかを明確で簡潔な理由の説明を提供してください。もし、あなたのパッ
+チに何も反応がない場合、たまにはメールの山に埋もれて見逃され、あなたの
+投稿が忘れられてしまうこともあるので、数日待って再度投稿してください。
+
+あなたがやるべきでないことは?
+
+  - 質問なしにあなたのパッチが受け入れられると想像すること
+  - 守りに入ること
+  - コメントを無視すること
+  - 要求された変更を何もしないでパッチを出し直すこと
+
+可能な限り最高の技術的解決を求めているコミュニティでは、パッチがどのく
+らい有益なのかについては常に異なる意見があります。あなたは協調的である
+べきですし、また、あなたのアイディアをカーネルに対してうまく合わせるよ
+うにすることが望まれています。もしくは、最低限あなたのアイディアがそれ
+だけの価値があるとすすんで証明するようにしなければなりません。
+正しい解決に向かって進もうという意志がある限り、間違うことがあっても許
+容されることを忘れないでください。
+
+あなたの最初のパッチに単に 1ダースもの修正を求めるリストの返答になるこ
+とも普通のことです。これはあなたのパッチが受け入れられないということで
+は **ありません**、そしてあなた自身に反対することを意味するのでも **あ
+りません**。単に自分のパッチに対して指摘された問題を全て修正して再送す
+れば良いのです。
+
+
+カーネルコミュニティと企業組織のちがい
+-----------------------------------------------------------------
+
+カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
+動いています。以下は問題を避けるためにできると良いことのリストです。
+
+  あなたの提案する変更について言うときのうまい言い方 -
+
+    - "これは複数の問題を解決します"
+    - "これは2000行のコードを削除します"
+    - "以下のパッチは、私が言おうとしていることを説明するものです"
+    - "私はこれを5つの異なるアーキテクチャでテストしたのですが..."
+    - "以下は一連の小さなパッチ群ですが..."
+    - "これは典型的なマシンでの性能を向上させます..."
+
+  やめた方が良い悪い言い方 -
+
+    - "このやり方で AIX/ptx/Solaris ではできたので、できるはずだ..."
+    - "私はこれを20年もの間やってきた、だから..."
+    - "これは私の会社が金儲けをするために必要だ"
+    - "これは我々のエンタープライズ向け商品ラインのためである"
+    - "これは私が自分のアイディアを記述した、1000ページの設計資料である"
+    - "私はこれについて、6ケ月作業している..."
+    - "以下は ... に関する5000行のパッチです"
+    - "私は現在のぐちゃぐちゃを全部書き直した、それが以下です..."
+    - "私は〆切がある、そのためこのパッチは今すぐ適用される必要がある"
+
+カーネルコミュニティが大部分の伝統的なソフトウェアエンジニアリングの労
+働環境と異なるもう一つの点は、やりとりに顔を合わせないということです。
+email と irc を第一のコミュニケーションの形とする一つの利点は、性別や
+民族の差別がないことです。Linux カーネルの職場環境は女性や少数民族を受
+容します。なぜなら、email アドレスによってのみあなたが認識されるからで
+す。
+国際的な側面からも活動領域を均等にするようにします。なぜならば、あなた
+は人の名前で性別を想像できないからです。ある男性が アンドレアという名
+前で、女性の名前は パット かもしれません (訳注 Andrea は米国では女性、
+それ以外(欧州など)では男性名として使われることが多い。同様に、Pat は
+Patricia (主に女性名)や Patrick (主に男性名)の略称)。
+Linux カーネルの活動をして、意見を表明したことがある大部分の女性は、前
+向きな経験をもっています。
+
+言葉の壁は英語が得意でない一部の人には問題になります。メーリングリスト
+の中で、きちんとアイディアを交換するには、相当うまく英語を操れる必要が
+あることもあります。そのため、自分のメールを送る前に英語で意味が通じて
+いるかをチェックすることをお薦めします。
+
+変更を分割する
+--------------
+
+Linux カーネルコミュニティは、一度に大量のコードの塊を喜んで受容するこ
+とはありません。変更は正確に説明される必要があり、議論され、小さい、個
+別の部分に分割する必要があります。これはこれまで多くの会社がやり慣れて
+きたことと全く正反対のことです。あなたのプロポーザルは、開発プロセスのと
+ても早い段階から紹介されるべきです。そうすれば あなたは自分のやってい
+ることにフィードバックを得られます。これは、コミュニティからみれば、あ
+なたが彼らと一緒にやっているように感じられ、単にあなたの提案する機能の
+ゴミ捨て場として使っているのではない、と感じられるでしょう。
+しかし、一度に 50 もの email をメーリングリストに送りつけるようなことは
+やってはいけません、あなたのパッチ群はいつもどんな時でもそれよりは小さ
+くなければなりません。
+
+パッチを分割する理由は以下 -
+
+1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
+   ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
+   らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
+   しかし、500行のパッチは、正しいことをレビューするのに数時間かかるか
+   もしれません(時間はパッチのサイズなどにより指数関数に比例してかかり
+   ます)
+
+   小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
+   チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
+   かしくなった後で)解剖するのに比べればとても簡単です。
+
+2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
+   る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。
+
+以下はカーネル開発者の Al Viro のたとえ話です -
+
+        *"生徒の数学の宿題を採点する先生のことを考えてみてください、
+        先生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでし
+        ょう。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知っ
+        ており、そして最終解の前の中間作業を提出することは決してないの
+        です*
+
+        *カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
+        問題を解決する解の背後になる思考プロセスを見たいとは思いません。
+        彼らは単純であざやかな解決方法を見たいのです。"*
+
+あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
+議論することのバランスをキープするのは難しいかもしれません。ですから、
+開発プロセスの早期段階で改善のためのフィードバックをもらうようにするの
+も良いですが、変更点を小さい部分に分割して全体ではまだ完成していない仕
+事を(部分的に)取り込んでもらえるようにすることも良いことです。
+
+また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
+てもらうように送っても、それは受け付けられないことを理解してください。
+
+あなたの変更を正当化する
+------------------------
+
+あなたのパッチを分割するのと同時に、なぜその変更を追加しなければならな
+いかを Linux コミュニティに知らせることはとても重要です。新機能は必要
+性と有用性で正当化されなければなりません。
+
+あなたの変更を説明する
+----------------------
+
+あなたのパッチを送付する場合には、メールの中のテキストで何を言うかにつ
+いて、特別に注意を払ってください。この情報はパッチの ChangeLog に使わ
+れ、いつも皆がみられるように保管されます。これは次のような項目を含め、
+パッチを完全に記述するべきです -
+
+  - なぜ変更が必要か
+  - パッチ全体の設計アプローチ
+  - 実装の詳細
+  - テスト結果
+
+これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
+ントの ChangeLog セクションを見てください -
+
+  "The Perfect Patch"
+      https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+これらはどれも、実行することが時にはとても困難です。これらの例を完璧に
+実施するには数年かかるかもしれません。これは継続的な改善のプロセスであ
+り、多くの忍耐と決意を必要とするものです。でも諦めないで、実現は可能で
+す。多数の人がすでにできていますし、彼らも最初はあなたと同じところから
+スタートしたのですから。
+
+
+
+
+----------
+
+Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process"
+(https://lwn.net/Articles/94386/) セクションをこのテキストの原型にする
+ことを許可してくれました。Rundy Dunlap と Gerrit Huizenga はメーリング
+リストでやるべきこととやってはいけないことのリストを提供してくれました。
+以下の人々のレビュー、コメント、貢献に感謝。
+Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
+Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
+Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
+David A. Wheeler, Junio Hamano, Michael Kerrisk, と Alex Shepard
+彼らの支援なしでは、このドキュメントはできなかったでしょう。
+
+
+
+Maintainer: Greg Kroah-Hartman <greg@kroah.com>

linux-7.2.3/Documentation/translations/ja_JP/process/submit-checklist.rst

@@ -0,0 +1,163 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. Translated by Akira Yokosawa <akiyks@gmail.com>
+
+.. An old translation of this document of a different origin was at
+   Documentation/translations/ja_JP/SubmitChecklist, which can be found
+   in the pre-v6.14 tree if you are interested.
+   Please note that this translation is independent of the previous one.
+
+======================================
+Linux カーネルパッチ投稿チェックリスト
+======================================
+
+.. note:: 【訳註】
+   この文書は、
+   Documentation/process/submit-checklist.rst
+   の翻訳です。
+   免責条項については、
+   :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、
+   :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。
+
+以下は、カーネルパッチの投稿時に、そのスムーズな受け入れのために心がける
+べき基本的な事項です。
+
+これは、 Documentation/process/submitting-patches.rst およびその他の
+Linux カーネルパッチ投稿に関する文書を踏まえ、それを補足するものです。
+
+.. note:: 【訳註】
+   可能な項目については、パッチもしくはパッチ内の更新を暗黙の主語として、
+   その望ましい状態を表す文体とします。その他、原義を損なわない範囲で
+   係り結びを調整するなど、簡潔で把握しやすい箇条書きを目指します。
+
+
+コードのレビュー
+================
+
+1) 利用する機能について、その機能を定義・宣言しているファイルを
+   ``#include`` している。
+   他のヘッダーファイル経由での取り込みに依存しない。
+
+2) Documentation/process/coding-style.rst に詳述されている一般的なスタイル
+   についてチェック済み。
+
+3) メモリバリアー (例, ``barrier()``, ``rmb()``, ``wmb()``) について、
+   そのすべてに、作用と目的、及び必要理由についての説明がソースコード内の
+   コメントとして記述されている。
+
+
+Kconfig 変更のレビュー
+======================
+
+1) 新規の、もしくは変更された ``CONFIG`` オプションについて、それが関係する
+   コンフィグメニューへの悪影響がない。また、
+   Documentation/kbuild/kconfig-language.rst の
+   "Menu attributes: default value" に記載の例外条件を満たす場合を除き、
+   そのデフォルトが無効になっている。
+
+2) 新規の ``Kconfig`` オプションにヘルプテキストがある。
+
+3) 妥当な ``Kconfig`` の組み合わせについて注意深くレビューされている。
+   これをテストでやり切るのは困難で、知力が決め手となる。
+
+ドキュメンテーションの作成
+==========================
+
+1) グローバルなカーネル API が  :ref:`kernel-doc <kernel_doc>` の形式で
+   ドキュメント化されている (静的関数には求められないが、付けてもよい)。
+
+2) 新規 ``/proc`` エントリーが、すべて ``Documentation/`` 以下に記載されて
+   いる。
+
+3) 新規カーネル・ブート・パラメータが、すべて
+   ``Documentation/admin-guide/kernel-parameters.rst`` に記載されている。
+
+4) 新規モジュール・パラメータが、すべて ``MODULE_PARM_DESC()`` によって記述
+   されている。
+
+5) 新規ユーザースペース・インターフェースが、すべて ``Documentation/ABI/``
+   以下に記載されている。詳しくは、 Documentation/admin-guide/abi.rst
+   (もしくは ``Documentation/ABI/README``) を参照。
+   ユーザースペース・インターフェースを変更するパッチは、
+   linux-api@vger.kernel.org にも CC すべし。
+
+6) なんらかの ioctl を追加するパッチは、
+   ``Documentation/userspace-api/ioctl/ioctl-number.rst``
+   の更新を伴う。
+
+ツールによるコードのチェック
+============================
+
+1) スタイル・チェッカー (``scripts/checkpatch.pl``) によって、犯しがちな
+   パッチ・スタイルの違反がないことを確認済み。
+   指摘される違反を残す場合は、それを正当化できること。
+
+2) sparse により入念にチェック済み。
+
+3) ``make checkstack`` で指摘される問題があれば、それが修正済み。
+   ``checkstack`` は問題点を明示的には指摘しないが、 スタック消費が
+   512 バイトを越える関数は見直しの候補。
+
+コードのビルド
+==============
+
+1) 以下の条件でクリーンにビルドできる。
+
+   a) 適用可能な、および ``=y``, ``=m``, ``=n`` を変更した ``CONFIG``
+      オプションでのビルド。
+      ``gcc`` およびリンカーからの警告・エラーがないこと。
+
+   b) ``allnoconfig`` と ``allmodconfig`` がパス
+
+   c) ``O=builddir`` を指定してのビルド
+
+   d) Documentation/ 以下の変更に関して、ドキュメントのビルドで新たな警告や
+      エラーが出ない。
+      ``make htmldocs`` または ``make pdfdocs`` でビルドし、問題があれば修正。
+
+2) ローカルのクロス・コンパイル・ツール、その他のビルド環境 (訳註: build farm)
+   を使って、複数の CPU アーキテクチャ向けにビルドできる。
+   特に、ワードサイズ (32 ビットと 64 ビット) やエンディアン (ビッグとリトル)
+   の異なるアーキテクチャを対象とするテストは、表現可能数値範囲・データ整列・
+   エンディアンなどについての誤った仮定に起因する様々な移植上の問題を捕える
+   のに効果的。
+
+3) 新規に追加されたコードについて (``make KCFLAGS=-W`` を使って)
+   ``gcc -W`` でコンパイル。
+   これは多くのノイズを伴うが、
+   ``warning: comparison between signed and unsigned``
+   の類いのバグをあぶり出すのに効果的。
+
+4) 変更されるソースコードが、下記の ``Kconfig`` シンボルに関連するカーネル
+   API や機能に依存 (もしくは利用) する場合、それらの ``Kconfig`` シンボルが、
+   無効、および (可能なら) ``=m`` の場合を組み合わせた複数のビルドを
+   (全部まとめてではなく、いろいろなランダムの組み合わせで) テスト済み。
+
+   ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
+   ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
+   ``CONFIG_NET``, ``CONFIG_INET=n`` (ただし、後者は ``CONFIG_NET=y``
+   との組み合わせ)。
+
+コードのテスト
+==============
+
+1) ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
+   ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
+   ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
+   ``CONFIG_PROVE_RCU`` および ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` をすべて
+   同時に有効にしてのテスト済み。
+
+2) ``CONFIG_SMP`` と ``CONFIG_PREEMPT`` が有効と無効の場合について、ビルドと
+   ランタイムのテスト済み。
+
+3) lockdep の機能をすべて有効にしての実行で、すべてのコード経路が確認済み。
+
+4) 最低限、slab と ページ・アロケーションの失敗に関する誤り注入
+   (訳註: fault injection) によるチェック済み。
+   詳しくは、 Documentation/fault-injection/index.rst を参照。
+   新規のコードが多い場合は、サブシステム対象の誤り注入を追加するのが望ましい
+   可能性あり。
+
+5) linux-next の最新タグに対するテストにより、他でキューイングされている
+   パッチや、VM、VFS、その他のサブシステム内のすべての変更と組み合わせての
+   動作を確認済み。

linux-7.2.3/Documentation/translations/ja_JP/process/submitting-patches.rst

@@ -0,0 +1,404 @@
+.. _jp_process_submitting_patches:
+
+パッチの投稿: カーネルにコードを入れるための必須ガイド
+======================================================
+
+.. note::
+
+   このドキュメントは :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` の日本語訳です。
+
+   免責事項: :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 です。彼のメールアドレスは
+<torvalds@linux-foundation.org> です。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 してください。
+
+MIME・リンク・圧縮・添付なし、プレーンテキストのみ
+----------------------------------------------------
+
+Linus や他のカーネル開発者は、あなたが投稿する変更を読み、
+コメントできる必要があります。カーネル開発者が標準的な
+メールツールを使ってあなたの変更を「引用」し、コードの特定の
+箇所についてコメントできることが重要です。
+
+このため、すべてのパッチはメール本文中に ``inline`` で投稿すべきです。
+これを行う最も簡単な方法は ``git send-email`` を使うことであり、
+強く推奨されます。``git send-email`` の対話型チュートリアルは
+https://git-send-email.io で利用できます。
+
+``git send-email`` を使わないことを選ぶ場合:
+
+.. warning::
+
+  パッチをコピー＆ペーストする場合は、エディタの word-wrap によって
+  パッチが壊れないよう注意してください。
+
+圧縮の有無にかかわらず、パッチを MIME 添付ファイルとして添付しては
+いけません。多くの一般的なメールアプリケーションは、MIME 添付
+ファイルを常にプレーンテキストとして送信するとは限らず、あなたの
+コードにコメントできなくなります。MIME 添付ファイルは Linus が
+処理するのにも少し余分な時間がかかるため、MIME 添付された変更が
+受け入れられる可能性を下げます。
+
+例外:  メーラがパッチを壊してしまう場合は、誰かから MIME を使って
+再送するよう求められることがあります。
+
+パッチを変更せずに送信するようメールクライアントを設定するための
+ヒントについては、Documentation/process/email-clients.rst を参照してください。
+
+
+レビューコメントに返答する
+--------------------------
+
+あなたのパッチには、ほぼ確実に、パッチを改善する方法について
+レビューアからコメントが付きます。それは、あなたのメールへの返信という
+形で届きます。それらのコメントには必ず返答してください。レビューアを
+無視することは、こちらも無視されるためのよい方法です。コメントに
+答えるには、単にそのメールへ返信すれば構いません。コード変更に
+つながらないレビューコメントや質問であっても、次のレビューアが状況を
+よりよく理解できるように、ほぼ確実にコメントまたは changelog エントリに
+反映すべきです。
+
+どのような変更を行うのかをレビューアに必ず伝え、時間を割いてくれた
+ことに感謝してください。コードレビューは疲れる、時間のかかる作業であり、
+レビューアが不機嫌になることもあります。そのような場合であっても、
+丁寧に返答し、指摘された問題に対応してください。次の版を送るときは、
+cover letter または個々のパッチに ``patch changelog`` を追加し、前回の
+投稿との差分を説明してください。詳細は原文の該当節
+("The canonical patch format") を参照してください。
+
+.. TODO: Convert to file-local cross-reference when the destination is
+   translated.
+
+あなたのパッチにコメントした人には、パッチの Cc リストに追加して、
+新しい版を知らせてください。
+
+メールクライアントとメーリングリストでの作法についての推奨事項は、
+Documentation/process/email-clients.rst を参照してください。
+
+メール議論では不要な引用を削った interleaved replies を使う
+------------------------------------------------------------
+
+Linux カーネル開発の議論では、top-posting は強く非推奨とされています。
+Interleaved replies、または ``inline`` replies を使うと、会話の流れを
+ずっと追いやすくなります。詳細は次を参照してください:
+https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
+
+メーリングリストでは、よく次のように引用されます::
+
+  A: http://en.wikipedia.org/wiki/Top_post
+  Q: Where do I find info about this thing called top-posting?
+  A: Because it messes up the order in which people normally read text.
+  Q: Why is top-posting such a bad thing?
+  A: Top-posting.
+  Q: What is the most annoying thing in e-mail?
+
+同様に、返信に関係のない不要な引用はすべて削ってください。
+そうすることで、返答を見つけやすくなり、時間と容量を節約できます。
+詳細は次を参照してください: http://daringfireball.net/2007/07/on_top ::
+
+  A: No.
+  Q: Should I include quotations after my reply?
+
+
+落胆しない、そして急がない
+--------------------------
+
+変更を投稿した後は、辛抱強く待ってください。レビューアは忙しい人たちであり、
+あなたのパッチをすぐに見られるとは限りません。
+
+かつては、パッチが何のコメントもなく虚空へ消えていくこともありましたが、
+現在の開発プロセスはそれよりも円滑に機能しています。数週間以内、
+通常は 2〜3 週間以内にコメントを受け取るはずです。そうならない場合は、
+パッチを正しい場所へ送ったか確認してください。再投稿したりレビューアに
+ping したりする前に、少なくとも 1 週間は待ってください。merge window の
+ような忙しい時期には、さらに長く待つ方がよい場合もあります。
+
+数週間後に、subject line に "RESEND" を追加して、パッチまたは
+パッチシリーズを再送しても構いません::
+
+   [PATCH Vx RESEND] sub/sys: Condensed patch summary
+
+パッチまたはパッチシリーズの修正版を投稿する場合は、"RESEND" を
+追加しないでください。"RESEND" は、前回の投稿から一切変更していない
+パッチまたはパッチシリーズを再送する場合にのみ使います。