Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

3 Commits   0 Branches   0 Tags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) NOTE:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) This is a version of Documentation/process/submitting-patches.rst into Japanese.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   3) This document is maintained by Keiichi KII <k-keiichi@bx.jp.nec.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   4) and the JF Project team <http://www.linux.or.jp/JF/>.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   5) If you find any difference between this document and the original file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) or a problem with the translation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) please contact the maintainer of this file or JF project.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) Please also note that the purpose of this file is to be easier to read
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) for non English (read: Japanese) speakers and is not intended as a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) fork. So if you have any comments or updates of this file, please try
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) to update the original English file first.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14) Last Updated: 2011/06/09
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17) これは、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18) linux-2.6.39/Documentation/process/submitting-patches.rst の和訳
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19) です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20) 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21) 翻訳日: 2011/06/09
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22) 翻訳者: Keiichi Kii <k-keiichi at bx dot jp dot nec dot com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) 校正者: Masanari Kobayashi さん <zap03216 at nifty dot ne dot jp>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24)          Matsukura さん <nbh--mats at nifty dot com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25)          Takeshi Hamasaki さん <hmatrjp at users dot sourceforge dot jp>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28)         Linux カーネルに変更を加えるための Howto
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29)         又は
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30)         かの Linus Torvalds の取り扱い説明書
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32) Linux カーネルに変更を加えたいと思っている個人又は会社にとって、パッ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) チの投稿に関連した仕組みに慣れていなければ、その過程は時々みなさんを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34) おじけづかせることもあります。この文章はあなたの変更を大いに受け入れ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) てもらえやすくする提案を集めたものです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37) コードを投稿する前に、Documentation/process/submit-checklist.rst の項目リストに目
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38) を通してチェックしてください。もしあなたがドライバーを投稿しようとし
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) ているなら、Documentation/process/submitting-drivers.rst にも目を通してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42) セクション1 パッチの作り方と送り方
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45) 1) 「 diff -up 」
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48) パッチの作成には「 diff -up 」又は「 diff -uprN 」を使ってください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) Linux カーネルに対する全ての変更は diff(1) コマンドによるパッチの形式で
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51) 生成してください。パッチを作成するときには、diff(1) コマンドに「 -u 」引
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52) 数を指定して、unified 形式のパッチを作成することを確認してください。また、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53) 変更がどの C 関数で行われたのかを表示する「 -p 」引数を使ってください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54) この引数は生成した差分をずっと読みやすくしてくれます。パッチは Linux
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55) カーネルソースの中のサブディレクトリではなく Linux カーネルソースのルート
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56) ディレクトリを基準にしないといけません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58) 1個のファイルについてのパッチを作成するためには、ほとんどの場合、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59) 以下の作業を行えば十分です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61) 	SRCTREE=linux-2.6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62) 	MYFILE=drivers/net/mydriver.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64) 	cd $SRCTREE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65) 	cp $MYFILE $MYFILE.orig
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) 	vi $MYFILE	# make your change
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67) 	cd ..
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) 	diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) 複数のファイルについてのパッチを作成するためには、素の( vanilla )、す
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71) なわち変更を加えてない Linux カーネルを展開し、自分の Linux カーネル
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72) ソースとの差分を生成しないといけません。例えば、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74) 	MYSRC=/devel/linux-2.6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76) 	tar xvfz linux-2.6.12.tar.gz
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  77) 	mv linux-2.6.12 linux-2.6.12-vanilla
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  78) 	diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  79) 		linux-2.6.12-vanilla $MYSRC > /tmp/patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81) dontdiff ファイルには Linux カーネルのビルドプロセスの過程で生成された
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82) ファイルの一覧がのっています。そして、それらはパッチを生成する diff(1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83) コマンドで無視されるべきです。dontdiff ファイルは 2.6.12 以後のバージョ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84) ンの Linux カーネルソースツリーに含まれています。それより前のバージョン
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85) の Linux カーネルソースツリーに対する dontdiff ファイルは、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86) <http://www.xenotime.net/linux/doc/dontdiff>から取得することができます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88) 投稿するパッチの中に関係のない余分なファイルが含まれていないことを確
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89) 認してください。diff(1) コマンドで生成したパッチがあなたの意図したとお
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90) りのものであることを確認してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) もしあなたのパッチが多くの差分を生み出すのであれば、あなたはパッチ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) を意味のあるひとまとまりごとに分けたいと思うかもしれません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) これは他のカーネル開発者にとってレビューしやすくなるので、あなたの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) パッチを受け入れてもらうためにはとても重要なことです。これを補助でき
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96) る多くのスクリプトがあります。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98) Quilt:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99) http://savannah.nongnu.org/projects/quilt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) 2) パッチに対する説明
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) パッチの中の変更点に対する技術的な詳細について説明してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) 説明はできる限り具体的に。もっとも悪い説明は「ドライバー X を更新」、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) 「ドライバー X に対するバグフィックス」あるいは「このパッチはサブシス
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) テム X に対する更新を含んでいます。どうか取り入れてください。」などです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) パッチの説明を Linux カーネルのソースコードマネジメントシステム「 git 」の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) コミットログとして簡単に引用できる形で書けば、メンテナから感謝されるでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) 以下の #15 を見てください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) 説明が長くなりだしたのであれば、おそらくそれはパッチを分ける必要がある
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) という兆候です。次の #3 を見てください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) パッチ(シリーズ)を(再)投稿する時、十分なパッチの説明とそのパッチが必要な理由を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) パッチに含めてください。ただ「これはパッチ(シリーズ)のバージョン N」とだけ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) 書かないでください。そして、パッチをマージする人にパッチの説明を探させそれを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) パッチに追記させるため、過去のバージョンのパッチやそのパッチの URL を参照する
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) 手間をかけさせないでください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) つまり、パッチシリーズとその説明は一緒にあるべきです。これはパッチをマージする
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) 人、レビューする人、どちらのためにもなります。レビューする人の中には、おそらく
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) 過去のバージョンのパッチを受け取ってもいない人がいます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) 登録済みのバグエントリを修正するパッチであれば、そのバグエントリを示すバグ ID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) や URL を明記してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) 3) パッチの分割
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) 意味のあるひとまとまりごとに変更を個々のパッチファイルに分けてください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) 例えば、もし1つのドライバーに対するバグフィックスとパフォーマンス強
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) 化の両方の変更を含んでいるのであれば、その変更を2つ以上のパッチに分
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) けてください。もし変更箇所に API の更新と、その新しい API を使う新たな
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) ドライバーが含まれているなら、2つのパッチに分けてください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) 一方で、もしあなたが多数のファイルに対して意味的に同じ1つの変更を加え
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) るのであれば、その変更を1つのパッチにまとめてください。言いかえると、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) 意味的に同じ1つの変更は1つのパッチの中に含まれます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) あるパッチが変更を完結させるために他のパッチに依存していたとしても、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) それは問題ありません。パッチの説明の中で「このパッチはパッチ X に依存
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) している」と簡単に注意書きをつけてください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) もしパッチをより小さなパッチの集合に凝縮することができないなら、まずは
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) 15かそこらのパッチを送り、そのレビューと統合を待って下さい。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) 4) パッチのスタイルチェック
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) あなたのパッチが基本的な( Linux カーネルの)コーディングスタイルに違反し
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) ていないかをチェックして下さい。その詳細を Documentation/process/coding-style.rst で
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) 見つけることができます。コーディングスタイルの違反はレビューする人の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) 時間を無駄にするだけなので、恐らくあなたのパッチは読まれることすらなく
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) 拒否されるでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) あなたはパッチを投稿する前に最低限パッチスタイルチェッカー
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) ( scripts/checkpatch.pl )を利用してパッチをチェックすべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) もしパッチに違反がのこっているならば、それらの全てについてあなたは正当な
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) 理由を示せるようにしておく必要があります。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) 5) 電子メールの宛先の選び方
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) MAINTAINERS ファイルとソースコードに目を通してください。そして、その変
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) 更がメンテナのいる特定のサブシステムに加えられるものであることが分か
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) れば、その人に電子メールを送ってください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) もし、メンテナが載っていなかったり、メンテナからの応答がないなら、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) LKML ( linux-kernel@vger.kernel.org )へパッチを送ってください。ほとんど
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) のカーネル開発者はこのメーリングリストに目を通しており、変更に対して
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) コメントを得ることができます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) 15個より多くのパッチを同時に vger.kernel.org のメーリングリストへ送らな
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) いでください!!!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) Linus Torvalds は Linux カーネルに入る全ての変更に対する最終的な意思決定者
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) です。電子メールアドレスは torvalds@linux-foundation.org になります。彼は
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) 多くの電子メールを受け取っているため、できる限り彼に電子メールを送るのは
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) 避けるべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) バグフィックスであったり、自明な変更であったり、話し合いをほとんど
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) 必要としないパッチは Linus へ電子メールを送るか CC しなければなりません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) 話し合いを必要としたり、明確なアドバンテージがないパッチは、通常まず
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) は LKML へ送られるべきです。パッチが議論された後にだけ、そのパッチを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) Linus へ送るべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) 6) CC (カーボンコピー)先の選び方
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) 特に理由がないなら、LKML にも CC してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) Linus 以外のカーネル開発者は変更に気づく必要があり、その結果、彼らはそ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) の変更に対してコメントをくれたり、コードに対してレビューや提案をくれ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) るかもしれません。LKML とは Linux カーネル開発者にとって一番中心的なメー
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) リングリストです。USB やフレームバッファデバイスや VFS や SCSI サブシステ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) ムなどの特定のサブシステムに関するメーリングリストもあります。あなた
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) の変更に、はっきりと関連のあるメーリングリストについて知りたければ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) MAINTAINERS ファイルを参照してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) VGER.KERNEL.ORG でホスティングされているメーリングリストの一覧が下記の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) サイトに載っています。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) <http://vger.kernel.org/vger-lists.html>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) もし、変更がユーザランドのカーネルインタフェースに影響を与え
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) るのであれば、MAN-PAGES のメンテナ( MAINTAINERS ファイルに一覧
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) があります)に man ページのパッチを送ってください。少なくとも
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) 情報がマニュアルページの中に入ってくるように、変更が起きたという
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) 通知を送ってください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) たとえ、メンテナが #5 で反応がなかったとしても、メンテナのコードに変更を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) 加えたときには、いつもメンテナに CC するのを忘れないようにしてください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) 小さなパッチであれば、Trivial Patch Monkey(ちょっとしたパッチを集めている)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) <trivial@kernel.org>に CC してもいいです。その現管理者については MAINTAINERS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) ファイルを見てください。ちょっとしたパッチとは以下のルールのどれか1つを満たして
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) いなければなりません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)  ・ドキュメントのスペルミスの修正
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)  ・grep(1) コマンドによる検索を困難にしているスペルの修正
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)  ・コンパイル時の警告の修正(無駄な警告が散乱することは好ましくないた
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)    めです)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219)  ・コンパイル問題の修正(それらの修正が本当に正しい場合に限る)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)  ・実行時の問題の修正(それらの修正が本当に問題を修正している場合に限る)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)  ・廃止予定の関数やマクロを使用しているコードの除去(例 check_region )
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)  ・問い合わせ先やドキュメントの修正
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)  ・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)    あればアーキテクチャ特有のことでも他の人がコピーできます)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225)  ・作者やメンテナによる修正(すなわち patch monkey の再転送モード)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) 7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) Linus や他のカーネル開発者はあなたが投稿した変更を読んで、コメントでき
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) る必要があります。カーネル開発者にとって、あなたが書いたコードの特定の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) 部分にコメントをするために、標準的な電子メールクライアントで変更が引用
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) できることは重要です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) 上記の理由で、すべてのパッチは文中に含める形式の電子メールで投稿さ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) れるべきです。警告:あなたがパッチをコピー&ペーストする際には、パッ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) チを改悪するエディターの折り返し機能に注意してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) パッチを圧縮の有無に関わらず MIME 形式で添付しないでください。多くのポ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) ピュラーな電子メールクライアントは MIME 形式の添付ファイルをプレーンテ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) キストとして送信するとは限らないでしょう。そうなると、電子メールクラ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) イアントがコードに対するコメントを付けることをできなくします。また、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) MIME 形式の添付ファイルは Linus に手間を取らせることになり、その変更を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) 受け入れてもらう可能性が低くなってしまいます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) 例外:お使いの電子メールクライアントがパッチをめちゃくちゃにするので
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) あれば、誰かが MIME 形式のパッチを再送するよう求めるかもしれません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) 余計な変更を加えずにあなたのパッチを送信するための電子メールクライアントの設定
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) のヒントについては Documentation/process/email-clients.rst を参照してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) 8) 電子メールのサイズ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) パッチを Linus へ送るときは常に #7 の手順に従ってください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) 大きなパッチはメーリングリストやメンテナにとって不親切です。パッチが
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) 未圧縮で 300KB を超えるようであるなら、インターネット上のアクセス可能な
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) サーバに保存し、保存場所を示す URL を伝えるほうが適切です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) 9) カーネルバージョンの明記
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) パッチが対象とするカーネルのバージョンをパッチの概要か電子メールの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) サブジェクトに付けることが重要です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) パッチが最新バージョンのカーネルに正しく適用できなければ、Linus は
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) そのパッチを採用しないでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) 10) がっかりせず再投稿
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) パッチを投稿した後は、辛抱強く待っていてください。Linus があなたのパッ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) チを気に入って採用すれば、Linus がリリースする次のバージョンのカーネル
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) の中で姿を見せるでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) しかし、パッチが次のバージョンのカーネルに入っていないなら、いくつもの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) 理由があるのでしょう。その原因を絞り込み、間違っているものを正し、更新
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) したパッチを投稿するのはあなたの仕事です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) Linus があなたのパッチに対して何のコメントもなく不採用にすることは極め
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) て普通のことです。それは自然な姿です。もし、Linus があなたのパッチを受
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) け取っていないのであれば、以下の理由が考えられます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) * パッチが最新バージョンの Linux カーネルにきちんと適用できなかった
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) * パッチが LKML で十分に議論されていなかった
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) * スタイルの問題(セクション2を参照)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) * 電子メールフォーマットの問題(このセクションを参照)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) * パッチに対する技術的な問題
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) * Linus はたくさんの電子メールを受け取っているので、どさくさに紛れて見
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286)   失った
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) * 不愉快にさせている
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) 判断できない場合は、LKML にコメントを頼んでください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) 11) サブジェクトに「 PATCH 」
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) Linus や LKML への大量の電子メールのために、サブジェクトのプレフィックスに
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) 「 [PATCH] 」を付けることが慣習となっています。これによって Linus や他の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) カーネル開発者がパッチであるのか、又は、他の議論に関する電子メールであるの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) かをより簡単に識別できます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) 12) パッチへの署名
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) 誰が何をしたのかを追いかけやすくするために (特に、パッチが何人かの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) メンテナを経て最終的に Linux カーネルに取り込まれる場合のために)、電子
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) メールでやり取りされるパッチに対して「 sign-off 」という手続きを導入し
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) ました。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) 「 sign-off 」とは、パッチがあなたの書いたものであるか、あるいは、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) あなたがそのパッチをオープンソースとして提供する権利を保持している、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) という証明をパッチの説明の末尾に一行記載するというものです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) ルールはとても単純です。以下の項目を確認して下さい。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310)         原作者の証明書( DCO ) 1.1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312)         このプロジェクトに寄与するものとして、以下のことを証明する。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314)         (a) 本寄与は私が全体又は一部作成したものであり、私がそのファイ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315)             ル中に明示されたオープンソースライセンスの下で公開する権利
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316)             を持っている。もしくは、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)         (b) 本寄与は、私が知る限り、適切なオープンソースライセンスでカバ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319)             ーされている既存の作品を元にしている。同時に、私はそのライセ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320)             ンスの下で、私が全体又は一部作成した修正物を、ファイル中で示
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321)             される同一のオープンソースライセンスで(異なるライセンスの下で
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322)             投稿することが許可されている場合を除いて)投稿する権利を持って
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323)             いる。もしくは、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325)         (c) 本寄与は(a)、(b)、(c)を証明する第3者から私へ直接提供された
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)             ものであり、私はそれに変更を加えていない。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328)         (d) 私はこのプロジェクトと本寄与が公のものであることに理解及び同意す
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329)             る。同時に、関与した記録(投稿の際の全ての個人情報と sign-off を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330)             含む)が無期限に保全されることと、当該プロジェクト又は関連する
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331)             オープンソースライセンスに沿った形で再配布されることに理解及び
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332)             同意する。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) もしこれに同意できるなら、以下のような1行を追加してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) 	Signed-off-by: Random J Developer <random@developer.example.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) 実名を使ってください。(残念ですが、偽名や匿名による寄与はできません。)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) 人によっては sign-off の近くに追加のタグを付加しています。それらは今のところ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) 無視されますが、あなたはそのタグを社内の手続きに利用したり、sign-off に特別
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) な情報を示したりすることができます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) あなたがサブシステムまたはブランチのメンテナであれば、受け取ったパッチを自身の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) ツリーにマージするために、わずかに変更が必要となる場合があります。なぜなら
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) あなたのツリーの中のコードと投稿者のツリーの中のコードは同一ではないためです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) もし、あなたが厳密に上記ルール(c)にこだわるのであれば、投稿者に再度差分を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) とるよう依頼すべきです。しかし、これは時間とエネルギーを非生産的に浪費する
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) ことになります。ルール(b)はあなたにコードを修正する権利を与えてくれます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) しかし、投稿者のコードを修正し、その修正によるバグを投稿者に押し付けてしまう
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) ことはとても失礼なことです。この問題を解決するために、末尾の投稿者の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) Signed-off-by とあなたがその末尾に追加する Signed-off-by の間に、修正を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) 加えたことを示す1行を追加することが推奨されています。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) (その1行の書き方に)決まりはありませんが、大括弧の中に電子メールアドレスや氏名
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) と修正内容を記載するやり方は目につきやすく、最終段階での変更の責任があなたに
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) あることを明確にするのに十分な方法のようです。例えば、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) 	Signed-off-by: Random J Developer <random@developer.example.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) 	[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) 	Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) あなたが安定版のブランチを管理しており、作成者のクレジット、変更の追跡、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) 修正のマージ、と同時に苦情からの投稿者の保護を行いたい場合、この慣習は特に
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) 有用となります。いかなる事情があってもチェンジログに出てくる作成者の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) アイデンティティ情報(From ヘッダ)は変更できないことに注意してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) バックポートする人のための特別な注意事項。追跡を容易に行うために、コミット
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) メッセージのトップ(サブジェクト行のすぐ後)にパッチの起源を示す情報を記述する
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) ことは一般的で有用な慣習です。例えば、これは 2.6-stable ツリーでの一例です。    
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371)     Date:   Tue May 13 19:10:30 2008 +0000
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373)         SCSI: libiscsi regression in 2.6.25: fix nop timer handling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375)         commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) そして、これは 2.4 ツリーでの一例です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379)     Date:   Tue May 13 22:12:27 2008 +0200
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381)         wireless, airo: waitbusy() won't delay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)         [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) どんな形式であれ、この情報はあなたのツリーを追跡する人やあなたのツリーのバグを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) 解決しようとしている人にとって価値のある支援となります。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) 13) いつ Acked-by: と Cc: を使うのか
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) 「 Signed-off-by: 」タグはその署名者がパッチの開発に関わっていたことやパッチ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) の伝播パスにいたことを示しています。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) ある人が直接パッチの準備や作成に関わっていないけれど、その人のパッチに対す
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) る承認を記録し、示したいとします。その場合、その人を示すのに Acked-by: が使
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) えます。Acked-by: はパッチのチェンジログにも追加されます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) パッチの影響を受けるコードのメンテナがパッチに関わっていなかったり、パッチ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) の伝播パスにいなかった時にも、メンテナは Acked-by: をしばしば利用します。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) Acked-by: は Signed-off-by: のように公式なタグではありません。それはメンテナが
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) 少なくともパッチをレビューし、同意を示しているという記録です。そのような
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) ことからパッチをマージする人がメンテナの「うん、良いと思うよ」という発言を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) Acked-by: へ置き換えることがあります。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) Acked-by: が必ずしもパッチ全体の承認を示しているわけではありません。例えば、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) あるパッチが複数のサブシステムへ影響を与えており、その中の1つのサブシステム
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) のメンテナからの Acked-by: を持っているとします。その場合、Acked-by: は通常
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) そのメンテナのコードに影響を与える一部分だけに対する承認を示しています。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) この点は、ご自分で判断してください。(その Acked-by: が)疑わしい場合は、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) メーリングリストアーカイブの中の大元の議論を参照すべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) パッチにコメントする機会を持っていたが、その時にコメントしなかった人がいれば、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) その人を指す「Cc:」タグを任意で追加してもかまいません。これは指定された人からの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) 明確なアクションなしに付与できる唯一のタグです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) このタグはパッチに関心があると思われる人達がそのパッチの議論に含まれていたこと
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) を明文化します。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) 14) Reported-by と Tested-by: と Reviewed-by: の利用
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) 他の誰かによって報告された問題を修正するパッチであれば、問題報告者という寄与を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) クレジットするために、Reported-by: タグを追加することを検討してください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) こまめにバグ報告者をクレジットしていくことで、うまくいけばその人たちが将来再び
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) コミュニティの力となってくれるでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) ただし、報告者の許可無くこのタグを追加しないように注意してください。特に、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) 問題が公の場で報告されていなかったのであれば。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) Tested-by: タグはタグで指定された人によって(ある環境下で)パッチのテストに成功
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) していることを示します。このタグはメンテナにテストが実施済みであることを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) 知らせ、将来の関連パッチのテスト協力者を見つける方法を提供し、テスト実施者に
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) 対するクレジットを保証します。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432) Reviewed-by: タグは、それとは異なり、下記のレビューア宣言の下にレビューされ、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) 受け入れ可能とみなされたパッチであることを示します。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435)         レビューアによる監督宣言
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437)         私は Reviewed-by: タグを提示することによって、以下のことを明言する。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439)         (a) 私はメインラインカーネルへの統合に向け、その妥当性及び「即応性
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440)             (訳注)」を検証し、技術的側面からパッチをレビュー済みである。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442)         訳注:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)         「即応性」の原文は "readiness"。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444)         パッチが十分な品質を持っており、メインラインカーネルへの統合を即座に
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445)         行うことができる状態であるかどうかを "readiness" という単語で表現
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446)         している。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448)         (b) パッチに関するあらゆる問題、懸念、あるいは、疑問は投稿者へ伝達済み
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449)             である。私はそれらのコメントに対する投稿者の返答に満足している。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451)         (c) 投稿に伴い改良されるコードがある一方で、現時点で、私は(1)それが
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452)             カーネルにとって価値のある変更であること、そして、(2)統合に際して
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453)             議論になり得るような問題はないものと確信している。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455)         (d) 私はパッチをレビューし適切であると確信している一方で、あらゆる
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456)             状況においてその宣言した目的や機能が正しく実現することに関して、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457)             いかなる保証もしない(特にどこかで明示しない限り)。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) Reviewd-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) 問題を残していないという意見の宣言です。興味のあるレビューアは誰でも(レビュー
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) 作業を終えたら)パッチに対して Reviewed-by タグを提示できます。このタグは
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) レビューアの寄与をクレジットする働き、レビューの進捗の度合いをメンテナに
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) 知らせる働きを持ちます。そのパッチの領域に詳しく、そして、しっかりとした
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) レビューを実施したレビューアによって提供される時、Reviewed-by: タグがあなたの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) パッチをカーネルにマージする可能性を高めるでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) 15) 標準的なパッチのフォーマット
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) 標準的なパッチのサブジェクトは以下のとおりです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471)     Subject: [PATCH 001/123] subsystem: summary phrase
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) 標準的なパッチの、電子メールのボディは以下の項目を含んでいます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475)   - パッチの作成者を明記する「 from 」行
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477)   - 空行
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479)   - 説明本体。これはこのパッチを説明するために無期限のチェンジログ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480)     (変更履歴)にコピーされます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482)   - 上述した「 Signed-off-by: 」行。これも説明本体と同じくチェン
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483)     ジログ内にコピーされます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485)   - マーカー行は単純に「 --- 」です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487)   - 余計なコメントは、チェンジログには不適切です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489)   - 実際のパッチ(差分出力)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) サブジェクト行のフォーマットは、アルファベット順で電子メールをとても
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) ソートしやすいものになっています。(ほとんどの電子メールクライアント
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) はソートをサポートしています)パッチのサブジェクトの連番は0詰めであ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) るため、数字でのソートとアルファベットでのソートは同じ結果になります。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) 電子メールのサブジェクト内のサブシステム表記は、パッチが適用される
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) 分野またはサブシステムを識別できるようにすべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) 電子メールのサブジェクトの「summary phrase」はそのパッチの概要を正確
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) に表現しなければなりません。「summary phrase」をファイル名にしてはい
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) けません。パッチシリーズ中でそれぞれのパッチは同じ「summary phrase」を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) 使ってはいけません(「パッチシリーズ」とは順序付けられた関連のある複数の
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) パッチ群です)。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) あなたの電子メールの「summary phrase」がそのパッチにとって世界で唯一の識別子に
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) なるように心がけてください。「summary phrase」は git のチェンジログの中へ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) ずっと伝播していきます。「summary phrase」は、開発者が後でパッチを参照する
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) ために議論の中で利用するかもしれません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) 人々はそのパッチに関連した議論を読むために「summary phrase」を使って google で
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) 検索したがるでしょう。それはまた2、3ヶ月あとで、人々が「gitk」や
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) 「git log --oneline」のようなツールを使用して何千ものパッチに目を通す時、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) 唯一目にとまる情報となるでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) これらの理由のため、「summary phrase」はなぜパッチが必要であるか、パッチが何を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) 変更するかの2つの情報をせいぜい70〜75文字で表現していなければなりません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516) 「summary phrase」は簡潔であり説明的である表現を目指しつつ、うまく
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) まとめられている概要となるべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) 「summary phrase」は「Subject: [PATCH tag] <summary phrase>」のように、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) 大括弧で閉じられたタグを接頭辞として付加してもかまいません。このタグは
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) 「summary phrase」の一部とは考えませんが、パッチをどのように取り扱うべきかを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522) 表現します。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) 一般的には「v1, v2, v3」のようなバージョン情報を表すタグ(過去のパッチに対する
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) コメントを反映するために複数のバージョンのパッチが投稿されているのであれば)、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) 「RFC」のようなコメントを要求するタグが挙げられます。パッチシリーズとして4つの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) パッチがあれば、個々のパッチに「1/4, 2/4, 3/4, 4/4」のように番号を付けても
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) かまいません。これは開発者がパッチを適用する順番を確実に把握するためです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) そして、開発者がパッチシリーズの中のすべてのパッチをもらさずレビュー或いは
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) 適用するのを保証するためです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) サブジェクトの例を二つ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533)     Subject: [patch 2/5] ext2: improve scalability of bitmap searching
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534)     Subject: [PATCHv2 001/207] x86: fix eflags tracking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536) 「 from 」行は電子メールのボディの一番最初の行でなければなりません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) その形式は以下のとおりです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539)         From: Original Author <author@example.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) 「 from 」行はチェンジログの中で、そのパッチの作成者としてクレジットされ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) ている人を特定するものです。「 from 」行がかけていると、電子メールのヘッ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) ダーの「 From: 」が、チェンジログの中でパッチの作成者を決定するために使わ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) れるでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) 説明本体は無期限のソースのチェンジログにコミットされます。なので、説明
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) 本体はそのパッチに至った議論の詳細を忘れているある程度の技量を持っている人
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) がその詳細を思い出すことができるものでなければなりません。パッチが対処する
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) 障害の症状(カーネルログメッセージや oops メッセージ等)を記載することは問題に
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) 対処可能なパッチを求めてコミットログを検索する人々にとって特に有用です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) パッチがコンパイル問題を解決するのであれば、そのパッチを探している人が見つける
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) ことができる情報だけで十分であり、コンパイル時の全てのエラーを含める必要は
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) ありません。「summary phrase」と同様に、簡潔であり説明的であることが重要です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) 「 --- 」マーカー行はパッチ処理ツールに対して、チェンジログメッセージの終端
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) 部分を認識させるという重要な役目を果たします。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) 「 --- 」マーカー行の後の追加コメントの良い使用方法の1つに diffstat コマンド
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) があります。diffstat コマンドとは何のファイルが変更され、1ファイル当たり何行
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) 追加され何行消されたかを示すものです。diffstat コマンドは特に大きなパッチに
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) おいて役立ちます。その時点でだけ又はメンテナにとってのみ関係のあるコメント
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) は無期限に保存されるチェンジログにとって適切ではありません。そのため、この
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) ようなコメントもマーカー行の後に書かれるべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) このようなコメントの良い例として、v1 と v2 のバージョン間で何が変更されたかを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) 表す「パッチの変更履歴」が挙げられます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) 「 --- 」マーカー行の後に diffstat コマンドの結果を含めるのであれば、ファイル
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) 名はカーネルソースツリーのトップディレクトリからの表記で列記されるため、横方向
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) のスペースをとり過ぎないように、diffstat コマンドにオプション「 -p 1 -w 70 」
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) を指定してください(インデントを含めてちょうど80列に合うでしょう)。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) 適切なパッチのフォーマットの詳細についてはセクション3の参考文献を参照して
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) ください。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575) 16) 「git pull」要求の送り方(Linus の電子メールから)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) 間違ったブランチから引っ張るのを防ぐために、git リポジトリのアドレスと
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) ブランチ名を同じ行に1行で記載してください。そうすることで、3回の連続クリック
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) で全て選択できます。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) 正しい形式は下記の通りです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) 	"Please pull from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) 		git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) 	 to get these changes:"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) その結果、アドレスを自分自身でタイピングして間違えることはなくなります(実際に、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) 何度か間違ったブランチから引っ張ってきてしまい、その時に diffstat の結果を
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591) 検証して間違っていることに気づいたことがあります。どこから何を引っ張るべきかを
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) 「探したり」、正しいブランチ名かどうかを重ねてチェックしたりする必要が
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) なくなればより快適になるでしょう)。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) diffstat の結果を生成するために「 git diff -M --stat --summary 」を使って
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) ください。-M オプションはファイル名の変更を検知でき、--summary オプションは
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) 新規ファイル、削除されたファイル、名前が変更されたファイルの概要を生成します。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599) -M オプション(ファイル名の変更検知)を指定すると、diffstat の結果はかなり
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) 異なってきます。git は大規模な変更(追加と削除のペア)をファイル名の変更と
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) 判断するためです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) ------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) セクション2 - ヒントとTIPSと小技
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605) ------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) このセクションは Linux カーネルに変更を適用することに関係のある一般的な
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) 「お約束」の多くを載せています。物事には例外というものがあります。しか
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609) し例外を適用するには、本当に妥当な理由が不可欠です。あなたは恐らくこの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) セクションを Linus のコンピュータ・サイエンス101と呼ぶでしょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) 1) Documentation/process/coding-style.rstを参照
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) 言うまでもなく、あなたのコードがこのコーディングスタイルからあまりに
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) も逸脱していると、レビューやコメントなしに受け取ってもらえないかもし
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) れません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) 特筆すべき例外は、コードをあるファイルから別のファイルに移動
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) するときです。この場合、コードを移動するパッチでは、移動されるコード
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) に関して移動以外の変更を一切加えるべきではありません。これにより、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) コードの移動とあなたが行ったコードの修正を明確に区別できるようにな
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) ります。これは実際に何が変更されたかをレビューする際の大きな助けに
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) なるとともに、ツールにコードの履歴を追跡させることも容易になります。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) 投稿するより前にパッチのスタイルチェッカー( scripts/checkpatch.pl )で
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) あなたのパッチをチェックしてください。このスタイルチェッカーは最終結
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627) 論としてではなく、指標としてみるべきです。もし、あなたのコードが違反
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) はしているが修正するより良く見えるのであれば、おそらくそのままにする
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629) のがベストです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) スタイルチェッカーによる3段階のレポート:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632)  - エラー: 間違っている可能性が高い
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633)  - 警告:注意してレビューする必要がある
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634)  - チェック:考慮する必要がある
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) あなたはパッチに残っている全ての違反について、それがなぜ必要なのか正当な
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) 理由を示せるようにしておく必要があります。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) 2) #ifdefは見苦しい
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641) ifdef が散乱したコードは、読むのもメンテナンスするのも面倒です。コードの中
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642) で ifdef を使わないでください。代わりに、ヘッダファイルの中に ifdef を入れて、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) 条件付きで、コードの中で使われる関数を「 static inline 」関数かマクロで定義し
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644) てください。後はコンパイラが、何もしない箇所を最適化して取り去ってくれるで
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645) しょう。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647) まずいコードの簡単な例
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649) 	dev = alloc_etherdev (sizeof(struct funky_private));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650) 	if (!dev)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651) 		return -ENODEV;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652) 	#ifdef CONFIG_NET_FUNKINESS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653) 	init_funky_net(dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 654) 	#endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 655) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 656) クリーンアップしたコードの例
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 657) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 658) (in header)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 659) 	#ifndef CONFIG_NET_FUNKINESS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 660) 	static inline void init_funky_net (struct net_device *d) {}
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 661) 	#endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 662) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 663) (in the code itself)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 664) 	dev = alloc_etherdev (sizeof(struct funky_private));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 665) 	if (!dev)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 666) 		return -ENODEV;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 667) 	init_funky_net(dev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 668) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 669) 3) マクロより「 static inline 」を推奨
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 670) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 671) 「 static inline 」関数はマクロよりもずっと推奨されています。それらは、
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 672) 型安全性があり、長さにも制限が無く、フォーマットの制限もありません。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 673) gcc においては、マクロと同じくらい軽いです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 674) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 675) マクロは「 static inline 」が明らかに不適切であると分かる場所(高速化パスの
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 676) いくつかの特定のケース)や「 static inline 」関数を使うことができないような
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 677) 場所(マクロの引数の文字列連結のような)にだけ使われるべきです。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 678) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 679) 「 static inline 」は「 static __inline__ 」や「 extern inline 」や
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 680) 「 extern __inline__ 」よりも適切です。
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 681) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 682) 4) 設計に凝りすぎるな
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 683) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 684) それが有用になるかどうか分からないような不明瞭な将来を見越した設計
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 685) をしないでください。「できる限り簡単に、そして、それ以上簡単になら
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 686) ないような設計をしてください。」
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 687) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 688) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 689) セクション3 参考文献
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 690) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 691) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 692) Andrew Morton, "The perfect patch" (tpp).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 693)   <http://www.ozlabs.org/~akpm/stuff/tpp.txt>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 694) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 695) Jeff Garzik, "Linux kernel patch submission format".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 696)   <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 697) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 698) Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 699)   <http://www.kroah.com/log/2005/03/31/>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 700)   <http://www.kroah.com/log/2005/07/08/>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 701)   <http://www.kroah.com/log/2005/10/19/>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 702)   <http://www.kroah.com/log/2006/01/11/>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 703) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 704) NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 705)   <https://lkml.org/lkml/2005/7/11/336>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 706) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 707) Kernel Documentation/process/coding-style.rst:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 708)   <http://users.sosdg.org/~qiyong/lxr/source/Documentation/process/coding-style.rst>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 709) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 710) Linus Torvalds's mail on the canonical patch format:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 711)   <http://lkml.org/lkml/2005/4/7/183>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 712) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 713) Andi Kleen, "On submitting kernel patches"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 714)   Some strategies to get difficult or controversial changes in.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 715)   http://halobates.de/on-submitting-patches.pdf
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 716) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 717) --
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 718) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 719)