SourceForge.JP: Open Source Software

まず最初に、2003年の8月から9月の間に、カーネル2.6リリースのパワーマネジメント機構の実装が２つに分岐したLKMLでの経緯について紹介する。この辺の事実関係は、パワーマネジメントの実装と同様に複雑であったのと、正式リリースでどうなるかが予測できなかったために、すぐにお伝えできなかった点はご容赦願いたい。

主な登場人物はPatrick MochelとPavel Machekである。Patrick Mochel は、新しいドライバ・モデルの導入と、それに伴うkobjectとsysfsの実装を担当していたが、現在は主にカーネル2.6以降の新しいパワーマネジメント機構を実装している。

Energy Starのロゴとともに省エネが叫ばれるようになって久しいが、DOSとの互換性や旧世代機構をサポートするBIOSを持つPCアーキテクチャにおいて、完全なパワーマネジメントをオペレーティングシステムが実装する事は難しい問題であった。例えばノートPCのバッテリ残容量に応じた機器制御や、状況に応じたスタンバイやサスペンド状態への移行とそこからの復帰を実現しなくてはならない。最近のマシンではCPUの動作周波数を制御したり、何箇所かのファンの制御も行なう。また、これは主にデバイスドライバの仕事になるが、接続する周辺機器に対する省エネ機構や、サスペンドとレジュームをサポートする必要もある。

カーネル2.6では、Patrick Mochel 提案の新しいドライバ・モデルを導入するとともに、カーネル2.4までは十分でなかった、このような全てのパワーマネジメントへの要求に応える事になっていた。この仕事が、カーネル・メンテナとしてのPatrick Mochel の役割でもある。

一方Pavel Machekは、swsusp(Software Suspend)のメンテナンスを行なってきた。swsuspはまさしく、サスペンド状態への移行とそこからの復帰を行なうソフトウェア（カーネルPatchとアプリケーション）である。元々カーネル2.2用に Gabor Kutiによって開発されたが、現在ではsourceforgeでPavel MachekやNigel Cunninghamらによってメンテナンスされ、カーネル2.4や2.6で動作するようになっている。

2003年の8月22日には、プレリリース版である2.6.0-test4がLinus Torvaldsによってリリースされたが、この-test4で初めて本格的に導入された、Patrick Mochelの新しいパワーマネジメント機構が事の発端だった。test4でのパワーマネジメント機構とインタフェイスの出来が悪く、2003年の8月9日にリリースされた2.6.0-test3までは動作していた、swsuspを始めとするパワーマネジメント関係の機能がうまく動かなくなったので、test4のリリース後はPavel Machekや他のメンバからLKMLに苦情が寄せられていたところであった。

Power Management Update

Patrick Mochelは8月30日に、「Power Management Update」と題した、次のようなメールをLKMLにポストした。メールには、test4に対するPatchの場所が明記されていて、また以下のようにtest4での実装の方向性を確信している様子が伺える。

2.6.0のパワーマネージメント変更の最初のpatchsetのリリースを発表して、私は嬉しい。（筆者注：Patrick Mochelの新しいパワーマネージメント機構が入ったtest4は、約一週間前にLinusによってリリースされていた。このメッセージはそれに対する、本人からの最初のPatchのポストを意味している）このリリースの目的は、それをLinusのもとへ送付する前に、皆にパワーマネージメントのコードを調査し、テストする機会を与えることである。

これらのPatchは、PM(Power Management)コア・コード、ドライバ・コアPMコードおよびソフトウェアサスペンドへの多くのクリーンアップとフィックスを含んでいる。全てのサスペンド状態(スタンバイ、suspend-to-ram と suspend-to-disk)が、低レベルのパワー・インタフェイスとしてACPIを使用する多くのPCで動作することを、私は確認した。しかしながらこれは、最小限度のプロセスが走っている状態でのVGAコンソールからという、制限付の機能である。

Patchはまた、test3およびtest4以前に成功させていたサスペンドの機能を、再現させるものである。以前の私の変更が引き起こした不便については、謝罪する。

このPatchでは、以前より多く「サスペンド/再開」をさせるわけでは無い。これらの実質的な恩恵と約束されたものは、より完全なパワーマネージメント・サブシステムと、システム全体をサスペンド・再開するための適切なフレームワークの開発である。それらについては、比較的急速に進展しているように見えるが、まだそれぞれの荒い面があるので、今のところは唯一の私の関心事である。

