About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / ja_JP / HOWTO

Based on kernel version 2.6.26. Page generated on 2008-07-16 21:13 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: 2007/11/16
15	==================================
16	これは、
17	linux-2.6.24/Documentation/HOWTO
18	の和訳です。
19	
20	翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
21	翻訳日： 2007/11/10
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	 -『プログラミング言語Ｃ第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 に送ることを勧めま
114	す。
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://www.zip.com.au/~akpm/linux/patches/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	   - 以下の URL で各 -rc リリースに存在する既知の後戻り問題のリスト
291	     が追跡されます-
292	     http://kernelnewbies.org/known_regressions
293	
294	  - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
295	    す。このプロセスはだいたい 6週間継続します。
296	
297	Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ
298	て書いたことをここで言っておくことは価値があります-
299	  「カーネルがいつリリースされるかは誰も知りません。なぜなら、これは現
300	  実に認識されたバグの状況によりリリースされるのであり、前もって決めら
301	  れた計画によってリリースされるものではないからです。」
302	
303	2.6.x.y -stable カーネルツリー
304	---------------------------
305	
306	バージョンに4つ目の数字がついたカーネルは -stable カーネルです。これに
307	は、2.6.x カーネルで見つかったセキュリティ問題や重大な後戻りに対する比
308	較的小さい重要な修正が含まれます。
309	
310	これは、開発/実験的バージョンのテストに協力することに興味が無く、
311	最新の安定したカーネルを使いたいユーザに推奨するブランチです。
312	
313	もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x
314	が最新の安定版カーネルです。
315	
316	2.6.x.y は "stable" チーム <stable[AT]kernel[DOT]org> でメンテされており、だ
317	いたい隔週でリリースされています。
318	
319	カーネルツリーに入っている、Documentation/stable_kernel_rules.txt ファ
320	イルにはどのような種類の変更が -stable ツリーに受け入れ可能か、またリ
321	リースプロセスがどう動くかが記述されています。
322	
323	2.6.x -git パッチ
324	------------------
325	
326	git リポジトリで管理されているLinus のカーネルツリーの毎日のスナップ
327	ショットがあります。(だから -git という名前がついています)。これらのパッ
328	チはおおむね毎日リリースされており、Linus のツリーの現状を表します。こ
329	れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的
330	に生成されるので、より実験的です。
331	
332	2.6.x -mm カーネルパッチ
333	------------------------
334	
335	Andrew Morton によってリリースされる実験的なカーネルパッチ群です。
336	Andrew は個別のサブシステムカーネルツリーとパッチを全て集めてきて
337	linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
338	とめます。
339	このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
340	が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
341	メインラインへ入れるように Linus にプッシュします。
342	
343	メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
344	チが -mm ツリーでテストされることが強く推奨されます。
345	
346	これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
347	りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。
348	
349	もしあなたが、カーネル開発プロセスの支援をしたいと思っているのであれば、
350	どうぞこれらのカーネルリリースをテストに使ってみて、そしてもし問題があ
351	れば、またもし全てが正しく動作したとしても、linux-kernel メーリングリ
352	ストにフィードバックを提供してください。
353	
354	すべての他の実験的パッチに加えて、これらのカーネルは通常リリース時点で
355	メインラインの -git カーネルに含まれる全ての変更も含んでいます。
356	
357	-mm カーネルは決まったスケジュールではリリースされません、しかし通常幾
358	つかの -mm カーネル (1 から 3 が普通）が各-rc カーネルの間にリリースさ
359	れます。
360	
361	サブシステム毎のカーネルツリーとパッチ
362	-------------------------------------------
363	
364	カーネルの様々な領域で何が起きているかを見られるようにするため、多くの
365	カーネルサブシステム開発者は彼らの開発ツリーを公開しています。これらの
366	ツリーは説明したように -mm カーネルリリースに入れ込まれます。
367	
368	以下はさまざまなカーネルツリーの中のいくつかのリスト-
369	
370	  git ツリー-
371	    - Kbuild の開発ツリー、Sam Ravnborg <sam[AT]ravnborg[DOT]org>
372		git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
373	
374	    - ACPI の開発ツリー、 Len Brown <len.brown[AT]intel[DOT]com>
375		git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
376	
377	    - Block の開発ツリー、Jens Axboe <axboe[AT]suse[DOT]de>
378		git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
379	
380	    - DRM の開発ツリー、Dave Airlie <airlied[AT]linux[DOT]ie>
381		git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
382	
383	    - ia64 の開発ツリー、Tony Luck <tony.luck[AT]intel[DOT]com>
384		git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
385	
386	    - infiniband, Roland Dreier <rolandd[AT]cisco[DOT]com>
387		git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
388	
389	    - libata, Jeff Garzik <jgarzik[AT]pobox[DOT]com>
390		git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
391	
392	    - ネットワークドライバ, Jeff Garzik <jgarzik[AT]pobox[DOT]com>
393		git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
394	
395	    - pcmcia, Dominik Brodowski <linux[AT]dominikbrodowski[DOT]net>
396		git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
397	
398	    - SCSI, James Bottomley <James.Bottomley[AT]SteelEye[DOT]com>
399		git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
400	
401	  quilt ツリー-
402	    - USB, PCI ドライバコアと I2C, Greg Kroah-Hartman <gregkh[AT]suse[DOT]de>
403		kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
404	    - x86-64 と i386 の仲間 Andi Kleen <ak[AT]suse[DOT]de>
405	
406	  その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
407	  イルに一覧表があります。
408	
409	バグレポート
410	-------------
411	
412	bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する
413	場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。
414	どう kernel bugzilla を使うかの詳細は、以下を参照してください-
415		http://test.kernel.org/bugzilla/faq.html
416	
417	メインカーネルソースディレクトリにあるファイル REPORTING-BUGS はカーネ
418	ルバグらしいものについてどうレポートするかの良いテンプレートであり、問
419	題の追跡を助けるためにカーネル開発者にとってどんな情報が必要なのかの詳
420	細が書かれています。
421	
422	メーリングリスト
423	-------------
424	
425	上のいくつかのドキュメントで述べていますが、コアカーネル開発者の大部分
426	は Linux kernel メーリングリストに参加しています。このリストの登録/脱
427	退の方法については以下を参照してください-
428		http://vger.kernel.org/vger-lists.html#linux-kernel
429	
430	このメーリングリストのアーカイブは web 上の多数の場所に存在します。こ
431	れらのアーカイブを探すにはサーチエンジンを使いましょう。例えば-
432		http://dir.gmane.org/gmane.linux.kernel
433	
434	リストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索
435	することを是非やってください。多数の事がすでに詳細に渡って議論されて
436	おり、アーカイブにのみ記録されています。
437	
438	大部分のカーネルサブシステムも自分の個別の開発を実施するメーリングリス
439	トを持っています。個々のグループがどんなリストを持っているかは、
440	MAINTAINERS ファイルにリストがありますので参照してください。
441	
442	多くのリストは kernel.org でホストされています。これらの情報は以下にあ
443	ります-
444		http://vger.kernel.org/vger-lists.html
445	
446	メーリングリストを使う場合、良い行動習慣に従うようにしましょう。
447	少し安っぽいが、以下の URL は上のリスト(や他のリスト)で会話する場合の
448	シンプルなガイドラインを示しています-
449		http://www.albion.com/netiquette/
450	
451	もし複数の人があなたのメールに返事をした場合、CC: で受ける人のリストは
452	だいぶ多くなるでしょう。良い理由がない場合、CC: リストから誰かを削除を
453	しないように、また、メーリングリストのアドレスだけにリプライすることの
454	ないようにしましょう。1つは送信者から、もう1つはリストからのように、メー
455	ルを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追加し
456	てこの状態を変えようとしないように。人々はそのようなことは好みません。
457	
458	今までのメールでのやりとりとその間のあなたの発言はそのまま残し、
459	"John Kernlehacker wrote ...:" の行をあなたのリプライの先頭行にして、
460	メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
461	す。
462	
463	もしパッチをメールに付ける場合は、Documentaion/SubmittingPatches に提
464	示されているように、そ&atild