/Documentation/ja_JP/SubmittingPatches

https://bitbucket.org/sammyz/iscream_thunderc-2.6.35-rebase · #! · 556 lines · 419 code · 137 blank · 0 comment · 0 complexity · 9788f085638a6e50ea14c0f676daa9c0 MD5 · raw file

  1. NOTE:
  2. This is a version of Documentation/SubmittingPatches into Japanese.
  3. This document is maintained by Keiichi KII <k-keiichi@bx.jp.nec.com>
  4. and the JF Project team <http://www.linux.or.jp/JF/>.
  5. If you find any difference between this document and the original file
  6. or a problem with the translation,
  7. please contact the maintainer of this file or JF project.
  8. Please also note that the purpose of this file is to be easier to read
  9. for non English (read: Japanese) speakers and is not intended as a
  10. fork. So if you have any comments or updates of this file, please try
  11. to update the original English file first.
  12. Last Updated: 2007/10/24
  13. ==================================
  14. これは
  15. linux-2.6.23/Documentation/SubmittingPatches の和訳
  16. です
  17. 翻訳団体 JF プロジェクト < http://www.linux.or.jp/JF/ >
  18. 翻訳日 2007/10/17
  19. 翻訳者 Keiichi Kii <k-keiichi at bx dot jp dot nec dot com>
  20. 校正者 Masanari Kobayashi さん <zap03216 at nifty dot ne dot jp>
  21. Matsukura さん <nbh--mats at nifty dot com>
  22. ==================================
  23. Linux カーネルに変更を加えるための Howto
  24. 又は
  25. かの Linus Torvalds の取り扱い説明書
  26. Linux カーネルに変更を加えたいと思っている個人又は会社にとってパッ
  27. チの投稿に関連した仕組みに慣れていなければその過程は時々みなさんを
  28. おじけづかせることもありますこの文章はあなたの変更を大いに受け入れ
  29. てもらえやすくする提案を集めたものです
  30. コードを投稿する前にDocumentation/SubmitChecklist の項目リストに目
  31. を通してチェックしてくださいもしあなたがドライバーを投稿しようとし
  32. ているならDocumentation/SubmittingDrivers にも目を通してください
  33. --------------------------------------------
  34. セクション1 パッチの作り方と送り方
  35. --------------------------------------------
  36. 1) diff -up
  37. ------------
  38. パッチの作成には diff -up 又は diff -uprN を使ってください
  39. Linux カーネルに対する全ての変更は diff(1) コマンドによるパッチの形式で
  40. 生成してくださいパッチを作成するときにはdiff(1) コマンドに -u
  41. 数を指定してunified 形式のパッチを作成することを確認してくださいまた
  42. 変更がどの C 関数で行われたのかを表示する -p 引数を使ってください
  43. この引数は生成した差分をずっと読みやすくしてくれますパッチは Linux
  44. カーネルソースの中のサブディレクトリではなく Linux カーネルソースのルート
  45. ディレクトリを基準にしないといけません
  46. 1個のファイルについてのパッチを作成するためにはほとんどの場合
  47. 以下の作業を行えば十分です
  48. SRCTREE= linux-2.6
  49. MYFILE= drivers/net/mydriver.c
  50. cd $SRCTREE
  51. cp $MYFILE $MYFILE.orig
  52. vi $MYFILE # make your change
  53. cd ..
  54. diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
  55. 複数のファイルについてのパッチを作成するためには素の( vanilla )
  56. なわち変更を加えてない Linux カーネルを展開し自分の Linux カーネル
  57. ソースとの差分を生成しないといけません例えば
  58. MYSRC= /devel/linux-2.6
  59. tar xvfz linux-2.6.12.tar.gz
  60. mv linux-2.6.12 linux-2.6.12-vanilla
  61. diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
  62. linux-2.6.12-vanilla $MYSRC > /tmp/patch
  63. dontdiff ファイルには Linux カーネルのビルドプロセスの過程で生成された
  64. ファイルの一覧がのっていますそしてそれらはパッチを生成する diff(1)
  65. コマンドで無視されるべきですdontdiff ファイルは 2.6.12 以後のバージョ
  66. ンの Linux カーネルソースツリーに含まれていますそれより前のバージョン
  67. Linux カーネルソースツリーに対する dontdiff ファイルは
  68. <http://www.xenotime.net/linux/doc/dontdiff>から取得することができます。
  69. 投稿するパッチの中に関係のない余分なファイルが含まれていないことを確
  70. 認してくださいdiff(1) コマンドで生成したパッチがあなたの意図したとお
  71. りのものであることを確認してください
  72. もしあなたのパッチが多くの差分を生み出すのであればあなたはパッチ
  73. を意味のあるひとまとまりごとに分けたいと思うかもしれません
  74. これは他のカーネル開発者にとってレビューしやすくなるのであなたの
  75. パッチを受け入れてもらうためにはとても重要なことですこれを補助でき
  76. る多くのスクリプトがあります
  77. Quilt:
  78. http://savannah.nongnu.org/projects/quilt
  79. Andrew Morton's patch scripts:
  80. http://www.zip.com.au/~akpm/linux/patches/
  81. このリンクの先のスクリプトの代わりとしてquilt がパッチマネジメント
  82. ツールとして推奨されています(上のリンクを見てください)
  83. 2) パッチに対する説明
  84. パッチの中の変更点に対する技術的な詳細について説明してください
  85. 説明はできる限り具体的にもっとも悪い説明はドライバー X を更新
  86. ドライバー X に対するバグフィックスあるいはこのパッチはサブシス
  87. テム X に対する更新を含んでいますどうか取り入れてくださいなどです
  88. 説明が長くなりだしたのであればおそらくそれはパッチを分ける必要がある
  89. という兆候です次の #3 を見てください
  90. 3) パッチの分割
  91. 意味のあるひとまとまりごとに変更を個々のパッチファイルに分けてください
  92. 例えばもし1つのドライバーに対するバグフィックスとパフォーマンス強
  93. 化の両方の変更を含んでいるのであればその変更を2つ以上のパッチに分
  94. けてくださいもし変更箇所に API の更新とその新しい API を使う新たな
  95. ドライバーが含まれているなら2つのパッチに分けてください
  96. 一方でもしあなたが多数のファイルに対して意味的に同じ1つの変更を加え
  97. るのであればその変更を1つのパッチにまとめてください言いかえると
  98. 意味的に同じ1つの変更は1つのパッチの中に含まれます
  99. あるパッチが変更を完結させるために他のパッチに依存していたとしても
  100. それは問題ありませんパッチの説明の中でこのパッチはパッチ X に依存
  101. していると簡単に注意書きをつけてください
  102. もしパッチをより小さなパッチの集合に凝縮することができないならまずは
  103. 15かそこらのパッチを送りそのレビューと統合を待って下さい
  104. 4) パッチのスタイルチェック
  105. あなたのパッチが基本的な( Linux カーネルの)コーディングスタイルに違反し
  106. ていないかをチェックして下さいその詳細を Documentation/CodingStyle
  107. 見つけることができますコーディングスタイルの違反はレビューする人の
  108. 時間を無駄にするだけなので恐らくあなたのパッチは読まれることすらなく
  109. 拒否されるでしょう
  110. あなたはパッチを投稿する前に最低限パッチスタイルチェッカー
  111. ( scripts/patchcheck.pl )を利用してパッチをチェックすべきです
  112. もしパッチに違反がのこっているならばそれらの全てについてあなたは正当な
  113. 理由を示せるようにしておく必要があります
  114. 5) 電子メールの宛先の選び方
  115. MAINTAINERS ファイルとソースコードに目を通してくださいそしてその変
  116. 更がメンテナのいる特定のサブシステムに加えられるものであることが分か
  117. ればその人に電子メールを送ってください
  118. もしメンテナが載っていなかったりメンテナからの応答がないなら
  119. LKML ( linux-kernel@vger.kernel.org )へパッチを送ってくださいほとんど
  120. のカーネル開発者はこのメーリングリストに目を通しており変更に対して
  121. コメントを得ることができます
  122. 15個より多くのパッチを同時に vger.kernel.org のメーリングリストへ送らな
  123. いでください!!!
  124. Linus Torvalds Linux カーネルに入る全ての変更に対する最終的な意思決定者
  125. です電子メールアドレスは torvalds@linux-foundation.org になります彼は
  126. 多くの電子メールを受け取っているためできる限り彼に電子メールを送るのは
  127. 避けるべきです
  128. バグフィックスであったり自明な変更であったり話し合いをほとんど
  129. 必要としないパッチは Linus へ電子メールを送るか CC しなければなりません
  130. 話し合いを必要としたり明確なアドバンテージがないパッチは通常まず
  131. LKML へ送られるべきですパッチが議論された後にだけそのパッチを
  132. Linus へ送るべきです
  133. 6) CC (カーボンコピー)先の選び方
  134. 特に理由がないならLKML にも CC してください
  135. Linus 以外のカーネル開発者は変更に気づく必要がありその結果彼らはそ
  136. の変更に対してコメントをくれたりコードに対してレビューや提案をくれ
  137. るかもしれませんLKML とは Linux カーネル開発者にとって一番中心的なメー
  138. リングリストですUSB やフレームバッファデバイスや VFS SCSI サブシステ
  139. ムなどの特定のサブシステムに関するメーリングリストもありますあなた
  140. の変更にはっきりと関連のあるメーリングリストについて知りたければ
  141. MAINTAINERS ファイルを参照してください
  142. VGER.KERNEL.ORG でホスティングされているメーリングリストの一覧が下記の
  143. サイトに載っています
  144. <http://vger.kernel.org/vger-lists.html>
  145. もし変更がユーザランドのカーネルインタフェースに影響を与え
  146. るのであればMAN-PAGES のメンテナ( MAINTAINERS ファイルに一覧
  147. があります) man ページのパッチを送ってください少なくとも
  148. 情報がマニュアルページの中に入ってくるように変更が起きたという
  149. 通知を送ってください
  150. たとえメンテナが #4 で反応がなかったとしてもメンテナのコードに変更を
  151. 加えたときにはいつもメンテナに CC するのを忘れないようにしてください
  152. 小さなパッチであればAdrian Bunk が管理している Trivial Patch Monkey
  153. (ちょっとしたパッチを集めている)<trivial@kernel.org> CC してもいい
  154. ですちょっとしたパッチとは以下のルールのどれか1つを満たしていなけ
  155. ればなりません
  156. ドキュメントのスペルミスの修正
  157. grep(1) コマンドによる検索を困難にしているスペルの修正
  158. コンパイル時の警告の修正(無駄な警告が散乱することは好ましくないた
  159. めです)
  160. コンパイル問題の修正(それらの修正が本当に正しい場合に限る)
  161. 実行時の問題の修正(それらの修正が本当に問題を修正している場合に限る)
  162. 廃止予定の関数やマクロを使用しているコードの除去( check_region )
  163. 問い合わせ先やドキュメントの修正
  164. 移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で
  165. あればアーキテクチャ特有のことでも他の人がコピーできます)
  166. 作者やメンテナによる修正(すなわち patch monkey の再転送モード)
  167. URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
  168. 7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ
  169. Linus や他のカーネル開発者はあなたが投稿した変更を読んでコメントでき
  170. る必要がありますカーネル開発者にとってあなたが書いたコードの特定の
  171. 部分にコメントをするために標準的な電子メールクライアントで変更が引用
  172. できることは重要です
  173. 上記の理由ですべてのパッチは文中に含める形式の電子メールで投稿さ
  174. れるべきです警告あなたがパッチをコピー&ペーストする際にはパッ
  175. チを改悪するエディターの折り返し機能に注意してください
  176. パッチを圧縮の有無に関わらず MIME 形式で添付しないでください多くのポ
  177. ピュラーな電子メールクライアントは MIME 形式の添付ファイルをプレーンテ
  178. キストとして送信するとは限らないでしょうそうなると電子メールクラ
  179. イアントがコードに対するコメントを付けることをできなくしますまた
  180. MIME 形式の添付ファイルは Linus に手間を取らせることになりその変更を
  181. 受け入れてもらう可能性が低くなってしまいます
  182. 例外お使いの電子メールクライアントがパッチをめちゃくちゃにするので
  183. あれば誰かが MIME 形式のパッチを再送するよう求めるかもしれません
  184. 警告 Mozilla のような特定の電子メールクライアントは電子メールの
  185. ヘッダに以下のものを付加して送ります
  186. ---- message header ----
  187. Content-Type: text/plain; charset=us-ascii; format=flowed
  188. ---- message header ----
  189. 問題は format=flowed が付いた電子メールを特定の受信側の電子メール
  190. クライアントがタブをスペースに置き換えるというような変更をすることです
  191. したがって送られてきたパッチは壊れているように見えるでしょう
  192. これを修正するにはmozilla defaults/pref/mailnews.js ファイルを
  193. 以下のように修正します
  194. pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
  195. pref("mailnews.display.disable_format_flowed_support", true);
  196. 8) 電子メールのサイズ
  197. パッチを Linus へ送るときは常に #7 の手順に従ってください
  198. 大きなパッチはメーリングリストやメンテナにとって不親切ですパッチが
  199. 未圧縮で 40KB を超えるようであるならインターネット上のアクセス可能な
  200. サーバに保存し保存場所を示す URL を伝えるほうが適切です
  201. 9) カーネルバージョンの明記
  202. パッチが対象とするカーネルのバージョンをパッチの概要か電子メールの
  203. サブジェクトに付けることが重要です
  204. パッチが最新バージョンのカーネルに正しく適用できなければLinus
  205. そのパッチを採用しないでしょう
  206. 10) がっかりせず再投稿
  207. パッチを投稿した後は辛抱強く待っていてくださいLinus があなたのパッ
  208. チを気に入って採用すればLinus がリリースする次のバージョンのカーネル
  209. の中で姿を見せるでしょう
  210. しかしパッチが次のバージョンのカーネルに入っていないならいくつもの
  211. 理由があるのでしょうその原因を絞り込み間違っているものを正し更新
  212. したパッチを投稿するのはあなたの仕事です
  213. Linus があなたのパッチに対して何のコメントもなく不採用にすることは極め
  214. て普通のことですそれは自然な姿ですもしLinus があなたのパッチを受
  215. け取っていないのであれば以下の理由が考えられます
  216. * パッチが最新バージョンの Linux カーネルにきちんと適用できなかった
  217. * パッチが LKML で十分に議論されていなかった
  218. * スタイルの問題(セクション2を参照)
  219. * 電子メールフォーマットの問題(このセクションを参照)
  220. * パッチに対する技術的な問題
  221. * Linus はたくさんの電子メールを受け取っているのでどさくさに紛れて見
  222. 失った
  223. * 不愉快にさせている
  224. 判断できない場合はLKML にコメントを頼んでください
  225. 11) サブジェクトに PATCH
  226. Linus LKML への大量の電子メールのためにサブジェクトのプレフィックスに
  227. [PATCH] を付けることが慣習となっていますこれによって Linus や他の
  228. カーネル開発者がパッチであるのか又は他の議論に関する電子メールであるの
  229. かをより簡単に識別できます
  230. 12) パッチへの署名
  231. 誰が何をしたのかを追いかけやすくするために (特にパッチが何人かの
  232. メンテナを経て最終的に Linux カーネルに取り込まれる場合のために)電子
  233. メールでやり取りされるパッチに対して sign-off という手続きを導入し
  234. ました
  235. sign-off とはパッチがあなたの書いたものであるかあるいは
  236. あなたがそのパッチをオープンソースとして提供する権利を保持している
  237. という証明をパッチの説明の末尾に一行記載するというものです
  238. ルールはとても単純です以下の項目を確認して下さい
  239. 原作者の証明書( DCO ) 1.1
  240. このプロジェクトに寄与するものとして以下のことを証明する
  241. (a) 本寄与は私が全体又は一部作成したものであり私がそのファイ
  242. ル中に明示されたオープンソースライセンスの下で公開する権利
  243. を持っているもしくは
  244. (b) 本寄与は私が知る限り適切なオープンソースライセンスでカバ
  245. ーされている既存の作品を元にしている同時に私はそのライセ
  246. ンスの下で私が全体又は一部作成した修正物をファイル中で示
  247. される同一のオープンソースライセンスで(異なるライセンスの下で
  248. 投稿することが許可されている場合を除いて)投稿する権利を持って
  249. いるもしくは
  250. (c) 本寄与は(a)(b)(c)を証明する第3者から私へ直接提供された
  251. ものであり私はそれに変更を加えていない
  252. (d) 私はこのプロジェクトと本寄与が公のものであることに理解及び同意す
  253. 同時に関与した記録(投稿の際の全ての個人情報と sign-off
  254. 含む)が無期限に保全されることと当該プロジェクト又は関連する
  255. オープンソースライセンスに沿った形で再配布されることに理解及び
  256. 同意する
  257. もしこれに同意できるなら以下のような1行を追加してください
  258. Signed-off-by: Random J Developer <random@developer.example.org>
  259. 実名を使ってください(残念ですが偽名や匿名による寄与はできません)
  260. 人によっては sign-off の近くに追加のタグを付加していますそれらは今のところ
  261. 無視されますがあなたはそのタグを社内の手続きに利用したりsign-off に特別
  262. な情報を示したりすることができます
  263. 13) いつ Acked-by: を使うのか
  264. Signed-off-by: タグはその署名者がパッチの開発に関わっていたことやパッチ
  265. の伝播パスにいたことを示しています
  266. ある人が直接パッチの準備や作成に関わっていないけれどその人のパッチに対す
  267. る承認を記録し示したいとしますその場合その人を示すのに Acked-by: が使
  268. えますAcked-by: はパッチのチェンジログにも追加されます
  269. パッチの影響を受けるコードのメンテナがパッチに関わっていなかったりパッチ
  270. の伝播パスにいなかった時にもメンテナは Acked-by: をしばしば利用します
  271. Acked-by: Signed-off-by: のように公式なタグではありませんそれはメンテナが
  272. 少なくともパッチをレビューし同意を示しているという記録ですそのような
  273. ことからパッチの統合者がメンテナのうん良いと思うよという発言を
  274. Acked-by: へ置き換えることがあります
  275. Acked-by: が必ずしもパッチ全体の承認を示しているわけではありません例えば
  276. あるパッチが複数のサブシステムへ影響を与えておりその中の1つのサブシステム
  277. のメンテナからの Acked-by: を持っているとしますその場合Acked-by: は通常
  278. そのメンテナのコードに影響を与える一部分だけに対する承認を示しています
  279. この点はご自分で判断してください(その Acked-by: )疑わしい場合は
  280. メーリングリストアーカイブの中の大元の議論を参照すべきです
  281. 14) 標準的なパッチのフォーマット
  282. 標準的なパッチのサブジェクトは以下のとおりです
  283. Subject: [PATCH 001/123] subsystem: summary phrase
  284. 標準的なパッチの電子メールのボディは以下の項目を含んでいます
  285. - パッチの作成者を明記する from
  286. - 空行
  287. - 説明本体これはこのパッチを説明するために無期限のチェンジログ
  288. (変更履歴)にコピーされます
  289. - 上述した Signed-off-by: これも説明本体と同じくチェン
  290. ジログ内にコピーされます
  291. - マーカー行は単純に --- です
  292. - 余計なコメントはチェンジログには不適切です
  293. - 実際のパッチ(差分出力)
  294. サブジェクト行のフォーマットはアルファベット順で電子メールをとても
  295. ソートしやすいものになっています(ほとんどの電子メールクライアント
  296. はソートをサポートしています)パッチのサブジェクトの連番は0詰めであ
  297. るため数字でのソートとアルファベットでのソートは同じ結果になります
  298. 電子メールのサブジェクト内のサブシステム表記はパッチが適用される
  299. 分野またはサブシステムを識別できるようにすべきです
  300. 電子メールのサブジェクトの概要の言い回しはそのパッチの概要を正確
  301. に表現しなければなりません概要の言い回しをファイル名にしてはい
  302. けません一連のパッチ中でそれぞれのパッチは同じ概要の言い回し
  303. 使ってはいけません(一連のパッチとは順序付けられた関連のある複数の
  304. パッチ群です)
  305. あなたの電子メールの概要の言い回しがそのパッチにとって世界で唯
  306. 一の識別子になるように心がけてください概要の言い回し git
  307. チェンジログの中へずっと伝播していきます概要の言い回し
  308. 発者が後でパッチを参照するために議論の中で利用するかもしれません
  309. 人々はそのパッチに関連した議論を読むために概要の言い回しを使って
  310. google で検索したがるでしょう
  311. サブジェクトの例を二つ
  312. Subject: [patch 2/5] ext2: improve scalability of bitmap searching
  313. Subject: [PATCHv2 001/207] x86: fix eflags tracking
  314. from 行は電子メールのボディの一番最初の行でなければなりません
  315. その形式は以下のとおりです
  316. From: Original Author <author@example.com>
  317. from 行はチェンジログの中でそのパッチの作成者としてクレジットされ
  318. ている人を特定するものです from 行がかけていると電子メールのヘッ
  319. ダーの From: チェンジログの中でパッチの作成者を決定するために使わ
  320. れるでしょう
  321. 説明本体は無期限のソースのチェンジログにコミットされますなので説明
  322. 本体はそのパッチに至った議論の詳細を忘れているある程度の技量を持っている人
  323. がその詳細を思い出すことができるものでなければなりません
  324. --- マーカー行はパッチ処理ツールに対してチェンジログメッセージの終端
  325. 部分を認識させるという重要な役目を果たします
  326. --- マーカー行の後の追加コメントの良い使用方法の1つに diffstat コマンド
  327. がありますdiffstat コマンドとは何のファイルが変更され1ファイル当たり何行
  328. 追加され何行消されたかを示すものですdiffstat コマンドは特に大きなパッチに
  329. おいて役立ちますその時点でだけ又はメンテナにとってのみ関係のあるコメント
  330. は無期限に保存されるチェンジログにとって適切ではありませんそのためこの
  331. ようなコメントもマーカー行の後に書かれるべきですファイル名はカーネルソー
  332. スツリーのトップディレクトリからの表記でリストされるため横方向のスペース
  333. をとり過ぎないようにdiffstat コマンドにオプション -p 1 -w 70 を指定し
  334. てください(インデントを含めてちょうど80列に合うでしょう)
  335. 適切なパッチのフォーマットの詳細についてはセクション3の参考文献を参照して
  336. ください
  337. ------------------------------------
  338. セクション2 - ヒントとTIPSと小技
  339. ------------------------------------
  340. このセクションは Linux カーネルに変更を適用することに関係のある一般的な
  341. お約束の多くを載せています物事には例外というものがありますしか
  342. し例外を適用するには本当に妥当な理由が不可欠ですあなたは恐らくこの
  343. セクションを Linus のコンピュータサイエンス101と呼ぶでしょう
  344. 1) Documentation/CodingStyleを参照
  345. 言うまでもなくあなたのコードがこのコーディングスタイルからあまりに
  346. も逸脱しているとレビューやコメントなしに受け取ってもらえないかもし
  347. れません
  348. 唯一の特筆すべき例外はコードをあるファイルから別のファイルに移動
  349. するときですこの場合コードを移動するパッチでは移動されるコード
  350. に関して移動以外の変更を一切加えるべきではありませんこれにより
  351. コードの移動とあなたが行ったコードの修正を明確に区別できるようにな
  352. りますこれは実際に何が変更されたかをレビューする際の大きな助けに
  353. なるとともにツールにコードの履歴を追跡させることも容易になります
  354. 投稿するより前にパッチのスタイルチェッカー( scripts/checkpatch.pl )
  355. あなたのパッチをチェックしてくださいこのスタイルチェッカーは最終結
  356. 論としてではなく指標としてみるべきですもしあなたのコードが違反
  357. はしているが修正するより良く見えるのであればおそらくそのままにする
  358. のがベストです
  359. スタイルチェッカーによる3段階のレポート:
  360. - エラー: 間違っている可能性が高い
  361. - 警告注意してレビューする必要がある
  362. - チェック考慮する必要がある
  363. あなたはパッチに残っている全ての違反についてそれがなぜ必要なのか正当な
  364. 理由を示せるようにしておく必要があります
  365. 2) #ifdefは見苦しい
  366. ifdef が散乱したコードは読むのもメンテナンスするのも面倒ですコードの中
  367. ifdef を使わないでください代わりにヘッダファイルの中に ifdef を入れて
  368. 条件付きでコードの中で使われる関数を static inline 関数かマクロで定義し
  369. てください後はコンパイラが何もしない箇所を最適化して取り去ってくれるで
  370. しょう
  371. まずいコードの簡単な例
  372. dev = alloc_etherdev (sizeof(struct funky_private));
  373. if (!dev)
  374. return -ENODEV;
  375. #ifdef CONFIG_NET_FUNKINESS
  376. init_funky_net(dev);
  377. #endif
  378. クリーンアップしたコードの例
  379. (in header)
  380. #ifndef CONFIG_NET_FUNKINESS
  381. static inline void init_funky_net (struct net_device *d) {}
  382. #endif
  383. (in the code itself)
  384. dev = alloc_etherdev (sizeof(struct funky_private));
  385. if (!dev)
  386. return -ENODEV;
  387. init_funky_net(dev);
  388. 3) マクロより static inline を推奨
  389. static inline 関数はマクロよりもずっと推奨されていますそれらは
  390. 型安全性があり長さにも制限が無くフォーマットの制限もありません
  391. gcc においてはマクロと同じくらい軽いです
  392. マクロは static inline が明らかに不適切であると分かる場所(高速化パスの
  393. いくつかの特定のケース) static inline 関数を使うことができないような
  394. 場所(マクロの引数の文字列連結のような)にだけ使われるべきです
  395. static inline static __inline__ extern inline
  396. extern __inline__ よりも適切です
  397. 4) 設計に凝りすぎるな
  398. それが有用になるかどうか分からないような不明瞭な将来を見越した設計
  399. をしないでくださいできる限り簡単にそしてそれ以上簡単になら
  400. ないような設計をしてください
  401. ----------------------
  402. セクション3 参考文献
  403. ----------------------
  404. Andrew Morton, "The perfect patch" (tpp).
  405. <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
  406. Jeff Garzik, "Linux kernel patch submission format".
  407. <http://linux.yyz.us/patch-format.html>
  408. Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
  409. <http://www.kroah.com/log/2005/03/31/>
  410. <http://www.kroah.com/log/2005/07/08/>
  411. <http://www.kroah.com/log/2005/10/19/>
  412. <http://www.kroah.com/log/2006/01/11/>
  413. NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
  414. <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
  415. Kernel Documentation/CodingStyle:
  416. <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
  417. Linus Torvalds's mail on the canonical patch format:
  418. <http://lkml.org/lkml/2005/4/7/183>
  419. --