Develop and Download Open Source Software

今回は前回に続いて、2003年の8月から9月の間に、カーネル2.6リリースにおける、パワーマネジメントの実装が２つに分岐した経緯について取り上げる。

前回のあらすじ

２つのコードが実装されているという事は、新しいドライバモデルを緩やかに導入する目的においては、正しい選択のように見える。しかしメンテナンス性と、今後のカーネル進化において、パワーマネジメントが重要機能である事を考慮すると望ましくはない。

カーネル開発者達の古い議論では、カーネル2.6には新しいパワーマネジメント機構だけが「オフィシャルな」カーネル内機能として組み込まれて、カーネル2.6のリリースとともに移行するはずであった。しかしPatrick Mochelが開発していた新しいパワーマネジメント機構は、カーネル2.5シリーズでは実装の全貌が公開されることはなく、2.6正式リリースを控えた2003年8月の2.6.0-test4での新機能として、いきなり組み込まれた。この新しいパワーマネジメント機構の実装は不完全で、事前にテストや公開されていたものではなかったので、swsusp(Software Suspend)という従来からのパワーマネジメント機構をメンテナンスしているPavel Machekらが、LKMLでカミついたわけである。Pavelは罵声とともに、test4でのPatrick Mochelの仕事を打ち消すPatchを、LKMLにポストした。その後Linus Tobaldsも巻き込んで、様々な議論がされた。

３日間のバトルの後

議論が続く中、３日後の９月３日には、LKMLにPavel Machekから、swsuspの機能を取り戻すための何回目かになるPatchが、「swsusp: revert to 2.6.0-test3 state」というサブジェクトでポストされた。

このPatchは、既知のよい状態(Patrickがテストしていない変更を加える前)にswsuspを戻す。私は、それをコンパイルできるようにするため、swsusp.cとpower.cの両方にいくつかの変更を行わなった。

Patrickが返答した。

私は、あなたが感情を害していることを理解する。私は、あなたがメンテナンスしてきたコードを修正し、無意識ではあったが壊してしまった。しかしながら、それ以来変更中の未解決の問題を修正したと特に思うので、お返しとして、私のコードを故意に壊すことは、我々のどちらも役立たない。私はたくさん検討して、前回のPatch以降の問題点を修正した。（Patrickは8月30日に、いくつかの問題点に対応した妥協的なPatch(test4-pm1)をLKMLに出していた）

それに対する返信で、Pavelは「故意にコードを壊しているわけではない」と言い、別のPatchで応えた。このようにコードの実装に関しては、依然として平行線のままだった。全く新しいパワーマネジメント機構（PMコア）の実装を進めたいPatrickに対して、Pavel は従来実現していたswsuspの実現に必要な、software_suspend()インタフェイスの保持を主張した。

それに対して、Patrickは答えた。

いいえ、私は（Pavelがかつて実装した）software_suspend()を絶対に呼びたくないことを理解しなければならない。あなたは、swsuspに関する私の変更を受け入れない選択を行なった。したがって、我々はコードを分岐してはどうだろうか。この結果我々はカーネル内において、競合するsuspend-to-diskの実装を持つことになる。

あなたは、software_suspend()に到達するまでのインタフェイスを維持する事ができる。しかしそれを呼び出すために、私のコードのセマンティクスを変更しないで欲しい。また時には、swsuspにPMコアの呼出しセマンティクスを遵守するフックを付け足すことを選択してもよい。そのときには、同じインフラストラクチャを使用することができる。それにはpm_{suspend,resume}からswsusp_*へ呼出しを移す、最小のPatchを送ってくれればよい。

Brian Litzingerはそのような重要なコードが今頃分岐することを聞いて、「2.6の6は偶数なので安定版だと思っていた」と驚いた。

Pavelは答えた。

私はPatchが戻される事を望む。あまりに少ないテストで素早くコードが交換されたので、私はいまだにそれを望んでいる。これは今後私がPatchを受理しないことではない。実際のところ私のプランは、test5ではswsuspのtest3バージョンを戻し、次に我々のtest3が再び機能するまでドライバモデルとswsuspを修正し、その後であなたのPatchを受け入れることである。もちろんそれは、あなたの協力があって可能になる。

Patrickは答えた。

それは素晴らしい。自分のペースで自身のコードを使って好きな事を行ってくれ。しかしあなたは、あなたとともに仕事はしないという私の主張を理解しなかったと思う。私は、あなたがPatchを受け入れるまで、あるいはこれ以上の悪口を耐え忍ぶために、ぶらぶらしているつもりはない。私は次のAかBのいずれかを推奨する。

Aは、私の変更を認めて修正する事。また基本機能にNigel Cunningham（現実的にはPavel Machekの後を引き継いで、swsuspのメンテナンスを行なっている）が行なっているカーネル2.4での変更をマージするのを支援する事。

Bは、コードの分岐と、Nigelの変更点のマージを受け入れて、その後で2つのソース・ベースをマージする事。

Nigel が答えた。

