3: 早い段階の計画
Linuxカーネル開発プロジェクトを計画する場合、ただちにスタートしてコーディングを開始したい誘惑に駆られることがあります。しかし、他の大きなプロジェクトと同様、コードの最初の1行を書き始める前に、成功のための十分な基礎を固めておくことが必要です。最初の計画やコミュニケーションに多少の時間を費やすことが、後で非常に大きな時間の節約につながります。
3.1: 問題の特定
一般のエンジニアリング・プロジェクトの場合と同様、カーネルの機能拡張を成功させるには、まず解決すべき問題を明確に定義することが必要です。この段階は、たとえば特定のハードウェアに対するドライバが必要な場合など、一部のケースでは非常に簡単です。しかし、そのようなケースを除けば、一般に真の問題と提案されたソリューションとを混同してしまいがちであり、そのような場合には困難に陥ります。
たとえば、以下のような例を考えてみます。数年前になりますが、Linuxのオーディオ系を担当していたある開発者が、システムの過大な遅延時間が原因で発生するドロップアウトやその他の副作用なしにアプリケーションを実行する方法を追求していました。彼らが到達した解はLinux Security Module (LSM)にフックを入れるカーネル・モジュールで、このモジュールは特定のアプリケーションに対しリアルタイム・スケジューラへのアクセスを許可するように設定するものでした。このモジュールが作成され、linux-kernel メーリングリストに送られましたが、ここで直ちに多くの問題が発生しました。
そのオーディオ系の開発者にとっては、このセキュリティ・モジュールは直面する問題解決に十分なものでした。しかし、カーネル・コミュニティ全体から見れば、これはLSMフレームワークの誤用であり、システムの安定度を損なう危険性があるものでした（すなわち、LSMは特定のプロセスに、他の方法では得られないような優先権を与えることを意図してはいません）。カーネル・コミュニティの希望する解は、短期的にはrlimitのメカニズムを介したリアルタイム・スケジューリングを用いるものであり、また長期的には遅延時間を短縮するための現在進行中の取り組みによるものでした。
しかし、オーディオ・コミュニティは彼らが作成した解を捨て去ることができず、代替案を受け入れることに難色を示しました。結果としての意見の不一致により、彼ら開発者はカーネル開発の全体プロセスに幻滅を感じることとなり、そのうちの1人があるオーディオ系のメーリングリストに以下の内容をポストしました。
非常に優秀なLinuxカーネル開発者は多いが、そのような開発者の声も、傲慢で愚かな群衆の大きな声にかき消されがちである。ユーザー要件についてこのような人々と話し合おうと努力することは時間の無駄である。彼らはあまりに「賢い」ため、弱者の声に対し耳を傾けない。
(http://lwn.net/Articles/131776/ ).
この状況の真実は、これとは異なります。すなわちカーネル開発者達にとっては、特定のモジュールに対する関心より、システムの安定度や長期的な保守、およびその問題に対する正しい解決策を見つけることに対する関心の方がはるかに強いのです。この話の教訓としては、特定の解に注目するのではなく、その問題点に注目すべきだということです。 また、コード作成に投資する前に、開発コミュニティとの間で検討を行うべきだということです。
このように、カーネル開発プロジェクトを計画する場合には、以下のような簡単な質問に対する回答を得ておくことが必要です。
- 真に解決が必要な問題は何か？
- この問題の影響を受けるユーザーは誰か？その解決策はどのユースケースに対応するのか？
- 現在、その問題に対処する上で、カーネルにどのような不足があるのか？
可能な解決策の検討を開始することに意味があるのは、これらの答が得られた後に限られます。
3.2: 早い時期からの議論
カーネル開発プロジェクトを計画する場合、その具体化に着手する前にコミュニティとの間で議論を行うことは非常に意味のあることです。早めのコミュニケーションは、様々な面で時間の節約とトラブルの回避に役立ちます。
- その問題はカーネルが既に対応しているが、自分がまだ理解していない可能性があります。Linuxカーネルは多数の機能を持つ大規模なものであり、その機能はすぐに分かるようなものではありません。カーネルの全機能が好ましい形で文書化されているとは限らず、また、よく見落とされることもあります。本文書の筆者自身も、既存のドライバと重複するドライバのポストを見たことがありますが、これはその作者が既存のドライバに気付かなかったことが原因です。「車輪」のような既存物を再発明するかのようなコードは単に無駄なだけでなく、メインライン・カーネルには決して受け入れられません。
- 提案された解にメインラインへのマージが認められないような要素が含まれている場合も考えられます。このような問題は、実際にコードを書く前に発見しておくことが望ましいものです。
- 他の開発者がその問題について既に検討を行っており、より優れた解のアイデアを持っているという場合も考えられます。その場合、その解の作成を好意的に支援してくれるかもしれません。
カーネル開発コミュニティの長年の経験から得られた明らかな教訓があります。それは、閉じられた環境で設計・開発されたカーネル・コードには必ずいくつかの問題が含まれており、その問題はコミュニティに対し公開されるまでは発見されない、ということです。これは極めて深刻な問題の場合もあり、カーネル・コミュニティの標準を満たすものになるまでに数ヶ月や数年を要する場合もあります。その例を以下にいくつか示します。
- Devicescapeネットワーク・スタックはシングルプロセッサ・システム用に設計され、実装されました。このコードはマルチプロセッサ・システム対応が行われるまで、メインラインへのマージは行えませんでした。改修のためのロック処理等をコード化するのは困難な仕事であり、その結果、現在mac80211と呼ばれているコードのマージは1年以上も遅れてしまいました。
- Reiser4 ファイルシステムには、中心的なカーネル開発者達の意見では、仮想ファイルシステム・レイヤで実現すべきだった多くの機能が含まれていました。また、ユーザーの操作に起因するデッドロック発生の可能性を認めない限り簡単には実装できないような機能も含まれていました。これらの問題の発見が遅れたため、またその一部の問題への対処が拒否されたこともあり、Reiser4はメインライン・カーネルにマージできないままになっています。
- AppArmorセキュリティ・モジュールは、仮想ファイルシステムの内部データ構造を利用していましたが、その方法は安全性や信頼性に欠けると考えられるものでした。その後、このコードには大幅な修正が行われてきましたが、依然としてメインラインにはマージされていません。
このような事例の場合、もしカーネル開発者達との間で早い時期からの議論が行われていれば、このような苦労や追加作業の多くは回避できた可能性があります。
3.3: 誰と話すか？
開発者がその計画の公開を決心した時、次の問題は「どこからスタートするか？」ということになります。その答は、適切なメーリングリストと適切なメンテナを見つけることです。メーリングリストについて最も適切なアプローチは、MAINTAINERSファイルで適切なポスト先を見つけることです。適切なサブシステム・メーリングリストがある場合、その関連するサブシステムの専門知識が豊富な開発者に出会える可能性が最も高く、またより充実した支援が得られる可能性があることから、linux-kernelにポストするよりもそのリストにポストした方が望ましいでしょう。
メンテナを見つけることは、これよりも少し難しい作業です。この場合もMAINTAINERSファイルからスタートします。ただし、このファイルは最新のものではない場合もあり、またすべてのサブシステムが掲載されているとは限りません。MAINTAINERSに記載されている人は、実際には現在その役割を果たしている人とは異なる場合があります。そのため、誰に連絡すべきかについて疑わしい場合に役立つ方法は、git（特に「git log」）を使うことで、これにより現在、誰がその対象サブシステムで活動しているかを調べることができます。誰がパッチの作成者か、またそのパッチに対し誰が「Signed-off-by（承認者）」の行を追加しているかを調べます。そのような人々が新規開発プロジェクトへの協力には最適です。 これらがうまく行かなかった場合、特定のコードに対応するメンテナを探すにはAndrew Mortonに相談するのも有効な方法です。
3.4: ポスティングの時期
可能な限り早い段階に計画をポストすることが有益です。解決する問題について記述し、またその具体化の方法についての計画があれば記述します。提供可能な情報はすべて提供することにより、そのプロジェクトに関する有用なインプットを開発コミュニティが提供しやすくなります。
この段階で発生する可能性のある最も思わしくない反応は、敵対的な反応ではなく、ほとんど、または全く反応がないことです。残念ながら (1)カーネル開発者は多忙な場合が多い、(2) 全体計画だけでその裏付けとなるコードをほとんど出さない（またはコードの見通しさえない）人が多い、(3) 他人がポストしたアイデアについてレビューを行ったりコメントしたりする義務は誰にもない、というのが実際のところです。コメント要求のポストに対しほとんどコメントが出なかった場合でも、そのプロジェクトに対する関心がないものとは考えないでください。また、残念ながら、出したアイデアに問題がないと仮定することもできません。このような状況での最善の行動は、コミュニティに対し自分のプロジェクトの状況を常に知らせておくことです。
3.5: 正式な承認を得ること
仕事が企業内で行われている場合（Linuxカーネル開発の多くは企業内で行われています）、自社の計画やコードを公開のメーリングリストにポストするには、当然のことですが、適切な権限を持つメンテナーの許可を得ることが必要です。GPL互換の使用許諾に基づくリリースが可能になっていないコードのポストは特に問題となる場合があります。カーネル開発プロジェクトのポストについて会社の経営者や法務担当の合意の時期が早ければ早いほど、すべての関係者が楽になります。
読者によっては、まだ正式にその存在を認めていない製品のためのカーネル開発について考えているかもしれません。事業主の計画を公開のメーリングリストで明らかにすることは不可能な場合があります。このような場合、その秘密主義が真に必要なものかどうかを検討する価値もあります。実際には開発計画を秘密にする必要性がない場合も多いからです。
当然ながら、会社として、開発プロセスの初期にはその計画を合法的に開示できない場合もあります。経験の深いカーネル開発者を持つ会社は、後で深刻なインテグレーション上の問題が発生することを避けられるために、オープンに議論を進めることを選択する場合もあります。そのような社内の専門家を持たない会社の場合、社外の開発者を雇い、機密保持契約を結んで計画のレビューを行わせることが最適な選択肢となる場合も多いでしょう。The Linux Foundationでは、このような時に役立つNDAプログラムを運用しており、その詳細は以下のサイトに紹介されています。
http://www.linuxfoundation.org/en/NDA_program
この種のレビューは、プロジェクトの開示なしに、後で重大な問題の発生を避けるのに有効です。
