(Translation of http://www.kroah.com/log/linux/ols_2006_keynote.html)

MythLiesAndTruthsAboutTheLinuxKernel

OLS 2006 基調講演

OLSのオーガナイザのご厚意により、今年、閉幕基調講演を努める機会をいただいた。 以下は、わたしの講演のスライドおよびテキストである(というか、話すつもりだった内容のテキストである。実際には、たぶんちょっと違ったふうに聞こえただろう)。

この講演に直接リンクしたい場合はこのリンクを使用していただきたい。


Linuxカーネルに関する神話、嘘、そして真実

http://www.kroah.com/log/images/ols_2006_keynote_00.jpg

Linuxカーネルに関する神話、嘘、そして真実
Greg Kroah-Hartman
SuSE Labs / Novell

こんにちは。Daveに紹介いただいたGregです。OLS関係者から時間をいただき ましたので、みなさんにカーネルのことについてすこしお話ししたいと思います。 カーネルについてよく言われているいろんな嘘について話し、その嘘を暴いてみます。 あまり知られていないすこしばかりの真実に触れて、それから、なんども繰り返し 聞かされるいくつかの神話について考えてみましょう。

ここで神話といったのは、いくらかの真実を含んでいると信じられているけれ ども、よく調べてみると嘘っぱちだと分かるもののことです。Linuxカーネルの 「都市伝説」と呼ぶことにしましょう。

では、まず、ひじょうによくある神話で、ほんとうに頭にくるものです:

http://www.kroah.com/log/images/ols_2006_keynote_01.jpg

「わたしのお気に入りの天敵・・プラグ・アンド・プレイ・・はまだWindowsのレベルに達していない」

Linuxにかかわっているほとんどの人は、これまで似たようなことを聞いたことがあると思います。Linuxにはデバイスのサポートがどれだけ不足しているか、とか、あるいは、もっと多くのハードウェアのサポートが急務である、とか、すべての分野のドライバでどれだけ遅れていることか、とか。つい数ヶ月前、これとほとんど同じようなことがOSDLのだれかの発言としてわたしの住んでいる地域の新聞に載っていて、ほんとうに頭にきました。

これはまさしく神話です。ですからもう認識を改めて、こんな発言はしないでいただきたい。で、いったいだれがこんなことを言ったのでしょうか?:

http://www.kroah.com/log/images/ols_2006_keynote_02.jpg

「わたしのお気に入りの天敵・・プラグ・アンド・プレイ・・はまだWindowsのレベルに達していない」
(Novell Inc., CTO, Jeff Jaffe)

あちゃ。うちのCTOだ。

まあ、たぶんずっと前にこんなことを言ったのでしょう。たしかにLinuxが いろんなものをサポートできていなかった頃、「プラグ・アンド・プレイ」が ISAバスやなにかで重要だった頃:

http://www.kroah.com/log/images/ols_2006_keynote_03.jpg

「わたしのお気に入りの天敵・・プラグ・アンド・プレイ・・はまだWindowsのレベルに達していない」
( Novell Inc., CTO, Jeff Jaffe, 2006年4月3日)

あらら。

はいはい。どうやらもっと時間をかけてこの神話を暴いて、もはや真実ではないということを明らかにしないといけませんね。

では、最近のLinuxとデバイスに関する事実はどうなんでしょう。じつはこうです:

http://www.kroah.com/log/images/ols_2006_keynote_04.jpg

Linuxは、「素のままで」、これまでのどんなOSよりも多くのデバイスをサポートしている

そう、そのとおり、わたしたちは他のだれものよりもたくさんのものをサポートしています。そして、他のだれかがこれまで成し遂げたよりも多く。Linuxには、他のだれかがサポートしているとしても、それより先にサポートしてきたもののとても長いリストがあります。このリストに載っているのは、たとえば、

しかし、ハードウェア・サポート問題には、特定のドライバだけにとどまらない、ほんとうに大きな部分があります。それは、これです:

http://www.kroah.com/log/images/ols_2006_keynote_05.jpg

Linuxは、これまでのどんなOSよりも多くの違ったプロセッサをサポートしている

そう、わたしたちは数年前に、サポートしている異なるプロセッサのファミリーとタイプの数でNetBSDを抜きました。ほかの「主要な」どのオペレーティング・システムも、Linuxでのプラットフォーム・サポートにはるかにおよびません。今ではLinuxは、携帯電話から、ラジコンのヘリコプタ、デスクトップ、インターネット上のサーバ、そして世界中の上位500位までのスーパーコンピュータのうちの73%までに至るまで、あらゆるところで走っています。

さらに覚えておいてほしいのは、わたしたちがサポートしているいろいろなドライバのほとんどすべては、これらのさまざまなプラットフォームのどれでも動きます。これはコンピューティングの歴史において、かつてだれも成し遂げられなかったことです。このようにLinuxがどれだけ柔軟で、どれだけ強力かは、驚くべきというしかありません。

これまで作られた中で、もっともスケーラブルで、もっともサポートされたオペレーティング・システムを手にしているのです。わたしたちが成し遂げたものは、誰にも真似のできないものであり、抜きん出ていて、柔軟なものなので、「Linuxはハードウェアをサポートしていない」という神話を繰り返すひとたちについては、みんなでやめさせる必要があります。もはや真実ではないのですから。

さてJeff Jaffeに対して公平であるためにひとこと言っておくと、かれがこの発言をしたとき、NovellのCTOに就任したばかりで、Linuxについて最近の経験があまりなく、最新のディストロが提供しているデバイス・サポートの実態をよく知らなかったのです。

最新バージョンのFedora、SuSE、Ubuntu、その他を見てください。インストールはまったく造作ありません(他のオペレーティング・システムのインストールよりもうんと簡単です)。新しいデバイスを接続すれば、正しいドライバが自動的にロードされ、どこかにあるドライバ・ディスクを探し回る必要はありません。リブートする必要すらないまま、立ち上がって実行しています。

たとえば、最近新しいUSBプリンタを自分のラップトップに繋ぎましたが、ダイアログ・ボックスが出てきて、テスト・ページを印字したいかどうか尋ねてきました。それだけです。ほかになにもしていません。これが「プラグ・アンド・プレイ」でなければ、何だというのでしょう。

けれども、だれもかれもがLinuxの成功を無視してきたわけではありません。このカンファレンスの規模を見れば明らかです。多くの人がLinuxを見て、自分の用事に使いたいと思っていますが、しかし、カーネルまで下りていって、それがどういうふうに開発されているかを見始めると、すぐにわかることはまったく計画性が欠けているということです。

http://www.kroah.com/log/images/ols_2006_keynote_06.jpg

カーネルには明白な設計が存在していない。

これにはいつも多くの人がいらいらさせられています。「Linuxにはロードマップがないのに、どうやってプロダクトを作ればよいのか」とか、「だれも指示しないのに、どうやってものごとが進むのか」とかいったようなことです。

これまでだれもできていなかったことがうまくいっているという事実に基づけば、なんとかして現状にたどりついたし、正しいことをやっているにちがいないのだけれども、いったいどうやって?

伝統的に、ソフトウェアの作り方というのは、その要求仕様を決めて、分厚い仕様書を書き、それをレビューして、みんなの同意を得て、その仕様を実装し、それをテストして…という具合です。大学ではウォーターフォール法とか、繰り返しプロセス法、形式的証明手法といったようなソフトウェア工学手法を教えています。そして、エクストリーム・プログラミングとかトップダウン設計などの新しいプログラム作成法もあります。

で、Linuxのカーネルではどうやっているのかって?

http://www.kroah.com/log/images/ols_2006_keynote_07.jpg

「オープン・ソースの開発は、知られている管理理論のほとんどすべてに反している」
(ミシガン州立大学社会科学学部長Marietta Baba博士)

Baba博士は、ビジネスがどのように進められるかを研究していて、オープン・ソース・コミュニティがどのように運営されているか、とくにLinuxカーネルがどのように開発され、管理されているかを調査した後、このような結論に到達しました。

これまでなされたことのないなにかをわたしたちは創り出したのですから、他とはなにか違うことをやったことでできたというのは納得できそうです。では、それは何なのでしょうか。カーネルはどのように設計され、創造されたのか? Linusは去年、この問いに対して答えています。カーネルの設計プロセスを説明するように求められたとき、企業のひとたちに対して次のように言っています。

http://www.kroah.com/log/images/ols_2006_keynote_08.jpg

Linuxは進化論であって、インテリジェント・デザイン[*]ではない(Linus Torvalds)

これは、ほんとうに重要なポイントですが、多くの人は理解できていないようです。いや、実際は理解しているのだけれども、そう考えたくないだけなのではないかと思います。

Linuxのカーネルは、分厚い設計文書とか、機能要求書のようなものに基づいて開発されているのではありません。そのときの必要に応じて、時間とともに進化しているのです。最初に作り始められたとき、1種類のプロセッサしかサポートしていませんでした。べつにそれしか必要なかったからです。やがて2番目のアーキテクチャが追加され、その後、時間とともに次から次へと増えてきました。そして新しいアーキテクチャが追加されるたびに、開発者はその特定のアーキテクチャをサポートするのに必要なことだけがわかり、そのための作業をしてきたのです。最初から今日サポートしているさまざまなプロセッサ・タイプのための信じられないような柔軟さを考慮に入れて作業をしていたわけではありません。どんなものが必要になるかなんて分かっていなかったのですから。

カーネルが変化するのは、変化する必要があるときにだけ、必要のあるようにだけです。ちっぽけなプロセッサにスケール・ダウンされたのはその必要が出てきたときであり、別の人がスケール・アップすることを望んだときにはそうされました。そして、そういったことが起こる都度、そのコードがツリーに戻されてマージされ、他のみんながその変更を享受することができるようにされました。そのようなライセンスによってカーネルはリリースされているからです。

カンファレンスの初日にJonathanは、カーネルに起こっている膨大な変更率の話をしました。山のような新機能が、バグフィックスやその他クリーンアップとともに、とてつもない速度で追加されています。これはカーネルが、最初に作られてからほとんど15年たった今でも、いかに高速に進化を続けているかを示しています。ひじょうに順応性が高く、ほんの数年前のものとすらほとんど別物のように見えるようなものに変身してしまっています。そして、これこそLinuxがこれほど成功しており、成功し続けていくであろう大きな理由です。変化を抱擁し、変化を愛し、変化を歓迎するからなのです。

しかし、多くの人にとってひとつの「問題」は、このたえず進化している状態であるゆえに、「従来の」オペレーティング・システムが提供しているようなものをLinuxのカーネルは提供してくれないことにあります。カーネル内の安定したAPIのようなものです。みなさんもこれまでに聞いたことがあるはずです:

http://www.kroah.com/log/images/ols_2006_keynote_09.jpg

「ベンダーがドライバを書けるように、カーネルには安定したAPIが必要だ」

APIが何かご存知ない方のために説明すると、これはカーネルが仕事をするために自分の内部とどのように対話するかを記述したものです。特定の仕事をするために必要な特定の関数がどんなもので、その関数がどのように呼ばれるかといったことを記述しています。

Linuxでは、安定した内部APIといったものはありません。そのようなものを望むひともいるでしょうが、そんなものをもつのはばかげています。2年ほど前、カーネル開発者が集まって、なぜLinuxはカーネル内に安定したAPIをもたないのかについて書き、カーネル内の以下のファイルとして公開しました:

http://www.kroah.com/log/images/ols_2006_keynote_10.jpg

Documentation/stable_api_nonsense.txt

もし疑問があるなら、どうかこのファイルを読んでください。なぜLinuxは安定したカーネル内APIをもたないのか、そして、なぜ今後ももたないのか、について説明しています。これはすべて進化に関することに帰着します。カーネルが内部的にどのように動作するかを凍結ししまえば、必要なように進化できなくなってしまいます。

これがどのようになっているかの例を紹介します。LinuxのUSBのコードはすくなくとも3度書き直されています。時間がたつうちに、高速のデバイスのように当初は扱う必要のなかったものを扱うようにするために、そして、最初の設計の問題点を学んだからという理由によって、あるいはバグやセキュリティの問題に対処するために、書き直しを行ってきました。APIに変更を行う都度、そのAPIを使用するすべてのカーネル・ドライバを修正し、うまく動くようにしてきました。そして、もはや使われなくなったり、うまく動作しなくなった古い関数を削除しました。このため、いろいろなオペレーティング・システムをすべてテストしてみれば、現在のLinuxは最高速のUSBバス速度をもっています。ハードウェアの持つ速度を限度まで引き出し、そして、厄介なカーネル・ドライバに手を入れる必要なしに、ユーザ空間のプログラムからこれを利用できます。

一方、WindowsもUSBスタックをすくなくとも3度書き直しています。まだ見ていませんが、Vistaでひょっとしたら4度かもしれません。しかし、再作業をおこない、新しい関数を追加して、古い関数を修正する都度、かれらは古いAPI関数をそのまま維持しなければなりませんでした。安定したAPIという観点から、後方互換性を捨てるわけにはいかないというスタンスをとってきたためです。また、さまざまなドライバすべてのコードにアクセスできるわけではないため、修正できないという問題もありました。その結果、現在のWindowsのコアはAPI関数を3セットとも抱いています。削除できなかったからです。つまり、古い関数を維持していて、ずっとメモリ中に保持しておかなければならず、またこの余分な複雑なものをみんな扱うためにエンジニアリング時間がかかります。こうしたのはかれらのビジネス上の判断であり、それはけっこうですが、Linuxではそのような判断をせず、その結果、はるかに小さく、より安定していて、よりセキュアでいられるわけです。

そして、セキュアというのは、文字通りのことを言っています。何度もあることですが、あるセキュリティの問題がドライバのひとつ、あるいはカーネルのコア・パートのひとつで発見されると、カーネル開発者はそれを修正し、そして同じ問題をもつ他のすべてのドライバも治してしまうでしょう。すると、修正版がリリースされたときには、どのドライバのユーザもみんなもう安全です。他のオペレーティング・システムですべてのドライバを自分のツリーにもっていなかった場合、ひとつのセキュリティの問題を修正しても、個々のドライバを更新し、その問題を修正するかどうかは、個々の企業まかせになってしまいます。そして、みんながきちんと修正するようなことはめったに起こりません。ですから、デバイスを購入し、そのデバイスに同梱されていた古いドライバを使用しているひとは、安全ではありません。こういうことが最近よく起こっていて、安定なAPIをもつことがいかにユーザに実害を与えうるかをはっきりと示しています。元々の目標は開発者の助けとなるはずだったのに。

カーネルAPIの不安定性と、どのようにカーネルが開発されているか、について話した後によく起こることですが、こういう反応がよくあります:

http://www.kroah.com/log/images/ols_2006_keynote_11.jpg

「わたしのドライバはあやしげなハードウェア専用なので、メイン・カーネルに取り込まれるはずがない」

これはまったく事実ではありません。世界中探しても2人しかユーザのいないサブ・アーキテクチャをサポートしています。ひとりしかユーザのいないとわかっているドライバもあります。なにしろそのために作られたハードウェアが1台しかなかったのです。上の言葉は本当でないだけでなく、どんなもののドライバだってツリーに取り込みます。ほんとうにそうしたいと望んでいるのですから。

どんなに「あやしげ」なものであっても、もっと多くのドライバがほしいと思っています。なぜなら、その結果、コードの中にパターンを発見することができ、どうすればもっとうまくできるかがわかるからです。同じことをするドライバがいくつかあることがわかれば、たいていは、共通のコードを取り出し、コードの共有部分に移して、ここのドライバを小さくし、整理して見栄えよくするでしょう。また、ドライバ全体をいっしょにマージしたこともありますが、これはほとんど同じことをしていたからです。これの例のひとつは、カーネル内にあるUSBデータ取得ドライバです。世の中にはいろんなUSBデータ取得デバイスが山のようにありますが、すこし前にあるドイツの会社が自分たちのデバイスをサポートするドライバを送ってきました。ちょうどわたしが作業していた別の会社の別のドライバとほとんど同じことをしていることがわかりました。そこで、協力してふたつのドライバをマージし、現在ではより小さなカーネルを実現しています。このひとつのドライバは別のいくつかの会社のデバイス用としても動作することがわかり、自分たちのデバイスのIDをドライバに追加するだけで、新しいコードをまったく書くことなく、完全なLinuxサポートを実現することができました。元のドイツの会社は自分たちのデバイスが完全にサポートされたことで満足し、それはかれらの顧客が望んだことでもあり、さらに他の会社みんなも余分な作業をまったくする必要がなかったということでたいへん満足しました。みんなが得をしたのです。

カーネルにコードを取り込ませることになったときに、みんながわたしに尋ねる2番目のことは、独占物なのだから自分たちのコードをプライベートなままにしておきたい、ということです。

そこで、この問題に対する単純な回答はこうです:

http://www.kroah.com/log/images/ols_2006_keynote_12.jpg

非公開ソースのLinuxカーネル・モジュールは違法である。

それだけです。単純なことです。不幸にも、わたしはこの話題について何年にもわたり、IPを専門とする大勢の弁護士と話してきましたが、わたしと話しただれもがみんな同意したことは、今日、非公開ソースにしておけるLinuxカーネル・モジュールを作成できる方法はないということです。そんなものは、派生物とか、リンキングとか、その他もろもろといった楽しいことにより、単にGPLを侵害します。もう一回言いますが、とても単純なことです。

現在、弁護士が公開の場に出てきて、こういう発言をすることはありませんが、弁護士はそもそもこのような公的な声明を出すことが認められていないためです。しかし、弁護士を雇って、依頼人と弁護士という関係で話をすれば、この問題についてアドバイスしてくれるでしょう。

わたしは弁護士ではありませんし、なりたいとも思いませんので、これについてこれ以上尋ねないでください。お願いします。ライセンスの問題について法律的な疑問があれば、法律家と話をしてください。linux-kernelのような公的なメーリング・リスト上へもちださないでください。そこにはプログラマしかいませんから。公的な場でプログラマに法的な判断を求めることは、わたしたちに医療上のアドバイスを求めるのと同じです。まったく意味がありません。

しかし、Linuxのカーネル開発者がある日突然、非公開ソースのモジュールをカーネルに入れようと決心したら何が起こるでしょう? カーネルがどのように動作し、時間とともに進化していくかにどのように影響を与えるでしょうか?

このようなことが現実になったとき、まさにどんなことが起こるかについて掘り下げた思考実験をArjan van de Venが書いていたことがわかりました。

http://www.kroah.com/log/images/ols_2006_keynote_13.jpg

非公開ソースのLinuxカーネル・モジュールはうまく動かない。

Arjanの論文は、linux-kernelアーカイブを探せばすぐみつかりますが、NovellとかRed Hatとかの大手ディストロだけがどんな新しいハードウェアがでてきてもすぐサポートできるものの、非公開ソースの別のいろいろなドライバを動かなくするような変更が許されないため、次第に沈滞してしまう様子を描写しています。そして、非公開ソースのモジュールを二つ以上ロードしたなら、そのシステムのサポートはほとんど不可能になってしまいます。今日でもよく見られることですが、非公開ソースのモジュールを二つ以上システムにロードしたなら、なにかが動かなくなっても、その問題をサポートしたがる会社はないでしょう。

この論文ではさらに、GentooとかDebianとかのコミュニティ・ベースのディストロであっても、次第に時代遅れになり、どんな新しいハードウェア・プラットフォームでも動かなくなり、もう使い物にならないとしてどのユーザもいなくなってしまうであろうことを示しています。そして、結局、ほんの数年で全体のカーネル・プロジェクト自身が行き詰まり、もうなにも革新したり、変化したりできなくなってしまいます。

これはまさに背筋の凍るような話ですが、よくできています。この話題に興味があれば、この論文をごらんになってください。

しかし、これからお話したいけれども、ほとんどの人は気にしていない、非公開ソース・モジュール問題にかかわるもうひとつの観点があります。それは、こうです。

http://www.kroah.com/log/images/ols_2006_keynote_14.jpg

非公開ソースのLinuxカーネル・モジュールは倫理にもとっている。

忘れないでください。だれもLinuxを使えと強制していません。Linuxカーネル・モジュールを作りたくなければ、作らなければよいのです。しかし、お客のを要求があり、そうしようと判断したならば、Linuxカーネルのルールに従ってふるまわなければなりません。それだけの簡単な話です。

そして、Linuxカーネルのルールというのは、GPLです。これは単純なライセンスであり、標準的な著作権所有問題であり、多くの弁護士はこれを理解しています。

ある企業が「自分たちの知的財産を保護」する必要があるというなら、それはけっこうなことです。わたしも、他のカーネル開発者のだれもそのことについて異議はありません。しかし、同じように、あなたもカーネル開発者たちの知的財産権を尊重する必要があります。わたしたちはコードをGPLの下にリリースしており、このライセンスは、このコードを利用する場合にあなたにどんな権利があるかをひじょうに独特な形で明確に規定しています。わたしたちのコード本体にあなたのコードをリンクする場合、あなたにはカーネルのライセンスに従う義務があり、(配布する場合は)あなたのコードも同じライセンスの下でリリースしなければなりません。

Linuxのカーネル・コードを使い、そのヘッダ・ファイルを用いてあなたのコードとリンクあるいはビルドしたにもかかわらず、わたしたちコードの明文化されているライセンスに従わないならば、なんらかの理由であなたのコードの方がカーネルの残り全部よりも重要だと言っていることになります。ようするに、自分たちのコードをリリースしたすべてのカーネル開発者たちを愚弄していることになるのです。

だから忘れないでください。個々の企業がカーネルよりも重要だということはいえないのです。カーネル開発コミュニティが存在しなかったならば、そもそもその企業が使うカーネルそのものが存在しなかったのですから。Andrew Mortonが2年前ここに立って、非公開ソースのカーネル・モジュールを作成する企業を「蛭」と呼びました。まったくそのとおりだと思います。かれらのしていることは、倫理にもとるといわざるとしか言いようがありません。企業によっては、自分の非公開ソースコードを再配布する方法を規定するライセンスを回避しようとして、そのエンドユーザにビルドとリンクすることを強制していますが、これだと、そのエンドユーザが他のだれかにビルド済みのモジュールをあげたいと思ったら、GPLに違反してしまうことになります。こうした企業は、あきらかに倫理にもとるし、まちがっています。

幸いみなさんこのことを認識し始めており、大手ディストロはもはやこのようなことは受け入れていません。これは、今年はじめにNovellが公式に声明を出したものです:

http://www.kroah.com/log/images/ols_2006_keynote_15.jpg

Novellの公式見解:
カーネル・コミュニティのほとんどの開発者は非GPLカーネル・モジュールが自分たちの著作権を侵害してると考えている。
Novellはこの見解を尊重し、将来のプロダクトの一部として非GPLカーネル・モジュールを今後配布することはしない。
(2006年2月9日)

これが意味するのは、SuSE 10.1、そしてSLESおよびSLED 10は、その中にソース非公開のカーネルモジュールをまったく含まない、ということです。たいへんすばらしいことです。

Red Hatも似たようなテキストをカーネル・パッケージに入れていますが、公式の場でこのような声明はまだ出していません。

はい、気のめいるような話はここまで。企業が自分たちのコードをカーネル・ツリーに取り込ませる必要があると認識した後、すぐにひとつの大きな問題にぶちあたります。

http://www.kroah.com/log/images/ols_2006_keynote_16.jpg

コードをメイン・カーネル・ツリーに取り込ませるのは簡単ではない。

これはほんとうは一見したほどてごわいな問題ではありません。おぼえておいてください。変更の割合は、カーネルのリリースごとにおよそ6000ものさまざまなパッチという具合ですから、だれかが自分のコードをツリーに取り込ませているわけです。

では、どうやるか。さいわい、カーネル開発をどのように進めるかを知るために必要なあらゆることをカーネル開発者たちは書き留めています。それはすべてひとつのファイルにあります:

http://www.kroah.com/log/images/ols_2006_keynote_17.jpg

Documentation/HOWTO

カーネル開発をどうやればいいのかということについて疑問をもっているひとがいれば、どうかこのファイルを教えてあげてください。これまでだれかが尋ねたことのあるあらゆることについて答えてくれるか、あるいは、回答をみつけることのできる別のところを教えてくれます。

このファイルが教えてくれるのは、カーネルの開発の仕方、パッチの作り方、カーネル・ツリー内のうろつき方、パッチの送り先、いろんなカーネル・ツリーがどういったものか、といったことで、自分のコードを真剣に受取ってもらいたいなら、linux-kernelメーリング・リストで言ってはいけないことのリストまであります。

これは偉大なファイルです。もしなにか役に立たないと思ったら、そのファイルの著者に教えてあげてください。きっと付け足してくれるでしょう。自分たちのコードをカーネル・ツリーにどうやって取り込んでもらうかについてもっと学びたいマネージャや開発者がいたら、これこそ教えてあげるべきものです。

このHOWTOファイルが説明していることのひとつに、カーネル開発に関して手を貸してくれるさまざまなコミュニティのことがあります。カーネル開発の初心者であれば、こういうプロジェクトがあります:

http://www.kroah.com/log/images/ols_2006_keynote_18.jpg

Kernel Newbies

これはとてもすばらしいwikiで、いやな思いをすることもなく初歩的な質問をすることができる、たいへんすてきで、初心者向きのメーリング・リストであり、大勢のカーネル開発者にリアルタイムで質問することのできるIRCチャネルもあります。もしカーネルにとりかかったばかりなら、ぜひここへ行ってください。学習するのにとてもすばらしい場所です。

ぜひカーネル開発を始めたいけれども、なにをしてよいかわからないならば:

http://www.kroah.com/log/images/ols_2006_keynote_19.jpg

Kernel Janitors

Kernel Janitorsプロジェクトこそ、手を着ける適切なところです。コード・ベースに対してだれかがやってくれたらいいな、とカーネル開発者が思っている、いろんな「雑用」的な仕事の長いリストがあります。その中から適当に選んで、パッチの作り方、適切なパッチを送るためのEメール・クライアントの修正のしかた、の基本を学び、そうしていると、パッチが採用されるとあなたの名前がカーネルのchangelogに載ることになります。

カーネル開発を始めてみたいけれど、まだなにも特定の作業がみつかっていないひとには、このプロジェクトはほんとうにお勧めです。カーネル・ツリーの中を探しまわり、ちょっとした修正をすることになりますが、そうしているうちに、他のだれもやっていないけれども興味のあるなにかがたいていみつかり、次第にカーネルの一部を自分のものにし始めることができるでしょう。このグループについてはいくらお勧めしても十分とはいえません。

そして、例の巨大なメーリング・リストがあり、みんなが居ついています:

http://www.kroah.com/log/images/ols_2006_keynote_20.jpg

Lnux kernel mailing list

このリストには、一日に200通程度のメールが届き、それを読もうとしたらだれでも気が遠くなってしまうかもしれません。これには心得があります。たぶんAndrew Mortonを除いて、このメールを全部読んでいる人間はいません。残りのみんなは単にフィルターを利用して、自分に興味のあるものだけを読んでいるのです。興味深いコメントをするとわかっている何人かの開発者をみつけておいて、その人たちが応答しているスレッドだけを読むというのはいかがでしょう。あるいは、おもしろそうなサブジェクトを探すだけでもかまいません。しかし、全部を読もうとなど考えないでください。もし読めたとしても、他に何もできなくなりますから。

Linuxカーネル・メーリング・リストには、別の種類の問題があることもわかっています。このリスト上の開発者の応答が、ときにとても「きつい」と感じる人も多いかもしれません。コードをポストすると、まずかったあらゆる点についてダメを出されます。コメントするひとたちはふつうそのコード自身を批判するだけなのですが、たいていの人にとって、批判を受ける側に立つのはとてもつらいことでしょう。完璧と思えるものを提出しただけなのに、それがずたずたにされてしまうことになるのです。

これの大きな問題は、カーネル・コミュニティでコードをレビューするのは本当はほんの少数の人しかいないということです。コードをレビューするというのは困難で、むくわれず、てごわい仕事なのです。あっという間に、人を気むずかしく、無作法にしてしまいます。一週間ずっとレビューをしようとしたことがありますが、しまいにはこんなEメールを書いていました:

http://www.kroah.com/log/images/ols_2006_keynote_21.jpg

「わお、こんな小さなファイルなのに、どの関数もひとつとして正しくない。
おまけに、見たこともない、興味深いやり方でsysfsを濫用している。
こんなことができるとは思いもつかなかったよ。きみは二つの新記録を作ったね。
おめでとう」(Greg Kroah-Hartman, lkml, 2006年5月)

コードをレビューしてくれる他の人たちは、この時のわたしほどやさしくはありません。

この場を借りてChristoph HellwigとRandy Dunlapにお礼をいいたいと思います。ふたりはLinuxカーネル・メーリング・リストにおいてコードのレビューに多くの時間を割いてくれています。とくにChiristophは高い悪評を博しています。みんながかれのレビューが好きでないという意味で評判が悪いのです。しかし、他のカーネル開発者たちはほんとうはそうではないのです。なぜならChristophが正しいからです。もし、なにかが間違っているから直す必要があるとかれに言われたら、そうしてください。アドバイスを無視してはいけません。他のみんなはあなたがほんとうに自分のコードを言われたとおりに直すかどうかを見ているからです。カーネル・コミュニティにはもっと大勢のChristophたちが必要なのです。

もし、みんなが週に2、3時間かけて、メーリングリストに送られてきたパッチを手分けしてレビューできるなら、すばらしいことでしょう。たとえ、自分が優秀な開発者でないと思っていても、他の人のコードを読み、それについて質問してみてください。作者がその設計やコードを弁護することができなければ、それはなにかほんとうにまずいことがあるということです。

また、これはプログラミングやカーネルについてより深く学ぶ方法としてもすぐれています。楽器の演奏を学んでいる場合、自分で交響曲を作曲することから始めるひとはいません。他の人の楽譜を読み、どのようにものごとが作られ、動作し、相互作用するかを学ぶのに何年も費やします。そうした後にはじめて小さな曲から自分の音楽を書き始め、そして望むなら、もっと大作にとりかかります。プログラミングについても同じことがいえます。他人のコードを読んで理解することから多くのことを学ぶことができます。ポストされたものを研究し、なぜそのようになっているのかを質問し、気づいた問題点を指摘してみてください。これがまさしく、現在、カーネルがほんとうに必要としている作業なのです。

(上記の引用について脱線するかも)

オーケイ、でもカーネルについてなにか手助けしたいけど、プログラマじゃない場合はどうすればいい? なにができるでしょうか? 去年Dave Jonesがみんなに言ったことは、カーネルは、ばらばらに進んでいて、バグはたくさん発見され、終わりが見えない。多くのの人がこう反応しました:

http://www.kroah.com/log/images/ols_2006_keynote_22.jpg

「カーネルがリグレッション・テストスイートさえもってくれていたら、すべてはもっとうまくいくだろう」

さて、これは真実です。もしひとつの単純なテストスイートがあって、だれもがリリースのたびに実行して、なにもこわれておらず、すべてが正しいことを確認できるならすばらしいことです。しかし、不幸にしてそのようなテストスイートはまだありません。私たちがもっている現実のテストのセットは、みんなが自分のマシンでカーネルを実行し、うまく動作するかどうかを知らせてもらうことだけです。

ですから、これが、力になりたいと思っているけれども、プログラマではない人たちにお願いしたいことなのです。どうか、Linuxのカーネル・ツリーからの毎晩のスナップショットをあなたのマシンで走らせ、なにかおかしければ大声で文句を言ってください。だれも聞いてくれなければ、文句を繰り返してください。ほんとうにしつこくやってください。バグをこちらへ登録してください:

http://www.kroah.com/log/images/ols_2006_keynote_23.jpg

bugzilla.kernel.org

関係者はここにあるものを追いかけています。ときにはそうでないように思えるときがあるでしょうが、やっぱり辛抱強くお願いします。だれかがなにかについて文句を言い続けていれば、落ち着かないのでなんとか直そうと作業します。うるさいやつと思われることにめげないでください。すべてのカーネル開発者が一致協力し続けるには「いやなやつ」がもっと必要だからです。

そして、勇気があるならば、どうかAndrew Mortonの-mmカーネル・ツリーを走らせてください。これに含まれているのは、すべてのカーネル・メインテナの開発ツリーをひとつのかたまりにした不安定なものです。これは、最終的にどれをLinuxのカーネル・ツリーに入れるかを実証する場です。ですから、大勢にこのカーネルをテストしてもらって、Linusのツリーに入る前に、早いうちに問題を報告してもらうことが必要なのです。

だいじなデータの入ったマシンでAndrewのカーネルを実行することはお薦めしません。あんまり賢明なことではないでしょう。ですから、遊んでいるマシンがあるか、あるいは、たいへん立派なバックアップ・ポリシーをお持ちならば、Andrewのカーネルを走らせてみて、なにか問題があったら知らせてください。

最後に、結論として、みなさんに憶えておいていただきたい大事なものをお見せします。

http://www.kroah.com/log/images/ols_2006_keynote_24.jpg

Linuxは他のどれよりもたくさんのデバイスをサポートしています。

http://www.kroah.com/log/images/ols_2006_keynote_25.jpg

Linuxは進化であり、デザインではありません。

http://www.kroah.com/log/images/ols_2006_keynote_26.jpg

クローズドなソース・モジュールは違法です。

http://www.kroah.com/log/images/ols_2006_keynote_27.jpg

Documentation/HOWTO

http://www.kroah.com/log/images/ols_2006_keynote_28.jpg

レビューとテストのための手助けを必要としています。

http://www.kroah.com/log/images/ols_2006_keynote_29.jpg

全世界征服は着々と進んでいる。


posted Sun, 23 Jul 2006 in http://www.kroah.com/log/linux

[translated by Takao Ikoma]

MythLiesAndTruthsAboutTheLinuxKernel (last edited 2008-05-07 18:22:30 by localhost)