オタワLinuxシンポジウム：1日目
Corbet氏の講演は、Linuxカーネルの開発プロセスの概要を説明するところから始まった。現在、Linuxカーネルは2～3カ月のサイクルでリリースされているという。カーネル2.6.17.6が現行バージョンで、近々2.6.17.7がリリースされる。2.6.xと記されるバージョンはメジャーリリースを、2.6.x.yという表記はバグ修正に伴うリリースを表している。
カーネル2.7がリリースされる見通しはまだなく、すべてを作り換えるような大きな変更が生じて、カーネルツリーが不安定なものになるまでは登場しないだろう、とCorbet氏は話している。
今のところ、カーネル開発者たちはメジャーリリースの間隔を約8週間としている。最初の週では、いわゆるマージウィンドウにおいて新しい機能がカーネルに追加される。通常、この作業は数千ものカーネルパッチという形として現れる。Linus Torvalds氏がこれで十分と認めた時点でこのプロセスは終了し、マージウィンドウのクローズが宣言される。
続いて、カーネルはリリース候補モードに移り、安定化とバグ修正の作業が行われる。リリース候補（-rc）カーネルのリリースは一定期間ごとに行われ、名目上は8週目（普通は少し遅れる）までにメジャーリリース版がリリースされる。それ以降にカーネルに対して行われたバグ修正とパッチはすべて、2.6.x.yというバージョン番号でリリースされる。
このマージウィンドウのプロセスは1年前に開始され、その結果、安定したカーネルのリリースが以前よりも見込めるようになった、とCorbet氏は話している。新しい機能が何年も待ち状態になることなく短期間で登場し、各種ディストリビューションでもこれまでより現行に近いカーネルを採用するようになっている。
Corbet氏は、カーネルパッチ数の時間的推移のグラフを提示して、マージウィンドウを用いたリリースサイクルのおかげで、カーネルに適用されるパッチ数の変化がいくぶん直線的だったものから階段状になってきたことを示した。
ほとんどの人々はこの新しいリリースサイクルの優秀さを喜んでいる、と話しながらもCorbet氏はこの「ほとんど」という部分を強調する。新しい機能に重点を置き過ぎてカーネルの品質が低下しており、実際には発見された数以上のバグが残っている、という見解の人々がいるというのだ。
カーネルのバグのはっきりした数はわからない、とCorbet氏は話している。ユーザ数が増えるにつれ、バグ報告の件数も増えているそうだ。たとえバグの比率（コード1,000行あたりのバグ数）が低下しても、コードの大規模化はバグの増加につながる。
Corbet氏によると、修正されているバグの多くは、非常に古いバグだという。最近、修正されたセキュリティのバグ2件のうち、1つは1年前に、もう1つは3年前に作られたものだった。バグが減ってカーネルの不具合を1つのバグデータベースで集中管理できるようになるのが理想だが、現在はその途上にあるとCorbet氏は考えている。また彼は、バグの修正を行わないならバグトラッキングはあまり役に立たない、と指摘している。
カーネル開発者たちの手元にはバグ修正に必要なハードウェアがないことが多いため、バグ修正のプロセスでは手間をかけてテストを何度も繰り返さなければならないことがある。なかなか進まないこのプロセスにテストチームが音を上げ、カーネルにバグが残されることもあるという。
Corbet氏によると、もう1つの問題は、バグの修正に関心を示す企業がそのためのリソースを投入しない限り、バグの修正を指示する人物がいないことだという。また、カーネル開発者たちも自分の担当箇所を放っておくことを心残りに感じているようだ。
最初の段階でバグを作り込む可能性は減りつつある、とCorbet氏は述べている。より優れたAPIの登場と自動バグ検出ツールの利用によって、状況が改善されているのだ。Linuxカーネルのメジャーリリースでは機能の追加ではなくバグの修正に厳しい目を向けるべきだという声もある。また、カーネルのバグマスターという役割を設置しようという提案もある。この地位には資金を与える必要があるだろう、と彼は述べている。
今後のカーネル開発
続いてCorbet氏は、現行バージョンが2.6.12だった昨年からこれまでのカーネルの大きな変更を振り返った。2.6.12以降にリリースされたバージョンのなかでも、Corbet氏は、カーネル2.6.15のリリースが、Linuxカーネルに取り組むために最初の開発マシンをTorvalds氏が購入してから15年後にあたる2006年1月2日だったことに触れていた。
Linuxカーネルは15年の歴史があるが、この先5年間のロードマップが存在しない。Linuxカーネルには機能面での明確なスケジュールや今後実装される具体的な機能のリストさえ存在せず、どんな機能であっても確実な資金源なしには開発を進める手立てがない、とCorbet氏は語っている。その途上でどんなハードウェアが出現するのか、ユーザからどんな要望が出てくるのかは誰にもわからない。とはいえ、どんな未来が我々に予測できるかを考えることからカーネルの次期リリース版は生まれる。
カーネル2.6.18のマージウィンドウはクローズされており、来るべきリリース版には、新たなコアの時間サブシステム、エラー処理やカーネルロックの検証機能を含むシリアルATA用の大がかりなパッチセットなど、数々の変更が加えられるだろう、とCorbet氏は話している。このシリアルATAのためのパッチは、カーネル開発に役立つように設計されている。ロックはスレッドを分離しておくためのものだが、正しく実現するのは難しい、と彼は説明している。また、カーネル2.6.18ではdevfsが削除されるだろうと彼が述べると、会場からは拍手が起こった。
さらにCorbet氏の話題は、仮想化機能をカーネルに統合する際の課題へと移り、さまざまな仮想化プログラムに個別の管理を求めてはならず、それぞれが独自のパッチセットを持つことのないように、統一されたパッチセットによってカーネルに取り入れる必要がある、と述べている。また彼は、真の管理ツール群を獲得しつつあるSELinuxと、SELinuxの競合で最近Novellが獲得したAppArmorを取り上げ、カーネルのセキュリティの話題にも時間を割いていた。
充実した45分間の講演の最後に、Corbet氏はLinuxカーネルがGPL ｖ3に移行することはまずないだろう、と述べた。ライセンスの切り替えにはカーネル開発者全員の同意が必要になるが、彼らはまだ個別にコードのごく一部に著作権を保持しており、そのなかには他界した開発者もいるので、どうしようもないだろう、とのことだ。
なお、Corbet氏の講演で使われたスライドはこちらから入手できる。
完全に自動化されたテスト
この日の後半は、GoogleのMartin J. Bligh氏による「テスト作業の完全自動化」という講演に出席した。Bligh氏の話は、なぜテストを完全に自動化するのか、という問いかけで始まった。自動化されたテストが必要な理由は、テストは退屈な作業だから、というほど単純なものではない。2.6のカーネルツリーの新たな開発サイクルの場合、Linuxカーネルの変更比率は恐るべき数値になっている。今やLinuxは非常に広い範囲で使われ、バグレポートのための古い手法はもはや十分に機能していない。
かつてはLinuxカーネルがそれほど普及していなかったので、カーネル開発者はユーザからのフィードバックに十分対応できたのだが、そういう時代はもう終わった。人件費に比べてコンピュータの価格が下がっているため、自動テスト装置が姿を消すことはないだろう、とBligh氏は述べる。では、テストの自動化によって世界の平和と食糧不足は解決されるだろうか。もちろんそんなことはないが、カーネルのバグに対する部分的な解決策にはなる、とBligh氏は語っている。バグテストの自動化には、これまでよりもプログラマと回帰テストの数を増やす必要がある。
自動テストは上流で行われるため、リリース後ではなくてリリース前に行うことができるという。バグにさらされるユーザが減るほど、厄介な問題が起こることも少なくなる。カーネルの新しいコードに依存するほかの機能が存在しないうちにバグが見つかった場合、さらなる問題を起こすことなく修正されるまで、そのコードはカーネルツリーから除かれる。バグの発見は早いほど良いのだ、とBligh氏は説明する。
1日に2回、大がかりな自動テストがLinuxカーネルに対して行われている、とBligh氏は述べている。このテストシステムはPythonで書かれているが、彼はPythonが選ばれた理由を詳細に語った。テストシステムの出力結果が出席者に示され、ほかのプログラミング言語がなぜ適切でないかについても説明が行われた。
プログラミング言語としてのPythonがこのシステムの要件を満たす理由として、変更および管理が簡単、ライトオンリーではない、例外処理がある、必ずしも高速ではないが強力、習得が容易、多岐に渡るモジュールが利用できる、といった点をBligh氏は挙げている。
Perlはライトオンリーな言語であり、そのシェルを使えばすばらしいことができるが、自動テストの実装にはふさわしくない、というのがPerlに対するBligh氏の説明だった。彼は笑みを浮かべて、Perlシェルを使って可能なことは大いに尊重しているが、最初からシェルで自動テストを行う必要はない、と述べていた。
また、Pythonについては、特にインデンテーションの使い方が気に入っている、と語っていた。ほかの言語とは違って、コンピュータはPythonを人が読むのと同じ方法で解釈するため、結果としてバグが少なくなるという。
test.kernel.orgは以前よりも優れたものになっているが、そこで実現されていることは可能性の面から言えばまだごく一部に過ぎない、とBligh氏は語っている。また、カーネルのテストは、テスト内容を共有するためのオープンでプラグイン可能なクライアントによって、さらに改善されるだろう、とも述べている。さらに彼は、もっと上流でのテストを求めており、企業にもテストへの参加を要請している。
バグによる影響を被る前に、企業が自らコードをデバッグしたり、バグ修正を行うコミュニティのためにバグの追跡に協力するほうがコストを抑えられるのではないだろうか、とBligh氏は問いかけた。彼は、テストの自動化に対する活動の現状を氷山の一角にたとえ、テストツールのダウンロードとWikiサイトの閲覧から始めることで、この取り組みに関わってもらえるように出席者たちに勧めていた。
バッテリーの寿命
続くセッションで「LinuxノートPCのバッテリー寿命」という講演を行ったのは、Intelのオープンソース・テクノロジセンター（Open Source Technology Centre）に所属し、LinuxカーネルのACPIサブシステムのメンテナでもあるLen Brown氏だった。ノートPCは、その性質上、パワーマネジメント分野の技術革新を生みだす原動力になっている、と彼は述べている。
講演の前半では、まずノートPCが消費する電力の目安を測定する方法が話題として取り上げられた。最初の方法は、可能ならばノートPCからバッテリーを外した状態で交流電力計を使うというものである。この方法は100ドルで実施できるが、交流から直流への電力変換ができず、ほとんどのノートPCは交流、つまりは際限のない電源につながっていることを認識して、バッテリー使用時に使われる省電力機能を無効にしてしまうという問題がある。
2つ目の方法も基本的にはこれと同じだが、電力ブリックによって生じる電力損失を計算から除くために直流電力計を使う点が異なる。コストはかかるがある程度正確な方法として、ノートPC側のバッテリーリードの間に直流の入力システムを設置するやり方もある。
だが、最もシンプルな方法は、ノートPCが提供するバッテリー情報を利用することだ、と彼は指摘する。まずは、フル充電したバッテリーを残量がゼロになるまで使い切るのにかかる時間を計測する。次に、計測した時間をバッテリーのワット数と比較して消費電力を求める。たとえば、容量53ワット時のバッテリーを1時間で使い切ったとすると、このノートPCは消費電力53ワットで動作したことになる。また、2時間で使い切ったなら、消費電力は26.5ワット、というように求めればよい。
Brown氏は、自分が取り組んできたLinux Battery Life Tool KitというGPLライセンスのプログラムのリリースについても告知していた。ただし、このプログラムはベンチマーク評価を行うものではない、と強調していた。コードは、kernel.orgサイト内の彼のディレクトリから入手できる。
このテストプログラムが提供している最初のテストは、アイドリングのテストである。アイドリングは、ノートPCの非常に基本的な機能であり、キーボードのキーを押す合間にもアイドリングが行われているという。次のテストはWeb読み込みテストで、2分ごとに別のWebページを表示させるものだ。アイキャンディを使ったアイドリングテストのようなものであり、その結果にアイドリングとの違いは見られない、とBrown氏は述べている。
次はOpenOffice.orgを利用したテストだが、実行にはOpenOffice.orgのバージョン1.1.4が必要であり、その他のバージョンには対応していない。ほかにもMplayerによるDVD再生テストや、ソースコードのブラウジングとコンパイルからなるソフトウェア開発者向けの負荷テストがある。
彼のノートPC上で行われた多くのテストの実施例が提示された。ただし、別の環境で行った電力消費の測定結果も見せながら、結果はノートPCごとに異なっている、とBrown氏は述べていた。
これらの結果には、別のテスト環境で得られた消費電力とパフォーマンスの両方の数値が含まれていた。こうした統計のなかには、彼のデュアルコアCPUのノートPCで、コアの1つを無効にした場合と2つとも有効にした場合のそれぞれで計測されたパフォーマンスと消費電力の統計値や、回転数が5400rpmのハードディスクドライブと7200rpmのものとの比較もあった。
ハードディスクドライブの回転速度は、ソフトウェア開発のパフォーマンスには大きな影響を与えていたが、その他の場合には、回転速度が高くても目立った影響はなく、逆に電力消費の点で少しコストがかさむことになる。また、2つ目のコアを有効にした場合は、追加の電力はほとんどかからないが、パフォーマンスは著しく向上する。最も大きな差が出たのは液晶ディスプレイ（LCD）の明るさだった、とBrown氏は述べている。彼のノートPCでLCD設定を最も明るいものから最も暗いものに変えると、バッテリー寿命が25%以上も延びたという。
また、Windows XPとLinuxのそれぞれの消費電力を手持ちのノートPCで比較したところ、やはりノートPCごとにパフォーマンスの違いに差が見られたそうだ。彼のノートPCの場合、DVD再生時の消費電力はLinuxよりもWindowsのほうが低かったようだが、これは絶えずDVDの読み込みを行うMplayerとは違ってWinDVDがバッファリングを行っているからだ、とBrown氏は説明していた。
この日の締めくくりは、Intelによるレセプションだった。講演者はいなかったが、LinuxやオープンソースをテーマとしたIntel主催のエッセイコンテストの審査結果が発表された。デジタルデバイドの解消に関するエッセイで最優秀者となったDavid Hellier氏には、高性能ノートPCが、「私にはできる（I can）」というエッセイで次点を獲得した人にはiPodが、賞品として贈られた。
NewsForge.com 原文
