/Documentation/ja_JP/HOWTO

https://bitbucket.org/abioy/linux · #! · 687 lines · 556 code · 131 blank · 0 comment · 0 complexity · 66b6ca6ca3dd37b73247bf21bd4f4222 MD5 · raw file

  1. NOTE:
  2. This is a version of Documentation/HOWTO translated into Japanese.
  3. This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
  4. and the JF Project team <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 for this file, please try
  11. to update the original English file first.
  12. Last Updated: 2008/10/24
  13. ==================================
  14. これは
  15. linux-2.6.28/Documentation/HOWTO
  16. の和訳です
  17. 翻訳団体 JF プロジェクト < http://www.linux.or.jp/JF/ >
  18. 翻訳日 2008/10/24
  19. 翻訳者 Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
  20. 校正者 松倉さん <nbh--mats at nifty dot com>
  21. 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
  22. 武井伸光さん<takei at webmasters dot gr dot jp>
  23. かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp>
  24. 野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
  25. 河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
  26. 岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
  27. 内田さん (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
  28. ==================================
  29. Linux カーネル開発のやり方
  30. -------------------------------
  31. これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した
  32. ドキュメントですここには Linux カーネル開発者になるための方法と
  33. Linux カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれて
  34. いますカーネルプログラミングに関する技術的な項目に関することは何も含
  35. めないようにしていますがカーネル開発者となるための正しい方向に向かう
  36. 手助けになります
  37. もしこのドキュメントのどこかが古くなっていた場合にはこのドキュメン
  38. トの最後にリストしたメンテナにパッチを送ってください
  39. はじめに
  40. ---------
  41. あなたは Linux カーネルの開発者になる方法を学びたいのでしょうか 
  42. れともあなたは上司からこのデバイスの Linux ドライバを書くように
  43. 言われているのでしょうか 
  44. この文書の目的はあなたが踏むべき手順とコミュニティと一緒にうまく働
  45. くヒントを書き下すことであなたが知るべき全てのことを教えることです
  46. またこのコミュニティがなぜ今うまくまわっているのかという理由の一部も
  47. 説明しようと試みています
  48. カーネルは 少量のアーキテクチャ依存部分がアセンブリ言語で書かれている
  49. 以外は大部分は C 言語で書かれていますC言語をよく理解していることはカー
  50. ネル開発者には必要ですアーキテクチャ向けの低レベル部分の開発をするの
  51. でなければ(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要あり
  52. ません以下の本はC 言語の十分な知識や何年もの経験に取って代わるもの
  53. ではありませんが少なくともリファレンスとしては良い本です
  54. - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
  55. -プログラミング言語C第2版(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
  56. - "Practical C Programming" by Steve Oualline [O'Reilly]
  57. - C実践プログラミング第3版(Steve Oualline著 望月康司監訳 谷口功訳) [オライリージャパン]
  58. - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
  59. - 詳説 C 言語 H&S リファレンス
  60. (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク]
  61. カーネルは GNU C GNU ツールチェインを使って書かれていますカーネル
  62. ISO C89 仕様に準拠して書く一方で標準には無い言語拡張を多く使って
  63. いますカーネルは標準 C ライブラリとは関係がないといったC 言語フリー
  64. スタンディング環境ですそのためC の標準で使えないものもあります
  65. 意の long long の除算や浮動小数点は使えません
  66. ときどきカーネルがツールチェインや C 言語拡張に置いている前提がどう
  67. なっているのかわかりにくいことがありまた残念なことに決定的なリファ
  68. レンスは存在しません情報を得るにはgcc info ページ( info gcc )
  69. 見てください
  70. あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
  71. とに留意してくださいそのコミュニティはコーディングスタイル
  72. 開発手順について高度な標準を持つ多様な人の集まりです
  73. 地理的に分散した大規模なチームに対してもっともうまくいくとわかったこと
  74. をベースにしながらこれらの標準は長い時間をかけて築かれてきました
  75. これらはきちんと文書化されていますから事前にこれらの標準についてでき
  76. るだけたくさん学んでくださいまた皆があなたやあなたの会社のやり方に合わ
  77. せてくれると思わないでください
  78. 法的問題
  79. ------------
  80. Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
  81. ライセンスの詳細についてはソースツリーのメインディレクトリに存在
  82. するCOPYING のファイルを見てくださいもしライセンスについてさらに質
  83. 問があればLinux Kernel メーリングリストに質問するのではなくどうぞ
  84. 法律家に相談してくださいメーリングリストの人達は法律家ではなく法的
  85. 問題については彼らの声明はあてにするべきではありません
  86. GPL に関する共通の質問や回答については以下を参照してください
  87. http://www.gnu.org/licenses/gpl-faq.html
  88. ドキュメント
  89. ------------
  90. Linux カーネルソースツリーは幅広い範囲のドキュメントを含んでおりそれ
  91. らはカーネルコミュニティと会話する方法を学ぶのに非常に貴重なものです
  92. 新しい機能がカーネルに追加される場合その機能の使い方について説明した
  93. 新しいドキュメントファイルも追加することを勧めます
  94. カーネルの変更がカーネルがユーザ空間に公開しているインターフェイスの
  95. 変更を引き起こす場合その変更を説明するマニュアルページのパッチや情報
  96. をマニュアルページのメンテナ mtk.manpages@gmail.com に送りCC
  97. linux-api@ver.kernel.org に送ることを勧めます
  98. 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
  99. -
  100. README
  101. このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
  102. configure )生成(訳注 build )するために必要なことは何かが書かれ
  103. ていますカーネルに関して初めての人はここからスタートすると良いで
  104. しょう
  105. Documentation/Changes
  106. このファイルはカーネルをうまく生成(訳注 build )走らせるのに最
  107. 小限のレベルで必要な数々のソフトウェアパッケージの一覧を示してい
  108. ます
  109. Documentation/CodingStyle
  110. これは Linux カーネルのコーディングスタイルと背景にある理由を記述
  111. しています全ての新しいコードはこのドキュメントにあるガイドライン
  112. に従っていることを期待されています大部分のメンテナはこれらのルー
  113. ルに従っているものだけを受け付け多くの人は正しいスタイルのコード
  114. だけをレビューします
  115. Documentation/SubmittingPatches
  116. Documentation/SubmittingDrivers
  117. これらのファイルにはどうやってうまくパッチを作って投稿するかに
  118. ついて非常に詳しく書かれており以下を含みます(これだけに限らない
  119. けれども)
  120. - Email に含むこと
  121. - Email の形式
  122. - だれに送るか
  123. これらのルールに従えばうまくいくことを保証することではありません
  124. (すべてのパッチは内容とスタイルについて精査を受けるので)
  125. ルールに従わなければ間違いなくうまくいかないでしょう
  126. この他にパッチを作る方法についてのよくできた記述は-
  127. "The Perfect Patch"
  128. http://userweb.kernel.org/~akpm/stuff/tpp.txt
  129. "Linux kernel patch submission format"
  130. http://linux.yyz.us/patch-format.html
  131. Documentation/stable_api_nonsense.txt
  132. このファイルはカーネルの中に不変のAPIを持たないことにした意識的な
  133. 決断の背景にある理由について書かれています以下のようなことを含
  134. んでいます-
  135. - サブシステムとの間に層を作ること(コンパチビリティのため?)
  136. - オペレーティングシステム間のドライバの移植性
  137. - カーネルソースツリーの素早い変更を遅らせる(もしくは素早い変更
  138. を妨げる)
  139. このドキュメントは Linux 開発の思想を理解するのに非常に重要です
  140. そして他のOSでの開発者が Linux に移る時にとても重要です
  141. Documentation/SecurityBugs
  142. もし Linux カーネルでセキュリティ問題を発見したように思ったら
  143. のドキュメントのステップに従ってカーネル開発者に連絡し問題解決を
  144. 支援してください
  145. Documentation/ManagementStyle
  146. このドキュメントは Linux カーネルのメンテナ達がどう行動するか
  147. 彼らの手法の背景にある共有されている精神について記述しています
  148. れはカーネル開発の初心者ならもしくは単に興味があるだけの人でも
  149. 重要ですなぜならこのドキュメントはカーネルメンテナ達の独特な
  150. 行動についての多くの誤解や混乱を解消するからです
  151. Documentation/stable_kernel_rules.txt
  152. このファイルはどのように stable カーネルのリリースが行われるかのルー
  153. ルが記述されていますそしてこれらのリリースの中のどこかで変更を取
  154. り入れてもらいたい場合に何をすれば良いかが示されています
  155. Documentation/kernel-docs.txt
  156.   カーネル開発に付随する外部ドキュメントのリストですもしあなたが
  157. 探しているものがカーネル内のドキュメントでみつからなかった場合
  158. このリストをあたってみてください
  159. Documentation/applying-patches.txt
  160. パッチとはなにかパッチをどうやって様々なカーネルの開発ブランチに
  161. 適用するのかについて正確に記述した良い入門書です
  162. カーネルはソースコードから自動的に生成可能な多数のドキュメントを自分自
  163. 身でもっていますこれにはカーネル内 API のすべての記述やどう正しく
  164. ロックをかけるかの規則が含まれますこのドキュメントは
  165. Documentation/DocBook/ ディレクトリに作られ以下のように
  166. make pdfdocs
  167. make psdocs
  168. make htmldocs
  169. make mandocs
  170. コマンドを実行するとメインカーネルのソースディレクトリから
  171. それぞれPDF, Postscript, HTML, man page の形式で生成されます
  172. カーネル開発者になるには
  173. ---------------------------
  174. もしあなたがLinux カーネル開発について何も知らないならば
  175. KernelNewbies プロジェクトを見るべきです
  176. http://kernelnewbies.org
  177. このサイトには役に立つメーリングリストがあり基本的なカーネル開発に関
  178. するほとんどどんな種類の質問もできます (既に回答されているようなことを
  179. 聞く前にまずはアーカイブを調べてください)
  180. またここにはリアルタイムで質問を聞くことができる IRC チャネルやLinux
  181. カーネルの開発に関して学ぶのに便利なたくさんの役に立つドキュメントがあ
  182. ります
  183. web サイトにはコードの構成サブシステム現在存在するプロジェクト(
  184. リーにあるもの無いものの両方)の基本的な管理情報があります
  185. ここにはまたカーネルのコンパイルのやり方やパッチの当て方などの間接
  186. 的な基本情報も記述されています
  187. あなたがどこからスタートして良いかわからないがLinux カーネル開発コミュ
  188. ニティに参加して何かすることをさがしている場合にはLinux kernel
  189. Janitor's プロジェクトにいけば良いでしょう -
  190. http://janitor.kernelnewbies.org/
  191. ここはそのようなスタートをするのにうってつけの場所ですここには
  192. Linux カーネルソースツリーの中に含まれるきれいにし修正しなければな
  193. らない単純な問題のリストが記述されていますこのプロジェクトに関わる
  194. 開発者と一緒に作業することであなたのパッチを Linuxカーネルツリーに入
  195. れるための基礎を学ぶことができそしてもしあなたがまだアイディアを持っ
  196. ていない場合には次にやる仕事の方向性が見えてくるかもしれません
  197. もしあなたがすでにひとまとまりコードを書いていてカーネルツリーに入
  198. れたいと思っていたりそれに関する適切な支援を求めたい場合カーネル
  199. メンターズプロジェクトはそのような皆さんを助けるためにできました
  200. ここにはメーリングリストがあり以下から参照できます
  201. http://selenic.com/mailman/listinfo/kernel-mentors
  202. 実際に Linux カーネルのコードについて修正を加える前にどうやってその
  203. コードが動作するのかを理解することが必要ですそのためには特別なツー
  204. ルの助けを借りてでもそれを直接よく読むことが最良の方法です(ほとんど
  205. のトリッキーな部分は十分にコメントしてありますから)そういうツールで
  206. 特におすすめなのはLinux クロスリファレンスプロジェクトですこれは
  207. 自己参照方式で索引がついた web 形式でソースコードを参照することが
  208. できますこの最新の素晴しいカーネルコードのリポジトリは以下で見つかり
  209. ます-
  210. http://sosdg.org/~qiyong/lxr/
  211. 開発プロセス
  212. -----------------------
  213. Linux カーネルの開発プロセスは現在幾つかの異なるメインカーネルブラン
  214. と多数のサブシステム毎のカーネルブランチから構成されます
  215. これらのブランチとは-
  216. - メインの 2.6.x カーネルツリー
  217. - 2.6.x.y -stable カーネルツリー
  218. - 2.6.x -git カーネルパッチ
  219. - 2.6.x -mm カーネルパッチ
  220. - サブシステム毎のカーネルツリーとパッチ
  221. 2.6.x カーネルツリー
  222. -----------------
  223. 2.6.x カーネルは Linus Torvalds によってメンテナンスされkernel.org
  224. pub/linux/kernel/v2.6/ ディレクトリに存在しますこの開発プロセスは
  225. 以下のとおり-
  226. - 新しいカーネルがリリースされた直後に2週間の特別期間が設けられ
  227. この期間中にメンテナ達は Linus に大きな差分を送ることができます
  228. このような差分は通常 -mm カーネルに数週間含まれてきたパッチです
  229. 大きな変更は git(カーネルのソース管理ツール詳細は
  230. http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ
  231. チファイルの形式のまま送るのでも十分です
  232. - 2週間後-rc1 カーネルがリリースされこの後にはカーネル全体の安定
  233. 性に影響をあたえるような新機能は含まない類のパッチしか取り込むこと
  234. はできません新しいドライバ(もしくはファイルシステム)のパッチは
  235. -rc1 の後で受け付けられることもあることを覚えておいてください
  236. ぜなら変更が独立していて追加されたコードの外の領域に影響を与え
  237. ない限り退行のリスクは無いからです-rc1 がリリースされた後
  238. Linus へパッチを送付するのに git を使うこともできますがパッチは
  239. レビューのためにパブリックなメーリングリストへも同時に送る必要が
  240. あります
  241. - 新しい -rc Linus 最新の git ツリーがテスト目的であれば十分
  242. に安定した状態にあると判断したときにリリースされます目標は毎週新
  243. しい -rc カーネルをリリースすることです
  244. - このプロセスはカーネルが 準備ができたと考えられるまで継続しま
  245. このプロセスはだいたい 6週間継続します
  246. - 各リリースでの既知の後戻り問題(regression: このリリースの中で新規
  247. に作り込まれた問題を指す) はその都度 Linux-kernel メーリングリスト
  248. に投稿されますゴールとしてはカーネルが 準備ができたと宣言
  249. する前にこのリストの長さをゼロに減らすことですが現実には数個の
  250. 後戻り問題がリリース時にたびたび残ってしまいます
  251. Andrew Morton Linux-kernel メーリングリストにカーネルリリースについ
  252. て書いたことをここで言っておくことは価値があります-
  253. カーネルがいつリリースされるかは誰も知りませんなぜならこれは現
  254. 実に認識されたバグの状況によりリリースされるのであり前もって決めら
  255. れた計画によってリリースされるものではないからです
  256. 2.6.x.y -stable カーネルツリー
  257. ---------------------------
  258. バージョン番号が4つの数字に分かれているカーネルは -stable カーネルです
  259. これには2.6.x カーネルで見つかったセキュリティ問題や重大な後戻りに対
  260. する比較的小さい重要な修正が含まれます
  261. これは開発/実験的バージョンのテストに協力することに興味が無く
  262. 最新の安定したカーネルを使いたいユーザに推奨するブランチです
  263. もし2.6.x.y カーネルが存在しない場合には番号が一番大きい 2.6.x
  264. 最新の安定版カーネルです
  265. 2.6.x.y "stable" チーム <stable@kernel.org> でメンテされており
  266. 要に応じてリリースされます通常のリリース期間は 2週間毎ですが差し迫っ
  267. た問題がなければもう少し長くなることもありますセキュリティ関連の問題
  268. の場合はこれに対してだいたいの場合すぐにリリースがされます
  269. カーネルツリーに入っているDocumentation/stable_kernel_rules.txt ファ
  270. イルにはどのような種類の変更が -stable ツリーに受け入れ可能かまたリ
  271. リースプロセスがどう動くかが記述されています
  272. 2.6.x -git パッチ
  273. ------------------
  274. git リポジトリで管理されているLinus のカーネルツリーの毎日のスナップ
  275. ショットがあります(だから -git という名前がついています)これらのパッ
  276. チはおおむね毎日リリースされておりLinus のツリーの現状を表します
  277. れは -rc カーネルと比べてパッチが大丈夫かどうかも確認しないで自動的
  278. に生成されるのでより実験的です
  279. 2.6.x -mm カーネルパッチ
  280. ------------------------
  281. Andrew Morton によってリリースされる実験的なカーネルパッチ群です
  282. Andrew は個別のサブシステムカーネルツリーとパッチを全て集めてきて
  283. linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
  284. とめます
  285. このツリーは新機能とパッチが検証される場となりますある期間の間パッチ
  286. -mm に入って価値を証明されたらAndrew やサブシステムメンテナが
  287. メインラインへ入れるように Linus にプッシュします
  288. メインカーネルツリーに含めるために Linus に送る前にすべての新しいパッ
  289. チが -mm ツリーでテストされることが強く推奨されていますマージウィン
  290. ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ
  291. れることは困難になります
  292. これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
  293. りませんしカーネルブランチの中でももっとも動作にリスクが高いものです
  294. もしあなたがカーネル開発プロセスの支援をしたいと思っているのであれば
  295. どうぞこれらのカーネルリリースをテストに使ってみてそしてもし問題があ
  296. ればまたもし全てが正しく動作したとしてもlinux-kernel メーリングリ
  297. ストにフィードバックを提供してください
  298. すべての他の実験的パッチに加えてこれらのカーネルは通常リリース時点で
  299. メインラインの -git カーネルに含まれる全ての変更も含んでいます
  300. -mm カーネルは決まったスケジュールではリリースされませんしかし通常幾
  301. つかの -mm カーネル (1 から 3 が普通が各-rc カーネルの間にリリースさ
  302. れます
  303. サブシステム毎のカーネルツリーとパッチ
  304. -------------------------------------------
  305. カーネルの様々な領域で何が起きているかを見られるようにするため多くの
  306. カーネルサブシステム開発者は彼らの開発ツリーを公開していますこれらの
  307. ツリーは説明したように -mm カーネルリリースに入れ込まれます
  308. 以下はさまざまなカーネルツリーの中のいくつかのリスト-
  309. git ツリー-
  310. - Kbuild の開発ツリーSam Ravnborg <sam@ravnborg.org>
  311. git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
  312. - ACPI の開発ツリー Len Brown <len.brown@intel.com>
  313. git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
  314. - Block の開発ツリーJens Axboe <axboe@suse.de>
  315. git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
  316. - DRM の開発ツリーDave Airlie <airlied@linux.ie>
  317. git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
  318. - ia64 の開発ツリーTony Luck <tony.luck@intel.com>
  319. git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
  320. - infiniband, Roland Dreier <rolandd@cisco.com>
  321. git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
  322. - libata, Jeff Garzik <jgarzik@pobox.com>
  323. git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
  324. - ネットワークドライバ, Jeff Garzik <jgarzik@pobox.com>
  325. git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
  326. - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
  327. git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
  328. - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
  329. git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
  330. - x86, Ingo Molnar <mingo@elte.hu>
  331. git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
  332. quilt ツリー-
  333. - USB, ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
  334. kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
  335. その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
  336. イルに一覧表があります
  337. バグレポート
  338. -------------
  339. bugzilla.kernel.org Linux カーネル開発者がカーネルのバグを追跡する
  340. 場所ですユーザは見つけたバグの全てをこのツールで報告すべきです
  341. どう kernel bugzilla を使うかの詳細は以下を参照してください-
  342. http://bugzilla.kernel.org/page.cgi?id=faq.html
  343. メインカーネルソースディレクトリにあるファイル REPORTING-BUGS はカーネ
  344. ルバグらしいものについてどうレポートするかの良いテンプレートであり
  345. 題の追跡を助けるためにカーネル開発者にとってどんな情報が必要なのかの詳
  346. 細が書かれています
  347. バグレポートの管理
  348. -------------------
  349. あなたのハッキングのスキルを訓練する最高の方法のひとつに他人がレポー
  350. トしたバグを修正することがありますあなたがカーネルをより安定化させる
  351. こに寄与するということだけでなくあなたは 現実の問題を修正することを
  352. 学び自分のスキルも強化できまた他の開発者があなたの存在に気がつき
  353. ますバグを修正することは多くの開発者の中から自分が功績をあげる最善
  354. の道ですなぜなら多くの人は他人のバグの修正に時間を浪費することを好ま
  355. ないからです
  356. すでにレポートされたバグのために仕事をするためには
  357. http://bugzilla.kernel.org に行ってください。もし今後のバグレポートに
  358. ついてアドバイスを受けたいのであればbugme-new メーリングリスト(新し
  359. いバグレポートだけがここにメールされる) または bugme-janitor メーリン
  360. グリスト(bugzilla の変更毎にここにメールされる)を購読できます
  361. http://lists.linux-foundation.org/mailman/listinfo/bugme-new
  362. http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
  363. メーリングリスト
  364. -------------
  365. 上のいくつかのドキュメントで述べていますがコアカーネル開発者の大部分
  366. Linux kernel メーリングリストに参加していますこのリストの登録/
  367. 退の方法については以下を参照してください-
  368. http://vger.kernel.org/vger-lists.html#linux-kernel
  369. このメーリングリストのアーカイブは web 上の多数の場所に存在します
  370. れらのアーカイブを探すにはサーチエンジンを使いましょう例えば-
  371. http://dir.gmane.org/gmane.linux.kernel
  372. リストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索
  373. することを是非やってください多数の事がすでに詳細に渡って議論されて
  374. おりアーカイブにのみ記録されています
  375. 大部分のカーネルサブシステムも自分の個別の開発を実施するメーリングリス
  376. トを持っています個々のグループがどんなリストを持っているかは
  377. MAINTAINERS ファイルにリストがありますので参照してください
  378. 多くのリストは kernel.org でホストされていますこれらの情報は以下にあ
  379. ります-
  380. http://vger.kernel.org/vger-lists.html
  381. メーリングリストを使う場合良い行動習慣に従うようにしましょう
  382. 少し安っぽいが以下の URL は上のリスト(や他のリスト)で会話する場合の
  383. シンプルなガイドラインを示しています-
  384. http://www.albion.com/netiquette/
  385. もし複数の人があなたのメールに返事をした場合CC: で受ける人のリストは
  386. だいぶ多くなるでしょう良い理由がない場合CC: リストから誰かを削除を
  387. しないようにまたメーリングリストのアドレスだけにリプライすることの
  388. ないようにしましょう1つは送信者からもう1つはリストからのようにメー
  389. ルを2回受けることになってもそれに慣れしゃれたメールヘッダーを追加し
  390. てこの状態を変えようとしないように人々はそのようなことは好みません
  391. 今までのメールでのやりとりとその間のあなたの発言はそのまま残し
  392. "John Kernlehacker wrote ...:" の行をあなたのリプライの先頭行にして
  393. メールの先頭でなく各引用行の間にあなたの言いたいことを追加するべきで
  394. もしパッチをメールに付ける場合はDocumentaion/SubmittingPatches に提
  395. 示されているようにそれは プレーンな可読テキストにすることを忘れない
  396. ようにしましょうカーネル開発者は 添付や圧縮したパッチを扱いたがりま
  397. せん-
  398. 彼らはあなたのパッチの行毎にコメントを入れたいのでそのためにはそうす
  399. るしかありませんあなたのメールプログラムが空白やタブを圧縮しないよう
  400. に確認した方が良いです最初の良いテストとしては自分にメールを送って
  401. みてそのパッチを自分で当ててみることですもしそれがうまく行かないな
  402. あなたのメールプログラムを直してもらうか正しく動くように変えるべ
  403. きです
  404. とりわけ他の登録者に対する尊敬を表すようにすることを覚えておいてくだ
  405. さい
  406. コミュニティと共に働くこと
  407. --------------------------
  408. カーネルコミュニティのゴールは可能なかぎり最高のカーネルを提供すること
  409. ですあなたがパッチを受け入れてもらうために投稿した場合それは技術
  410. 的メリットだけがレビューされますその際あなたは何を予想すべきでしょ
  411. うか?
  412. - 批判
  413. - コメント
  414. - 変更の要求
  415. - パッチの正当性の証明要求
  416. - 沈黙
  417. 思い出してくださいここはあなたのパッチをカーネルに入れる話です
  418. なたはあなたのパッチに対する批判とコメントを受け入れるべきでそれら
  419. を技術的レベルで評価してパッチを再作成するかなぜそれらの変更をすべ
  420. きでないかを明確で簡潔な理由の説明を提供してください
  421. もしあなたのパッチに何も反応がない場合たまにはメールの山に埋もれて
  422. 見逃されあなたの投稿が忘れられてしまうこともあるので数日待って再度
  423. 投稿してください
  424. あなたがやるべきでないものは?
  425. - 質問なしにあなたのパッチが受け入れられると想像すること
  426. - 守りに入ること
  427. - コメントを無視すること
  428. - 要求された変更を何もしないでパッチを出し直すこと
  429. 可能な限り最高の技術的解決を求めているコミュニティではパッチがどのく
  430. らい有益なのかについては常に異なる意見がありますあなたは協調的である
  431. べきですしまたあなたのアイディアをカーネルに対してうまく合わせるよ
  432. うにすることが望まれていますもしくは最低限あなたのアイディアがそれ
  433. だけの価値があるとすすんで証明するようにしなければなりません
  434. 正しい解決に向かって進もうという意志がある限り間違うことがあっても許
  435. 容されることを忘れないでください
  436. あなたの最初のパッチに単に 1ダースもの修正を求めるリストの返答になるこ
  437. とも普通のことですこれはあなたのパッチが受け入れられないということで
  438. *ありません*そしてあなた自身に反対することを意味するのでも *ありま
  439. せん*単に自分のパッチに対して指摘された問題を全て修正して再送すれば
  440. 良いのです
  441. カーネルコミュニティと企業組織のちがい
  442. -----------------------------------------------------------------
  443. カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
  444. 動いています以下は問題を避けるためにできると良いことのリストです-
  445. あなたの提案する変更について言うときのうまい言い方
  446. - "これは複数の問題を解決します"
  447. - "これは2000行のコードを削除します"
  448. - "以下のパッチは、私が言おうとしていることを説明するものです"
  449. - "私はこれを5つの異なるアーキテクチャでテストしたのですが..."
  450. - "以下は一連の小さなパッチ群ですが..."
  451. - "これは典型的なマシンでの性能を向上させます.."
  452. やめた方が良い悪い言い方
  453. - このやり方で AIX/ptx/Solaris ではできたのでできるはずだ
  454. - 私はこれを20年もの間やってきただから
  455. - これは私の会社が金儲けをするために必要だ
  456. - これは我々のエンタープライズ向け商品ラインのためである
  457. - これは 私が自分のアイディアを記述した1000ページの設計資料である
  458. - 私はこれについて6ケ月作業している
  459. - 以下は ... に関する5000行のパッチです
  460. - 私は現在のぐちゃぐちゃを全部書き直したそれが以下です...
  461. - 私は〆切があるそのためこのパッチは今すぐ適用される必要がある
  462. カーネルコミュニティが大部分の伝統的なソフトウェアエンジニアリングの労
  463. 働環境と異なるもう一つの点はやりとりに顔を合わせないということです
  464. email irc を第一のコミュニケーションの形とする一つの利点は性別や
  465. 民族の差別がないことですLinux カーネルの職場環境は女性や少数民族を受
  466. 容しますなぜならemail アドレスによってのみあなたが認識されるからで
  467. 国際的な側面からも活動領域を均等にするようにしますなぜならばあなた
  468. は人の名前で性別を想像できないからですある男性が アンドレアという名
  469. 前で女性の名前は パット かもしれません (訳注 Andrea は米国では女性
  470. それ以外(欧州など)では男性名として使われることが多い同様にPat
  471. Patricia (主に女性名) Patrick (主に男性名)の略称)
  472. Linux カーネルの活動をして意見を表明したことがある大部分の女性は
  473. 向きな経験をもっています
  474. 言葉の壁は英語が得意でない一部の人には問題になります
  475. メーリングリストの中できちんとアイディアを交換するには相当うまく英語
  476. を操れる必要があることもありますそのためあなたは自分のメール
  477. を送る前に英語で意味が通じているかをチェックすることをお薦めします
  478. 変更を分割する
  479. ---------------------
  480. Linux カーネルコミュニティは一度に大量のコードの塊を喜んで受容するこ
  481. とはありません変更は正確に説明される必要があり議論され小さい
  482. 別の部分に分割する必要がありますこれはこれまで多くの会社がやり慣れて
  483. きたことと全く正反対のことですあなたのプロポーザルは開発プロセスのと
  484. ても早い段階から紹介されるべきですそうすれば あなたは自分のやってい
  485. ることにフィードバックを得られますこれはコミュニティからみれば
  486. なたが彼らと一緒にやっているように感じられ単にあなたの提案する機能の
  487. ゴミ捨て場として使っているのではないと感じられるでしょう
  488. しかし一度に 50 もの email をメーリングリストに送りつけるようなことは
  489. やってはいけませんあなたのパッチ群はいつもどんな時でもそれよりは小さ
  490. くなければなりません
  491. パッチを分割する理由は以下です-
  492. 1) 小さいパッチはあなたのパッチが適用される見込みを大きくしますカー
  493. ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
  494. らです5行のパッチはメンテナがたった1秒見るだけで適用できます
  495. しかし500行のパッチは正しいことをレビューするのに数時間かかるか
  496. もしれません(時間はパッチのサイズなどにより指数関数に比例してかかり
  497. ます)
  498. 小さいパッチは何かあったときにデバッグもとても簡単になりますパッ
  499. チを1個1個取り除くのはとても大きなパッチを当てた後に(かつ何かお
  500. かしくなった後で)解剖するのに比べればとても簡単です
  501. 2) 小さいパッチを送るだけでなく送るまえに書き直してシンプルにす
  502. (もしくは単に順番を変えるだけでも)こともとても重要です
  503. 以下はカーネル開発者の Al Viro のたとえ話です
  504. "生徒の数学の宿題を採点する先生のことを考えてみてください、先
  505. 生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでしょ
  506. 先生は簡潔な最高の解を見たいのです良い生徒はこれを知って
  507. おりそして最終解の前の中間作業を提出することは決してないので
  508. "
  509. カーネル開発でもこれは同じですメンテナ達とレビューア達は
  510. 問題を解決する解の背後になる思考プロセスを見たいとは思いません
  511. 彼らは単純であざやかな解決方法を見たいのです
  512. あざやかな解を説明するのとコミュニティと共に仕事をし未解決の仕事を
  513. 議論することのバランスをキープするのは難しいかもしれません
  514. ですから開発プロセスの早期段階で改善のためのフィードバックをもらうよ
  515. うにするのも良いですが変更点を小さい部分に分割して全体ではまだ完成し
  516. ていない仕事を(部分的に)取り込んでもらえるようにすることも良いことです
  517. またでき上がっていないものや"将来直す" ようなパッチを本流に含め
  518. てもらうように送ってもそれは受け付けられないことを理解してください
  519. あなたの変更を正当化する
  520. -------------------
  521. あなたのパッチを分割するのと同時になぜその変更を追加しなければならな
  522. いかを Linux コミュニティに知らせることはとても重要です新機能は必要
  523. 性と有用性で正当化されなければなりません
  524. あなたの変更の説明
  525. --------------------
  526. あなたのパッチを送付する場合にはメールの中のテキストで何を言うかにつ
  527. いて特別に注意を払ってくださいこの情報はパッチの ChangeLog に使わ
  528. いつも皆がみられるように保管されますこれは次のような項目を含め
  529. パッチを完全に記述するべきです-
  530. - なぜ変更が必要か
  531. - パッチ全体の設計アプローチ
  532. - 実装の詳細
  533. - テスト結果
  534. これについて全てがどのようにあるべきかについての詳細は以下のドキュメ
  535. ントの ChangeLog セクションを見てください-
  536. "The Perfect Patch"
  537. http://userweb.kernel.org/~akpm/stuff/tpp.txt
  538. これらのどれもが時にはとても困難ですこれらの慣例を完璧に実施するに
  539. は数年かかるかもしれませんこれは継続的な改善のプロセスでありそのた
  540. めには多数の忍耐と決意を必要とするものですでも諦めないでこれは可
  541. 能なことです多数の人がすでにできていますし彼らも皆最初はあなたと同
  542. じところからスタートしたのですから
  543. Paolo Ciarrocchi に感謝彼は彼の書いた "Development Process"
  544. (http://linux.tar.bz/articles/2.6-development_process)セクショ
  545. ンをこのテキストの原型にすることを許可してくれました
  546. Rundy Dunlap Gerrit Huizenga はメーリングリストでやるべきこととやっ
  547. てはいけないことのリストを提供してくれました
  548. 以下の人々のレビューコメント貢献に感謝
  549. Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
  550. Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
  551. Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
  552. David A. Wheeler, Junio Hamano, Michael Kerrisk, Alex Shepard
  553. 彼らの支援なしではこのドキュメントはできなかったでしょう
  554. Maintainer: Greg Kroah-Hartman <greg@kroah.com>