(57)【要約】【課題】  ＡＣＰＩマシン語テーブルの生成システムおよびその方法を提供する。【解決手段】  本発明の一実施形態は、ハードウェアデバイスのデバイス特有の記述子を記憶するデータベースを有するＡＣＰＩ互換システムを提供し、デバイス特有の記述子を使用して、ハードウェアデバイスのＡＣＰＩテーブルエントリを自律的に構築するＡＣＰＩエージェントを備える。また、本発明の他の実施形態は、ハードウェアデバイスのＡＣＰＩテーブルエントリを自律的に構築するＡＣＰＩ互換システム用の方法を提供し、ハードウェアデバイスに関連付けられたファームウェアから、該ハードウェアデバイスのデバイス特有の記述子を受け取ることと、ＡＣＰＩ互換システム上で実行されるＡＣＰＩエージェントが、デバイス特有の記述子を使用して、ハードウェアデバイスのＡＣＰＩテーブルエントリを自律的に構築することとを含む。【選択図】図７
2004355620.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェアデバイス（２０３）のデバイス特有の記述子を記憶するデータベース（２０６）と、
前記デバイス特有の記述子を使用して、前記ハードウェアデバイスのＡＣＰＩテーブルエントリ（２１１）を自律的に構築するように動作できるＡＣＰＩエージェント（２０７）と
を備えるＡＣＰＩ互換システム。
【請求項２】
前記ＡＣＰＩエージェントは、前記ＡＣＰＩテーブルエントリに含まれるＡＭＬコードを自律的に構築するように動作できる
請求項１に記載のＡＣＰＩ互換システム。
【請求項３】
前記ハードウェアデバイスに関連付けられたデバイス特有のファームウェア
をさらに備え、
該デバイス特有のファームウェアは、
前記デバイス特有の記述子
を含む
請求項１に記載のＡＣＰＩ互換システム。
【請求項４】
前記デバイス特有の記述子は、
前記ハードウェアデバイスのＡＭＬコード
を含む
請求項１に記載のＡＣＰＩ互換システム。
【請求項５】
ＡＣＰＩ互換オペレーティングシステム（２０４）
をさらに備え、
該オペレーティングシステムは、前記ＡＣＰＩテーブルエントリにアクセスして、前記ハードウェアデバイスの記述子を取得するように動作できる
請求項１に記載のＡＣＰＩ互換システム。
【請求項６】
ハードウェアデバイス（２０３）のＡＣＰＩテーブルエントリ（２１１）を自律的に構築するＡＣＰＩ互換システム（２００）用の方法であって、
前記ハードウェアデバイスに関連付けられたファームウェアから、該ハードウェアデバイスのデバイス特有の記述子を受け取ることと、
前記ＡＣＰＩ互換システム上で実行されるＡＣＰＩエージェント（２０７）が、前記デバイス特有の記述子を使用することであって、それによって、前記ハードウェアデバイスのＡＣＰＩテーブルエントリを自律的に構築する使用することと
を含むＡＣＰＩ互換システム用の方法。
【請求項７】
前記デバイス特有の記述子を、前記ＡＣＰＩエージェントによってアクセス可能なデータベース（２０６）に記憶すること
をさらに含む請求項６に記載のＡＣＰＩ互換システム用の方法。
【請求項８】
前記ＡＣＰＩエージェントは、前記ＡＣＰＩテーブルエントリに含まれるＡＭＬコードを構築する
請求項６に記載のＡＣＰＩ互換システム用の方法。
【請求項９】
前記ＡＣＰＩ互換システム上で実行されるＡＣＰＩ互換オペレーティングシステム（２０４）が、前記ＡＣＰＩテーブルエントリにアクセスすることであって、それによって、前記ハードウェアデバイスの記述を取得するアクセスすること、
をさらに含む請求項６に記載のＡＣＰＩ互換システム用の方法。
【請求項１０】
前記ＡＣＰＩエージェントが、
前記デバイス特有の記述子に関連付けられた少なくとも１つのフラグに少なくとも部分的に基づいて、前記ＡＣＰＩテーブルエントリに含める情報の型を決定すること
をさらに含む請求項６に記載のＡＣＰＩ互換システム用の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＡＣＰＩ（Advanced Configuration and Power Management Interface）マシン語テーブルの生成システムおよび生成方法に関する。
【背景技術】
【０００２】
オペレーティングシステム（ＯＳ）は、コンピュータシステムのコンポーネントである。
既存の技術では、多くのＯＳが知られており、例えば、ＤＯＳ、ＷＩＮＤＯＷＳ（登録商標）  ２０００、ＷＩＮＤＯＷＳ（登録商標）  ＮＴ、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ、および他の多くのものがある。
一般に、ＯＳは、コンピュータシステム上で実行されるソフトウェアに共通のプラットフォームを提供する。
例えば、２つの異なるプログラムは、それぞれが、それ自身の記憶フォーマットを有する場合があるので、ＯＳがないと、それらプログラムがそれぞれ作成したファイルを同じディスクに保存できない場合がある。
さらに、ＯＳは、通常、アプリケーションプログラムの外部でタスクを実行するツールも提供し、例えば、ファイルの削除およびファイルのディスクへのコピー、印刷、ならびにバッチファイルのコマンドの集まりの実行を行うツールがある。
【０００３】
ほとんどのコンピュータシステムにおいて、ＯＳは、単独では機能しない。
通常、ＯＳは、他のプログラムの協力だけでなく、コンピュータシステムの基本入出力システム（ＢＩＯＳ）およびソフトウェアドライバとの円滑な噛み合いに依存している。
ＢＩＯＳは、一般に、コンピュータシステムのハードウェア、プロセッサ、およびＯＳの間の仲介者として動作する。
デバイスドライバは、特殊化されたＢＩＯＳと類似している。
このようなドライバは、通常、ＯＳおよびＢＩＯＳからのコマンドを、例えばプリンタ、スキャナ、またはＣＤ−ＲＯＭドライブのような特定の１つのハードウェア用の命令に変換する。
【０００４】
ほとんどのコンピュータシステムのブートアッププロセスの期間中は、そのシステムのＢＩＯＳを実施するファームウェアが、最初に使用されて、ＯＳをディスクからシステムのランダムアクセスメモリ（ＲＡＭ）にロードするために十分にコンピュータのデバイスを初期化する。
すなわち、システムの読み出し専用メモリ（ＲＯＭ）に記憶されたＢＩＯＳブートコードが、最初に起動されて、システムのハードウェアデバイスの初期化を制御し、システムのＯＳのロードを開始する。
このようなブートアッププロセスの期間中、ＢＩＯＳは、コンピュータシステムのハードウェア資源を識別することができ、（例えば、パワーオンセルフテスト（ＰＯＳＴ（power on self-test））を実行することにより）中央処理装置（ＣＰＵ）、メモリなどの資源が適切に機能していることを確かめることができる。
ＯＳがロードされると、システムの制御は、このようなＯＳに渡される。
プラグアンドプレイシステムでは、資源アービトレータが、ＯＳに含まれて、そのシステムに接続された各デバイスにどの資源（例えば割り込みなど）を割り当てるかを決定することがある。
【０００５】
コンピュータシステムが発展して複雑になるに伴い、そのようなコンピュータシステムの電力消費を管理する技法が開発されてきた。
例えば、拡張電力管理（ＡＰＭ（Advanced Power Management））を実施するＢＩＯＳベースの電源管理技法が、いくつかのコンピュータシステムで使用されてきた。
このような従来のＡＰＭ技法によると、ＯＳは、ＡＰＭが実施されていることを知らない。
ＡＰＭが引き起こした問題は、ＯＳが引き起こしたようにユーザには見えるので、多くのＯＳ開発者は、ＯＳによる指示を受ける電力管理技法が実施される方を好む。
したがって、最近になって、拡張コンフィギュレーション／電源管理インターフェース（「ＡＣＰＩ」（Advanced Configuration and Power Management Interface））として知られているインターフェース仕様が、ＯＳ指示型の電源管理（ＯＳＰＭ（OS-directed power management））およびコンフィギュレーション用に開発された。
【０００６】
ＡＣＰＩは、COMPAQ Computer Corporation、INTEL Corporation、MICROSOFT CORPORATION、PHOENIX Technologies Ltd.、およびTOSHIBA Corporationによって共同開発され、一般にリリースされたオープンの業界仕様である。
ＡＣＰＩ仕様は、ＯＳ指示型のコンフィギュレーションおよび電源管理用の業界標準インターフェースを、パーソナルコンピュータ（ＰＣ）、ラップトップ、デスクトップ、およびサーバのようなコンピュータシステム上に確立するために開発された。
ＡＣＰＩは、ＯＳ指示型のコンフィギュレーションおよび電源管理（ＯＳＰＭ）の重要な要素である。
一般に、ＯＳＰＭは、電源（およびシステム）管理のモデルであり、このモデルでは、ＯＳが、中心的役割を果たし、グローバル情報を使用して、目下のタスク用にシステムの挙動を最適化する。
ＡＣＰＩは、既存の技術における既知の発展した標準であり、ＡＣＰＩの現在の版は、非特許文献１，２［「Advanced Configuration and Power Interface Specification, Revision 2.0 Errata, Errata document」改訂版１．５（２００１年４月１３日）および「Advanced Configuration and Power Interface Specification」改訂版２．０ａ（２００２年３月３１日）］に、より詳細に記述されている。
これらの開示は、参照により本明細書に援用される。
ＡＣＰＩ仕様は、ＯＳソフトウェア、ハードウェア、およびＢＩＯＳソフトウェアの間のインターフェースを含むＡＣＰＩインターフェースを定義する。
さらに、この仕様は、これらのインターフェースの意味も定義する。
【０００７】
ＡＣＰＩは、電源管理ＢＩＯＳコード（ＡＰＭ）アプリケーションプログラミングインターフェース、マルチプロセッサ仕様（ＭＰＳ（Multiprocessor Specification））テーブルなどの既存の集まりを明確に定義された電源管理およびコンフィギュレーションのインターフェース仕様に発展させる。
ＡＣＰＩは、既存（レガシー）のハードウェアからＡＣＰＩハードウェアに系統的に移行するための手段を提供し、ＡＣＰＩによって、ＡＣＰＩおよびレガシーメカニズムの双方が、単一のマシンに存在して、必要に応じて使用されることが可能になる。
【０００８】
したがって、ＡＣＰＩは、コンピュータシステムの電源管理および資源管理のより多くの制御をＯＳに与えることができる拡張可能な手段を定義する。
例えば、ＡＣＰＩは、ＯＳがシステムのハードウェア資源（例えばマザーボードデバイス）の特性を操作できる、ハードウェアとソフトウェアとのインターフェースを定義する。
この技術は、少なくとも次の２つの点で従来のＢＩＯＳベースの技術と異なる。
すなわち、
（ｉ）ＢＩＯＳサポートコードが、プラットフォームの固有のアセンブリ言語ではなく、本明細書でさらに解説するように、ｐコードと呼ばれるＡＣＰＩマシン語（「ＡＭＬ（ACPI Machine Language）」）で記述されること、および、
（ｉｉ）ＢＩＯＳサポートコードが、電源管理または資源管理のポリシーまたはタイムアウトを決定しないこと、
の２つの点で異なる。
逆に、これらのポリシーは、ＯＳによって決定される。
【０００９】
ＡＣＰＩハードウェアインターフェースは、少なくとも次の２つのカテゴリの機能をＯＳに提供する。
すなわち、
（ｉ）システム制御割り込み（「ＳＣＩ（System Control Interrupt）」）として知られている通常割り込みを使用したシステム制御イベントの制御／検出、および、
（ｉｉ）システム電源状態の制御、
の２つのカテゴリの機能を提供する。
ハードウェアインターフェースに対するプラットフォームのサポートの詳細は、システムＢＩＯＳ内の明確に定義されたテーブル（「ＡＣＰＩテーブル」と呼ばれる）の組に設けられる。
【００１０】
ＡＭＬは、ＡＣＰＩ互換ＯＳによってサポートされる仮想マシン用の擬似コードであり、そこには、ＡＣＰＩ制御メソッド（以下にさらに説明する）が記述されている。
すなわち、ＡＭＬは、ＯＳドライバによって解釈される擬似コードアセンブリ言語である。
２００２年３月３１日に発行された「Advanced Configuration and Power Interface Specification」改訂版２．０ａ（非特許文献２）の第１７章には、ＡＳＬのリファレンスが記述されている。
この開示は、参照により本明細書に援用される。
ＡＣＰＩソース言語（ＡＳＬ（ACPI Source Language））は、ＡＭＬと同等のプログラミング言語である。
ＡＳＬは、通常、開発者（例えば、ＯＥＭおよびＢＩＯＳ開発者）が、ＡＭＬイメージにコンパイルされるソースコードを作成することに使用するプログラミング言語である。
すなわち、ＡＳＬは、通常、ＡＣＰＩ制御メソッドを記述するために使用されるソース言語である。
ＡＳＬコードは、その後、変換ツールによって、その制御メソッドのＡＭＬコード版に変換される。
ＡＳＬおよびＡＭＬは密接に関係しているが、それらは異なる言語であることに留意すべきである。
【００１１】
制御メソッドは、ＯＳが、簡単なハードウェアタスクをどのようにして実行できるかを定義したものである。
例えば、ＯＳは、制御メソッドを起動して、温度領域の温度を読み出すことができる。
制御メソッドは、ＡＭＬで記述され、ＡＣＰＩ互換ＯＳは、制御メソッドを解釈して実行することができる。
通常、ＡＣＰＩ互換ＯＳは、ＡＣＰＩテーブル開発者が自身の制御メソッドにおいて参照することができる明確に定義された制御メソッドの組を提供する。
したがって、例えば、ＯＥＭは、コンフィギュレーションを検査して必要に応じて対応する制御メソッドをＢＩＯＳに含めるか、または、チップセットの改訂版ごとに異なる制御メソッドの組を含めることにより、１つのＢＩＯＳで、さまざまな改訂版のチップセットをサポートすることができる。
【００１２】
ＡＣＰＩソフトウェアインターフェースは、ＯＳが、システムＢＩＯＳ内で異なるＡＣＰＩ関連テーブルを見つけ出し、かつ、ＯＳが、ＡＭＬを使用して一定のハードウェアデバイスの特性を理解して制御する機能を提供する。
ＡＭＬは、システムＢＩＯＳ内のＡＣＰＩテーブルに存在する。
したがって、システムのＯＳに対して、コンピュータシステムに利用可能となり得るハードウェア資源を記述するＡＣＰＩテーブルが構築される。
ＡＣＰＩテーブルにおけるこのような記述は、ハードウェア資源用のＡＭＬコードであって、ＯＳが使用できる（例えばハードウェア特有の機能のための）制御メソッドを定義するＡＭＬコードを含むことができる。
【００１３】
ＡＣＰＩが有効であるＯＳは、ＡＭＬ用のインタープリタを備える。
ＡＳＬを使用することは、強制的なものではないが、ほとんどの開発者は、通常、自身の好ましいソース言語としてＡＳＬを使用する。
少なくとも理論的には、ユーザは、自身の任意のソース言語を開発することができ、この任意のソース言語を、トランスレータを使用してＡＭＬに変換することができる。
【００１４】
ＡＭＬは、ＡＣＰＩメソッドインタープリタによって処理される言語である。
ＡＭＬは、本来、宣言型言語であり、定義ブロックのロード時にＡＣＰＩインタープリタによってＡＣＰＩ名前空間にコンパイルされる宣言の組を提供する。
ＡＣＰＩ名前空間は、ＯＳが制御するメモリにおいては、名前を有するオブジェクトを含んだ階層的なツリー構造である。
これらのオブジェクトは、データオブジェクト、制御メソッドオブジェクト、バス／デバイスパッケージオブジェクトなどであってもよい。
ＯＳは、ＡＣＰＩ  ＢＩＯＳに存在するＡＣＰＩテーブルからの定義ブロックのロードおよび／またはアンロードを行うことにより、ランタイムに名前空間の内容を動的に変更する。
【非特許文献１】「Advanced Configuration and Power Interface Specification, Revision 2.0 Errata, Errata document」改訂版１．５（２００１年４月１３日）
【非特許文献２】「Advanced Configuration and Power Interface Specification」改訂版２．０ａ
【発明の開示】
【課題を解決するための手段】
【００１５】
本発明の１実施形態によれば、ハードウェアデバイスのデバイス特有の記述子を記憶するデータベースを有するＡＣＰＩ互換システムが提供される。
本システムはさらに、デバイス特有の記述子を使用して、ハードウェアデバイスのＡＣＰＩテーブルエントリを自律的に構築するように動作できるＡＣＰＩエージェントを備える。
【００１６】
また、本発明の１実施形態によれば、ハードウェアデバイスのＡＣＰＩテーブルエントリを自律的に構築するＡＣＰＩ互換システム用の方法が提供される。
本方法は、ハードウェアデバイスに関連付けられたファームウェアから、該ハードウェアデバイスのデバイス特有の記述子を受け取ること、ＡＣＰＩ互換システム上で実行されるＡＣＰＩエージェントが、デバイス特有の記述子を使用することであって、それによって、ハードウェアデバイスのＡＣＰＩテーブルエントリを自律的に構築する、使用することとを含む。
【００１７】
さらに、本発明の一実施の形態によれば、ハードウェアデバイスのデバイス特有の記述子を記憶する手段を備えたＡＣＰＩ互換システムが提供される。
このシステムは、このデバイス特有の記述子を使用して、そのハードウェアデバイスのＡＭＬコードを自動的に生成する手段をさらに備える。
【発明を実施するための最良の形態】
【００１８】
ＡＭＬの１つの特徴は、メモリ、Ｉ／Ｏ、およびＰＣＩコンフィギュレーション空間へのＡＭＬのアクセスが、静的であるか、あるいは、動的な値に対して提供される機能が、非常に役立たないほどに制限されているということである。
後者の理由は、動的な値が、
（ａ）ＡＭＬがＯＳによって最初にロードされる時に評価され、かつ、
（ｂ）その時点で変更すること
が非常に難しいからである。
【００１９】
上述したように、ＷＩＮＤＯＷＳ（登録商標）  ２０００のように、オペレーティングシステムの中には、当該オペレーティングシステムを実施してＡＣＰＩをサポートするコンピュータシステムを予定しているものがある。
例えば、ＷＩＮＤＯＷＳ（登録商標）  ２０００サーバの最新版のハードウェア設計ガイド  ３．０版（Hardware Design Guide Version 3.0）から以下の文章を引用する。
【００２０】
ＡＣＰＩ  ２．０版は、ＩＡ−３２システムおよびＩＡ−６４システムの双方の要求事項に対応する。
この版のハードウェア設計ガイドでは、ＡＣＰＩ  ２．０版が、すべてのＩＡ−６４システムに必要とされる。
その理由は、ＡＣＰＩ  ２．０版が、ＡＣＰＩのファームウェア、ハードウェア、およびマザーボードのサポートに関するＩＡ−６４システムに特有の要求事項に対応したＡＣＰＩ仕様の最初の版であるからである。
特に、ＡＣＰＩ  ２．０の仕様は、拡張されたテーブル定義ならびに新しいＡＣＰＩソース言語（ＡＳＬ）およびＡＣＰＩマシン語（ＡＭＬ）の６４ビット機能により、ＩＡ−６４をサポートする拡張インターフェースを定義する。
【００２１】
ＡＣＰＩモデルの主要な機能的価値は、ＡＣＰＩが、コンピュータシステムのハードウェアを記述するファームウェアのための技法を、標準データ構造体によりＯＳに提供することであることに留意されたい。
ＡＣＰＩの記述能力に加えて、ハードウェアに依存したオペレーションを、ＡＣＰＩオブジェクト（例えば、ＡＭＬでコード化される制御メソッド）としてテーブルで提供することもできる。
【００２２】
ＡＣＰＩモデルは、ＯＥＭハードウェアベンダが、標準システム機能に対するハードウェア特有のオペレーションを言語で記述するための移植可能なメソッドを提供する。
この言語とは、標準的なＡＭＬインタープリタを収容する任意のＯＳ（すなわち、任意のＡＣＰＩ準拠のＯＳ）と共に動作するものである。
このメソッドは、物理ハードウェアを明示的にモデル化するＡＣＰＩテーブルに記憶されるので、標準ハードウェア機能（例えばＩ／Ｏスロットの電源オン）の実施特有のハードウェア素子への明確なマッピングが、ＯＳに提供される。
【００２３】
システムファームウェアは、ＡＣＰＩテーブルがＯＳによって使用される前にＡＣＰＩテーブルを構築する。
したがって、システムファームウェアのある機能が、ＡＣＰＩテーブルを構築することになる。
ＡＣＰＩアーキテクチャは、ラップトップ製品の要求事項から発展したものであり、本来は、非常に単純で、マザーボード中心の観点のシステムトポロジーを前提としていた。
このようなシステムでは、ハードウェアのほとんどが、固定された定義を有し、モデムまたはローカルエリアネットワーク（ＬＡＮ）コントローラのようなプラグインハードウェアの個数および場所も固定されていた。
上述したように、このようなシステムのＡＭＬは、通常、開発者によってＡＳＬで記述され、次いて、このＡＳＬは、ＡＭＬにコンパイルされる。
次いで、このＡＭＬは、通常のシステムファームウェアのデータ部として含まれる。
このようなＡＭＬは、従来から、コンピュータシステムのブートアップ前に生成されて、システムファームウェアのデータ部に記憶されていた。
その点で、このようなＡＭＬは、コンピュータシステムに存在する可能性があると予想されるシステム資源（例えばハードウェアデバイス）を記述する。
ＡＭＬのこの生成方法を、本明細書では、「静的ＡＭＬ生成」と呼ぶ。
一例として、ラップトップコンピュータは、ハードウェアデバイスを結合できる一定数のスロットを有することができ、したがって、ラップトップコンピュータに接続できる一定数のハードウェアデバイス用のＡＣＰＩオブジェクト（例えば、制御メソッド）を定義するために、ＡＭＬコードを（ラップトップのブートに先立って）静的ＡＭＬ生成を通じて作成することができる。
【００２４】
ファームウェアの初期化中における適切な時に、ＡＭＬコードを含むＡＣＰＩテーブルが、ＲＯＭからメインメモリにコピーされ、ＯＳは、メインメモリからデータを検索する。
非ＡＭＬ固定テーブルが、ブート時にファームウェアコードによって構築されることがあり、それらのテーブルは、ＡＳＬで構築されたバイナリの一部であることがあり、コピーされることもある。
しかし、従来のＡＣＰＩ互換システムのすべてにおいて、ＡＭＬバイトコード化テーブルは、事前にコンパイルされ、システムのＲＯＭイメージに構築される。
【００２５】
上記から見て、ＡＭＬを生成するための従来の解決法には、ファームウェアＲＯＭの固定された静的テーブル（すなわちＡＣＰＩテーブル）内へ、ＡＳＬからＡＭＬをコンパイルすることが必要とされる。
その後、これらのテーブルは、ファームウェア初期化中にＲＯＭからシステムＲＡＭにコピーされる。
この手法は、ハードウェアコンフィギュレーションが事前に判明しているシステムに適しており、また、ハードウェアコンフィギュレーションの変形が限定されている場合に適している。
単純なラップトップコンピュータ（ＡＣＰＩが最初に使用された）、または、アドレス指定可能な資源が追加も除去もされず、せいぜい、周辺機器カードもしくはデバイスの追加および除去が行われることがある小さなサーバの場合、静的ＡＭＬ生成は適していることがある。
しかしながら、高度にコンフィギュレーション可能なシステムの場合、例えば、ＣＰＵ、メモリコントローラ、およびＩ／Ｏリンクコントローラが追加されたり、実行中のシステムから除去されたりすることがあるセルラサーバ（cellular server）の場合、静的ＡＭＬテーブルの使用は問題が多い。
【００２６】
図１を参照して、静的ＡＭＬ生成を使用する従来のＡＣＰＩ互換システムの実施態様の一例を示す。
システム１００は、例えば、ＰＣ、ラップトップ、デスクトップ、サーバ、または他のプロセッサベースのデバイスである。
図示するように、このシステム１００は、予想されるハードウェア素子ＡおよびＢ（それぞれ、１０１および１０２のラベルを有する）を備えることができる。
すなわち、システム１００のブートアップ前に、ハードウェア素子ＡおよびＢがシステム１００に含まれ得ることが予想される。
システム１００は、ＯＳ１０４をさらに備える。ＯＳ１０４は、例えば、ＷＩＮＤＯＷＳ（登録商標）  ２０００、ＷＩＮＤＯＷＳ（登録商標）  ＮＴ、または他のＡＣＰＩ互換ＯＳである。
開発者（例えば、ＯＥＭまたはＢＩＯＳ開発者）は、通常、ＡＳＬ１０５を使用して、予想されるハードウェアデバイス１０１および１０２の制御メソッド（例えば、ハードウェア特有の機能）を定義するＡＭＬコードを構築する。
次に、システムのＲＯＭには、静的ＡＣＰＩテーブル（１つまたは複数）１０６が記憶されており、静的ＡＣＰＩテーブル１０６は、予想されるハードウェア素子ＡおよびＢのそれぞれの記述子１０７および１０８を含む。
ＡＭＬコードが、予想されるハードウェア素子、この例では例えば素子Ｂに必要とされる場合、生成されたＡＭＬコードは、ＡＣＰＩテーブル１０６において、そのようなハードウェア素子の記述子（例えば、この例では記述子１０８）に記憶される。
予想されるハードウェア素子ＡおよびＢの１つまたは２つは、実際には、システム１００に存在しないこともあるが、このような予想されるハードウェア素子は、それぞれ事前に定義された静的ＡＣＰＩテーブル１０６に記述されているので、予想されるハードウェア素子のいずれも、システム１００内に含めることができる。
【００２７】
このようなＡＭＬの静的生成は、システム１００のすべてのハードウェア素子を、事前に構築されたＡＣＰＩテーブル（１つまたは複数）に記述することを必要とする点で、制限的であるということが認識されるべきである。
したがって、（ＡＣＰＩテーブル１０６に事前に規定されていない）記述されていないハードウェア素子、例えばハードウェア素子Ｃ（図１で１０３のラベルを有する）をシステム１００に追加したい場合であっても、このような予想されないハードウェア素子を、システムのランタイム中にシステム１００に追加することはできない。
その理由は、予想されないハードウェア素子Ｃは、静的ＡＣＰＩテーブル１０６に事前に記述されていないからである。
このような記述されていないハードウェア素子Ｃは、ＡＣＰＩテーブル１０６に事前に記述されていない点で、「予想されない」と呼ぶことができる。
一例として、記述されていないハードウェア素子Ｃをシステム１００に追加したいものと仮定し、さらに、ハードウェア素子Ｃの制御メソッド（例えば、ハードウェア特有の機能）を定義するための一定のＡＭＬコードを実施したいものと仮定する。
その場合、必要なＡＭＬコードが、静的ＡＣＰＩテーブル１０６に事前に含まれていないので、システムのランタイム中にハードウェア素子Ｃをシステム１００に追加することはできない。
したがって、記述されていない（すなわち「予想されない」）ハードウェア素子Ｃを従来のシステム１００に追加するには、システム１００をシャットダウンして、ハードウェア素子Ｃに必要なＡＭＬコードを含んだ新しい／更新された静的ＡＣＰＩテーブル１０６を作成し、その後、システム１００を再起動することになる。
【００２８】
このように、従来のコンピュータシステムは、静的に「成長」することができる。
この意味において、システムは、そのシステムに含まれることが当初予想されなかったハードウェア資源を含めるように拡張されることで「成長」する。
例えば、ユーザは、４個のＣＰＵを含み、最大で１２個のＣＰＵまで含めるようにアップグレード可能なコンピュータシステムを購入することがある。
すなわち、静的ＡＣＰＩテーブル１０６は、システムに含めることが可能な１２個のすべてのＣＰＵに必要な記述子およびＡＭＬコードを含むように事前に構築することができる。
システムを４個のＣＰＵから１２個のＣＰＵにアップグレードするには、ユーザは、従来、システムをシャットダウンして、８個の追加ＣＰＵを追加する。
その後、システムが再起動されると、システムファームウェアは、全部で１２個の予想されたＣＰＵがシステムに存在することを認識し、事前に構築された静的ＡＣＰＩテーブル１０６が、８個の追加ＣＰＵをＯＳに記述するために使用される。
しかしながら、ユーザが、当初予想された１２個のＣＰＵを超えて、例えば２０個のＣＰＵをシステム内に実施するようにシステムを「成長」させたい場合には、システムをシャットダウンし、予想されない追加ＣＰＵの新しいＡＭＬコードを（ＡＳＬを使用して）生成し、このようなＡＭＬコードをＡＣＰＩテーブル１０６に記憶して、予想されないＣＰＵをＯＳ１０４に対して記述することが必要となる。
その後、システムを再起動することができ、ＯＳ１０４は、成長した資源（例えば当初予想された１２個のＣＰＵを越えて追加された追加ＣＰＵ）を認識することができる。
このように、従来のシステムのシステムファームウェアは、予想されないハードウェアのＡＭＬコードを動的に生成することはない。
【００２９】
別の例として、ハードウェアを接続できる４つのスロットがコンピュータシステムにあると、これらの４つのスロットを記述するＡＣＰＩテーブルを事前に構築することができる。
したがって、新しいＡＭＬコードをそれらのスロット用に生成する必要なく、ハードウェアをこれらのスロットに接続することができる。
しかしながら、新しいスロットを追加することによってシステムが成長するには、新しく追加されるスロット用のＡＭＬコードをさらに生成することが必要となることがある。
この場合も、従来のシステムのシステムファームウェアは、このような予想されないハードウェア資源に必要なＡＭＬコードを動的に生成することはない。
【００３０】
コンピュータシステムの複雑度は、当初予想されたものを上回って増大することが多いので（また、コンピュータシステムの将来の成長に必要とされ得る可能なすべてのＡＭＬコードを記憶すると、システム内に実際には存在しないことがあるハードウェア素子を記述するため、望ましくない大量のメモリ資源が消費されるので）、システムが、ハードウェア素子に必要なＡＭＬコードを動的に生成できるシステムおよび方法に対する要求が存在する。
すなわち、コンピュータシステムのハードウェア素子が、コンピュータシステムに追加されるに伴い（例えば、コンピュータシステムが「成長」するに伴い）、このようなハードウェア素子に必要なＡＭＬコードを自律的に生成するシステムおよび方法に対する要求が存在する。
【００３１】
図２を参照して、本発明の一実施の形態の実施態様の一例を示す。
システム２００は、例えば、ＰＣ、ラップトップ、デスクトップ、サーバ、または他のプロセッサベースのデバイスである。
図示するように、このシステム２００は、予想されるハードウェア素子ＡおよびＢ（それぞれ、２０１および２０２のラベルを有する）を備える。
すなわち、システム２００のブートアップ前に、ハードウェア素子ＡおよびＢがシステム１００に含まれ得ることが予想される。
システム２００は、ＯＳ２０４をさらに備える。ＯＳ２０４は、例えば、ＷＩＮＤＯＷＳ（登録商標）  ２０００、ＷＩＮＤＯＷＳ（登録商標）  ＮＴ、または他のＡＣＰＩ互換ＯＳである。
システムのＲＯＭには、静的ＡＣＰＩテーブル（１つまたは複数）２０８が記憶されており、この静的ＡＣＰＩテーブル２０８は、予想されるハードウェア素子ＡおよびＢのそれぞれの記述子２０９および２１０を含む。
ＡＭＬコードが、予想されるハードウェア素子、例えばこの例では素子Ｂに必要とされる場合、生成されたＡＭＬコードが、ＡＣＰＩテーブル２０８のそのようなハードウェア素子の記述子（例えば、この例では記述子２１０）に記憶される。
【００３２】
記述されていないハードウェア素子Ｃ（２０３のラベルを有する）の記述子は、ＡＣＰＩテーブル２０８に事前に定義されておらず、このハードウェア素子Ｃをシステム２００に追加したい場合、一実施の形態は、ハードウェア素子Ｃをサポートするために、あらゆる追加ＡＭＬコードを含むＡＣＰＩテーブルエントリをＡＣＰＩテーブル２０８に自律的かつ動的に生成するように動作可能である。
記述されていないハードウェア素子Ｃは、ＡＣＰＩテーブル２０８に事前に記述されていないことから、本明細書では、記述されていないハードウェア素子Ｃを「予想されない」ハードウェアＣと呼ぶことがある。
ただし、（以下にさらに説明するように）一実施の形態では、システムは、いわば、記述されていないハードウェア素子を収容することを予想し、このような新しく収容されたハードウェア素子をＡＣＰＩテーブル２０８に動的に記述できる点で、「予想されないということを予想している」。
より具体的には、一実施の形態では、ハードウェア素子Ｃがシステム２００に追加される（例えば、システム２００に通信接続される）と、デバイス認識ファームウェア２０５が、このようなハードウェア素子Ｃを認識し、ハードウェア素子Ｃと相互作用して、そのデバイス特有のプロパティの記述を構築することができる。
デバイス認識ファームウェア２０５は、この記述をデータベース２０６に記憶する。
次いで、ＡＣＰＩエージェント２０７が実行され、それによって、データベース２０６にアクセスし、データベース２０６に記憶されたハードウェア素子Ｃのデバイス特有のプロパティを利用して、ハードウェア素子ＣをサポートするあらゆるＡＭＬコードを生成することができる。
次いで、ＡＣＰＩエージェント２０７は、新しいエントリ（例えば、新しい記述子）２１１をＡＣＰＩテーブル２０８に生成する。
この新しいエントリは、もしあれば、ハードウェア素子Ｃ用の追加ＡＭＬコードを含む。
次いで、ＯＳ２０４には、新しいＡＣＰＩテーブルエントリが利用可能であることが通知される。
次いで、ＯＳ２０４は、ハードウェア素子ＡおよびＢとまったく同様に、ハードウェア素子Ｃのオペレーションを適切に管理するために、ＡＣＰＩテーブル２０８を利用することができる。
【００３３】
上記から見て、この実施の形態は、静的ＡＣＰＩテーブルにエントリを自律的かつ動的に生成できるシステムを提供する。
すなわち、新しいハードウェアがシステム２００に追加されると、システムは、このような新しく追加されたハードウェアを記述する補助ＡＣＰＩテーブルエントリをＯＳ２０４に対して自律的に生成することができる。
さらに、制御メソッドを定義（例えば、デバイス特有の機能を定義）するために、ＡＭＬコードが、新しく追加されたハードウェア素子（例えば、図２の例ではハードウェア素子Ｃ）に必要とされる場合、ＡＣＰＩエージェント２０７は、このようなＡＭＬコードを自律的に生成し、新しく追加されたハードウェア素子用のＡＣＰＩテーブルエントリに含めることが可能であることが好ましい。
【００３４】
図３は、実施の形態を実施できる一例の状況を示している。
図３は、一例のシステム３００の抽象モデルを示している。
このシステム３００は、ハードウェアプラットフォーム３０１、プロセッサ（１つまたは複数）３０２、ＯＳ３０３、およびシステムファームウェア３０７を備える。
この実施態様の例では、システムファームウェア３０７は、プロセッサ抽象レイヤ（ＰＡＬ（Processor Abstraction Layer））３０４、システム抽象レイヤ（ＳＡＬ（System Abstraction Layer））３０５、および拡張ファームウェアインターフェース（ＥＦＩ（Extended Firmware Interface））３０６を備える。
【００３５】
さまざまなプロセッサアーキテクチャが、この技術において知られており、例えば、HEWLETT-PACKARD Company（「ＨＰ」）により開発されたＰＡ−ＲＩＳＣファミリーのプロセッサ、INTEL Corporationの（ＩＮＴＥＬ）アーキテクチャ（ＩＡ）プロセッサ（例えば、既知のＩＡ−３２プロセッサおよびＩＡ−６４プロセッサ）などがある。
既知のように、ＩＡ−６４は、ＨＰおよびＩＮＴＥＬによって共同開発された６４ビットプロセッサアーキテクチャである。
このプロセッサアーキテクチャは、明示的並列命令コンピューティング（ＥＰＩＣ（Explicitly Parallel Instruction Computing））に基づいている。
【００３６】
図３に示す一例のシステム３００は、既知のＩＡ−６４アーキテクチャに従い、例えば、既知のＩＴＡＮＩＵＭプロセッサファミリー（ＩＰＦ）用に実施される。
本発明の実施の形態は、ＡＣＰＩを利用する他の任意の適切なシステムアーキテクチャ内で実施できる（したがって、図３に示すＩＡ−６４アーキテクチャにもっぱら限定されるものではない）が、以下では、本発明の一実施の形態を、図３のＩＡ−６４（例えばＩＰＦ）システムアーキテクチャ内で実施されるものとして説明する。
ＩＡ−６４プロセッサアーキテクチャの定義は、ＩＡ−６４プロセッサを利用するシステムのファームウェアアーキテクチャの要素に対する要求事項の仕様を定める。
このアーキテクチャの典型的なモデルは、Intel IA-64 Architecture Software Developer's ManualのVolume 2: IA-64 System Architectureの１１．１節のFirmware Modelに提供されている。
この文献は、ＩＡ−６４ファームウェアが、３つの主要なコンポーネントであるＰＡＬ３０４、ＳＡＬ３０５、およびＥＦＩ３０６を備え、これら３つのコンポーネントが、ＯＳブート用のプロセッサおよびシステムの初期化を共に提供することを記述している。
【００３７】
３つのコンポーネント３０４、３０５、および３０６は、ＡＣＰＩと互換性を有する標準的なＩＡ−６４コンピュータシステムのシステムファームウェアの機能のすべてを表しているとは限らないことがある。
ＡＣＰＩ互換システムでは、プラットフォームファームウェアの実施態様のＳＡＬコンポーネント３０５が、ＡＣＰＩ要求事項を満たすように記述されることが予想されるが、必須ではない。
【００３８】
ハードウェアプラットフォーム３０１は、システムのプロセッサ３０２以外のシステム３００のハードウェアコンポーネントのすべての集まりを表す。
図３の抽象モデルに示す、これらさまざまなコンポーネント間の矢印は、システム３００の挙動の相互作用の型を示している。
まず、システム３００に電源が投入されると、いくつかの健全性検査（例えばパワーオンセルフテスト）が、プラットフォーム３０１に含まれるマイクロプロセッサによって実行される。
このマイクロプロセッサは、アプリケーションを実行するメインシステムプロセッサ３０２ではない。
それらの検査が合格した後、次に、電源およびクロックが、プロセッサ３０２に供給される。
プロセッサ３０２は、システムのＲＯＭ（図３に特に図示せず）からのコードの実行を開始する。
実行されるコードは、ＰＡＬ３０４であり、ＰＡＬ３０４は、システム３００を制御する。
ＰＡＬ３０４は、実行されることによって、同じファームウェアを通じてプロセッサが同時に実行を開始するように、プロセッサ３０２のすべてを確保する。
【００３９】
ＰＡＬ３０４は、プロセッサ（１つまたは複数）３０２を初期化するという自身の義務を遂行した後、システム３００の制御をＳＡＬ３０５に渡す。
ＳＡＬ３０５の役割は、どのハードウェアがプラットフォーム３０１に存在するのかを発見し、そのハードウェアを初期化して、ＯＳ３０３に利用可能とすることである。
このハードウェアは、第１にメインメモリである。
メインメモリが初期化され、機能すると、ファームウェア３０７（すなわち、ＰＡＬ３０４、ＳＡＬ３０５、およびＥＦＩ３０６であり、ＥＦＩ３０６はまだ実行されていない）が、メインメモリにコピーされる。
次いで、制御は、ＥＦＩ３０６に渡される。
ＥＦＩ３０６は、ブートデバイスの起動を担当する。
ブートデバイスには、通常、ディスクが含まれる。
ＥＦＩ３０６は、このディスクを読み出して、プログラムをメモリにロードする。
このプログラムは、通常、オペレーションシステムローダと呼ばれる。
ＥＦＩ３０６は、ＯＳローダをメモリにロードし、次いで、プロセッサ３０２の１つ（通常、ブートスタートアッププロセッサと呼ばれる）をこのようなＯＳローダプログラムのエントリポイントに分岐させることにより、ＯＳローダにシステム３００の制御を渡す。
【００４０】
次いで、ＯＳローダプログラムは、標準ファームウェアインターフェース３０７を使用して、システム３００のさらに制御すべきものを発見して初期化する。
ＯＳローダがマルチプロセッサシステムにおいて通常行うことの１つは、他のプロセッサの制御を取り戻すことである。
例えば、マルチプロセッサシステムでは、この時点で、他のプロセッサは、何も行わないループを実行中であることがある。
ＡＣＰＩ互換システムでは、ＯＳ３０３は、ＡＣＰＩ呼び出しを行って、ＡＣＰＩテーブル（以下で図５と共にさらに説明する）を構文解析して、マルチプロセッサシステム３００の他のプロセッサを発見する。
次いで、ＯＳ３０３は、ファームウェアインターフェース３０７を使用して、それら発見されたプロセッサをオペレーションシステムコードに分岐させる。
その時点で、ＯＳ３０３は、プロセッサのすべてを制御し、ファームウェア３０７は、システム３０３をもはや制御していない。
【００４１】
ＯＳ３０３は、初期化されるに伴い、ブート時にどのハードウェアが存在するのかをファームウェア３０７から発見する。
そして、ＡＣＰＩ標準では、ＯＳ３０３は、ランタイムにおいても、どのハードウェアが存在するのか、追加されているのか、または除去されているのかを発見する。
システムに存在し得るハードウェアを発見する際、ＯＳ３０３は、システムのＡＣＰＩテーブル（１つまたは複数）にアクセスする。
本明細書では、それらのＡＣＰＩテーブルの内容を動的に変更するためのさまざまな技法として、アドレス技法を開示している。
ＯＳは、システムの初期化中に関数呼び出しを使用して、ＡＣＰＩテーブルのアドレスを検出する。
それらのＡＣＰＩテーブルへのポインタが、ＥＦＩシステムテーブルポインタ５０１（図５参照）に渡される。
ＥＦＩシステムテーブルポインタ５０１は、図３の標準ＥＦＩ手順呼び出し３０８の１つを行うことにより得られる。
したがって、ＥＦＩ手順呼び出し３０８を使用して、システム３００のハードウェアを記述したＡＣＰＩテーブル（図５に示す）のアドレスが渡される。
ＯＳ３０３がブート時にアクセスするこのようなＡＣＰＩテーブルは、システム３００に利用可能な資源を記述している。
例えば、ＡＣＰＩテーブルは、既存のハードウェア、および、そのハードウェアをプラグ接続できるハードウェアスロットを記述している。
例えば、システム３００は、イーサネット（登録商標）カードを収容するスロットを備えたラップトップであってもよい（ただし、そのスロットには、実際にはイーサネット（登録商標）カードが接続されていなくてもよい）。
そのスロットは、ＡＣＰＩ資源として知られており、ラップトップのブート時にラップトップのＡＣＰＩテーブルに記述される。
イーサネット（登録商標）カードがそのスロットにプラグ接続されると、ＯＳ３０３は、プラットフォーム３０１から通知を得る。
次いで、ＯＳ３０３は、ＡＣＰＩテーブルにアクセスして、そのデバイスのデバイスドライバを（ＡＣＰＩテーブルに設けられた情報を使用して）起動する方法を決定する。
【００４２】
図４を参照して、ＡＣＰＩシステムの要素と他のシステムの要素との間の関係を図示する一例のソフトウェアシステム図を示す。
すなわち、図４は、ＡＣＰＩに関連したソフトウェアコンポーネントおよびハードウェアコンポーネント、ならびに、それらのコンポーネントが互いにどのように関係しているのかを定義するブロック図である。
図４は、「Advanced Configuration and Power Interface Specification」改訂版２．０ａ（２００２年３月３１日）の１．６節から直接引用したものであり、また、そこに説明されているものであることに留意すべきである。
ＡＣＰＩ仕様４０２は、システムファームウェア３０７（図３）で実施され、コンポーネント、ＡＣＰＩテーブルの内容、および他のＡＣＰＩコンポーネントの関連した意味の間のインターフェースを記述する。
ＡＣＰＩテーブル４０５は、ＡＣＰＩの実施態様の定義構成体（defining construct）であり、ＡＣＰＩ準拠のＢＩＯＳの役割は、主として、アプリケーションプログラミングインターフェース（ＡＰＩ）ではなく、ＡＣＰＩテーブルを供給することである。
【００４３】
図４は、ＡＣＰＩの以下の３つのランタイムコンポーネントを示している。
（１）ＡＣＰＩテーブル４０５：
これらのテーブルは、ハードウェアに対するインターフェースを記述する。
それらのインターフェースは、さまざまなコンフィギュレーションを取ることができ、ＡＭＬコードによる記述を含むことができる。
その記述のうちのいくつかは、構築可能なものを制限し（ただし、ほとんどの記述は、任意の方法でハードウェアを構築することを可能にするものである）、また、ハードウェアを機能させるのに必要な任意のオペレーションシーケンスも記述することができる。
ＡＣＰＩテーブル４０５は、ＡＭＬを利用でき、このＡＭＬは解釈されるので、ＯＳ３０３は、ＡＭＬインタープリタ４０７を含み、ＡＭＬインタープリタ４０７が、ＡＭＬでコード化されてＡＣＰＩテーブル４０５に記憶された手順を実行する。
（２）ＡＣＰＩレジスタ４０３：
これらは、ハードウェアインターフェースの限られた部分であり、ＡＣＰＩテーブル４０５によって少なくともある場所に記述される。
（３）ＡＣＰＩ  ＢＩＯＳ４０４：
これは、ＡＣＰＩ仕様と互換性のあるファームウェア３０７の部分をいう。
ＡＣＰＩ  ＢＩＯＳ４０４は、通常、システムＢＩＯＳ４０１から分離されていないが、この例では、その追加機能およびＡＣＰＩ仕様との互換性を強調するために分離したコンポーネントとして示していることに留意されたい。
したがって、（ＩＡ３２システムの）ＡＣＰＩ  ＢＩＯＳ４０４または（ＩＰＦシステムの）ＳＡＬ３０５は、システム４００をブートするコードを含むと共に、スリープ、ウェイク、およびいくつかの再起動オペレーションのインターフェースも実施する。
【００４４】
デバイスドライバ４０６は、コンピュータシステムに取り付けられた特定のハードウェアデバイスの管理および制御を行う複数のＯＳコンポーネントの任意の１つを表す。
一例は、ＳＣＳＩ（小型コンピュータシステム相互接続）ディスクコントローラおよびディスクドライブである。
別の例は、イーサネット（登録商標）コントローラである。
デバイスドライバ４０６は、ＯＳカーネル４０８の残りの部分に抽象化したものを提供する（その結果、例えば、ＯＳ自身は、ＳＣＳＩコントローラの異なるブランド間の相違およびモデル間の相違または他のハードウェアデバイスの型の間の相違について知る必要がない）。
ＯＳカーネル４０８およびデバイスドライバ４０６の双方は、ＯＳＰＭシステムコード４０９のＯＳ特有のインターフェースを使用して、ＡＣＰＩインタープリタシステム４０７と相互作用する。
このインターフェースは、ＡＣＰＩアーキテクチャが提供する標準ＡＣＰＩインタープリタを抽象化したものに対するインターフェースである。
例えば、ＡＭＬインタープリタ４０７は、ＡＭＬにより宣言されたオペレーション領域のマッピングをＡＣＰＩテーブル４０５に作成する際に、仮想メモリサービスをＯＳＰＭシステムコード４０８から受け取る。
仮想的なマッピングがないと、ＯＳが仲介するＡＭＬインタープリタ４０７を通じてハードウェアへのアクセスを要求するＡＭＬは、そうすることができず、そのオペレーション領域にアクセスできない。
【００４５】
図５は、ＡＣＰＩテーブルが、一般に、ＡＣＰＩ互換システムで実施される場合のＡＣＰＩテーブルの高位ブロック図を示している。
システムファームウェア３０７（ＩＰＦモデルのＳＡＬ３０５、ＩＡ３２モデルのＢＩＯＳ）は、これらのＡＣＰＩテーブルを、ＯＳ３０３によって使用される前に構築する。
図５は、ＥＦＩインターフェースとＡＣＰＩテーブルとの間の関係を示している。
ＥＦＩ３０６は、ＩＰＦシステムにおけるＡＣＰＩテーブルのルートへのポインタ５１０を提供する。
また、図５は、ＡＭＬとして提供されるＡＣＰＩテーブルの要素も示している。
【００４６】
このように、図５は、ＡＣＰＩ準拠システムに対して一般に実施されるソフトウェア記述データ構造体の概念モデルである。
要素５０１は、このデータ構造体（本明細書では「ＡＣＰＩテーブル」と呼ぶ）の開始点である。
ＡＣＰＩテーブルは、データ構造体の編成された（architected）組である。
その相互の関係は、編成されているが、その特定の内容は、ハードウェアプラットフォームによって変化し得る。
そこで、ＯＳは、巡回アルゴリズムを含むことができ、そのアルゴリズムが、ＡＣＰＩテーブルの編成されたルールに従って任意のシステム上で機能することになる。
このデータ構造体の巡回の開始点は、図３のＥＦＩ手順呼び出し３０８によってこのデータ構造体に与えられたポインタ５０１で始まる。
次いで、オペレーションは、「ルートシステム記述ポインタ」（ＲＳＤ  ＰＴＲ）５０２に進む。
このＲＳＤ  ＰＴＲ５０２は、ＯＥＭ  ＩＤ５０３によってキューに入れられる。
その中には、「拡張システム記述テーブル」（ＸＳＤＴ）５０５と呼ばれるものへのポインタ５０４が存在する。
ＸＳＤＴ５０５は、個数が変化するエントリを含んだテーブルである。
各エントリは、別のテーブル項目、例えば項目５１−１から５１−Ｎを指し示す。
それらの図示した項目のうちのいくつかは、必要とされることがあり、また、いくつかは、必要とされない。
それらの項目が存在する場合、当該項目は、自身が記述することになっているものをＯＳ３０３に対して特定するためのヘッダフォーマットを有する。
項目が記述するものに応じて、項目の内部フォーマットが変化することになる。
これらの項目の例は、割り込み記述５１−１およびデバッグテーブル（ＤＢＧＰ５１−２として示す）である。
【００４７】
項目５１−Ｎは、２次システム記述テーブル（「ＳＳＤＴ（Secondary System Description Table）」）と呼ばれる。
ＳＳＤＴは、ハードウェア素子のＡＭＬを含む記述からなるブロックを含む（ＳＳＤＴは、「Advanced Configuration and Power Interface Specification」改訂版２．０ａの第１７ページにさらに説明されている）。
さらに、差分システム記述テーブル（「ＤＳＤＴ（Differential System Description Table）」）５０６は、ＡＭＬを含む固定テーブルである（ＤＳＤＴは、「Advanced Configuration and Power Interface Specification」改訂版２．０ａの第１４ページにさらに説明されている）。
テーブル５１−Ｎおよびテーブル５０６は、機能メソッドおよび記述オブジェクトの双方をＡＣＰＩ名前空間に記述する。
【００４８】
そこで、ＯＳ３０３は、ＡＣＰＩテーブルとして知られているこの編成されたデータ構造体を巡回する。
そして、ＯＳ３０３は、そのメインメモリ内において、このデータ構造体を、ファームウェアが当該データ構造体に与えたこの表現から、ある等価な表現に変換する。
この等価な表現は、ＡＣＰＩインタープリタおよび割り込みの構造、ならびにメソッドを実行するＡＭＬコードによって増強されたものである。
ＡＭＬコードは、ＡＣＰＩ内で実行される。
これは、ＡＭＬコードがファームウェアＲＯＭにおいて実行されず、その代わり、ＯＳ３０３の内部で実行されることを意味する。
ＯＳ３０３は、ＡＭＬがバグを有する場合であっても、ＯＳが、障害（例えば、「ブルースクリーン」になる）から保護されるように、ある型の保護環境を提供する。
一般に、システムは、ＡＭＬを含んだ単一のＤＳＤＴテーブル５０６をエクスポーズするが、ＡＭＬも含んだＳＳＤＴについては、０個または１個以上のＳＳＤＴ５１−Ｎを提供することができる。
ＡＭＬオブジェクトは、ＯＳ３０３によって、ＡＣＰＩ名前空間と呼ばれる編成されたモデルにロードされる。
この名前空間は、編成されたランタイム環境をＡＣＰＩオブジェクトに提供する。
ＡＣＰＩ標準は、動的なロードまたはアンロードの機能を達成するための実施を定義しないが、ＳＳＤオブジェクト５１−Ｎは、動的にロードすることもできるし、アンロードすることもできる。
説明したシステムは、システムに追加された新しいハードウェアに対して、これらのＳＳＤＴ５１−Ｎおよび／またはＤＳＤＴ５０６を動的に生成することができる。
説明したシステムは、システムから除去されたハードウェアに対して、このようなテーブルを（例えばUnload()（アンロード（））演算子を使用して）動的に除去することができる。
【００４９】
例示した技法により、システムは、システムのランタイム中に、コンピュータシステムによって成長された新たな資源に対しては、必要なＡＣＰＩテーブルエントリ（例えばＡＭＬコード）を自律的かつ動的に生成することができ、かつ／または、除去されたハードウェア資源に対しては、ＡＣＰＩテーブルエントリを自律的かつ動的に除去することができる。
実施の形態の中には、本明細書でバンヤン（Banyan）システムと呼ぶシステムアーキテクチャで実施されるものがある。
もちろん、他のシステムアーキテクチャ内において、代替的な実施の形態を実施することもできる。
図６は、バンヤンシステムの一例のブロック図を示している。
バンヤンファームウェアシステム６００は、フレームワークプラスコンポーネント（Framework plus Components）モデルの応用である。
フレームワークは、システムの機能の主要部を含んだドメイン特有のソフトウェア機能の組である。
コンポーネントは、明確に定義されたインターフェースを介してフレームワークと、および、互いに協力して相互作用し、システム全体の機能を実現する。
フレームワークは、一般に、開発および学習が困難であり、ドメイン特有のものである。
しかしながら、フレームワークが非常に良くできている場合、フレームワークは、最高レベルの再利用可能性を実現する最良の手段にもなる。
【００５０】
システムのハードウェアは、コンポーネントによって変化するので、フレームワークプラスコンポーネントモデルは、成長するシステムのファームウェアを実施するのに適している。
すなわち、新しいファームウェアまたは追加されたファームウェアを利用するハードウェアは変化するが、システムの機能の多くは、同じままである。
そこで、ファームウェアの多くが、異なるコンポーネントにわたって再利用できるように、ブート時またはハードウェアの起動時のいずれかにおける要素の調整、ハードウェアの発見、発見されたハードウェアに対するファームウェアの整合などのシステムファームウェアの機能の多くは、フレームワークで実施することができ、ファームウェアのハードウェア特有の部分は、フレームワークプラスコンポーネントモデルのコンポーネントとして実施することができる。
【００５１】
この例のバンヤンアーキテクチャ６００の要素を以下のとおり説明する。
（１）ＡＣＰＩテーブル６０８：
ＡＣＰＩテーブル６０８は、図５と共に上記で十分に説明されている。
（２）ＡＣＰＩエージェント６０９：
ＡＣＰＩエージェント６０９は、ＡＣＰＩ（標準）ファームウェア機能をエキスポートする。
このモデルでは、ＡＣＰＩエージェント６０９は、コア６０１が初期化された後、ブートストラップの期間中、制御が与えられるコードである。
ブートストラップの期間中、ＡＣＰＩエージェント６０９は、内部で使用されるシステムの表現を、外部の標準によって使用される表現に変換する。
ＡＣＰＩエージェント６０９は、ＡＣＰＩインターフェースの発展部分を、システムを記述し、かつ、いくつかのハードウェア機能を制御するために、内部で使用されるものから分離するという点で、プロキシ設計パターンに類似する。
（３）ＥＦＩ  ＡＢＩ６１０：
ＥＦＩ  ＡＢＩ６１０は、ブートサービスをＯＳローダおよび初期のＯＳ初期化コードに提供する、外部インターフェース（手順呼び出しベース）のＩＡ６４標準セットである。
また、ＥＦＩ  ＡＢＩ６１０は、ＯＳに全制御が与えられた後であって、ブート時のサービスが利用可能でなくなった時であっても利用可能であるランタイムサービスの非常に小さなセットも含む。
ＥＦＩパッケージは、標準ＥＦＩブートドライブをサポートするＥＦＩブートドライバのランタイム基盤設備も含むことができる。
（４）ＳＡＬ  ＡＢＩ６１１：
このベニヤ（別のアダプタパターン）は、ＩＡ６４アーキテクチャによって使用される標準ＩＡ６４ファームウェア手順インターフェースを実施する。
また、ＳＡＬ  ＡＢＩ６１１は、製品差別化機能用のＯＥＭ特有の手順も実施する。
内部では、ＯＥＭ特有の機能の、サブパッケージまたは分離したコンポーネント（１つまたは複数）への分離が行われることがある。
（５）移植可能コア（または「データベース」）６０１：
これは、マルチパッケージデータベースであり、多数の機能を実施する。
システムハードウェアコンフィギュレーションの完全な動的記述は、「デバイスツリー」アーキテクチャパターン６０５を実施するサブシステムに保持される。
フレームワークをブートストラップするコンソールのようなコアＩ／Ｏドライバは、このパッケージの一部である。
コアＩ／Ｏドライバは、リモートコンソールプロトコル、デバッガサポート６０７、システム初期化の調整、エラーハンドリングの調整、および移植可能とすることができるファームウェアシステムの機能の基本的にほとんどのものである。
コア６０１の要素を、以下のとおり、さらに十分に説明する。
（ａ）デバイスツリー６０５：
システムプラットフォームのハードウェアコンポーネントおよびソフトウェアコンポーネントを表す結合コンポーネント（bound-component）からなる動的システムであるバンヤンコンポーネントツリーパッケージである。
（ｂ）ツリーコンポーネント６０６：
これは、デバイスツリー６０５にインスタンス化するのに利用できるコンポーネントの緩やかに接続されたバイナリイメージの集合体を表す。
いくつかは、「ソフトウェアパッケージ」であり、それ以外のものは、「ハードウェアパッケージ」である。
ソフトウェアパッケージは、ネットワークプロトコル、バッファキャッシュなどのような共有可能なサービスを表す。
ハードウェアパッケージは、ツリーの「デバイスノード」を実施する。
このデバイスノードは、実際のシステムハードウェアコンポーネントに対応する。
インスタンス化されたコンポーネントは、ブート時に構築されるコンポーネントツリーに存在する。
（ｃ）デバッガ６０７：
このパッケージは、デバッグのローカルモデルおよびリモートモデルの双方をサポートする対話型のデバッガ機能を表す。
リモートモデルは、サポートされる任意のデバイス（通常、シリアル接続またはＬＡＮ接続）を通じて接続することができる。
ローカルデバッガは、直接的なリンク接続を通じて使用されることが予想される。
ローカルデバッグは、必要なシンボルテーブルが利用可能でないことがあるので、ソースレベルのデバッグをサポートしないことがある。
このデバッガパッケージは、いくつかのバンヤンコンポーネントから構成されることになっている。
（ｄ）コアフレームワーク６０２：
メモリ管理、プリミティブコンソールなどを含み、デバイスツリーパッケージ６０５をサポートするサポートサービスである。
しかし、これらのサポートサービスは、モジュール化を行うために、そのパッケージの外部でより良く収集される。
主要なものは、「コンポーネント結合」および「コンポーネントフレームワーク」の基盤設備、エラーハンドリング基盤設備、ならびに「ＯＳ類似」の基盤設備（ロックプリミティブ、ロックトレース、イベントログ記録などをここで実施することができる）である。
（ｅ）イベントシーケンサ６０３：
順序付けを使用する主な２種類のイベントには、初期化イベントおよびエラーハンドリングイベントが含まれる。
このパッケージは、集中化したハンドリングメカニズムを表すものではない。
むしろ、我々は、これを、さまざまな音楽家からなる「オーケストラ」の「指揮者」と考える。
各音楽家は、自身の命令（初期化、エラーハンドリング）の演奏方法は知っているが、全体の交響曲の楽譜は知らない。
指揮者は、楽譜は知っているが、各命令の演奏方法は知らない。
指揮者は、「コーディネータ」としての機能を果たす。
これは、分散エラーハンドリングシステムおよび集中化エラーハンドリングシステムの双方の利点を損失なく提供する。
（ｆ）ＳＡＬサブストレート(SAL substrate)６０４：
このパッケージは、ＰＡＬの要求事項に適合したＳＡＬ＿ＥＮＴＲＹ（ＳＡＬエントリ）機能を表す。
また、このパッケージは、プラットフォームに依存した構造の初期化プリミティブおよびエラーハンドリングフレームワークも含む。
プラットフォームから独立した機能の組も存在する。
この機能組は、プロセッサの命令セットに依存するか、または、依存する可能性がある。
プロセッサモデルに依存したコードは、この基板パッケージ、または、プロセッサに対応するデバイスノード（または両者の組み合わせ）において実施することができる。
また、ＳＡＬ基板は、他のパッケージおよびコンポーネントツリーのコンポーネントにもサービスをエキスポートする。
【００５２】
一実施の形態では、コンピュータシステムのハードウェア素子ごとに、ファームウェア要素が実施される。
システムのブート時に、ファームウェアは、どのハードウェアがシステムに存在するのかを発見し、コンポーネントと呼ばれる複数の個別のプログラムを含む実行プログラムを動的に構成する。
これらのコンポーネントのそれぞれ１つは、ＡＣＰＩテーブルを構築するファームウェアのあるものを含む。
したがって、新しいハードウェア素子が、いつシステムに追加されても、そのハードウェア素子は、自身に関連付けられて起動されるあるファームウェアを有することができる。
その関連付けられたファームウェアは、このハードウェア素子に必要なＡＭＬを含むことができる。
一定の実施の形態では、この関連付けられたファームウェアは、このようなＡＭＬコードに加えて、あるいは、このようなＡＭＬコードに代えて、情報を含むことができる。
この情報は、ＡＣＰＩエージェントが使用して、そのハードウェア素子に適切なＡＭＬコードを生成することができる情報である。
本明細書で「バンヤンコア」と呼ぶことがあるデータベース６０１（図２にデータベース２０６で示す）が構築されて、新しく追加されたハードウェア素子を正確に記述する。
好ましい実施の形態では、データベース６０１の一部は、新しく追加されたデバイスに必要なＡＭＬ（もしあれば）のすべてまたは一部を含むことができる。
ＡＣＰＩエージェント６０９は、コンポーネント６０６のデータベース６０１を巡回し、システムのハードウェア素子を記述するために使用されるＡＣＰＩテーブル６０８をＯＳ３０３用に生成する。
【００５３】
バンヤンフレームワーク６００の要素は、ファームウェアが管理するハードウェアの明示的なモデルである。
このモデルが、データベース（すなわち「デバイスツリー」）６０５である。
システムハードウェア自体は、集約された要素の集合体から構築されるので、バンヤンのデータベース６０５は、複合ソフトウェア設計パターンによって、これらの集合体を明確にミラーリングする。
この複合パターンは、ツリーに類似し、したがって、データベース６０５は、デバイスツリーと呼ばれることがある。
【００５４】
バンヤンコアのファームウェアシステムは、サーバがブートされた時に、そのサーバに、どのハードウェアが存在し、アクティブであるのかを正確かつ明確に表すデータベース６０１を構築する。
データベース６０１は、コンポーネント６０６から構成される。
このコンポーネント６０６は、ハードウェアを管理し、テキストおよびデータの双方を含む。
コンポーネント６０６は、初期化された静的データに加えて動的データの双方を含むことができる。
各コンポーネントは、データベース６０１のデバイス特有のプロパティの組、すなわちデータオブジェクトの組を公開することができる。
その後、データベース６０１のいずれのクライアントも、データベース上で反復を行う５つの単純なプリミティブを使用して、この組を問い合わることができる。
これらの反復子プリミティブは、IEEE Standard for Boot firmware（ブートファームウェアのＩＥＥＥ標準）（その第１２７５ページ参照）に述べられているのと同様の方法で実施される。
一実施の形態は、ＧｅｔＰｒｏｐ、ＧｅｔＰｒｏｐｌｅｎ、ＮｅｘｔＰｒｏｐ、ＳｅｔＰｒｏｐ、およびＤｅｌｅｔｅＰｒｏｐを使用する。
バンヤンの一例の実施態様では、これらの関数は、次のように実施される。
STATUS GetProP (dhandle_t Node,
char *PropertyName,
void *PropertyValue,
uint64 ValueSize,
uint64 *PropertyLength,
propformat_t *Format);
STATUS GetProplen (dthande_t Node,
char *PropertyName,
uint64 *PropertyLength);
STATUS NextProp (dthande_t Node,
char *Current,
char *Next,
uint64 (NextSize);
STATUS SetProp (dthandle_t Node,
char *PropertyName,
void *PropertyValue,
uint64 PropertyLength,
PROPFORMAT_T fORMAT);
STATUS DeleteProp (dthandle_t Node,
char *PropertyName);
【００５５】
コア６０１が初期化された後、ブートマネージャが起動されて、ＯＳ３０３をロードする前に、ＡＣＰＩエージェント６０９と呼ばれるファームウェアパッケージが制御を取得する。
ＡＣＰＩエージェント６０９のジョブは、ＡＣＰＩテーブル６０８（図５に、より詳細に示した）を構築することである。
ハードウェア特有のテキストおよびデータが、ハードウェア特有のコンポーネント６０６内に含まれるので、ＡＣＰＩエージェント６０９は、所与のプラットフォーム３０１の特定のハードウェアではなく、ＡＣＰＩの抽象化したもののみを理解しなければならない。
したがって、この例のバンヤンアーキテクチャ６００により、考慮すべき事項（特定のハードウェアから標準テーブルフォーマット）を分離することが可能になり、加えて、デバイスツリー６０５に設けられた明示的な複合パターンデータベースの問い合わせインターフェースが可能になり、加えて、コンポーネント６０６がデータオブジェクト（すなわち「プロパティ」）を含むことができることが可能になる。
【００５６】
ＡＣＰＩエージェント６０９は、ＯＳ３０３によって使用されるＡＣＰＩテーブル６０８を構築する。
この構築は、デバイスツリーデータベース６０５を巡回し、編成されたデバイスによって公開された予想されるプロパティを抽出し、そして、それらのプロパティを標準ＡＣＰＩフォーマット（１．０または２．０）に変換することにより行われる。
ＡＭＬテーブルを必要とするデバイスに対して、各コンポーネント６０６は、そのデバイス用のＡＭＬのすべてまたは一部を含んだ標準名のプロパティを含む。
このＡＭＬは、必要に応じて、動的に生成することもできるし、静的に生成することもできる。
例えば、静的ＡＭＬメソッドを、ＡＳＬソースから構築することができる。
このＡＳＬソースは、ＡＣＰＩテーブル６０８のＡＭＬを必要とする各コンポーネント６０６のソースに、Ｃ言語のデータ宣言として含まれる。
しかしながら、ＡＣＰＩエージェント６０９が各コンポーネント６０６からＡＭＬオブジェクトを検索するために使用するメソッドは、単なるデータ検索機能であるので、コンポーネントは、ＡＭＬを要求に応じて合成することもできるし、そのコンポーネント内の初期化されたデータからＡＭＬを提供することもできる。
ＡＣＰＩエージェント６０９は知る必要はない。
したがって、ＡＣＰＩエージェント６０９は、１）ＡＭＬの合成、２）ＡＳＬから構築されたＡＭＬのコピー、および３）バイナリからバイナリへの変換またはこれら３つの方法の任意の組み合わせによるＡＭＬの生成／コンパイルのいずれかを行うように実施することができる。
【００５７】
ＡＣＰＩエージェント６０９は、システムハードウェアのトポロジーに対応する名前空間をデバイスツリー６０５から直接構築する。
このデバイスツリー６０５も、システムハードウェアのトポロジーに対応する。
このデバイスツリー６０５と、そのツリーのノードのプロパティとが存在することにより、ＡＭＬの動的生成は、比較的直接的なプロセスとなる。
さらに、ＡＣＰＩエージェント６０９自体は、いずれのバンヤンファームウェアプラットフォームに対しても完全に移植可能（バイナリ形式で再利用可能）となる。
【００５８】
物理プラットフォームの資源のデリファレンス（dereference）（アクセス）を行うＡＭＬオブジェクトは、オペレーション領域の名前を有するフィールドへのアクセスを通じて、デリファレンス（アクセス）を行うことができる。
オペレーション領域は、ＡＭＬの物理アドレスへのマッピングを提供する記述である。
このマッピングは、ＯＳカーネルのＡＣＰＩインタープリタ（ＯＳＰＭと呼ばれる）が、カーネルアドレス空間にインストールする。
これらのマッピングがないと、ＡＭＬは、ハードウェアに「接触（touch）」できず、その機能目的、例えば、カードのイジェクト、またはＬＥＤの点灯、またはハードウェアデバイスの有効化、を達成することができない。
この発明の一定の実施の形態では、ＡＣＰＩエージェント６０９は、ＡＣＰＩエージェント６０９がバンヤンコアデバイスツリー６０５から抽出したデータに基づいてＡＭＬを直接かつ動的に生成することにより、オペレーション領域の記述を構築することができる。
【００５９】
デバイスツリー６０５は、ランタイムにおいて、枝の動的な成長および削除を行うことができるので、（ＡＣＰＩモデルにおける）新しい物理資源は、ハードウェアの成長および収縮に整合するように追加または除去される。
これらの資源のいずれかがＡＭＬによってアクセスされることになると、それらの資源には、新しいオペレーション領域を記述するＡＭＬが付随する。
ＡＣＰＩエージェント６０９は、標準デバイスツリー６０５のデータプロパティを構文解析して、その内部のデータベースの表現を標準ＡＭＬ  ＳＳＤＴに変換することにより、新しいオペレーション領域のＡＭＬを動的に構築することができる。
【００６０】
これらのオペレーション領域を参照する各コンポーネント６０６のＡＭＬは、エージェント６０９がオペレーション領域を構築することを知って、記述される（すなわち生成される）。
それらのオペレーション領域により、ＡＭＬが解釈される際のエージェント６０９の機能が有効になる。
これらの型のＡＭＬおよび他の型のＡＭＬについて、静的にコンパイルされたＡＭＬデータプロパティは、「未解決の参照」を含み、したがって「不完全なもの」となる。
（オペレーション領域フィールドへの）参照は、コンパイル時には解決されず、コンパイル警告が発行されるが、それ以外は、機能的に完全である。
ＡＣＰＩエージェント６０９が、このようなＡＭＬを実際のＡＭＬに変換する時には、ＡＣＰＩエージェント６０９は、オペレーション領域を構築していることになり、ランタイムにおいて参照を修復することにより不完全なＡＭＬを解決することができる。
これは、オペレーティングシステム用の動的リンカが、動的にリンクされた共有ライブラリを使用するプロセスに対して行うのとほとんど同様である。
【００６１】
この実施態様の例において、ＡＭＬをバンヤンファームウェアアーキテクチャで動的に生成することは、４つの主要な段階を含む。
図６のコアのバンヤンシーケンサ６０３は、最初の２つのステップを駆動する。
ＡＣＰＩエージェント６０９としても知られているＡＣＰＩクライアントは、ＡＭＬが生成される最後の２つのステップをガイドする。
ＡＣＰＩエージェント６０９は、ＡＭＬを含まない静的ＡＣＰＩテーブル７０８の生成も行うことに留意することができる。
例として、ＲＳＤＰ、ＸＳＤＴ、およびＨＰＥＴがある。
図６のアーキテクチャ例では、静的テーブルがＡＭＬを含まない場合であっても、その内容がハードウェアコンフィギュレーションに依存する静的テーブルの正確な生成を容易にするのに、デバイスツリーデータベース６０５が重要となる。
このようなテーブルの例として、ＳＬＩＴ、ＳＲＡＴ、ＨＰＥＴ、およびＭＡＤＴがある。
静的テーブルの生成は、以下のステップ３の直前で行われ、ある最終セットアップは、次のステップ４で完了する。
一実施の形態において、ＡＭＬを動的に生成する４つの主要な段階は、次のとおりである。
（１）デバイスツリーのインスタンス化およびハードウェアの初期化（シーケンサ駆動）：
この段階は、ＡＣＰＩ名前空間がハードウェアをモデル化する方法と類似して（トポロジー的に）、利用可能なハードウェアの論理構成を反映する巡回容易なデータベースのデバイスごとのプロパティを提供する。
（２）ＡＭＬオブジェクトを生成するデバイスツリー巡回（シーケンサ駆動）：
この段階は、制御シーケンスにBuildAcpiObjects()（ＡＣＰＩオブジェクト構築（））メソッドを起動することを含む。
このメソッドは、所定のバンヤンコンポーネントによってエキスポートされる。
この所定のエキスポートするバンヤンコンポーネントとは、当該コンポーネントによるＡＣＰＩ名前空間の要求事項に基づいて、ＡＭＬを生成し、静的内容および動的内容を有するＡＣＰＩオブジェクト記述子の要素のそのリスト（配列）の初期化を担当する、あらゆるバンヤンコンポーネントである。
（３）ＡＣＰＩ名前空間パスを生成するデバイスツリー巡回（ＡＣＰＩクライアント駆動）：
この段階は再帰的である。
この段階では、デバイスツリーの各コンポーネントの正規のＡＣＰＩパスを構築することにより、コンピュータに対して、ＡＣＰＩ名前空間のスケルトンが開発される。
ＡＣＰＩ名前空間は、基本的には、ツリー形状のグラフである。
このグラフは、バンヤンデバイスツリーのサブツリーと同一構造であるが、ツリーのパスを表すのに特定のシンタックスを使用する。
バンヤンコンポーネントは、わずかに異なるトポロジー構成を有する異なるサーバで使用されることがあるので、ＡＣＰＩ名前空間トポロジーを事前（ブート前）に知ることはできない。
動的名前空間の作成および変更は、動的なＡＭＬの生成が解決する主要な問題の１つである。
（４）ＡＭＬ  ＤＤＢテーブルを構成するデバイスツリー巡回（ＡＣＰＩクライアント駆動）：
この段階では、各コンポーネントのＡＣＰＩオブジェクト記述子のプロパティおよびＡＣＰＩパス名のプロパティに記憶された情報が、ＡＣＰＩエージェントによって構文解析され、ＡＭＬ「デバイス定義ブロック」が、それらのテーブルヘッダと共に生成される。
これらのテーブルは、ＸＳＤＴに（ポインタを記憶することにより）配置される。
最後に、ＸＳＤＴのチェックサムおよび長さが計算され、ＲＳＤＰがＸＳＤＴを指し示すように設定され、そのアドレスが、ＥＦＩアダプタへハンドオフして、ロードされたオペレーティングシステムへその後配信するために保存される。
【００６２】
上述した最初の段階において、デバイスツリーデータベース６０５は、各ファームウェアコンポーネントのプラットフォーム特有のシーケンスの初期化を通じて構築される。
シーケンサ５０３として知られているバンヤンコアモジュールが、この段階を駆動する。
このツリー６０５は、バンヤンコンポーネントの集まりであり、複合設計パターンの一例である。
バンヤンコンポーネントは、コンピュータシステムの論理（ａ．ｋ．ａ．プログラミング）ビューをミラーリングすると言われている。
このマッピングにより、新しいハードウェア設計に整合したファームウェアコンポーネントの新しい構成を作成することが、より簡単になる。
【００６３】
ツリー６０５の各ノードは、記述バイナリデータ（プロパティとして知られている）のリストに加えて、そのコンポーネントの機能的役割に関係した実行可能なマシンコードの関数（メソッドとして知られている）への参照を保持する。
この手法は、クラスのインスタンスがオブジェクトとして知られているオブジェクト指向型プログラミングモデルと同様である。
プロパティのいくつかは、すべてのコンポーネントに共通した標準的なものであり、例えば、名前プロパティおよび型プロパティがある。
それ以外のものは、そのデバイスノードに特有のものである。
ＡＣＰＩ名前空間に反映されるデバイスツリー６０５のコンポーネントのすべては、プロパティ名ＡＣＰＩ＿Ｏｂｊｅｃｔ（ＡＣＰＩオブジェクト）も所有する。
これらのオブジェクトは、ＡＣＰＩオブジェクト記述子の要素からなるリスト（配列）である。
ＡＣＰＩ名前空間オブジェクトをも有するデバイスツリーノードの３つの例は、プロセッサデバイス、メモリデバイス、およびＩ／Ｏスロットデバイスである。
コンポーネントをモジュール化すること、および、コンポーネント特有のＡＣＰＩオブジェクトの知識を含めることにより、ＡＭＬの生成がモジュール化され、より一層再利用可能にもなる。
【００６４】
ＡＣＰＩエージェント６０９は、ＡＣＰＩオブジェクト記述子の要素（一種の擬似ＡＳＬ）のリストからＡＣＰＩ記述子テーブルのＡＭＬ（ＤＤＢ）を生成する。
このＡＣＰＩオブジェクト記述子の要素のそれぞれは、（通常）ＡＭＬ命令操作コードまたはデータオブジェクトを定義する。
これらのオブジェクト要素リストは、各バンヤンコンポーネント６０６によって（ステップ２の期間中に）生成されて、そのコンポーネントのＡＭＬオブジェクトを記述し、そして、グローバルプロパティとしてデバイスツリーノードに記憶される。
したがって、完全な記述子テーブルを生成することは、すべてのデバイスツリーコンポーネントからこれらのオブジェクトリストを処理して、記述子テーブルに含めることを含む。
【００６５】
ＡＣＰＩエージェント６０９は、２通過手法（上記ステップ３および４）を使用して記述子テーブルのＡＭＬを生成する。
第１の通過は、各コンポーネントのＡＣＰＩデバイスパスを生成するために使用される。
これらのデバイスパスは、コンポーネントノードのそれぞれにグローバルプロパティとして記憶される。
第２の通過は、必要に応じて第１の通過から生成されたデバイスパスを使用して、実際のＡＭＬを生成する。
【００６６】
図９Ａおよび図９Ｂ（以下にさらに解説する）は、動的なＡＭＬ生成機能によってサポートされる２つの原則的な使用ケースであるブート時および実行時を示している。
両者には、同じ機能が使用され、それらの起動のシーケンスが異なるだけである。
【００６７】
図６のアーキテクチャ例では、コアセルは、除去できないことから、常に、ＤＳＤＴに記述される一方、各追加セルは、個別のＳＳＤＴに記述される。
このアーキテクチャ例では、個々にロードされたテーブルは、名前空間から個々にアンロードできるだけであるので、セルごとに個別のＳＳＤＴテーブルが使用される。
実行中のシステムにセルが追加される場合、ＡＭＬの動的生成の重要なステップは、ブート時のものと同一である。
しかし、実行中の名前空間への新しいテーブルのロードには、より複雑な調整およびＡＣＰＩ２．０のＬｏａｄＴａｂｌｅ（ロードテーブル）という命令操作コードの使用が必要となる。
【００６８】
以下に説明する図９Ａおよび図９Ｂは、一実施の形態に従って、名前空間を成長させる資源に対してＡＭＬ生成をどのように行うのかの概要を示している。
同様の協力は、一定の実施の形態において、Ｕｎｌｏａｄ（アンロード）命令操作コードの使用を通じて、セルを除去し、その対応する名前空間の要素を取り除くために行うことができる。
【００６９】
バンヤンアーキテクチャの２つの態様を結合することにより、動的なＡＭＬ生成が可能になる。
これら２つは、
（１）集約することによってコンピュータシステムを形成するハードウェア素子の物理トポロジーを記述するデバイスツリー６０５、および、
（２）デバイスツリー６０５の各ノードに含まれ得る記述オブジェクト（すなわち「プロパティ」）
である。
したがって、記述オブジェクトは、いくつかのＡＣＰＩプロパティを定義することができる。
これらのＡＣＰＩプロパティは、ＡＣＰＩエージェント６０９によって使用される。
したがって、例えば、新しいコンポーネントを書き込んでいる開発者は、自身のハードウェアにリアルタイムクロックを使用することができ、そのクロック用のＡＭＬコードを開発することができる。
より具体的には、その開発者は、そのハードウェアデバイス用のプロパティを生成することができ、そのデバイスのファームウェアは、デバイスがシステムに追加された時に、データベース６０１にこのプロパティを書き込む。
ＡＣＰＩエージェント６０９は、その後、ツリー６０５のそれらのプロパティを摘み取って、それらのプロパティをＡＣＰＩテーブルに構築することができる。
したがって、ハードウェアデバイス用のコンポーネントコード（例えば、リアルタイムクロック用のコード）は、ＡＣＰＩのわずかな部分、すなわち、それらのハードウェアに関連した部分のみを含まなければならないだけであり、エージェント６０９は、ハードウェア特有のコードをなんら知る必要はなく、それらのコードを得る方法だけを知らなければならない。
一実施の形態は、ハードウェア特有の特徴を広範囲に記述する能力をデータベースに提供し、次いで、システムのフレームワークの部分が、それらの記述にアクセスして、それらの記述をＡＣＰＩに変換する。
一実施の形態のこのフレームワークプラスコンポーネントアーキテクチャは、そのフレームワークにおいて高い再利用可能性を提供し、ハードウェア特有の記述（例えばＡＭＬ）を含むコンポーネントの追加を可能にする。
【００７０】
図７を参照して、図７は、図４のＡＣＰＩ互換システムで実施される本発明の一実施の形態の一例のブロック図を示している。
図示するように、システムファームウェアレベル３０７には、ＡＣＰＩエージェント２０７、データベース２０６、およびデバイス認識ファームウェア２０５が含まれる。
この例では、新しいハードウェアデバイスＡおよびＢが、プラットフォームハードウェア３０１内に追加される。
さらに、ファームウェアレイヤ３０７には、追加されるデバイスＡに関連付けられたファームウェア７０１、および、追加されるデバイスＢに関連付けられたファームウェア７０２が含まれる。
各デバイスの関連付けられたファームウェア７０１、７０２は、そのそれぞれのハードウェアデバイス用のデバイス特有の記述子（例えばＡＭＬコード）を含む。
デバイス認識ファームウェア２０５は、ファームウェア７０１、７０２から記述子を検索し、そのデバイス特有の記述子（すなわち「プロパティ」）をデータベース２０６に記憶する。
その後、上述したように、ＡＣＰＩエージェント２０７が、データベース２０６にアクセスし、デバイス特有の記述子を使用して、追加されたハードウェアデバイスＡおよびＢに必要なＡＣＰＩテーブルエントリを生成するように動作できる。
例えば、ＡＣＰＩエージェント２０７は、データベース２０６に各デバイス用に記憶された記述子に基づいて、各デバイスに必要なＡＭＬコードを生成し、ＡＣＰＩテーブル４０５にそのＡＭＬコードを記憶するように動作できる。
【００７１】
図８を参照して、図８は、本発明の一実施の形態に従って、新しいハードウェアデバイスをシステムで実施する一例の操作フロー図を示している。
図示するように、操作ブロック８０１において、開発者が、デバイス特有のファームウェアを作成する。
このファームウェアは、システムに追加されるハードウェアデバイスに必要なあらゆるＡＭＬコードを含むことができる。
例えば、ハードウェアデバイスが、リアルタイムクロックを必要とする場合、開発者は、そのリアルタイムクロック機能を実施するＡＭＬコードをデバイス特有のファームウェアに含めることができる。
操作ブロック８０２において、ハードウェアデバイスおよびデバイス特有のファームウェアが、システムに追加される。
次いで、操作ブロック８０３において、デバイス認識ファームウェアが、新しいハードウェアデバイスがシステムに追加されたことを認識し、デバイス特有のファームウェア（例えば、そのデバイスの記述子。
この記述子はＡＭＬコードを含むことができる）からの情報を使用して、デバイス特有のプロパティを有するデバイスエントリを作成する。
【００７２】
操作ブロック８０４において、ＡＣＰＩエージェントが、デバイスにアクセスし、追加されたハードウェアデバイスの（必要なあらゆるＡＭＬコードを有する）ＡＣＰＩテーブルエントリを自律的に構築する。
次いで、操作ブロック８０５において、ＯＳが、ＡＣＰＩテーブルと相互作用して、追加されたハードウェアデバイスを管理するために、このようなデバイスの記述を取得する。
【００７３】
図９Ａおよび図９Ｂは、システムが、新しく追加されたハードウェアデバイスのＡＣＰＩテーブルエントリ（追加されたあらゆるＡＭＬコードを含む）を自律的に生成する、本発明の例の操作フロー図を示している。
より具体的には、図９Ａは、システムのブートアッププロセス中のシステムの一例の操作フロー図を示し、図９Ｂは、システムのランタイム中のシステムの一例の操作フロー図を示している。
【００７４】
図９Ａは、電源投入からのコンピュータシステムの初期ブートストラップの一例の操作フロー図９００を示している。
例えば、あるシステムは、例えば１６個のセルならびに最大１２８個のプロセッサおよび最大１９２個のＩ／Ｏカードを備えるセルラシステムで実施されることがあるので、動的なＡＭＬ生成が有益となる。
したがって、このようなセルラシステムのサーバハードウェアを構成するには、１６の階乗（１６！）個の異なる並べ替え（合計で２０兆個を越える異なる並べ替え）が存在し得る。
このようなセルラシステムでは、ファームウェアが、異なる構成のどの１つにブートアップ中であるのかを事前に知ることなく、他のシステムを使用して、セルのすべてについて正確なＡＭＬを生成することができる。
【００７５】
操作ブロック９０２は、初期状態であり、コンピュータのすべてのハードウェア素子のほぼ同時の電源投入への移行およびファームウェアの実行開始を表す。
（マルチセルコンフィギュレーションの）各セルは、同じファームウェアのコピーを含み、「パーティション」と呼ばれるものを形成する際に当該パーティションに加入することになる他のセルを（現在のところ）知ることなく、その初期化を開始する。
したがって、各セルは、フレームワークの初期化の操作ブロック９０３およびセルツリーの構築の操作ブロック９０４を、それ自身の構成されたハードウェアに従って並列に実行することができる。
１つのセルが、ルート（君主と呼ばれることがある）セルとして選ばれる。
残りのセルは、いわゆるスレーブセルとなる。
これらのスリーブセルは、ルートセルによる通知（図示せず）を受けるまで、待ち状態（図示せず）に入り、ＯＳローダの起動９１３の前に、ＯＳ待ち合わせ状態に入ってコマンドを待ち、そして、実行中のＯＳと合流する。
【００７６】
ルートセルとして選ばれたセルは、パーティションツリーの構築９０５に入る。
パーティションツリーの構築９０５では、最上位レベルのデバイスツリールートが作成され、各セルのデバイスツリーのすべてが、そのルートに接合される。
これは、パーティションツリーを作成する。
このパーティションツリーは、現在パーティションに構成されたすべてのハードウェアの記述データベースのすべてを保持する。
それが、生成されるＡＣＰＩテーブルに記述されるべきこのハードウェアのすべてである。
上記ステップのシーケンスは、（図６の）シーケンサ６０３によってガイドされ、まず第１に、バンヤンファームウェアシステムの例におけるデバイスツリー６０５、コンポーネント６０６、プラットフォームハードウェア３０１、およびコアフレームワーク６０２の要素間の広範な協力を伴う。
【００７７】
ルートセルで単独で実行されるシーケンサ６０３は、ブートストラップを続けて、パーティションツリーデータベース６０５全体を巡回して、ツリー内に表現された各コンポーネントを突き止める。
また、シーケンサ６０３は、ステップ９０６で、BuildAcpiObjects()サービスをエキスポートして、ＡＣＰＩオブジェクトも構築する。
このようなサービスを有するもののそれぞれに対して、そのサービスは起動される。
これらの関数は、（以下に説明するソフトウェア方法論の例でさらに説明するように）デバイスごとのＡＣＰＩオブジェクトエントリのリストを作成する。
このリストの作成は、実際のＡＭＬの生成に先立って行われる。
オブジェクトエントリリストは、デバイスツリー６０５の各コンポーネント６０６のノードに記憶される。
【００７８】
操作ブロック９０６におけるＡＣＰＩオブジェクトエントリリストのプロパティの生成に続いて、バンヤンコア６０１のさまざまなクライアント６０９、６１０、６１１、および６１２が、クライアントのロードステップ９０７において、ＲＯＭからメインメモリにロードされ、それらの場所が記憶される。
【００７９】
シーケンサ６０３によってＡＣＰＩクライアント６０９に制御が与えられ、このコードは、固定テーブルの生成ステップ９０８を実行する。
次いで、実行は、通過１−ＡＣＰＩパスの生成９０９に進む。
通過１−ＡＣＰＩパスの生成９０９では、デバイスツリー６０５が巡回されて、ＡＣＰＩ名前空間がスケルトンの形で作成される。
これからＯＳ内部のＡＣＰＩ名前空間の一部となるデバイスツリー６０５の各コンポーネント６０６には、そのＡＣＰＩ名を保持するプロパティが与えられる。
これらのプロパティは、次の通過２−ＡＭＬの生成ステップ９１０で使用されて、ＡＭＬを必要とする正確なＡＣＰＩパス参照が、Notify（通知）命令操作コードのオペランド１のようなＡＭＬにコード化される。
生成されたＡＭＬは、ＤＳＤＴ（ＲＯＯＴセル記述用）またはルートでない個々のセルごとの個々のＳＳＤＴのいずれかとしてＡＣＰＩ  ＸＳＤＴテーブルに置かれる。
すべての下位（接続されたデバイス）の要素は、そのルートでないセルに属する。
動的なＡＭＬ生成は、このステップで完了する。
実際のＡＣＰＩ名前空間は、ＯＳが、ＡＣＰＩテーブルを構文解析し、実際のＡＣＰＩ名前空間を作成するさらに後（図示せず）になるまで作成されない。
【００８０】
次に、ＳＡＬアダプタの初期化ステップ９１１において、シーケンサ６０３が、ＳＡＬアダプタクライアント６１１を起動し、次に、ＳＡＬアダプタクライアント６１１は、ＥＦＩアダプタの初期化ステップ９１２において、ＥＦＩ  ＡＢＩアダプタ６１０を起動する。
最後に、ＥＦＩアダプタは、ステップ９１３において、オペレーティングシステムローダを起動する。
【００８１】
図９Ｂは、先のある時にすでにブートされ、現在実行中のシステムにセルを追加することの一部として、動的なＡＭＬ生成を伴う制御シーケンス例を示している。
一般に、セルは、メモリ、プロセッサ、およびオプションとしてのＩ／Ｏハードウェア接続を含む。
これらの資源のすべてが、このような資源を実行中のＯＳに対して記述するために生成される新しいＡＭＬコードを必要とすることがある。
そして、このような新しいＡＭＬは、既存のＡＣＰＩ名前空間にロードされることになる。
このＡＣＰＩ名前空間は、図９Ａのブートアップフローを使用して提供されたＡＣＰＩテーブルからブート時に構築されたものである。
【００８２】
図９Ｂは、新しいハードウェアであるセルが、実行中のコンピュータに追加される時の本発明の一実施の形態のオペレーション例を示している。
この実行中のコンピュータは、１つまたは２つ以上のセルを有し、これらのセルは、すでにアクティブであり、ＡＣＰＩ名前空間に記述されている。
この例におけるＡＭＬ生成のいくつかのステップは、図９Ａのブートアップオペレーションのものと同一のファームウェアを必要とするが、それらのステップは、異なった順序に並べられている。
比較のため先を見ると、ステップ９１７は、ステップ９０３と等しい。
ステップ９１８は、ステップ９０４と等しい。
ステップ９２１および９２４は、共にステップ９０５と類似する。
ステップ９２５は、ステップ９０６と類似する。
ステップ９２６は、（既存のセルは、自身のパス識別情報をすでに所有するので、新しいセルのパスのみが生成されることを除いて）ステップ９０８と類似する。
ステップ９２７は、ステップ９１０と等しい。
このように、一定の解法ステップ（例えば、ファームウェアの機能的部分）は、ブート時に加えて、ランタイムにおけるＡＭＬの生成にも使用される。
したがって、この実施の形態により、ブート時の実施およびランタイムの実施に対して、このような機能コンポーネントの効率的な再利用が可能になる。
【００８３】
図９Ｂのセル内部９１４は、セルがパーティションの一部となる前にセルの内部プロセッサによって実行されるステップを示している。
図９Ｂのパーティション内部９１５は、実行中のパーティションにすでに属する１つまたは２つ以上のプロセッサによって実行されるステップを示している。
ハードウェアが、ファームウェアによって適切にプログラミングされるまで、これら２つのグループのプロセッサは、他方のグループの資源にアクセスできないことに留意すべきである。
このことは、メンバでないプロセッサによるアクセスを阻止する各セルのチップセットハードウェアで実施されるいわゆるファイアウォールのためである。
この能力は、これらの再構成可能なセルラサーバ、例えば図９Ａおよび図９Ｂと共に説明しているこのセルラシステム例におけるハードパーティションの基本的な価値である。
【００８４】
セルの追加９１６は、未加入セル（free cell）を（管理性プロセッサ（manageability processor）が所有する不揮発性のグローバルデータベースを操作することにより）、ある既存のパーティションの新しい「対象となる」メンバとしてコンフィギュレーションした後、当該未加入セルの物理的なインストールおよび電源投入、または、単なる電源投入のいずれかを行うことを表す。
これにより、このセルは、新しいパーティションの一部となるためにブートを開始する。
ステップ９０３と同様に、フレームワークの初期化９１７は、そのセルに属する（セル内部の、または、セルに接続された）プロセッサ、メモリ、およびＩ／Ｏ資源の発見および初期化を開始する。
セルツリーの構築ステップ９１８は、ファームウェアコンポーネントからなる、セルのローカルデバイスツリーを構築し、そして、セルのパーティションマップをプログラミングして、そのセルが加入しているパーティション内のプロセッサによるアクセスを可能にする。
この時点において、準備のアナウンス９１９で、これらのステップをガイドしているシーケンサ６０３が、パーティションに加入する準備ができたパーティション（１つまたは複数）を「外部」の管理性サブシステムに通知する。
このセルは、その後、加入の通知を受けるまで待ち状態９２０に入る。
【００８５】
矢印９３４は、イベントが、管理性サブシステムによってアクティブなパーティションに信号で送られることを示している。
このイベントは、ＯＳによる処理９２２を受けて、ＡＣＰＩ名前空間のＡＭＬファームウェアに渡される。
このファームウェアは、コアファームウェア９２３の起動を準備する。
コアファームウェア９２３は、ＡＭＬのハードウェア設計および制限に必要とされる。
【００８６】
パーティションへのセルの接合９２４は、パーティション内部でコアファームウェア９２３を実行するプロセッサと、パーティションへの加入９２１を実行する制御（君主）プロセッサとの間の協力によって行われる。
この協力プロセスは、矢印９３５の形で表されている。
このステップの後、セルは、パーティションの内部に含まれ、そのプロセッサは、ＯＳに利用可能となる。
ただし、ＯＳは、まだ、この新しいハードウェアについて知らない。
このシーケンスの残りの部分は、この新しいハードウェアを記述することになるＡＭＬを生成し、このＡＭＬをＯＳに利用可能にする。
【００８７】
セルが、パーティションツリーの一部になるので、セルのＡＣＰＩオブジェクトの構築ステップ９２５を起動することができる。
このステップは、１つのセル（新しいセル）だけが、当該セルのオブジェクトを有する点を除いて、９０６によって表されるものと同様である。
そのオブジェクトとは、セルのローカルデバイスツリーの各コンポーネントの巡回により構築され、そのコンポーネントにおいて検出されたBuildAcpiObjects()メソッドを起動するものである。
このステップの後、コアファームウェアが、ＡＣＰＩクライアント６０９の特別なエントリを起動し、それによって、単一のセルのＡＭＬが作成される。
これは、ＡＣＰＩパスの生成９２６（通過１）から開始して、ＡＭＬの生成９２７（通過２）に続く。
【００８８】
新しいＳＳＤＴが構築され、この新しいＡＭＬテーブルへのポインタは、ブート時に使用された既存のＸＳＤＴに配置される（ＳＳＤＴのＸＳＤＴへの挿入９２８）。
このＸＳＤＴの再利用を実現するために、ＡＣＰＩテーブルは、ＯＳによって再生されることはない。
ファームウェアは、ＥｆｉＡＣＰＩＭｅｍｏｒｙＮＶＳ（ＥｆｉＡＣＰＩメモリＮＶＳ）としてこれらのテーブルを含むメモリを記述することを通じて、これを保証する。
このＥｆｉＡＣＰＩＭｅｍｏｒｙＮＶＳは、編成されたメソッドであり、ＡＣＰＩおよびＥＦＩの標準で記述されたLoadTable()（テーブルロード（））命令操作コードをサポートする。
ステップ９２８の一部は、未加入のエントリを検出すること、ＸＳＤＴヘッダの長さフィールドおよびチェックサムフィールドを再計算することとを含む。
したがって、ＯＳが、その後、ＸＳＤＴを（探索して）再度構文解析しても（ステップ９３１）、エラーは、発生しない。
【００８９】
プロセッサが開始したコアファームウェアの制御をＯＳに戻す直前に、ファームウェアは、ＬｏａｄＴａｂｌｅ  ＧＰＥ（ロードテーブルＧＰＥ）のアサート９２９を行う。
これにより、特定のＡＭＬメソッドが、その後、ＧＰＥの処理９３０で実行される。
これらの特定のＡＭＬメソッドの１つは、初期のステップ９２２で保持された情報を当該メソッドの１つに渡すLoadTable()命令操作コードを起動する。
これにより、ＯＳは、新しいテーブルを得るためにＸＳＤＴを探索することが可能になり、まだそこに存在するそれ以外のテーブルを無視することが可能になる。
テーブルがロードされると、新しいＡＭＬのすべてが、既存のＡＣＰＩ名前空間の一部になる（コアファームウェアが、ステップ９２４でデバイスツリーに共に接合される方法と同様に、新しいＡＭＬのすべては、既存のＡＣＰＩ名前空間に接合される）。
LoadTable()を起動したＡＭＬファームウェアの最後のステップは、Notify()命令操作コード９３２を起動して、ＯＳに通知を行うことである。
この通知は、新しい資源が名前空間に存在すること、当該資源がＯＳによって数え上げられ、かつ、要求されるべきであること、および、当該資源がアプリケーションに利用可能にされるべきであること９３３を示す。
【００９０】
［一実施の形態の実施に使用されるソフトウェア方法論の一例］
次に、この発明の一実施の形態の実施に使用される一定のソフトウェア方法論を説明する。
これらの詳細は、ソフトウェア設計であり、使用される表記および記述は、ファームウェアを記述するソフトウェア開発者によく知られているものである。
【００９１】
<オブジェクト記述子の要素>
ＡＣＰＩエージェント６０９に使用されてＡＭＬを生成するＡＣＰＩオブジェクト記述子の要素リストは、生成されるＡＭＬオブジェクトの記述を含んだデータ構造体のリストである。
このリストにおける要素ごとのデータ構造体は、以下のフォーマットを有する。
typedef struct {
unit8  name[4];
unit8  type;
unit8  dtype;
union {
unit64  data[3];
unit8   string[24];
} u;
acpi_object_entry_t;
【００９２】
name（名前）フィールドは、ＡＣＰＩオブジェクト名（例えば、Device（デバイス）、Method（メソッド）、Name（名前）など）を必要とするそれらＡＭＬオブジェクトのＡＣＰＩオブジェクト名を提供するために使用される。
type（型）フィールドは、記述されているＡＭＬオブジェクト型（例えば、Device、Name、Methodなど）を定義するために使用される。
dtype（データ型）フィールドは、ＡＭＬオブジェクトに関連付けられたデータ型（例えば、BYTE（バイト）、WORD（ワード）、DWORD（ダブルワード）など）がもしあれば、そのデータ型を定義するために使用される。
すべてのオブジェクトが、関連付けられたデータを有するとは限らないであろう。
このデータ共用体（union）フィールドは、任意の関連付けられたデータオブジェクトを渡すために使用される。
この共用体がどのように使用されるかは、オブジェクト型によって決定されるが、以下のいくつかの一般的な規約が使用される。
u.data[0]は、データ値、ノードポインタ、およびバッファポインタを渡すために使用される。
u.data[1]は、メソッドフラグを渡すために使用される。
u.data[2]は、要素カウント、バッファ長、または引数カウントを渡すために使用される。
u.stringは、文字列の値に使用される。
【００９３】
<ＡＣＰＩ要素オブジェクトフラグ>
オブジェクト記述子の要素のflags（フラグ）フィールドは、ＡＭＬ生成の変更に使用できるフラグを指定するために使用される。
以下のフラグがサポートされている。
（これらは、Ｃ言語ソースの#defineマニフェスト定数である。）
【００９４】
ACPI_OBJECT_BUILD_MASK（ＡＣＰＩオブジェクト構築マスク）：
flagsフィールドの下位６ビットは、オブジェクトのＡＣＰＩ構築マスクビットを指定するために使用される。
このフィールドによって指定されたＡＣＰＩ構築マスクの指定ビット（０〜６３）が設定されていない場合には、そのオブジェクトは、ＡＣＰＩエージェントによってスキップされることになり、このオブジェクトによって制御されるＡＭＬは省略される。
Scope()（スコープ（））オブジェクト、Device()（デバイス（））オブジェクト、Processor()（プロセッサ（））オブジェクト、およびMethod()（メソッド（））オブジェクトの場合、そのオブジェクトを無視することにより、そのオブジェクトのスコープ内に含まれるすべてのオブジェクトも無視される。
このフィールドが０である場合、そのオブジェクトは、ＡＣＰＩ構築マスクによって影響を受けないことになり、オブジェクトの内容（ヌルの場合もある）に従ってＡＭＬが生成されるであろう。
ＡＣＰＩ構築マスクは、ブートプロセスの初期に、専門家ユーザによってDUI acpi_dbgコマンドで制御することができる。
【００９５】
以下の構築マスクの選択項目が現在サポートされている。
【００９６】
【表１】
2004355620.tif 000003
【００９７】
ACPI_OBJECT_FLAG_NONCORE（ＡＣＰＩオブジェクトフラグ非コア）：
このフラグは、設定されると、非コアセルの場合にのみ、そのオブジェクトが処理されるべきであることを示すであろう。
コアセルの場合、そのオブジェクトは無視されるであろう。
【００９８】
ACPI_OBJECT_FLAG_CORE（ＡＣＰＩオブジェクトフラグコア）：
このフラグは、設定されると、コアセルの場合にのみ、そのオブジェクトが処理されるべきであることを示すであろう。
非コアセルの場合、そのオブジェクトは無視されるであろう。
【００９９】
ACPI_OBJECT_FLAG_END（ＡＣＰＩオブジェクトフラグエンド）：
このフラグは、設定されると、このオブジェクト要素が、現在のスコープ（Scope()、Processor()、またはMethod()）の最後の要素であることを示す。
このフラグは、スコープをクローズするために、特定のＥＮＤオブジェクトの代わりに使用することができる。
【０１００】
ACPI_OBJECT_FLAG_EXTENSION（ＡＣＰＩオブジェクトフラグ拡張）：
このフラグは、設定されると、拡張オブジェクト（１つまたは複数）が含まれることを示す。
拡張オブジェクトは、いくつかのオブジェクト型に対してデータ要素を指定するために使用される。
【０１０１】
<ＡＣＰＩ要素データ型>
データオブジェクトを含むか、またはデータオブジェクトを記述するＡＣＰＩオブジェクトの場合、生成されるデータオブジェクトの型が、dtypeパラメータによって指定される。
実際のデータまたはデータへのポインタは、データ共用体で渡される。
データ型フィールドに加えて、データ型と共に使用できる以下の２つのデータ修飾フラグがある。
（１）ACPI_DATA_TYPE_EXTERN（ＡＣＰＩデータ型＿外部）：
これは、データが、オブジェクトに直接記憶されているのではなく、実際には、コンポーネントノードのグローバルプロパティに記憶されていることを指定するために使用することができる。
この場合、オブジェクトのデータフィールドは、実際のデータが記憶されているグローバルプロパティを指定するＡＳＣＩＩ文字列（長さは最大２３バイトまで）を含むであろう。
記憶されたデータのフォーマットは、データ型フィールドによって指定される。
（２）ACPI_DATA_TYPE_UNICODE（ＡＣＰＩデータ型＿ユニコード）：
これは、渡されたＡＳＣＩＩ文字列が、記述子テーブルに記憶される前に、ＵＮＩＣＯＤＥ（ユニコード）に変換されるべきであることを示すために、文字列データ型と共に使用することができる。
【０１０２】
以下のデータ型が、現在、ＡＣＰＩエージェント６０９によってサポートされているものである。
【０１０３】
ACPI_DATA_TYPE_NONE（ＡＣＰＩデータ型＿ＮＯＮＥ）：
この要素に関連付けられたデータオブジェクトが存在しないことを示す。
【０１０４】
ACPI_DATA_TYPE_BYTE（ＡＣＰＩデータ型＿バイト）：
byte（バイト）データオブジェクトが生成されるであろう。８ビットデータ値が、DATA[0]フィールドに含まれる。
【０１０５】
ACPI_DATA_TYPE_WORD（ＡＣＰＩデータ型＿ワード）：
word（ワード）データオブジェクトが生成されるであろう。１６ビットデータ値が、data[0]フィールドに記憶される。
【０１０６】
ACPI_DATA_TYPE_DWORD（ＡＣＰＩデータ型＿ＤＷＯＲＤ）：
dword（ダブルワード）データオブジェクトが生成されるであろう。３２ビットデータ値が、data[0]フィールドに記憶される。
【０１０７】
ACPI_DATA_TYPE_QWORD（ＡＣＰＩデータ型＿ＱＷＯＲＤ）：
qword（クアドワード）データオブジェクトが生成されるであろう。６４ビットデータ値が、data[0]フィールドに記憶される。
【０１０８】
ACPI_DATA_TYPE_STRING（ＡＣＰＩデータ型＿文字列）：
string（文字列）データオブジェクトが生成されるであろう。
短い（<２４バイト）文字列が、stringフィールドに含まれる。
ACPI_DATA_TYPE_UNICODE修飾フラグが、このデータ型と共に使用されると、ＡＳＣＩＩ文字列は、記述子テーブルに記憶される前に、ユニコード文字列に変換されることになる。
この場合、buffer（バッファ）オブジェクトが生成されて、ユニコード文字列を収容する。
【０１０９】
ACPI_DATA_TYPE_LONG_STRING（ＡＣＰＩデータ型＿ロング文字列）：
stringデータオブジェクトが生成されるであろう。
長い（>＝２４バイト）文字列が、バッファに含まれる。
このバッファのポインタが、data[0]フィールドに記憶され、その長さが、data[2]フィールドに記憶される。
しかしながら、ACPI_DATA_TYPE_EXTERNフラグが、このデータ型に対して設定されている場合、stringフィールドは、実際の文字列が記憶されるコンポーネントノードのグローバルプロパティを含むことになる。
ＡＣＰＩエージェントは、オブジェクトの処理を行う前に、目的のプロパティを読み込み、バッファポイントフィールドおよび長さフィールドをそのオブジェクトに記憶する。
ACPI_DATA_TYPE_UNICODE修飾フラグが含まれている場合、ＡＳＣＩＩ文字列は、記述子テーブルに記憶される前に、ユニコード文字列に変換されることになる。
この場合、bufferＡＣＰＩオブジェクトが生成される。
【０１１０】
ACPI_DATA_TYPE_PACKAGE（ＡＣＰＩデータ型＿パッケージ）：
package（パッケージ）データオブジェクトが生成されるであろう。
このパッケージに含める要素のリストは、以下の３つの方法の１つで指定することができる。
（１）ACPI_OBJECT_FLAG_EXTENSIONフラグが設定されており、かつ、ACPI_DATA_TYPE_EXTERNフラグが設定されていない場合、パッケージ要素は、このデータ型に続くオブジェクト記述子のリストに含まれる。
data[2]フィールドは、パッケージの要素数を含む。
ACPI_OBJECT_TYPE_EXTENSIONの説明を参照されたい。
（２）ACPI_OBJECT_FLAG_EXTENSIONフラグが設定されておらず、かつ、ACPI_DATA_TYPE_EXTERNフラグも設定されていない場合、data[0]フィールドは、その要素を含んだオブジェクト記述子リストが含まれているバッファへのポインタを含む。
data[2]フィールドは、パッケージに含める要素数を含む。
（３）ACPI_DATA_TYPE_EXTERNフラグが設定されている場合、stringフィールドは、要素オブジェクト記述子リストが含まれるコンポーネントノードのグローバルプロパティ名を含むことになる。
この場合、ＡＣＰＩエージェントは、そのプロパティから要素リストを読み出し、オブジェクトを処理する前に、バッファへのポインタおよび要素カウントをオブジェクトに記憶するであろう。
【０１１１】
パッケージ要素リストは、ＡＣＰＩ要素構造体のリストとして記憶される。
この要素リストの各オブジェクトは、ACPI_OBJECT_TYPE_EXTENSIONのtypeを有し、要素リストの最後のオブジェクトを除くすべのオブジェクトは、ACPI_OBJECT_FLAG_EXTENSIONフラグが設定される。
【０１１２】
ACPI_DATA_TYPE_BUFFER（ＡＣＰＩデータ型＿バッファ）：
Buffer()（バッファ（））オブジェクトが生成される。
このオブジェクトに含めるバイナリデータは、data[0]フィールドによって指し示され、バッファの長さは、data[2]フィールドに含まれる。
ACPI_OBJECT_TYPE_EXTERNフラグが、このデータ型に対して設定されている場合、stringフィールドは、実際のバッファデータが記憶されるコンポーネントノードのグローバルプロパティ名を含むことになる。
ＡＣＰＩエージェントは、オブジェクトの処理を行う前に、目的のプロパティを読み込み、バッファポインタおよびバッファの長さをそのオブジェクトに記憶するであろう。
【０１１３】
ACPI_DATA_TYPE_NODE（ＡＣＰＩデータ型＿ノード）：
このデータ型は、デバイスツリーノードポインタが、data[0]フィールドに含まれることを指定する。
ポインタをどのように処理するかは、オブジェクト型に依存する。
【０１１４】
ACPI_DATA_TYPE_LOCALOP（ＡＣＰＩデータ型＿ローカルＯＰ）：
ＡＭＬローカル変数命令操作コードが、通常、ACPI_OBJECT_TYPE_STORE要素と共に生成されるStore()（記憶（））命令操作コードの目的（第２）のオペランドとして、生成される。
data[0]フィールドは、選択された命令操作コードに対して指定された｛０…７｝（それぞれ、ローカル０，…，ローカル７）を含む。
【０１１５】
ACPI_DATA_TYPE_NAMESEG（ＡＣＰＩデータ型＿名前ＳＥＧ）：
マルチセグメント名オブジェクトが生成される。
連鎖した名前セグメントを含むバッファへのポインタが、data[0]フィールドに含まれ、名前セグメントカウントが、data[2]フィールドに含まれる。
これらの名前セグメントは、長さがそれぞれ４バイトである。
ACPI_DATA_TYPE_EXTERNフラグが、このデータ型に対して設定されている場合、stringフィールドは、実際の名前セグメントデータが記憶されるコンポーネントノードのグローバルプロパティ名を含むことになる。
ＡＣＰＩエージェントは、オブジェクトの処理を行う前に、目的のプロパティを読み込み、名前セグメントポインタおよびセグメントカウントをそのオブジェクトに記憶するであろう。
【０１１６】
ACPI_DATA_TYPE_ROOTED_PATH（ＡＣＰＩデータ型＿ルートパス）：
完全なＡＣＰＩデバイス／オブジェクトパスが生成されるであろう。
このパスは、＼でルートが示される。
バンヤンデバイスのノードハンドルのＡＣＰＩパスが生成される場合、このバンヤンデバイスのノードハンドルは、data[0]フィールドに含まれる。
バンヤンノードのＡＣＰＩデバイスパスは、ＡＣＰＩクライアント記述子テーブル生成の第１の通過で生成され、そのノードのプロパティリストに、ACPI_PATH_PROPERTYという名前のプロパティとして記憶される。
次いで、data[0]フィールドおよびdata[2]フィールドは、このプロパティのアドレスおよびパスセグメント数を保持するように更新される。
第２の通過において、ＡＭＬが生成されると、オブジェクトは、ACPI_DATA_TYPE_NAMESEGと同様に処理される。
ＡＣＰＩエージェントは、パスオブジェクトを構築すると、パス分離文字を追加するであろう。
【０１１７】
ACPI_DATA_TYPE_LITERAL（ＡＣＰＩデータ型＿リテラル）：
data[0]から変換された１バイトのリテラルが生成され、ＡＭＬバイトストリームにされる。
非常に限られた方法で請求（sue）されて（１または０を生成し）、スマートオブジェクトによって廃棄（obsolete）されることがある。
【０１１８】
ACPI_DATA_TYPE_ZERO（ＡＣＰＩデータ型＿ゼロ）：
ＡＣＰＩエージェントに０ｘ００が生成させて、ＡＭＬバイトストリームにする。
【０１１９】
ACPI_DATA_TYPE_LOCATION（ＡＣＰＩデータ型＿位置）：
これは、＿ＳＴＲオブジェクトを生成するためだけに設計された特定のハイレベルオブジェクトである。
＿ＳＴＲオブジェクトは、バッファオブジェクトであり、その内容は、ユニコードでコード化された、デバイス記述を表す文字列である。
【０１２０】
<ＡＣＰＩ要素オブジェクト型>
ＡＣＰＩオブジェクト要素構造体のtypeフィールドは、生成されるＡＣＰＩ  ＡＭＬオブジェクトの型を定義する。
ＡＣＰＩエージェントは、現在、以下のＡＣＰＩオブジェクト型をサポートしている。
【０１２１】
ACPI_OBJECT_TYPE_NONE（ＡＣＰＩオブジェクト型＿ＮＯＮＥ）：
このオブジェクト型により、オブジェクトエントリは、スキップされることになる。
【０１２２】
ACPI_OBJECT_TYPE_NAME（ＡＣＰＩオブジェクト型＿名前）：
Name()（名前（））オブジェクトが生成されるであろう。
nameフィールドは、４文字のＡＣＰＩ名を含む。
dtypeフィールドは、これから生成される関連付けられたデータオブジェクト（もしあれば）を指定する。
【０１２３】
ACPI_OBJECT_TYPE_OPREGION（ＡＣＰＩオブジェクト型＿ＯＰ領域）：
OpRegion()（Ｏｐ領域（））オブジェクトが生成されるであろう。
nameフィールドは、４文字のＯｐＲｅｇｉｏｎ名を含む。
ＡＣＰＩコード化を使用して、ＯｐＲｅｇｉｏｎ型は、data[0]フィールドに含まれ、ＯｐＲｅｇｉｏｎオフセットは、data[1]フィールドに含まれ、ＯｐＲｅｇｉｏｎの長さは、data[2]フィールドに含まれるであろう。
オフセットフィールドおよび長さフィールドは、クアドワードのＡＭＬオブジェクトとして生成されるであろう。
【０１２４】
ACPI_OBJECT_TYPE_METHOD（ＡＣＰＩオブジェクト型＿メソッド）：
以下の形の簡単なMethod()オブジェクトが生成されるであろう。
Method(name) {
Return(data object)
}
nameフィールドは、４文字のメソッド名を含む。
返されるデータオブジェクトは、dtypeフィールドによって指定される。
data[1]フィールドは、メソッドフラグを含む。
ACPI_DATA_TYPE_EXTERNフラグが、dtypeフィールドに設定されている場合、stringフィールドは、プロパティ文字列を含むことになり、したがって、メソッドフラグを指定できないことに留意されたい。
この場合、メソッドフラグは、デフォルトで９になる。
特定のメソッドフラグを設定する必要がある場合、ACPI_DATA_TYPE_EXTERNフラグが使用されるべきではなく、ACPI_OBJECT_TYPE_METHOD_SCOPE型が使用されるべきである。
【０１２５】
ACPI_OBJECT_TYPE_NOTIFY（ＡＣＰＩオブジェクト型＿通知）
以下の形のNotifyコマンドの部分が生成されるであろう。
Notify(<path>, <cmd>)
【０１２６】
dtypeフィールドは、ACPI_DATA_TYPE_ROOTED_PATHを含むべきであり、data[0]は、通知オペレーションのスコープであるＡＣＰＩ名前空間ノードに対応するデバイスツリーノードのノードハンドルを含むべきである。
【０１２７】
<cmd>引数は、拡張オブジェクトで供給されなければならない。
したがって、flagsフィールドは、ACPI_OBJECT_FLAG_EXTENSIONが設定されるべきであり、別のＡＣＰＩオブジェクトは、コマンド番号の整数値をコード化する適切なＡＣＰＩデータオブジェクトを有するデータ型ACPI_OBJECT_TYPE_EXTENSIONを含むことにすぐに従うべきである。
通常、Notifyオブジェクトは、ACPI_MASK_BIT_HOTPLUG値もflagsフィールドに設定されており、それによって、このNotifyオブジェクトが、そのＡＣＰＩエージェントフラグによって制御されるべきオブジェクトであることを示す。
【０１２８】
ACPI_OBJECT_TYPE_RESOURCE（ＡＣＰＩオブジェクト型＿資源）：
Name(_CRS)オブジェクトが生成されるであろう。
nameフィールドは、「＿ＣＲＳ」を含むべきである。
dtypeフィールドは、ACPI_DATA_TYPE_BUFFERを含むべきである。
ACPI_DATA_TYPE_EXTERN修飾フラグが設定されている場合、stringフィールドは、資源バッファが含まれるコンポーネントノードのグローバルプロパティ名を含むことになる。
そうでない場合、data[0]は、資源バッファへのポインタを含み、data[2]は、資源バッファの長さを含むことになる。
指定されたデータバッファは、ＥＮＤ資源要素を除くＡＣＰＩ資源データを含むべきである。
ＥＮＤ資源要素は、生成されたバッファの記述子およびチェックサムの後尾に追加される。
【０１２９】
ACPI_OBJECT_TYPE_PRT（ＡＣＰＩオブジェクト型＿ＰＲＴ）：
Method(_PRT)オブジェクトが生成されるであろう。
nameフィールドは、「＿ＰＲＴ」を含むべきである。
dtypeフィールドは、ACPI_DATA_TYPE_BUFFERを含むべきである。
ACPI_DATA_TYPE_EXTERNフラグが設定されている場合、stringフィールドは、ＰＣＩ経路テーブル情報が含まれるコンポーネントノードのグローバルプロパティ名を含むことになる。
そうでない場合、data[0]は、バッファの長さを含むことになる。
ＰＣＩ経路データは、各エントリが以下のフォーマットを有するテーブルによって指定される。
typedef struct {
unit16        unit;
unit8         slot;
unit8         device;
unit8         pin;
unit32        gsi;
} pci_route_entry_t;
【０１３０】
unitパラメータは、ＰＣＩバスエントリをグループ化するために内部で使用され、ＡＣＰＩエージェントによっては使用されない。
slotパラメータ、deviceパラメータ、pinパラメータ、およびgsiパラメータは、ＰＣＩ経路テーブルパッケージ要素を構築するためにＡＣＰＩエージェントによって使用される。
経路パッケージは、リストの要素ごとに生成されるであろう。
【０１３１】
ACPI_OBJECT_TYPE_AML（ＡＣＰＩオブジェクト型＿ＡＭＬ）：
静的ＡＭＬコード（ＡＳＬコンパイラによって生成される）のブロックは、ＡＣＰＩ記述子テーブルに挿入されるであろう。
dtypeフィールドは、ACPI_DATA_TYPE_BUFFERを含むべきである。
ACPI_DATA_TYPE_EXTERNフラグが設定されている場合、stringフィールドは、ＡＭＬコードが含まれるコンポーネントノードのグローバルプロパティ名を含むことになる。
そうでない場合、data[0]フィールドは、ＡＭＬコードを含むバッファへのポインタを含むことになり、data[2]は、バッファの長さを含むことになる。
静的ＡＭＬバッファは、読み込まれ、チェックサムおよびヘッダ情報は、検証されるであろう。
ヘッダは、取り除かれて、データは、記述子テーブルに直接挿入される。
【０１３２】
ACPI_OBJECT_TYPE_DEVICE（ＡＣＰＩオブジェクト型＿デバイス）：
Device()オブジェクトが生成されるであろう。
デバイス名は、nameフィールドに含まれる。
このオブジェクトは、デバイススコープ（Device scope）をオープンする。
現在の要素リストの終了に至るまで、または、ACPI_OBJECT_TYPE_ENDオブジェクトもしくはACPI_OBJECT_FLAG_ENDフラグに遭遇するまで続くすべてのオブジェクトは、このデバイススコープの範囲内に含まれるであろう。
【０１３３】
ACPI_OBJECT_TYPE_PROCESSOR（ＡＣＰＩオブジェクト型＿プロセッサ）：
Processor()オブジェクトが生成されるであろう。
プロセッサデバイス名は、nameフィールドに含まれる。
このオブジェクトは、プロセッサスコープ（Processor scope）をオープンする。
現在の要素リストの終了に至るまで、または、ACPI_OBJECT_TYPE_ENDオブジェクトもしくはACPI_OBJECT_FLAG_ENDフラグに遭遇するまで続くすべてのオブジェクトは、このプロセッサスコープの範囲内に含まれるであろう。
data[0]フィールドは、プロセッサＩＤパラメータを含み、data[1]フィールドは、ブロックアドレスパラメータを含み、data[2]フィールドは、ブロック長パラメータを含む。
【０１３４】
ACPI_OBJECT_TYPE_INCLUDE（ＡＣＰＩオブジェクト型＿包含）：
このオブジェクトは、別のソースからのＡＣＰＩ要素リストを含み、処理するであろう。
dtypeフィールドが、ACPI_DATA_TYPE_STRINGを含む場合、このオブジェクトリストは、現在のコンポーネントノードの文字列によって指定されるグローバルプロパティから読み出されることになる。
dtypeフィールドが、ACPI_DATA_TYPE_NODEを含む場合、このオブジェクトリストは、data[0]フィールドで使用されるノードのACPI_OBJECT_PROPERTYグローバルプロパティから読み出されることになる。
dtypeフィールドが、ACPI_DATA_TYPE_BUFFERを含む場合、オブジェクトリストは、data[1]フィールドで指定されるバッファから、data[2]フィールドで指定される長さで読み出されることになる。
【０１３５】
ACPI_OBJECT_TYPE_SCOPE（ＡＣＰＩオブジェクト型＿スコープ）：
Scope()オブジェクトが生成されるであろう。
現在の要素リストの終了に至るまで、または、ACPI_OBJECT_TYPE_ENDオブジェクトもしくはACPI_OBJECT_FLAG_ENDフラグに遭遇するまで続くすべてのオブジェクトは、指定されたスコープの範囲内に含まれるであろう。
dtypeフィールドが、ACPI_DATA_TYPE_STRINGを含む場合、単一の４文字の要素スコープ名が、stringフィールドに含まれる。
dtypeフィールドが、ACPI_DATA_TYPE_NAMESEGを含む場合、data[0]フィールドは、連鎖した名前セグメントを含んだバッファへのポインタを含み、data[2]フィールドは、セグメントカウントを含む。
ＡＣＰＩエージェントは、パスを構築する時、名前セグメント分離文字を生成するであろう。
【０１３６】
ACPI_OBJECT_TYPE_CALL（ＡＣＰＩオブジェクト型＿呼び出し）：
メソッド呼び出しが生成されるであろう。
nameフィールドは、呼び出される４文字のメソッドを含む。
dtypeパラメータが、ACPI_DATA_TYPE_PATHを含む場合、data[0]フィールドは、ＡＣＰＩデバイスパスが読み出されるコンポーネントノードを含む。
このデバイスパスは、目的のノードのグローバルプロパティに記憶され、ＡＣＰＩエージェントの記述子テーブルの処理の第１の通過において生成される。
dtypeパラメータが、ACPI_DATA_TYPE_BUFFERを含む場合、data[0]フィールドは、連鎖したＡＣＰＩデバイスパスセグメントが含まれるバッファへのポインタを含み、data[2]フィールドは、セグメントカウントを含む。
ACPI_OBJECT_FLAG_EXTENSIONフラグが設定されている場合、呼び出されたメソッドに渡される引数が、このオブジェクトに続く。
この場合、引数オブジェクトのリストは、それぞれ、ACPI_OBJECT_TYPE_EXTENSIONの型を有するべきであり、そのリストの最後の引数オブジェクトを除くすべての引数オブジェクトは、ACPI_OBJECT_FLAG_EXTENSIONフラグが設定されているべきである。
【０１３７】
ACPI_OBJECT_TYPE_METHOD_SCOPE（ＡＣＰＩオブジェクト型＿メソッド＿スコープ）：
Method()スコープをオープンする。
nameフィールドは、４文字のメソッド名を含む。
現在のオブジェクトリストの終了に至るまで、または、ACPI_OBJECT_TYPE_ENDオブジェクトもしくはACPI_OBJECT_FLAG_ENDフラグに遭遇するまで続くすべてのオブジェクトは、このメソッドスコープの範囲内に含まれるであろう。
data[1]フィールドは、メソッドフラグを含む。
【０１３８】
ACPI_OBJECT_TYPE_EXTENSION（ＡＣＰＩオブジェクト型＿拡張）
このオブジェクト型は、先行するオブジェクトに対する拡張を指定するために使用され、主として、メソッド呼び出しの引数を定義するのに使用される。
dtypeフィールドは、生成されるデータオブジェクトの型を指定する。
複数の拡張オブジェクトがリストに存在する場合、ACPI_OBJECT_FLAG_EXTENSIONフラグは、リストの最後のオブジェクトを除くすべてのオブジェクトに対して設定されるべきである。
【０１３９】
ACPI_OBJECT_TYPE_RETURN（ＡＣＰＩオブジェクト型＿リターン）：
Return()（リターン（））オブジェクトを生成する。
dtypeフィールドは、返されるデータオブジェクトの型を指定する。
【０１４０】
ACPI_OBJECT_TYPE_END（ＡＣＰＩオブジェクト型＿エンド）：
現在のスコープ（SCOPE()、Processor()、またはMethod()）の終了を示す。
ACPI_OBJECT_FLAG_ENDフラグが任意のオブジェクトに設定されている場合、このフラグは、特定のエンドオブジェクトを含むのと同じ効果を有することになる。
同様に、現在のオブジェクトリストの終了により、現在のスコープはクローズされることになる。
【０１４１】
［簡単な例、ＰＣＩスロットデバイス］
上述したように、一実施の形態におけるＡＭＬを動的に生成するメカニズムは、ブート時に使用されて、ブート時において発見されたハードウェア資源およびデバイスの名前空間を作成し、また、ランタイムにおいても、名前空間の資源が成長しなければならない時にこの名前空間を作成する。
ＰＣＩスロットデバイスのこの簡単な例は、生成されるＡＭＬ資源記述子（すなわち、_CRSオブジェクト）を使用せず、機能メソッドを含んだ名前空間を定義するＡＭＬが使用される。
【０１４２】
この簡単な例においてここで使用されるＡＭＬ生成の同じ基本パターンは、プロセッサ、メモリデバイス、およびＩ／Ｏデバイスを名前空間に追加するはるかに複雑なシナリオにも使用される。
主な相違は、ＡＭＬおよび名前空間がより複雑（より多くのプロパティ、より多くのＡＭＬ、より複雑なオブジェクトなど）となる点である。
【０１４３】
各コンポーネントによって構築されたＡＣＰＩオブジェクト要素リストは、ともにリンクされて、完全なリストを生成し、ＡＣＰＩエージェントの記述子リストパーサに渡される。
ＡＣＰＩエージェントは、各セルノードからのリストを適切な記述子テーブルに処理する。
コアセルリストは、ＤＳＤＴを生成するために使用され、それぞれの非コアセルは、個別のリストに生成されるであろう。
ＰＣＩバスアダプタによってサポートされる各ＰＣＩスロットは、スロット／機能ＰＣＩデバイスオブジェクトを記述する関連付けられたＰＣＩデバイス要素リストを有する。
ＰＣＩデバイス要素リストは、pciコンポーネントによって生成され、pciデバイスノードに記憶される。
これらのリストは、ＰＣＩバスの制御を可能にする親のＬＢＡデバイスにより含まれる。
各ＰＣＩデバイスリストは、８つのＰＣＩ機能のそれぞれについて以下の要素を含む。
−  デバイス要素：スロット／機能デバイススコープをオープンする。
「ＳｘＦｙ」の形の名前が生成される。
ここで、ｘは、スロット番号であり、スーパドーム（Superdome）システムでは０である。
ｙは、ＰＣＩスロットの８つの機能のそれぞれを表す｛０，１，２，３，４，５，６，７｝の１つである。
−  ＿ＡＤＲ要素：＿ＡＤＲ名前オブジェクトを定義する。
−  ＿ＵＩＤ要素：＿ＵＩＤ名前オブジェクトを定義する。
−  ＿ＳＵＮ要素：＿ＳＵＮ名前オブジェクトを定義する。
−  ＿ＳＴＲ要素：＿ＳＴＲ名前オブジェクトを定義する。
−  静的ＡＭＬ包含要素：以下の６つのメソッドの定義を提供する静的ＡＭＬコード（以下を参照）を含む。
デバイスステータスを返す＿ＳＴＡメソッド−ＡＣＰＩ標準。
デバイスをイジェクトする＿ＥＪＯメソッド−ＡＣＰＩ標準。
スロットのアテンションＬＥＤを点灯するＡＴＮ１メソッド−非標準。
スロットのアテンションＬＥＤを点滅させるＡＴＮＦメソッド。
スロットのアテンションＬＥＤを消灯するＡＴＮ０
スロットのアテンションＬＥＤの現在の状態を返すＡＳＴＡ
【０１４４】
これらのメソッドのそれぞれは、ＳｘＦｙデバイスの親であるＬＢＡデバイスのＡＭＬメソッドを実際に起動する。
ＡＭＬメソッドには、オペレーション領域のデリファレンスを行う実際の作業が登録され、それによって、オペレーションが実行される。
【０１４５】
これらのオブジェクトを定義するソースコード例を抜粋したものを、以下に記載する。
static unit8 pci_aml_data[] = {
#include "pci_method.h"
}; /* ＡＳＬコンパイラによって生成されるデータ定義ファイル */
pci_method.hファイルは、以下のものを含む。
/*
*
* Ｉｎｔｅｌ  ＡＣＰＩコンポーネントアーキテクチャＡＳＬコンパイラＸ２０３９［２００２年５月２９日］
* ＡＣＰＩ  ＣＡサブシステムのバージョン２００２０３０８を含む。
* 著作権（Ｃ）２０００−２００２  Intel Corporation
* ＡＣＰＩ仕様の改訂版２．０をサポートする。
*
* 「pci_method.asl」をコンパイルしたもの−２００２年１０月２６日（土）１３時３９分３３秒
*
* Ｃソースコード出力
*
*/
0x53, 0x53, 0x44, 0x54, 0x79, 0x00, 0x00, 0x00, /*    00000000  "SSDTy…"   */
0x02, 0x33, 0x48, 0x50, 0x00, 0x00, 0x00, 0x00, /*    00000008  ".3HP...."   */
0x47, 0x72, 0x61, 0x6E, 0x69, 0x74, 0x65, 0x00, /*    00000010  "Granite."   */
0x00, 0x00, 0x00, 0x00, 0x49, 0x4E, 0x54, 0x4C, /*    00000018  "….INT   */
0x39, 0x20, 0x00, 0x02, 0x14, 0x0E, 0x5F, 0x45, /*    00000020  "9…._E"   */
0x4A, 0x30, 0x01, 0xA4, 0x5E, 0x5E, 0x5F, 0x45, /*    00000028  "J0..^^_E"   */
0x4A, 0x30, 0x68, 0x14, 0x0D, 0x5F, 0x53, 0x54, /*    00000030  "J0h.._ST"   */
0x41, 0x00, 0xA4, 0x5E, 0x5E, 0x53, 0x53, 0x54, /*    00000038  "A..^^SST"   */
0x41, 0x14, 0x0D, 0x41, 0x53, 0x54, 0x41, 0x00, /*     00000040  "A..ASTA."   */
0xA4, 0x5E, 0x5E, 0x41, 0x53, 0x54, 0x41, 0x14, /*    00000048  "^^ASTA."   */
0x0D, 0x41, 0x54, 0x4E, 0x30, 0x00, 0xA4, 0x5E, /*    00000050  ".ATN0..^"   */
0x5E, 0x41, 0x54, 0x4E, 0x30, 0x14, 0x0D, 0x41, /*    00000058  "^ATN0..A"   */
0x54, 0x4E, 0x31, 0x00, 0xA4, 0x5E, 0x5E, 0x41, /*    00000060  "TN1..^^A"   */
0x54, 0x4E, 0x31, 0x14, 0x0D, 0x41, 0x54, 0x4E, /*    00000068  "TNI..ATN"   */ 
0x46, 0x00, 0xA4, 0x5E, 0x5E, 0x41, 0x54, 0x4E, /*    00000070  "F..^^ATN"   */
0x46,
【０１４６】
この定義は、オブジェクト型がACPI_OBJECT_TYPE_AMLであるfun[*].amlオブジェクトにより含まれるＡＭＬのバイト配列を生成する。
この.hデータファイルを生成した実際のコードは、以下のとおりである。
DefinitionBlock(
"pci method.aml",          // 出力ファイル名
"SSDT",                   // シグネチャ
2,                         // ＳＳＤＴ改訂版
"HP",                     // ＯＥＭＩＤ
"Granite",                 // テーブルＩＤ
0x0000                    // ＯＥＭ改訂版
)
{   // 定義ブロックの開始
// これらのメソッドは、親のローカルバスアダプタデバイスで定義され、
// そして、そこで、実際の作業が行われる。
８つのスロット／機能デバイスの
// それぞれは、これらのメソッドについて同一のＡＭＬを有するので、
// 我々は、それらについて静的ＡＭＬを使用する。
External(^^SSTA, MethodObj)
External (^^_EJ0, MethodObj)
External(^^ASTA, MethodObj)
External(^^AST0, MethodObj)
External(^^ATN1,MethodObj)
External(^^ATNF, MethodObj)
// _ＥＪ0−イジェクトメソッドは、親のＬＢＡの_ＥＪ0メソッドを起動する
Method(_EJ0,  1) {Return(^^_EJ0(Arg0))} // End of _EJ0
// _ＳＴＡ−ステータスメソッドは、親のＬＢＡのＳＳＴＡメソッドを起動する
Method(_STA) {Return(^^SSTA( ))} // ＿ＳＴＡの終了
// ＡＳＴＡ−アテンションＬＥＤのステータス（オフ、オン、点滅）を返す
Method(ASTA) {Return(^^ATNA( ))}
//ＡＴＮ０−呼び出されたＬＢＡメソッドによりアテンションＬＥＤをオフに設定する
Method(ATN0) {Return(^^ATN0( ))} 
//ＡＴＮ１−ＬＢＡメソッドを呼び出すことによりアテンションＬＥＤをオンに設定する
Method(ATN1) {Return(^^ATN1( ))} 
//ＡＴＮＦ−ＬＢＡメソッドを呼び出すことによりアテンションＬＥＤに点滅を設定する
Method(ATNF) {Return(^^ATNF( ))} 
} // DefinitionBlock()の終了
【０１４７】
上記から分かるように、静的に生成されたＡＭＬは、かなりシンプルであり、デバイス特有の知識を含まない。
【０１４８】
ＰＣＩ機能デバイスの動的ＡＭＬ  ＡＣＰＩオブジェクトは、以下のようなソースで定義される。
typedef struct pci_slot_object{
struct pci_function_object{
acpi_object_entry_t       dev;    /* デバイススコープ */
acpi_object_entry_t       adr;    /* ＿ＡＤＲ */
acpi_object_entry_t       uid;    /* ＿ＵＩＤ */
acpi_object_entry_t       sun;    /* ＿ＳＵＮ */
acpi_object_entry_t       str;    /* ＿ＳＴＲ */
acpi_object_entry_t       aml;    /* 静的ＡＭＬを含む */
acpi_object_entry_t       end;    /* データスコープの終了 */
}                   fun[8];
}     pci_slot_object_t;
【０１４９】
以下のコードは、これらのＳｘＦｙのＡＣＰＩオブジェクトのそれぞれをランタイムに動的に初期化する。
このＰＣＩデバイスに関係したデバイスツリープロパティにアクセスすることから得られる重要なランタイムデータ値は、次のとおりである。
我々が「ロープ（rope）」番号と呼ぶものを識別するｒｐ−>ｓｌｏｔ
ロープごとのスロット数であり、このシステムでは１に等しいｓｌｏｔＩｎｄｅｘ
このコンポーネントのデータの内容をデバイスツリーに保持するＰＣＩデバイスの状態変数構造体であるｉｎｆｏＰｔｒ
【０１５０】
/* オブジェクト用のメモリを割り当てる */
sp = (pci_slot_object_t*)malloc(slotIndex * sizeof(pci_slot_object_t));
for (funcIndex = 0; funcIndex <= PCI_PFA_FUNC_NUM_MAX; funcIndex++){
/* Device() */
sprintf(name, "S%1XF%1X", rp->slot,  (uint8) funcIndex);
strncpy(sp [slotIndex].fun[funcIndex].dev.name,  name, 4);
sp[slotIndex].fun[funcIndex].dev.type = ACPI_OBJECT_TYPE_DEVICE;
sp[slotIndex].fun[funcIndex].dev.dtype = ACPI_DATA_TYPE_NONE;
sp[slotIndex].fun[funcIndex].dev.flags = ACPI_MASK_BIT_PCI;
/* _ADR() */
strncpy(sp [slotIndex].fun[funcIndex].adr.name, "_ADR", 4);
sp[slotIndex].fun[funcIndex].adr.type = ACPI_OBJECT_TYPE_NAME;
sp[slotIndex].fun[funcIndex].adr.dtype = ACPI_DATA_TYPE_DWORD;
sp[slotIndex].fun[funcIndex].adr.flags = ACPI_MASK_BIT_ADR;
sp[slotIndex].fun[funcIndex].adr.ACPI_OBJ_DATA = 
(rp->device << 16)|funcIndex;
/* _UID */
Strncpy (sp [slotIndex].fun[funcIndex].uid.name,  "_UID", 4);
sp[slotIndex].fun[funcIndex].uid.type = ACPI_OBJECT_TYPE_NAME;
sp[slotIndex].fun[funcIndex].uid.dtype = ACPI_DATA_TYPE_BYTE;
sp[slotIndex].fun[funcIndex].uid.flags = ACPI_MASK_BIT_UID;
sp[slotIndex].fun[funcIndex].uid.ACPI_OBJ_DATA = 
(rp->slot << 4)|funcIndex $ 0xf);
/* _SUN */
strncpy (sp [slotIndex].fun[funcIndex].sun.name,  "_SUN", 4);
sp[slotIndex].fun[funcIndex].sun.type = ACPI_OBJECT_TYPE_NAME;
sp[slotIndex].fun[funcIndex].sun.dtype = ACPI_DATA_TYPE_BYTE;
sp[slotIndex].fun[funcIndex].sun.flags = ACPI_MASK_BIT_SUN;
sp[slotIndex].fun[funcIndex].sun.ACPI_OBJ_DATA= rp->slot;
/* _STR−物理位置のユニコード文字列 */
strncpy (sp [slotIndex].sun.name,  "_STR", 4);
sp[slotIndex].fun[funcIndex].sun.type = ACPI_OBJECT_TYPE_NAME;
sp[slotIndex].fun[funcIndex].sun.dtype = ACPI_DATA_TYPE_LOCATION;
sp[slotIndex].fun[funcIndex].sun.flags = ACPI_MASK_BIT_STR;
sp[slotIndex].fun[funcIndex].sun.data[0] = CreateLocation(infoPtr);
sp[slotIndex].fun[funcIndex].sun.data[1] = 0;
sp[slotIndex].fun[funcIndex].sun.data[2] = 0;
/* ＡＭＬを含める */
sp[slotIndex].fun[funcIndex].aml.type = ACPI_OBJECT_TYPE_AML;
sp[slotIndex].fun[funcIndex].aml.dtype = ACPI_DATA_TYPE_BUFFER;
sp[slotIndex].fun[funcIndex].aml.flags = ACPI_MASK_BIT_EJ0;
sp[slotIndex].fun[funcIndex].aml.ACPI_OBJ_DATA = (uint64)& pci_aml_data;
sp[slotIndex].fun[funcIndex].aml.ACPI_OBJ_LENGth = sizeof(pci_aml_data);
/* 終了 */
sp[slotIndex].fun[funcIndex].end.type=ACPI_OBJECT_TYPE_END;
sp[slotIndex].fun[funcIndex].end.dtype=ACPI_DATA_TYPE_NONE;
sp[slotIndex].fun[funcIndex].end.flags=ACPI_MASK_BIT_PCI;
【０１５１】
ＰＣＩスロットデバイスプロパティは、ＤＵＩコマンドインターフェースによって表示される時にリストにされる。
重要なことは、上記で使用された、２つのＰＣＩデバイスに依存したランタイム変数を得るために使用される１つのＬｂａＮｏｄｅである。
Name（名前）                        pci008000
Type（型）                          pci
LbaNode（ＬＢＡノード）            0x80000ffc0040ec10
PciBus（ＰＣＩバス）                0x00
PciBusRange（ＰＣＩバスレンジ）    0x0000000000000010
PciSegment（ＰＣＩセグメント）      0x0000000000000008
ACPI_Objects（ＡＣＰＩオブジェクト）
0x00000000:     0x00000811000000000         0x000008003f8d6110
0x00000010:     0x00000000000000000         0x0000000000000700
【０１５２】
上述したように、ＡＣＰＩエージェントは、acpi_object_entry_t記述子のリストを処理して、このリストを、（ＤＳＤＴ、または、ＳＳＤＴの１つのいずれかの）ＤＤＢの一部であるバイナリＡＭＬに変換する。
【図面の簡単な説明】
【０１５３】
【図１】静的ＡＭＬ生成を使用する従来のＡＣＰＩ互換システムの実施態様の一例を示す図である。
【図２】本発明の一実施の形態の実施態様の一例を示す図である。
【図３】本発明の実施の形態を実施することができるシステム例の抽象モデルを示す図である。
【図４】ＡＣＰＩ互換システムにおけるＡＣＰＩ要素と他のシステムの要素との間の関係を図示する一例のブロック図である。
【図５】ＡＣＰＩテーブルを実施する一例の高位ブロック図である。
【図６】本発明の一実施の形態が実施されるシステムアーキテクチャのブロック図である。
【図７】図４のＡＣＰＩ互換システムで実施される本発明の一実施の形態の一例のブロック図である。
【図８】本発明の一実施の形態に従って、新しいハードウェアデバイスをシステムで実施する一例の操作フロー図である。
【図９Ａ】本発明の一実施の形態に従って、システムが、新しく追加されたハードウェアデバイスのＡＣＰＩテーブルエントリ（必要なあらゆるＡＭＬコードを含む）を自律的に生成する例の操作フロー図である。
【図９Ｂ】本発明の一実施の形態に従って、システムが、新しく追加されたハードウェアデバイスのＡＣＰＩテーブルエントリ（必要なあらゆるＡＭＬコードを含む）を自律的に生成する例の操作フロー図である。
【符号の説明】
【０１５４】
２０５・・・デバイス認識ファームウェア、
２０６・・・データベース、
２０７・・・ＡＣＰＩエージェント、
３０１・・・プラットフォーム、
３０３・・・ＯＳ、
３０７・・・システムファームウェアレベル、
６００・・・バンヤンファームウェアシステム、
６０１・・・移植可能コア（データベース）、
６０８・・・ＡＣＰＩテーブル、
６０９・・・ＡＣＰＩエージェント、
６０１・・・コア、
６０２・・・コアフレームワーク、
６０３・・・イベントシーケンサ、
６０４・・・ＳＡＬサブストレート、
６０５・・・アーキテクチャパターン（デバイスツリー）、
６０６・・・ツリーコンポーネント、
６０７・・・デバッガサポート、
６１０・・・ＥＦＩ  ＡＢＩ、
６１１・・・ＳＡＬ  ＡＢＩ、
７０１，７０２・・・ファームウェア、
【図１】
2004355620.tif 000004
【図２】
2004355620.tif 000005
【図３】
2004355620.tif 000006
【図４】
2004355620.tif 000007
【図５】
2004355620.tif 000008
【図６】
2004355620.tif 000009
【図７】
2004355620.tif 000010
【図８】
2004355620.tif 000011
【図９Ａ】
2004355620.tif 000012
【図９Ｂ】
2004355620.tif 000013