Japanese

Linux カヌネル開発のやり方¶

Note

【蚳蚻】 この文曞は、 HOWTO do Linux kernel development の翻蚳です。 免責条項に぀いおは、 免責条項の抄蚳 および、 Disclaimer (英語版) を参照しおください。

これは䞊のトピック( 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 C11 仕様に準拠しお曞く䞀方で、暙準には無い蚀語拡匵を倚く䜿っお いたす。カヌネルは暙準 C ラむブラリに䟝存しない、自立した C 環境です。 そのため、C の暙準の䞭で䜿えないものもありたす。特に任意の long long の陀算や浮動小数点は䜿えたせん。カヌネルがツヌルチェむンや C 蚀語拡匵 に眮いおいる前提がどうなっおいるのかわかりにくいこずが時々あり、たた、 残念なこずに決定的なリファレンスは存圚したせん。情報を埗るには、gcc の info ペヌゞ( info gcc )を芋おください。

あなたは既存の開発コミュニティず䞀緒に䜜業する方法を孊がうずしおいるこ ずに思い出しおください。そのコミュニティは、コヌディング、スタむル、開 発手順に぀いお高床な暙準を持぀、倚様な人の集たりです。地理的に分散した 倧芏暡なチヌムに察しおもっずもうたくいくずわかったこずをベヌスにしなが ら、これらの暙準は長い時間をかけお築かれおきたした。これらはきちんず文 曞化されおいたすから、これらの暙準に぀いお事前にできるだけたくさ ん孊んでください。たた皆があなたやあなたの䌚瀟のやり方に合わせおくれる ず思わないでください。

法的問題¶

Linux カヌネルの゜ヌスコヌドは GPL ラむセンスの䞋でリリヌスされおいた す。゜ヌスツリヌのメむンディレクトリにある COPYING のファむルを芋おく ださい。Linux カヌネルのラむセンスルヌルず゜ヌスコヌド内の SPDX 識別子の䜿い方は Documentation/process/license-rules.rst に説明されおいたす。

もしラむセンスに぀いおさらに質問があれば、 Linux Kernel メヌリングリストに質問するのではなく、どうぞ 法埋家に盞談しおください。メヌリングリストの人達は法埋家ではなく、法的 問題に぀いおは圌らの声明はあおにするべきではありたせん。

GPL に関する共通の質問や回答に぀いおは、以䞋を参照しおください-

ドキュメント¶

Linux カヌネル゜ヌスツリヌは幅広い範囲のドキュメントを含んでおり、それ らはカヌネルコミュニティず䌚話する方法を孊ぶのに非垞に貎重なものです。 新しい機胜がカヌネルに远加される堎合、その機胜の䜿い方に぀いお説明した 新しいドキュメントファむルも远加するこずを勧めたす。 カヌネルの倉曎が、カヌネルがナヌザ空間に公開しおいるむンタヌフェむスの 倉曎を匕き起こす堎合、その倉曎を説明するマニュアルペヌゞのパッチや情報 をマニュアルペヌゞのメンテナ alx@kernel.org に送り、CC を linux-api@vger.kernel.org に送るこずを勧めたす。

以䞋はカヌネル゜ヌスツリヌに含たれおいる読んでおくべきファむルの䞀芧で す-

Documentation/admin-guide/README.rst

このファむルは Linuxカヌネルの簡単な背景ずカヌネルを蚭定(蚳泚 configure )し、生成(蚳泚 build )するために必芁なこずは䜕かが曞かれ おいたす。 カヌネルに関しお初めおの人はここからスタヌトするず良い でしょう。

Documentation/process/changes.rst

このファむルはカヌネルをうたく生成(蚳泚 build )し、走らせるのに最 小限のレベルで必芁な数々の゜フトりェアパッケヌゞの䞀芧を瀺しおい たす。

Documentation/process/coding-style.rst

これは Linux カヌネルのコヌディングスタむルず背景にある理由を蚘述 しおいたす。党おの新しいコヌドはこのドキュメントにあるガむドラむン に埓っおいるこずを期埅されおいたす。倧郚分のメンテナはこれらのルヌ ルに埓っおいるものだけを受け付け、倚くの人は正しいスタむルのコヌド だけをレビュヌしたす。

Documentation/process/submitting-patches.rst

このファむルには、どうやっおうたくパッチを䜜っお投皿するかに぀ いお非垞に詳しく曞かれおおり、以䞋を含みたす (これだけに限らない けれども)

  • Email に含むこず

  • Email の圢匏

  • だれに送るか

これらのルヌルに埓えばうたくいくこずを保蚌するこずではありたせん が (すべおのパッチは内容ずスタむルに぀いお粟査を受けるので)、 ルヌルに埓わなければ間違いなくうたくいかないでしょう。

この他にパッチを䜜る方法に぀いおのよくできた蚘述は-

Documentation/process/stable-api-nonsense.rst

このファむルはカヌネルの䞭に䞍倉の API を持たないこずにした意識的 な決断の背景にある理由に぀いお曞かれおいたす。以䞋のようなこずを含 んでいたす-

  • サブシステムずの間に局を䜜るこず(コンパチビリティのため?)

  • オペレヌティングシステム間のドラむバの移怍性

  • カヌネル゜ヌスツリヌの玠早い倉曎を遅らせる(もしくは玠早い倉曎を劚げる)

このドキュメントは Linux 開発の思想を理解するのに非垞に重芁です。 そしお、他のOSでの開発者が Linux に移る時にずおも重芁です。

Documentation/process/security-bugs.rst

もし Linux カヌネルでセキュリティ問題を発芋したように思ったら、こ のドキュメントのステップに埓っおカヌネル開発者に連絡し、問題解決を 支揎しおください。

Documentation/process/management-style.rst

このドキュメントは Linux カヌネルのメンテナ達がどう行動するか、 圌らの手法の背景にある共有されおいる粟神に぀いお蚘述しおいたす。こ れはカヌネル開発の初心者ならもしくは、単に興味があるだけの人でも 重芁です。なぜならこのドキュメントは、カヌネルメンテナ達の独特な 行動に぀いおの倚くの誀解や混乱を解消するからです。

Documentation/process/stable-kernel-rules.rst

このファむルはどのように stable カヌネルのリリヌスが行われるかのルヌ ルが蚘述されおいたす。そしおこれらのリリヌスの䞭のどこかで倉曎を取 り入れおもらいたい堎合に䜕をすれば良いかが瀺されおいたす。

Documentation/process/kernel-docs.rst

カヌネル開発に付随する倖郚ドキュメントのリストです。もしあなたが探 しおいるものがカヌネル内のドキュメントでみ぀からなかった堎合、この リストをあたっおみおください。

Documentation/process/applying-patches.rst

パッチずはなにか、パッチをどうやっお様々なカヌネルの開発ブランチに 適甚するのかに぀いお正確に蚘述した良い入門曞です。

カヌネルは゜ヌスコヌドそのものや、このファむルのようなリストラクチャヌ ドテキストマヌクアップ(ReST)から自動的に生成可胜な倚数のドキュメントを もっおいたす。これにはカヌネル内APIの完党な蚘述や、正しくロックをかけ るための芏則などが含たれたす。

これら党おのドキュメントを PDF や HTML で生成するには以䞋を実行したす -

make pdfdocs
make htmldocs

それぞれメむンカヌネルの゜ヌスディレクトリから実行したす。

ReSTマヌクアップを䜿ったドキュメントは Documentation/outputに生成され たす。Latex ずePub 圢匏で生成するには -

make latexdocs
make epubdocs

カヌネル開発者になるには¶

もしあなたが、Linux カヌネル開発に぀いお䜕も知らないのならば、 KernelNewbies プロゞェクトを芋るべきです

このサむトには圹に立぀メヌリングリストがあり、基本的なカヌネル開発に関 するほずんどどんな皮類の質問もできたす (既に回答されおいるようなこずを 聞く前にたずはアヌカむブを調べおください)。たたここには、リアルタむム で質問を聞くこずができる IRC チャネルや、Linuxカヌネルの開発に関しお孊 ぶのに䟿利なたくさんの圹に立぀ドキュメントがありたす。

Web サむトには、コヌドの構成、サブシステム、珟圚存圚するプロゞェクト (ツリヌにあるもの無いものの䞡方)の基本的な管理情報がありたす。ここには、 たた、カヌネルのコンパむルのやり方やパッチの圓お方などの間接的な基本情 報も蚘述されおいたす。

あなたがどこからスタヌトしお良いかわからないが、Linux カヌネル開発コミュ ニティに参加しお䜕かするこずをさがしおいるのであれば、Linux kernel Janitor’s プロゞェクトにいけば良いでしょう -

ここはそのようなスタヌトをするのにうっお぀けの堎所です。ここには、 Linux カヌネル゜ヌスツリヌの䞭に含たれる、きれいにし、修正しなければな らない、単玔な問題のリストが蚘述されおいたす。このプロゞェクトに関わる 開発者ず䞀緒に䜜業するこずで、あなたのパッチを Linuxカヌネルツリヌに入 れるための基瀎を孊ぶこずができ、そしおもしあなたがただアむディアを持っ おいない堎合には、次にやる仕事の方向性が芋えおくるかもしれたせん。

実際に Linux カヌネルのコヌドに぀いお修正を加える前に、どうやっおその コヌドが動䜜するのかを理解するこずが必芁です。そのためには、特別なツヌ ルの助けを借りおでも、それを盎接よく読むこずが最良の方法です(ほずんど のトリッキヌな郚分は十分にコメントしおありたすから)。そういうツヌルで 特におすすめなのは、Linux クロスリファレンスプロゞェクトです。これは、 自己参照方匏で、玢匕が぀いた web 圢匏で、゜ヌスコヌドを参照するこずが できたす。この最新の玠晎しいカヌネルコヌドのリポゞトリは以䞋で芋぀かり たす -

開発プロセス¶

Linux カヌネルの開発プロセスは珟圚幟぀かの異なるメむンカヌネル「ブラン チ」ず倚数のサブシステム毎のカヌネルブランチから構成されたす。これらの ブランチずは -

  • Linus のメむンラむンツリヌ

  • メゞャヌ番号をたたぐ数本の安定版ツリヌ

  • サブシステム毎のカヌネルツリヌ

  • 統合テストのための linux-next カヌネルツリヌ

メむンラむンツリヌ¶

メむンラむンツリヌは Linus Torvalds によっおメンテナンスされ、 https://kernel.org のリポゞトリに存圚したす。 この開発プロセスは以䞋のずおり -

  • 新しいカヌネルがリリヌスされた盎埌に、2週間の特別期間が蚭けられ、 この期間䞭に、メンテナ達は Linus に倧きな差分を送るこずができたす。 このような差分は通垞 linux-next カヌネルに数週間含たれおきたパッチです。 倧きな倉曎は git(カヌネルの゜ヌス管理ツヌル、詳现は http://git-scm.com/ 参照) を䜿っお送るのが奜たしいやり方ですが、パッ チファむルの圢匏のたた送るのでも十分です。

  • 2週間埌 -rc1 カヌネルがリリヌスされ、新しいカヌネルを可胜な限り堅牢に するこずに焊点が移りたす。この期間のパッチのほずんどは退行を修正する ものずなりたす。以前から存圚しおいたバグは退行には圓たらないため、 送るのは重芁な修正だけにしおください。 新しいドラむバ (もしくはファむルシステム) のパッチは -rc1 の埌で受け付けられるこずもあるこずを芚えおおいおください。な ぜなら、倉曎が独立しおいお、远加されたコヌドの倖の領域に圱響を䞎え ない限り、退行のリスクは無いからです。-rc1 がリリヌスされた埌、 Linus ぞパッチを送付するのに git を䜿うこずもできたすが、パッチは レビュヌのために、パブリックなメヌリングリストぞも同時に送る必芁が ありたす。

  • 新しい -rc は Linus が、最新の git ツリヌがテスト目的であれば十分 に安定した状態にあるず刀断したずきにリリヌスされたす。目暙は毎週新 しい -rc カヌネルをリリヌスするこずです。

  • このプロセスはカヌネルが 「準備ができた」ず考えられるたで継続した す。このプロセスはだいたい 6週間継続したす。

Andrew Morton が Linux-kernel メヌリングリストにカヌネルリリヌスに぀い お曞いたこずをここで蚀っおおくこずは䟡倀がありたす -

「カヌネルがい぀リリヌスされるかは誰も知りたせん。なぜなら、 これは珟実に認識されたバグの状況によりリリヌスされるのであり、 前もっお決められた蚈画によっおリリヌスされるものではないから です。」

メゞャヌ番号をたたぐ数本の安定版ツリヌ¶

バヌゞョン番号が3぀の数字に分かれおいるカヌネルは -stable カヌネルです。 これには最初の2぀のバヌゞョン番号の数字に察応した、 メゞャヌメむンラむンリリヌスで芋぀かったセキュリティ問題や 重倧な埌戻りに察する比范的小さい重芁な修正が含たれたす。

メゞャヌ安定版シリヌズのそれぞれのリリヌスは バヌゞョン番号の3番目を増加させ、最初の2぀の番号は同じ倀を保ちたす。

これは、開発/実隓的バヌゞョンのテストに協力するこずに興味が無く、最新 の安定したカヌネルを䜿いたいナヌザに掚奚するブランチです。

安定版ツリヌは”stable” チヌム <stable@vger.kernel.org> でメンテされおおり、 必芁に応じおリリヌスされたす。通垞のリリヌス期間は 2週間毎ですが、差 し迫った問題がなければもう少し長くなるこずもありたす。セキュリティ関 連の問題の堎合はこれに察しおだいたいの堎合、すぐにリリヌスがされたす。

カヌネルツリヌに入っおいる、 Everything you ever wanted to know about Linux -stable releases ファむルにはどのような皮 類の倉曎が -stable ツリヌに受け入れ可胜か、たたリリヌスプロセスがどう 動くかが蚘述されおいたす。

サブシステム毎のカヌネルツリヌ¶

それぞれのカヌネルサブシステムのメンテナ達は --- そしお倚くのカヌネル サブシステムの開発者達も --- 各自の最新の開発状況を゜ヌスリポゞトリに 公開しおいたす。そのため、自分ずは異なる領域のカヌネルで䜕が起きおいる かを他の人が芋られるようになっおいたす。開発が早く進んでいる領域では、 開発者は自身の投皿がどのサブシステムカヌネルツリヌを元にしおいるか質問 されるので、その投皿ずすでに進行䞭の他の䜜業ずの衝突が避けられたす。

倧郚分のこれらのリポゞトリは git ツリヌです。しかしその他の SCM や quilt シリヌズずしお公開されおいるパッチキュヌも䜿われおいたす。これら のサブシステムリポゞトリのアドレスは MAINTAINERS ファむルにリストされ おいたす。これらの倚くは https://git.kernel.org/ で参照するこずができた す。

提案されたパッチがこのようなサブシステムツリヌにコミットされる前に、メヌ リングリストで事前にレビュヌにかけられたす以䞋の察応するセクションを 参照。いく぀かのカヌネルサブシステムでは、このレビュヌは patchworkず いうツヌルによっお远跡されたす。Patchwork は web むンタヌフェむスによっ おパッチ投皿の衚瀺、パッチぞのコメント付けや改蚂などができ、そしおメン テナはパッチに察しお、レビュヌ䞭、受付枈み、拒吊ずいうようなマヌクを぀ けるこずができたす。倧郚分のこれらの patchwork のサむトは https://patchwork.kernel.org/ でリストされおいたす。

統合テストのための linux-next カヌネルツリヌ¶

サブシステムツリヌの曎新内容がメむンラむンツリヌにマヌゞされる 前に、それらは統合テストされる必芁がありたす。この目的のため、実質的に 党サブシステムツリヌからほが毎日プルされおできる特別なテスト甚のリポゞ トリが存圚したす-

このやり方によっお、linux-next は次のマヌゞ機䌚でどんなものがメむン ラむンにマヌゞされるか、おおたかな展望を提䟛したす。 linux-next の実行テストを行う冒険奜きなテスタヌは倧いに歓迎されたす。

バグレポヌト¶

メむンカヌネル゜ヌスディレクトリにあるファむル ‘Reporting issues’ は、カヌネルバグらしきものの報告の仕方、および、カヌネル開発者が問題を 远跡する際の手がかりずなる情報に぀いおの詳现を説明しおいたす。

バグレポヌトの管理¶

あなたのハッキングのスキルを蚓緎する最高の方法のひず぀に、他人がレポヌ トしたバグを修正するこずがありたす。あなたがカヌネルをより安定化させる こずに寄䞎するずいうこずだけでなく、あなたは 珟実の問題を修正するこずを 孊び、自分のスキルも匷化でき、たた他の開発者があなたの存圚に気が぀きた す。バグを修正するこずは、倚くの開発者の䞭から自分が功瞟をあげる最善の 道です、なぜなら倚くの人は他人のバグの修正に時間を浪費するこずを奜たな いからです。

すでにレポヌトされたバグの䜜業をするためには、興味のあるサブシステムを 芋぀け、そのサブシステムのバグの報告先 (倚くの堎合メヌリングリスト、 皀にバグトラッカヌ) を MAINTAINERS ファむルで調べおください。 そのアヌカむブで最近の報告を怜玢し、できそうなものに力を貞しおください。 https://bugzilla.kernel.org でバグ報告を調べようずする人もいるでしょう。 これは限られた䞀郚のサブシステムのバグ報告ず远跡に利甚されるずずもに、 ずりわけ、カヌネル党䜓に察するバグの登録先ずなっおいたす。

メヌリングリスト¶

䞊のいく぀かのドキュメントで述べおいたすが、コアカヌネル開発者の倧郚分 は Linux kernel メヌリングリストに参加しおいたす。このリストの登録/脱 退の方法に぀いおは以䞋を参照しおください-

このメヌリングリストのアヌカむブは web 䞊の倚数の堎所に存圚したす。こ れらのアヌカむブを探すにはサヌチ゚ンゞンを䜿いたしょう。䟋えば-

リストに投皿する前にすでにその話題がアヌカむブに存圚するかどうかを怜玢 するこずを是非やっおください。倚数の事がすでに詳现に枡っお議論されおお り、アヌカむブにのみ蚘録されおいたす。

倧郚分のカヌネルサブシステムも自分の個別の開発を実斜するメヌリングリス トを持っおいたす。個々のグルヌプがどんなリストを持っおいるかは、 MAINTAINERS ファむルにリストがありたすので参照しおください。

倚くのリストは kernel.org でホストされおいたす。これらの情報は以䞋にあ りたす -

メヌリングリストを䜿う堎合、良い行動習慣に埓うようにしたしょう。少し安っ ぜいが、以䞋の URL は䞊のリスト(や他のリスト)で䌚話する堎合のシンプル なガむドラむンを瀺しおいたす -

もし耇数の人があなたのメヌルに返事をした堎合、CC: で受ける人のリストは だいぶ倚くなるでしょう。正圓な理由がない限り、CC: リストから誰かを削陀 をしないように、たた、メヌリングリストのアドレスだけにリプラむするこず のないようにしたしょう。1぀は送信者から、もう1぀はリストからのように、 メヌルを2回受けるこずになっおもそれに慣れ、しゃれたメヌルヘッダヌを远 加しおこの状態を倉えようずしないように。人々はそのようなこずは奜みたせ ん。

今たでのメヌルでのやりずりずその間のあなたの発蚀はそのたた残し、 “John Kernelhacker wrote ...:” の行をあなたのリプラむの先頭行にしお、 メヌルの先頭でなく、各匕甚行の間にあなたの蚀いたいこずを远加するべきで す。

もしパッチをメヌルに付ける堎合は、 Submitting patches: the essential guide to getting your code into the kernel に提瀺されおいるように、そ れは プレヌンな可読テキストにするこずを忘れないようにしたしょう。カヌ ネル開発者は 添付や圧瞮したパッチを扱いたがりたせん。圌らはあなたのパッ チの行毎にコメントを入れたいので、そうするしかありたせん。あなたのメヌ ルプログラムが空癜やタブを圧瞮しないように確認したしょう。最初の良いテ ストずしおは、自分にメヌルを送っおみお、そのパッチを自分で圓おおみるこ ずです。もしそれがうたく行かないなら、あなたのメヌルプログラムを盎しお もらうか、正しく動くように倉えるべきです。

䜕をおいおも、他の賌読者に察する敬意を衚すこずを忘れないでください。

コミュニティず共に働くこず¶

カヌネルコミュニティのゎヌルは可胜なかぎり最高のカヌネルを提䟛するこず です。あなたがパッチを受け入れおもらうために投皿した堎合、それは、技術 的メリットだけがレビュヌされたす。その際、あなたは䜕を予想すべきでしょ うか?

  • 批刀

  • コメント

  • 倉曎の芁求

  • パッチの正圓性の蚌明芁求

  • 沈黙

思い出しおください、これはあなたのパッチをカヌネルに入れる話です。あな たは、あなたのパッチに察する批刀ずコメントを受け入れるべきで、それらを 技術的レベルで評䟡しお、パッチを再䜜成するか、なぜそれらの倉曎をすべき でないかを明確で簡朔な理由の説明を提䟛しおください。もし、あなたのパッ チに䜕も反応がない堎合、たたにはメヌルの山に埋もれお芋逃され、あなたの 投皿が忘れられおしたうこずもあるので、数日埅っお再床投皿しおください。

あなたがやるべきでないこずは?

  • 質問なしにあなたのパッチが受け入れられるず想像するこず

  • 守りに入るこず

  • コメントを無芖するこず

  • 芁求された倉曎を䜕もしないでパッチを出し盎すこず

可胜な限り最高の技術的解決を求めおいるコミュニティでは、パッチがどのく らい有益なのかに぀いおは垞に異なる意芋がありたす。あなたは協調的である べきですし、たた、あなたのアむディアをカヌネルに察しおうたく合わせるよ うにするこずが望たれおいたす。もしくは、最䜎限あなたのアむディアがそれ だけの䟡倀があるずすすんで蚌明するようにしなければなりたせん。 正しい解決に向かっお進もうずいう意志がある限り、間違うこずがあっおも蚱 容されるこずを忘れないでください。

あなたの最初のパッチに単に 1ダヌスもの修正を求めるリストの返答になるこ ずも普通のこずです。これはあなたのパッチが受け入れられないずいうこずで は ありたせん、そしおあなた自身に反察するこずを意味するのでも あ りたせん。単に自分のパッチに察しお指摘された問題を党お修正しお再送す れば良いのです。

カヌネルコミュニティず䌁業組織のちがい¶

カヌネルコミュニティは倧郚分の䌝統的な䌚瀟の開発環境ずは異ったやり方で 動いおいたす。以䞋は問題を避けるためにできるず良いこずのリストです。

あなたの提案する倉曎に぀いお蚀うずきのうたい蚀い方 -

  • “これは耇数の問題を解決したす”

  • “これは2000行のコヌドを削陀したす”

  • “以䞋のパッチは、私が蚀おうずしおいるこずを説明するものです”

  • “私はこれを5぀の異なるアヌキテクチャでテストしたのですが...”

  • “以䞋は䞀連の小さなパッチ矀ですが...”

  • “これは兞型的なマシンでの性胜を向䞊させたす...”

やめた方が良い悪い蚀い方 -

  • “このやり方で AIX/ptx/Solaris ではできたので、できるはずだ...”

  • “私はこれを20幎もの間やっおきた、だから...”

  • “これは私の䌚瀟が金儲けをするために必芁だ”

  • “これは我々の゚ンタヌプラむズ向け商品ラむンのためである”

  • “これは私が自分のアむディアを蚘述した、1000ペヌゞの蚭蚈資料である”

  • “私はこれに぀いお、6ケ月䜜業しおいる...”

  • “以䞋は ... に関する5000行のパッチです”

  • “私は珟圚のぐちゃぐちゃを党郚曞き盎した、それが以䞋です...”

  • “私は〆切がある、そのためこのパッチは今すぐ適甚される必芁がある”

カヌネルコミュニティが倧郚分の䌝統的な゜フトりェア゚ンゞニアリングの劎 働環境ず異なるもう䞀぀の点は、やりずりに顔を合わせないずいうこずです。 email ず irc を第䞀のコミュニケヌションの圢ずする䞀぀の利点は、性別や 民族の差別がないこずです。Linux カヌネルの職堎環境は女性や少数民族を受 容したす。なぜなら、email アドレスによっおのみあなたが認識されるからで す。 囜際的な偎面からも掻動領域を均等にするようにしたす。なぜならば、あなた は人の名前で性別を想像できないからです。ある男性が アンドレアずいう名 前で、女性の名前は パット かもしれたせん (蚳泚 Andrea は米囜では女性、 それ以倖(欧州など)では男性名ずしお䜿われるこずが倚い。同様に、Pat は Patricia (䞻に女性名)や Patrick (䞻に男性名)の略称)。 Linux カヌネルの掻動をしお、意芋を衚明したこずがある倧郚分の女性は、前 向きな経隓をもっおいたす。

蚀葉の壁は英語が埗意でない䞀郚の人には問題になりたす。メヌリングリスト の䞭で、きちんずアむディアを亀換するには、盞圓うたく英語を操れる必芁が あるこずもありたす。そのため、自分のメヌルを送る前に英語で意味が通じお いるかをチェックするこずをお薊めしたす。

倉曎を分割する¶

Linux カヌネルコミュニティは、䞀床に倧量のコヌドの塊を喜んで受容するこ ずはありたせん。倉曎は正確に説明される必芁があり、議論され、小さい、個 別の郚分に分割する必芁がありたす。これはこれたで倚くの䌚瀟がやり慣れお きたこずず党く正反察のこずです。あなたのプロポヌザルは、開発プロセスのず おも早い段階から玹介されるべきです。そうすれば あなたは自分のやっおい るこずにフィヌドバックを埗られたす。これは、コミュニティからみれば、あ なたが圌らず䞀緒にやっおいるように感じられ、単にあなたの提案する機胜の ゎミ捚お堎ずしお䜿っおいるのではない、ず感じられるでしょう。 しかし、䞀床に 50 もの email をメヌリングリストに送り぀けるようなこずは やっおはいけたせん、あなたのパッチ矀はい぀もどんな時でもそれよりは小さ くなければなりたせん。

パッチを分割する理由は以䞋 -

  1. 小さいパッチはあなたのパッチが適甚される芋蟌みを倧きくしたす、カヌ ネルの人達はパッチが正しいかどうかを確認する時間や劎力をかけないか らです。5行のパッチはメンテナがたった1秒芋るだけで適甚できたす。 しかし、500行のパッチは、正しいこずをレビュヌするのに数時間かかるか もしれたせん(時間はパッチのサむズなどにより指数関数に比䟋しおかかり たす)

    小さいパッチは䜕かあったずきにデバッグもずおも簡単になりたす。パッ チを1個1個取り陀くのは、ずおも倧きなパッチを圓おた埌に(か぀、䜕かお かしくなった埌で)解剖するのに比べればずおも簡単です。

  2. 小さいパッチを送るだけでなく、送るたえに、曞き盎しお、シンプルにす る(もしくは、単に順番を倉えるだけでも)こずも、ずおも重芁です。

以䞋はカヌネル開発者の Al Viro のたずえ話です -

“生埒の数孊の宿題を採点する先生のこずを考えおみおください、 先生は生埒が解に到達するたでの詊行錯誀を芋たいずは思わないでし ょう。先生は簡朔な最高の解を芋たいのです。良い生埒はこれを知っ おおり、そしお最終解の前の䞭間䜜業を提出するこずは決しおないの です

カヌネル開発でもこれは同じです。メンテナ達ずレビュヌア達は、 問題を解決する解の背埌になる思考プロセスを芋たいずは思いたせん。 圌らは単玔であざやかな解決方法を芋たいのです。”

あざやかな解を説明するのず、コミュニティず共に仕事をし、未解決の仕事を 議論するこずのバランスをキヌプするのは難しいかもしれたせん。ですから、 開発プロセスの早期段階で改善のためのフィヌドバックをもらうようにするの も良いですが、倉曎点を小さい郚分に分割しお党䜓ではただ完成しおいない仕 事を(郚分的に)取り蟌んでもらえるようにするこずも良いこずです。

たた、でき䞊がっおいないものや、”将来盎す” ようなパッチを、本流に含め おもらうように送っおも、それは受け付けられないこずを理解しおください。

あなたの倉曎を正圓化する¶

あなたのパッチを分割するのず同時に、なぜその倉曎を远加しなければならな いかを Linux コミュニティに知らせるこずはずおも重芁です。新機胜は必芁 性ず有甚性で正圓化されなければなりたせん。

あなたの倉曎を説明する¶

あなたのパッチを送付する堎合には、メヌルの䞭のテキストで䜕を蚀うかに぀ いお、特別に泚意を払っおください。この情報はパッチの ChangeLog に䜿わ れ、い぀も皆がみられるように保管されたす。これは次のような項目を含め、 パッチを完党に蚘述するべきです -

  • なぜ倉曎が必芁か

  • パッチ党䜓の蚭蚈アプロヌチ

  • 実装の詳现

  • テスト結果

これに぀いお党おがどのようにあるべきかに぀いおの詳现は、以䞋のドキュメ ントの ChangeLog セクションを芋おください -

“The Perfect Patch”

https://www.ozlabs.org/~akpm/stuff/tpp.txt

これらはどれも、実行するこずが時にはずおも困難です。これらの䟋を完璧に 実斜するには数幎かかるかもしれたせん。これは継続的な改善のプロセスであ り、倚くの忍耐ず決意を必芁ずするものです。でも諊めないで、実珟は可胜で す。倚数の人がすでにできおいたすし、圌らも最初はあなたず同じずころから スタヌトしたのですから。

Paolo Ciarrocchi に感謝、圌は圌の曞いた “Development Process” (https://lwn.net/Articles/94386/) セクションをこのテキストの原型にする こずを蚱可しおくれたした。Rundy Dunlap ず Gerrit Huizenga はメヌリング リストでやるべきこずずやっおはいけないこずのリストを提䟛しおくれたした。 以䞋の人々のレビュヌ、コメント、貢献に感謝。 Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael Kerrisk, ず Alex Shepard 圌らの支揎なしでは、このドキュメントはできなかったでしょう。

Maintainer: Greg Kroah-Hartman <greg@kroah.com>