-\feffNOTE:
+NOTE:
This is a version of Documentation/HOWTO translated into Japanese.
This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
and the JF Project team <www.linux.or.jp/JF>.
fork. So if you have any comments or updates for this file, please try
to update the original English file first.
-Last Updated: 2007/07/18
+Last Updated: 2008/10/24
==================================
これは、
-linux-2.6.22/Documentation/HOWTO
+linux-2.6.28/Documentation/HOWTO
の和訳です。
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
-翻訳日： 2007/07/16
+翻訳日： 2008/10/24
翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
校正者： 松倉さん <nbh--mats at nifty dot com>
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
+ 内田さん (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
==================================
Linux カーネル開発のやり方
手助けになります。
もし、このドキュメントのどこかが古くなっていた場合には、このドキュメン
-ã\83\88ã\81®æ\9c\80å¾\8cã\81«ã\83ªã\82¹ã\83\88ã\81\97ã\81\9fã\83¡ã\83³ã\83\86ã\83\8aã\83¼ã\81«ã\83\91ã\83\83ã\83\81ã\82\92é\80\81ã\81£ã\81¦ã\81\8fã\81 ã\81\95ã\81\84ã\80\82
+トの最後にリストしたメンテナにパッチを送ってください。
はじめに
---------
ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの
でなければ、(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要あり
ません。以下の本は、C 言語の十分な知識や何年もの経験に取って代わるもの
-ではありませんが、少なくともリファレンスとしてはいい本です。
+ではありませんが、少なくともリファレンスとしては良い本です。
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
-『プログラミング言語Ｃ第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
- "Practical C Programming" by Steve Oualline [O'Reilly]
ときどき、カーネルがツールチェインや C 言語拡張に置いている前提がどう
なっているのかわかりにくいことがあり、また、残念なことに決定的なリファ
レンスは存在しません。情報を得るには、gcc の info ページ( info gcc )を
-みてください。
+見てください。
あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
とに留意してください。そのコミュニティは、コーディング、スタイル、
Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
す。ライセンスの詳細については、ソースツリーのメインディレクトリに存在
-する、COPYING のファイルをみてください。もしライセンスについてさらに質
+する、COPYING のファイルを見てください。もしライセンスについてさらに質
問があれば、Linux Kernel メーリングリストに質問するのではなく、どうぞ
法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
問題については彼らの声明はあてにするべきではありません。
新しいドキュメントファイルも追加することを勧めます。
カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
-をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めます。
+をマニュアルページのメンテナ mtk.manpages@gmail.com に送り、CC を
+linux-api@ver.kernel.org に送ることを勧めます。
以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
す-
README
このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
configure )し、生成(訳注 build )するために必要なことは何かが書かれ
- ています。カーネルに関して初めての人はここからスタートするとよいで
+ ています。カーネルに関して初めての人はここからスタートすると良いで
しょう。
Documentation/Changes
Documentation/CodingStyle
これは Linux カーネルのコーディングスタイルと背景にある理由を記述
しています。全ての新しいコードはこのドキュメントにあるガイドライン
- ã\81«å¾\93ã\81£ã\81¦ã\81\84ã\82\8bã\81\93ã\81¨ã\82\92æ\9c\9få¾\85ã\81\95ã\82\8cã\81¦ã\81\84ã\81¾ã\81\99ã\80\82大é\83¨å\88\86ã\81®ã\83¡ã\83³ã\83\86ã\83\8aã\83¼ã\81¯ã\81\93ã\82\8cã\82\89ã\81®ã\83«ã\83¼
+ に従っていることを期待されています。大部分のメンテナはこれらのルー
ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
だけをレビューします。
この他にパッチを作る方法についてのよくできた記述は-
"The Perfect Patch"
- http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
+ http://userweb.kernel.org/~akpm/stuff/tpp.txt
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html
支援してください。
Documentation/ManagementStyle
- このドキュメントは Linux カーネルのメンテナー達がどう行動するか、
+ このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
彼らの手法の背景にある共有されている精神について記述しています。こ
れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）
- 重要です。なぜならこのドキュメントは、カーネルメンテナー達の独特な
+ 重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
行動についての多くの誤解や混乱を解消するからです。
Documentation/stable_kernel_rules.txt
このファイルはどのように stable カーネルのリリースが行われるかのルー
ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
- り入れてもらいたい場合に何をすればいいかが示されています。
+ り入れてもらいたい場合に何をすれば良いかが示されています。
Documentation/kernel-docs.txt
カーネル開発に付随する外部ドキュメントのリストです。もしあなたが
ここには、また、カーネルのコンパイルのやり方やパッチの当て方などの間接
的な基本情報も記述されています。
-あなたがどこからスタートしてよいかわからないが、Linux カーネル開発コミュ
+あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
ニティに参加して何かすることをさがしている場合には、Linux kernel
-Janitor's プロジェクトにいけばよいでしょう -
+Janitor's プロジェクトにいけば良いでしょう -
http://janitor.kernelnewbies.org/
ここはそのようなスタートをするのにうってつけの場所です。ここには、
Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
ます-
- http://sosdg.org/~coywolf/lxr/
+ http://sosdg.org/~qiyong/lxr/
開発プロセス
-----------------------
以下のとおり-
- 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
- この期間中に、メンテナー達は Linus に大きな差分を送ることができま
- ã\81\99ã\80\82ã\81\93ã\81®ã\82\88ã\81\86ã\81ªå·®å\88\86ã\81¯é\80\9a常 -mm ã\82«ã\83¼ã\83\8dã\83«ã\81«æ\95°é\80±é\96\93å\90«ã\81¾ã\82\8cã\81¦ã\81\8dã\81\9fã\83\91ã\83\83ã\83\81ã\81§
- す。 大きな変更は git(カーネルのソース管理ツール、詳細は
+ この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
+ ã\81\93ã\81®ã\82\88ã\81\86ã\81ªå·®å\88\86ã\81¯é\80\9a常 -mm ã\82«ã\83¼ã\83\8dã\83«ã\81«æ\95°é\80±é\96\93å\90«ã\81¾ã\82\8cã\81¦ã\81\8dã\81\9fã\83\91ã\83\83ã\83\81ã\81§ã\81\99ã\80\82
+ 大きな変更は git(カーネルのソース管理ツール、詳細は
http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ
チファイルの形式のまま送るのでも十分です。
- このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
す。このプロセスはだいたい 6週間継続します。
+ - 各リリースでの既知の後戻り問題(regression: このリリースの中で新規
+ に作り込まれた問題を指す) はその都度 Linux-kernel メーリングリスト
+ に投稿されます。ゴールとしては、カーネルが 「準備ができた」と宣言
+ する前にこのリストの長さをゼロに減らすことですが、現実には、数個の
+ 後戻り問題がリリース時にたびたび残ってしまいます。
+
Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ
て書いたことをここで言っておくことは価値があります-
「カーネルがいつリリースされるかは誰も知りません。なぜなら、これは現
2.6.x.y -stable カーネルツリー
---------------------------
-バージョンに4つ目の数字がついたカーネルは -stable カーネルです。これに
-ã\81¯ã\80\812.6.x ã\82«ã\83¼ã\83\8dã\83«ã\81§è¦\8bã\81¤ã\81\8bã\81£ã\81\9fã\82»ã\82\adã\83¥ã\83ªã\83\86ã\82£å\95\8fé¡\8cã\82\84é\87\8d大ã\81ªå¾\8cæ\88»ã\82\8aã\81«å¯¾ã\81\99ã\82\8bæ¯\94
-較的小さい重要な修正が含まれます。
+バージョン番号が4つの数字に分かれているカーネルは -stable カーネルです。
+ã\81\93ã\82\8cã\81«ã\81¯ã\80\812.6.x ã\82«ã\83¼ã\83\8dã\83«ã\81§è¦\8bã\81¤ã\81\8bã\81£ã\81\9fã\82»ã\82\adã\83¥ã\83ªã\83\86ã\82£å\95\8fé¡\8cã\82\84é\87\8d大ã\81ªå¾\8cæ\88»ã\82\8aã\81«å¯¾
+する比較的小さい重要な修正が含まれます。
これは、開発/実験的バージョンのテストに協力することに興味が無く、
最新の安定したカーネルを使いたいユーザに推奨するブランチです。
-もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x
-が最新の安定版カーネルです。
+もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x が
+最新の安定版カーネルです。
-2.6.x.y は "stable" チーム <stable@kernel.org> でメンテされており、だ
-いたい隔週でリリースされています。
+2.6.x.y は "stable" チーム <stable@kernel.org> でメンテされており、必
+要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ
+た問題がなければもう少し長くなることもあります。セキュリティ関連の問題
+の場合はこれに対してだいたいの場合、すぐにリリースがされます。
カーネルツリーに入っている、Documentation/stable_kernel_rules.txt ファ
イルにはどのような種類の変更が -stable ツリーに受け入れ可能か、またリ
linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
とめます。
このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
-が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、メ
-インラインへ入れるように Linus にプッシュします。
+が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
+ã\83¡ã\82¤ã\83³ã\83©ã\82¤ã\83³ã\81¸å\85¥ã\82\8cã\82\8bã\82\88ã\81\86ã\81« Linus ã\81«ã\83\97ã\83\83ã\82·ã\83¥ã\81\97ã\81¾ã\81\99ã\80\82
メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
-チが -mm ツリーでテストされることが強く推奨されます。
+チが -mm ツリーでテストされることが強く推奨されています。マージウィン
+ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ
+れることは困難になります。
これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- - SCSI, James Bottomley <James.Bottomley@SteelEye.com>
+ - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
+ - x86, Ingo Molnar <mingo@elte.hu>
+ git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
+
quilt ツリー-
- - USB, PCI ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
+ - USB, ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- - x86-64 と i386 の仲間 Andi Kleen <ak@suse.de>
その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
イルに一覧表があります。
bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する
場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。
どう kernel bugzilla を使うかの詳細は、以下を参照してください-
- http://test.kernel.org/bugzilla/faq.html
-
+ http://bugzilla.kernel.org/page.cgi?id=faq.html
メインカーネルソースディレクトリにあるファイル REPORTING-BUGS はカーネ
ルバグらしいものについてどうレポートするかの良いテンプレートであり、問
題の追跡を助けるためにカーネル開発者にとってどんな情報が必要なのかの詳
細が書かれています。
+バグレポートの管理
+-------------------
+
+あなたのハッキングのスキルを訓練する最高の方法のひとつに、他人がレポー
+トしたバグを修正することがあります。あなたがカーネルをより安定化させる
+こに寄与するということだけでなく、あなたは 現実の問題を修正することを
+学び、自分のスキルも強化でき、また他の開発者があなたの存在に気がつき
+ます。バグを修正することは、多くの開発者の中から自分が功績をあげる最善
+の道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好ま
+ないからです。
+
+すでにレポートされたバグのために仕事をするためには、
+http://bugzilla.kernel.org に行ってください。もし今後のバグレポートに
+ついてアドバイスを受けたいのであれば、bugme-new メーリングリスト(新し
+いバグレポートだけがここにメールされる) または bugme-janitor メーリン
+グリスト(bugzilla の変更毎にここにメールされる)を購読できます。
+
+ http://lists.linux-foundation.org/mailman/listinfo/bugme-new
+ http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
+
メーリングリスト
-------------
せん-
彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうす
るしかありません。あなたのメールプログラムが空白やタブを圧縮しないよう
-に確認した方がいいです。最初の良いテストとしては、自分にメールを送って
+に確認した方が良いです。最初の良いテストとしては、自分にメールを送って
みて、そのパッチを自分で当ててみることです。もしそれがうまく行かないな
ら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべ
きです。
とも普通のことです。これはあなたのパッチが受け入れられないということで
は *ありません*、そしてあなた自身に反対することを意味するのでも *ありま
せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば
-いいのです。
+良いのです。
カーネルコミュニティと企業組織のちがい
-----------------------------------------------------------------
カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
-動いています。以下は問題を避けるためにできるとよいことののリストです-
+動いています。以下は問題を避けるためにできると良いことのリストです-
あなたの提案する変更について言うときのうまい言い方：
- "以下は一連の小さなパッチ群ですが..."
- "これは典型的なマシンでの性能を向上させます.."
- やめた方がいい悪い言い方：
+ やめた方が良い悪い言い方：
- このやり方で AIX/ptx/Solaris ではできたので、できるはずだ
- 私はこれを20年もの間やってきた、だから
1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
- らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。し
- ã\81\8bã\81\97ã\80\81500è¡\8cã\81®ã\83\91ã\83\83ã\83\81ã\81¯ã\80\81æ\ad£ã\81\97ã\81\84ã\81\93ã\81¨ã\82\92ã\83¬ã\83\93ã\83¥ã\83¼ã\81\99ã\82\8bã\81®ã\81«æ\95°æ\99\82é\96\93ã\81\8bã\81\8bã\82\8bã\81\8bã\82\82
- ã\81\97ã\82\8cã\81¾ã\81\9bã\82\93(æ\99\82é\96\93ã\81¯ã\83\91ã\83\83ã\83\81ã\81®ã\82µã\82¤ã\82ºã\81ªã\81©ã\81«ã\82\88ã\82\8aæ\8c\87æ\95°é\96¢æ\95°ã\81«æ¯\94ä¾\8bã\81\97ã\81¦ã\81\8bã\81\8bã\82\8aã\81¾
- す)
+ らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
+ ã\81\97ã\81\8bã\81\97ã\80\81500è¡\8cã\81®ã\83\91ã\83\83ã\83\81ã\81¯ã\80\81æ\ad£ã\81\97ã\81\84ã\81\93ã\81¨ã\82\92ã\83¬ã\83\93ã\83¥ã\83¼ã\81\99ã\82\8bã\81®ã\81«æ\95°æ\99\82é\96\93ã\81\8bã\81\8bã\82\8bã\81\8b
+ ã\82\82ã\81\97ã\82\8cã\81¾ã\81\9bã\82\93(æ\99\82é\96\93ã\81¯ã\83\91ã\83\83ã\83\81ã\81®ã\82µã\82¤ã\82ºã\81ªã\81©ã\81«ã\82\88ã\82\8aæ\8c\87æ\95°é\96¢æ\95°ã\81«æ¯\94ä¾\8bã\81\97ã\81¦ã\81\8bã\81\8bã\82\8a
+ ã\81¾ã\81\99)
小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。
-以ä¸\8bã\81¯ã\82«ã\83¼ã\83\8dã\83«é\96\8bç\99ºè\80\85ã\81® Al Viro ã\81®ã\81\9fã\81¨ã\81\88話ã\81\97ã\81§ã\81\99ï¼\9a
+以下はカーネル開発者の Al Viro のたとえ話です：
"生徒の数学の宿題を採点する先生のことを考えてみてください、先
- 生は生徒が解に到達するまでの試行錯誤をみたいとは思わないでしょ
- う。先生は簡潔な最高の解をみたいのです。良い生徒はこれを知って
+ 生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでしょ
+ う。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知って
おり、そして最終解の前の中間作業を提出することは決してないので
す"
- カーネル開発でもこれは同じです。メンテナー達とレビューア達は、
- 問題を解決する解の背後になる思考プロセスをみたいとは思いません。
- 彼らは単純であざやかな解決方法をみたいのです。
+ カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
+ 問題を解決する解の背後になる思考プロセスを見たいとは思いません。
+ 彼らは単純であざやかな解決方法を見たいのです。
あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
議論することのバランスをキープするのは難しいかもしれません。
ですから、開発プロセスの早期段階で改善のためのフィードバックをもらうよ
-うにするのもいいですが、変更点を小さい部分に分割して全体ではまだ完成し
-ていない仕事を(部分的に)取り込んでもらえるようにすることもいいことです。
+うにするのも良いですが、変更点を小さい部分に分割して全体ではまだ完成し
+ていない仕事を(部分的に)取り込んでもらえるようにすることも良いことです。
また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
てもらうように送っても、それは受け付けられないことを理解してください。
- テスト結果
これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
-ントの ChangeLog セクションをみてください-
+ントの ChangeLog セクションを見てください-
"The Perfect Patch"
- http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
+ http://userweb.kernel.org/~akpm/stuff/tpp.txt
これらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するに
は数年かかるかもしれません。これは継続的な改善のプロセスであり、そのた
git://ftp.safe.ca / safe / jmp / linux-2.6 / blobdiff