FreedomHECレポート
FreedomHECは、『Linux Journal』誌の前編集長Don Marti氏の構想から生まれた。この2日間のミニカンファレンスは、WinHECの翌日に同じ場所、シアトルで始まった。
スポンサーの1つ、Pogo Linuxの協力で、シアトルの中心にある超高層ビルColumbia Centerに会場が設けられた。76階建てのこのビルはミシシッピ以西で最も高い建物で、最上階とすぐ下の階はColumbia Clubが占有している。FreedomHECは、最上階にあるColumbia Clubの部屋の1つを借りて行われ、参加者はすばらしい眺めを楽しむことができた。
1日目
初日の参加者は30名ほどだった。この日、最初に行われたのは、どんな話題で議論を行うか、という議論だった。Marti氏の司会で進められ、ほどなくこの日のスケジュールがまとまった。
まずは、優秀なLinuxカーネルメンテナ、Greg Kroah-Hartman氏がsysfsとudevについて語ることになった。彼の話は、/procファイルシステムとその歴史の説明で始まった。そこには、本来は/procにふさわしくないファイルまでが多数が保存され、これまでずっと混乱した状態にあった。
現在は、プロセスに関連しないファイルはすべて/procから追い出され、sysfsファイルシステムの/sysディレクトリに移動しつつある。/sysディレクトリ内のファイルは、理解するまでもないちっぽけなファイルだと思われている。理想的には、ここにあるファイルは1行だけ、しかも1つの値しか持たず、ASCII文字だけで記述されているべきだ。Kroah-Hartman氏は、この点を強調している。「1ファイルにつき値は1つ！ ほかのことは忘れても、これだけは忘れないでください」
Udevは、カーネルによるハードウェア詳細の公開を可能にする、柔軟な動的ハードウェア管理システムで、ユーザ空間のプログラムとの連携も容易である。また、Kroah-Hartman氏は、Pythonで書かれた「デバイスマネージャ」のGUIシステムのデモも実施していた。
続いて登場したのは、Open Source Development Lab（OSDL）に勤務し、これまた優秀なLinuxカーネル開発者であるRandy Dunlap氏だ。Dunlap氏は、Linuxカーネルの開発コミュニティとどのように協力していくべきか、という「Linuxソーシャルエンジニアリング」の話題を取り上げた。そこには一般的な協力以上のさまざまな要素が存在する。このコミュニティとの協力のしかたを理解していれば、Linuxカーネルに貢献するのも難しくないという。実際、Linuxドライバに関する協力のプロセスが、Windowsドライバに比べて難しいわけではない。ただ、プロセスが異なっているだけなのだ。
| |
| Greg Kroah-Hartman氏 ― クリックで拡大表示 |
昼食後は、Linuxカーネル用SCSIドライバのメンテナ、James Bottomley氏が、LinuxのSCSIについて説明し、そのデバイスドライバモデルがどのように動作するかを語った。Linuxは、幅広いSCSIドライバをサポートしている。SCSIドライバのバグの発生源の観点から、カーネルバグ、デバイスバグ、通信バグの3つの主なバグが取り上げられた。このうち最も始末が悪いのが、デバイス間通信に影響を及ぼす通信バグだ。たとえば、SCSIケーブルは、ただ踏むだけで、見た目に変わりはなくても信頼性が落ちる。これだけで誰にも真似できないバグを発生させることができるのだ。SCSIレイヤが通信の問題にどこまで対処できるかを試すために、彼が故意に劣化させたケーブル（たとえば、絶縁部分にわずかな切り込みを入れたもの、など）のコレクションは相当な量らしい。
次の話題は、ロケット、正確には、Linuxをロケット工学に利用するというものだった。オレゴン州、ポートランドのPortland State Universityを母体とするPortland State Aerospace Society（PSAS）に所属するSarah Bailey氏とJamey Sharp氏が話を進めた。ロケットを造って飛ばす人々は数多くいるが、ロケット用のオンボードフライトコンピュータを手がける技術者はわずかしかいない。PSASのロケット技術者は、そうした貴重な人々だ。PSASの目的は、「ナノサテライト（飲料缶サイズの超小型衛星）」を地球の周軌道にのせるためのロケットを開発することだ。ロケット自体の製造はそれほど大きな問題ではないが、最終的に安定した軌道飛行を実現できるだけの正確な航法および操舵装置を搭載するのが難しい。
直近のロケット打ち上げでは、首尾よく21,000フィート（6,400メートル）の高度まで到達したのだが、残念ながら着陸に問題があったそうだ。その高度での気温と気圧の低さが原因で、着陸用パラシュートを開くための点火剤が一部しか燃焼しなかったのだ。パラシュートは開かず、ロケットは時速560マイル（900km/h）以上の速度で地面に激突した。オープンソースソフトウェアを実行していた航法システムがその寸前まで発信を続けていたため、墜落地点を探索する必要がなかったのは、せめてもの救いだった。Bailey氏らは現場に急行し、ロケットの残骸を発見したそうだ。この先、PSASは新たなロケットの製造と打ち上げを予定している。詳細についてはPSASのWebサイトを参照していただきたい。
| |
| Randy Dunlap氏 ― クリックで拡大表示 |
1日目の最後には、Linuxカーネルでのドライバの採用に関してKroah-Hartman氏とのQ&Aセッションが行われた。カーネル開発の多くの領域にわたり、さまざまな質疑応答が繰り広げられた。その中で、Kroah-Hartman氏は、カーネル開発者は皆さんのドライバに関心を寄せています、と参加者に向かって明言し、次のように語った。「私はよく、『カーネル開発者は私の作ったドライバなんか欲しがらない。このドライバは年に数百台しか出荷されていないマイナー商品のものだから』という発言を聞きます。そんなときはいつもこう返答します。Linuxカーネルでは、1人か2人しかユーザを知らないようなハードウェアに対してもデバイスサポートを行っています。我々は、実際に皆さんのドライバを取り入れようとしているのです、と」
2日目
この日も、会場に集まったのは30数名だった。だが、前日にいた人の姿がなかったり、この日初めて見かける人もいた。FreedomHECの参加者は、2日間合わせて42名だったと思われる。前日と同様、議論したい話題を手短に話し合うところから始まった。
最初のセッションは、私が待ち焦がれていた、Kroah-Hartman氏による「Linuxのデバイスドライバを自作する」というものだった。彼の書いたドライバのソースコードをLinuxノートPCにインストールし、指示に従って作業を進めるという内容なので、実際には、「簡単なLinuxのデバイスドライバをコンパイルしながら学ぶ」というタイトルが適切だったかもしれない。
確かに我々はまったくコードを書かなかったが、対象とするドライバの難易度および実用性を少しずつ上げながら、ビルド、インストール、テストという手順を繰り返した。目標は、USB接続の温度プローブ用のドライバを完成させることだった。このドライバは、/sysディレクトリにファイルを作成し、そこから読み込みを行うことでUSB温度センサが返す温度の値を取得する。まずは、カーネルログに「Hello, world」と書き込むだけの単純なドライバに取り組んだ。次のドライバは、/sysにファイルを作成するものだった。続いて、USB温度センサを検出して初期化するドライバを、最後に、これらをすべてまとめたバージョンを手がけた。最終版のドライバは、直接的でわかりやすいコードで書かれていた。カーネルのデバイスドライバがどのように動作するかを学ぶことができる、非常に有意義なセッションだ。
自分たちのUSB温度センサのドライバを試す前に、該当するLinuxの正式なドライバ、ldusbを無効にしたのだが、Kroah-Hartman氏は、このldusbドライバについて簡単に説明してくれた。この小さなドライバ1つで4つのメーカーのデータ獲得デバイスをサポートできる優れものだという。各メーカーは、ほんの数行のコードを書き加えるだけで新しいデバイスをサポートできる、と喜んでいるそうだ。デバイスをLinuxに対応させるために多くの労力をかける必要がないのだ。そのほか、Kroah-Hartman氏は、Linuxドライバをデバッグするための簡単なテクニックも授けてくれた。
昼食後は、グラフィックハードウェアと今後のX11について、PSASのSharp氏が語ってくれた。Sharp氏はPSASのロケット技術者でもあるが、これまでのXlibの後継となるxcbライブラリに5年間携わった経験も持っている。
Xサーバは、グラフィックハードウェアについてあまりに多くのことを行い過ぎている、とSharp氏と説明する。歴史的に、グラフィックデバイスに対するLinuxカーネルのハードウェアサポートは十分ではなかった。そのため、Xの開発者たちは、Linuxカーネルのハードウェアサポートを向上させる代わりに、Xの内部からグラフィックハードウェアに対処していたのだ。今では、ハードウェアの管理をXの外側に移して、本来のLinuxカーネル内で処理するようになってきている。
X.orgは急激に勢いを取り戻しつつある。Xの構築、そしてXへの新しいデバイスの追加は、これまでになく容易だ。ハードウェア高速化の新たなライブラリが開発途上にあり、主要なLinuxディストリビューションでは、アイキャンディ（見る者を楽しませるデモ）の効果がもうすぐ確認できるだろう。また、Xの開発者は、ホットプラグシステムにも取り組んでいる。これが完成すれば、たとえば、立ち上げたノートPCにプロジェクタをつなげるだけで、自動検出が行われて「何も設定しなくても動作する」ようになるそうだ。
続いて登場したのはBottomley氏だった。彼はSCSIデバイスドライバの主任メンテナであると同時に、SteelEye Technologyという会社のCTO（最高技術責任者）でもある。今日はSCSIメンテナとしてではなく、CTOの立場で話をしたい、と述べた彼は、「展示会に行くときはCTOに、Linuxのカンファレンスに出るときはSCSIメンテナになるが、同じイベントで二役をこなすのは今回が初めて」と語った。話題は、「LinuxおよびWindowsが相手側の売り上げに貢献する理由」だった。
ほとんどすべての企業にはWindowsとLinuxの両方がある、とBottomley氏は指摘する。サーバにはLinuxが、デスクトップにはWindowsが使われているかもしれないし、研究部門ではUnixをベースにしながらも職員のスケジュール管理にはExchangeが使われていることもある。Bottomley氏は、WindowsとLinuxの両方をサポートしているサプライヤは、両者の混在する企業のサポートにおいて有利な立場にある、と語る。「企業は、自分たちの選択を尊重してくれるサプライヤを信頼します。一方的にサプライヤの都合を押しつけるだけの宣伝文句は、相手にされない傾向があります」
また彼は、Windows製品を提供することで、Linux製品の販売が伸びることがある、とも話している。企業は、Linuxベースのテクノロジを採用することに慎重な姿勢を取っているため、Windows版も用意しておくことで、最初から検討の対象外にされることを回避できる可能性があるという。「実際、Linux版からWindows版への切り替えが起こることは決してないのですが、そうした切り替えが可能だとわかってもらうことで、商談の成立に結びつくこともあるのです」
SteelEye Technologyは、LifeKeeper Data Replication（LKDR）という製品を販売しており、この製品にはLinux版とWindows版がある。当初、T3回線において、Linux版が最大帯域幅の90%の効率を発揮したのに対し、コードベースがまったく異なるWindows版では20%に過ぎなかった。Windows移植版のスループットを向上させるために、Bottomley氏は、Windows開発者とLinux開発者に共同で問題解決に当たらせたという。「APIどうしはまったく違っても、互いの技能は伝えることができます」と彼は語った。このWindows製品の改良にはLinux開発者の知識が役立ち、今ではWindows版でもT3回線の最大帯域幅帯域幅の90%の性能を出せるそうだ。
最後は、Kroah-Hartman氏との非公式なQ&Aセッションだった。Linus Torvalds氏のソース管理システムGitがカーネル開発に有効なのはなぜか、といった多くの質問が出た。
この日の締めくくりとして、Marti氏がFreedomHECの今後について簡単に語った。来年のFreedomHECはもっと大規模なものになることが期待される。今年のFreedomHECは、WinHECの少し前に企画されたばかりだったため、スケジュールの都合をつけて参加できた人はほとんどいなかったのだ。
1年の準備期間があれば、もっと早くFreedomHEC 2007開催の案内が出ることになるだろう。そうすれば、人々は前もってWinHECとFreedomHECの両方に参加できるように旅程を組むことができる。来年のFreedomHECについてはまだ何も決まっていないが、次回もWinHECの翌日に開かれることになるだろう。
FreedomHECでは多くのことを学び、すばらしい時間を過ごすことができた。また、著名なカーネル開発者の方々に会うこともできた。来年、WinHECに参加しようと考えている、あるいは、カーネル開発に関心があるのなら、ぜひFreedomHECへの参加も検討していただきたい。
NewsForge.com 原文