私の現在の関心事は次の通りである：

• プラットホーム・デバイスと、もっと一般的な1つ以上のクラスに属することがあるデバイス

  ある人にとっては、パワーマネジメント関係に見える場合もあるが、多くの場合はドライバ・モデルの問題だからである。

• ドライバ

  ドライバを急激に進化させるのは難しいが、常にパワーマネジメント機能を働かせなければならないという必要性があった。私は適切な動作を確認し、必要ならばメンテナに連絡すべき、多くのデバイスを持っている。しかし今のところは、IRQルーティングに関する多くの問題があるように見える。それを解決することは、より多くのシステムに作用することができるだろう。

• リリースがより多くのシステムに作用すること

  PMコードは伝統的に凝ったコードだったが、重大な問題にも遭わないで欲しいと望んでいる。多くのテストマシンや、自発的なテスタがいるので、できれば速く移行していくべきだと考えている。

• APM

  私は不運にも、APM問題の報告について調査する機会がなかった。しかし私は、APMを持っている古いラップトップを結局掘り出したと言うことができてうれしい。

私は、Patchやテストをダウンロードし、かつ私やLKMLに自発的に問題を報告してくれるような人々を激励する。PMが単に作動しないというだけでは、システムのために確実な、あるいはタイムリーな返答を保証できない。今後は、多くのシステムを調べていくので、より簡単になると思うので、我慢して欲しい。

Pavel Machekは、これに対して翌8/31に幾つかのコメントを返答したが、ほとんどが無視されてしまった。そしてPavel は、ついに次のようなメールをLKMLに出した。

Fix up power managment in 2.6

やあ皆さん。Patrickは誰とも議論しないで、2.6.0-test4のパワーマネジメントに＜クソッタレ＞をしてくれた。

• 彼はユーザーランド・インタフェイスを変更した。
• 彼は、パワーマネジメントを必要とするドライバをすべて変更する必要があるのと同じ方法で、カーネル内インタフェイスを変更した。また、彼はそれを台無しにした、ドライバは、もはやレジューム動作中に、割り込みを有効にも無効にするといった操作をすることができない。
• 彼は、＜わざと＞変更点をテストしなかった。また、suspend-to-diskとsuspend-to-ramの両方を壊した。彼の「クリーンアップ」は不必要で、明白にバギーである(彼はプロトタイプを変更したが、アセンブリ機能を変更しなかった)。そして彼は、非i386アーキテクチャを無視している。

不運にも、相違点は十分に大きく、一度に非常に多くのことをしてくれているので、修正することは事実上不可能である。この状態のパワーマネジメントにおいて、有用な事は何も無い。test3状態にツリーを戻すためには、添付のPatchを使って-Rで実行して欲しい。本来は、PatrickのPatchが受け入れられるべきではないので、これは賢明な方法ではない。Patrickのパワーマネジメント追加を除外するためにbitkeeperが利用できれば、その方がよいだろう。

Linus Torvalds

この＜クソッタレ＞が効いたのか、Linus Torvaldsがなだめに入った。

個人攻撃はしないで、単に話だけをしよう。このPatchに他の人が本能的な嫌悪感を持っているようではなく、またそれまでは議論もしていたので、これは個人的な摩擦に過ぎないね。お願いだからわざとねじまげずに、互いに問題点について話すようにして欲しいね。

Pavelは答えた。

不運にも、それは個人攻撃では無く、それは事実だ。Patrickでさえ、彼のtest4の変更が悪影響があったことを認めている。また、彼からは「公式謝罪」を受け取っている。

彼は単にコードを修正すればいいと思っている。しかし私は、コードが戻され、レビューされ、テストされた後で修復されることを望んでいる。現在の混乱を修正するための時間はあまり無い。

私は、ソフトウェア・サスペンドのメンテナとされているのに、そのコードに関する議論は見ていないし、以前のコードがマージされたかの確認ができていないというのは、おかしいのではないか。

Pavelの言うように、2.6.0-test4における変更の前に、PatrickがLKMLでテスト用リリースやレビューを行なった形跡は無く、またtest4とその後に出したPatchの出来も良くないようなので、Pavelがヘソを曲げたのも無理はない。この後の展開と、どのように事態が収集していったのかについては、次回に続く。