2011/03/31==================================これは、linux-2.6.38/Documentation/HOWTOの和訳です。カーネル開発のやり方)の重要な事柄を網羅したドキュメントです。カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。カーネルプログラミングに関する技術的な項目に関することは何も含めないようにしていますが、カーネル開発者となるための正しい方向に向かう手助けになります。このドキュメントのどこかが古くなっていた場合には、このドキュメントの最後にリストしたメンテナにパッチを送ってください。この文書の目的は、あなたが踏むべき手順と、コミュニティと一緒にうまく働くヒントを書き下すことで、あなたが知るべき全てのことを教えることです。このコミュニティがなぜ今うまくまわっているのかという理由の一部も説明しようと試みています。言語で書かれています。C言語をよく理解していることはカーネル開発者には必要です。言語)は必要ありません。言語の十分な知識や何年もの経験に取って代わるものではありませんが、少なくともリファレンスとしては良い本です。ツールチェインを使って書かれています。仕様に準拠して書く一方で、標準には無い言語拡張を多く使っています。言語フリースタンディング環境です。標準で使えないものもあります。除算や浮動小数点は使えません。言語拡張に置いている前提がどうなっているのかわかりにくいことがあり、また、残念なことに決定的なリファレンスは存在しません。あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしていることに留意してください。開発手順について高度な標準を持つ、多様な人の集まりです。地理的に分散した大規模なチームに対してもっともうまくいくとわかったことをベースにしながら、これらの標準は長い時間をかけて築かれてきました。これらはきちんと文書化されていますから、事前にこれらの標準についてできるだけたくさん学んでください。皆があなたやあなたの会社のやり方に合わせてくれると思わないでください。ライセンスの下でリリースされています。ファイルを見てください。メーリングリストに質問するのではなく、どうぞ法律家に相談してください。問題については彼らの声明はあてにするべきではありません。関する共通の質問や回答については、以下を参照してください。カーネルソースツリーは幅広い範囲のドキュメントを含んでおり、それらはカーネルコミュニティと会話する方法を学ぶのに非常に貴重なものです。新しい機能がカーネルに追加される場合、その機能の使い方について説明した新しいドキュメントファイルも追加することを勧めます。)するために必要なことは何かが書かれています。カーネルに関して初めての人はここからスタートすると良いでしょう。小限のレベルで必要な数々のソフトウェアパッケージの一覧を示しています。カーネルのコーディングスタイルと背景にある理由を記述しています。全ての新しいコードはこのドキュメントにあるガイドラインに従っていることを期待されています。大部分のメンテナはこれらのルールに従っているものだけを受け付け、多くの人は正しいスタイルのコードだけをレビューします。(すべてのパッチは内容とスタイルについて精査を受けるので)、ルールに従わなければ間違いなくうまくいかないでしょう。format"http://linux.yyz.us/patch-format.htmlDocumentation/stable_api_nonsense.txtこのファイルはカーネルの中に不変のAPIを持たないことにした意識的な決断の背景にある理由について書かれています。開発の思想を理解するのに非常に重要です。移る時にとても重要です。カーネルでセキュリティ問題を発見したように思ったら、このドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を支援してください。彼らの手法の背景にある共有されている精神について記述しています。これはカーネル開発の初心者なら(もしくは、単に興味があるだけの人でも)重要です。このドキュメントは、カーネルメンテナ達の独特な行動についての多くの誤解や混乱を解消するからです。カーネルのリリースが行われるかのルールが記述されています。これらのリリースの中のどこかで変更を取り入れてもらいたい場合に何をすれば良いかが示されています。Documentation/kernel-docs.txtカーネル開発に付随する外部ドキュメントのリストです。あなたが探しているものがカーネル内のドキュメントでみつからなかった場合、このリストをあたってみてください。Documentation/applying-patches.txtパッチとはなにか、パッチをどうやって様々なカーネルの開発ブランチに適用するのかについて正確に記述した良い入門書です。すべての記述や、どう正しくロックをかけるかの規則が含まれます。(既に回答されているようなことを聞く前にまずはアーカイブを調べてください)。チャネルや、Linuxカーネルの開発に関して学ぶのに便利なたくさんの役に立つドキュメントがあります。サイトには、コードの構成、サブシステム、現在存在するプロジェクト(ツリーにあるもの無いものの両方)の基本的な管理情報があります。的な基本情報も記述されています。-http://kernelnewbies.org/KernelJanitorsここはそのようなスタートをするのにうってつけの場所です。カーネルソースツリーの中に含まれる、きれいにし、修正しなければならない、単純な問題のリストが記述されています。Linuxカーネルツリーに入れるための基礎を学ぶことができ、そしてもしあなたがまだアイディアを持っていない場合には、次にやる仕事の方向性が見えてくるかもしれません。あなたが、すでにひとまとまりコードを書いていて、カーネルツリーに入れたいと思っていたり、それに関する適切な支援を求めたい場合、カーネルメンターズプロジェクトはそのような皆さんを助けるためにできました。カーネルのコードについて修正を加える前に、どうやってそのコードが動作するのかを理解することが必要です。そのためには、特別なツールの助けを借りてでも、それを直接よく読むことが最良の方法です(ほとんどのトリッキーな部分は十分にコメントしてありますから)。クロスリファレンスプロジェクトです。形式で、ソースコードを参照することができます。カーネルの開発プロセスは現在幾つかの異なるメインカーネル「ブランチ」と多数のサブシステム毎のカーネルブランチから構成されます。ディレクトリに存在します。大きな差分を送ることができます。カーネルに数週間含まれてきたパッチです。使って送るのが好ましいやり方ですが、パッチファイルの形式のまま送るのでも十分です。性に影響をあたえるような新機能は含まない類のパッチしか取り込むことはできません。後で受け付けられることもあることを覚えておいてください。変更が独立していて、追加されたコードの外の領域に影響を与えない限り、退行のリスクは無いからです。使うこともできますが、パッチはレビューのために、パブリックなメーリングリストへも同時に送る必要があります。ツリーがテスト目的であれば十分に安定した状態にあると判断したときにリリースされます。カーネルをリリースすることです。「準備ができた」と考えられるまで継続します。メーリングリストに投稿されます。「準備ができた」と宣言する前にこのリストの長さをゼロに減らすことですが、現実には、数個の後戻り問題がリリース時にたびたび残ってしまいます。メーリングリストにカーネルリリースについて書いたことをここで言っておくことは価値があります-「カーネルがいつリリースされるかは誰も知りません。実に認識されたバグの状況によりリリースされるのであり、前もって決められた計画によってリリースされるものではないからです。カーネルで見つかったセキュリティ問題や重大な後戻りに対する比較的小さい重要な修正が含まれます。最新の安定したカーネルを使いたいユーザに推奨するブランチです。最新の安定版カーネルです。要に応じてリリースされます。2週間毎ですが、差し迫った問題がなければもう少し長くなることもあります。セキュリティ関連の問題の場合はこれに対してだいたいの場合、すぐにリリースがされます。ツリーに受け入れ可能か、またリリースプロセスがどう動くかが記述されています。カーネルツリーの毎日のスナップショットがあります。いう名前がついています)。ツリーの現状を表します。カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的に生成されるので、より実験的です。各自の最新の開発状況をソースリポジトリに公開しています。そのため、自分とは異なる領域のカーネルで何が起きているかを他の人が見られるようになっています。開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。シリーズとして公開されているパッチキューも使われています。ファイルにリストされています。参照することができます。提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メーリングリストで事前にレビューにかけられます(以下の対応するセクションを参照)。patchworkというツールによって追跡されます。インターフェイスによってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そしてメンテナはパッチに対して、レビュー中、受付済み、拒否というようなマークをつけることができます。ツリーにマージされる前に、それらは統合テストされる必要があります。カーネルは次のマージ機会でどんなものがメインラインカーネルにマージされるか、おおまかなの展望を提供します。カーネル開発者がカーネルのバグを追跡する場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。バグレポートの管理-------------------あなたのハッキングのスキルを訓練する最高の方法のひとつに、他人がレポートしたバグを修正することがあります。現実の問題を修正することを学び、自分のスキルも強化でき、また他の開発者があなたの存在に気がつきます。バグを修正することは、多くの開発者の中から自分が功績をあげる最善の道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好まないからです。変更毎にここにメールされる)を購読できます。メーリングリストに参加しています。上の多数の場所に存在します。これらのアーカイブを探すにはサーチエンジンを使いましょう。-http://dir.gmane.org/gmane.linux.kernelリストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索することを是非やってください。多数の事がすでに詳細に渡って議論されており、アーカイブにのみ記録されています。大部分のカーネルサブシステムも自分の個別の開発を実施するメーリングリストを持っています。ファイルにリストがありますので参照してください。これらの情報は以下にあります-http://vger.kernel.org/vger-lists.htmlメーリングリストを使う場合、良い行動習慣に従うようにしましょう。受ける人のリストはだいぶ多くなるでしょう。リストから誰かを削除をしないように、また、メーリングリストのアドレスだけにリプライすることのないようにしましょう。1つは送信者から、もう1つはリストからのように、メールを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追加してこの状態を変えようとしないように。人々はそのようなことは好みません。行をあなたのリプライの先頭行にして、メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきです。プレーンな可読テキストにすることを忘れないようにしましょう。添付や圧縮したパッチを扱いたがりません-彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうするしかありません。あなたのメールプログラムが空白やタブを圧縮しないように確認した方が良いです。最初の良いテストとしては、自分にメールを送ってみて、そのパッチを自分で当ててみることです。それがうまく行かないなら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべきです。他の登録者に対する尊敬を表すようにすることを覚えておいてください。コミュニティと共に働くこと--------------------------カーネルコミュニティのゴールは可能なかぎり最高のカーネルを提供することです。的メリットだけがレビューされます。思い出してください、ここはあなたのパッチをカーネルに入れる話です。あなたは、あなたのパッチに対する批判とコメントを受け入れるべきで、それらを技術的レベルで評価して、パッチを再作成するか、なぜそれらの変更をすべきでないかを明確で簡潔な理由の説明を提供してください。要求された変更を何もしないでパッチを出し直すこと可能な限り最高の技術的解決を求めているコミュニティでは、パッチがどのくらい有益なのかについては常に異なる意見があります。あなたは協調的であるべきですし、また、あなたのアイディアをカーネルに対してうまく合わせるようにすることが望まれています。最低限あなたのアイディアがそれだけの価値があるとすすんで証明するようにしなければなりません。容されることを忘れないでください。1ダースもの修正を求めるリストの返答になることも普通のことです。自分のパッチに対して指摘された問題を全て修正して再送すれば良いのです。カーネルコミュニティと企業組織のちがい-----------------------------------------------------------------カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で動いています。私はこれについて、6ケ月作業している。働環境と異なるもう一つの点は、やりとりに顔を合わせないということです。第一のコミュニケーションの形とする一つの利点は、性別や民族の差別がないことです。アドレスによってのみあなたが認識されるからです。国際的な側面からも活動領域を均等にするようにします。あなたは人の名前で性別を想像できないからです。米国では女性、それ以外(欧州など)では男性名として使われることが多い。(主に男性名)の略称)。向きな経験をもっています。言葉の壁は英語が得意でない一部の人には問題になります。メーリングリストの中できちんとアイディアを交換するには、相当うまく英語を操れる必要があることもあります。そのため、あなたは自分のメールを送る前に英語で意味が通じているかをチェックすることをお薦めします。カーネルコミュニティは、一度に大量のコードの塊を喜んで受容することはありません。別の部分に分割する必要があります。これはこれまで多くの会社がやり慣れてきたことと全く正反対のことです。あなたのプロポーザルは、開発プロセスのとても早い段階から紹介されるべきです。あなたは自分のやっていることにフィードバックを得られます。これは、コミュニティからみれば、あなたが彼らと一緒にやっているように感じられ、単にあなたの提案する機能のゴミ捨て場として使っているのではない、と感じられるでしょう。メーリングリストに送りつけるようなことはやってはいけません、あなたのパッチ群はいつもどんな時でもそれよりは小さくなければなりません。小さいパッチはあなたのパッチが適用される見込みを大きくします、カーネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないからです。5行のパッチはメンテナがたった1秒見るだけで適用できます。500行のパッチは、正しいことをレビューするのに数時間かかるかもしれません(時間はパッチのサイズなどにより指数関数に比例してかかります)小さいパッチは何かあったときにデバッグもとても簡単になります。パッチを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かおかしくなった後で)解剖するのに比べればとても簡単です。小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにする(もしくは、単に順番を変えるだけでも)ことも、とても重要です。生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでしょう。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知っており、そして最終解の前の中間作業を提出することは決してないのです"カーネル開発でもこれは同じです。問題を解決する解の背後になる思考プロセスを見たいとは思いません。彼らは単純であざやかな解決方法を見たいのです。あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を議論することのバランスをキープするのは難しいかもしれません。開発プロセスの早期段階で改善のためのフィードバックをもらうようにするのも良いですが、変更点を小さい部分に分割して全体ではまだ完成していない仕事を(部分的に)取り込んでもらえるようにすることも良いことです。ようなパッチを、本流に含めてもらうように送っても、それは受け付けられないことを理解してください。コミュニティに知らせることはとても重要です。性と有用性で正当化されなければなりません。あなたの変更の説明--------------------あなたのパッチを送付する場合には、メールの中のテキストで何を言うかについて、特別に注意を払ってください。使われ、いつも皆がみられるように保管されます。Patch"http://userweb.kernel.org/~akpm/stuff/tpp.txtこれらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するには数年かかるかもしれません。これは継続的な改善のプロセスであり、そのためには多数の忍耐と決意を必要とするものです。多数の人がすでにできていますし、彼らも皆最初はあなたと同じところからスタートしたのですから。セクションをこのテキストの原型にすることを許可してくれました。メーリングリストでやるべきこととやってはいけないことのリストを提供してくれました。以下の人々のレビュー、コメント、貢献に感謝。Shepard彼らの支援なしでは、このドキュメントはできなかったでしょう。