JPH09507319A

JPH09507319A - 自動ブーティング・フレームワーク

Info

Publication number: JPH09507319A
Application number: JP7517403A
Authority: JP
Inventors: レモン，スティーヴン．ピー; ロス，パトリック，ディー．
Original assignee: オブジェクトテクノロジーライセンシングコーポレイション
Priority date: 1993-12-21
Filing date: 1994-09-15
Publication date: 1997-07-22
Also published as: EP0728332B1; CA2178581C; EP0728332A1; DE69404166D1; DE69404166T2; US5379431A; AU1287695A; CA2178581A1; WO1995017717A1

Abstract

(57)【要約】自動ブート・フレームワークが開示され、具体的には、ストレージ（記憶装置）および接続された周辺デバイスを備えたプロセッサをブートするとき使用されるシステムが開示されている。システムは、ストレージおよび１つまたは２つ以上の周辺デバイスをリセットすることによりコンピュータを初期化する手法を利用している。そのあと、システムは性能低下した環境を初期化して、オペレーティング・システムをアクチベートするとき使用されるようにする。性能低下したオペレーティング環境は、ファイル共有と他の重要な基本タスクを動作可能にして、入出力デバイス、システム・プリファレンスおよびハードウェア構成をロードし、その環境自体を入出力ファイル・システムに置き換えてオペレーティング・システムにより使用されるようにする。

Description

