(57)【要約】【課題】　メモリマップドＩ／Ｏ（ＭＭＩＯ）を用いてシステムデバイスを管理する。【解決手段】　ＡＣＰＩ名前空間内のローカルバスアダプタは、ＭＭＩＯを用いて、その子デバイスのメモリアドレスを識別する。ＡＣＰＩの未使用のコンストラクトが、オペレーティングシステム（ＯＳ）を通じてデバイスドライバにＭＭＩＯ情報を渡すために使用されることにより、メモリがデバイスによって予約されるとともにＯＳには隠蔽されたままであることが可能となる。「ｖｅｎｄｏｒ−ｌｏｎｇ」などの長い情報に対するベンダ定義のリソースデータタイプが、ＯＳを通じて適当な情報を渡すために使用され、ＯＳが間違ってアドレスを空いているとみなし、それを誤って再割当てするというリスクなしに、メモリ情報がＯＳに渡される。【選択図】図３
2004070946.tif 000002
【特許請求の範囲】
【請求項１】
　デバイスによって所有されメモリマップドＩ／Ｏ（ＭＭＩＯ）（図４および図５）を用いて割り当てられるメモリをオペレーティングシステム（１０１）から隠蔽するメカニズムであって、
　複数のデバイス（３０５、３０９、３１３、３２３）に接続され、オペレーティングシステムがＡＣＰＩ(Advanced Configuration and Power Interface)（１０５、１０７、１０９）を用いて該複数のデバイスと相互作用する、コンピュータシステム（３００）と、
　該コンピュータシステムに接続され、前記複数のデバイスに割り当てられて、デバイス相互作用のためのＭＭＩＯレジスタマップ（４０１、４０３）を提供する、メモリブロックと、
　前記オペレーティングシステムからメモリの領域（４１１）を隠蔽する手段と
　を備え、
　前記隠蔽されるメモリは前記複数のデバイス（３０５、３０９、３１３、３２３）の少なくとも１つに割り当てられ、少なくとも１つのツールにとってアクセス可能であり、前記ツールは、隠蔽されたメモリを割り当てられた前記デバイスの少なくとも１つと相互作用する
　メカニズム。
【請求項２】
　前記ツールはデバイスドライバである
　請求項１に記載のメカニズム。
【請求項３】
　前記メモリの領域（４１１）を隠蔽する手段は、前記隠蔽されたメモリ（４１１）に関する情報を渡すために可変長のＡＣＰＩデータオブジェクト（１０５、１０７）を使用し、
　前記オペレーティングシステム（１０１）は、前記可変長のＡＣＰＩデータオブジェクトで渡される情報を無視する
　請求項１に記載のメカニズム。
【請求項４】
　前記可変長のＡＣＰＩデータオブジェクト（１０５、１０７）は、事前に定義されているＡＣＰＩのｖｅｎｄｏｒ−ｌｏｎｇデータオブジェクトである
　請求項３に記載のメカニズム。
【請求項５】
　前記コンピュータシステムはＩＡ−６４命令セットアーキテクチャを使用する
　請求項４に記載のメカニズム。
【請求項６】
　メモリマップドＩ／Ｏ（ＭＭＩＯ）（図４および図５）を使用して、システムデバイスを管理するようにする方法であって、
　複数のデバイス（３０５、３０９、３１３、３２３）のレジスタマップ（４０１、４０３）に対応するコンピュータシステム内のメモリを前記複数のデバイスに割り当てることと、
　オペレーティングシステム（１０１）から隠蔽されるべきである割り当てられたメモリのエリア（４１１）を識別することであって、前記隠蔽されるエリアは、前記複数のデバイスの少なくとも１つと相互作用する少なくとも１つのツールによってアクセス可能である、識別することと、
　前記コンピュータシステム上で動作しているオペレーティングシステムが、ＭＭＩＯの選択されたメモリ割当て（４０１）を見ることを可能にすることであって、前記オペレーティングシステムは前記割り当てられたメモリの隠蔽されるエリア（４１１）を無視する、可能にすることと
　を含む方法。
【請求項７】
　前記オペレーティングシステムが選択されたメモリ割当てを見ることを可能にすることは、
　リソースのカレントステータスデータオブジェクトを受け取ること（１０５、１０７）であって、前記カレントステータスは、前記オペレーティングシステム（１０１）にとって利用可能なデバイスおよびリソースのメモリ割当てに対応する情報を返す、受け取ることと、
　リソースのｖｅｎｄｏｒ−ｌｏｎｇデータオブジェクトを受け取ること（１０５、１０７）であって、前記ｖｅｎｄｏｒ−ｌｏｎｇは、前記オペレーティングシステムから隠蔽されたデバイスおよびリソースのメモリ割当てに対応する情報を返す、受け取ることと
　を含む請求項６に記載の方法。
【請求項８】
　前記オペレーティングシステムによって、前記隠蔽されたメモリ割当て情報を利用するツールに前記ｖｅｎｄｏｒ−ｌｏｎｇデータを渡すことをさらに含む
　請求項７に記載の方法。
【請求項９】
　前記ツールはデバイスドライバである
　請求項８に記載の方法。
【請求項１０】
　前記コンピュータシステムはＩＡ−６４命令セットアーキテクチャを使用する
　請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、メモリマップドＩ／Ｏ（ＭＭＩＯ）を用いてシステムデバイスを管理するシステムおよび方法に関する。
【背景技術】
【０００２】
　ＡＣＰＩ(Advanced Configuration and Power Interface)は、ラップトップ、デスクトップ、サーバなどを含むコンピュータにおいてオペレーティングシステムがハードウェアステータス情報を利用できるようにする仕様である。
　ＡＣＰＩに関するさらに多くの情報は、Compaq Computer Corporation、 Intel Corporation、 Microsoft Corporation、Phoenix Technologies Ltd.、および東芝によって共同で規定された５００ページにわたる「Advanced Configuration and Power Interface Specification」、Revision 2.0a、２００２年３月３１日、に見出され得る。
【０００３】
　ＡＣＰＩ仕様は、堅牢なオペレーティングシステム（ＯＳ）指向のマザーボードデバイスコンフィグレーションと、デバイスおよびシステム全体の両方の電源管理とを可能にする業界共通のインタフェースを確立するために開発された。
　ＡＣＰＩは、ＯＳＰＭ(operating system-directed configuration and power management)における主要な要素である。
【０００４】
　ＡＣＰＩは、Ｍｉｃｒｏｓｏｆｔ（登録商標) Corporationから入手可能なＷｉｎｄｏｗｓ（登録商標）、さまざまなベンダからオープンソースとして入手可能なＬｉｎｕｘ、およびHewlett-Packard Companyから入手可能なＨＰ−ＵＸのようなさまざまなオペレーティングシステムを実行するパーソナルコンピュータ（ＰＣ）で使用される。
　ＡＣＰＩはまた、ハードウェアリソースを操作することも可能にする。
【０００５】
　たとえば、ＡＣＰＩは、コンピュータシステムの周辺装置が、改善された電源管理のために電源をオン・オフされ得るようにすることによって、電源管理を支援する。
　ＡＣＰＩはまた、コンピュータシステムが外部デバイスによってオン・オフされることも可能にする。
　たとえば、マウスに触れることまたはキーを押すことによって、ＡＣＰＩを用いたコンピュータシステムをウェイクアップすることが可能である。
【０００６】
　従来、ＡＣＰＩはさまざまな理由で取り扱いが困難である。
　第１に、ＡＣＰＩは、いかなるコンピュータシステム・プラットフォームのネイティブなアセンブリ言語でも書かれていない。
　その代わりに、ＡＣＰＩはその固有のソース言語および機械語、すなわち、それぞれＡＳＬ(ACPI Source Language)およびＡＭＬ(ACPI Machine Language)を有する。
【０００７】
　その非常に特殊化した用途のため、ＡＳＬプログラマは比較的少数しかいない。
　また、ＡＳＬは、その限定された用途のため、比較的少数のコンストラクト(construct)しか有していない。
　さらに、ＡＣＰＩコードは従来、その設計においてモノリシックである。
【０００８】
　結果として、このことは、ＡＣＰＩコードを他のプラットフォームに、または同じプラットフォームの異なるコンフィグレーションにさえ、移植することを困難にしている。
　したがって、新たに設計されたプラットフォームを取り扱うためには、新たなＡＳＬコードが書かれる必要がある。
　ＡＳＬプログラマの数が制限されているために、新たなコードを書くことはそれだけますます問題が多く高価になる。
【０００９】
　ＡＣＰＩは、スタティック(static)およびインタプリタブル(interpretable)の両方のテーブルから構成される。
　ブートアップ時に、システムファームウェア（通常はＢＩＯＳ、すなわち基本入出力システム）がスタティックテーブルを構成し、これはオペレーティングシステムにより消費される。
　インタプリタブルテーブルはＡＭＬから構成され、これはコンパイルされた後、システムファームウェアにマージされる。
【００１０】
　オペレーティングシステムは、インタプリタブルテーブルからＡＭＬを読み出し、ＡＣＰＩインタプリタを用いて、構築されたインタフェースを実行する。
　このようにして、オペレーティングシステムはハードウェアリソースを操作する。
　インタプリタブルテーブルはシステムファームウェアにマージされるため、この従来の方法にはフレキシビリティ、およびスケーラビリティが欠けており、多様なシステムコンフィグレーションに対応するための再プログラミングには相当の時間を必要とする。
【００１１】
　たとえば、従来、ＡＳＬ開発者は、ある特定のコンフィグレーションのプラットフォームまたはその差を指定するためにＡＣＰＩコードを書いている。
　残念ながら、取るに足りないハードウェア変更が実行されただけでも、その設計は修正されなければならない。
　このことは、新たなＡＭＬコードが書かれること、および新たなテーブルがシステムファームウェアにマージされることを必要とする。
　したがって、従来の設計は移植可能あるいは再使用可能でない。
【００１２】
　さらに、ＡＣＰＩは従来、プラットフォームの差がある場合、またはプラットフォームが複数のＡＣＰＩアウェアなＯＳシステムをサポートしておりそれらのＯＳシステムが相互に排他的なＡＣＰＩ要件を有する場合に、異なるシステムファームウェアＲＯＭ（読み出し専用メモリ）またはＢＩＯＳが使用されることを要求している。
　同じシステムが複数のオペレーティングシステムをサポートすべき場合にも、異なるシステムファームウェアＲＯＭを使用しなければならなかった。
【００１３】
　たとえば、パーソナルコンピュータにおける現在の技術は、ＩＡ−３２命令セットを使用している。
　ＡＣＰＩは、主としてＭｉｃｒｏｓｏｆｔ（登録商標）ファミリのオペレーティングシステム、特にＩＡ−３２命令セットを有するシステムで使用された。
【００１４】
　ＡＣＰＩは、さまざまなオペレーティングシステムにより標準のインタフェースとして採用されている。
　新しい命令セットアーキテクチャであるＩＡ−６４が開発されているが、その利点は、旧来の(legecy)（レガシー）ＡＣＰＩコードあるいは方法では十分に利用することができない。
　Ｉｎｔｅｌ（登録商標）Corporationから入手可能な新しいＩｔａｎｉｕｍ（登録商標）プロセッサファミリは、ＩＡ−６４命令セットを使用する。
【００１５】
　現在のやり方が用いられるのであれば、このファミリのそれぞれの新しいプロセッサごとにＡＳＬを個別に書き直すことが必要とされるであろう。
　さらに、所与のプロセッサ上で複数のオペレーティングシステムが動作しなければならない場合、ＡＳＬは、それぞれのＯＳごとにも個別であることが必要とされることになる。
【００１６】
　ＡＣＰＩ名前空間は、ＯＳにより制御されるメモリ内の、名前づけられたオブジェクトを含む階層的ツリー構造である。
　これらのオブジェクトは、データオブジェクト、制御メソッドオブジェクト、バス／デバイスパッケージオブジェクトなどであり得る。
　ＯＳは、ＡＣＰＩ　ＢＩＯＳに存在するＡＣＰＩテーブルから定義ブロックをロードおよび／またはアンロードすることによって、実行時に名前空間の内容を動的に変更する。
【００１７】
　ＡＣＰＩ名前空間内のすべての情報は、差分定義ブロックと、１つ以上の他の定義ブロックとを含む差分システム記述テーブル（ＤＳＤＴ：differentiated system description table）から来る。
　現在の技術では、ＯＥＭ（相手先商標製品製造業者）がＤＳＤＴをＡＣＰＩ互換なＯＳに供給しなければならず、そのＯＳが、ベースシステムに関する実施情報およびコンフィグレーション情報を供給する。
　ＯＳは常に、システムブート時にＤＳＤＴ情報をＡＣＰＩ名前空間に挿入し、それを削除することはない。
【００１８】
　もう１つのＡＣＰＩコンストラクトは、二次システム記述テーブル（ＳＳＤＴ：secondary system description table）である。
　ＳＳＤＴは、ＤＳＤＴの続きである。
　複数のＳＳＤＴが、プラットフォーム記述の一部として使用され得る。
【００１９】
　ＤＳＤＴがＡＣＰＩ名前空間にロードされた後、固有のＯＥＭテーブルＩＤを有するそれぞれの二次記述テーブルがロードされる。
　これにより、ＯＥＭは、１つのテーブルでベースサポートを提供する一方、より小規模なシステムオプションを他のテーブルで追加することができる。
　追加テーブルはデータを追加することだけができ、前のテーブルからのデータに上書きすることはできない。
【００２０】
　ＩＡ−３２およびＡＣＰＩを使用する従来技術のコンピュータシステムは通常、Ｉ／Ｏポートアドレス空間を用いて、コンピュータシステム内のさまざまなＩ／Ｏデバイスに対するレジスタメモリマップを管理する。
　この方法はＩＡ−６４に対して使用され得るが、サーバが５００以上のデバイスおよびリソースを有することができることを考慮すると、重大な欠点を有する。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
　本発明の目的は、メモリマップドＩ／Ｏ（ＭＭＩＯ）を用いてシステムデバイスを管理するシステムおよび方法を提供することである。
【課題を解決するための手段】
【００２２】
　ＡＣＰＩ名前空間内の親デバイス、たとえばローカルバスアダプタは、（ＭＭＩＯ）を用いて、その子デバイスのメモリアドレスを識別する。
　ＡＣＰＩの既存ではあるが未使用のコンストラクトが、オペレーティングシステム（ＯＳ）を通じてデバイスドライバにＭＭＩＯ情報を渡すために使用されることにより、メモリがデバイスによって予約されるとともにＯＳには隠蔽されたままであることが可能となる。
【００２３】
　「ｖｅｎｄｏｒ−ｌｏｎｇ」ディスクリプタとしても知られる、長い情報に対するベンダ定義のリソースデータタイプが、ＯＳを通じて適当な情報を渡すために使用される。
　この方法は、ＯＳが間違ってアドレスを空いているとみなし、それを誤って再割当てするというリスクなしに、メモリ情報がＯＳに渡されることを可能にする。
【発明の効果】
【００２４】
　本発明によれば、メモリマップドＩ／Ｏ（ＭＭＩＯ）を用いてシステムデバイスを管理することができる。
【発明を実施するための最良の形態】
【００２５】
　詳細な説明は添付の図面を参照するが、そこで同じ番号は同じ要素を指す。
【００２６】
　ＡＣＰＩは、ＩＡ−３２命令セットの概念であり、新しいＩＡ−６４命令セットに対しても依然として使用される概念である。
　ＡＣＰＩは、オペレーティングシステム（ＯＳ）とファームウェアとの相互作用のためのハードウェアのコンフィグレーションを定義するために、ハードウェアの操作およびコンフィグレーションデータを抽象化する１つの方法である。
【００２７】
　ＡＣＰＩは業界標準の仕様である。
　現在、主要な３つの商用のパーソナルコンピュータ（ＰＣ）用オペレーティングシステム、すなわち、Ｌｉｎｕｘ、ＨＰ／ＵＸおよびＷｉｎｄｏｗｓ（登録商標）は、ＡＣＰＩをＩＡ−３２空間で使用しており、ＡＣＰＩを用いて新しいＩＡ−６４空間で動作するであろう。
　システムブート時に、ファームウェアが起動され、システムコンフィグレーションを判断する。
【００２８】
　必要であればシステムが初期化された後、オペレーションはＯＳに渡される。
　すなわち、システムがＯＳをブートアップする。
　システムは、ブートアップされるとき、相異なるプラットフォームコンフィグレーションの情報を有していなければならない。
　ＡＣＰＩは、多様なプラットフォームコンフィグレーションを定義するための、インタフェースオブジェクトおよび名前空間を有する、ハードウェアコンフィグレーションのための仕様である。
【００２９】
　ＡＣＰＩ名前空間は、論理的な方法で、コンピュータシステムの階層を記述する。
　たとえば、ＯＳは、名前空間を消費するとき、下位のハードウェアがどのようなものかの描像を得る。
　したがって、ＯＳが、所与のハードウェアコンポーネントに対するリソースを取得する必要がある場合、または、コンポーネントにアクセスする仕方を知る必要がある場合には、名前空間を参照する。
【００３０】
　たとえば、ＯＳがマシンをスリープさせる必要がある場合には、デバイスをスリープさせる仕方を識別するオブジェクトが存在する。
　ＯＳは、名前空間で定義されたインタフェースあるいはオブジェクトを用いてハードウェアを操作する。
　これがＡＣＰＩの機能である。
【００３１】
　本発明のシステムおよび方法は、単にＩＡ−３２プラットフォームから残存しているレガシーコードを使用するのではなく、ＩＡ−６４命令セットアーキテクチャを利用する。
　具体的には、今日のコンピュータシステムは、５００を優に超える制御すべきデバイスおよびリソースを有することがある。
【００３２】
　リソースアドレスを定義するために従来のようにＩ／Ｏポート空間を使用することは不十分である。
　本発明のシステムおよび方法は、ＡＣＰＩの既存のコンストラクトであるｖｅｎｄｏｒ−ｌｏｎｇフィールドを利用して、要求されるリソースに対応する適当なメモリマップドＩ／Ｏ情報を渡す。
【００３３】
　ここで図面、特に図１を参照すると、ＯＳとＡＣＰＩインタプリタとＡＣＰＩテーブルの間の相互作用を図示したブロック図が示されている。
　通常のシステム動作中に、ＯＳ１０１は、何らかのハードウェア機能にアクセスすなわちそれを操作する必要がある。
　これを行うためには、ＯＳ１０１はハードウェアが動作する方法に関する情報を有していなければならない。
【００３４】
　ブートアップ時に、システムファームウェア１０３はＡＣＰＩ名前空間を作成し、ＡＣＰＩテーブル１０９をシステムコンポーネント情報で埋める。
　ＯＳ１０１は、ハードウェアにアクセスすなわちそれを操作しようとするとき、ＡＣＰＩインタプリタ１０５を通じてＡＣＰＩ　ＡＭＬコード１０７を実行し、システム情報を取得する。
　従来技術のシステムでは、ＡＭＬは特定のオペレーティングシステム用にハードコードされているであろう。
【００３５】
　システムファームウェア１０３は、ブートアップ中に、その対応するＡＭＬ１０７を用意する。
　システムファームウェア１０３はまた、構築されたスタティックテーブル１０９もセットアップする。
【００３６】
　ＯＳが制御を取ると、ＯＳはＡＣＰＩテーブル１０９を見つける方法を自動的に知り、それらを取得し、それらを消費する。
　所与のブートに対して、スタティックＡＣＰＩテーブル１０９は、変化することなく、そのままにとどまる。
【００３７】
　ＡＣＰＩテーブルは、ロードされたシステムコンポーネントの名前空間を定義する。
　次に図２を参照すると、例示的な単純化されたＡＣＰＩ名前空間定義が示されている。
　名前空間は、パッケージ２０１、プロセッサオブジェクト２０３、電源リソースオブジェクト２０５、バス／デバイスオブジェクト２０７、データオブジェクト２０９および制御メソッドすなわちＡＭＬコード２１１を含み得る。
【００３８】
　Ｒｏｏｔ（パッケージ）２２１は、対応するプロセッサツリー、＼＿ＰＲ、２２３および対応するシステムバスツリー、＼＿ＳＢ、２２５を有する。
　システムバスツリーは、対応するシステムバスアダプタ、＿ＳＢＡ０　２２６、のツリーを同様に有する。
【００３９】
　ＰＣＩバス（バス／デバイスオブジェクト）、ＰＣＩ０、２２７は、＿ＳＢＡ０　２２６の子であり、対応するバス／デバイスツリーを有する。
　汎用イベントパッケージ、＼＿ＧＰＥ、２２９はＲｏｏｔ２２１の子である。
【００４０】
　この例示的な名前空間では、システムバスアダプタ＿ＳＢＡ０　２２６およびＰＣＩバスＰＣＩ０　２２７は両方ともデバイス識別子、＿ＨＩＤ、２３１および２２８、ならびにカレントリソースステータス・データオブジェクト、＿ＣＲＳ、２３３および２３０を有する。
　ＰＣＩバス２２７はまた、ＩＤＥ０デバイスのバス／デバイスオブジェクト２３５も有する。
【００４１】
　次に図３を参照すると、例示的なシステムバスアダプタＳＢＡ０　３００が示されている。
　ＳＢＡ０　３００は、チップセットレジスタ３０３を備えたシステムバスアダプタＳＢＡ３０１を有する。
　システムバスアダプタＳＢＡ３０１は、３個のローカルバスアダプタ（ＬＢＡ）３０５、３０９および３１３に接続される。
【００４２】
　ＬＢＡ３０５、３０９および３１３はそれぞれレジスタブロック３０７、３１１および３１５を有する。
　それぞれのＬＢＡはまた、ＰＣＩバス３１７、３１９および３２１も有する。
　ＰＣＩバス３１９は外部デバイス３２３に接続される。
【００４３】
　いかなる所与のチップセットもＩ／Ｏコントローラ（ＩＯＣ）を有するであろう。
　チップセットはまた、メモリ管理コントローラ（ＭＭＣ）を有するかもしれない。
　これらのコントローラ以外に、ＯＳはしばしば外部のものと相互作用する。
　チップセットレジスタは、これらの外部デバイスのための内部レジスタを有しない。
【００４４】
　チップセットは、いくつかの機能を統制するため、また、それが外部デバイスと相互作用する方法を統制するために、その固有のレジスタを有する。
　パーソナルコンピュータ（ＰＣ）の技術では、ＩＡ−３２命令セットアーキテクチャはＩＡ−６４命令セットアーキテクチャに移行しつつある。
　ＩＡ−３２では、レジスタは通常、Ｉ／Ｏポート空間と呼ばれるある一定のアドレス領域にマップされる。
【００４５】
　メモリマップドＩ／Ｏ（ＭＭＩＯ）方式は、アドレスをファームウェアコンポーネント、デバイスの物理アドレス、ＡＣＰＩデバイスアドレス、またはＩ／Ｏポート空間にマップすることができる。
　そのアドレスが使用されるとき、いかなる応答もそのアドレスがマップされているデバイスから発信される。
【００４６】
　ＯＳが、メモリを消費しているデバイスの理解において制限されている場合、そのデバイスをＡＣＰＩ名前空間に呈示することは、あるメモリ領域が実際には消費されているときに、消費されていないと考えるようＯＳを誤って導く可能性がある。
　ＯＳがこの領域を再割当てする場合、コンフリクトが生じるであろう。
　このシナリオは、レジスタマップの場合に当てはまる。
　ＭＭＩＯは、他のメモリエリアだけでなく、レジスタをマップするためにも使用される。
【００４７】
　ＡＣＰＩリソースが記述されるとき、あるものはプロデューサとして識別され、あるものはコンシューマとして識別される。
　メモリアクセスがチップセットによって受け取られた場合、チップセットは、応答の方法を決定しなければならない。
　チップセットは、そのメモリ範囲を所有していると応答することがあるが、その場合、そのアドレス範囲を実際に所有している子リソースにデータを渡す。
【００４８】
　したがって、チップセットはプロデューサである。
　プロデューサは単に、メモリアクセスを子デバイスに反映させる。
　その子デバイスが、アクセスされているメモリを直接に所有している場合、その子デバイスはそのトランザクションのコンシューマである。
【００４９】
　再び図２を参照すると、システムバスアダプタ＿ＳＢＡ０　２２６は、その子ＰＣＩ０デバイス２２７のために使用されるアドレス範囲について知っている。
　＿ＳＢＡ０はプロデューサであり、同様にＰＣＩ０はそのアドレス範囲のプロデューサである。
　ＰＣＩ０デバイス２２７は、コンシューマとしてそのアドレスに応答することになる。
【００５０】
　次に図４を参照すると、ＭＭＩＯとともに使用される例示的なメモリブロックが示されている。
　この例示的なＭＭＩＯにおいて、メモリ領域０〜５（参照符号４０１で示す）はＲＡＭである。
　システムバスアダプタＳＢＡはメモリ５〜９（参照符号４０３で示す）を有する。
【００５１】
　したがって、アドレス５〜９を通じてのすべてのトランザクションはＳＢＡによって所有される。
　メモリエリア７がレジスタマップであると仮定する。
　ＯＳは、５〜９が本当にメモリであって、技術的にはＳＢＡがデバイスであるのでデバイスにマップされているのだと理解する。
【００５２】
　新たなデバイスが接続され、１ユニットのメモリを必要とする。
　本発明の方法がなければ、ＯＳは、レジスタマップエリア（７）を見て、それを、メモリの割当て可能なセクションであるとみなす。
　従来技術では、このメモリ領域がすでに他の用途専用とされていることを示す方法がなかった。
　したがって、ＯＳは、ＰＣＩバスがそのメモリの一部を消費することを必要としており、そのため他のリソースには利用可能でないことを知ることができなかった。
【００５３】
　従来技術のシステムは、必要に応じてメモリの領域を割り当てた。
　たとえば、メモリ領域４（４０５）がＰＣＩ０によって消費され、メモリ領域１〜２がＰＣＩ２（４０７）によって消費されていると仮定する。
　新たなデバイスＤがインストールされ、メモリ領域１〜５は空いているように見えると仮定する。
【００５４】
　領域１〜２および４〜４はＰＣＩ０およびＰＣＩ２によって使用されている。
　デバイスＤは１ユニットのメモリを必要とする。
　ＯＳは領域０〜５を見て、領域３〜３が空いているように見えると判断する。
　そこでＯＳは、領域３〜３をデバイスＤのために割り当てる。
　Ｄが２ユニットを必要としたとすれば、ＯＳは他のデバイスのうちの１つを再マップして、２メモリユニットを有する連続領域を作成しなければならないであろう。
【００５５】
　ＡＣＰＩでは、メモリには、それが消費されていることを示す属性があるが、ＩＡ−３２のために書かれたレガシーコードは、Ｉ／Ｏポート空間に対応することができるだけであり、ＭＭＩＯには対応することができない。
　レジスタマップをＭＭＩＯコンストラクトに取り入れる標準的な方法はない。
【００５６】
　より多くのメモリが子デバイスあるいはリソースに割り当てられなければならない場合、親はその領域の制御を取り、それを割り当てる。
　ツールおよびデバイスドライバがハードウェアと直接相互作用することを強いられないように、レジスタマップがツールおよびデバイスドライバに呈示されなければならない。
　したがって、ドライバアプリケーションまたはツールは、ハードウェアと相互作用するため、あるいはリソースを取得するためには、ＡＣＰＩを使用しなければならない。
【００５７】
　本発明のシステムおよび方法は、ＡＣＰＩの＿ＣＲＳ（カレントリソース設定）データオブジェクトを利用して、ＭＭＩＯアドレス情報をＯＳから隠蔽し、ＯＳが誤ってメモリ領域を再割当てすることがないようにする。
　リソースが要求されると、そのリソースを要求するイベントは、＿ＣＲＳデータオブジェクトにおけるカレントリソース設定を返す。
　＿ＣＲＳオブジェクトは、デバイスに現在割り当てられているシステムリソースを記述するバイトストリームに評価される。
　さらに、バスデバイスは、それがデコードし、その子デバイスに割り当てることができるリソースを供給しなければならない。
【００５８】
　たとえば、本発明の方法のＭＭＩＯ技法を用いて、ＳＢＡはそのＰＣＩバスのためにメモリ領域７〜８を使用する。
　メモリ領域７〜８（４１１）は、ＯＳが＿ＣＲＳを要求するときには、ＯＳがこの領域を再割当てしようとすることのないように、ＯＳから隠蔽されなければならない。
　ＯＳがＳＢＡのためのカレントリソースを判断する必要があるとき、リソースステータス＿ＣＲＳデータオブジェクトは５〜６および８〜９を返すことになる。
【００５９】
　領域７〜８は、＿ＣＲＳで呈示される代わりに、ｖｅｎｄｏｒ−ｌｏｎｇと呼ばれるバイトストリームで識別される。
　ＯＳはこのストリングの内容を無視するが、適当なときに、それをもとのリクエスタすなわちデバイスドライバに渡す。
　したがって、ＯＳには、メモリ領域０〜６および８〜１０は見えるが、７〜８は見えない。
　メモリ位置７は隠蔽されたままとなる。
　ＯＳは、０〜５はＲＡＭであり、５〜６および８〜９はＳＢＡによって所有されていることを知る。
【００６０】
　ＰＣＩバスもまたステータスを返すことができる。
　図５は、領域７〜８におけるメモリ空間の詳細を示す。
　ＳＢＡ０のレジスタマップは７〜７．５（符号５０１）である。
　ＰＣＩ１は７．５〜７．８（符号５０３）を所有する。
【００６１】
　ＰＣＩ２は７．８〜７．８５（符号５０５）を所有する。
　ＰＣＩ３は７．８５〜８（符号５０７）を所有する。
　しかし、＿ＣＲＳデータがＳＢＡリソースに関するクエリから返されるとき、領域７〜８に対するメモリエリアはｖｅｎｄｏｒ−ｌｏｎｇバイトストリームでのみ返される。
　ＡＣＰＩはこのデータを無視するため、このメモリエリアは有効に隠蔽される。
【００６２】
　ＯＳが、ＰＣＩ１に対するカレントリソースを要求すると仮定する。
　ＰＣＩ１は、７．５〜７．８のメモリマップを所有している。
　ＰＣＩ１はまた、隠蔽されたレジスタマップだけでなく、通常のマップ内のメモリも有するであろう。
　たとえば、この例では、ＰＣＩ１はメモリ８〜８．５（図４、符号４１３）を有する。
　＿ＣＲＳデータがＰＣＩ１リソースに関するクエリに対して返されるとき、ＯＳには８〜８．５のみが見え、７．５〜７．８の領域は隠蔽されたままとなるであろう。
　この隠蔽された情報はｖｅｎｄｏｒ−ｌｏｎｇバイトストリームで送られ、このオブジェクトを理解するために開発されたツールによってのみ使用される。
【００６３】
　１つの目標は、ＯＳが、すでに所有されているレジスタメモリを、別のＰＣＩデバイスまたは別のアドインデバイスに与えないようにすることである。
　これは、カスタマ／ユーザには見えないローカルバスアダプタまたは他のデバイスのような項目にとって必要である。
　それらはＯＳには見えるが、カスタマには見えない。
【００６４】
　それはまた、ビデオカード、ネットワークカード、または他のデバイスのためのデバイスドライバのパフォーマンスを微調整するためにも望ましいかもしれない。
　これは、レジスタ設定を微調整することによって行うことができる。
　隠蔽されたチップセットレジスタアドレスにアクセスすることができることを知っているドライバは、チップセット内の設定を変更することができる。
　たとえば、あるネットワークカードは、あるバスの下ではパフォーマンスが上がる可能性がある。
【００６５】
　これに対して、従来技術のシステムでは、レジスタアドレスが潜在的な誤使用にさらされていたために、ドライバを最適化することができなかった。
　従来技術のレジスタマップは、ＯＳに呈示されると、何か他の機能のためにＯＳによる誤りによって自動的に消費されてしまう可能性があった。
【００６６】
　たとえば、レジスタマップはＰＣＩデバイスにマップされる。
　システムプロセッサがあるアドレスにアクセスするとき、そのアドレスはチップセットを通って来る。
　アドレスがチップセットを通って来るとき、それはＰＣＩデバイスによって所有されているとして識別される。
【００６７】
　ＡＣＰＩツールは、レジスタマップが隠蔽されているために、＿ＣＲＳで返される情報に基づいてレジスタにアクセスすることはできないであろう。
　したがって、適当なメモリアドレス情報を、それを必要としているツールあるいはデバイスドライバに渡すために、ｖｅｎｄｏｒ−ｌｏｎｇディスクリプタ（０ｘ４）が使用される。
　したがって、ＯＳまたは他のアプリケーションがそのメモリ領域を見るとき、見えるのは最初の部分（＿ＣＲＳデータオブジェクト）だけであり、ＯＳは、ｖｅｎｄｏｒ　ｌｏｎｇとマークされているものを文字通りただ無視するだけである。
【００６８】
　ここで、ｖｅｎｄｏｒ−ｌｏｎｇバイトストリームはＭＭＩＯ用途の場合に以下のように定義される。
　１バイトがリソースタイプを示す。
　別の１バイトはリソースタイプデータストリームの開始を示し、第３のバイトはそのリソースに対するデータストリームの終了を示す。
【００６９】
　たとえば、最初の２バイトは、開始アドレスまたはアドレスのサイズである。
　最後のアドレスは終了アドレスである。
　当業者には理解されるように、さまざまなフォーマットが定義可能である。
　このようにして、ｖｅｎｄｏｒ−ｌｏｎｇデータオブジェクトは今や、デバイスおよびリソースへのアクセスを必要としているツールに有益な情報を渡すことができる。
【００７０】
　ｖｅｎｄｏｒ　ｌｏｎｇのテンプレートの例を、例示の目的で以下に示す。
【００７１】
【表１】
2004070946.tif 000003
【００７２】
　以上、既存のＡＣＰＩ変数をＭＭＩＯ情報で埋めて使用する新規な方法の好ましい実施形態（それらは例示的であることを意図しており、限定的であることは意図していない）について説明したが、当業者は上記の教示に照らして修正および変形を行うことが可能であることが留意される。
　したがって、理解されるべきであるが、開示された本発明の特定の実施形態においては、併記の特許請求項によって規定される本発明の範囲および精神に含まれる変更を行うことが可能である。
【産業上の利用可能性】
【００７３】
　本発明は、コンピュータのシステムデバイスの管理に利用可能である。
【図面の簡単な説明】
【００７４】
【図１】ＯＳとＡＣＰＩインタプリタとＡＣＰＩテーブルとの間の相互作用を図示したブロック図を示す。
【図２】例示的な単純化されたＡＣＰＩ名前空間定義を示す。
【図３】例示的なシステムバスアダプタＳＢＡ０のブロック図である。
【図４】ＭＭＩＯとともに使用される例示的なメモリブロックを示す。
【図５】図４のメモリ空間の領域７における詳細を示す。
【符号の説明】
【００７５】
１０１・・・ＯＳ、
１０３・・・システムファームウェア、
１０９・・・ＡＣＰＩテーブル、
１０５・・・ＡＣＰＩインタプリタ
１０７・・・ＡＣＰＩ　ＡＭＬコード、
２０１・・・パッケージ
２０３・・・プロセッサオブジェクト、
２０５・・・電源リソースオブジェクト、
２０７・・・バス／デバイスオブジェクト、
２０９・・・データオブジェクト、
２１１・・・ＡＭＬコード、
２２１・・・Ｒｏｏｔ（パッケージ）、
２２７・・・ＰＣＩバス、
２３５・・・バス／デバイスオブジェクト、
３００・・・システムバスアダプタＳＢＡ０、
３０１・・・システムバスアダプタＳＢＡ、
３０３・・・チップセットレジスタ、
３０５，３０９，３１３・・・ローカルバスアダプタ（ＬＢＡ）、
３０７，３１１，３１５・・・レジスタブロック、
３１７，３１９，３２１・・・ＰＣＩバス、
【図１】
2004070946.tif 000004
【図２】
2004070946.tif 000005
【図３】
2004070946.tif 000006
【図４】
2004070946.tif 000007
【図５】
2004070946.tif 000008