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>.If you find any difference between this document and the original fileor a problem with the translation,please contact the maintainer of this file or JF project. Please also note that the purpose of this file is to be easier to readfor non English (read: Japanese) speakers and is not intended as afork. So if you have any comments or updates for this file, please tryto update the original English file first. Last Updated: 2011/03/31==================================これは、linux-2.6.38/Documentation/HOWTOの和訳です。 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >翻訳日： 2011/3/28翻訳者： 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>         武井伸光さん、<takei at webmasters dot gr dot jp>         かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or 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 カーネル開発のやり方------------------------------- これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅したドキュメントです。ここには Linux カーネル開発者になるための方法とLinux カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。カーネルプログラミングに関する技術的な項目に関することは何も含めないようにしていますが、カーネル開発者となるための正しい方向に向かう手助けになります。 もし、このドキュメントのどこかが古くなっていた場合には、このドキュメントの最後にリストしたメンテナにパッチを送ってください。 はじめに--------- あなたは　Linux カーネルの開発者になる方法を学びたいのでしょうか？　それともあなたは上司から「このデバイスの Linux ドライバを書くように」と言われているのでしょうか？　この文書の目的は、あなたが踏むべき手順と、コミュニティと一緒にうまく働くヒントを書き下すことで、あなたが知るべき全てのことを教えることです。また、このコミュニティがなぜ今うまくまわっているのかという理由の一部も説明しようと試みています。  カーネルは 少量のアーキテクチャ依存部分がアセンブリ言語で書かれている以外は大部分は C 言語で書かれています。C言語をよく理解していることはカーネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするのでなければ、(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要ありません。以下の本は、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実践プログラミング第3版』(Steve Oualline著 望月康司監訳 谷口功訳) [オライリージャパン] - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall] - 『新・詳説 C 言語 H&S リファレンス』       (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク] カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネルは ISO C89 仕様に準拠して書く一方で、標準には無い言語拡張を多く使っています。カーネルは標準 C ライブラリとは関係がないといった、C 言語フリースタンディング環境です。そのため、C の標準で使えないものもあります。任意の long long の除算や浮動小数点は使えません。ときどき、カーネルがツールチェインや C 言語拡張に置いている前提がどうなっているのかわかりにくいことがあり、また、残念なことに決定的なリファレンスは存在しません。情報を得るには、gcc の info ページ( info gcc )を見てください。 あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしていることに留意してください。そのコミュニティは、コーディング、スタイル、開発手順について高度な標準を持つ、多様な人の集まりです。地理的に分散した大規模なチームに対してもっともうまくいくとわかったことをベースにしながら、これらの標準は長い時間をかけて築かれてきました。これらはきちんと文書化されていますから、事前にこれらの標準についてできるだけたくさん学んでください。また皆があなたやあなたの会社のやり方に合わせてくれると思わないでください。 法的問題------------ Linux カーネルのソースコードは GPL ライセンスの下でリリースされています。ライセンスの詳細については、ソースツリーのメインディレクトリに存在する、COPYING のファイルを見てください。もしライセンスについてさらに質問があれば、Linux Kernel メーリングリストに質問するのではなく、どうぞ法律家に相談してください。メーリングリストの人達は法律家ではなく、法的問題については彼らの声明はあてにするべきではありません。 GPL に関する共通の質問や回答については、以下を参照してください。	http://www.gnu.org/licenses/gpl-faq.html ドキュメント------------ Linux カーネルソースツリーは幅広い範囲のドキュメントを含んでおり、それらはカーネルコミュニティと会話する方法を学ぶのに非常に貴重なものです。新しい機能がカーネルに追加される場合、その機能の使い方について説明した新しいドキュメントファイルも追加することを勧めます。カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報をマニュアルページのメンテナ mtk.manpages@gmail.com に送り、CC をlinux-api@ver.kernel.org に送ることを勧めます。 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧です-   README    このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注    configure )し、生成(訳注 build )するために必要なことは何かが書かれ    ています。カーネルに関して初めての人はここからスタートすると良いで    しょう。   Documentation/Changes     このファイルはカーネルをうまく生成(訳注 build )し、走らせるのに最     小限のレベルで必要な数々のソフトウェアパッケージの一覧を示してい     ます。   Documentation/CodingStyle    これは Linux カーネルのコーディングスタイルと背景にある理由を記述    しています。全ての新しいコードはこのドキュメントにあるガイドライン    に従っていることを期待されています。大部分のメンテナはこれらのルー    ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード    だけをレビューします。   Documentation/SubmittingPatches  Documentation/SubmittingDrivers     これらのファイルには、どうやってうまくパッチを作って投稿するかに     ついて非常に詳しく書かれており、以下を含みます(これだけに限らない     けれども)        - Email に含むこと        - Email の形式        - だれに送るか     これらのルールに従えばうまくいくことを保証することではありません     が (すべてのパッチは内容とスタイルについて精査を受けるので)、     ルールに従わなければ間違いなくうまくいかないでしょう。      この他にパッチを作る方法についてのよくできた記述は- 	"The Perfect Patch"		http://userweb.kernel.org/~akpm/stuff/tpp.txt	"Linux kernel patch submission format"		http://linux.yyz.us/patch-format.html   Documentation/stable_api_nonsense.txt     このファイルはカーネルの中に不変のAPIを持たないことにした意識的な     決断の背景にある理由について書かれています。以下のようなことを含     んでいます-       - サブシステムとの間に層を作ること(コンパチビリティのため?)       - オペレーティングシステム間のドライバの移植性       - カーネルソースツリーの素早い変更を遅らせる(もしくは素早い変更         を妨げる)     このドキュメントは Linux 開発の思想を理解するのに非常に重要です。     そして、他のOSでの開発者が Linux に移る時にとても重要です。   Documentation/SecurityBugs    もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ    のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を    支援してください。   Documentation/ManagementStyle    このドキュメントは Linux カーネルのメンテナ達がどう行動するか、    彼らの手法の背景にある共有されている精神について記述しています。こ    れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）    重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な    行動についての多くの誤解や混乱を解消するからです。   Documentation/stable_kernel_rules.txt    このファイルはどのように stable カーネルのリリースが行われるかのルー    ルが記述されています。そしてこれらのリリースの中のどこかで変更を取    り入れてもらいたい場合に何をすれば良いかが示されています。   Documentation/kernel-docs.txt　　カーネル開発に付随する外部ドキュメントのリストです。もしあなたが    探しているものがカーネル内のドキュメントでみつからなかった場合、    このリストをあたってみてください。   Documentation/applying-patches.txt    パッチとはなにか、パッチをどうやって様々なカーネルの開発ブランチに    適用するのかについて正確に記述した良い入門書です。 カーネルはソースコードから自動的に生成可能な多数のドキュメントを自分自身でもっています。これにはカーネル内 API のすべての記述や、どう正しくロックをかけるかの規則が含まれます。このドキュメントはDocumentation/DocBook/ ディレクトリに作られ、以下のように	make pdfdocs	make psdocs	make htmldocs	make mandocsコマンドを実行するとメインカーネルのソースディレクトリからそれぞれ、PDF, Postscript, HTML, man page の形式で生成されます。 カーネル開発者になるには--------------------------- もしあなたが、Linux カーネル開発について何も知らないならば、KernelNewbies プロジェクトを見るべきです	http://kernelnewbies.org このサイトには役に立つメーリングリストがあり、基本的なカーネル開発に関するほとんどどんな種類の質問もできます (既に回答されているようなことを聞く前にまずはアーカイブを調べてください)。またここには、リアルタイムで質問を聞くことができる IRC チャネルや、Linuxカーネルの開発に関して学ぶのに便利なたくさんの役に立つドキュメントがあります。 web サイトには、コードの構成、サブシステム、現在存在するプロジェクト(ツリーにあるもの無いものの両方)の基本的な管理情報があります。ここには、また、カーネルのコンパイルのやり方やパッチの当て方などの間接的な基本情報も記述されています。 あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュニティに参加して何かすることをさがしている場合には、Linux kernelJanitor's プロジェクトにいけば良いでしょう -	http://kernelnewbies.org/KernelJanitorsここはそのようなスタートをするのにうってつけの場所です。ここには、Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければならない、単純な問題のリストが記述されています。このプロジェクトに関わる開発者と一緒に作業することで、あなたのパッチを Linuxカーネルツリーに入れるための基礎を学ぶことができ、そしてもしあなたがまだアイディアを持っていない場合には、次にやる仕事の方向性が見えてくるかもしれません。 もしあなたが、すでにひとまとまりコードを書いていて、カーネルツリーに入れたいと思っていたり、それに関する適切な支援を求めたい場合、カーネルメンターズプロジェクトはそのような皆さんを助けるためにできました。ここにはメーリングリストがあり、以下から参照できます	http://selenic.com/mailman/listinfo/kernel-mentors 実際に Linux カーネルのコードについて修正を加える前に、どうやってそのコードが動作するのかを理解することが必要です。そのためには、特別なツールの助けを借りてでも、それを直接よく読むことが最良の方法です(ほとんどのトリッキーな部分は十分にコメントしてありますから)。そういうツールで特におすすめなのは、Linux クロスリファレンスプロジェクトです。これは、自己参照方式で、索引がついた web 形式で、ソースコードを参照することができます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかります-	http://sosdg.org/~qiyong/lxr/ 開発プロセス----------------------- Linux カーネルの開発プロセスは現在幾つかの異なるメインカーネル「ブランチ」と多数のサブシステム毎のカーネルブランチから構成されます。これらのブランチとは-  - メインの 2.6.x カーネルツリー  - 2.6.x.y -stable カーネルツリー  - 2.6.x -git カーネルパッチ  - サブシステム毎のカーネルツリーとパッチ  - 統合テストのための 2.6.x -next カーネルツリー 2.6.x カーネルツリー----------------- 2.6.x カーネルは Linus Torvalds によってメンテナンスされ、kernel.orgの pub/linux/kernel/v2.6/ ディレクトリに存在します。この開発プロセスは以下のとおり-   - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、    この期間中に、メンテナ達は Linus に大きな差分を送ることができます。    このような差分は通常 -next カーネルに数週間含まれてきたパッチです。    大きな変更は git(カーネルのソース管理ツール、詳細は    http://git-scm.com/  参照) を使って送るのが好ましいやり方ですが、パッ    チファイルの形式のまま送るのでも十分です。   - 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定    性に影響をあたえるような新機能は含まない類のパッチしか取り込むこと    はできません。新しいドライバ(もしくはファイルシステム)のパッチは    -rc1 の後で受け付けられることもあることを覚えておいてください。な    ぜなら、変更が独立していて、追加されたコードの外の領域に影響を与え    ない限り、退行のリスクは無いからです。-rc1 がリリースされた後、    Linus へパッチを送付するのに git を使うこともできますが、パッチは    レビューのために、パブリックなメーリングリストへも同時に送る必要が    あります。   - 新しい -rc は Linus が、最新の git ツリーがテスト目的であれば十分    に安定した状態にあると判断したときにリリースされます。目標は毎週新    しい -rc カーネルをリリースすることです。   - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま    す。このプロセスはだいたい 6週間継続します。   - 各リリースでの既知の後戻り問題(regression: このリリースの中で新規    に作り込まれた問題を指す) はその都度 Linux-kernel メーリングリスト    に投稿されます。ゴールとしては、カーネルが 「準備ができた」と宣言    する前にこのリストの長さをゼロに減らすことですが、現実には、数個の    後戻り問題がリリース時にたびたび残ってしまいます。 Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについて書いたことをここで言っておくことは価値があります-  「カーネルがいつリリースされるかは誰も知りません。なぜなら、これは現  実に認識されたバグの状況によりリリースされるのであり、前もって決めら  れた計画によってリリースされるものではないからです。」 2.6.x.y -stable カーネルツリー--------------------------- バージョン番号が4つの数字に分かれているカーネルは -stable カーネルです。これには、2.6.x カーネルで見つかったセキュリティ問題や重大な後戻りに対する比較的小さい重要な修正が含まれます。 これは、開発/実験的バージョンのテストに協力することに興味が無く、最新の安定したカーネルを使いたいユーザに推奨するブランチです。 もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x が最新の安定版カーネルです。 2.6.x.y は "stable" チーム <stable@kernel.org> でメンテされており、必要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫った問題がなければもう少し長くなることもあります。セキュリティ関連の問題の場合はこれに対してだいたいの場合、すぐにリリースがされます。 カーネルツリーに入っている、Documentation/stable_kernel_rules.txt ファイルにはどのような種類の変更が -stable ツリーに受け入れ可能か、またリリースプロセスがどう動くかが記述されています。 2.6.x -git パッチ------------------ git リポジトリで管理されているLinus のカーネルツリーの毎日のスナップショットがあります。(だから -git という名前がついています)。これらのパッチはおおむね毎日リリースされており、Linus のツリーの現状を表します。これは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的に生成されるので、より実験的です。 サブシステム毎のカーネルツリーとパッチ------------------------------------------- それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネルサブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに公開しています。そのため、自分とは異なる領域のカーネルで何が起きているかを他の人が見られるようになっています。開発が早く進んでいる領域では、開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。 大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM やquilt シリーズとして公開されているパッチキューも使われています。これらのサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされています。これらの多くは http://git.kernel.org/ で参照することができます。 提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メーリングリストで事前にレビューにかけられます（以下の対応するセクションを参照）。いくつかのカーネルサブシステムでは、このレビューは patchworkというツールによって追跡されます。Patchwork は web インターフェイスによってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そしてメンテナはパッチに対して、レビュー中、受付済み、拒否というようなマークをつけることができます。大部分のこれらの patchwork のサイトはhttp://patchwork.kernel.org/ でリストされています。 統合テストのための 2.6.x -next カーネルツリー--------------------------------------------- サブシステムツリーの更新内容がメインラインの 2.6.x ツリーにマージされる前に、それらは統合テストされる必要があります。この目的のため、実質的に全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリポジトリが存在します-       http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git       http://linux.f-seidel.de/linux-next/pmwiki/ このやり方によって、-next カーネルは次のマージ機会でどんなものがメインラインカーネルにマージされるか、おおまかなの展望を提供します。-next カーネルの実行テストを行う冒険好きなテスターは大いに歓迎されます バグレポート------------- bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。どう kernel bugzilla を使うかの詳細は、以下を参照してください-	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 メーリングリスト------------- 上のいくつかのドキュメントで述べていますが、コアカーネル開発者の大部分は Linux kernel メーリングリストに参加しています。このリストの登録/脱退の方法については以下を参照してください-	http://vger.kernel.org/vger-lists.html#linux-kernel このメーリングリストのアーカイブは web 上の多数の場所に存在します。これらのアーカイブを探すにはサーチエンジンを使いましょう。例えば-	http://dir.gmane.org/gmane.linux.kernel リストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索することを是非やってください。多数の事がすでに詳細に渡って議論されており、アーカイブにのみ記録されています。 大部分のカーネルサブシステムも自分の個別の開発を実施するメーリングリストを持っています。個々のグループがどんなリストを持っているかは、MAINTAINERS ファイルにリストがありますので参照してください。 多くのリストは kernel.org でホストされています。これらの情報は以下にあります-	http://vger.kernel.org/vger-lists.html メーリングリストを使う場合、良い行動習慣に従うようにしましょう。少し安っぽいが、以下の URL は上のリスト(や他のリスト)で会話する場合のシンプルなガイドラインを示しています-	http://www.albion.com/netiquette/ もし複数の人があなたのメールに返事をした場合、CC: で受ける人のリストはだいぶ多くなるでしょう。良い理由がない場合、CC: リストから誰かを削除をしないように、また、メーリングリストのアドレスだけにリプライすることのないようにしましょう。1つは送信者から、もう1つはリストからのように、メールを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追加してこの状態を変えようとしないように。人々はそのようなことは好みません。 今までのメールでのやりとりとその間のあなたの発言はそのまま残し、"John Kernlehacker wrote ...:" の行をあなたのリプライの先頭行にして、メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきです。 もしパッチをメールに付ける場合は、Documentaion/SubmittingPatches に提示されているように、それは プレーンな可読テキストにすることを忘れないようにしましょう。カーネル開発者は 添付や圧縮したパッチを扱いたがりません-彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうするしかありません。あなたのメールプログラムが空白やタブを圧縮しないように確認した方が良いです。最初の良いテストとしては、自分にメールを送ってみて、そのパッチを自分で当ててみることです。もしそれがうまく行かないなら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべきです。 とりわけ、他の登録者に対する尊敬を表すようにすることを覚えておいてください。 コミュニティと共に働くこと-------------------------- カーネルコミュニティのゴールは可能なかぎり最高のカーネルを提供することです。あなたがパッチを受け入れてもらうために投稿した場合、それは、技術的メリットだけがレビューされます。その際、あなたは何を予想すべきでしょうか?  - 批判  - コメント  - 変更の要求  - パッチの正当性の証明要求  - 沈黙 思い出してください、ここはあなたのパッチをカーネルに入れる話です。あなたは、あなたのパッチに対する批判とコメントを受け入れるべきで、それらを技術的レベルで評価して、パッチを再作成するか、なぜそれらの変更をすべきでないかを明確で簡潔な理由の説明を提供してください。もし、あなたのパッチに何も反応がない場合、たまにはメールの山に埋もれて見逃され、あなたの投稿が忘れられてしまうこともあるので、数日待って再度投稿してください。 あなたがやるべきでないものは?  - 質問なしにあなたのパッチが受け入れられると想像すること  - 守りに入ること  - コメントを無視すること  - 要求された変更を何もしないでパッチを出し直すこと 可能な限り最高の技術的解決を求めているコミュニティでは、パッチがどのくらい有益なのかについては常に異なる意見があります。あなたは協調的であるべきですし、また、あなたのアイディアをカーネルに対してうまく合わせるようにすることが望まれています。もしくは、最低限あなたのアイディアがそれだけの価値があるとすすんで証明するようにしなければなりません。正しい解決に向かって進もうという意志がある限り、間違うことがあっても許容されることを忘れないでください。 あなたの最初のパッチに単に 1ダースもの修正を求めるリストの返答になることも普通のことです。これはあなたのパッチが受け入れられないということでは *ありません*、そしてあなた自身に反対することを意味するのでも *ありません*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば

Lines 1–500 of 644. Load more