【発明の詳細な説明】自動ブーティング・フレームワーク発明の背景発明の分野本発明は、一般的にはコンピュータ・システムの入出力アーキテクチャを目的とし、より具体的にはコンピュータ・システムのオブジェクト指向入出力アーキテクチャを目的としている。関連技術代表的なコンピュータは、コンピュータに接続された周辺デバイスとのインタフェースとなる入出力（Ｉ／Ｏ）システムを含んでいる。この入出力システムは、コンピュータ・システムの資源と周辺デバイスとの間のインタフェースとして働いている。また、この入出力システムは、コンピュータ・システムで実行されるプログラムと周辺デバイスとの間のインタフェースともなっている。入出力システムは、従来の「手続き指向(procedure-oriented)」ソフトウェア・プログラミング技法（オブジェクト指向またはルール・ベースのソフトウェア・プログラミング技法と対比されている）を用いてインプリメント（実装）されているのが代表的である。理解されるように、手続き指向ソフトウェア・プログラミング技法を使用して作られたソフトウェア・プログラムは拡張が容易でないことがよくある。また、この種のソフトウェア・プログラムは再利用が容易でないこともよくある。従って、従来の入出力システムは拡張が容易でないことがよくあり、また、かかる入出力システムに関連するソフトウェアは再利用が容易でないことがよくある。代表例として、入出力システムは、単一のオペレーティング・システムに特定した形でインプリメントされている。この入出力システムは、オペレーティング・システムに関連する入出力関数コール(function call)に応答してそれを正しく処理しているが、この入出力システムは他のどのオペレーティング・システムでもサポートできる能力は備えていない。複数のオペレーティング・システムをサポートするコンピュータに対する要求が高まっている。明らかなように、従来の入出力システムを使用するコンピュータは、その入出力システムがサポートするオペレーション・システム(operation system)のみサポートできるので、現在のマーケットでは不利になっている。以上のように、要求されていることは、拡張が容易であり、再利用が容易であるソフトウェアを具体化しており、しかも、複数のオペレーティング・システムをサポートしているコンピュータの入出力システムである。発明の概要本発明は、劣化した(degradated)ファイル共用メカニズム(file sharing mech anism)を完全に定義したオペレーションで最初に初期化して、オペレーティング・システムのより高度化した側面を動作可能にするとき使用されるようにするブーティング・プロシージャを目的としている。ストレージ（記憶装置）および接続された周辺デバイスを備えたプロセッサをブートするのに使用するシステムが開示されている。このシステムはオブジェクト指向技法(object-oriented techn iques)を利用して、ストレージと１つまたは２つ以上の周辺デバイスをリセットすることによりコンピュータ・システムを初期化するようにしている。そのあと、システムは劣化した環境を初期化し、オペレーティング・システムをアクチベートするとき使用されるようにする。劣化したオペレーティング環境(operating environment)は、ファイル共用と他の重要な基本タスクを動作可能にして、入出力デバイス、システム優先(system preferences)、およびハードウェア構成にロードさせて、その環境自体を入出力システム・フレームワークに置き換えてオペレーティング・システムで使用されるようにする。本発明のその他の特徴と利点は、本発明の種々の実施例の構造とオペレーションと共に、添付図面を参照して以下で詳しく説明する。図面の簡単な説明図１は、好適実施例の好適実施例による入出力サービス・フレームワークを示す図である。図２は、好適実施例の入出力システムの全体構成を示すブロック図である。図３は、デバイス・アクセス・マネージャと割込みハンドラを抽象化した図であり、好適実施例のこれらのエレメント間のデータの流れを示している。図４は、好適実施例によるハードウェア階層の例を示す図である。図５は図４のハードウェア階層に対応するのもので、好適実施例によるソフトウェア階層を示す図である。図６は、好適実施例による親子関係を示す図である。図７は、好適実施例によるＳＣＳＩバス構成の例を示すブロック図である。図８は、好適実施例の特徴を説明するときに使用される、別のハードウェア階層の例を示す図である。図９は図８のハードウェア階層に対応するもので、好適実施例によるソフトウェア階層を示す図である。図１０は、好適実施例の入出力システムがその上で動作するコンピュータ・プラットフォームを示すブロック図である。図１１は、好適実施例によるブーティング・フレームワークのコンポーネントを示すブロック図である。図１２は、ブート・オペレーションのときの制御の流れを示すフローチャートである。図１３は、好適実施例によるブート・フレームワーク処理のタイムライン(tim eline)を示す図である。図１４は、好適実施例によるブート処理を示すブロック図である。図１５は、好適実施例によるBootImage目次(table of contents)を示すブロック図である。図１６は、好適実施例においてブーティングのために使用される処理を、ブーティング・タイムラインで再現して(recap)示す図である。好適実施例の詳細な説明概要好適実施例は、コンピュータの入出力（Ｉ／Ｏ）システムを目的としている。好適実施例の入出力システムは拡張が容易であり、再利用が容易であるソフトウェアを具体化し、複数のオペレーティング・システムをサポートしている。好適実施例のその他の利点については、以下で説明する。オブジェクト・テクノロジは好適実施例の入出力システムをインプリメント（実装）するために使用されている。従って、好適実施例はオブジェクト指向入出力システムを表している。オブジェクト・テクノロジの使用は普及しており、割込み処理のように現在までプロセッサ固有であり、性質上手続き向きであった多数のローレベル・サービスの抽象化をサポートしている。これらの一般化されたオブジェト・ベースの抽象化は、マイクロカーネル・テクノロジの使用と共に、デバイス・インタフェーシング(device interfacing)となる新モデルの生成を可能にしている。好適実施例の入出力システムは、サービス・プロバイダとそのクライアントとを関連づけたものである。意義のあるサービスをそのクライアントに提供するために、入出力システムは他のいくつかのサービス・プロバイダのクライアントとなる。図１０は、好適実施例によるオブジェクト指向入出力システムがそこに置かれているコンピュータ・プラットフォーム１００２を示すブロック図である。なお、別の好適実施例では、入出力システムはコンピュータ・プラットフォーム１００２と一緒に包含されていることに留意すべきである。コンピュータ・プラットフォーム１００２は、ランダム・アクセス・メモリ（ＲＡＭ）１００８および中央処理ユニット（ＣＰＵ）１００６などのハードウェア・コンポーネント１００３を含んでいる。なお、ＣＰＵ１００６はシングル・プロセッサを表すことができるが、好ましくは並列に動作するマルチプロセッサを表している。コンピュータ・プラットフォーム１００２は、ハードウェア・コンポーネント１００３に接続された周辺デバイスも含んでいる。これらの周辺デバイスとしては、１つまたは複数の入力デバイス（キーボード、マウス、ライトペンなど）１０１８、データ記憶デバイス１０２０（ハードディスクやフロッピディスクなど）、ディスプレイ１０２４、プリンタ１０２６、およびネットワーク・アダプタ１０２２などがある。コンピュータ・プラットフォーム１００２は他の周辺デバイスに接続することもできる。コンピュータ・プラットフォーム１００２は、オペレーティング・システム１０１４も含んでおり、マイクロ命令コード１０１０（ファームウェアとも呼ばれる）を含むことも可能である。オペレーティング・システム１０１４は、ディスク・オペレーティング・システム（ＤＯＳ）やＵＮＩＸオペレーティング・システムのように、実質的に全機能オペレーティング・システムを表すことができる。しかし、オペレーティング・システム１０１４は、他のタイプのオペレーティング・システムを表すことも可能である。好ましくは、オペレーティング・システム１０１４は、ＩＢＭ社開発のMachマイクロカーネルのような限定機能のオペレーティング・システムを表しているが、これはこの分野では周知である。十分な特色を有する(full featured)オペレーティング・システムは、コンピュータ・プラットフォーム１００２上でアプリケーション・プログラム１０３０として動作することが可能である。好適実施例では、コンピュータ・プラットフォーム１００２は、インターナショナル・ビジネス・マシンズ（ＩＢＭ）社のコンピュータまたはＩＢＭコンパチブル・コンピュータになっている。別の実施例では、コンピュータ・プラットフォーム１００２はアップル社のコンピュータになっている。１つまたは２つ以上のアプリケーション・プログラム１０３０はコンピュータ・プラットフォーム１００２上で並列に動作する。また、１つまたは２つ以上のデバイス・アンサンブル(device ensemble)１０３２はコンピュータ・プラットフォーム１００２上で動作する。デバイス・アンサンブル１０３２とは、好適実施例のオブジェクト指向入出力システムを総称的に表す。デバイス・アンサンブル１０３２は相互に作用し合って、入出力サービスをエンド・ユーザ（アプリケーション１０３０など）に提供する。デバイス・アンサンブル１０３２は、以下でより詳細に説明される。上述したように、アプリケーション１０３０はIBM OS/2などのオペレーティング・システムを表すことができる。これらのアプリケーション１０３０はデバイス・アンサンブルのクライアントであるので、好適実施例の入出力システムは複数のオペレーティング・システムをサポートしている。コンピュータ・プラットフォーム１００２のエレメントは図１０に別の表し方で示すことも可能である。例えば、デバイス・アンサンブル１０３２はオペレーティング・システム１０１４の一部であるように示すことができる（その場合は、デバイス・アンサンブル１０３２とオペレーティング・システム１０１４はコンピュータ・プラットフォーム１００２の同じ層に置かれることになる）。選択されたオブジェクト指向テクノロジ概念の概要オブジェクト指向テクノロジとコンピュータ・プログラミング技法は一般に周知であり、多くの公表された利用可能な文献で説明されている。そのような文献として、例えば、Grady Booch著「オブジェクト指向設計(Object-Oriented Desi gn）」(Benjamin Cummings 1991)およびDonald Firesmith著「オブジェクト指向の要求分析と論理設計(Object-Oriented Requirements Analysis and Logical D esign）」(Wiley 1993)がある。このセクションでは、オブジェクト指向テクノロジの選択された特徴のうち、本発明と係わりのある特徴について説明する。オブジェクトオブジェクト・プログラミングの２つの見方が、オブジェクト指向(object- oriented -ＯＯ）業界の主流になっている。セルフ・サポーティング・スタンド・アロン・オブジェクト(self-supporting stand-alone object)と協調ライトウェイト・オブジェクト(collaborative lightweight object)である。以下では、これらの見方について説明する。一方の見方であるオブジェクト・テクノロジは、「ヘビーウェイト」オブジェクトの思想に移行している。このオブジェクト設計は、できるかぎり多くを単一のスタンド・アロン・エンティティにカプセル化するのに役立っている。例を挙げると、データベース・オブジェクトがあり、これはディスク・ベースのリレーショナル・ファイリング・システムのすべての巧妙なもの(subtleties)を１つのオブジェクトにカプセル化している。このようなオブジェクトは、フィールド、タプル(tuple)、テーブル、リレーション、インデックス、そしておそらくは、照会の抽象が具体化され、実装されることになる。この方法は、粒度の大きいオブジェクトを作り出し、具体化される抽象の柔軟性を制限する。フィールド抽象をリファイン（改善）または適応することは、データベース・オブジェクトの内部構造の熟知を当然に要求される。これに対して、オブジェクトのライトウェイトな見方は、個々のオブジェクトのスコープ（有効範囲）を、他のオブジェクト（おそらく多数の）と協調して目標を達成するように設計された、機能的に、意味的に整合性のあるパズル・ピース(puzzle piece)に制限するのに役立っている。これらは柔軟度の高いオブジェクトであり、もっと大きなスケールで使用（および再使用）されている。オブジェクトのこの見方では、単純なデータベースはタプル・オブジェクトで関連づけられたフィールド・オブジェクトが協調する集合といってもよく、タプル・オブジェクトの方は、テーブル（表）オブジェクトによって含まれている。インデックス、リレーション、または照会は別々のエンティティとなり、フィールド、タプル、およびテーブルと近似的に協調することになる。これらの抽象の各々は整合性のあるインタフェースを提供でき、各々は新しい動作(behavior)を採用するために容易にサブクラス化することができる。以上を要約すれば、オブジェクトに対するこれらの２つの異なる手法を調べると、ソフトウェア・ライブラリと個々のサブルーチンとの間に類似性を引出すことができる。どちらの手法も、カプセル化と再使用の自立的な(self-contained) 単位を提供している。好適実施例では、ライトウェイトで、細粒度の協調オブジェクトを幅広く利用している。フレームワーク種々のサブシステムにとって必要な構造を提供するために、ライトウェイト・オブジェクトは設計フレームワークの枠組みに組み立てられ、そこではパブリック・インタフェースおよび相互関係が明確に定義されている。オブジェクトがコード再使用の単位であるときは、フレームワークは設計再使用の単位である。フレームワークは一般に周知である。フレームワークはクラス階層全体をスパンして、それと同時に包絡的アーキテチャ(enveloping architecture)を提供し、設計の系統的編成を表すことができる。フレームワークはサブフレームワークに分解することもでき、いくつかのフレームワークが大きなフレームワークにより包含されることも可能である。フレームワークが設計を具体化したものであれば、フレームワークをインプリメント（実装）するオブジェクトの集合を呼ぶための用語(term)がなければならない。例えば、Ｃ++では、クラスとオブジェクトは、クラスが仕様(specificati on)であり、オブジェクトがクラスのインスタンスであると言うことによりこれらの２つを別々に区別するものとよく言われている。好適実施例によれば、フレームワークの実装「インスタンス」はアンサンブル(ensemble)と呼ばれている。この「アンサンブル」という用語は、フレームワークを集合的に実装するクラスを意味している。例えば、従来「デバイス・ドライバ」と呼ばれていたプロダクトはデバイス・アンサンブルとなっている。フレームワークによると、アンサンブルの種々の部品間の協調と継承を通して共通性(commonalty)が管理されることができる。明確に定義されたクラス階層の使用を通して、共通性は追求され、それが設計全体の中で意味をもつ個所だけで徐々にあらわれる。各フレームワークは、すべてのフレームワークにわたって適用される「１サイズがすべてにフィットする(one-size-fits-all)」というパラダイムに拘束されることなく、適当な、望ましいインタフェースをそのクライアントに提供することができる。好適実施例の特徴と利点好適実施例のオブジェクト指向入出力システムの特徴と利点のいくつかは、上述した通りである。その他の特徴と利点は以下のセクションで説明する。開発能力の付与オブジェクトとフレームワークを幅広く使用することは、ハードウェア・デバイス・インタフェース・ソフトウェアの分野では新しいことであり、アンサンブル作成者(ensemble author)をいくつかの面で支援するのに役立っている。第一に、フレームワークは、秩序正しいスタートアップ（起動）、割込み通知の受信、デバイス・ハードウェアのサービス（保守）、および秩序正しいシャットダウン（遮断）といった設計上の問題を通して作成者のガイドとなる働きをする。第二に、類似の特性と目的をもつアンサンブル・オブジェクトを再使用すると、作成者は必然的に異なる動作(behaviors)だけに集中することができる。例えば、新しいディスク・コントローラ・カードのアンサンブルの作成者は、既存のアンサンブルから受け継ぐようにすると、実際のハードウェア・アクセスを行う関数だけをオーバライドできる場合がある。これとは対照的に、まったく新しいハードウェア部分のアンサンブルの作成者には、それから受け継ぐべきアンサンブルが標準規格品として豊富に提供されていない場合がある。そのような場合には、好適実施例によって定義された下位レベル入出力フレームワークの多くは、設計上およびアーキテクチャ上のガイドを作成者に提供することによりこの努力を支援する。ハードウェアおよびソフトウェア革新の奨励従来のハードウェアおよびソフトウェア革新は、相互の知識が熟知しすぎているという欠点がある。オペレーティング・システムとアプリケーション・ソフトウェアはその基礎となるハードウェア・プラットフォームを「知りすぎている」ために、これらはこの知識を活用して最大限の値を得ている。この情報を使用すると、ハードウェア・ベンダは、アプリケーションを分解しないと変更を行うことが非常に困難になるようなモードに拘束されることになる。さらに、この知識は、ソフトウェアが最小公分母(least common denominator)シンドロームから逃れることを困難にしている。オブジェクト抽象化を下位レベル・サブシステム全体に使用すると、このデッドロックを解決することができる。フレームワーク・インタフェースはハードウェア詳細をアプリケーションから見えないようにするだけでなく、アプリケーション詳細をハードウェアからも見えないようにする。システム全体のハードウェア依存部分とハードウェア独立部分との間のこの明確に定義されたインタフェースは、ハードウェアだけでなくオブジェクト・ベースのソフトウェアがその影響がシステム全体に波及することがなく変更できるので、ハードウェアとソフトウェアの両方の革新を奨励する。ロケーション独立のデバイス抽象化論理的ソフトウェア階層を実装し、共通の抽象化を提供し、共用ライブラリ・システムを利用することにより、入出力アーキテクチャは、ハードウェアが現われる物理的ロケーションとその数に関係なく、同じデバイス・アンサンブルを使用することを可能にしている。つまり、特定のUARTチップのアンサンブルはアンサンブル作成者が余計な作業を行わなくても、マザーボード・プレーナ(motherb oard planar)上のポートおよび、サードパーティ拡張カード上のポートにサービスすることが可能になっている。資源にユーザを見つけさせる既存システムの、もう１つの基本的問題は、含まれている構成データベースの見方である。現在のトップダウン資源ハンティングの見方では、インストールされているデバイスや見るための場所に関して明示的にシステムに知らせる必要がある。ある場合には、これらのデータベースは入力として使用され、ドライバを統計的にリンクしてカーネルに入れている。ある場合には、これらのデータベースは入力として使用され、ドライバを統計的にリンクしてカーネルに入れている。構成ファイルはシステムの各所に分散化され、新しいシステム・サービスがオンラインにされるように増加している。その結果はかなり統一されているが、新しいデバイスを追加するには、不明瞭で、整っていない、通常は整合性のないステップが大量に要求される。改良されたパラダイムでは、現行の見方を逆転して新しいデバイスを追加するようにしている。好適実施例によれば、この考え方は「資源にユーザを見つけさせる(let resorces find you)」と呼ばれている。この「資源にユーザを見つけさせる」パラダイムでは、SCSIアンサンブルはドライブを大容量記憶サブシステムに報告し、次にサブシステムの方はマウント可能な論理ドライブ（ボリュームまたは区画(partition)）をファイル・システムに報告することになる。この方法によると、ユーザは、どのボリュームをマウントするかをファイル・システムに指示するように一部のデータベースを構成する責任がなくなり、ファイル・システムは、ドライブとボリュームの起こり得る、すべてのハード・ドライブ・インタフェースを検証する負担を軽くすることになる。デバイスには、上例のように直接的で、直観的なクライアントが常にいるとは限らない場合がある。そのような場合には、デバイスは中央の「パーツ・ビン(p arts bin)」に非特定資源として登録されることになる。例えば、RS232Cポートは自身をパーツ・ビンに登録することができ、そのあとでなんらかのユーザ・アクションでビンから抜き出して、モデムまたはプリンタ・ポートを構成するために使用することができる。この場合、使用可能であって、未割当てのデバイスだけがパーツ・ビンへの道をみつけるので、提示されたオプションが有効であることがユーザに保証されることになる。「プラグ・アンド・プレイ」ユーザ・モデル「資源にユーザを見つけさせる」の頂点にあるのが、「プラグ・アンド・プレイ(Plug & Play)」ユーザ・モデルである。「プラグ・アンド・プレイ」オペレーションは、入出力ハードウェアを追加または除去するために構成ファイルを扱わなくても済むようにユーザを解放する。動的インストールと構成ハードウェアとソフトウェアの動的構成は、好適実施例の「プラグ・アンド・プレイ」モデルをサポートするためには必須のフィーチャ（機能または特徴）である。この目標を達成するために、デバイス・ソフトウェアの構成には、デバイス特定のソフトウェア（インタフェース・アンサンブル）の動的インストールが必要である。例えば、「ホスト・プラギング(host-plugging)」が可能なＳＣＳＩインタフェースでは、デバイスがバスに追加されたり、バスから除去されたとき、そのインタフェースから提供されるデバイスとサービスを再構成する必要が起こる。この機能は、割込み処理カーネル・コードを控えめにアンインジェクション(u n-injection)または除去することを含めて、アンサンブルの個々のインスタンスを随意に作成し、破壊できるようにする、もっと動的なシナリオに拡張することができる。非集中化ポリシを有する柔軟性のある抽象化柔軟性のある抽象化を入出力アーキテクチャ全体にわたって使用すると、ベース・アーキテクチャに縛られることなく、多くの設計上の決定をフレームワーク開発者に委ねることが可能になる。このようにすると、設計者が選択できるオプションが増加するので、設計者は問題領域に対して最良のトレードオフのセットを得ることができる。このトレードオフのセットは、パフォーマンス、セキュリティ、デバイス・アロケーション、およびデバイス・アクセスのポリシ問題にスパンすることができる。このようにすると得られる柔軟性の例として、各デバイス抽象化は、デバイスを共用にできるか、一度に１つのクライアントに制限できるかを定義することになる。このデバイス・アロケーション・ポリシ決定を非集中化すると、特定デバイスのスコープ（有効範囲）を越えて影響を及ぼすことなく、かかるポリシをのちに変更することが可能になる。クライアント／デバイス・アクセス・ポリシを定義することのほかに、デバイス抽象化は、入出力アドレス空間や割込みソース(interrupt source - ＩＲＱ) などの必要資源をアロケートしなければならない。これらの下位レベル資源は、各入出力フレームワークごとに割込みサービス・フレームワークによって管理される。これらの資源の調整は、衝突が起こらなければ、個々の入出力フレームワークに対しては見えないようになっている。非集中化ポリシの効果は、デバイス抽象化が取り扱う必要のある依存関係の数を減少し、個々のフレームワーク設計者が正しいポリシを適当なレベルに設定する機会を増加することである。非集中化ポリシの価値は、初期実装の基準(refer ence)のフレームから逸脱する新しいハードウェア・システムを受け入れるようにソフトウェアを移植するときに明らかになる。システム信頼性の向上今日の共通デスクトップ・オペレーティング・システム・テクノロジによって達成されるシステム信頼性の現行レベルは、新しいシステムには受け入れられない。保護アドレス空間やユーザ・モード・ドライバのような特徴をもつこの分野では、進歩していることは明らかである。このような進歩があっても、入出力アーキテクチャはシステム安定性の目的に重要な貢献をしていない。好適実施例では、この欠点に取り組んでいる。割込みハンドラ内のプロセッサ例外からの回復大部分のシステムは、システムが割込みコードの実行中に発生した割込みに対して非常に厳格になっている。その結果起こるシステム・クラッシュはほとんどシステム信頼性のモデルになっていないので、一見、不可解であることがよくある。これを改善するために、好適実施例の入出力アーキテクチャは、割込みドメインに対してデフォルトとカスタムの両方の例外ハンドラをサポートしている。エラー・ロギング入出力エラー・ロギング(error logging)は問題を追跡し、重要でないエラーが発生したとき診断フィードバックを得る有効な手段である。好適実施例では、このロギングに対して柔軟性のあるサービスをサポートしている。資源の自動再利用好適実施例は、資源を正しく再利用(reclamation)することを達成している。具体的には、好適実施例は異常終了を検出し、そのあとでクリーンアップ(clean up)する。異種ハードウェアのサポート好適実施例は、デバイス、プロセッサおよびバスを広範囲にわたってサポートしている。積極的にサポートされるデバイスは、単純な非割込み駆動型デバイス（例えば、アップルSWIMフロッピ・コントローラ・チップ）からDMAまたはチャネル・ベースのディスク・コントローラまでの範囲にわたっている。入出力バスの全範囲はサポートされ、この場合も、単純な（ＩＳＡ）から高度の（マイクロチャネルまたはNuBus）までの範囲にわたっている。この入出力アーキテクチャはプロセッサ独立であり、マルチプロセシングを含む、すべての公知プロセッサ構成をサポートしている。オブジェクト指向入出力システムの構造入出力サービス・フレームワークエンド・ユーザがある機器部分を注文するとき、ハードウェアを入手するだけということはめったにない。むしろ、ユーザはあるレベルのサービスを得ようとする。例えば、モデム・メーカはあるレベルの通信サービスを達成する手段を提供している。モデムを販売することは、実際の取引の１部分にすぎない。従って、デバイスをアクセス可能にするだけでは、最早不十分である。焦点を必要とされるサービスに移さなければならない。この目的を達成するために、好適実施例の入出力システムはサービス指向になっている。システムはディスク・ドライバを提供するのではなく、大容量記憶サービス(Mass Storage Services) を提供する。従来のディスク・ドライバの概念は、ソフトウェアがドライブをアクセスする手段にすぎない。大容量記憶サービスは、ファイル・システムに使用可能な区画(partition)を提供し、ドライブ区画化とフォーマッティングを行う技術的およびユーザ・インタフェース・タスクを準備するといった、追加の責任を含んでいる。ここで認識すべき重要なことは、好適実施例は、提供されるサービスのレベルを上げることによって従来のデバイス・インタフェースの役割を拡張していることである。好適実施例の入出力システムによって提供される入出力サービスのいくつかを挙げると、(a)大容量記憶入出力サービス、(b)キーボード処理サービス、(c)マウス／ポインティング・デバイス処理サービス、(d)ＳＣＳＩサービス、(e)シリアル通信ポートサービス、(f)拡張バス管理サービス、(g)デスクトップ・バス入出力サービス、および(h)電源管理サービスがある。好適実施例によれば、入出力サービス・フレームワークは、エンド・ユーザ（人間のオペレータ、オペレーティング・システムの機能、アプリケーション・プログラムなど）が上記およびその他のサービスを実行できるようにするために用意されたものである。具体的には、エンド・ユーザはこれらの入出力サービス・フレームワークと相互作用して、サポートされる入出力オペレーションを実行することができる。主要な入出力サービス・フレームワーク１０２は、フレームワークから提供される特定のサービスとフレームワークがアクセスするデバイスの一部と共に図１に示されている（サービスとデバイスは楕円で示されている）。これらの入出力サービス・フレームワーク１０２には、(1)マウス・ポート、デスクトップ・バスおよびシリアル・マウスに関係するサービスを提供するマウス／ポインティング・デバイス・フレームワーク１０２Ａ、(2)アクセス・バスに関係するサービスを提供するデスクトップ・バス・フレームワーク１０２Ｂ、(3)シリアル・ポートを経由するデータの同期および非同期転送に関係するサービスを提供するシリアル・ポート・フレームワーク１０２Ｃ、(4)電源検知およびスクリーン管理に関係するサービスを提供する電源管理フレームワーク１０２Ｄ、(5)パラレル・タイプ・デバイス（プリンタ、ポータブル・ディスク、ネットワーク・インタフェースなど）との相互作用に関係するサービスを提供するパラレル・ポート・フレームワーク１０２Ｅ、(6)拡張バスとの相互作用に関係するサービスを提供する拡張バス管理フレームワーク１０２Ｆ、(7)大容量記憶デバイスに関係するサービスを提供する大容量記憶デバイス・フレームワーク、(8)キーボード入力デバイスに関係するサービスを提供するキーボード・フレームワーク１０２Ｈ、 (9)ＳＣＳＩバスとそのバスに接続されたデバイスに関係するサービスを提供するＳＣＳＩバス・フレームワーク１０２Ｉがある。これらのサービスの一部が他のサービスのクライアントとなって所期の目標を達成することが起こり得る（場合によっては、そうする必要がある）。例えば、ある構成では、大容量記憶フレームワーク１０２Ｇは、ＳＣＳＩフレームワーク１０２Ｉのクライアントになっている。ＳＣＳＩフレームワーク１０２Ｉの方は、拡張バス・フレームワーク１０２Ｆのクライアントになることが可能である。ポインティング・デバイス・フレームワーク１０２Ａは、シリアル・ポート・マウスを使用するためには、シリアル・ポート・サービス・フレームワーク１０２Ｃのクライアントになる必要がある。入出力フレームワーク１０２はデバイス・インタフェーシングと関係がない、他の多数のオペレーティング・システム・サービスのクライアントにもなっている。基礎となる入出力フレームワーク上述した入出力サービス・フレームワーク１０２は、好適実施例の入出力システムとエンド・ユーザとの間のインタフェースを表わしている。入出力サービス・フレームワーク１０２は、以下に示す下位レベル・フレームワークと一緒に動作してそれぞれのタスクを実行する。割込みサービス・フレームワーク２０６と、割込みハンドラ・フレームワーク２０８と、アクセス・マネージャ・フレームワーク２１０である。これらのフレームワークは、入出力システムの基本的ビルディング・ブロックを表わしている。図２は、これらのフレームワークがどのように通信し、相互作用して複数のサービスを提供するかを示している（上述したように、これらのフレームワークのインスタンシエーションはアンサンブルと呼ばれ、図１０にエレメント１０３２で示されている）。図２は、好適実施例の入出力システムの全体構造を基本的に示す図である。入出力サービス・フレームワーク１０２では、各フレームワークはプラットフォーム相互間で整合性のあるインタフェースを、そのクライアント２１４に提示する。従って、特定のフレームワーク、例えば、大容量記憶フレームワークの場合のインタフェースはPowerPCを実装したものと同じであり、これはインテルPen tiumまたはモトローラMC68040を以前実装したものと同じである。割込みサービス・フレームワーク２０６は、複数の割込みハンドラ２０８を管理するためのカーネル・ベースのサービスを提供して、第１レベル割込みデコードと適当な割込みハンドラ２０８へのディスパッチを実行する。このフレームワークは多数の管理タスクにも責任がある。割込みハンドラ２０８（割込みハンドラ・フレームワーク２０８のインスタンシエーションを表わしている割込みハンドラ）は、デバイス割込みを処理するデバイス特定の抽象化である。これはオプションのビルディング・ブロックであり、これが必要になるのは、管理されるデバイスが割込みを引き起こしたときだけである。割込みハンドラはカーネル・モードで実行されるので、カーネル特権命令とオペレーションをアクセスすることができる。デバイス・アクセス・マネージャ２１０（アクセス・マネージャ・フレームワーク２１０のインスタンシエーション）はユーザ・モードの抽象化であり、カーネルの外で実行され、ハードウェア・アクセスと関連があるすべてのタスクを担当している。図２に示すハードウェア・デバイス２１２は、好適実施例の入出力システムによって管理されているハードウェア・デバイスを表している。アクセス・マネージャ２１０と割込みハンドラ２０８はハードウェア・デバイス２１２と通信していることに留意してほしい。割込みデバイス２０６はカーネル２０４と通信しているが、これは、好ましくは、ＩＢＭ社開発のMachマイクロカーネルになっており、これはこの分野では公知である。オブジェクト指向入出力システムのオペレーション好適実施例の入出力システムは好ましくは次のように動作する。クライアント２１４はサービス要求を、そのクライアントに関連する特定の入出力サービス・フレームワーク１０２へ送信する。入出力サービス・フレームワーク１０２はその関連アクセス・マネージャ２１０を使用して、「バイト書込み」、「ブロックをバッファとする」または適当なアクションとなるもの、などの適当なコマンドを適当なデバイス・レジスタにロードする。割込みは図２において下から上へ向かって進んでいく。カーネル・ベースの割込みサービス・フレームワーク２０６はプロセッサ割込みをとらえて、特定の割込みレベルまたはＩＲＱ用に登録しておいた割込みハンドラ２０８をコールする。割込みハンドラ２０８はハードウェアを照会し、適当なメッセージをその関連デバイス・アクセス・マネージャ２１０へ送信する。デバイス・アクセス・マネージャ２１０はバッファ読取りといった、ハードウェア・インタフェース・オペレーションを実行し、メソッド・コールかＩＰＣ（プロセス間通信）のどちらか適当なものを通して、適当な入出力サービス・フレームワーク１０２に通知する。最後に、入出力サービス・フレームワーク１０２は、データを送ることによってクライアント・スレッドをアンブロッキングするといった、適当なアクションをとる。どのデバイス・アクセス・マネージャ２１０も、およびその関連する割込みハンドラ２０８も、図３に示すように、従来のデバイス・ドライバに見られる関数を実行することが可能である。デバイス・アクセス・マネージャ２１０と割込みハンドラ２０８は、どちらも、それぞれのハードウェア・デバイス２１２へ直接アクセスすることができる。そのために開発者は、実装別の、設計目標全体を達成するように、デバイス・アクセス・マネージャ２１０と割込みハンドラ２０８との間で機能をバランスよく調和することができる。ある程度進んだ入出力ハードウェアでは、機能性（およびコード量）は主としてデバイス・アクセス・マネージャ２０８に持たせ、割込みハンドラ２０８のサイズと複雑性は、最小限にすることが可能である。フィーチャまたは関数をどこに置くかは、設計者に任されている。フィーチャをどの程度までデバイス・アクセス・マネージャ２１０または割込みハンドラ２０８に常駐させておくかは、設計者の要求条件と次の条件に従って決めるべきである。コードを割込みハンドラ２０８に実装する目的が圧倒的に明確化されていなければ、コードはデバイス・アクセス・マネージャ２１０に置いておくべきである。このルールは、割込みハンドラ２０８をできる限り小さくし、単純化して（実用上の考慮から）パフォーマンスを向上させるという意図に基づいている。割込みハンドラ２０８は、それぞれのデバイス・アクセス・マネージャ２１０の要求でインストールされ、削除される。通常、デバイス・アクセス・マネージャ２１０と割込みハンドラ２０８は１対１に対応づけられている。すなわち、各デバイス・アクセス・マネージャ２１０は、割込みハンドラ２０８を１つだけインストールするのが通常である。この１対１対応の例外も認められ、許容される。そのような例外のいくつかを示すと、次の通りである。(1)割込みを発生しないポーリングされたデバイスに対するデバイス・アクセス・マネージャは、どの割込みハンドラもインストールしないで済む。(2)ある種のハードウェアは、多数の別個の割込みを発生する能力がある同種デバイスの複数のインスタンスをもつことができる（例えば、複数のＵＡＲＴをもつＩＳＡシリアル・ポート・カード）。この場合には、設計者は共通のデバイス・アクセス・マネージャを使用することを選ぶことができるが、その場合は、複数の割込みハンドラがインストールされることになる。図３に戻って説明すると、デバイス・アクセス・マネージャと割込みハンドラは、２つの標準インタフェースを使用して通信する。第一に、デバイス・アクセル・マネージャは、コントロール・メカニズムを使用して双方向通信トランザクションを開始することができる。第二に、割込みハンドラは、割込み通知サービスを通して一定量のデータを任意のタスクへ送信することができる。このインタフェースの目的は、一定のステート情報をデバイス・アクセス・マネージャに通信する割込み通知を可能にすることである。どの標準および適当な通信インタフェースを使用しても、コントロール・メカニズムと割込み通知サービスを実装することが可能である。以下、好適実施例のオペレーションについて詳しく説明する。入出力サービス・フレームワーク１０２はそのデバイス・アクセス・マネージャ２１０と相互作用する。デバイス・アクセス・マネージャ２１０は、仮想アドレス範囲を入出力の準備状態にするようにメモリ管理サービスに要求することにより、バッファを準備状態にする。次に、デバイス・アクセス・マネージャ２１０はハードウェア・デバイス２１２と直接に相互作用するか、あるいはコントロール・メソッドを通してデバイス割込みハンドラ２０８と相互作用する。ハードウェア・デバイス２１２は要求データを受け取るか、あるいは供給する。ある時点で、ハードウェア・デバイス２１２が割込みを発生すると、これは割込みサービス・フレームワーク２０６によって受信され、正しい割込みハンドラ２０８へディスパッチされる。割込みハンドラ２０８はハードウェア・デバイス２１２をアクセスし、ハードウェア・デバイス２１２のステート（状態）を調べることができる。そのあと、割込み通知サービスを通してデバイス・アクセス・マネージャ２１０に通知し、可能ならば、その通知と一緒に必要なステート情報を送信する。次に、デバイス・アクセス・マネージャ２０８はクライアントの常駐入出力バッファをアンロック（ロック解除）する。最後に、デバイス・アクセス・マネージャ２０８は要求されたアクションが完了したことを、入出力サービス・フレームワーク１０２の１つを通してクライアント２１４に通知する。デバイス・アクセス・マネージャ従来のドライバではなく、なぜデバイス・アクセス・マネージャ２０８であるのか？その答えは、好適実施例の入出力アンサンブルに要求される、拡張された役割にある。デバイスは各タイプごとに、アクセス・ルールとプロトコルに差異がある。この多様性を「１サイズがすべてにフィットする」インタフェース抽象化に圧縮することは、現行のＯＳアーキテクチャ間で共通に行われている。革新を可能にする目標を受け入れるには、これらのアクセス・プロトコルの任意の与えられたセットが多様化していることを認識しなければならない。従って、デバイスの各カテゴリは、独自の抽象インタフェースを定義できるようになっていなければならない。例えば、プリンタとタップ・ドライブは複数のクライアント間で共用される可能性はほとんどない。しかし、異なるプロセス・ポリシを使用すると、プリンタ・ポートは、スプーリング・キュー（待ち行列）を管理することにより共用されるという錯覚を与えるおそれがある。従って、デバイス・アクセス・マネージャ２１０は、そのアクセス・ポリシをカプセル化し、隠蔽して、その制御を行うことができる。デバイス・アクセス・ポリシは、現在と将来のすべてのデバイスについてグローバルに、明確に、あるいは正確に予測することはできない。これを行おうとすると、新しいハードウェア革新に適合できない、圧縮された入出力モデルをもたらすことになる。好適実施例は、グローバル入出力アクセス・ポリシをセットしない。現在適用されているグローバル・デバイス・アクセス・ポリシが、将来正しくなくなるか、不適切になる可能性がある。好適実施例の入出力システムは、多くのポリシ決定を可能な限りデバイス・アクセス・マネージャ２１０に委ねることによってこの問題に取り組んでいる。従って、デバイスのアクセス・ポリシを定義することは、デバイス・アクセス・マネージャ２１０の機能上の役割になっている。ユーザ・モード・アクセス・マネージャ２１０に対する、もう１つの理由は、デバイス・サービス機能をカーネル・スペースの外に置くことができるようにすることである。このようにすると、カーネルの増長(bloat)が低減し、システム安定性が向上するという利点が得られる。割込みハンドラ割込みハンドラ２０８は割込みソース（発生源）特定の抽象化であり、割込みを処理し、カーネルのアドレス空間で実行される。割込みハンドラ２０８がデバイス特定であるのは、そのコードがターゲット・デバイス２１２の詳細知識をもっているからである。しかし、割込みハンドラ２０８は、異なる物理ロケーションに置かれたデバイスの複数のインスタンスを処理する機能をもつという意味で、汎用的でもある。（つまり、割込みハンドラはＵＡＲＴとＳＣＳＩインタフェース・チップの両方に対しては、割込み通知を処理する(field)ことはできないが、複数のＵＡＲＴチップに対しては割込みを処理することができる。）すべての割込みハンドラは抽象基底クラス(abstract base class)TInterrupt Ha ndlerからサブクラス化される。TInterrupt Handlerクラスは、デバイス特定の割込みハンドラとカーネルの割込みサービス・フレームワークとの間の必要とされるインタフェースを定義している。デバイス特定サブクラスのオブジェクトは、割込みハンドラによって使用される他のオブジェクトと共に、処理されて共用ライブラリに入れられる。割込みハンドラ２０８がデバイス・アクセス・マネージャ２１０によってインストールされると、「デス・ウォッチ(death watch)」が開始されるので、デバイス・アクセス・マネージャ２１０が壊されると割込みハンドラ２０８が自動的に削除されるようになっている。このようすると、システムは、割込みハンドラ２０８によって使用された資源が、デバイス・アクセス・マネージャ２１０が削除されたとき再利用されることを保証することができる。このデス・ウォッチは、割込みサービス・フレームワーク２０６によって目立たないように管理される。割込みサービス・フレームワーク割込みサービス・フレームワーク２０６は、割込みハンドラ２０８によって使用されるカーネル・レベル・サービスをカプセル化すると共に、割込みデコーティングを提供し、適当な割込みハンドラ２０８へディスパッチする。割込みサービス・フレームワーク２０６から提供されるサービスには、次のものがある。 (1) 割込みハンドラのインストール。カーネル常駐割込みハンドラはすべてこのフレームワークによってインストールされる。 (2) 入出力資源の管理。このタスクは、割当て済みで、要求された入出力アドレス範囲と割込みスペースを追跡して、衝突が調停されることを含む。これらの資源の調停は、最初に到着したものが最初にサービスを受ける(first-come，fir st-served)という性格のものであるが、ハードウェア・アーキテクチャと割込みサービス・フレームワーク２０６の特定の実装に依存して、このモデルと異なることもあり得る。 (3) 割込みハンドラ例外の管理。割込み時に起こるプロセッサ例外を最終的に処理するのは、割込みサービス・フレームワーク２０６の仕事である。この責任には例外をロギングし、例外ハンドラを呼び出すことが含まれる。オフェンディング(offending)割込みハンドラ２０８がカスタム例外ハンドラを指定していれば、それが呼び出される。そうでなければ、システムのデフォルト例外ハンドラが使用される。 (4) デバイス・アクセス・マネージャのデス・ウォッチ。アクセス・マネージャ２１０が壊されたかどうかをウォッチし、まだインストールされている関連の割込みハンドラ２０８を削除するのは、このフレームワークである。 (5) 割込みハンドラの削除。割込みハンドラ２０８を削除する要求が受信されたとき、要求側が適当な権利をもっていることを前提として、その作業を行うのはこのフレームワークの責任である。通常、割込みハンドラ２０８をインストールしたデバイス・アクセス・マネージャ２１０だけが、そのハンドラを削除する権利をもっている。さらに、割込みサービス・フレームワークは割込み階層を構築し、それをサポートしていなければならない。割込み階層は、ロケーション独立のデバイス抽象化のサポートに不可欠な革新であるので、以下で説明する。ハードウェア階層と構成入出力ハードウェア・デバイスは多種類のハードウェア・パスを経由してシステムに接続することができる。一部のデバイスはマザーボード上に組み込まれており、一部のデバイスはバス（例えば、マイクロチャネル、ＮｕＢｕｓ、ＳＣＳＩ、ＩＳ）に接続されており、他のデバイスはいくつかの手段の組合わせを使用して接続されている。例えば、ＳＣＳＩドライブは、ＳＣＳＩチップがそこに置かれているＮｕＢｕｓカードに接続することが可能である。単純化した抽象化では、異種のハードウェア構成はハードウェア階層の集まりとして見えるようになっている。図４は、そのようなハードウェア階層の例を示したものである。図４の階層を要約して示すと、次のようになる。マザーボード・ハードウェア拡張バス・カード単純デバイスＡ単純デバイスＢこのハードウェア階層をソフトウェア・ドメインに投影することによって、好適実施例はかなりの程度の柔軟性を達成し、専門化されたデバイス知識を適当なレベルでカプセル化している。これについては下述する。ソフトウェア階層ハードウェアを階層と見る見方は、これらのデバイスのソフトウェアも階層であるとの見方に通じる。ソフトウェアを階層と見る見方は、知識の範囲を階層の適当な層に限定することになる。この知識の範囲を制限することにより、入出力ポリシ問題を階層の最下位レベルに押し付けることが可能である。割込みが発生すると、正しい割込みハンドラ２０８がこの割込みを処理するまで、コントロール（制御権）は階層を下って行くことになる。これを示したのが図５である。このソフトウェア階層は割込み処理に限定されず、自動システム構成という関心事にもスパンしている。ハードウェア階層の「ルート(root)」が見つかると、ソフトウェア階層のルート(root - 根)が生成される。このソフトウェア・ルートのタスクは、新しいハードウェア・ノードを見つけると、ソフトウェア階層の各ノードを見つけて、インスタンシエイトすることである。好適実施例のこの側面の詳しい説明は、構成アクセス・マネージャに関するセクションで下述されている。親子関係好適実施例の入出力アーキテクチャを階層として見る見方では、単純な親子関係を使用してソフトウェア階層のすべてのノードを管理している。各割込みハンドラ２０８とデバイス・アクセス・マネージャ２１０は親関係をもち、子関係はもつ場合と、もたない場合とがある。これらの親子関係はこのような階層抽象化を管理するためのモデルを形成する。これらの関連づけのすべてのセットは、ソフトウェア階層のトポロジを自然に、かつ動的に定義している。この定義は２つの重要な目標を達成している。(a)これは、ソフトウェア階層がどのように（どの順序で）構築されているかを定義している。(b)これは、割込み発生時のコントロールの流れを記述している。階層内のノードを定義することは、大部分の入出力ハードウェアでは単純なタスクである。しかし、少数の場合には、親子関係を区別するジョブは明確になっていない。例として、Zilog Z8530 SCCチップがある。このチップは２種類の別個のシリアル・ポート（ＡとＢ）と共通の割込みレジスタをもっている。明らかな初期設計は、２つのシリアル・ポートを定義し、各々が割込みハンドラを持つことである。しかし、ポートＡの割込みハンドラが割込みレジスタを読み取ると、これは両ポートの割込みステータス（状況）を取得し、このアクションによってレジスタをクリアしている。独立の割込みハンドラの概念はこのケースでは有効でないことは明らかである。解決方法は、抽象化をチップとポートの２レベルで定義することである。これは図６に示されている。そこでは、チップ抽象化は親であり、２つのソフトウェア独立のシリアル・ポートをエクスポートしている。あるクライアント・アプリケーション（例えば、ＭＩＤＩ）がその割当てポートを使用する必要が起こった場合には、まず、正しい親の割込みハンドラ・オブジェクト（チップ割込みハンドラ）を獲得し、ＭＩＤＩ割込みハンドラをその親の子としてインストールするように要求する。親子関係がどのように使用されて、ソフトウェア階層が構築されるかは上述した通りである。次に、割込みの場合におけるコントロールの流れについて説明する。上例（図６）において、ＳＣＣポートＢが割込みを主張したとする。マザーボードは、割込み信号をプロセッサへルート(route)し、プログラム・カウンタはベクトル化されて割込みサービス・フレームワークに入力される。割込みサービス・フレームワークはプロセッサ割込みをデコード（解読）し、ＳＣＣ割込みハンドラをディスパッチする。ＳＣＣ割込みハンドラは割込みレジスタを読み取り（この結果、割込みステータス・ビットがクリアされる）、そこで見つけた値をデコードし、ポートＢが割込みを発生したことを決定する。次に、割込みサービス・フレームワークのサービスInvokeChildをコールしてポートＢ割込みハンドラをディスパッチし、割込みレジスタのコピーを「親オブジェクト」に引き渡す。注意すべき重要なことは、ＳＣＣ割込みハンドラは、ポートＢでどのハンドラが現在アクティブな子であるかを知らなくてもよいことである。子が割込みを処理すべきことを知っているだけで充分である。割込みレジスタがポートＡの割込みも示していたときは、ＳＣＣ割込みハンドラは、ポートＢの割込みサービスが完了すると、同じようにポートＡ割込みハンドラをディスパッチすることになる。このようにして、個別ポート割込みハンドラは共用割込みレジスタの破壊読取りをしないで済むことになる。構成アクセス・マネージャ構成アクセス・マネージャはデバイスのコレクションを構成することを付加的に担当するデバイス・アクセス・マネージャ２１０であり、これらは好適実施例のプラグ・アンド・プレイ目的の中心的エレメントとなっている。構成アクセス・マネージャには２種類ある。最初のものは構成するための一定セットのデバイスを有するので、単刀直入な構成タスクを持っている。二番目のものは任意数の「タイプのない」デバイスを構成しなければならない。構成アクセス・マネージャの二番目の形は、なんらかのプロトコルを利用して、その構成タスクを完了する前に存在するデバイスの数とタイプを決定する。いずれかの構成アクセス・マネージャが始動されたとき、それが担当するすべてのデバイスを見つける必要がある。すべてのデバイスが見つかり、識別されると、構成アクセス・マネージャはポリシ決定を行う。つまり、適当なデバイス・アクセス・マネージャ２１０をインスタンシエイトするか、あるいはデバイスが見つかったが、デバイス・アクセス・マネージャ２１０とリンクされていないことを記録するだけである。次に、図７について説明する。そこでは、ＳＣＳＩバス構成アクセス・マネージャは標準ＳＣＳＩプロトコルに従って、どのデバイスが現在ＳＣＳＩバス７０４に接続されているかを識別する必要がある。デバイスが見つかると、構成アクセス・マネージャは、どのデバイス特定デバイス・アクセス・マネージャをインスタンシエイトすべきかを決定する。構成するための一定セットのデバイスの例は、いくつかのデバイスを有する拡張カード上に見出される。このタイプの構成アクセス・マネージャでは、ポリシ決定はハード・コード(hard-coded)になっている。２つのＳＣＳＩコントローラを含む拡張カードでは、ＳＣＳＩチップはカードの構成アクセス・マネージャに知らされる。これらのＳＣＳＩバスの各々のデバイスは、ＳＣＳＩバス構成アクセス・マネージャによって構成する必要がある。この例が示すように、構成アクセス・マネージャのモデルはリカーシブ（再帰的）に適用することができる。ソフトウェア階層を使用して任意のハードウェア階層を管理するようにすると、入出力システムは任意のハードウェア・プラットフォームまたは構成を動的に構成することができる。データ転送とデバイス・アクセス・マネージャデータはプロセッサ（プログラム入出力）またはハードウェア（ダイレクト・メモリ・アクセス、ＤＭＡ）によってハードウェア・デバイスとの間で転送することができる。チャネル処理、つまり、専用入出力プロセッサをＤＭＡと一緒に使用することは、これらの転送オプションの組合せを表している。プログラム入出力(programmed IO)が好適実施例によってサポートされることは、デバイス・アクセス・マネージャの上例を見れば明らかである。ＤＭＡ関連サービス群が、デバイス・インタフェース・アンサンブルに使用可能である。これらのサービスとしては、次のものがある。(a)ＤＭＡチャネルのクライアントへの動的割当て、(b)分散読取り(scatterd-read)、集合書出し(gat hered-write)（分散−集合(scatter-gather)とも呼ばれる）のサポート、(c)ハードウェア制限のカプセル化（ＩＳＡバス・ハードウェアの２４ビット・アドレシング制限など）。ＤＭＡサービスを使用すると、物理メモリの好ましくは下位１６Ｍｂに中間バッファを用意することにより、ＤＭＡデバイスがシステム上に許されることになる。この機能はデータ転送を低速にするので、オプションになっている。(d)ＤＭＡサービス・クラスはサードパーティ・バス・マスタをサポートするようにサブクラス化することが可能である。これらのＤＭＡサービスは、ＩＳＡシステムで見られるものよりも、ハードウェア・サポートを向上することを目標としている。ハードウェア・ベースの進歩と共に、ＤＭＡモデルは、ＩＳＡバスの遺物をサポートするために必要であった、ある種の機能を削除することが可能である。ＭＣＡ、ＥＩＳＡおよび他のワイド・バス・アーキテクチャでは、そのような機能は必要ではなくなるべきである。アーキテクチャの例上述したように、好適実施例によれば、オブジェクト・テクノロジの再使用と抽象化の使用によって入出力ソフトウェアを進歩させることができる。このセクションでは、好適実施例のこれらの利点を示す例について説明する。サード・パーティ開発者が単純な付加価値カードを製造して、市場で販売することを決定したとする。マーケット・リサーチの結果、ＳＣＳＩバスといくつかのシリアル・ポートを有する拡張カードの需要があることが明らかになった（図８参照）。開発者は、ターゲットＯＥＭが使用しているものと同じ入出力チップを使用することを選択した。ハードウェア・カードを製造することは単純であるが、このサード・パーティ開発者はどれだけのソフトウェアを書く必要があるか？好適実施例によれば、開発者が書く必要のあるソフトウェア量は非常に少なくなる。その理由は、カードを制御するソフトウェアの大部分は既存のアンサンブルから得られるからである。ハードウェア・レベルとソフトウェア・レベルの両方をてこにしたので、サード・パーティ開発者は、ソフトウェア・ソリューションのわずかな部分を開発するだけで済んだ。図９に示すように、開発者が貢献したのは、サード・パーティ・カードの割込みハンドラとカード特定の構成アクセス・マネージャである（図９には示していない）。アンサンブルの残り部分は他から提供されたものである。複数プロセッサのサポート好適実施例の入出力システムは、好ましくは、基礎となるカーネルのマルチプロセッシング（ＭＰ）機能を追跡する。ＭＰサポートは、好ましくは、公知のユニフォーム・メモリ・アクセス（Uniform Memory Access - ＵＭＡ）モデルを利用する対称マルチプロセッシング(Symmetric Multi-Processing - ＳＭＰ)に集中している。どのＭＰ構成に対するデバイス・アンサンブルをサポートする能力は、サポートされる適当なカーネルと実装特定の同期プリミティブに依存する。割込みハンドラ（カーネル内(in-kernel)同期）の場合は、TInterruptMutex同期メカニズムが必要である。デバイス・アクセス・マネージャと他のユーザ・モード抽象化の場合は、システムの標準ユーザ・モード同期サービス・セット（モニタ、セマフォアなど）があれば、充分である。ＯＯブーティング・フレームワークシステムをブートする根本のオペレーションは、システム・ソフトウェアを立ち上げて、実行状態にするプリミティブ手段(vehicle)を提供することである。このオペレーションをサポートするために、ブーティング・フレームワークはブーティングを準備し、制御する機能を用意している。ブーティング・フレームワークは３つの論理部分に分かれている。1)直接クライアント・インタフェース定義、2)フレームワーク定義、および3)サービス定義（内部ステップと実装）である。ブーティング・フレームワークの目標と要求のいくつかを示すと、次のとおりである。・システム・ソフトウェアを立ち上げて、実行状態にするプリミティブ手段を提供する。・システムの相互依存性の一部を管理し、隠蔽する。・ブート時実行可能(boot time executable)の制約を最小限にする。・サード・パーティ・アクセスと共に単純性と拡張性を提供する。・すべてのＰｉｎｋプロセッサと入出力プラットフォームのポータブル・ソリューション。・ハードウェアとシステム・ソフトウェアのマーケッティング時間を短縮化する。・複数のブート・データ・ソースからのブーティングをサポートする。・ユーザ・エラーとハードウェア・エラー発生に対し強くする。ブーティング・フレームワークはベース・システム関数群を用意していなければならない。ポライト(polite)で、見立たない(unobtrusive)とは、ブーティング・フレームワークは、それがアクチベートするソフトウェアに余計な負担をかけてはならないことを意味する。オープンで拡張可能なブーティング・モデルを使用すると、それをガイドとしてブート設計の多くを行うことができる。このモデルは単一のバウンド・ファイル(bound file)ではなく、ファイルの集まりをブート可能単位として使用する。ブート・イメージ・メンバをファイルで解決することは、オープン・モデルをサポートする重要な設計方針である。ブーティング時にアクティブになるオブジェクト群は、個別ファイルのコンテキストで存在するので、ファイルは単純で直観的方法で追加し、削除することができる。この結果、システム・ソフトウェアの更新機能と拡張機能が強化されることになる。オブジェクト指向フレームワークとコード再使用をローレベルＰｉｎｋオペレーティング・システムで使用すると、システム初期化時にオブジェクトを使用できるようにする要件を作成するのに役立つ。この問題は好適実施例では、メモリ・ベースのブート・イメージ(memory based boot image)を利用することによって取り組まれている。メモリ・ベースのブート・イメージは、必要な相互依存性がすべて解決されている自立型(self contained)オブジェクトの集合である。この集合は、バッキング・ストア・デバイスをマウントし、それによってブート・イメージに含まれていないソフトウェアの残り部分をアクセスできるようにする、十分なシステム・ソフトウェアを含んでいる。従って、システムは、システムの低レベル部分をこのブート・イメージからブリング・アップ(bring up)し、ブート・イメージの外側に出してシステムの残り部分をブリング・アップすることによりブートすることができる。好適実施例は、ファイル・システムと入出力システムが使用可能になるのに先立ち、ブーティング期間にカーネル・ページング要求を満足させるメカニズムも備えていなければならない。ブート・コンテント・サーバ(boot content server )はこの問題を解決するために採用されている。ブート・コンテント・サーバは、ページング・アーキテクチャに基づくデータ・ソース独立コンテント・サーバ・ベースを利用している。コンテント・サーバはカーネル・メモリ・マネージャをファイル・システムから切り離し、バッキング・ストア・ベースのファイル・システムの有無に関係なく、メモリ・マネージャ要求が整合性のある方法でサービスを受けることを可能にする。カーネル・メモリ・マネージャへのアクセスと、ブート・イメージ内の種々ファイルへのアクセスを提供する。ファイル・システムが立ち上がって、実行状態になる前に、ページング要求はこのブート・コンテント・サーバによって処理される。ブート・コンテント・サーバに知らされるファイルとデータ構造の集合全体はメモリ・ベースになっている。ブート・コンテント・サーバとバッキング・ストア・デバイスとの相互作用は行われない。ブート・コンテント・サーバは一時的なものであり、できるかぎり早い時期に本来のファイル・システムに道を譲る。ブート・フレームワークはブーティング作業をカプセル化し、モジュール化するための、いくつかの重要なインタフェースを定義している。ブーティング・フレームワークを使用すると、新しいＯＥＭプラットフォームと新しいブート・ソース・デバイスにブート・ソースとして移植する際に必要になる作業が容易化される。モジュール性は、ＣＰＵプラットフォームとブート・ソース・デバイスの独立性を提供する。従って、ブーティングの土台は特定のＲＯＭにも、スタート・コードの断片にも束縛されていない。ブーティング設計は、キー・サービスの一部を含んでいる最小限のシステムをブート時に具体化し、ブート時に実行されるソフトウェアの多くがフィーチャ（機能）を整合性のある方法で使用できるようにする。例えば、ブーティング・フレームワークはファイル・システムのプロパティ(property)とプリファレンス(preference)を、ブート・プロセス期間に使用することをサポートしている。ブート・コントロールは明示にではなく黙示にドライブされる。ハンド・クラフトの構成スクリプトは使用されない。ブート・イメージに存在するファイルの集合、システムに存在するハードウェアの集合、およびブート・イメージ・ファイル上のプロパティの集合は一緒に働いて、ブート時の実行の順序と選択をガイドする。ハードウェアとデバイス・ドライバとのバインディング（結び付き）は、抽象化可能な多相的(polymorphic)構成内でブーティング・コントロール・ソフトウェアによって取り扱われる。ブーティング・フレームワーク・アーキテクチャブーティング・フレームワークのアーキテクチャは相互に依存するいくつかのコンポーネントを含み、これらはブート・イメージの周囲に包み込まれている。ブート・イメージは、バッキング・ストア、ネーティブ入出力、ファイル・システムと共にカーネルをサポートし、必要なバッキング・ストア・デバイスをマウントする個所までシステムをブリング・アップする(bring up)とき必要になる論理ファイルの集合である。これらのサービスが所定位置に置かれると、システムは独立に実行することができ、ファイル・システムとアクセス・マネージャを使用して、ハイレベル・ツールボックス・ピースのような、システム・ソフトウェア・サービスの残り部分をバッキング・ストアからブリング・アップすることが可能になる。ブート・イメージ・モデルは、必要な部品の集合全体を１つの集合に集約し、システムのブート時にシステムがそれを使用できるようにすることにより、ブーティング・フレームワークが循環依存性問題(circular dependency p roblem)を解決するのを支援する。ブーティングの中心的作用は非常に単純化されている。つまり、このブート・イメージのプリミティブなフェッチを行ってＲＡＭに入れ、ＲＡＭベースのブート・イメージからコードを取り出して実行し、システムの残り部分へ間をおかずに移っていく。図１１は、好適実施例によるブーティング・フレームワークのコンポーネントを示すブロック図である。基本はブート・デバイスに関するものである。このことは、ローカル・ディスク・ブートの場合には、ディスク・ドライバ・ソフトウェア、ローカル・ファイル・システム、およびこれらに依存する共用ライブラリが基本であることを意味する。これに対して、ネットワークとリモート・ファイリング・ソフトウェアはローカル・ディスク・ブートに対して基本になっていない。バッキング・ストア・サポートを含まないが、むしろ、単純なユーティリティのように、ある種のメモリ・ベース・システムが実行されるケースがいくつかある。また、カーネル・デバッガが必要でないために、それがブート・イメージに含まれていないケースもある。ブート・イメージは、以下に示すベーシックな基本ビルディング・ブロックに依存する。つまり、オブジェクト、共用ライブラリ、ライブラリ・サーチャ、クライアント／サーバ・プロトコル、ファイル・システム・インタフェースのサブセット、プリファレンス、タイム・サービス、トークン・サービス、ハードウェア構成サービスなどである。ＲＡＭ常駐ブート・イメージに存在するファイルと、ブート・ソース・デバイスに存在するファイルとの間には直接的対応関係がある。ブーティング・サービスは、ブート・デバイス上のブート・イメージ内のファイル、ブート・デバイス上のブート・イメージ記述子、およびＲＡＭに置かれたブート・イメージ内のファイル相互間の整合性を保証しなければならない。ブート・イメージに組み入れるべきサービスを選択することは、非常に重要である。ブート・イメージ内のソフトウェアの量はメモリ・フットプリント (memory footprint)を小さくするために最小限にしなければならない。しかし、ブート・イメージから取り出されて実行されるコードがそのジョブを可能な限り効率的に完了できるようにするためには、十分なサービスがブート・イメージに存在していなければならない。標準システム・ソフトウェアは、すべてのブート・イメージに存在していなければならない。そのほかに、ブート・イメージは、オプションとして、その意図するユーザのために特殊化機能を提供することも可能である。ファイルがブート・イメージに追加されて、特定のシナリオ用にカストマイズしたブーティング解決手法を提供することができる。例えば、クラスルームにおいて複数のシステムがローカル・ネットワークからブートアップされるシナリオでは、ファイルを追加して、セキュリティとネットワーク・ファイリング機能を提供し、各学習者のために、ファイル・サーバ・ベースの個別デスクトップ環境をサポートすることが可能になる。ブーティング・フレームワークフレームワークは、関連問題群の解決手法の抽象設計を具体化するクラスの集まりであり、クラスよりも大きな粒度での再使用をサポートする。特定のブーティング・システムを実装したものは、ブート・システム構成特定のコンポーネントに結合されたブーティング・フレームワークから構成されることになる。ブーティング・フレームワークは４つのコンポーネントから構成されている。BootPr eparation、BootDelivery、BootSetup、およびBootExecutionである。図１２はブート・オペレーションにおけるコントロールの流れを示すフローチャートである。これらのコンポーネントの各々はブーティング世界の一部をカプセル化している。ブート・イメージはこのフレームワークの中心となるもので、コンポーネントの各々に種々の形で存在している。ブート・フレームワークのコンポーネント BootPreparationコンポーネント BootPreparationは、BootFileSetを特定のブート・デバイスでブーティングする準備状態に置くことに責任がある。このコンポーネントは純粋部分とＯＥＭブート・デバイス特定の部分を含んでいる。 BootDeliveryコンポーネント BootDeliveryは、システム診断と構成、ブート・デバイス選択、およびブート・イメージのフェッチに貴任がある。このコンポーネントはＣＰＵプラットフォームおよびブート・デバイスに特定している。 BootSetupコンポーネント BootSetupは、低レベル・ブート・ローディングおよび環境セットアップに責任がある。このコンポーネントは純粋部分とＣＰＵプラットフォーム特定の部分の両方を含んでいる。 BootExecutionコンポーネント BootExecutionは実際のシステム・ソフトウェアを始動する。このコンポーネントはＣＰＵプラットフォームおよびブート・デバイス依存である。ブーティング・タイムライン図１３は、好適実施例によるブート・フレームワーク処理のタイムラインを示す図である。以下は、ブート・フレームワーク・インタフェースを示したものである。 BootFileSetインタフェース BootFileSetインタフェース・クラスは、ブーティングのターゲットとなるファイルの集合を提示する。ブーティングのマークが付けられるほかに、これらのブート・ファイルは、ブーティング・フレームワークが要求する一部の追加ブート特定の特性を、個別ファイルのファイル・システム・プロパティの形で含んでいる。 BootableDeviceインタフェース BootableDeviceインタフェースは、ブーティングの準備が完了したデバイスを表している。このことは、有効なブート・イメージ、このブート・イメージの適当なブート・イメージ記述子、ブート・イメージ記述子へのパスウェイ(pathway )を提供するブート・アンカ(boot anchor)、およびこの情報を使用してブート・イメージを得るためのコードを含んでいることを意味している。 BootableRAMインタフェース BootableRAMインタフェースは、そこでブーティングを行うことができる土台を提供する。ブート・イメージはメモリ（ＲＡＭまたはＲＯＭ）に入って使用可能である。この中には、ブートしようとするシステムのステートに関する合意、および提供される、ある種のデータの指定が含まれている。データはハードウェア記述子情報とブート・イメージ・メモリ情報を含んでいる。 UniversalStartPointインタフェース UniversalStartPointインタフェースは、共通ＣＰＵプラットフォームとブート・デバイスから独立した、カーネルへの入口インタフェースを提供する。Univ ersalStartPointの中心となる考え方では、この時点の以前には、かなりのプラットフォームおよびデバイス特定のアクティビティがあり、この時点のあとは、すべてのアクティビティが純粋アクティビティになるようにしている。このインタフェースはBootableRAMインタフェースに用意されているシステム・ステート合意を継承する。さらに、UniversalStartPointインタフェースはカーネルに与えられる、ある種のデータを指定している。 Personalityインタフェース Personalityインタフェースは、システム・ソフトウェアの１次ベース(primar y base)がブーティングによってアクチベートされたあと、マシンのコントロールをブーティングから受け取るソフトウェアのある種の自律部分(autonomous pi ece)の、ゆるやかに定義された抽象化である。このクラスは適当なベース・エンド・システム(based end system)を始動し、必要に応じて追加システム・ソフトウェアをアクチベートする。ブーティング・フレームワークの詳細システムのブーティングは順次プロセスである。従って、ブート・モデルは、各プロセスが複数のステップを含んでいる順次プロセスのコンテキストで説明すると好都合である。その意味で、ブーティング・フレームワークのコンポーネントの各々はこのプロセスの１ステージを構成している。ブート準備 BootPreparationコンポーネントのソフトウェアは環境内で実行される。ブーティング準備は、ンストレーション・モデルを通してインストールされたファイルに作用する。インストレーション・モデルは一般的インストレーションのファイルとブート・インストレーションのファイルとを区別する。ブート・インストレーションのファイルはブート・ファイルと呼ばれ、BootFileSetとして互いに集められる。ブート・ファイルはブートを行うためにインストールされたファイルであり、オプションとしてある種の特殊なブート・プロパティを含んでいる。 BootFileSetはインストールされたbootfilesの集合であり、BootPreparationコンポーネントに渡される。ブーティング・フレームワークはBootFileSetに作用する。集合内のファイルは、データをアクセスするとき、どの特殊なカスタム・コンテント・サーバも、解読器(decrypter)も、伸長器(decompressor)も必要としない。特殊なブート・プロパティ BootFileSet内のファイルは、ブーティングに特定するある種の特性であってブーティング・フレームワーク内でフィルタおよびカストマイジング・エージェントとして使用するものを識別する、ある種の追加のオプションの情報をもつことができる。この追加ブーティング情報は、ファイル・システム・プロパティ内にTBootCommand(s)で表される。これらのプロパティはBootExecution期間にブート・コンダクタ(boot conductor)によって照会される。これらのプロパティは開発システム上、デスクトップ上またはその双方で構築時にファイルに付けることができる。実際には、もっとプリミティブな特性の一部は構築時にだけセットされ、もっとユーザ・カスマイズ可能な特性の一部はワークスペース内にセットされる。ここで説明しているファイル・プロパティの使用は、ブート・ファイルの集合を互いに集めるために必要とされるファイル・プロパティの使用とは区別される。ブート準備クラス BootPreparationはブート・ファイルの集合を処理して、ブート可能なファイルの集まりにする責任がある。TBootImageクラスは、ブート・ファイルの集合をデバイスでブート可能にする責任がある。TBootImageインタフェースのクライアントはファイルの集合を用意しなければならない。これらのファイルはTCollect ion& theBootFiles)として渡される。最終的で、有効なファイルの集合が分かった時点で、ブート・イメージ記述子とブート・アンカは生成され、ブート・デバイスに付けなければならない。TBootImageは抽象基底クラスである。サブクラスは特定のハードウェア・プラットフォームとブート・デバイスに特定している。 TBootCommandクラスは、所望の実行特性を個別のブート・ファイルに渡すときのインタフェースとなる。これらの特性はブート・コンダクタをインスタンシエイトする。このクラスはインストール時とBootPreparation時にブート・ファイルに付けることができる。このクラスはBootExecution時に使用される。 TBootImageメソッド： TBootImage(TColl1ection& theBootFiles) protected このパラメータ化構築子はオブジェクト・ステートを、TCollection入力によって指定されたブート・ファイルを含んでいる無効なブート・イメージに初期化する。 TBootImage() protected TBootImage(const TBootImage&) protected 〜TBootImage() 消滅子は内部オブジェクト・ステートを保持しているストレージを解放する。 void AddFiles(TCollection& theBootFiles) 指定されたファイルを、このブート・イメージに含まれているファイルの集合に追加する。 void GetFiles(TCollection& theBootFiles) 含まれているブート・ファイルを検索する。 void RemoveFiles(TCollection& theBootFiles) 指定されたファイルを、このブート・イメージに含まれているファイルの集合から削除する。 virtual ValidateFileSet() ブート・ファイルの含まれている集合が完全であるかどうかを検査する。集合が有効でなければ、記述例外(descriptive exception)を引き起こす。例外でない完全さは、ブート・イメージのファイルの集合が、プログラム・メソッドが決定できるかぎり完全であることを示している。 virtual Boolean ValidateDescriptor() = 0 ブート・イメージ記述子が存在するかどうか、それがこのファイルの集合で有効かどうかをチェックする。集合が有効でなければ、記述例外を引き起こす。例外でない完全さは、ブート・イメージのファイルの集合がデバイスで有効な記述子を持っていることを示している。 virtual Boolean IsDescriptorBound() = 0 有効なブート・イメージ記述子がこのブート・イメージでバインドされているかどうかをチェックする。 virtual TStream& operator>>=(TStream& towhere) const=0 virtual TStream& operator<<=(TStream& towhere) =0 virtual TStream& operator=（const TBootImage) =0 virtual void BuildDescritor() = 0 ターゲットのブート・デバイスに適当なBootImageDescriptorを生成する。記述子には次のものがある。 (i) ブート・イメージの各ファイルのファイル・システムのファイル識別子 - B ootExecutionコンポーネントのブート・イメージ再利用ステップの間に使用される。 (ii) ブート・イメージ部分のブート・デバイス特定記述子−BootDeliveryコンポーネントのフェッチ・ステップのときに使用される。これらの記述子を作成するには、ファイル・システムおよび／またはデバイス・マネージャからのある種の機能が必要になる場合がある。 BuildDescriptor()はこのBootImageDescriptorをブート・デバイスにストアし、このTBootImageをフラット化してブート・イメージ記述子に付加する。これは、ブート・イメージ記述子からTBootImageへ戻るのに使われる。このメソッドは、ここではイメージがブーティングで使用できるようにするが、必ずしも選択したものとは限らない（複数のイメージが使用可能である場合があり、その１つは、明示の選択メカニズムがないとき使用される、デフォルトに選択しているとしてフラグが付いているものとみなされる）。このメソッドは、ブート・イメージ・コンテントがまだ有効であるとされていなければ例外を引き起こす。 virtual void BindDesriptor() = 0 BootImageDescriptorをこのブート・デバイスでブート時に見つけるためのパスウェイ（通路）となるBootAnchorを生成する。このパスウェイはブート・デバイスに書き出され、BootDelivery期間に、システム内のスタート・コードからBo otImageDescriptorまでの間のインタフェースの働きする。このパスウェイは論理的パスウェイである。これは単純にブート・デバイスのアドレスである場合と、ブート・イメージを見つけるために実行されるある種のコードである場合とがある。このメソッドは、このイメージをこのデバイスでブートするときのデフォルトの選択したものにする。このメソッドは、ブート・イメージ・コンテントがまだ有効であるとされていないか、または記述子が作られていないならば例外を引き起こす。 virtual Boolean MakeBootable() ValidateFileSet()、BuildDescriptor()、およびBindDescriptor()メソッドを続けて呼び出す。 TBootCommandメソッド： TBootCommand () ヌル構築子。 TBootCommand (TText& className,TText& libraryName) パラメータ化構築子は、指定されたクラスとライブラリ情報でTBootCommandを初期化する。〜TBootCommand () 消滅子は、内部オブジェクト・ステートを保持しているストレージを解放する。 void Run() BootStartEntity情報をセットしてプロパティ・コンテナに入れる。このメソッドは作成時またはワークスペースで使用される。モデルとして使用でき、ブート時に事物をスタートする方法は、ほかにもいくつかある。 (i) オブジェクトをコンダクタのアドレス空間に生成する。このオブジェクトは（クラス、ライブラリ）のペアで指定する。このオブジェクトが行なえることはほとんどないが、先へ進んで出てから、追加のオブジェクトを新しいチームでスタートすることもできる。これは、デフォルトの動作(behavior)として基底クラスで提供されるモデルである。 (ii) （クラス、ライブラリ）ペアのTClassTaskProgramを生成する。 TClassTaskProgramを構築子引数として使用してTTeam[6]を生成する。このようにして、所望のオブジェクトを新チームで立ち上げて、実行状態にする。 (iii) ストリームを復活するためのTFileStreamTaskProgramを生成する。 TFileStreamTaskProgramを構築子引数として使用してTTeamを生成する。このようにして、所望のオブジェクトを新チームで立ち上げて、実行状態にし、オブジェクトは、フラット化したオブジェクトを通してあらかじめ初期化する。 TBootCommand基底クラスは、上記の基本モデル(i)をサポートする。ブーティング・フレームワークは、モデル(ii)と(ii)をサポートするためにTBootCommand サブクラスを提供することができる。使い方のシナリオターゲット・ハードウェアとブート・デバイス・プラットフォームでブートを行う特定の実装では、TBootImageのサブクラスが存在していなければならない。例えば、ブート／フープ(hoop)のターゲットは、ＨＰＳベースのローカル・ディスクからブートするマッキントッシュ・プラットフォームである。TMacDiskBoot Imageサブクラスが存在することになる。ワークスペースは、ブート・ファイルのインストールが完了すると、TMacDiskBootImageをインスタンシエイトして、インストールされたブート・ファイルの集合を提供することができる。そのあと、ワークスペースはこのTBootImageでMakeBootable()メソッドを呼び出して、フート・ファイル集合の有効性を検査し、そのブート・ファイル集合をこのハードウェア・プラットフォームとブート・デバイスでブートする準備状態に置くことができる。MakeBootable()の方は、ValidateFileSet()、BuildDescriptor()、およびBindDescriptor()メソッドを呼び出すことになる。図１４は、好適実施例によるブート処理を示すブロック図である。ブート・デリバリブート・デリバリ(boot delivery)カテゴリは、ある種のまさしくハードウェア・プラットフォートとブート・デバイス特定のアクションを実行することに責任がある。この中には、低レベル・システム診断、低レベル構成グロベリング(g roveling)、ブート・デバイス選択、およびブート・イメージ・フェッチングが含まれる。ブート・デリバリ・カテゴリよりなるコードは、ブート・イメージの外に常駐する。このコードはアセンブリ言語で書かれたプリミティブＲＯＭコードにすることも、Ｃ++で書かれたリッチ・コード(rich code)にすることもできる。コードはスタティック・データ、スタティック・オブジェクト、およびヒープを使用することもできる。重要なことは、ユーザが必要とする言語のサポートとランタイム（実行時）サポートを行うのは、この断片のＯＥＭ実装の義務であることである。しかし、もっと一般的には、共用ライブラリはNubLibary サーバが始動されたあと使用可能になるが、これはBootExecutionフェーズ期間に行われる。このソフトウェアはＲＯＭにも、ブート・デバイス上のプリミティブ・ロケーションにも、ほかのロケーションにも、これらのロケーションを組み合わせたものにも、常駐させておくことができる。デリバリ・フェーズ内のステップの順序は厳格でない。実際には、実装によっては、最初にデバイスを選択し、そのあとで、一部の追加スタート・コードをそのデバイスから持ち込むことができる。ブーティング・フレームワークはこのレベルではポリシを指図しない。 BootDeliveryコンポーネントは２つの機能部分を提供する。ブート・スタート (boot start)とブート・フェッチである。ブート・スタートは従来の低レベル低質(grunge)コードであり、ハードウェア構成を決定し、マシン上で低レベル診断を実行するためのものである。ハードウェア構成の決定はマザーボード・レベルで行われる。例えば、マッキントッシュのブート・デリバリはＲＯＭに存在する。ボトム・ライン(bottom line)はそれが終了して、スタート・コード・ステップが完了したとき、構成が分かっていて、健全なものでなければならない。スタート・コードは、オプションのブート時デバイスとBootProfile選択を提供することもできる。BootProfileは、ブート処理の間使用するパラメータの（オプション）の識別子である。これらのパラメータは、ある種の動作のとき許可または禁止する働きを提供する。BootProfileはブート・プロセスに渡されていき、Boo tExecutionコンポーネントで使用される。ほとんどの場合、このステップはユーザ入力を要求しないが、PRAMなどの持続的ストレージからパラメータを取得して、デバイスとプロフィールの選択をガイドする。ブーティング・フレームワークは、特定の実装がデバイス選択をどのように扱うことができるかに関する、どのようなポリシ・ステートメントも出さない。この選択ステップはブート・アンカについていって、BootImageDescriptorを位置づけなければならない。このBootI mageDescriptorはBootFetch関数に手渡される。この選択ステップは、特定のハードウェア・プラットフォームに特定する可能性が大である。 bootfetchは、Boot Deliveryカテゴリの中心となる関数である。BootFetchへのインタフェースは単一のパラメータである、BootImageDescriptorへのハンドル(handle)をもつエントリ・ポイントである。BootFetchはBootImageDesc riptorを処理して、デバイスからのブート・イメージをメモリに入れる。ブート・イメージをブート・デバイスからフェッチしている間に、ブート・マップが構築される。このマップはメモリにあるブート・イメージの場所を記述している。フェッチ・ステップは特定のブート・デバイスに特定している。BootDeliveryコンポーネントは、プリミティブ・フィードバック・メカニズムを提供するようにも要求される。最低限必要なハードウェア構成を確立しなければならない。このベースラインが与えられていれば、ある種の汎用的最小公分母ユーザ・フィードバックを定義することができる。例えば、ビープトーン(beep-tone）・ジェネレータは、ある場合には、適当であることもあり得る。このメカニズムは、低レベルのものが出現して、改良されたメカニズムがUniversalStartPointの反対側で使用可能になるまで、ここで使用されるほかに、ブーティングの以後のステージの間に使用される。このプリミティブ・メカニズムは、この関数を提供するスタンド・アロン・コードとして、指定されたエントリ・ポイントと一緒にエクスポートすべきである。このコードのメモリ・フットプリントはBootableRAMデータの中で与えられる。 BootDelivery、BootSetup、およびBootExecutionステージの間に認識される小さな、固定されたエラー条件の集合がある。ブーティング・フレームワークは、これらの条件をヘッダ・ファイルにパブリッシュ(publish)された列挙型を通して形式化する。このプリミティブ・フィードバック関数のセマンティックスは、これらの条件の各々について、区別できるサウンドまたは他のしるし(indicia) を出力するように設計されている。この関数の特定のシンタックスはヘッダ・ファイルに形式化されている。BootDelivery関数は一緒に働いて、ハードウェア記述子、ブート・イメージ・メモリ・マップおよびBootProfileをBootableRAMにパッケージ化する。いったん完了すると、コントロールはブート・イメージに渡される。ブート・セットアップ BootSetupコンポーネントのソフトウェアは環境の外で実行される。BootSetup コンポーネントのコードはブート・イメージに常駐されている。図１５は好適実施例によるBootImage目次(table of contents)を示すブロック図である。BootSe tupはブート・イメージに入るエントリ・ポイントである。このコンポーネントのコードは、ブート・イメージ内の公知のエントリ・ポイントに残っており、Bo otableRAMデータへのハンドルをパラメータとして受け取る。このコードは、Boo tableRAMに置かれているマッピングに基づいてブート・イメージ目次を修正(fix up)する責任がある（図８参照）。さらに、このコードはカーネルをロード（実行時にという意味）する責任がある。カーネルのローディングは、カーネルの作成時に作られたカーネルのロード・ファイル・フォーマットによってドライブされる。BootSetupは必要とされるプロセッサ特定リロケーションまたはフィックスアップ(fix-ups)をブート・イメージ内で実行することにも責任がある。新しいCPUプラットフォームのときは、新しいロードファイル・フォーマットを扱うように特定のブート・ローダ機能を置き換えることが可能である。カーネルがロードされたあと、BootSetupはＲＡＭ記述子のテーブルに記入し、UniversalStar tPointの要求を満足する。いったんこれが完了すると、コントロールはカーネルに移って、カーネルのmain()エントリ・ポイントを呼び出し、UniversalStartPo intのデータのセットを渡す。ブート実行 Bootl Executionコンポーネントは、ＯＥＭによってオーバライドされることを目的としていない。ＯＥＭがBootDeliveryとBootSetupエリアのフレームワークを厳守しているときは、純粋Boot Executionコンポーネントをそのままで使用することができる。BootExecutionコンポーネントはブート・プロセスのワークハウス(workhouse)である。システム・ソフトウェアはそこからブリング・アップ(bringup)される。このアクティビティは２ステップに分割されている。システム生成(genesis)ステップとブート・コンダクタ・ステップである。システム生成ステップでは、カーネルを初期化し、共用ライブラリをサポートするようにランタイムをブリング・アップすることが行われる。システム生成時に実行されるコードは、ベーシックなＣをランタイム使用可能にしている。このことは、少なくともスタックと初期化されたグローバル・データを意味する。システム生成ステップ時のファイル・オペレーションは、ブート・イメージに含まれているファイルを管理するカーネル・タスクである、BootContentServerによって処理される。カーネル自体は、このステップ時に自身の初期化を内部で取り扱う。カーネルのmainは、カーネル・タスクを初期化するために必要なシステム構成情報を記述したUniversalStartPointデータと一緒にコールされる。カーネルが初期化されると、ページングを開始することができる。この時点では、ページングはメモリ・ベースのブート・イメージを管理するブート・コンテント・サーバを通して行われる。カーネルにリンクされたシステム生成タスクもあり、これは共用ライブラリのサポートに必要な基本的NubLibraryサーバを始動する。 NubLibraryは静的にリンクされたランタイム・サービス、ある種のサーバ、および低レベル・システム共用ライブラリの集合である。この集合は、共用ライブラリをサポートするためにランタイム・システムをアクチベートさせるために必要な正確なソフトウェアを含んでいる。NubLibraryにバインドされたライブラリとサーバの集合は、ランタイム・グループによって決定される。NubLibraryに置かれていて、明示的に始動させる必要がある基本的サーバの集合は、プライベート・ファイル・ベースのリストを通してランタイム・グループによって指定される。システム生成タスクの最終的行動はブート・コンダクタ・プログラムを始動することである。ブート・コンダクタブート・コンダクタ(boot conductor)は、必要なステージングを行って必要なソフトウェアをブリング・アップし、存在する必須のハードウェアをサポートし、システム・ソフトウェアを保持しているストレージ・デバイスでファイル・アクセスを行うことをサポートすることを担当している。BootConductorはハードウェア・プラットフォームおよびブート・デバイスから独立している。ブート・コンダクタ・クラスと抽象化 BootConductor BootConductorプログラムはBootExecutionコンポーネントの心臓である。ブーティングの関心のある側面の大部分を制御するのがこのコードである。ブート・プロセスにあるとき、なにが始動されるかはここで決定される。存在するハードウェア・コンポーネントの集合、ブート・イメージに存在するソフトウェアの集合、これらのコンポーネントのプロパティ、およびカスタム・ライブラリ・サーチャは一緒になってブート・コンダクタのアクションをドライブする。このプログラムは一度だけ実行され、共用ライブラリが使用可能になると、直ちにシステム生成タスクによって始動される。 BootFSServer BootFSServerは、ファイル・システム・インタフェースのサブセットを提供する。ファイルをアクセスし、ファイル・プロパティをオープンし、クローズし、これらのファイル内のデータをアクセスするためのサポートが行われる。このアクセスはブート・コンテント・サーバを通して行われる。BootFSServerに知らされるファイルの集合はブート・イメージに存在するファイルに制限されている。 TBootCommand 上述したように、ブートのこの部分の間、TBootCommand(s)はBootConductorのアクションをガイドするために使用される。 TBootLibrarySearcher TBootLibrarySearcherクラスは、ブート時に共用ライブラリに位置づけるためのカスタム・ライブラリ・サーチャを提供する。このクラスは、TLibrarySe archerからサブクラス化され、CreateContainerAndFindLibraryがオーバライドするキー・メソッドとなっている。ブート時に複数のサーチャがアクティブになることができる。オプションのBootProfileは、ブート期間にTBootLibrarySearc her(s)のセットを使用することを指図するのを助ける。さらに、特殊なTBootLib rarySearcherが、ブート・イメージ、例えば、NuBusデバイスのＲＯＭベースのドライバにではなく、デバイスにストアされたある種のドライバ共用ライブラリを見つけるためにある。これらは、主として、タリジェント社ブーティング・コードから得られるが、ＯＥＭから得ることも可能である。ブート・コンダクタの考え方 TMachine、ブート・イメージ内のファイルのプロパティ、およびブート・ライブラリ・サーチャは、ブート時になにを実行するかを選択するときのキー・プロセスとなっている。BootProfileは、ブート・ライブラリ・サーチャが使用するためのガイダンスと、特定のブート・セッション時にどのファミリのブート・ファイル・プロパティを適応させるかについてのガイダンスをブート・コンダクタに与えることができる。コンダクタはカスタム・ライブラリ・サーチャを使用して、種々のオブジェクトを探し出して、オブジェクトへのアクセスを見えないようにするが、これはなにを、いつ始動させるかを制御する間接的方法である。一般的には、アクションは明示にではなく黙示に行われる。１次オブジェクトと２次オブジェクト１次オブジェクトは、BootConductorがインスタンシエイトするブート・イメージ・ベースのオブジェクトである。これらのオブジェクトは、システムを立ち上げてＯＰＤをマウントするBootConductorの中心ジョブの基本となるものである。１次オブジェクトの例として、TMachineがある。２次オブジェクトは、１次オブジェクトでないが、ブート時に実行させたいブート・イメージ・ベースのオブジェクトである。これらの２次オブジェクトは必須にすることも、オプションにすることもできる。オプションの２次オブジェクトの例としては、ある種のバックグランド・プリンタ・ステータス・サーバがある。ブート・コンダクタは、実行機会を何回か２次オブジェクトに与える。オブジェクトとチームブート・コンダクタによる１次オブジェクトと２次オブジェクトのスタートアップは、オブジェクト実行モデルに従って行われる。ブート・コンダクタはオブジェクトをインスタンシエイトする。オブジェクトの方は、オブジェクトの目的に応じてアクティブ・サーバを生成し、チームを送り出し(launch)、他のオブジェクトをインスタンシエイトすることに貴任がある。パッシブ・サーバは、クライアント／サーバ・プロトコルを使用して暗黙に始動される。ブート実行可能は TBootCommandによって指定される。ブート・コンダクタ・シーケンス BootConductorプログラムは、一定シーケンスに並んだオペレーションからなり、各オペレーションはプログラムのルーチンにカプセル化されている。このセクションでは、オペレーションのシーケンスをリストする。 BootFSServerをブリング・アップする BootFSServerは最初に始動される。BootFSServerが立ち上がると、これはファイル・システム・リソース・マネージャに登録され、そのサーバを始動させる。 TMachineとデバイス・ドライバを構成するタリジェント・デバイス・ドライバは、入出力デバイスを取り扱って、システム・ソフトウェアに統合化するために必要なオブジェクトの集まりと考えることができる。入出力デバイスをこれらのソフトウェア・オブジェクトにバインドすることは、TMachineと構成アクセス・マネージャの抽象化で処理される。ブート・コンダクタはTMachine抽象化を通してデバイス・ドライバを始動する。TMachi neは、種々のルート・ハードウェア・コンポーネントをその制御に必要なソフトウェアにマップ（対応づけ）するために必要とされるデバイス依存知識について責任をもっている。TMachineは、ブート・コンダクタが始動して、このデバイス依存ソフトウェアを開始するためのメソッドを提供する。ハードウェア構成サーバに登録する責任は、TMachineにより処理される。単純フィードバック・メカニズムの置換この時点までのブート・プロセスは、BootDeliveryコンポーネントによりBoot ableRAMを通して提供されるプリミティブ・フィードバック・メカニズムを採用している。デバイス・ドライバとランタイムは使用可能になっている現時点では、ブート・コンダクタは、もっと進んだ、しかしまだリッチでないユーザ・フィードバック・メカニズムである、TSimpleOutputDeviceを使用する。この目標は、ブート・プロセスのこの時点で異なるプラットフォームで使用可能になっている機能の範囲からグレースに性能低下させること(graceful degradation)である（例えば、この範囲は完全グラフィックス・システムからprintf()スタイルのライン・モードまでにわたっている）。インタフェースは、グラフィックスと文字ベースの両世界で達成可能になっている必要がある。ファイル・システムをブリング・アップするこの時点で、ＦＳサーバをブリング・アップすることが可能である。これはローカルまたはリモートにすることができる。ＦＳサーバをブリング・アップするモデルはファイル・システム・オブジェクトをインスタンシエイトするモデルである。このファイル・システム・オブジェクトは、必要なチーム、サーバ、またはＦＳサーバが必要とするものをブリング・アップすることに責任があることになる。このFSServerはファイル・システム・リソース・マネージャに登録されることになるが、これは以前にBootFSServerによって暗黙に始動されていたものである。ＦＳサーバが立ち上がって、バッキング・ストア・デバイスがマウントされると、カーネルのデフォルト・ルート・コンテント・サーバのノーション(not ion)は、ブート・コンテント・サーバからＦＳコンテント・サーバへ転送される。新しいファイル・アクセス・コールはＦＳサーバのサービスを受けるが、Boot FSServerと共にオープンされたファイルは、ブート・イメージ再利用が完了するまでBootFSServerによるサービスを受け続ける。これについては、以下で説明する。ブート・イメージ再利用を実行するファイル・システムが使用可能になると、ブート・コンダクタはブート・イメージＲＡＭフットプリントの一部を再利用することができる。これは、BootFSSe rverと共にオープンされたファイルの集合を繰り返し、各ファイルごとに、特殊なオペレーションのセットを実行することにより達成される。このオペレーションのセットでは、ファイル・システムが、あるファイル・システム・ハンドルを取り戻してファイルをオープンし、このハンドルをブート・イメージ上の旧ハンドルと交換するようにメモリ・マネージャに指示し、最後に、メモリ・エクステントを解放するようにメモリ・マネージャにプロンプトすることが行われる。これは、メモリ・マネージャに、これらのファイルのＲＡＭブート・イメージにではなく、バッキング・ストアに移る能力を与える。 TMachineとデバイス・ドライバを構成する−再度全ファイル・システムが使用可能になったことが分かったので、BootConducto rは、階層を再び開始するようにTMachineに要求する。階層をたどっていく間に、より多くの必要なオブジェクトが使用可能であることが予想されるので、より多くのデバイス・ドライバがアクティブにされることになる。フェード・ツーするフェード・ツー(fade to)ステップでは、パーソナリティ・オブジェクトが始動される。このオブジェクトは、前述のブート実行可能の個所で説明したように、TBootCommandメカニズムを通してブート・コンダクタによって見つけられる。これは本来のオブジェクトである場合と、実オブジェクトを見つけて、始動する方法を知っているライトウェイト代理(lightweight proxy)である場合とがある。これはシングル・エンティティにするべきであり、これはコンダクタがその送出方法を知っているスタートアップ・アプリケーション群をもたなくても、スタートアップ・プログラム・プロトコルの独自のバージョンをもつことができる。この時点で、意図するシステムは立ち上がり、実行状態になるが、これはそれで終わる場合と、もっと大きなものへのステッピング・ストーンである場合とがある。これで、ブーティングは完了する。ブート・コンダクタのステップブーティング進行マーカ・ポイントのセットが存在する。このセットはブート・フィードバック情報をドライブする。これらのポイントのサブセットはBootSt artEntitiesの挿入ポイントをドライブする。ブート・プロセスは図１６にブーティング・タイムラインで再現されている。このタイムラインは、ブート可能デバイスがスターティング・ポイントとして存在することを想定している。ウォーム・ブーティングウォーム・ブーティング(warm booting)とはチェックポイント・システムのステートの使用に関し、システムのリスタート（再始動）に必要なオーバヘッドを大幅に軽減するものである。これは興味があり、見込みのある概念であり、基本レベルにあり、ブーティング・レベルにあるだけでないシステムを含む。ブーティング設計はこのトピックを扱っていない。ソフト・ブーティング（または拡張可能リスタート）ブート／フープ実装のデフォルト・ケースはハード・ブート(hard boot)になっている。このことは、システム・ブート・プロセスがハードウェア・リセットで開始されることを意味する。ソフトウェア・リセットでブート・プロセスを開始する考え方はブーティング設計によってサポートされている。ソフト・ブートでは、ＲＯＭとの依存関係の一部とハードウェア・プラットフォームのスタート・コードが削除される。ソフト・ブートは、ある種の追加システム・サービスが達成可能であることを要求する。ソースを選択し、ソフト・ブートを呼び出すときに含まれるヒューマン・インタフェース上の問題がいくつかある。また、シャットダウンの完了時のシステムの保証されたステートを含む、シャットダウンの完了時にコントロールをどこに渡すかという、システム・シャットダウン上の問題もある。以上、好適実施例の種々実施形態を説明してきたが、これらは単なる例示であり、これらに限定されるものでないことは勿論である。従って、好適実施例の広さや範囲は上述した実施例に限定されるものではなく、請求の範囲に記載されている事項および等価事項に従ってのみ判断されるものである。

【手続補正書】特許法第１８４条の８【提出日】１９９６年２月９日【補正内容】（原文明細書第１頁）明細書自動ブーティング・フレームワーク発明の背景発明の分野本発明は、一般的にはコンピュータ・システムの入出力アーキテクチャを目的とし、より具体的にはコンピュータ・システムのオブジェクト指向入出力アーキテクチャを目的としている。関連技術代表的なコンピュータは、コンピュータに接続された周辺デバイスとのインタフェースとなる入出力（Ｉ／Ｏ）システムを含んでいる。この入出力システムは、コンピュータ・システムの資源と周辺デバイスとの間のインタフェースとして働いている。また、この入出力システムは、コンピュータ・システムで実行されるプログラムと周辺デバイスとの間のインタフェースともなっている。入出力システムは、従来の「手続き指向(procedure-oriented)」のソフトウェア・プログラミング技法（オブジェクト指向またはルール・ベースのソフトウェア・プログラミング技法と対比されている）を用いてインプリメント（実装）されているのが代表的である。理解されるように、手続き指向ソフトウェア・プログラミング技法を使用して作られたソフトウェア・プログラムは拡張が容易でないことがよくある。また、この種のソフトウェア・プログラムは再利用が容易でないこともよくある。従って、従来の入出力システムは拡張が容易でないことがよくあり、また、かかる入出力システムに関連するソフトウェアは再利用が容易でないことがよくある。代表例として、入出力システムは、単一のオペレーティング・システムに特定した形でインプリメントされている。この入出力システムは、オペレーティング・システムに関連する入出力関数コール(function call)に応答してそれを正しく処理しているが、この入出力システムは他のどのオペレーティング・システムでもサポートできる能力は備えていない。複数のオペレーティング・システムをサポートするコンピュータに対する要求が高まっている。明らかなように、従来の入出力システムを使用するコンピュータは、その入出力システムがサポートするオペレーション・システム(operation system)のみサポートできるので、現在のマーケットでは不利になっている。 EP-A2-0-565-875は、基本入出力システム（ＢＩＯＳ）とアドバンスド基本入出力システム（ＡＢＩＯＳ）の欠陥を、ペン・ベースのポータブル・コンピュータと関連づけて取組むための方法と手法のセットを開示しており、他方では、ハードウェアとオペレーティング・システムとの間に絶縁層を設けることによって、その長所の多くをそのまま残して、同じオペレーティング・システム・コード本体が種々のハードウェア・プラットフォームで実行されるようにしている。具体的には、次のような欠陥が取り上げられている。(a)ユーザがセットアップ・プロシージャを通して、従来の（ＤＯＳスタイル）ブーティング・プロシージャまたはペンポイント・スタイルのブーティング・プロシージャのどちらかを選択できるようにするデュアル・ブート能力、(b)オペレーティング・システムからある種のデバイス特性をマスクする能力（コールバック・メカニズムと定義されている）、および(c)コンピュータの操作期間に切離しまたは再接続ができるデバイスのデバイス・ステート情報を収集し、維持する方法。以上のように、要求されていることは、拡張が容易であり、再利用が容易であるソフトウェアを具体化しており、しかも、複数のオペレーティング・システムをサポートしているコンピュータの入出力システムである。発明の概要本発明は、劣化した(degradated)ファイル共用メカニズム(file sharing mech anism)を完全に定義したオペレーションで最初に初期化して、オペレーティング・システムのより高度化した側面を動作可能にするとき使用されるようにするブーティング・プロシージャを目的としている。（原文明細書第３８頁）ある。これはシングル・エンティティにするべきであり、これはコンダクタがその送出方法を知っているスタートアップ・アプリケーション群をもたなくても、スタートアップ・プログラム・プロトコルの独自のバージョンをもつことができる。この時点で、意図するシステムは立ち上がり、実行状態になるが、これはそれで終わる場合と、もっと大きなものへのステッピング・ストーンである場合とがある。これで、ブーティングは完了する。ブート・コンダクタのステップブーティング進行マーカ・ポイントのセットが存在する。このセットはブート・フィードバック情報をドライブする。これらのポイントのサブセットはBootSt artEntitiesの挿入ポイントをドライブする。ブート・プロセスは図１６にブーティング・タイムラインで再現されている。このタイムラインは、ブート可能デバイスがスターティング・ポイントとして存在することを想定している。ウォーム・ブーティングウォーム・ブーティング(warm booting)とはチェックポイント・システムのステートの使用に関し、システムのリスタート（再始動）に必要なオーバヘッドを大幅に軽減するものである。これは興味があり、見込みのある概念であり、基本レベルにあり、ブーティング・レベルにあるだけでないシステムを含む。ブーティング設計はこのトピックを扱っていない。ソフト・ブーティング（または拡張可能リスタート）ブート／フープ実装のデフォルト・ケースはハード・ブート(hard boot)になっている。このことは、システム・ブート・プロセスがハードウェア・リセットで開始されることを意味する。ソフトウェア・リセットでブート・プロセスを開始する考え方はブーティング設計によってサポートされている。ソフト・ブートでは、ＲＯＭとの依存関係の一部とハードウェア・プラットフォームのスタート・コードが削除される。ソフト・ブートは、ある種の追加システム・サービスが達成可能であることを要求する。ソースを選択し、ソフト・ブートを呼び出すときに含まれるヒューマン・インタフェース上の問題がいくつかある。また、シャットダウンの完了時のシステムの保証されたステートを含む、シャットダウンの完了時にコントロールをどこに渡すかという、システム・シャットダウン上の問題もある。請求の範囲１．ブート・コマンドに応答してコンピュータ・システムを初期化する装置であって、プロセッサと、揮発性メイン・ストレージと、該ストレージに接続され、その制御下に置かれている不揮発性ストレージとを含んでいるものにおいて、（ａ）前記外部ストレージは、システム・ソフトウェア、特定のシナリオ用にカストマイズされたブーティング解決手法、およびブーティング・プログラムのコピーを含んでいるブート・イメージを収容していて（図１２）、（ｂ）前記ブート・コマンドに応答して、前記ブーティング・プログラムを前記外部ストレージから前記揮発性メイン・ストレージにロードする手段と（図１３）、（ｃ）前記ブーティング・プログラムが前記揮発性メイン・ストレージにロードされると動作して、該ブーティング・プログラムを始動する手段であって、それと同時に該ブーティング・プログラムは前記プロセッサを制御するものと（図１４）、（ｄ）前記ブーティング・プログラムによって制御され、前記システム・ソフトウェアおよび前記カストマイズされたブーティング解決手法を利用して該コンピュータ・システムを構成し、オペレーティング・システムを前記揮発性メイン・ストレージにローディングする手段と（図１５）、（ｅ）該コンピュータ・システムがブートされると動作して、複数のブート・ファイルを生成する手段と、前記複数のブート・ファイルの生成に応答して、該複数のブート・ファイル内のすべてのシステム相互依存性を解決する手段と、上記で生成された該複数のブート・ファイルを、以後に行われるプーティング・プロセスのカストマイズされたブーティング解決手法として前記外部ストレージにストアする手段と（図１６）を備えていることを特徴とする装置。２．前記コンピュータ・システム（１００２）は複数の周辺デバイス（１０１８，１０２０，１０２２，１０２４，１０２６）を備えており、前記構成およびオペレーティング・システム・ローディング手段は前記複数の周辺デバイスの各々をブーティング・プロセス間に初期化するための情報をストアする第１データ構造手段を備えたこと（図１５）を特徴とする請求項１に記載の装置。３．前記構成およびオペレーティング・システム・ローディング手段は前記オペレーティング・システムをブーティング・プロセス間に初期化するための情報をストアする第２データ構造手段を備えたこと（図１１）を特徴とする請求項１に記載の装置。４．前記構成およびオペレーティング・システム・ローディング手段は複数の共用ライブラリおよび、該複数の共用ライブラリの各々をブーティング・プロセス間に使用可能にする手段とを備えたこと（図１６）を特徴とする請求項１に記載の装置。５．複数のブート・ファイルは前記外部ストレージにストアされていて、該装置は前記ブート・コマンドに応答して、前記複数のブート・ファイルの各々を該外部ストレージから前記揮発性メイン・ストレージにローディングする手段と前記ブーティング・プログラムによって制御されて該複数のブート・ファイルを使用して前記コンピュータ・システムを初期化する手段とをさらに備えたこと（図１５）を特徴とする請求項１に記載の装置。６．前記ブーティング・プログラムによって制御されて、前記複数のブート・ファイルを使用して前記揮発性メイン・ストレージを初期化する手段を備えたこと（図１５）を特徴とする請求項１に記載の装置。７．追加のシステム・ファイルは前記外部ストレージにストアされていて、前記ブーティング・プログラムは該追加のシステム・ファイルをブーティング・プロセス間にアクセスすること（図１６）を特徴とする請求項６に記載の装置。８．前記追加のシステム・ファイルは共用ライブラリを備え、前記ブーティング・プログラムは該共有ライブラリを前記ブーティング・プロセス間に前記外部ストレージから前記揮発性メイン・ストレージにロードすること（図１６）を特徴とする請求項７に記載の装置。９．ブート・コマンドに応答してコンピュータ・システムを初期化する方法であって、プロセッサと、揮発性メイン・ストレージと、該ストレージに接続され、その制御下に置かれている不揮発性ストレージとを含んでいるものにおいて、（ａ）システム・ソフトウェア、特定のシナリオ用にカストマイズされたブーティング解決手法、およびブーティング・プログラムのコピーを含んでいるブート・イメージを前記外部ストレージにストアするステップと（図１２）、（ｂ）前記ブーティング・プログラムを該外部ストレージから前記揮発性メイン・ストレージにロードするステップと（図１３）、（ｃ）該ブーティング・プログラムを始動するステップであって、それと同時に該ブーティング・プログラムは前記プロセッサを制御するものと（図１４）、（ｄ）前記システム・ソフトウェアおよび前記カストマイズされたブーティング解決手法を利用して前記コンピュータ・システムを構成し、オペレーティング・システムを該揮発性メイン・ストレージにローディングするステップと（図１５）、（ｅ）複数のブート・ファイルを生成するステップと、該複数のブート・ファイルの作成に応答して該複数のブート・ファイル内のすべてのシステム相互依存性を解決する手段と、上記で作成された該複数のブート・ファイルを、以後に行われるプーティング・プロセスのカストマイズされたブーティング解決手法として前記外部ストレージにストアする手段とを含むこと（図１６）を特徴とする方法。１０．前記コンピュータ・システム（１００２）は複数の周辺デバイス（１０１８，１０２０，１０２２，１０２４，１０２６）を備えており、前記複数の周辺デバイスの各々をブーティング・プロセス間に初期化するステップを含むこと（図１５）を特徴とする請求項９に記載の方法。１１．前記オペレーティング・システムをブーティング・プロセス間に初期化するための情報をストアするステップを含むこと（図１１）を特徴とする請求項９に記載の方法。１２．前記複数の共用ライブラリの各々をブーティング・プロセス間に使用可能にするステップを含むこと（図１６）を特徴とする請求項９に記載の方法。１３．前記複数のブート・ファイルの各々を前記外部ストレージから前記揮発性メイン・ストレージにローディングするステップと、前記ブーティング・プログラムによって制御されて該複数のブート・ファイルを使用して前記コンピュータ・システムを初期化する手段とを含むこと（図１５）を特徴とする請求項９に記載の方法。１４．前記複数のブート・ファイルを使用して、前記揮発性メイン・ストレージを初期化するステップを含むこと（図１５）を特徴とする請求項９に記載の方法。１５．前記追加のシステム・ファイルをブーティング・プロセス間にアクセスするステップを含むこと（図１６）を特徴とする請求項１４に記載の方法。１６．共用ライブラリを前記ブーティング・プロセス間に前記外部ストレージから前記揮発性メイン・ストレージにローディングするステップを含むこと（図１６）を特徴とする請求項１５に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ (72)発明者ロス，パトリック，ディー. アメリカ合衆国 94087 カリフォルニア州サニーヴェイルカナリードライブ 1626

Claims

【特許請求の範囲】１．ブート・コマンドに応答してコンピュータ・システムを初期化する装置であって、（ａ）プロセッサと、（ｂ）前記プロセッサに接続され、該プロセッサの制御下に置かれている揮発性メイン・ストレージと、（ｃ）前記プロセッサに接続され、該プロセッサの制御下に置かれている不揮発性外部ストレージであって、該外部ストレージはオペレーティング・システムのコピーとブーティング・プログラムのコピーを含んでいるものと、（ｄ）前記ブート・コマンドに応答して前記ブーティング・プログラムを該外部ストレージから該揮発性メイン・ストレージにローディングする手段と、（ｅ）前記ブーティング・プログラムが前記揮発性メイン・ストレージにロードされると動作して該ブーティング・プログラムを始動する手段であって、そのあと該ブーティング・プログラムは該プロセッサを制御するものと、（ｆ）前記ブーティング・プログラムによって制御されて、前記コンピュータ・システムを構成し、前記オペレーティング・システムを前記揮発性メイン・ストレージにロードする手段とを備えたことを特徴とする装置。２．前記コンピュータ・システムは複数の周辺デバイスを備えていて、前記構成およびオペレーティグ・システム・ローディング手段はブーティング・プロセス間に前記複数の周辺デバイスの各々を初期化するための情報をストアしている第１データ構造手段を備えたことを特徴とする請求項１に記載の装置。３．前記構成およびオペレーティング・システム・ローディング手段はブーティング・プロセス間に前記オペレーティング・システムを初期化するための情報をストアしている第２データ構造手段を備えたことを特徴とする請求項１に記載の装置。４．前記構成およびオペレーティング・システム・ローディング手段は複数の共用ライブラリおよび、ブーティング・プロセス期間に前記複数の共用ライブラリの各々を使用可能にする手段を備えたことを特徴とする請求項１に記載の装置。５．複数のブート・ファイルが前記外部ストレージにストアされていて、該装置は、さらに、前記ブート・コマンドに応答して前記複数のブート・ファイルの各々を該外部ストレージから前記揮発性メイン・ストレージにローディングする手段と、前記ブーティング・プログラムに制御されて該複数のブート・ファイルを使用して前記コンピュータ・システムを初期化する手段を備えたことを特徴とする請求項１に記載の装置。６．前記コンピュータ・システムがブートされたあと動作して、複数のブート・ファイルを生成する手段と、前記複数のブート・ファイルの生成に応答して、該複数のブート・ファイルにおいてすべてのシステム相互依存性を解決する手段と、かくして生成された該複数のブート・ファイルを以後のブーティング・プロセスに備えて前記外部ストレージにストアしておく手段とを、さらに備えたことを特徴とする請求項５に記載の装置。７．前記ブーティング・プログラムによって制御されて、前記複数のブート・ファイルを使用して前記揮発性メイン・ストレージを初期化する手段を備えたことを特徴とする請求項６に記載の装置。８．追加のシステム・ファイルが前記外部ストレージにストアされていて、前記ブーティング・プログラムはプーティング・プロセス間に前記追加システム・ファイルをアクセスすることを特徴とする請求項７に記載の装置。９．前記追加システム・ファイルは共用ライブラリを備え、前記ブーティング・プログラムは前記ブーティング・プロセス間に前記共有ライブラリを前記外部ストレージから前記揮発性メイン・ストレージにロードすることを特徴とする請求項８に記載の装置。１１．前記オペレーティング・システムは、アップル・システム７オペレーティング・システム、ＯＳ／２オペレーティング・システム、ＤＯＳオペレーティング・システムおよびＵＮＩＸオペレーティング・システムからなるグループから選択されることを特徴とする請求項１に記載の装置。１２．ブート・コマンドに応答してコンピュータ・システムを初期化する方法であって、該コンピュータ・システムはプロセッサと、該プロセッサに接続され該プロセッサの制御下に置かれた揮発性メイン・ストレージと、該プロセッサに接続され該プロセッサの制御下に置かれた不揮発性外部ストレージとを有し、前記外部ストレージはオペレーティング・システムのコピーおよびブーティング・プログラムのコピーを含んでいて、該方法は、（ａ）前記ブート・コマンドに応答して、前記ブーティング・プログラムを前記外部ストレージから前記揮発性メイン・ストレージにローディングするステップと、（ｂ）該揮発性メイン・ストレージで前記ブーティング・プログラムを始動し、そのうえに、該ブーティング・プログラムは前記プロセッサを制御するステップと、（ｃ）前記ブーティング・プログラムを利用して前記コンピュータ・システムを構成し、前記オペレーティング・システムを前記揮発性メイン・ストレージにロードするステップとを備えたことを特徴とする方法。１３．前記コンピュータ・システムは複数の周辺デバイスを備えていて、該方法は、前記複数の周辺デバイスの各々を初期化するための情報を前記外部ストレージに置かれた第１データ構造にストアするステップをさらに備えたことを特徴とする請求項１２に記載の方法。１４．前記方法は、前記オペレーティング・システムを初期化するための情報をストアし、該オペレーティング・システムを初期化するための前記情報をプーティング・プロセス間にアクセスするステップをさらに備えたことを特徴とする請求項１２に記載の方法。１５．複数の共用ライブラリが前記外部ストレージにストアされていて、該方法は、前記複数の共用ライブラリを前記揮発性メイン・ストレージにローディングし、該複数の共用ライブラリを該揮発性メイン・ストレージで使用可能にするステップをさらに備えたことを特徴とする請求項１２に記載の方法。１６．複数のブート・ファイルが前記外部ストレージにストアされていて、該方法は、前記ブート・コマンドに応答して前記複数のブート・ファイルの各々を該外部ストレージから前記揮発性メイン・ストレージにローディングし、該複数のブート・ファイルを使用して前記コンピュータ・システムを初期化するステップをさらに備えたことを特徴とする請求項１２に記載の方法。１７．前記コンピュータ・システムがブートされたあと複数のブート・ファイルを生成するステップと、前記複数のブート・ファイルにおいてすべてのシステム相互依存性を解決するステップと、かくして生成された該複数のブート・ファイルを以後のブーティング・プロセスに備えて前記外部ストレージにストアしておくステップとをさらに備えたことを特徴とする請求項１６に記載の方法。１８．前記ブーティング・プログラムおよび前記複数のブート・ファイルを使用して前記揮発性メイン・ストレージを初期化するステップをさらに備えたことを特徴とする請求項１７に記載の方法。１９．追加のシステム・ファイルが前記外部ストレージにストアされていて、該方法は、前記追加システム・ファイルをブーティング・プロセス間にアクセスするステップをさらに備えたことを特徴とする請求項１８に記載の方法。２０．前記追加ファイルは共用ライブラリを備えて、該方法は、前記共用ライブラリを前記ブーティング・プロセス間に前記外部ストレージから前記揮発性メイン・ストレージにローディングするステップをさらに備えたことを特徴とする請求項１９に記載の方法。２２．前記オペレーティング・システムは、アップル・システム７オペレーティング・システム、ＯＳ／２オペレーティング・システム、ＤＯＳオペレーティング・システムおよびＵＮＩＸオペレーティング・システムからなるグループから選択されることを特徴とする請求項１２に記載の方法。２３．ブート・コマンドに応答してコンピュータ・システムをブートする装置であって、該コンピュータ・システムはプロセッサと、該プロセッサを制御するプログラムをストアしておくための揮発性メイン・ストレージと、該プロセッサに接続され、該プロセッサの制御下に置かれている不揮発性外部ストレージとを有しており、該外部ストレージはオブジェクト指向オペレーティング・システムのコピーおよびブート・イメージ・オブジェクトのコピーを含んでいて、該装置は、（ａ）前記ブート・コマンドに応答して、前記ブート・イメージ・オブジェクトを前記外部ストレージから前記揮発性メイン・ストレージにローディングする手段であって、該ブート・イメージ・オブジェクトはブーティング・プログラムおよび複数のブート・ファイルを備えているものと、（ｂ）前記ブーティング・プログラムが前記揮発性メイン・ストレージにロードされたあと動作して該ブーティング・プログラムを始動する手段であって、そのうえに該ブーティング・プログラムは該プロセッサを制御するものと、（ｃ）前記ブーティング・プログラムによって制御されて前記コンピュータ・システムを構成し、前記オブジェクト指向オペレーティング・システムを前記揮発性メイン・ストレージにローディング手段とを備えていることを特徴とするコンピュータ・システムをブートする装置。２４．前記ブーティング・プログラムは前記ブート・ファイルを使用して前記揮発性メイン・ストレージを構成する手段を備え、前記構成およびローディング手段は該揮発性メイン・ストレージの構成に応答して前記オブジェクト指向オペレーティング・システムを構成された揮発性メイン・ストレージにローディングする手段を備えたことを特徴とする請求項２３に記載のコンピュータ・システムをブートする装置。２５．前記構成およびローディング手段は前記ブート・ファイルを使用して前記コンピュータ・システムおよび前記オブジェクト指向オペレーティング・システムを前記揮発性メイン・ストレージに構成する手段を備えたことを特徴とする請求項２４に記載のコンピュータ・システムをブートする装置。２６．前記ブート・イメージ・オブジェクトをローディングする前記手段は不揮発性スタートアップ・ストレージおよび該スタートアップ・ストレージにストアされたスタートアップ・プログラムを備えたことを特徴とする請求項２３に記載のコンピュータ・システムをブートする装置。２７．以前にブートされたコンピュータ・システム上で動作して前記ブート・イメージ・オブジェクトを生成し、該ブート・イメージ・オブジェクトを以後のブーティング・プロセスに備えて前記外部ストレージにストアしておく手段をさらに備えたことを特徴とする請求項２３に記載のコンピュータ・システムをブートする装置。２８．前記生成手段は前記ブート・ファイルを生成する手段および該ブート・ファイルをチェックしてシステム相互依存性を解決する手段を備えたことを特徴とする請求項２７に記載のコンピュータ・システムをブートする装置。