SourceForge.JP: Open Source Software

2.6のパワーマネージメントを担当しているPatrick Mochelが書いている、内部構造に関する文書は多く無い。2003年オタワで開かれた、カーネルサミット03では、彼が話したしたACPI and power managementと題したセッションがあったので、少し探ってみる事にした。

ACPI and power management

このセションの最初の部分は、 Andrew Groverが担当して、ACPIの開発について話した。ACPIについてはここで詳細は解説しないが、Windowsでは実装されている、PCプラットフォームにおけるパワーマネジマント機構の実質的な業界標準である。

群衆の中の2、3人は異論を示したものの、Andrewによれば、ACPIは「かなりうまく行く」と説明した。それはハードウェアとルートの割込みを数えあげるために、使用されている。Andrewは、「全ての場合に必ずしもうまく行くとは限らない。」とも補足した。「バッテリーとそのパワーマネージメントについては、より一般的に働いている。しかしながら、ACPIは多くの困難な問題のごみ捨て場でもあるので、常にちょっとした混乱がある。標準スキームに入らないハードウェアがある場合、それを働かせるためには、ACPIに依存して取り残される。」と解説をした。

Patrick Mochelは、カーネル2.7のこのエリアで開発者が望むことを訊ねながら、パワーマネージメントとsysfsについて話した。Matthew Wilcoxは、起こりうる最良のことは、デバイス・モデルおよびsysfsの完全な除去になるだろうと述べた。ドライバがそれぞれそれを作成するところで、そのプレファレンスはそれ自身のもの、プライベートなファイルシステムといった「ファイルシステムの森」になるだろうから。しかしながらLinus Torvaldsは、このアプローチに関する問題点を指摘した。それは、ファイルシステム間のリンクに関する問題を無視している。Sysfsは、単一のファイルシステムであることによって、競合条件や他の問題なしでデバイス(または、他のオブジェクト)の間のリンクを扱うことができる、という内容だった。

Rusty Russellは、sysfsの中のモジュール・パラメータの表現に関して次のように尋ねた。「かぎの多くは今そこにある。新しいスタイルのモジュール・パラメータ宣言はsysfsのパミッション・フィールドを含んでいる。」そこで、Rusty とPatが、お互いに相手が、この機能をインプリメントするのを待っていた事が判明した。しかし、実際の所そのセションは、両者とも仕事をする申し出をせずに締めくくった。

パワーマネージメントに関する文書

このようにKernel Summit03のセッションからは、パワーマネジメントの実装に関する話題は、あまり得るものが無かった。

カーネル・ソースコードのほかに、という事では、この2.6の新しいパワーマネジメントに関する文書は、Patrick Mochelが書いたoverview.txtがあるほか、カーネル内のDocumentation/power以下のディレクトリにある幾つかのファイルと、前回紹介したswsuspのサイトぐらいにしか見当たらないので、1年前の古い文書ではあるが、今回から暫くの間、Mochelのoverview.txtを取り上げる事にした。

カーネル2.6における適正なパワーマネージメント・モデル

-- overview.txt --

我々はついに、健全なドライバ・モデルの基で、適正なパワーマネージメント・モデルを開発することができた。これは、モデルの構成とその使用方法の概要である。

次の２種類のタイプのパワーマネージメントが存在する。

• システム・パワーマネージメント

システム全体をロー・パワー・ステートにすることを含んでいる

• ランタイム・パワーマネージメント

デバイスを個々にサスペンドすることを含んでいる

PMコア（パワーマネジメント・コア）の中の２つタイプの間には、それほど多くは無いが、ちょっとだけオーバーラップもある。ランタイム・パワーマネージメントは完全にドライバ・モデル・コアによって扱われる。一方システム・パワーマネージメントは、PMコアによって扱われ、直ちにすべてのデバイスをサスペンドするためにはドライバ・モデル・コアと相互に作用する。

次回は、PMコアがサポートする2種類の機構のうち、「システム・パワーマネージメント」の定義を取り上げる。