SourceForge.JP: Open Source Software

以前の経緯については、その１とその２を参照されたい。

提案

7月19日、20日のカーネル・サミット開催の直前、17日にLKMLへのポストでPatrick Mochelが言った。

約1年前に私は、swsusp(suspend-to-disk)のコードに行ったcleanupの束をマージしようとして、結局挫折した。理由はいろいろあったが、いずれもこのときに適切だったとは言えないものだ。私は事態を収拾するため、コードを分岐させて、片方をpmdiskと呼んでcleanupとマージした。私は2つをマージするつもりだった。しかし状況は、最悪の事態へと展開していって、私はその面倒をみる時間が取れなかった。このままにしておけば、私の多くの努力が損害を受けたままで残されてしまう。

コードを分岐させたことは間違っていた。私はPavel Machekに対して、彼を軽視したことを謝罪する。ユーザは、suspend-to-diskの実装において、いまだに放置されたままである。

私は、少しだけ時間を割いて、Linusの最新のBKツリーに対して適用可能な、2つをマージする1セットのパッチを作った。全ての機能は失われていないはずだ。また、いままで累積してきた修正点は、以前の2つのものよりもよくなるだろう。このメールの後に、パッチの短い要約をつける。またパッチは、それ自体別の電子メールでポストする。私はパブリックにアクセスできるBKツリーを持っていないが、誰かがそれを望めば取り組もうと思う。

結局のところこれらのパッチは、カーネルからpmdiskを取り除き、swsuspコードをベースにしてcleanupする。その結果、これらは一つの非常に改善されたコードとなり、誰かが理解するのを助けると期待している。

swsuspコードも、それは小さいながらもパワーマネジメント・コアの残りに統合された。これは少しだけコードの重複を削減し、メイン・エントリ・ポイントを少しシンプルにする。今回の変更の主な利点は、swsusp実現のために/proc/acpi/sleepあるいは修正済のsys_reboot()システムコールに依存しないということである。それは/sys/power/stateに書くことで使用することができる。別の有意点は、マシンを常にシャットダウンするのではなく、プラットホーム(例えばACPI-4状態)の実際のLow Power状態を作用させることができるということである。

オタワでは文字通りドア出口にいる事ができるように、私は必要最小限のテストを行った。そして少なくとも1台のPentium-Mベースのラップトップ(Compaq Evo N620c)で、動作することを確認した。私は、x86-64アーキテクチャへのlow-levelの変更をポーティングする機会はなかった。それについては、Documentationディレクトリのテクニカル・ノートのためのもっと形式的な説明を書くとともに、TODOリストにも残しておく。

私は、このパッチに関する意見に興味を持っており、またそれらを試してみるようにすすめたい。来週、多くの人々がオタワに来るだろうが、多くののフィードバックがそこであることを期待している。

反応

早速このポストに応じて、コードが分岐するきっかけを作ったPavel Machekは、Patrick Mochelに感謝しパッチをチェックし始めた。また、swsusp2のパッチをまとめているNigel Cunninghamは、このマージが完全になるまで、パッチを提出するのを待とうと提案した。

Andrew Mortonも言った。

私は、mmカーネルに加えるべきBKツリーのリストに、PatrickのBK URLを加えよう。それは即ち、コミットするものがすべて-mmへ自動吸収することを意味している。したがって、私が使用しているのと異なるURLがある場合には、知らせて欲しい。Pavel Machekへ、Patrickやみんなは、好意を持ってコードに取り組み続けた。

カーネル・サミット

Patrick Mochelは、「Software suspend: 確実にサスペンドしてシステムを回復する前に何ができるか」と題したセッションを持った。

まずPatrickは、既存のsoftware suspendがほとんどのシステムで動作すると説明した。それは特に、彼が使うすべてのシステムで動作するため、残りの問題を扱うのは非常に難しい。Linusは、どれだけの人が実際にsoftware suspendを使用しているか尋ねたところ、ほんの数人が手を上げた。Linusはそれについて注意した。software suspendのすすめ方について不平が多いのにしては、実際にそれで仕事をする人数が十分ではなかったからだ。

