About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / ja_JP / HOWTO

Based on kernel version 2.6.30. Page generated on 2009-06-11 10:12 EST.

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

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.