Ottawa Linux Symposium 4日目レポート
この日、私はまず、正午に始まる一般セッションの中から「NPTL安定化プロジェクト」と題するセッションを選んだ。発表者は、欧州企業BullのSebastien DecugisとTony Reixの2人である。
ライブラリの虫干し
両氏は、所属企業で行った14か月にわたるプロジェクトについて発表した。比較的新しいライブラリNative POSIX Thread Library（NPTL）を徹底的にテストしようというプロジェクトの報告である。プロジェクトで実行された適合テストは2000を超え、一つずつ、しかも2段階の手間をかけて実行していったのだという。
各テストの第1段階では、POSIX標準の規定を調べ、ライブラリ・ルーチンの動作状態と比較し、テストを作成する。
第2段階では、そのテスト・ケースを実行するためのコードを書き、実行し、結果を評価する。結果のログ・ファイルは300キロバイトに及ぶこともあり、当初は、ログを読むだけで2日もかかったという。
そこで、TSLogParserを利用したところ、作業はわずか15分に短縮したそうだ。結果は表形式で示され、生データが詰まった長大なログ・ファイルを読まなくても、正常個所と不正個所を詳細かつ容易に知ることができたという。
これまでに見つかったバグは、glibcに22個、カーネルに1つ。そして、POSIX標準自体にも6つ。これは、仕様が曖昧であったり、矛盾したりしている個所である。
インターネットは満員札止め
NPTLについての発表――実際には、ここに紹介したよりも遥かに詳細なものだった――の次は、慶應義塾大学の吉藤英明とUSAGIプロジェクトによる「LinuxはIPv6へ」と題する講演を聞いた。
1980年代半ばには既にIPv4のアドレス空間は満杯だったと、IPv6の歴史を振り返りつつ吉藤は語る。IPv4の持つアドレス空間の限界――40億を少し上回るアドレスが可能――を回避する道を探っていたIETF（Internet Engineering Task Force）はIPNGという概念を作り出した。すなわち、Internet Protocol: Next Generationである。これは、後にIPv6として知られることになる。
1995年12月にRFC 1883として仕様が公開され、IPv6が誕生する。
IPv6がIPv4を凌ぐ点は幾つかあるが、その一つは長さ、128ビットという長さである。単純計算すれば、アドレス空間に含まれるIPアドレスは340,282,366,920,938,463,463,374,607,431,768,211,456個（およそ3.403×1038、化学用語で言えば5.7×1014モル）。32ビットの現行IPアドレスは世界の人口よりも数が少なかったが、IPv6なら枯渇する心配はしなくてもよさそうだ。
さらに、IPSecというセキュリティ機能や移動性をも備え、ルーティング・アーキテクチャも単純化されている。したがって、IPv6では、IPアドレスが経路に制約されることはない。
LinuxカーネルがIPv6をサポートしたのは2.1開発ツリーからで、1996年のことである。このときは、まだ、モバイルIPv6にもIPSecにも対応していない。
2000年に、Linux IPv6の開発を目指して、Universal Playground for IPv6（USAGI）プロジェクトが発足し、IPSecをLinux IPv6実装に組み込んだ。当初は、FreeS/WANプロジェクトに基づいていた。
2003年9月、USAGIは、LinuxのIPv6サポートについてipv6ready.org認定プログラムのBasic試験に着手した。2005年2月、Linuxカーネル2.6.11rc-2がAdvanced試験に合格し、IPv6の認定を受けた。これ以降の各バージョンも認定試験に合格する必要があるが、問題はないと思われる。
吉藤が発表に使ったスライドは、まもなく、オンラインで公開される。
バグ報告者のバグ
今年の基調講演に登壇するのは、Red HatでカーネルとAGPドライバを担当するDave Jonesだ。そのJonesを紹介するのは、OLSの長い伝統に従って、昨年、基調講演を行ったAndrew Mortonである。
Jonesの基調講演の標題は、「より良いバグ報告とテストとツールを」。
Mortonの陽気な紹介は、Red Hatには世界に誇れる技術者が沢山いるのに、さらにDave Jonesを雇ったという話で始まった。
Jonesは1996年にカーネル開発チームに加わり、現在はカーネル・ソース・ツリーのAGPドライバの面倒を見ている。また、Red Hatカーネルを担当する中心的人物でもある。Red Hat Linuxが市場に占める割合は50％前後ないしはそれを超えるが、それがDave Jonesをしてカーネル・コミュニティにおける重鎮たらしめている。
カーネル2.5の開発ツリーが始まったときのことだ。Jonesはカーネル2.4から多くのバグ改修を取り込む作業を買って出た。しかし、そのパッチをいざ組み込もうとしたとき、それはもはや無用の長物となっていた。準備ができたときには、カーネル2.5のソース・ツリーは大きく変更されており、パッチをカーネル・ソース・コードに適用できなくなっていたのだ。
また、最近、大きな危機に見舞われたが、Red Hat経営陣の卓越した指導力により、電子メールの「最も暗い時」を切り抜けることができた。ここで、Mortonは、Linuxカーネル・メーリングリストへの投稿を読み上げた。それは、JonesをRed Hatから追い出そうという脅迫状だった。
Mortonに紹介されたJonesは、冒頭、昨年のOLSで基調講演を引き受けたとき（Jonesは参加者全員の前で指名されたのだった）、何について話すか全く思いつかなかったと述べた。しかし、マサチューセッツ州ウェストフォードに着いたときテーマを思いついたと言う。そして、1枚の写真をプロジェクタに載せた。写真には氷河が写り、遠くに人が見える。表題は「マサチューセッツ州ウェストフォード」。そこは、JonesがRed Hatのbugzillaバグ追跡システムで働き始めた場所である。
次いで、一番のお気に入りの話を披露した。
「君は、コンピュータ産業には向かないね」――15年前、私は計算機科学の先生にこう言われました。
そして、カーネル2.6.0から2.6.7まではほぼ毎月新バージョンがリリースされていたが、2.6.7以降3か月に1回にペースが落ちたことを指摘し、開発サイクルをもっと早める必要があると述べた。
ここで、Jonesは本題に入った。カーネルをアップグレードするとドライバが壊れることがよくあるが、それは十分なテストが行われていないためであると述べ、代表的事例として、カーネル2.6.11におけるALSAサウンド・ドライバの機能不全を挙げた。しかし、リリースごとにすべてのドライバをすべての条件でテストするのは困難だろうとJonesは言う。AGPドライバだけでも50種ものチップセットをサポートしており、ちょっとした変更が問題を引き起こし、カーネルがリリースされるまで見つからない可能性があるというのである。
各部門の担当者がすべてのパッチを丹念に読む時間がないため、パッチによっては十分なレビューを経ずにカーネルに適用されると、Jonesは告白した。
リリースの際、ストレス・テスト、ファズ・テスト、パフォーマンス・テストは実施されるが、縮退テスト、エラー・パス・テスト、コード・カバレージ・テストは、リリースごとに行われているわけではない。
さらに、カーネル開発のリリース候補段階で見つけられるはずの多くのバグが発見できていない。それは、カーネルがプレリリースされても、ほとんどのユーザは使わず、見せかけだけの安定版カーネルを待つからである。そして、多くの人がテスト・リリースを使っていたらもっと早く見つかったであろうバグを報告することになる。
次いで、話題をバグ報告と管理に移し、Red Hatがバグの追跡に使っているBugzillaを中心に長い時間をかけて語った。Jonesは、Bugzillaはバグ追跡のすべてではないが、同社の中では最善のものだと言う。
ある日のこと、カーネル・コードを見るのに疲れたJonesは、GNOMEソース・ツリー全体をgrepして、ありがちなバグを探してみた。すると、50ほども出てきた。そのすべてについてパッチを書いたのだが、その報告については考え込んでしまった。GNOMEのバグを見つけた場合、そのバグをパッチとともにbugzillaに登録することになっているが、それには長い時間がかかる。結局、誰かがJonesの代わりに処理してくれたのだった。
Jonesは、バグを報告する者の心理を理解することが重要だと指摘する。誰でも、自分が発見したバグが報告されたバグの中で最も重要なものだと考える。誰かが重要な問題を引き起こすバグに気がつき、別の人が他の重要な問題を引き起こすバグに気づいたとき、当事者にとってはどちらも重要な問題だが、バグを抱えているソフトウェアから見れば、いずれかのバグを優先しなければならない。だから、バグ・システムでユーザーが指定する優先度は役に立たない。誰もが自分の発見したバグに最高の優先度を与え、本来の目的を無視するからだ。Jonesは、ほとんどのバグ・システムでは優先度は単に無視されるだけだと言う。
中には、バグを報告する際に細工をする者もいる。出力を編集して、カーネルが汚染されていることを警告するカーネル・モジュールのローディング・メッセージを隠してしまうのだ。この情報がなければ、バグの解決など覚束ない。
バグを見つけたユーザーの多くは開発過程の上流に報告しようとせず、カーネルではなくディストリビューションに責任を求める。別のディストリビューションに乗り換えてバグを回避するユーザーもいるが、ほどなく、カーネルをアップグレードしたときに同じバグに遭遇することになる。
ヒット・エンド・ランを行う者もいる。バグを報告しても、そのバグを解決するための質問には回答しないのだ。やむなくバグは情報不足でクローズされるが、クローズされると、当のユーザーは再度オープンさせ、解決されていないのにクローズしたと腹を立てる。しかし、バグを解決するための情報収集には協力しないのである。
バグを報告する際、何の関係もない情報を長々と添付してくる者もいる。ときには、コンピュータを買った店や値段まで書き添えてくる。無用なログ出力を何千行も添付するのに、肝心の問題については役立たずの短い説明しかしない人もいるのだ。
中でも厄介なのは、カーネルの古いバージョンが持つバグを報告し、アップグレードしようとしない者である。
こうした気むずかしいバグ報告者は「のらくら者」だと、Jonesは言う。こうした人たちはバグを見つけると、あちこちいじり回すが、その結果は芳しくない。そのうちバグを改修した新バージョンがリリースされるが、それでも問題は解決しない。あちこちいじり回したツケが回ったのだ。そして、どれかのアップグレードで、たまたま、動き出したりする。
Jonesが思い描くBugzillaの将来バージョンは、相互に情報を交換する機能を持っている。あちこちにいろいろなBugzillaがあり、必要に応じて、バグを上流へあるいは下流へと回送するのだ。
なぜなら、多くのバグはディストリビュータに報告されるが、本来対応すべきカーネル・チームにまで届くことはなく、一方、何か所かに同時に報告されるバグもあるからだ。
Bugzillaと、Red Hatによるその実装の話を終える前に、Jonesは全体的な傾向について語った。
バイナリのみのカーネル・モジュールの使用はかなり少なくなり、週に数件あったバグの報告が、月に数件だけになった。しかし、バイナリのみのヘルパー――Linuxの下でWindowsドライバを使ってハードウェアを動かすためのドライバ・ラッパー――の使用は増えている。
Jonesは、バージョン2.0.30のカーネルに初めて参加したとき以来、時代は変わったと述懐する。カーネルは以前より遥かに複雑になり、学ぶのが難しくなった。かつてはカーネル開発に追いつくのは容易だったが、今ではコツを学びカーネルに馴れるには長い時間がかかるようになったという。
Jonesはvalgrindやgcc -DFORTIFY_SOURCEなどを利用してカーネルのバグを発見し除去する方法について述べた後、満員のフロアとの質疑応答に入った。
その中に、SETI@Homeのように、分散コンピューティング・モデルがバグの発見と解決に使えるだろうかという質問があった。Jonesは、実用的なソリューションにはならないだろうと答えた。バグを見つけたとしても、そのときはホスト・システムが動かなくなっているだろうから、調整用のサーバにバグを報告できないのだ。
Dave Jonesに会ったら、サルと宇宙船について尋ねてみよう。
基調講演の後、OLSの組織委員会から種々の発表があり、協賛団体にはその変わらぬサポートに対して、参加者には今年の催しが無事終了したことに対して謝意を表明した。
最後に、精力的なGreg Kroah-Hartmanを来年の基調講演者に指名して幕となった。
なぜLinuxを使うのか
onlamp.comに、今年のOLS第1日について、Andy Oramの評が載っている。私は、ここで、その評に対して異を唱えたい。Oramは、OpenOffice.orgのメモリ使用量に関する批判に対して、「それ自体に固有の価値があるからこそLinuxを使うのだと考えている参加者がいる。彼らは、人々が何かを行う際に使うアプリケーションのためのプラットフォームとしてLinuxを見ていない」と述べている。しかし、Ottawa Linux Symposiumはカーネル領域のカンファレンスであって、ユーザー領域の開発者のためのカンファレンスではない。彼らにとってこそ、Linuxは、多くの場合、固有の価値を持つものでしかないのだ。それは、まさに、Linuxはそれ自体が良いという、視野の狭い技術的見方の故である。オペレーティング・システム自体の開発ではなく、一般ユーザー向けにソフトウェアの実用を模索しているようなカンファレンスなら、同じオタワで開かれるDesktop Summitなどに行くべきである。同様のLinuxカンファレンスは、世界中で開催されている。
最後に、付言しておきたい。OLSは知識を共有する場である。手練れのカーネル開発者も、小さなパッチを1つ報告しただけの人々に混ざって会場を巡っている。群れることもなく、コミュニティの有名人を指さす者もいない。OLSは開発者とその関係者のカンファレンスであり、誰もが提供すべきものを持ち、まだ知らないことを学ぼうとしている。OLSは、あらまほしき姿のカンファレンスなのである。
7年間、このカンファレンスを適切に運営し適切な規模と参加しやすい日程（朝の8時半にセッションを始めるようなカンファレンスなど他にはない）を守ってきた運営関係者の努力に拍手を送りたい。そして、これからも続くことを願う。
96のセッションと公式イベントが組まれた今年のLinuxシンポジウムで、私は23のセッションに参加し、42ページの手書き資料を受け取った。今回の一連の記事で取り上げたのはそのうち15セッションである。紹介できたのはごく一部だけだが、お楽しみいただけただろうか。
原文