私はカーネル2.4用のswsuspの1.1を完成していて、2.6に対する移植作業中である。今からどのように取り掛かるかわからないが、私はそれをマージさせたい。今後のためにもマージする価値があると信じている。それは、RAMの(最小ではなく)全てのイメージを保存する機能のサポート、highmemのサポート、スワップ・ファイル、エラー時にクリアにアボートするフル機能の非同期入出力、ユーザ・チューニングおよび、よいインタフェイスを持っている。また、広範囲なテストのために１年間かけている。私は、それが捨てられるのを見たくはないし、3番めのオプションも持ちたくない！

（筆者注：Nigel Cunninghamの活動の成果は、前回紹介したswsuspのページで参照する事ができる。Nigelの手による、３つのサスペンド機構のわかりやすい比較表があるので、ぜひとも参照されたい。）

Pavelは答えた。

見たところ、それはNigelにとっても都合がよさそうだ。いずれにしても、コードは書き直されるのだから、「壊れていない場合は、それを修正しないこと」等という常識は、もはや重要ではないし、Nigelにとっても良いことだ。しかし私はまだ、2.6.Xで、2つのソフトウェア・サスペンド機構を持つことは回避させたいと望んでいる。

終結

このスレッドは終わった。そして９月８日に、Linus Torvaldsによって、2.6.0-test5がリリースされた。test5では、パワーマネジメントについては、test4からは一点しか変更されてなかった。それは、それまで選択可能であった（といってもtest4では機能しなかった）CONFIG_SOFTWARE_SUSPEND(swsusp)のオプションが、メニューから選択できなくなっていた点である。

翌９日には、Patrick Mochelによって2.6.0-test5用の、新しいパワーマネジメントPatchが以下のようにアナウンスされた。

これは、次のラウンドのパワーマネージメントの更新である。2.6.0-test5用のPatchは以下から入手できる。

http://developer.osdl.org/~mochel/patches/test5-pm1/test5-pm1.diff.bz2

個別のchangesetのPatchはそのディレクトリに置いてある。

そこのchangesetsや以下にリストしたものは、私が先週記述したPatchをすべて累積的に含んでいる。このリリースからのハイライトを下記に示す：

• SMPとプリエンプションが有効にされた環境用に修正された suspend-to-diskサポート

Suspend-to-diskは、SMPが有効になったUPシステムで動作する。SMPシステムでではない。低いプライオリティだが、これはTODOリストに載っている。

• いくつかの小さなバグフィックス

• swsuspは2つの動作可能なツリーへと分岐させた

swsusp自体のコード・ベースは2.6.0-test3あたりの状態に戻された。「pmdisk」と呼ぶ新しいsuspend-to-diskの実装は、kernel/power/pmdisk.cとして作成されている。それらは、ほとんど同一のコードをベースに作成されているので、現在と同じ機能を提供する。私が今後、さらにクリーンナップしたコードを出すので、近いうちに変わっていくと思う。

pmdiskの実装では次のように、sysfsインタフェイス経由でアクセス可能である：

echo -n disk > /sys/power/state

swsuspは/proc/acpi/sleepのインタフェイス経由でアクセス可能なので、それはsysfsインタフェイスへswsuspを繋げる事ができる。また今後は、そんなことをするためのPatchが増えるだろう。

カーネルを構築する場合には、pmdiskに対する新しいconfigメニュー・オプションに注意すること。（筆者注：ここで初めて、CONFIG_PM_DISK(pmdisk)のカーネルオプションが生まれ、この版で復活したCONFIG_SOFTWARE_SUSPEND(swsusp)とともに、同じような機能のオプションとして同居することになった）

何人かの人々が経験しているランダム・クラッシュを修正するために、まだたくさんの成すべき事がある。私は、テストしている人が行ったことを認識し、PatchやPatchが実装している機能に関するどんなフィード・バックも評価しよう。

このPatchのコードに対してPavel Machekは、いくつかコメントを発したが、コードが分岐した事については何も言わなかった。

補足

Subodh Shrivastavaは尋ねた。「このPatchが、mmシリーズに対してリリースされる機会があるのだろうか？ちなみに私は、reiserfsファイルシステムでsuspend to diskを2.6.0-test4-mm6で試みたところ、ファイルシステムの損傷も無く、問題なく動作した。」

これを聞いて、Patrickは喜んで付け加えた。「Andrew Mortonは、mmシリーズのための最後のPatchとしてこれを拾い上げている。したがって、ほとんどは既にそのツリーに存在している。」運がよければ、残りのPatchでも彼は同じことをするだろう。そうでなければ私が、最新のmmカーネルの上にインクリメンタルにPatchをポストする。」

Subodhはさらにいくつかのテストの後、2.6.0-test5-mm1システムでのusbモデム(アルカテルSpeedtouch)で「suspend to disk」を試した時の問題点を報告した。

GregKHは、「PavelによるUSBコアのバグを修正するPatchがある。これを回避するためには、サスペンド前にusbcoreモジュールをアンロードするしかない。」と返答した。

以上が、2.6の正式リリース直前に起こった、パワーマネジメントの実装が２つに分岐した経緯である。２つの目的は同じだが、実装方法や品質、インタフェイス等が異なっている理由でもある。時間を追った各バージョンとPatchがサポートしていた状況を、以下の表にまとめた。

注：○＝動作する、△＝動作が怪しい、×＝動作しない、-＝実装されてないか選択できない

次回からはいよいよ、カーネル2.6のパワーマネジメント機能の中身について取り上げたい。