残りの多くの問題は、デバイスドライバにある。まずドライバには、Suspendサポートを明示的に加えなければならない。そして初めてテストが十分にされていない状態になる。つまりドライバでのSuspendサポートは、「無し」から「低信頼性」に変わる。

ドライバ・インタフェイスがいくつかの仕事を必要とすることも挙げられた。ドライバに渡された値は一貫していない。またいくつかかのドライバは、より多くの情報を必要とする。特にカーネルが本当にシャットダウンされたか、異なるカーネルがブートしたかどうかを知る必要がある。デバイスの準備に必要なものは、2つのケースにおいて異なる。情報を加えるために(結局)ドライバAPIを変更するか、「システムの一貫性」を保持するために単にグローバル変数を加える意見もあった。グローバル変数は一般的に、short-term-hackとみなされるが、一旦導入されれば他の開発者は、それが無くならないかと心配する。

Software suspendは、後でシステムを回復することができる場合にだけ有用であるのだが、現在のリストア・コードは少し壊れ易いとみなされている。システムがダウンしている間にハードウェアが変更された場合、適切に戻って来ない場合がある。適切なアプローチは、サスペンドする全てのデバイスの"hot remove"に対するホットプラグ・システムの使用である。システム上で一旦それが立ち上がれば、新しいものとして全てを扱うべきでもある。

いくつかの開発者は、サスペンド時に作られたシステム・イメージで、上書きしてから始めるLinuxカーネルのブート過程が好きではない。恐らく、最小限のブートローダから直接回復する方がよいと誰かに言われたからだろう。しかしながら、そのようなことは起きない。システム・イメージを検索する前に必要になるかなりの量の複雑なセットアップがある。ソフトウェアRAIDセットアップはその一例である。特別目的用のブ−トローダからのディレクトリ・リストアを備えた、特許の問題もある。

Nigel Cunninghamは不運にも、サミットに参加できなかったが、次の議論では彼のswsusp2パッチが取り上げられた。swsusp2は大きなものなので、誰かが一連の小さなパッチに分けることができれば、それぞれは評価可能で、それが一旦終われば、少なくともいくつかの部分は、メインラインになり得る。

タスクの議論では、ユーザプロセスをカーネルプロセスの前に止められるように、プロセスを「冷凍する」過程は分離させる必要があると指摘した。ユーザページは、外部記憶に分けてフラッシュするか、あるいは全てまとめて「サスペンド・イメージ」として書くべきではないだろうか？後者の場合は、まとめて入出力できるので、サスペンドの前後の動作が速くなる。

残る難しい問題のうちの1つはビデオ状態の回復であるが、この議論の多くは午後遅くのビデオドライバ・セションまで延期された。（訳注：Linux Kernel Developers Summit 2004報告 (1)によるとXサーバのsuspendからの復帰について議論されたようだ）

その後

サミットの後でも、具体的なコードの修正点の議論がLKMLで行われた。Benjamin Herrenschmidtのように、新しい追加機能を実装しようとしている人々は、少しの間待たされることになった。8月5日に、状況を問い合わせたBenjaminに対して、Patrick Mochelは「Linusが2.6.8をリリースすれば、私はその間に生じるバグフィックスを含めて、彼とともに私のツリーをマージするよう努めるつもりである。」と答えた。

これについて、「うまく行けば我々は変わることができる。そして、どんな混乱もクリアできるだろう。」と、Pavel Machekも期待を寄せた。しかしながらこのマージするパッチは、2.6.8-rc2-mm1以降の-mmシリーズには含まれているが、現在リリース予定の2.6.9-rc2には入っていないので、依然として調整がすすめられていると思われる。

（2005年4月2日 スペルミスを訂正）