JP2004070953A - 複数のオペレーティングシステムをサポートする方法 - Google Patents

Abstract

【課題】単一コンピュータシステム、またはプラットフォームにおいて、相互に排他的な要件を有する複数のオペレーティングシステムをサポートするシステムおよび方法を提供すること。
【解決手段】オペレーティングシステム（１０１）はＡＣＰＩ（１０５）変数を設定して、プラットフォーム（２００）において実行されるオペレーティングシステム（１０１）を特定する。システムファームウェア（１０３）は、自動的にプラットフォーム上においてすべてのオペレーティングシステムを充足する機能の共通のセットを作り出す。ＡＣＰＩインタプリタ（１０５）は、ブートアップ時の変数が特定するＯＳ（１０１）を読み出し、それを、オペレーティングシステム（１０１）に依存する条件付きコード（１０７）において使用して、システムコンポーネントの動作を定義する。
【選択図】図１

Description

　ＡＣＰＩをサポートする複数のオペレーティングシステムにおいてオペレーティングシステムが定義したフィールドを使用するシステムに関する。

　ＡＣＰＩ(Advanced Configuration and Power Interface)は、ラップトップ、デスクトップ、サーバ等を含むコンピュータのオペレーティングシステムにハードウェア状態情報を提供する仕様である。ＡＣＰＩについてのより多くの情報は、Compaq Computer 社、Intel社、Microsoft 社、Phoenix Technologies Ltd.、およびToshiba 社が共同で規定した５００頁の「Advanced Configuration and Power Interface Specification」(Revision 2.0a、March 31,2002）に見られる。ＡＣＰＩ仕様は、装置とシステム全体の両方に対して堅牢な、オペレーティングシステム（ＯＳ）によるマザーボードデバイスの構成および電力の直接管理を可能にする業界標準インタフェースを確立するために策定されたものである。ＡＣＰＩは、オペレーティングシステムによる構成および電力の直接管理（ＯＳＰＭ）における重要な要素である。

　ＡＣＰＩは、Ｍｉｃｒｏｓｏｆｔ（商標）社市販のＷｉｎｄｏｗｓ（商標）、様々なベンダーからオープンソースとして入手可能なＬｉｎｕｘ、Hewlett-Packard　社市販のＨＰ−ＵＸ等の多種多様なオペレーティングシステムを実行させるパーソナルコンピュータ（ＰＣ）で使用される。またＡＣＰＩは、ハードウェア資源を操作することもできる。たとえば、ＡＣＰＩは、コンピュータシステムの周辺機器の電源をオンオフできるようにすることによって電力管理を支援し、電力管理を改善させる。ＡＣＰＩはまた、外部装置によってコンピュータシステムをオンオフできるようにする。たとえば、マウスに触れる、またはキーを押下することにより、ＡＣＰＩを使用するコンピュータシステムを起動させることができる。

　従来のＡＣＰＩは、様々な理由により扱いが難しい。第１に、ＡＣＰＩは、コンピュータシステムプラットフォームにネイティブ（固有）のアセンブリ言語で書かれない。その代わりに、ＡＣＰＩは、独自のソース言語および機械語であるＡＣＰＩソース言語（ＡＳＬ）およびＡＣＰＩ機械語（ＡＭＬ）をそれぞれ有する。用途が高度に特化されているため、ＡＳＬのプログラマは比較的少ない。さらに、ＡＳＬは、使用が限定されていることからコンストラクト（construct）が比較的少ない。その上、ＡＣＰＩコードの設計は従来、モノリシックである。したがってこれにより、ＡＣＰＩコードを他のプラットフォーム、さらには同じプラットフォームの異なる構成に移植することが困難になる。このため、新しく設計されたプラットフォームを扱うには、新しいＡＳＬコードを書く必要がある。ＡＳＬプログラマの数が限られていることから、コードを新たに書くと、問題およびコストが一層増してしまう。

　ＡＣＰＩは、静的テーブルおよび解釈可能テーブルの両方からなる。ブートアップ時に、システムファームウェア（通常ＢＩＯＳ、すなわち基本入出力システム）が静的テーブルを構築し、オペレーティングシステムがこの静的テーブルを使用する。解釈可能テーブルはＡＭＬからなる。ＡＭＬはコンパイルされてから、システムファームウェアに併合される。オペレーティングシステムは、ＡＭＬを解釈可能テーブルから読み取り、ＡＣＰＩインタプリタを使用して構築されたインタフェースを実行する。このようにして、オペレーティングシステムはハードウェア資源を操作する。解釈可能テーブルがシステムファームウェアに併合されるため、この従来の方法は柔軟性、および拡張性を欠き、相違するシステム構成に適合するように再プログラムするために相当の時間を要する。

　たとえば、従来、ＡＳＬ開発者は、特定の構成のプラットフォームまたはその差(variance)を指定するＡＣＰＩコードを書く。不都合なことに、ハードウェア変更が少しでも行われる場合には、設計を変更する必要がある。このためには、新しいＡＭＬコードを書き、新しいテーブルをシステムファームウェアに併合する必要がある。したがって、従来の設計には移植性がない、すなわち再利用することができない。

　さらに、従来ＡＣＰＩでは、プラットフォームの差がある場合、または相互に排他的なＡＣＰＩ要件を有する２つ以上のＡＣＰＩアウェアＯＳシステムをサポートする場合、異なるシステムファームウェアＲＯＭ（読み取り専用メモリ）またはＢＩＯＳを使用する必要があった。同じシステムが複数のオペレーティングシステムをサポートすべき場合、異なるシステムファームウェアＲＯＭを使用する必要もあった。たとえば、現行のパーソナルコンピュータの分野では、ＩＡ−３２命令セットが使用されている。ＡＣＰＩは、主として、Ｍｉｃｒｏｓｏｆｔ（商標）ファミリのオペレーティングシステム、特にＩＡ−３２命令セットを有するシステムによって用いられている。

　ＡＣＰＩは、様々なオペレーティングシステムに標準インタフェースとして受け入れられてきた。新しい命令セットアーキテクチャＩＡ−６４が開発されつつあるが、レガシーＡＣＰＩコード、またはメソッドと一緒では、その利点を十分に利用することができない。Ｉｎｔｅｌ（商標）社から市販されている新しいＩｔａｎｉｕｍ（商標）プロセッサファミリは、ＩＡ−６４命令セットを使用している。現行の手法を利用すると、このファミリの新しいプロセッサ毎に、ＡＳＬを一意に書き換える必要があるだろう。さらに、所与のプロセッサに複数のオペレーティングシステムがある場合も同様に、ＡＳＬは各ＯＳ毎に一意である必要がある。

　ＡＣＰＩ名前空間は、名前付きのオブジェクトを含むＯＳ制御メモリ内の階層ツリー構造である。こうしたオブジェクトは、データオブジェクト、制御メソッドオブジェクト、バス／デバイスパッケージオブジェクト等であり得る。ＯＳは、ＡＣＰＩ　ＢＩＯＳに存在するＡＣＰＩテーブルから定義ブロックをロードかつ／またはアンロードすることにより、実行時に名前空間の内容を動的に変更する。ＡＣＰＩ名前空間中の情報はすべて、差分定義ブロックと、１つまたは複数の他の定義ブロックとを含む差分システム記述テーブル（ＤＳＤＴ）からの情報である。現行技術では、ＯＥＭ（相手先商標による製品製造会社）は、ベースシステムについての実施情報および構成情報を提供するＤＳＤＴをＡＣＰＩ互換ＯＳに供給しなければならない。ＯＳは、常にシステムブート時にＤＳＤＴ情報をＡＣＰＩ名前空間に挿入し、これを除去することは決してない。

　別のＡＣＰＩコンストラクトは、システム記述補助テーブル（ＳＳＤＴ）である。ＳＳＤＴはＤＳＤＴの延長であり、複数のＳＳＤＴをプラットフォーム記述の一部として使用することができる。ＤＳＤＴがＡＣＰＩ名前空間にロードされた後に、一意のＯＥＭテーブルＩＤを有する各補助記述テーブルがロードされる。これによりＯＥＭは、他のテーブルにわずかなシステム選択肢を付加しながら、あるテーブルに基本的なサポートを提供することができる。追加のテーブルが付加できるのはデータのみであり、前のテーブルからのデータを上書きすることはできない。

　ＡＣＰＩ仕様は、オペレーティングシステムを特定するストリングに評価されるオブジェクトとしてオペレーティングシステム定義変数＼＿ＯＳを定義する。堅牢なＯＳＰＭ実施形態では、＼＿ＯＳは各ＯＳリリースを別様に評価する。これにより、ＡＭＬコードはＯＳＰＭ実施形態の違いに適応することができる。この値は、ＡＭＬインタプリタが各種改訂されても変化しない。この変数は現在、すべてのオペレーティングシステムに実装されているわけではなく、使用される場合でも標準的な方法で使用されない。

　異なるオペレーティングシステムと動作可能な従来技術による単一コンピュータシステムは、一意のＢＩＯＳ、またはファームウェアを通常有し、ロードされたＢＩＯＳまたはファームウェアは、１つのオペレーティングシステムにのみ固有である。異なるＯＳをロードするには、ファームウェアをスワップアウトするか、またはプログラミングし直す必要がある。

　本発明の目的は、単一コンピュータシステム、またはプラットフォームにおいて、相互に排他的な要件を有する複数のオペレーティングシステムをサポートするシステムおよび方法を提供することである。

　オペレーティングシステムは、ＡＣＰＩ変数＼＿ＯＳをセットして、プラットフォーム上で実行されているオペレーティングシステムを特定する。システムファームウェアが、プラットフォーム上で実行することのできるすべてのオペレーティングシステムを満足させる共通機能セットを自動的にロードする。ＡＣＰＩインタプリタは、ブートアップ時に＼＿ＯＳ変数を読み出す。

　２つ以上のオペレーティングシステムが存在する場合に適合するために、ＡＣＰＩ原始コードが書かれる。＼＿ＯＳ変数は、現在実行中のＯＳ用にシステムをカスタマイズするかどうかの条件として用いられる。ＡＣＰＩはやはりソース言語で書き、次いでＡＣＰＩ機械語にコンパイルする必要がある。オペレーティングシステムの特定情報を使用する追加ロジックが、ＡＳＬコードに埋め込まれる。

　ＡＣＰＩは、新しいＩＡ−６４命令セットに依然として用いられているＩＡ−３２命令セットの概念である。ＡＣＰＩは、ハードウェア操作および構成データを抽出して、オペレーティングシステム（ＯＳ）とファームウェアとの対話のためにハードウェアの構成を定義する方法である。ＡＣＰＩは業界標準の仕様である。現在、商業的な３つの主なパーソナルコンピュータ（ＰＣ）のオペレーティングシステム、すなわちＬｉｎｕｘ、ＨＰ／ＵＸ、およびＷｉｎｄｏｗｓ（商標）は、ＡＣＰＩをＩＡ−３２空間で使用しており、ＡＣＰＩを新しいＩＡ−６４空間で使用して実行することになる。システムがブートされると、ファームウェアに電源が投入され、システム構成を確認する。必要であればシステムが初期化され、次いで動作がＯＳに引き渡される、すなわちＯＳをブートアップする。システムは、ブートアップされるとき、相違するプラットフォーム構成についての知識を持っていなければならない。ＡＣＰＩは、多様なプラットフォーム構成を定義するためのインタフェースオブジェクトおよび名前空間を有するハードウェア構成のための仕様である。

　新しいプラットフォームに対するＡＣＰＩコードの作成をより構造化するとともに、ＡＣＰＩコードプラットフォームとオペレーティングシステムとを独立させることが望ましい。これは、ＡＣＰＩコードにモジュール方式の設計を使用する構築化されたアプローチを用いて達成することができる。このＡＣＰＩ設計方法は現在使用されておらず、実際、開発者には不評である。

　従来のＡＣＰＩ設計に伴う別の問題は、ＡＣＰＩ開発者がＡＳＬを使用して任意所与のプラットフォームまたはオペレーティングシステムバリアンスを完全に記述する必要があったことである。この設計では、ブートアップ中のハードウェアコンポーネントの欠損を含め、行われたハードウェア変更がごくわずかであった場合でも移植または再利用することができなかった。その上、同じシステムが複数のオペレーティングシステムをサポートする場合、所与のプラットフォームタイプのバリアンスは同じＲＯＭを採用することができなかった。

　ＡＣＰＩ名前空間は、コンピュータシステムの階層を論理的な方法で記述する。たとえば、ＯＳが名前空間を埋めると、下位にあるハードウェアがどのように見えるかついてのイメージが得られる。したがって、ＯＳが所与のハードウェアコンポーネントに資源を獲得する必要がある場合、またはコンポーネントにどのようにアクセスするかを知る必要がある場合には、名前空間を見る。たとえば、ＯＳがマシンを待機モードにする必要がある場合には、装置を待機モードにする方法を特定するオブジェクトがある。ＯＳは、名前空間において定義されるインタフェースまたはオブジェクトを使用してハードウェアを操作する。これはＡＣＰＩの機能である。

　本システムおよび本方法の利点は、共通または一般的にプログラムされたファームウェアを使用して様々なオペレーティングシステムを実行させることができることである。現在のファームウェアの未だ満たされていない要望は、１つのＯＳを使用する１つのプラットフォームという一構成でしか使用できないことである。本システムおよび本方法では、システムファームウェアが３つの主なＯＳすべてと共に同時に動作することができる。したがって、ＯＳが変更されるたびにファームウェアをアップグレード／変更する必要がない。このためには特に、どのＯＳがブート時にプラットフォームで実行されているかをＯＳが知る必要がある。

　これより図面、特に図１を参照して、ＯＳ、ＡＣＰＩインタプリタ、およびＡＣＰＩテーブルの間の対話を示すブロック図を示す。システムの通常動作中、ＯＳ１０１はいくつかのハードウェア機能にアクセスするか、または動作させる必要がある。このためには、ＯＳはハードウェアがどのように動作するかについての情報を持たなければならない。ブートアップすると、システムファームウェア１０３が上述したＡＣＰＩ名前空間を作成し、ＡＣＰＩテーブル１０９にシステムコンポーネント情報を入れる。ＯＳ１０１は、ハードウェアにアクセスするかまたはハードウェアに動作させようとするとき、ＡＣＰＩインタプリタ１０５を通してＡＣＰＩ　ＡＭＬコード１０７を実行してシステム情報を検索する。従来技術によるシステムでは、ＡＭＬは特定のオペレーティングシステムにハードコードされる。

　ＡＣＰＩテーブルは、静的テーブルおよび動的テーブルの両方からなる。動的テーブルは、たとえばホットプラグ可能な装置に対応する。システムファームウェア１０３がブートアップされると、対応するＡＭＬ１０７を実行する。システムファームウェア１０３は、構築された静的テーブル１０９もセットアップする。テーブルは構造化されており、ファームウェアはメモリにこれらテーブルを作成し、メモリに残す（ＡＣＰＩテーブル１０９）。ＯＳは、制御権を有するときには、ＡＣＰＩテーブル１０９の発見方法、検索方法、および使用方法を自動的に知る。これらＡＣＰＩテーブル１０９は本質的に静的なものである。所与のブートについて、静的ＡＣＰＩテーブル１０９は変更されることなくそのままである。

　ファームウェア１０３はまた、ＡＣＰＩ　ＡＭＬ１０７の動的な部分もセットアップする。ＯＳ１０１が起動するとき、ＯＳ１０１はＡＣＰＩインタプリタ１０５を起動する。インタプリタ１０５はＡＭＬ１０７を消費する。このＡＭＬ１０７は、一部は上述したように静的であり、一部は本質的に動的なものである。ホットプラグ可能なカードをシステムに追加する場合がある。ホットプラグ可能な装置には、標準オブジェクト、たとえば＿ＥＪ０（デバイス取り外しオブジェクト、たとえば、イジェクトオブジェクト）および＿Ｌｘｘ（制御メソッド、たとえば、挿入オブジェクト）が関連付けられている。ホットプラグ可能なカードが追加されると、そのカードを取り扱う方法についての命令が生成される。そのホットプラグイベントのためにＡＭＬバイトコードが書かれて実行される。イベントが処理され、次いで状態がＯＳに返される。このようにすれば、ＯＳは特定のシステムのホットプラグ動作をどのように行うべきかについて知る必要がない。ファームウェア設計者は、ホットプラグ定義をＡＳＬで書き、そのコードがコンパイルされてＡＭＬ１０７の一部になる。ＯＳが実行され、たとえば、ホットプラグ可能なデバイスをイジェクトする必要があるかどうかを判定する。ＯＳは、命令をＡＣＰＩインタプリタ１０５に送り、次いでハードウェアを操作する。この例では、デバイスがイジェクトされ、ＯＳは動作から状態が返ってくるのを待つ。

　ＡＣＰＩテーブルは、ロードされたシステムコンポーネントの名前空間を定義する。これより図２を参照して、ＯＳがＡＣＰＩインタプリタを介してハードウェアと対話することができるように名前空間を定義する必要がある例示的なシステム２００を示す。システムは、システムバスアダプタＳＢＡ０　２０３に接続されたＣＰＵ２０１を有する。システムバスアダプタ２０３は、３つのローカルバスアダプタＬＢＡ１　２０５、ＬＢＡ２　２０７、およびＬＢＡ２　２０９に接続されている。ＬＢＡ１　２０５はＰＣＩスロットＰＣＩ１　２１１を有する。ＬＢＡ３　２０９はＰＣＩスロットＰＣＩ５　２１３を有する。オペレーティングシステムが適宜機能するためには、ＡＣＰＩインタプリタがＯＳとハードウェアとの間にインタフェースを提供するように、これらシステムコンポーネントがＡＣＰＩ名前空間で記述されなければならない。

　これより図３を参照して、図２における例示的なシステムに対応する簡単にした例示的なＡＣＰＩ名前空間定義を示す。ＣＰＵ３０１のシステムバス＿ＳＢは、子システムバスアダプタ＿ＳＢＡ０　３０３を有する。システムバスアダプタ＿ＳＢＡ０　３０３は、子である＿ＣＲＳ（現在の資源設定）３０５と、３つのローカルバスアダプタ＿ＬＢＡ１　３０７、＿ＬＢＡ２　３０９、および＿ＬＢＡ３　３１１とを有する。ローカルバスアダプタ＿ＬＢＡ１　３０７は子ＰＣＩスロットＰＣＩ１　３１３を有し、ローカルバスアダプタ＿ＬＢＡ３　３１１は子ＰＣＩスロットＰＣＩ５　３１５を有する。ローカルバスアダプタ＿ＬＢＡ１　３０７、＿ＬＢＡ２　３０９、および＿ＬＢＡ３　３１１にはそれぞれ＿ＣＲＳ（現在の資源状態）３１７、３１９、および３２１として他の子も関連付けられる。ＰＣＩスロットは、＿ＣＲＳ３２３および３２５も有する。＿ＰＣＩ１は状態＿ＳＴＡ３２７もさらに有する。

　ＡＣＰＩ仕様は、プラットフォーム上で実行されているオペレーティングシステムを特定する＼＿ＯＳ変数も定義する。システムファームウェアは、プラットフォーム上で実行可能なすべてのオペレーティングシステムを満足させる共通機能セットを使用して自動的にブートアップする。ＡＣＰＩインタプリタは、ブートアップ時に＼＿ＯＳ変数を読み取る。この変数は、ＩＡ−３２命令セットにも定義されていたが、すべてのオペレーティングシステムに幅広く使用されているわけではなかった。現在このフィールドを規則正しく埋めるオペレーティングシステムは、Ｗｉｎｄｏｗｓ（商標）のみである。

　本方法では、ＡＣＰＩ原始コードは、２つ以上のオペレーティングシステムが存在する場合に対処するように書かれる。＼＿ＯＳ変数は、現在実行中のＯＳ用にシステムをカスタマイズする条件として使用される。ＡＣＰＩは依然としてソース言語で書き、次いでＡＣＰＩ機械語にコンパイルする必要がある。しかし今回、現在ではＷｉｎｄｏｗｓ（商標）にのみ使用されている、オペレーティングシステムについての情報を使用する追加ロジックがコードに埋め込まれる。

　たとえば、イジェクト動作の完了にかかる最長許容時間はＯＳに応じて変化する。イジェクト動作の完了にＷｉｎｄｏｗｓ（商標）では３秒許され、Ｌｉｎｕｘでは１０秒許され、ＨＰ−ＵＸでは１５秒許されるものと仮定する。ファームウェアが現在実行中のＯＳを考慮せずにデフォルトである５秒を採用すると、Ｌｉｎｕｘが実行中の場合イジェクトに１０秒かかり、システムは失敗するか、または少なくともエラー状態になる。本方法では、＼＿ＯＳ変数を使用することにより、システムが様々なオペレーティングシステムに対応することが可能である。

　ＡＳＬは、＼＿ＯＳ変数をテストするように設計される。＼＿ＯＳ変数がどのように使用されるかについての単純な例を、プログラム設計言語（ＰＤＬ）で以下に示す。

　　IF ((＼＿OS==WINDOWS AND EJECT_TIME <=3Sec) OR
　　　　(＼＿OS==LINUX AND EJECT_TIME <=10Sec) OR
　　　　(＼＿OS==HP-UX AND EJECT_TIME <=15Sec)) THEN
　　　　　　　STATUS=SUCCESS
　　ELSE
　　　　STATUS=FAIL
　　ENDIF
　イジェクト時間がＯＳ定義のしきい値以下、すなわち３秒以下、１０秒以下、または１５秒以下の場合には、成功状態がＯＳに返される。イジェクト時間が許容されるしきい値よりも長い場合、失敗状態が返される。ＡＳＬプログラマは、オペレーティングシステムの種類に基づいた条件を現在使用しておらず、ＡＳＬを特定のオペレーティングシステムにハードコードしている。

　本方法は、ＯＳが＼＿ＯＳ変数を埋める場合に最適なモードで機能する。しかし、ＯＳが＼＿ＯＳ変数を埋めていない場合、または＼＿ＯＳ変数の値が未知の場合、デフォルトモードをコード化することができる。たとえば、上記ＰＤＬはここでは以下のようにコード化される。

　　IF ((＼＿OS==WINDOWS AND EJECT_TIME <=3Sec) OR
　　　　(＼＿OS==LINUX AND EJECT_TIME <=10Sec) OR
　　　　(＼＿OS==HP-UX AND EJECT_TIME <=15Sec) OR
　　　　(＼＿OS==undefined AND EJECT_TIME <=10 Sec)) THEN
　　　　　　　STATUS=SUCCESS
　　ELSE
　　　　STATUS=FAIL
　　ENDIF
　この方法では、ＡＳＬをコード化し直す必要なく、任意の数のオペレーティングシステムを１つのプラットフォームで実行させることができる。資源を隠す能力を強調する別の例は以下である。Ｗｉｎｄｏｗｓ（商標）は２５０本を越えるＰＣＩバスをコンピュータシステムにおいて処理することができず、一方Ｌｉｎｕｘは任意の量をサポートすることができるものと仮定する。ＡＣＰＩインタプリタが名前空間をロードアップすると、名前空間には３００本のＰＣＩバスが記述されている。ＡＭＬは、実行中のＯＳがＷｉｎｄｏｗｓ（商標）であることを発見する。３００本はＯＳが処理可能な本数を越えているため、越えた分の５０本のＰＣＩバスが名前空間からアンロードされ、Ｗｉｎｄｏｗｓ（商標）システムのブートが可能になる。

　ＡＣＰＩコード解釈時に既存の変数を埋めて条件として使用する新規の方法の好適な実施形態について述べたが（限定ではなく例示を意図する）、当業者は上記教示を鑑みて変更および変形を行うことができることに留意する。したがって、併記特許請求項によって規定される本発明の範囲および精神内にある、開示された本発明の特定の実施形態に変更を行ってよいことは認められよう。

ＯＳ、ＡＣＰＩインタプリタ、およびＡＣＰＩテーブルの間の対話を示すブロック図。 ＯＳがＡＣＰＩインタプリタを介してハードウェアと対話することができるようにするために名前空間を定義する必要がある例示的なシステム。 図２におけるシステムに対応する簡単にした例示的なＡＣＰＩ名前空間定義。

Claims (10)

1. 　コンピュータシステム上で実行されるオペレーティングシステムが定義したフィールドを使用して、相互に排他的な要件を有する複数のオペレーティングシステムをサポートする方法であって、
   　システムブートアップ中にアクセスすることが可能なオペレーティングシステム識別子を格納するステップと、
   　システムブートアップ中に使用される条件付きコードを提供するステップであって、前記条件付きコードは、システムコンポーネント定義インタプリタによって解釈されるとともに、前記オペレーティングシステム識別子で条件付けられ、システムコンポーネント定義は前記オペレーティングシステム識別子によって定義される、条件付きコードを提供するステップと、
   を含む方法。
2. 　前記オペレーティングシステム識別子がシステムブートアップ後に未定義のとき、インスタンスを収容するために前記オペレーティングシステム識別子にデフォルト値を提供するステップをさらに含む請求項１記載の方法。
3. 　前記システムコンポーネント定義インタプリタはＡＣＰＩインタプリタであり、該ＡＣＰＩインタプリタはＡＣＰＩ機械語を解釈し、前記オペレーティングシステム識別子はＡＣＰＩ定義変数である＼＿ＯＳである請求項１記載の方法。
4. 　オペレーティングシステムをコンピュータシステム上で実行することをさらに含み、前記オペレーティングシステムがシステムコンポーネントを利用するとき、前記システムコンポーネント定義インタプリタと対話する請求項１記載の方法。
5. 　システムブートアップ中に名前空間を埋めるステップをさらに含み、前記名前空間は前記コンピュータシステムに存在するシステムコンポーネントを定義し、前記オペレーティングシステムおよび前記システムコンポーネント定義インタプリタは前記名前空間にアクセス可能である請求項４記載の方法。
6. 　ＩＡ−６４命令ファームウェアを有する複数オペレーティングシステムのコンピュータシステムであって、
   　中央演算処理装置と、
   　該中央演算処理装置を少なくとも１つのシステムコンポーネントに接続するメモリバスと、
   　前記中央演算処理装置に接続され、前記コンピュータシステムをブートアップするシステムファームウェアであって、該システムファームウェアは、前記少なくとも１つのシステムコンポーネントを定義する共通名前空間を埋め、該共通名前空間はオペレーティングシステム識別子をさらに含むシステムファームウェアと、
   　前記オペレーティングシステムを前記システムコンポーネントに橋渡しするインタプリタインタフェースであって、前記共通名前空間および前記オペレーティングシステム識別子にアクセスするインタプリタインタフェースと、
   　システムコンポーネントの対話が必要な際に前記インタプリタインタフェースを使用する現オペレーティングシステムであって、前記インタプリタインタフェースの動作は前記オペレーティングシステム識別子で条件付けられる、現オペレーティングシステムと、
   を備えるシステム。
7. 　システムブートアップ後に未定義のとき、前記オペレーティングシステム識別子は予め定義されたタイプにセットされる請求項６記載のシステム。
8. 　前記インタプリタインタフェースはＡＣＰＩインタプリタであって、前記ＡＣＰＩインタプリタはＡＣＰＩ機械語を解釈し、前記オペレーティングシステム識別子はＡＣＰＩ定義変数である＼＿ＯＳであり、前記共通名前空間はＡＣＰＩテーブルを定義する請求項６記載のシステム。
9. 　前記現オペレーティングシステムは、Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ、およびＨＰ−ＵＸからなるオペレーティングシステム群から選択される請求項８記載のシステム。
10. 　前記コンピュータシステムはＩＡ−６４命令セットを使用する請求項６記載のシステム。
    

Images