JP4060890B2 - 階層化ドライバ入出力システム内の複数ドライバによる入出力要求の再処理を可能にするファイル・システム・プリミティブ - Google Patents
階層化ドライバ入出力システム内の複数ドライバによる入出力要求の再処理を可能にするファイル・システム・プリミティブ Download PDFInfo
- Publication number
- JP4060890B2 JP4060890B2 JP54426298A JP54426298A JP4060890B2 JP 4060890 B2 JP4060890 B2 JP 4060890B2 JP 54426298 A JP54426298 A JP 54426298A JP 54426298 A JP54426298 A JP 54426298A JP 4060890 B2 JP4060890 B2 JP 4060890B2
- Authority
- JP
- Japan
- Prior art keywords
- driver
- input
- driver means
- processing
- reanalysis
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/10—Program control for peripheral devices
- G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Description
１．発明の分野
本発明は、入出力（Ｉ／Ｏ）システム内の複数のドライバが入出力要求の処理に参加することを可能にするシステムおよび方法に関する。さらに具体的には、本発明によれば、あるドライバが通常の入出力処理シーケンスに割り込みをかけて別のドライバにコントロール（制御権）を引き渡し、以後の入出力要求処理をそのドライバに任せることを可能にしている。
２．従来技術の説明
関数型コンピュータ・システムは、３つの基本コンポーネントから構成されているのが一般である。第１のコンポーネントはコンピュータ・ハードウェアである。コンピュータ・ハードウェアとしては、中央処理ユニット（ＣＰＵ）などのデバイス、ＲＡＭやＲＯＭなどのシステム・メモリ、磁気または光ディスク・ストレージなどの大容量記憶装置、キーボードまたはその他の入力デバイス、およびディスプレイまたはその他の出力デバイスがある。コンピュータ・システムのユーザはユーザまたはアプリケーション・プログラムとやりとり（インタラクション−対話）しているのが一般である。そのようなプログラムとしては、なじみのあるワードプロセッシング・アプリケーション、スプレッドシート・アプリケーション、データベース・アプリケーションなどがある。最新の関数型コンピュータ・システムの最後のコンポーネントはオペレーティング・システムである。コンピュータ・オペレーティング・システムは、ユーザにアプリケーション・プログラムの実行を開始させる、といったように多数の関数を実行している。さらに、最新オペレーティング・システムは、アプリケーション・プログラムとコンピュータ・システム・ハードウェアとの間のインタフェースも提供している。以上のように、かつてはアプリケーション・プログラムがコンピュータ・システム・ハードウェアに直接にアクセスすることが普通であったが、最新オペレーティング・システムでは、標準化された統一インタフェースが用意されているため、ユーザ・アプリケーションが標準化された方法でコンピュータ・ハードウェアとのインタフェースとなったり、コンピュータ・ハードウェアに直接にアクセスしたりすることが可能になっている。
ユーザ・アプリケーションなどのプロセスと特定タイプのハードウェア・デバイスとを統一インタフェースで結ぶために、実際のハードウェアとプロセスの間にはいくつかのソフトウェア層が設けられている。例えば、プロセスはコールを行ってオペレーティング・システムに入り込むことが可能になっている。これに対して、オペレーティング・システムはハードウェア・ドライバ層が提供するサービスを利用することができる。この場合、ハードウェア・ドライバ層はハードウェアとの直接インタフェースとなっている。この階層化による方法の主な利点は、層の追加や置換が、残りの層に大きな影響を与えないで行えることである。例えば、新しいハードウェア・デバイスがシステムに追加されるとき、新しいドライバが追加できるので、オペレーティング・システムはそのハードウェアにアクセスすることが可能になる。これらの変更はすべて、既存のアプリケーション・プロセスに与える影響を最小限または皆無にして行うことができる。
ドライバがハードウェア・デバイスとのインタフェースとなるために使用されるとき、モノリシック（monolithic）なドライバを作り、オペレーティング・システムと特定のハードウェア・デバイスとのインタフェースになるために必要な、すべての機能をドライバに組み込んでおくのが従来の傾向であった。最近では、オペレーティング・システムは複数のドライバを使用して種々の入出力タスクを実行するように開発されている。これの特に顕著な例として、ディスクや他の大容量記憶装置に対する入出力要求を取り扱うときがある。
データは大容量記憶デバイスに階層的にストアされ、ディレクトリまたはファイルはツリー構造に似た階層に編成されているのが代表的である。任意のファイルまたはディレクトリのロケーションはファイルのパス名で指定されるのが代表的である。パス名はルートまたは開始ディレクトリで始まり、必要とするファイルまたはディレクトリに到達するまでの各サブディレクトリの名前を指定しているのが代表的である。例えば、“file.dat”と名づけたファイルはルート・ディレクトリ“root”のサブディレクトリである、ディレクトリ“temp”にストアすることができる。従って、パス名は/root/temp/file.datとなる。ファイル・システムでのファイル名の解決は、マルチステージ・プロシージャになっているのが代表的である。このプロシージャはファイル・システムに正しく識別させる必要のある、名前付き構成要素（named component）のすべてをデコードするステージから始まっているのが一般である。次に、このプロシージャは、ファイル名中の連続する構成要素を、通常は左から右に向かって識別する繰り返しプロセスが続いている。最後に、このプロシージャはこれらの名前解決の各々が成功したか、失敗したかを判別している。従って、この例では、パス名は連続する構成要素に分解され、解決プロセスはルート・ディレクトリ、tempディレクトリ、およびファイルfile.datを順番に識別していくことになる。
大部分のＵＮＩＸシステムでは、複数のデータ・マネージャが１つのシステム（installation：導入されたシステムのこと）内に共存することが可能になっている。これを達成するために、階層ファイル・ネーム・スペース（hierarchicalfile name space：ファイル名空間）はファイル名とディレクトリ名のサブツリーに分割されている。この場合、各サブツリーの管理は専用のデータ・マネージャが行っている。入出力要求が行われると、名前解決プロセスは名前を特定のサブツリーに変換するので、その入出力要求はそのサブツリーのデータ・マネージャによって処理されることになる。そのあと、データ・マネージャは組み込みＵＮＩＸファイル・システムをコールして、データの実際のストアとリトリーブを行うことができる。従って、データ・マネージャは特定ファイル・システムの能力を拡張する付加価値コンポーネントの働きをする。
複数のデータ・マネージャがＵＮＩＸ入出力システムに存在するときは、正しいデータ・マネージャへの要求のルーチング（routing: 経路選択）は「マウントポイント（mount point）」のメカニズムを通して達成されている。サブツリーの各々を表すために１つのマウントポイントがネームスペースに設定されている。名前解決プロセスの過程で、あるマウントポイントが現れると、ＵＮＩＸ入出力システムは、そのマウントポイントで表されたサブツリーの管理を担当する該当データ・マネージャに要求を送付する。要求を受け取ると、その該当データ・マネージャは名前解決プロセスを継続する。
標準ＵＮＩＸファイル・システムはシンボリックリンク（symbolic link）もサポートしている。シンボリックリンクは名前解決プロシージャが別の名前を使用して新たに開始されるという、組み込み型ケースのひとつである。シンボリックリンクが現れたとき、あるファイル名は別のファイル名に盲目的に置き換えられ、名前解決プロセスはその置換名を使用して新たに開始される。
以上のように、従来のファイル・システムは複数のデータ・マネージャを使用してアドレス空間の異なる部分を管理していた。これらのデータ・マネージャは入出力要求を処理するために、標準ファイル・システムとやりとりすることも可能であった。しかし、従来システムで使用されているモデルは相対的に決定論モデル（deterministic）であったため、モデル設計者が意図していなかったシナリオまでをカバーする拡張は不可能であった。言い換えれば、データ・マネージャとファイル・システムとのやりとりは相対的に固定しており、各々は定義された役割を実行していた。データ・マネージャまたはファイル・システムのどちらかを除去し、それを別のコンポーネントで置き換えて他のなんらかの関数を実行しようとしても、それは困難であった。同様に、別のマネージャをシステムに入れてサブツリーの管理以外の関数を実行させようとしても、それは、不可能ではないとしても、既存のドライバ・モデルを使用して行うことが困難であった。従って、複数のコンポーネントが協力し合って入出力要求を処理できるようにし、その場合、コンポーネントの数が固定されていないで、システムの設定時に意図していなかった関数を処理する新規コンポーネントを追加するように随意に拡張または変更できるようにする方法が望まれていた。また、いずれかのコンポーネントを置き換えても、残りのコンポーネントが大きな破壊を受けないようにすることも望まれていた。
従来技術のもう１つの問題は複数のデータ・マネージャが使用されていても、名前解決プロセスに参加することが、データ・マネージャが制御権をもつネームスペースに制限されていることである。言い換えれば、複数のマウントポイントを識別するためには、複数のデータ・マネージャは各々が特定のマウントポイントを取り扱うようにインストールされていなければならない。そこで、望まれることは、単一のデータ・マネージャが複数のマウントポイントまたはサブツリーの情報を管理できるようにすることである。
以上のように、望まれていることは、複数のデータ・マネージャまたはドライバを使用して入出力要求を処理する入出力システムを動的に拡張し、再構成するメカニズムである。また、望まれていることは、そのような再構成や拡張を行っても、システム内の他のデータ・マネージャやドライバに与える影響を最小限にすることである。
発明の概要
上述した従来技術の問題は、本発明によれば、入出力システムにおける通常の処理シーケンスに割り込みをかけ、コントロール（制御権）をあるデータ・マネージャまたはドライバから別のデータ・マネージャまたはドライバに移すようにするシステムおよび方法を提供することによって解決している。本発明は、入出力要求を満たす際に、複数のデータ・マネージャまたはドライバを使用して種々の処理関数を実行するようにした入出力システムで利用すると、特に好都合である。
複数のドライバまたはデータ・マネージャが協力し合って入出力要求を満たすようにしたシステムでは、ドライバまたはデータ・マネージャは階層関係にあって、各ドライバが種々タイプの関数を実行して入出力要求を処理していることがよくある。例えば、入出力システムはファイル・システム・ドライバがデバイス・ドライバの上に置かれた階層構造になっている場合がある。この場合、入出力要求を受けると、ファイル・システム・ドライバは、ファイル名を解決し、ファイル名をディスク上の特定のロケーションに変換するといった、ある種の関数を実行している。そのあと、ディスク上の特定ロケーションはデバイス・ドライバに渡され、デバイス・ドライバはディスク上の正しいロケーションを見つけ、必要とする情報を読み書きしている。他のデバイスも、階層構造上でファイル・システム・ドライバの上か下に置かれている。例えば、望ましい方法は、ファイル・システム・ドライバとデバイス・ドライバの間に別の（冗長）ファイル・システム・ドライバを置くことである。このようすると、この冗長ファイル・システム・ドライバはデータ・ミラーリング（data mirroring）を行って、データをディスク上の複数のロケーションにミラーリング（複製）したり、データを複数のディスクにミラーリング（複製）したりできる。
従来の階層ドライバ・モデルでは、情報はある層から別の層に渡され、各層が独自の種々タスクを実行してからその要求を別の層に渡すようにしている。ケースによっては、通常の処理シーケンスに割り込みをかけて、入出力要求の少なくとも一部を処理するためのコントロールを別のドライバに渡すようにすると、非常に好都合な場合がある。例えば、おそらく重要なことは、ある種のファイルを特殊なロケーションにストアしておくことである。その特殊ロケーションにストアされたファイルへのアクセス管理は、ドライバを開発することで行うことができる。従って、ファイル・システム・ドライバが名前を特殊ロケーションに変換するとき、望ましいことは、入出力要求を通常のデバイス・ドライバに渡すのではなく、入出力要求のコントロールをその情報を処理するドライバに渡すことである。
本発明によれば、通常の処理シーケンスに割り込みをかけ、入出力要求を特定のドライバに渡すことを可能にしている。本発明の方法は動的に拡張可能であり、システムは他のドライバのオペレーションを中断することなく、ドライバを追加または除去するように構成することができる。これを達成するために、新規のディレクトリとファイル属性が定義され、これは「再解析ポイント（reparsepoint）」属性と名づけられている。この再解析ポイントは付加的属性であるので、個別ファイルとディレクトリは、再解析ポイント属性のステータスに応じて再解析ポイントにすることも、しないことも可能になっている。
再解析ポイント属性は、好ましくは、タグとデータ値の両方をもっている。タグはどのドライバが再解析ポイントの所有者であるかを示すために使用される。一般的に、再解析ポイントの所有者はその再解析ポイントが係わりをもつ入出力要求の全部または一部を処理することを受け持っている。データ値は所有者によって再解析ポイントにストアされたデータである。従って、所有者は再解析ポイントの値を使用して、再解析ポイントが係わっている特定の入出力要求を完了するために必要または役立つデータをストアすることができる。
複数の階層化ドライバを含んでいる実施形態では、ある再解析ポイントが特定のドライバによって識別されると、そのドライバはその再解析ポイントのタグとデータ値を抜き出すようになっている。入出力要求は、再解析ポイントのタグとデータ値と一緒に、あるドライバが自分がその再解析ポイントの所有者であると認識するまで他のドライバに渡されていく。その所有者はコントロールを受け取り、入出力要求の処理を再開する。再解析ポイントの所有者は、入出力要求を最後まで処理することも、他のドライバを利用して入出力要求の処理を完了させることもできる。また、所有者は他のコンピュータを利用して、入出力要求の処理を完了させることも可能である。
各再解析ポイントはタグと値の両方をもっているので、再解析ポイント・メカニズムは、任意の数のドライバが使用して任意の数の関数を達成できるようにする、非常に柔軟性のある構造になっている。例えば、ローカル・ストレージからアーカイブ・ストレージに自動的に移行されるデータを管理するために、コントロールを階層記憶マネージャに渡すことができる。別の例として、複数の異なるディスク・ドライブにストアされているファイルを管理する分散ファイル・マネージャにコントロールを渡すこともできる。さらに別の例として、コントロールをセキュア・ファイル・マネージャに渡し、セキュア・ロケーションにストアされているファイルや暗号化フォーマットでストアされているファイルを管理させることもできる。基本的には、本発明によれば、通常の処理シーケンスに割り込みをかけ、コントロールを異なるドライバに渡して特殊タイプのファイルやディレクトリの特殊処理要求を処理させることができる。このメカニズムによれば、入出力システムがもつ能力を時間と共に変化する要求に見合うように、統一された方法で拡張することができる。
本発明は、入出力システムによって通常サポートされる標準入出力オペレーション以上に入出力システムの能力を拡張できるだけの、十分な幅広さをもっている。ドライバまたはマネージャは、ある標準入出力オペレーションから得られるアクションが標準入出力オペレーションとは関係のないアクションになるように開発することができる。例えば、ホーム・オートメーション環境では、再解析ポイントは任意の数の目標を達成するために使用できる。再解析ポイントは警察署や消防署を呼び出すために使用できる。例えば、１つの可能な実装例として、再解析ポイントを設定して、警察署や消防署の電話番号を再解析ポイントの一部としてストアしておくことができる。入出力システムが再解析ポイントにアクセスすると、その再解析ポイントを所有するドライバは、上述したように処理コントロールを受け取ることになる。そのあと、所有者は該当の電話番号をリトリーブして、モデムまたは他のシステムを通してその電話番号をダイヤルし、通知、情報、音声、その他を被呼び出し側エンティティに送信することができる。本発明は他のどうような状況においても使用できるので、標準入出力オペレーションとは関係のない結果を得るために標準入出力オペレーションを使用することができる。
本発明のその他の利点は以下の説明の中で明らかにされているが、そのいくつかは以下の説明を読むことで理解できるものと、本発明を実施することで理解できるものとがある。本発明の利点は請求の範囲に具体的に記載されている種々の手段とその組み合わせによって実現し、得ることができる。本発明の上記およびその他の特徴は以下の説明および請求の範囲を読めば十分に理解できるが、以下で説明するように本発明を実施することで知得することもできる。
【図面の簡単な説明】
本発明の上述した利点およびその他の利点がどのようにして得られるかを説明するために、以下では、要約して上述した本発明を、添付図面に図示されている具体的実施形態を参照して詳しく説明することにする。なお、添付図面に図示の実施形態は本発明の代表的な実施例であり、従って、本発明の範囲を限定するものではないとの了解のもとで、以下では、添付図面を参照してより具体的にかつ詳細に本発明を説明し、解説することにする。
図１は階層化されたドライバを採用する入出力システムを示す図である。
図２は、再解析ポイント属性に出会ったときある階層ドライバから別の階層ドライバにコントロールがどのように渡されるかを示す図である。
図３は、本発明で使用するのに適しているファイルまたはディレクトリの属性を示す図である。
図４は、２つの階層ドライバによって提供されるサービスを示すと共に、本発明によってドライバに組み込まれている全体機能を示す図である。
図５は、本発明がどのように使用されて、再解析ポイントが係わりをもつ入出力要求が処理されるかを示す例である。
図６は図５に示す例のディレクトリ構造を示す図である。
図７は、別のコンピュータを使用して入出力要求を完了する場合の例を示す図である。
図８は、本発明が入出力システムの能力をどのように拡張しているかを示す図である。
好ましい実施形態の詳細な説明
以下では、本発明のシステムおよび方法を実現するために使用される実施形態の構造または処理を図面を参照して具体的に説明しながら、本発明について説明する。上記のように図面を参照して本発明を説明するが、そのことは本発明の範囲を限定するものではない。本発明が目的とする方法とシステムは、どちらも、入出力システムにおける通常の処理シーケンスに割り込みをかけ、コントロール（制御権）を別のドライバに渡して入出力要求の以後の処理をそのドライバに任せるようにしたものである。本発明の実施形態では、特殊目的または汎用目的のコンピュータを含み、そのコンピュータは中央処理ユニット（ＣＰＵ）などの標準コンピュータ・ハードウェアまたはコンピュータ実行可能命令を実行する他の処理手段、実行可能命令をストアしておくためのコンピュータ読取可能媒体、情報を表示または出力するディスプレイまたは他の出力デバイス、情報を入力するためのキーボードまたは他の入力手段、その他を装備している。本発明はコントロールをあるドライバから別のドライバに渡すことを目的としているので、本発明の範囲に属する実施形態は一般的に入出力システムをもち、この入出力システムは複数のドライバまたはデータ・マネージャを使用して入出力要求を完了するようにしている。しかし、本発明は、特に断りがない限り、コンピュータ・ハードウェア上で実行される入出力システムのタイプに制約されるものではない。
本発明の範囲に属する実施形態には、実行可能命令を格納しているコンピュータ読取可能媒体も含まれている。かかるコンピュータ読取可能媒体としては、汎用目的または特殊目的コンピュータがアクセスできる媒体ならば、どのような媒体でも利用可能である。例を挙げると、そのようなコンピュータ読取可能媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭや他の光ディスク記憶装置、磁気ディスク記憶装置、または必要とする実行可能命令をストアするために使用できて、汎用目的または特殊目的コンピュータがアクセスできる他の媒体があるが、これらに限定されるものではない。コンピュータ読取可能媒体の範囲には、上記媒体を組み合わせたものも当然に含まれる。実行可能命令の例としては、ある種の関数または関数群を汎用目的コンピュータ、特殊目的コンピュータまたは特殊目的処理デバイスに実行させるための命令とデータがある。最後に、本発明の範囲に属する実施形態には、データ構造を表す複数のデータ・フィールドをそこにストアしておくコンピュータ読取可能媒体が含まれている。
本発明の背景をもっと理解しやすくするために、以下、図１を参照して説明するが、図１はクライアント・プロセスと、入出力要求を処理するために複数のドライバ手段を使用しているオペレーティング・システムとのやりとりを単純化して示したものである。この図は、Mircosoft Windows NT（登録商標）オペレーティング・システムの場合の例を示したものである。また、図１に示すオペレーティング・システムは、入出力要求を処理するために複数のドライバ手段を使用するオペレーティング・システムならば、どのオペレーティング・システムであっても構わない。
図１に示すように、クライアント・プロセス２０は入出力要求を実行するためにオペレーティング・システム・サービス２２を利用している。これは、オペレーティング・システムに用意されているアプリケーション・プログラム・インタフェース（Application Program Interface - API）の関数をクライアント・プロセス２０がコールすることによって行われるのが代表的である。該当のＡＰＩ関数をコールすると、最終的にオペレーティング・システムのサービス２２がコールされる。このコールは矢印２４で示されている。
図１において、クライアント・プロセス２０は「ユーザ」モードで稼働するものとして示され、オペレーティング・システム・サービスは「カーネル」モードで稼働するものとして示されている。最新のオペレーティング・システムは、種々のアプリケーション・プログラムと直観的ユーザ・インタフェースのための強固な環境を提供しているのが代表的である。このようなオペレーティング・システムは、オペレーティング・システムが精巧化されているレベルと、そのオペレーティング・システムに実装されているセキュリティ機能に応じて、異なる動作レベルまたは「モード」をもっているのが通常である。通常のアプリケーション・プログラムは最低プライオリティ（優先度）で実行され、他のアプリケーションとの干渉またはオペレーティング・システムの他の層との干渉を禁止するセキュリティ・デバイスが完備されているのが代表的である。オペレーティング・システムによって提供されるハードウエアやその他のサービスは制御されたインタフェースまたはメカニズムを通してのみアクセスされるようにして、ユーザ・モードのユーザ・アプリケーションや他のプロセスがシステムを「クラッシュ」する可能性を制限している。この最低プライオリティ・モードはユーザ・モードと呼ばれているのが普通で、大部分のコンピュータ・ユーザに親しみのあるモードである。ドライバとその関連ハードウェアは緊密に統合化されているため、また多くのドライバが実行するタスクはその性質上時間を重視しているため、ドライバはプライオリティがはるかに高く、セキュリティ保護がはるかに低いオペレーティング・システムのモードで実行されるのが代表的である。このモードは「カーネル」モードと呼ばれているのが一般である。ドライバおよび他のオペレーティング・システム・サービスをカーネル・モードにすると、オペレーティング・システムをより高いプライオリティで稼働させ、ユーザ・モードでは不可能である多数の関数を実行させることができる。
クライアント・プロセス２０が入出力要求を実行するためにオペレーティング・システム・サービス２２をコールすると、その入出力要求は入出力要求を処理する第１のドライバ手段に渡される。図１では、ファイル・システム・ドライバ２６とデバイス・ドライバ２８は入出力要求を処理するドライバ手段の例を示している。入出力要求が第１ドライバ手段にどのように渡されるかは、例えば、矢印３０で図１に示されている。ファイル・システム・ドライバ２６は入出力要求を受け取ると、入出力要求の一部を処理してからその入出力要求を次のドライバに渡すのが一般的である。本発明で「入出力要求」というときは、入出力システムがサポートする、どのタイプの入出力オペレーションも含まれる。なお、この中には、入出力システムに通常関連している通常のファイル・オペレーション以上のものが含まれることはもちろんである。また、この用語には、入出力システムの拡張機能も含まれる。従って、「入出力要求」という用語は広い意味で解釈されるものである。
１つの例として、クライアント・プロセス２０がディスク上の特定のファイルをオープンして、そのファイルから情報をリトリーブすることを望んでいるとする。この場合、入出力要求はクライアント・プロセス２０からオペレーティング・システム・サービス２２に渡されてからファイル・システム・ドライバ２６に渡される。そのあと、ファイル・システム・ドライバ２６は入出力要求をファイル名からディスク上の特定のロケーションに変換する。この変換プロセスには、特定ロケーションでディスクに読み書きされるデータ・ブロックの数を含めておくことも可能である。この場合、この情報は、例えば、デバイス・ドライバ２８のような、次のドライバに渡すことができる。デバイス・ドライバ２８が必要とする情報を渡すプロセスは図１に矢印３２と３４で示されている。デバイス・ドライバ２８は、読み書きされるデータ・ブロックのロケーションと数を受け取ると、それらを該当の制御信号に変換して必要とする情報をハードウェア・デバイス３６からリトリーブし、あるいは必要とする情報をそこにストアする。リトリーブされた情報はデバイス・ドライバ２８からファイル・システム・ドライバ２６に渡され、最終的には戻り矢印３８に示すようにクライアント・プロセス２０に戻されることになる。ステータス情報も同じように戻される。
図１では、入出力要求はファイル・システム・ドライバ２６とデバイス・ドライバ２８の間で直接に受け渡しされていない。むしろ、入出力要求は入出力マネージャ４０を介してドライバ相互間で受け渡しされている。しかし、どの実装でも入出力マネージャが存在している必要はない。入出力要求があるドライバから別のドライバに直接に渡されるようにする実施形態も可能である。
図１から理解されるように、重要な概念の１つは入出力要求がクライアント・プロセスによって作成されたとき、従来システムでの処理シーケンスが相対的に固定され、未変更のままになっていることである。言い換えれば、特定タイプの入出力要求はそのタイプの入出力要求が受け取られるたびに、まったく同じように処理されることである。入出力要求は最初にあるドライバに渡され、そこで部分的処理が行われてから、その入出力要求は別のドライバに転送され、そこでも入出力要求が部分的に処理されている。一般的に、このプロシージャは、各ドライバが後続のドライバに入出力要求を渡していき、入出力要求が最終的に処理されるまで続けられる。従来のシステムでは、通常の処理シーケンスに割り込みをかけ、コントロールを直前のドライバに戻すか、あるいは特殊タイプの入出力要求を処理する別のドライバに渡すようになっていない。
次に図２を参照して説明すると、図は本発明を実現しているシステムの概要図を示したものである。この場合も、クライアント・プロセス２０は矢印２４に示すように最終的にオペレーティング・システム・サービス２２に転送される入出力要求を行っている。本発明の入出力システムはそのような入出力要求を処理する複数のドライバ手段を含んでいる。例えば、図２では、かかるドライバ手段は層１のドライバ４２、層２のドライバ４４および層Ｎのドライバ４６で示されているが、これらは単なる例示である。
入出力要求はあるドライバ手段から別のドライバ手段に渡されるので、本発明の範囲に属する実施形態では、入出力要求をあるドライバから別のドライバに渡す手段を含めることができる。例えば、図２では、そのような手段は矢印４８と５０で示され、入出力要求があるドライバから別のドライバに直接に渡される様子を示している。この手段としては、図１に示すものと同じように、入出力要求をあるドライバから別のドライバに転送することを取り扱う入出力マネージャにすることも可能である。
図２に示すように、入出力マネージャ４０はクライアント・プロセス２０から受け取った入出力要求を層１のドライバ４２に転送している。この入出力要求は該当の情報を該当のドライバに転送する入出力マネージャや他のメカニズムによってコールされる関数またはサービスの形にすることができる。Microsoft Windows NT（登録商標）では、例えば、入出力システムの種々ドライバ間の通信のためにメッセージ駆動型メカニズムが使用されている。このシステムでは、入出力要求を行うと、入出力マネージャは入出力要求パケット（I/O request packet - IRP）を作成し、そのＩＲＰを該当のドライバに送っている。入出力要求が処理され、他のドライバに転送されるとき、情報がＩＲＰに追加され、そのＩＲＰが次のドライバに渡される。状況によっては、ＩＰＲが修正または「別の形に変換」されてから次のドライバに渡される場合もある。Microsoft Windows NT（登録商標）では、入出力マネージャはドライバ間でＩＲＰを転送することを担当している。他のシステムでは、他のメカニズムが使用可能になっている。これらをどのように実装するかの詳細は設計上の問題であり、本発明にとっては重要でない選択事項である。
図２に戻って説明すると、層１のドライバ４２が必要とされる処理を実行すると、入出力要求は層２のドライバ４４に渡され、そこで必要な処理が行われたあと、その入出力要求は次のドライバに転送される。なお、図２には各ドライバが入出力要求を順番に受け取ることが示されているが、実施形態によっては、あるドライバをスキップして、入出力要求を処理させる必要のあるドライバだけに入出力要求を実際に処理させることが望ましい場合がある。
本発明は通常の処理シーケンスに割り込みをかけ、コントロールを別のドライバに渡すシステムおよび方法を提供しているので、本発明の実施形態によれば、入出力要求の処理に割り込みをかける手段が含まれている。図２に示すように、そのような手段は、例えば、層Ｎのドライバ４６に組み込むことが可能である。本発明では、通常の処理シーケンスは特殊タイプのファイルまたはディレクトリが入出力要求を処理している途中で現れたとき割り込みがかけられる。このような特殊ファイルまたはディレクトリは「再解析ポイント（reparse point）」と呼ばれる。以下で詳しく説明するように、再解析ポイントは特殊な再解析ポイント属性をファイルまたはディレクトリに含めることで作成される。この特殊な再解析ポイント属性はその入出力要求の実行時にドライバによって認識される。この属性が認識されると、入出力要求を処理する通常シーケンスは一時中止され、入出力要求の処理を完了するためのステップがとられる。このステップでは、入出力要求を処理するコントロールが別のドライバに渡され、そのドライバが特殊タイプのファイルまたはディレクトリの入出力要求の処理に参加できるようにされる。従って、本発明の範囲に属する実施形態では、入出力要求を処理するコントロールをあるドライバから別のドライバに渡すための手段が含まれている。入出力要求の処理が途中で割り込まれたとき、コントロールを入出力要求を処理中のドライバから別のドライバに渡すメカニズムならば、どのメカニズムでも利用可能である。図２には、このメカニズムは、例えば、矢印５２で示され、入出力要求の処理の途中で再解析ポイントが現れたとき、入出力要求を処理するコントロールが層Ｎのドライバ４６から層１のドライバ４２に渡されることが示されている。以下で詳しく説明するように、コントロールをあるドライバから別のドライバに渡すメカニズムに要求されることは、ある種の情報を渡して、コントロールを受け取ったドライバが再解析ポイントを正しく処理できるようにすることである。従って、実施形態には、再解析ポイント情報を受け渡すための手段とステータス情報を受け渡すための手段を含めることも可能である。これらのメカニズムは以下で詳しく説明する。
コントロールが層Ｎのドライバ４６から層１のドライバ４２に渡された後、層１のドライバ４２は入出力要求の処理を進めるために再解析ポイントを正しく処理しなければならない。ある種の状況および実施形態では、再解析ポイントが現れたときコントロールを受け取ったドライバは入出力要求を自分で最後まで処理できる場合もある。
そのような状況では、ドライバが入出力要求を最後まで処理した後、結果および／またはステータス情報が必要に応じてクライアント・プロセスに戻されることになる。そのような結果の例を示したのが図２であるが、そこでは層１のドライバ４２は層１のドライバ４２から出た矢印５０で示すように入出力要求の結果を戻している。他方、再解析ポイントが現れたとき入出力要求を最後まで処理する場合でも、他のドライバの援助が必要になる場合がある。従って、本発明の範囲に属する実施形態では、オリジナル入出力要求の処理を継続するために第２の入出力要求を作成するための手段を含めることができる。図２に示すように、このような手段は、例えば、層１のドライバ４２に組み込んでおくことができる。層１のドライバ４２は第２の入出力要求を初めから作成することも、例えば、オリジナル入出力要求を別の形に変換してからその入出力要求を別のドライバに転送することもできる。例えば、Microsoft Windows NT（登録商標）では、このような手段は新しいＩＲＰを作成し、そのＩＲＰを該当のドライバに渡すことによって実現されている。また、この手段は既存のＩＲＰを別の形に変換してからそのＩＲＰを別のドライバに渡すことによっても実現できる。図２では、かかる手段は、例えば、矢印５４で示されており、そこでは作成された入出力要求が層１のドライバ４２から層２のドライバ４４に、最終的に層Ｎのドライバ４６に渡されることが示されている。図７を参照して以下で説明するように、入出力要求を最後まで処理するためには、他のコンピュータによる処理が必要になる場合がある。従って、第２の入出力要求を作成する手段は入出力要求を他のコンピュータに転送することもできる。
層１のドライバ４２が該当の再解析ポイントの処理を終え、オリジナル入出力要求の処理を終えるために別の入出力要求を作成したとすると、層Ｎのドライバ４６はその第２入出力要求を受け取り、該当のハードウェア５６とのインタフェースとなってオリジナル入出力要求を完了することができる。その結果は矢印５０で示すように入出力マネージャ４０に、最終的には矢印５８で示すようにクライアント・プロセスに戻すことができる。
以上を要約すると、本発明は、入出力要求を処理する通常のシーケンスに割り込みをかけて、通常では入出力要求の処理に関与していないドライバが入出力要求の処理に介入できるようにするシステムと方法を提供している。以下で詳しく説明するように、このようなメカニズムはある種の特殊タイプのファイルやディレクトリを実装するときに利用すると、非常に便利である。本発明では、ファイルまたはディレクトリのどちらかに関連づけられた再解析ポイント属性のメカニズムを使用して、通常の処理シーケンスに割り込みをかけ、再解析ポイントを処理するコントロールを特定のドライバに渡すようにしている。このドライバは入出力要求の処理を完了することも、他のドライバを使用して入出力要求の処理を終了するために別の入出力要求を作成することもできる。以下で詳しく説明するように、このメカニズムによると、入出力システムが初めて開発されたとき意図していなかった状況に対処するように、統一された方法で既存の入出力システムの能力を拡張することができる。このように柔軟性があるため、時間と共に進化していく、先進的ファイルとディレクトリ編成構造をサポートする能力が強化されることになる。
その開発当時、ＵＮＩＸオペレーティング・システムは単純化した新しい見方で入出力を定義していた。読み書きされるデータはすべて、仮想ファイルに送られる単純なバイトの流れとして扱われ、仮想ファイルはファイル記述子で表されていた。仮想ファイルとは、あたかもファイルとして扱われる入出力のソースまたはデスティネーションのことである。同様に、ファイルとディレクトリは区別されていなかった。ディレクトリは単純に特殊タイプのファイルとして見られていた。最新のオペレーティング・システムはこの基本的考え方を発展させ、そこではファイルとディレクトリは単純な「属性」の集まりと考えられている。属性は、最も抽象化されたレベルでは、単にデータ記憶ロケーションである。あるファイルまたはディレクトリの異なるプロパティを指定するために異なる属性が使用され、あるいは異なる情報ビットを格納するために異なる属性が使用され、オペレーティング・システムまたは他のプロセスがファイルまたはディレクトリを扱う必要のあるとき、そのファイルまたはディレクトリに関するある種の情報を知ることができるようにしている。例えば、ファイルはプロセスがファイルを特定できるようにする名前属性と、そのファイルにストアされたデータであるデータ属性をもつことができる。ファイルは、次のような他の属性をいくつでももつことができる。つまり、だれがファイルにアクセスでき、どのようにアクセスできるかを示すセキュリティ属性、タイムスタンプ属性、ファイルがどのディレクトリに格納されているかを示す属性などである。ディレクトリも、同じ種類の属性をもつことができるが、ディレクトリはユーザが大量のデータをストアできる場合にはデータ属性をもたないのが普通である。
次に図３を参照して説明すると、図は、本発明で使用するのに適しているファイルまたはディレクトリの属性を絵図で示したものである。これらの属性は、特にMicrosoft Windows NT（登録商標）用に開発されたＮＴＦＳファイル・システムで使用されている属性リストの修正版を示している。ＮＴＦＳファイル・システムは、Helen Custer著「インサイドWindows NTファイル・システム（Inside the Windows NT File System）」、Microsoft Press発行に詳しく説明されているが、その内容は引用により本明細書の一部を構成するものである。図３に示すように、ファイルまたはディレクトリを構成する属性は基本的に２つのグループに分類できる。第１の基本グループは全体が６０で示されており、ファイルとディレクトリの両方に共通の属性を表している。第２の基本グループは全体が６２で示されており、ファイルに固有の属性（図中の左側）またはディレクトリに固有の属性（図中の右側）を含んでいる。
ファイルとディレクトリの両方に共通の属性グループに属するものには、標準情報属性６４、属性リスト６６、名前属性６８、セキュリティ記述子属性７０および再解析ポイント属性７２がある。標準情報属性６４は、次のような“MS-DOS”の標準属性を表している。つまり、ファイルの場合の読取専用、読み書き、隠蔽など、ファイルまたはディレクトリのタイムスタンプ、いくつのディレクトリがファイルをポイントしているか、といった属性である。属性リスト６６は、ファイルまたはディレクトリがマスタファイル・テーブルに占める記憶レコードが２つ以上になったとき、ファイルまたはディレクトリを構成する追加属性のロケーションを特定するためにＮＴＦＳによって使用される属性である。マスタファイル・テーブルは、ファイルまたはディレクトリのすべての常駐属性がそこにストアされるロケーションである。名前属性６８はファイルまたはディレクトリの名前である。ファイルまたはディレクトリは、ＮＴＦＳでは複数の名前属性をもつことができる。例えば、長い名前、MS-DOSでの短い名前、などである。セキュリティ記述子属性７０は、だれがファイルまたはディレクトリを所有し、だれがそれにアクセスできるかを指定するためにWindows NT（登録商標）で使用されるデータ構造を含んでいる。これらの属性は前掲の「インサイドWindows NTファイル・システム」に詳しく説明されている。
再解析ポイント属性７２は本発明で追加された新規属性である。再解析ポイント属性７２はある特定ファイルまたはディレクトリが、入出力システム内の特定ドライバによる特殊処理を必要とする再解析ポイントであることを示している。再解析ポイントは、好ましくは、２つの目標が達成できるだけの十分な情報を収めている。第１の目標は、再解析ポイントを処理させる特定ドライバ（再解析ポイントの所有者）が特定できるようにすることである。さらに、最大限の柔軟性を得るために、好ましいことは再解析ポイントの所有者が再解析ポイントと一緒にデータをストアしておき、所有者があとでそのデータを使用して、再解析ポイントを正しく処理できるようにすることである。ある実施形態では、再解析ポイント属性は次のような構成になっている。
再解析ポイントは特定のドライバによって処理されるので、本発明の範囲に属する実施形態によれば、特定のドライバを再解析ポイントが係わっている入出力要求の少なくとも一部を処理させるドライバとして特定するための手段が含まれている。そのような手段としては、特定のドライバを再解析ポイントの所有者として特定するメカニズムならば、どのメカニズムでも使用が可能である。再解析ポイント属性が上記テーブルに示す構造になっていれば、この手段は、例えば、タグ値を含むことができる。上に示す再解析ポイントでは、タグは再解析ポイントの所有者のＩＤを収めているデータワードである。好ましい方法は、ドライバがどのシステムにインストールされているかに関係なく、同じタグが常に同じ所有者ドライバに関連づけられるようにタグが割り当てられるようにすることである。言い換えれば、好ましいことはタグ値を特定のドライバに割り当てる、なんらかのメカニズムが存在していることである。そのような例として、タグ値のブロックを種々のドライバ・メーカに割り当てる中央レポジトリまたはクリアリングハウスがある。そのようにすれば、ドライバ・メーカはタグを個々のドライバに割り当てることができる。他にも使用できるメカニズムとして、タグ値を多くても１つのドライバと関連づけることを可能にするメカニズムがある。タグ値をこのように割り当てると、ドライバがどのシステムにインストールされているかに関係なく、同じ所有者ドライバに同じ再解析ポイントを処理させることが可能になる。事情によっては、ローカルのタグ値をダイナミックに割り当てて、タグ値がインストール時にシステムによって割り当てられるようにする別の方法も可能である。しかし、この方法にはいくつかの問題があり、そのような理由から、一般的には好ましい方法ではない。
上記テーブルに示す再解析ポイント属性では、再解析ポイント・フラグが示されているが、これはオプションである。再解析ポイント・フラグが上に示されているのは、どのファイルまたはディレクトリが再解析ポイントであるかを特定できるようにするメカニズムの存在が必要であることを示すためである。このような指示は、例えば、有効な再解析ポイント属性を示す再解析ポイント・フラグを使用することで与えることができる。上記とは別に、他のメカニズムを使用することも可能である。例えば、ファイルまたはディレクトリが再解析ポイントでないことを示すために、１つまたは２つ以上のタグ値を予約しておくことも可能である。このようなメカニズムを使用すると、ファイルまたはディレクトリが再解析ポイントでないことを示すために、例えば、タグ０を予約しておくことが可能になる。
上に示した再解析ポイント属性は所有者制御（owner controlled）データ・フィールドも含んでいる。この所有者制御データ・フィールドは、再解析ポイントの所有者が再解析ポイントを正しく処理するために必要とされる、任意のタイプのデータをそこに置いておくことができるロケーションを示している。例えば、所有者がファイルまたはディレクトリの種々属性をリモートにストアすることを扱っていれば、ある種の属性がリモートにストアされるとき、リモートにストアされた属性のロケーションは再解析ポイント属性のデータ・フィールドにストアしておくことができる。
上に示した再解析ポイント属性では、データ・フィールドの前にデータ長インジケータが置かれている。このストレージ・フォーマットでは、データ・フィールドの長さは、データ・フィールドを完成するためにどれだけのデータを読み取る必要があるかを確かめるためにストアされている。別の方法として、実施形態によっては、固定長のデータ・フィールドまたはポインタまたはリンクで１つに連鎖された情報ブロックを使用するデータ・フィールドをストアしておくと、効率化する場合がある。基本的には、データ・フィールドを完成するためにどれだけのデータを読み取る必要があるかを確かめるメカニズムならば、どのメカニズムでも使用できる。所有者ドライバにどれだけのデータをストアさせるかについても考慮しておく必要がある。このような考慮はデータ・フィールドがストアされるときの方法およびデータ・フィールドの可能とされる最大長にも影響することになる。
図３に戻って、次にグループ６２について説明する。そこでは、ファイルで使用される属性とディレクトリで使用される属性との相違点が示されている。ファイルは図３にデータ属性７４で示すように、１つまたは２つ以上のデータ属性をもっているのが代表的である。データ属性７４はユーザ制御データをそこにストアできるロケーションを表している。これはユーザまたはユーザ・プロセスがそこにデータをストアする属性である。ユーザ・プロセスは他の属性にアクセスして、そこにデータをストアできるが、これらの属性はユーザ・プログラムによってだけでなく、ドライバのような他のシステム・リソースによっても理解されるのが一般的である。しかし、ドライバはデータ属性にストアされたデータを理解したり、扱ったりしないのが一般的である。ＮＴＦＳファイル・システムのような、ある種のファイル・システムは２つ以上のデータ属性をもつことが可能になっている。
データ属性７４のほかに、ファイルは他の属性７６で示すように、他の属性をもつこともできる。このような属性はファイルと共にストアされる、他の任意の属性を表している。システムによっては、ユーザ定義の属性を許しているものもあるが、その場合には、他の属性７６はユーザが定義して、ストアした任意の数またはタイプの属性を表している。
ディレクトリで使用される属性としては、例えば、インデックス・ルート属性７８、インデックス・アロケーション属性８０、およびビットマップ属性８２がある。これらの属性の詳しい説明は前掲の文献「インサイドWindows NTファイル・システム」に記載されているが（なお、その内容は引用により本明細書の一部を構成するものである）、基本的にはインデックス・ルート属性７８はディレクトリに格納されたファイルへのインデックスを収めており、インデックス・アロケーション属性８０はデータ・ブロックまたは「クラスタ」のマッピングに関する情報を収めており、ビットマップ属性８２はどのクラスタが使用中で、どのクラスタが解放されているかを記録している。他の属性も、他の属性８４で示すように、ディレクトリの一部として定義して、ストアすることができる。
ある特定タイプのファイルまたはディレクトリに関して若干詳しく上述してきたが、以上の説明は単なる例示的なものであり、本発明の範囲を限定するものではない。本発明は、ファイルまたはディレクトリの既存属性に再解析ポイント属性が追加されていれば、どのタイプのファイルまたはディレクトリでも有効である。別の方法として、既存属性を本発明に取り入れても、その既存属性を利用しても、再解析ポイント属性情報をストアすることができるので、この方法によっても、ファイルまたはディレクトリ内の既存属性の数を増やすことなく再解析ポイント属性を含めることが可能である。
次に、図４を参照して説明すると、図は入出力要求を処理する複数のドライバ手段を含んでいる入出力システムの詳細を示す図である。図４に示す入出力システムはMicrosoft Windows NT（登録商標）で利用されているものと同じ入出力システムにすることができる。入出力要求を処理するために複数のドライバ手段を使用する他のオペレーティング・システムも、同じような構成にすることが可能である。図４を参照して説明する概念は、入出力要求を処理する複数のドライバ手段を含んでいるシステムならば、どのシステムを使用しても実装することが可能である。図４に示す構造の使用は１つの可能な実装例を示したにすぎず、本発明の範囲を限定するものではない。
図４に示す実施形態では、入出力要求を処理する複数のドライバ手段が含まれている。図４において、そのようなドライバ手段は、例えば、全体を８６で示すドライバＡと全体を８８で示すドライバＢで示されている。また、本発明の範囲に属する実施形態では、入出力要求をあるドライバから別のドライバに渡す手段も含まれている。図４には、１つの例として、かかる手段は入出力マネージャ９０として示されているが、これに限定されるものではない。入出力マネージャ９０は、例えば、入出力システムで使用される複数のドライバ間で入出力要求を転送することを受け持つマネージャの代表例である。前述したように、実施形態によっては、入出力マネージャを利用していないものがあり、そこでは種々ドライバは直接に通信し合っている。このような実施形態では、入出力要求をあるドライバから別のドライバに渡す手段は、あるドライバが入出力要求を別のドライバに直接に渡すために使用されるメカニズムになっている。
図４に示すように、ドライバＡ ８６とドライバＢ ８８は、種々の関数を実行するために入出力マネージャ９０がアクセスできるサービスまたはルーチン群を提供している。図４に示すルーチンは利用できるルーチンのうち、Microsoft Windows NT（登録商標）の下で動作するドライバがもつことができる部分を示している。種々ルーチンに関する詳しい説明は、前掲のHelen Custer著「インサイドWindowsNT」、Microsoft Press発行に記載されており、その全内容は引用により本明細書の一部を構成するものである。
ある種のルーチンはドライバＡ ８６とドライバＢ ８８のどちらの場合も、類似の関数を実行している。これらのルーチンの正確な詳細は非常に異なることがあっても、ルーチンの全体目標は同じである。ドライバＡ ８６とドライバＢ８８のどちらの場合も類似の関数を実行するルーチンには、次のものがある。初期化ルーチン９２、スタートＩ／Ｏルーチン９４、割り込みサービス・ルーチン９６、遅延プロシージャ・コール・ルーチン９８、キャンセルＩ／Ｏルーチン１００およびアンロード・ルーチン１０２である。これらのルーチンはドライバがMicrosoft Windows NT（登録商標）などのオペレーティング・システムの下で動作するときに重要であるが、本発明では、一般的には、その目的上重要ではない。しかし、これらのルーチンの機能について、以下で簡単に説明することにする。
ドライバＡ ８６とドライバＢ ８８はどちらも初期化ルーチン９２をもっている。初期化ルーチンはドライバごとに異なることがあっても、初期化ルーチンは、入出力マネージャがドライバをオペレーティング・システムにロードするとき入出力マネージャによって実行される。このルーチンは必要とされる初期化を行って、入出力マネージャがドライバを使用し、アクセスできるようにする。スタートＩ／Ｏルーチン９４はデバイスとの間でやりとりされるデータの転送を開始するために使用される。割り込みサービス・ルーチン９６はドライバが特定ドライバに割り込みを引き起こしたときコールされる。Windows NT（登録商標）の下では、割り込みサービス・ルーチンでの処理は、低レベルの割り込みが必要以上にブロックされるのを防止するために最小限に保たれている。遅延プロシージャ・コール・ルーチン９８は、割り込みサービス・ルーチンが実行された後で、デバイス割り込みを取り扱うことに関係する処理の大部分を実行する。キャンセルＩ／Ｏルーチン１００は入出力オペレーションをキャンセルする必要が起こったときコールされる。アンロード・ルーチン１０２はシステム・リソースを解放して、入出力マネージャがドライバをメモリから除去できるようにする。
Microsoft Windows NT（登録商標）の下のドライバは、ドライバＡ ８６のディスパッチ・ルーチン１０４およびドライバＢ ８８のディスパッチ・ルーチン１０６といった、ディスパッチ・ルーチン群を含んでいる。ディスパッチ・ルーチンはデバイス・ドライバから提供されるメイン関数である。例をいくつか挙げると、読み書き関数や、デバイス、ファイル・システム、またはネットワークのドライバがサポートするその他の機能がある。入出力オペレーションがドライバによって処理されるとき、入出力マネージャ９０は入出力要求パケット（I/O Request Packet - IRP）を生成し、ドライバのディスパッチ・ルーチンの１つを通してドライバをコールする。従って、入出力要求は図４に示すように、ドライバ相互間でまたは入出力マネージャとドライバの間で受け渡しされるＩＲＰで表すことができる。
複数のドライバが使用されるときは、あるドライバは入出力要求の部分的処理を行ってからそのあとに続くドライバにその入出力要求を渡すことができる。このようなプロセスを示したのが図４であり、そこではＩＲＰ １０８がドライバＡ ８６に渡され、ＩＲＰ処理ブロック１１０で示すようにドライバＡによって部分的に処理され、ＩＲＰ １１２を通してドライバＢ ８８に渡されている。なお、ＩＲＰ １０８とＩＰＲ １１２は同じＩＲＰであっても構わない。しかし、ＩＲＰがドライバ間でどのように受け渡しされるかを分かりやすくするために、図４には別の番号が付けられている。また、ＩＲＰ １０８とＩＲＰ １１２が別のものとなるように新しいＩＲＰを作成する実施形態にすることも可能である。
関連の再解析ポイント属性をもつファイルまたはディレクトリの処理と係わりのない入出力要求であるときは、ドライバはその入出力要求を通常通りに処理して、入出力要求に関連する情報を通常通りに返却する。例えば、ＩＲＰ １１２がドライバＢ ８８によって受信されると、その入出力要求はＩＲＰ処理ブロック１１６によって通常通りに処理される。入出力要求を処理している途中で、ドライバＢ ８８はステータス情報および／またはＩＲＰをその前に置かれたドライバに戻すことがある。これは図４にＩＲＰ １１８とステータス１２０で示されている。図４に示されていないが、ＩＲＰ １１８および／またはステータス１２０はドライバＢ ８８による処理の後ドライバＡ ８６に戻される場合がある。これは通常の入出力処理の一部であり、前掲の「インサイドWindows NT」に詳しく解説されているが、その内容は引用により本明細書の一部を構成するものである。
ＩＲＰがドライバによって受信されたとき、ＩＲＰで表された入出力要求は関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている場合がある。図２を参照して前述したように、関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている入出力要求が現れたときは、通常の入出力要求処理に割り込みがかけられ、コントロールは別のドライバに移される。このプロセスを行うために、本発明の範囲に属する実施形態では、入出力要求の処理に割り込みをかける手段が含まれている。このような手段としては、関連の再解析ポイントをもつファイルまたはディレクトリが係わっている入出力要求であるとドライバが認識したとき、その入出力要求の処理を途中で終了してコントロールが別のドライバに渡されるようにするメカニズムならば、どのようなメカニズムであっても構わない。図４には、この手段は、例えば、再解析ポイント検出ブロック１１４で示されている。
入出力要求が関連の再解析ポイント属性をもつファイルまたはディレクトリと係わりがあると再解析ポイント検出ブロック１１４が判断したときは、通常の入出力要求処理は中止され、入出力要求処理責任を再解析ポイントの所有者に引き渡すステップがとられる。図４に示すように、これらのステップは再解析ポイント処理ブロック１２２によって実行される。
再解析ポイント処理ブロック１２２は、コントロールを現在のドライバから再解析ポイントの所有者に引き渡し、再解析ポイントの所有者が入出力要求の処理を継続できるようにするために必要な前処理を実行する。例えば、再解析ポイント属性が前述したようにタグとデータ・フィールドを含んでいれば、再解析ポイント処理ブロック１２２はそのタグとデータ・フィールドを再解析ポイント属性から抜き出し、それらを再解析ポイントの所有者に転送する準備状態に置くことができる。従って、本発明の範囲に属する実施形態では、再解析ポイント情報をドライバに渡すための手段を含めることができる。例えば、図４にはこの手段は解析データ１２４で示されているが、これに限定されるものではない。再解析データ１２４は再解析ポイント処理ブロック１２２で抜き出された再解析情報を表しているだけである。実施形態によっては、再解析ポイント属性を抜き出し、それを再解析ポイントの所有者に直接に渡すようにすることも可能である。基本的には、再解析ポイントの所有者が再解析ポイント属性にストアされた情報にアクセスすることを可能にするメカニズムならば、どのメカニズムでも再解析ポイント情報をドライバに渡す手段として利用することができる。この中には、再解析ポイント情報がそこにストアされているロケーションまたは再解析ポイント属性そのものを指すポインタを渡すことも含まれる。ある実施形態では、再解析データ１２４はＩＲＰに入れられて、別のドライバに渡されている。
以下で詳しく説明するように、ドライバが再解析ポイント情報を調べるとき好ましいことは、再解析ポイントが現れたことをドライバが即時に知ることができるようにすることである。従って、望ましいことは再解析ポイントが現れたことを示すステータス情報を渡すことである。従って、実施形態には、ステータス情報をあるドライバから別のドライバに渡す手段を含めることができる。図４にはこの手段は、例えば、ステータス１２６で示されている。なお、ステータス１２６は単独で渡すことも、解析データ１２４と結合してＩＲＰに入れ、ユニットとして渡すことも可能である。同様に、ステータス情報をＩＲＰに入れ、解析データ１２４を指すポインタまたはリンクをＩＲＰに入れることができる。もう１つの例として、ステータス１２６を渡した後、若干時間を置いてから再解析データを別のＩＲＰに入れて渡すようにすることも可能である。
関連の再解析ポイントをもつファイルまたはディレクトリが係わっている入出力要求であると分かったときは、入出力要求を処理する責任はあるドライバから別のドライバに移される。従って、本発明の範囲に属する実施形態では、入出力要求を処理するコントロールをあるドライバから別のドライバに移すための手段が含まれている。図４に示す実施形態では、この手段は、例えば、完了ルーチン１２８になっている。Windows NT（登録商標）オペレーティング・システム用に書かれたドライバは低レベルのドライバがＩＲＰの処理を終えたあと入出力マネージャによってコールされる１つまたは２つ以上の完了ルーチンを含んでいる場合がある。例えば、ファイル・システム・ドライバとデバイス・ドライバをもつ実施形態では、入出力マネージャは、デバイス・ドライバがファイルとの間でデータ転送を終えたあとファイル・システム・ドライバの完了ルーチンをコールするようになっている。完了ルーチンはオペレーションが成功したか、失敗したかあるいはキャンセルされたかをファイル・システム・ドライバに通知し、ファイル・システムがクリーンアップ（終結処置）オペレーションを実行できるようにしている。従って、通常処理のとき、ドライバＢ ８８がＩＲＰ １１２を受け取り、それを最後まで処理し、ＩＲＰ １１８を戻すと、入出力マネージャ９０はブロック１２８で完了ルーチンをコールし、完了ルーチンは入出力オペレーションが成功したか、失敗したかをドライバＡ ８６に通知し、ドライバＡ ８６がクリーンアップ処理を実行できるようにする。
入出力マネージャ９０は低レベルのドライバがその処理を完了したとき完了ルーチンをコールするので、その完了ルーチンは、関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている入出力要求処理のコントロールが移転したことを検出するメカニズムを置いておく理想的な場所になっている。従って、完了ルーチン１２８は再解析データ１２４および／またはステータス１２６を調べ、ドライバＡ ８６が再解析ポイントの所有者であり、入出力要求の処理責任を任せるべきかどうかを確かめるようになっている。
しかし、関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている入出力要求の処理責任をドライバが引き受ける前に、そのドライバはそれが再解析ポイントの所有者であるかどうかを確かめなければならない。本発明の範囲に属する実施形態では、特定のドライバによって受信された再解析ポイント情報がそのドライバによって所有されているかどうかを確かめる手段を含めることができる。例えば、図４にはこの手段は再解析ポイント検出ブロック１３０で示されているが、これに限定されるものではない。再解析ポイント検出ブロック１３０は再解析データ１２４および／またはステータス１２６を調べ、ドライバＡ ８６が再解析ポイントの所有者であるかどうかを確かめる。ドライバＡ ８６が再解析ポイントの所有者でなければ、ドライバＡ ８６は完了処理ブロック１３２で示すように、必要とされる通常完了処理を実行し、再解析データ１２４および／またはステータス１２６を入出力マネージャ９０に渡し、そこから別のドライバに転送されるようにする。
他方、ドライバＡ ８６が再解析ポイントの所有者であると再解析ポイント検出ブロック１３０が判断したときは、コントロールは再解析ポイント処理ブロック１３４に渡され、入出力要求の以後の処理が行われる。入出力要求の処理コントロールを受け取ること以外は、ドライバが自身が再解析ポイントの所有者であると判断されたときなにが行われるかは、本発明では未定義である。しかし、一般的には、ドライバは入出力要求の処理責任を引き受けて、入出力要求を完了させるステップをとることになる。ある実施形態では、再解析ポイントの所有者であるドライバは、入出力要求の処理を最後まで行うことが可能になっている。そのような実施形態では、ドライバが入出力要求の処理を終えると、通常の完了手続きがとられることになる。Microsoft Windows NT（登録商標）の場合には、この中には、必要な情報をＩＲＰに入れて入出力マネージャに送り返し、そこから転送されることが含まれている。上位レベルのドライバの完了ルーチンをコールして、ドライバに必要なクリーンアップ処理を行わせたり、入出力要求のステータスをドライバに通知したりすることを含めることも可能である。
実施形態によっては、再解析ポイントの所有者であるドライバは入出力要求の残り部分を単独で最後まで処理できない場合がある。そのような実施形態では、再解析ポイント処理ブロック１３４はＩＲＰを生成し、そのあとＩＲＰは他のドライバに渡されて入出力要求の処理を続けるようにしている。別の方法として、図７を参照して説明するように、入出力要求を生成したあと、別のコンピュータに渡して以後の処理を行わせることも可能である。従って、本発明の範囲に属する実施形態では、オリジナル入出力要求の処理を継続するために別の入出力要求を作成する手段を含めることが可能である。そのような手段としては、他のドライバの援助を得て入出力要求を完了するために特定の実施形態で利用されるメカニズムが利用できる。例えば、図４には、別の入出力要求を作成する手段は再解析ポイント処理ブロック１３４とＩＲＰ １３６で示されている。ＩＲＰ １３６は、例えば、図４のドライバＢ ８８と同じように、別のドライバに渡すことができる。ドライバＢ ８８はＩＲＰ １３６を受け取ると、それを他のＩＲＰと同じように処理する。再解析ポイント処理ブロック１３４はＩＲＰ １３６を作成するとき、そのＩＲＰを初めから作ることも、既存のＩＲＰを受け取ってそのＩＲＰを「別の形に変換」することもできる。この変換プロセスは既存のＩＲＰを受け取ると、そのＩＲＰ内の情報を変更して修正版または新規ＩＲＰを作成する。別の入出力要求を作成する手段はシステムが異なるごとに、異なる方法で実装することができる。例えば、あるドライバが別のドライバを直接にコールするようなシステムでは、別の入出力要求を作成する手段は、情報がアセンブルされたあと、直接コール・メカニズムを通して別のドライバに渡されるようにするメカニズムにすることができる。基本的には、必要なことは入出力要求を作成または修正したあと、別のドライバに渡して以後の処理を任せることである。
上記プロセスを具体的に説明するために、以下では、関連の再解析ポイント属性をもつディレクトリが係わっている入出力要求を処理する具体例について図５と図６を参照して説明する。まず、図５を参照して、入出力システムの全体構造について説明する。図５において、クライアント・プロセス１３８は入出力要求を処理する複数のドライバ手段を備えた入出力システムへのコールを行う。クライアント・プロセス１３８はオペレーティング・システム・サービス１４０へのコールを行う。入出力マネージャ１４２は入出力要求を受け取り、入出力要求の転送を入出力システムの種々ドライバ間で調整する。
図５には、入出力要求を処理する複数のドライバ手段が示されている。ドライバ手段はシンボリックリンク・デコーダ１４４、分散ファイル・マネージャ１４６、階層ファイル・システム・マネージャ１４８、ファイル・システム・ドライバ１５０、およびディスク・ドライバ１５２から構成されている。シンボリックリンク・ドライバ１４４は入出力要求にシンボリックリンクがあれば、それをデコードすることを担当する。分散ファイル・システム・マネージャ１４６は複数の物理ボリュームにまたがって分散されたファイルを、１つの統合ボリュームであるかのように管理する。階層ファイル・システム・マネージャ１４８はアクセス頻度の低いファイルを除去し、それらをテープ上などのリモート・ロケーションにストアする。また、階層ファイル・システム・マネージャ１４８はリモートにストアされたファイルをその必要時にリトリーブすることも担当する。ファイル・システム・ドライバ１５０はファイルまたはディレクトリへのアクセス要求をディスク上の物理ロケーションに変換することを担当する。ディスク・ドライバ１５２は情報をディスク１５４からリトリーブしたり、情報をディスク上に配置することを担当する。以上のように、図５の入出力システムは、各々が独自の関数または関数群を担当する複数のドライバを使用して強固な入出力環境を提供している。
次に図６を参照して説明すると、図は２つの異なるディスク・ボリュームの論理構造を示している。ボリューム１は図６に１５６で示すように、Ｃと名づけたルート・ディレクトリをもっている。ディレクトリＣは名前がＡで番号が１５８であるファイルと、名前がＢで番号が１６０であるディレクトリを収めている。図６に示すように、ファイルＡ １５８はタグが５で、なんらかのデータ値をもつ再解析ポイントである。ディレクトリＢ １６０はＥ １６２と名づけたファイルと、Ｄ １６４と名づけたディレクトリを収めている。図６に示すように、ディレクトリＤ １６４はタグがDFSMで値がＷである、関連の再解析ポイントをもっている。タグがDFSMであることは、再解析ポイントが分散ファイル・システム・マネージャ１４６によって所有されていることを示している。以下の例で説明するように、このタグと値はディレクトリＤでボリューム２に接ぎ木するマウントポイントを作るために使用される。このマウントポイントは図６に矢印１６６で示されている。ボリューム２はＷ １６８と名づけたルート・ディレクトリをもっている。ディレクトリＷ １６８はディレクトリＸ １７０とディレクトリＹ １７２を収めている。ディレクトリＹはファイルＺ １７４を収めている。
図５に戻り、クライアント・プロセス１３８がパス名C＼B＼D＼Y＼Zと係わりをもつ入出力要求を作成したとする。この入出力要求はファイルＺ １７４にデータを読み書きするものとする。この場合、パス名はファイルＺ １７４にアクセスするためにクライアント・プロセス１３８によって使用される。クライアント・プロセス１３８は、矢印１７６で示すようにサービス１４０をコールすることによってこの入出力要求を送信する。入出力マネージャ１４２はＩＲＰ１７８を作成し、ＩＲＰ １７８をシンボリックリンク・デコーダ１４４に渡す。図４と同じように、入出力マネージャ１４２は入出力要求をあるドライバから別のドライバに渡す手段の１つの例である。
クライアント・プロセス１３８から出された入出力要求を満たすためには、ファイルのパス名C＼B＼D＼Y＼Zを解決する必要がある。一般的に、名前解決はマルチステージ・プロセスであり、これによれば、名前はその構成要素に分解され、各構成要素は、通常左から右に向かって解決されていき、成功したか、失敗したかが解決プロセスの各ステージで判断される。ＩＲＰ １７８がシンボリックリンク・デコーダ１４４に渡されるとき、解決する必要のあるパス名がＩＲＰの一部として渡される。シンボリックリンク・デコーダ１４４がどのように実装されているかにもよるが、シンボリックリンク・デコーダ１４４はＩＲＰ１７８内のパス名をスキャンしてパス名の構成要素のどれかがシンボリックリンクであるかどうかを確かめることができる。他の実装も可能であり、どのように実装するかは入出力システムにおける設計上の考慮事項によって決まる。図６に示す例では、シンボリックリンクがないために、シンボリックリンク・デコーダ１４４はＩＲＰ １７８を分散ファイル・マネージャ１４６に渡すことになる。前述したように、Microsoft Windows NT（登録商標）では、ＩＲＰの受け渡しは入出力マネージャ１４２を経由して行われることになる。
ＩＲＰ １７８は分散ファイル・マネージャ１４６によって受信され、このマネージャは、前述したように、複数ボリュームのファイル・システムを管理し、それらを１つの論理ファイル・システムに統合化することを担当している。この例では、分散ファイル・システム１４６は、解決プロセスのこのステージではＩＲＰ １７８で多くの処理をしないことが想定されている。分散ファイル・システム１４６は、例えば、図６に示すように最初の構成要素Ｃがボリューム１に属するものと判断するだけにすることができる。そのあと、ＩＲＰ １７８は階層ファイル・システム・マネージャ１４８に渡される。この場合も、階層ファイル・システム・マネージャ１４８はＩＲＰ １７８の処理をほとんど、あるいはまったく行わないで、それをファイル・システム・ドライバ１５０に渡すことが想定されている。
そのあと、ファイル・システム・ドライバ１５０は名前解決プロセスを開始する。ファイル・システム・ドライバ１５０は図６のディレクトリＣ １５６から始めて、ディレクトリＣ １５６をディスク１５４上の物理ロケーションに変換する。この情報はＩＲＰ １７８に入れられ、ディスク・ドライバ１５２に渡される。そのあと、ディスク・ドライバ１５２はディスク１５４にアクセスし、ＩＲＰ １８０に情報を入れて戻し、ファイル・システム・ドライバ１５０が解決プロセスを継続することを可能にする。このプロセスはパス名の各構成要素ごとに繰り返される。
図６に戻って説明すると、ファイル・システム・ドライバ１５０はディレクトリＣ １５６から開始し、ディレクトリＢ １６０に移り、ディレクトリＤ １６４に進んでいく。ディレクトリＤ １６４がディスクからリトリーブされたときは、ファイル・システム・ドライバ１５０はディレクトリＤが関連の再解析ポイント属性をもつものと認識することになる。そのあと、ファイル・システム・ドライバ１５０に組み込まれていて、入出力要求の処理に割り込みをかける手段は入出力要求の通常の処理シーケンスに割り込みをかけることになる。図４を参照して上述したように、ファイル・システム・ドライバ１５０は、ディレクトリＤ １６４の再解析ポイント属性から再解析データを抜き出すことができる。再解析ポイント属性がタグとデータ値をもっているとすると、前述したように、この情報が抜き出され、次の上位レベル・ドライバに戻されることになる。図５には、これは再解析データ１８２で示されている。図５の再解析データ１８２は再解析ポイント情報をドライバに渡す手段のもう１つの例を示している。このケースでは、図６に示すように、タグはデータベースであり、値はＷになっている。この例では、タグDFSMは分散ファイル・システム・マネージャ１４６が再解析ポイントの所有者であることを示している。
図５の再解析ポイント・データ１８２は図示のように階層ファイル・システム・マネージャ１４８に転送される。階層ファイル・システム・マネージャ１４８によって受信される再解析ポイント情報がそのドライバによって所有されているかどうかを判別する手段は、再解析データ１８２が階層ファイル・システム・マネージャ１４８によって所有されているかどうかを判別することになる。この手段は図４を参照して前述したように、階層ファイル・システム・マネージャ１４８の完了ルーチンに実装させることができる。このケースでは、階層ファイル・システム・マネージャ１４８は図６の解析ポイント１６４の所有者となっていない。再解析データ１８２が階層ファイル・システム・マネージャ１４８によって所有されていないと判断したあと、階層ファイル・システム・マネージャ１４８は再解析データ１８２を図５に示す次の上位レベル・ドライバに転送する。
分散ファイル・システム・マネージャ１４６は再解析データ１８２を受け取ると、再解析データ１８２が分散ファイル・システム・マネージャ１４６によって所有されているかどうかを判別する。これは、分散ファイル・システム・マネージャ１４６によって受信された再解析ポイント情報がそのドライバによって所有されているかどうかを判別する手段を通して行われる。この手段は図４を参照して前述したように、完了ルーチンに実装させることができる。図６に示す例では、分散ファイル・システム・マネージャ１４６は再解析データ１８２を調べ、自分が所有者であると認識することになる。これは、特定のドライバが入出力要求の少なくとも一部を処理させるドライバであると判断する手段によって行うことができる。前述したように、かかる手段の例としては、再解析データ１８２のタグがある。言い換えれば、分散ファイル・システム・マネージャ１４６は、再解析データ１８２のタグ値を自身が所有するタグ値と突き合わせることで、再解析データ１８２が自分のものであると認識することができる。
ドライバが再解析データを自分が所有するものであると認識すると、そのドライバはその入出力要求の処理を継続する責任を引き受けることになる。入出力要求の処理を続けるために、ドライバは再解析ポイント属性のデータ値を調べ、そこにストアされている情報を使用して入出力要求を処理するのが代表的である。このケースでは、分散ファイル・システム・マネージャ１４６はマウントポイントのターゲットをデータ値にストアする。次に図６に戻って、ディレクトリＤ１６４に関連する再解析ポイントのデータ値を調べれば分かるように、データ値はＷになっている。これはボリューム２のディレクトリＷであることを示している。分散ファイル・システム・マネージャ１４６はデータ値を調べれば、ボリューム２のディレクトリＷがマウント・ポイントのターゲットであることを知ることができる。そのあと、分散ファイル・システム・マネージャ１４６は、ボリューム２のディレクトリＷから始まって、解決プロセスを継続していくＩＲＰを作成することができる。ボリューム２のディレクトリＷから始まって、名前解決プロセスを継続していく第２のＩＲＰを作成するためには、分散ファイル・システム・マネージャ１４６はオリジナル入出力要求の処理を継続する第２の入出力要求を作成するための手段を採用することができる。この手段は図４を参照して前述したように実装することができる。名前解決プロセスをどのように進めるかを判断するために非常に望ましいことは、再解析ポイントが現れる前に名前解決プロセスがどこまで進んだかを分散ファイル・システム・マネージャ１４６が判断できるようにすることである。従って、実施形態によっては、オリジナルのパス名とオフセットを戻して、再解析ポイントが現れる前に名前解決プロセスがどこまで進んだかを判断できるようにすることが望ましい場合がある。この例では、パス名はC＼B＼D＼Y＼Zになっている。この場合、オフセットがディレクトリＤを指しているのは、それが再解析ポイントが見つかった場所であるからである。名前解決プロセスを継続する別のＩＲＰを作成するとき、分散ファイル・システム・マネージャ１４６は名前のうちすでに解決されている部分を取り除き、解決プロセスをそこから継続させるロケーション、つまり、図６のディレクトリＷ １６８で再解析ポイントＤを置き換えることを選択することができる。そのような場合には、新しいパス名はW＼Y＼Zとなる。そのあと、分散ファイル・システム・マネージャ１４６はこの情報をＩＲＰ １８４に入れて、ＩＲＰ １８４を階層ファイル・システム・マネージャ１４８に渡すことができる。
そのあと、階層ファイル・システム・マネージャ１４８はＩＲＰ １８４をファイル・システム・ドライバ１５０に転送する。ファイル・システム・ドライバ１５０は図６のディレクトリＷから始まって名前解決プロセスを継続していく。名前解決プロセスはディレクトリＹ １７２に移り、ファイルＺ １７４に到達するまで続けられる。このプロセスでは、図５に示すように、ＩＲＰ １８４がディスク・ドライバ１５２に渡され、ＩＲＰ １８６がディスク・ドライバ１５２から戻されている。なお、名前解決プロセスでは、ファイル・システム・ドライバ１５０とディスク・ドライバ１５２の間でＩＲＰ １８４と１８６がなん度も受け渡しされる場合がある。また、ＩＲＰ １８６はＩＲＰ １８４と同じにすることができ、ＩＲＰ １７８はＩＲＰ １８０と同じにすることができる。これらが図５に異なる番号で示されているのは、ディスク・ドライバ１５２が入出力オペレーションの結果をそこに入れることでＩＲＰを修正できることを示すためにすぎない。
図６のファイルＺ １７４が係わりをもつ、必要とする入出力オペレーションが実行され、結果がＩＲＰ １８６に入ってファイル・システム・ドライバ１５０に戻されると、ファイル・システム・ドライバ１５０はＩＲＰ １８６を階層ファイル・システム・マネージャ１４８に返送することになる。図５に示すように、ＩＲＰ １８６は分散ファイル・システム・マネージャ１４６とシンボリックリンク・デコーダ１４４に連続的に渡されていき、最終的に結果は矢印１８８で示すようにクライアント・プロセス１３８に戻されることになる。
次に図７を参照して説明する。図７は再解析ポイント属性が現れたとき入出力要求が別のコンピュータ・システムに送られて処理を任せるようにした場合の例を示している。図７に示す実施形態では、クライアント・プロセス１９０はローカル・コンピュータ１９２で実行されている。ローカル・コンピュータ１９２はコンピュータ相互間を接続するネットワーク手段を介してリモート・コンピュータ１９４に接続されている。図７において、このネットワーク手段はネットワーク・カード１９６とコネクション１９８で示されている。ローカル・コンピュータ１９２の入出力システム２００は入出力要求を処理する複数のドライバ手段を含んでいる。図７において、このドライバ手段は、例えば、シンボリックリンク・デコーダ２０２、ファイル・システム・ドライバ２０４およびディスク・ドライバ２０６で示されている。入出力システム２００はオペレーティング・システム・サービス２０８と入出力マネージャ２１０も含んでいる。図５に示すと同じように、クライアント・プロセス１９０はオペレーティング・システム・サービス２０８へのコールを行う。入出力マネージャ２１０は入出力要求を受け取り、入出力システムの種々ドライバ手段相互間の入出力要求の転送を調整する。別の方法として、入出力システムの種々ドライバ手段は、種々ドライバ手段相互間の情報転送を調整する入出力マネージャや他のデバイスによらなくても、相互に直接に通信し合うようにすることも可能である。
この例では、クライアント・プロセス１９０は、リモート・コンピュータ１９４に接続されたディスク上に置かれたファイルまたはディレクトリを指すシンボリックリンクが係わりをもつ入出力要求を行うものと想定されている。例えば、クライアント・プロセス１９０が、リモート・コンピュータ１９４に接続されたディスク２１２に置かれているディレクトリへのシンボリックリンクをもつディレクトリの内容をリストするために入出力要求を行ったとする。この入出力要求は、例えば、クライアント・プロセス１９０が矢印２１４で示すようにオペレーティング・システム・サービス２０８をコールすることによって行われる。入出力要求はファイル・システム・ドライバ２０４に渡され、このドライバはディスク・ドライバ２０６を利用して名前解決プロセスを開始する。ディスク・ドライバ２０６はディスク・コントローラ２１８を使用してディスク２１６から情報を読み取る。名前解決プロセスは、前述したように、シンボリックリンクを表している再解析ポイントが見つかるまで続けられる。その個所で、再解析ポイント情報が抜き出され、他のドライバに渡されるが、これはあるドライバが自分が再解析ポイントの所有者であると認識するまで続けられる。この例では、シンボリックリンク・デコーダ２０２が、リモート・コンピュータ１９４へのシンボリックリンクを実装するために使用された再解析ポイントの所有者であると認識することになる。
シンボリックリンク・デコーダ２０２は自身が再解析ポイントの所有者であると認識すると、シンボリックリンク・デコーダ２０２は入出力要求を処理する責任を引き受けることになる。この例では、シンボリックリンク・デコーダ２０２が入出力要求を単独で最後まで処理できないのは、入出力要求を処理するためにリモート・コンピュータ１９４からディレクトリ情報をリトリーブする必要があるためである。そのような場合には、本発明の範囲に属する実施形態では、入出力要求をリモート接続のコンピュータに送って処理させる手段を含めることが可能である。図７に示すように、ローカル・コンピュータ１９２とリモート・コンピュータ１９４がネットワーク手段で接続されているような実施形態では、入出力要求をリモート接続のコンピュータに送る手段は、入出力要求をネットワーク経由でリモート・コンピュータ１９４に転送し、リモート・コンピュータ１９４に入出力要求を処理させ、要求を満たすようにするメカニズムならば、どのようなメニズムにすることもできる。例えば、図７において、入出力要求をリモート接続のコンピュータに送る手段はリディレクタ（redirector）２２０とネットワーク・トランスポート・ドライバ２２２で構成することが可能である。図７に示す実施形態では、リディレクタ２２０はローカル・コンピュータ１９２がネットワーク上の他のマシン上のリソースにアクセスするとき必要になる機能を備えている。ネットワーク・トランスポート・ドライバ２２２は、情報をローカル・コンピュータ１９２からネットワーク・カード１９６とコネクション１９８を経由してリモート・コンピュータ１９４へ転送できるようにするメカニズムを備えている。入出力要求をリモート接続のコンピュータに送る手段は他のメカニズムを使用して実装することも可能である。一般的に、この手段は入出力要求をあるコンピュータから別のコンピュータに転送するトランスポート・メカニズムを備えている。このようなメカニズムは、専用リンク、ローカルエリアネットワーク（LAN）、広域ネットワーク（WAN）、電話回線、ワイヤレス（無線）などのように、任意のタイプのコネクションで２コンピュータ間を結ぶことを可能にしているのが一般である。さらに、この手段は、あるコンピュータの入出力システムから入出力要求を受け取り、その入出力要求を別のコンピュータの入出力システムに発送するメカニズムを含むこともできる。このためには、種々タイプのソフトウェアやファームウェアまたはドライバが必要になる。入出力要求をリモート接続のコンピュータに送る手段に要求されることは、リモート・コンピュータで処理できるフォーマットで入出力要求を発送することである。
図７の実施形態では、シンボリックリンク・デコーダ２０２はリモート・コンピュータ１９４に入出力要求を行う必要があると認識したときは、シンボリックリンク・デコーダ２０２は入出力要求をリディレクタ２２０に渡せば、リディレクタ２２０がネットワーク・トランスポート・ドライバ２２２を使用して入出力要求をネットワーク・カード１９６とコネクション１９８経由でリモート・コンピュータ１９４に転送してくれる。この具体例では、入出力要求はシンボリックリンクが指しているディレクトリのディレクトリ内容に対するものである。
リモート・コンピュータ１９４に渡された入出力要求はネットワーク・トランスポート・ドライバ２２４によって受信され、サーバ・ファイル・システム２２６に渡される。サーバ・ファイル・システム２２６はリディレクタ２２０と通信して、リモート・コンピュータ１９４に送られた入出力要求を処理し、その要求満たすようにする。入出力要求を満たすためには、サーバ・ファイル・システム２２６はファイル・システム２２８やディスク・コントローラ２３０のような、リモート・コンピュータ１９４のドライバとハードウェアを利用することができる。この例では、サーバ・ファイル・システム２２６はファイル・システム・ドライバ２２８を利用して、該当のディレクトリ内容をディスク２１２からリトリーブし、そのディレクトリ内容をローカル・コンピュータ１９２に戻している。ディレクトリ内容が戻されたとき、シンボリックリンク・デコーダ２０２はそのディレクトリ内容をクライアント・プロセス１９０に送り返すことができる。
図７に示す実施形態では、ローカル・コンピュータ１９２とリモート・コンピュータ１９４の間で通信を行う特定のコンポーネントが含まれているが、そのようなコンポーネントはすべての点で例示的なものである。本発明で必要とされるものは、入出力要求がローカル・コンピュータ側のドライバからリモート・コンピュータに渡されて、そこで入出力要求が満たされ、該当の情報が戻されるようにするメカニズムである。上記機能を然るべき方法で実行するメカニズムであれば、どのメカニズムも本発明の範囲に属するものである。
本発明を全体にわたって理解するのを容易にするために、次に図８を参照して説明する。図８は、本発明を使用して入出力システムの能力を拡張する実施形態を示すトップレベル図である。一般的に、入出力システムはハードウェア・デバイスとの間でデータを送受信するために使用される。そのようなハードウェア・デバイスとしては、前述したように大容量記憶デバイスや、図７に示すようなネットワークを含む他のタイプのハードウェア・デバイス、またはデータの送信側またはデータの使用側となる他のタイプのデバイスがある。実際には、キーボードやディスプレイなどのデバイスであっても、具体的な実装と環境にもよるが、入出力システムの一部で制御することが可能である。一般的に、クライアント・プロセスはデータを特定のハードウェア・デバイスに送るために、あるいはデータを特定のハードウェア・デバイスからリトリーブするために、入出力要求を入出力システムに送っている。さらに、入出力システムはハードウェア・デバイスからの情報があるとき、そのことをクライアント・プロセスに通知することができる。前述したように、入出力要求は広義の意味に解釈されるものである。従って、入出力要求には、クライアント・プロセスと入出力システムとの間のすべてのやりとりを含めることができ、その中には、データを入出力要求を送り込んだり、データを入出力システムから受け取ったりする要求も含まれる。
図８に示すように、全体的ハードウェア・デバイスはハードウェア・デバイス２３２で示されている。上に示した例で説明したように、特定のハードウェア・デバイスにアクセスするためには、１つまたは２つ以上のドライバを入出力システムで使用することができる。図８に示すように、ハードウェア・デバイス２３２にアクセスするために使用されるドライバはハードウェア・アクセス・ドライバ２３４で示されている。ハードウェア・アクセス・ドライバ２３４は入出力要求を処理するドライバ手段のもう１つの例である。ハードウェア・アクセス・ドライバ２３４は、ハードウェア・デバイス２３２にアクセスするために必要とされる任意の数またはタイプのドライバにすることができる。ハードウェア・デバイス２３２が、例えば、ディスクであれば、ハードウェア・アクセス・ドライバ２３４はファイル・システム・ドライバとディスク・ドライバの一方または両方にすることができる。ハードウェア・デバイス２３２がネットワーク・デバイスであれば、ハードウェア・アクセス・ドライバ２３４はネットワークにアクセスするために必要とされる任意の数またはタイプのドライバにすることができる。このようなことが起こるのは、例えば、ネットワーク経由で大容量記憶デバイスにアクセスする場合である。
入出力システムの能力を拡張し、当初から入力システムに組み込まれていなかった別の機能を追加するためには、処理される入出力要求の特定タイプ別に１つまたは２つ以上の拡張デバイスを追加することができる。図８には、この特定タイプのドライバは拡張ドライバ２３６で示されている。拡張ドライバ２３６は可入出力要求を処理するドライバ手段のもう１つの例である。拡張ドライバ２３６は上記の例で前述した一般的原理に従って再解析データを処理するドライバ層を代表しているのが一般である。前述したように、通常の入出力オペレーション時には、拡張ドライバ２３６は入出力要求の処理の一部になっていない。しかし、再解析ポイントがハードウェア・アクセス・ドライバ２３４によって検出されたときは、コントロールが拡張ドライバ２３６に渡され、拡張ドライバ２３６が入出力要求の処理に介入できるようにする。
前述したように、拡張ドライバ２３６がコントロールを受け取ったとき、そのあと行われる処理は本発明では未定義になっている。本発明はどのタイプの処理を行うためにも使用できる。１つの例では、再解析ポイントはホーム・オートメーション環境で設定されている。再解析ポイントにアクセスするとき、コントロールが拡張ドライバに渡されると、拡張ドライバは再解析ポイントに見合ったアクションをとる。例えば、おそらくは、消防署または警察署の電話番号が再解析ポイント情報の一部としてストアされることになる。出された入出力要求が再解析ポイントと係わりがあるときは、コントロールを特定のドライバに渡すことができるので、その特定ドライバは再解析ポイントから電話番号を抜き出し、警察署または消防署にダイヤルすることになる。警察署または消防署に連絡をしたあと、合成音声は他のオーディオ情報を送信するといった、該当アクションがとられ、具体的状態が警察署または消防署に通知されることになる。基本的には、入出力システムが再解析ポイントを見つけ、コントロールが特定の拡張ドライバに渡されて処理が行われるとき、そのあとなんらかのアクションがとられる。このアクションには、入出力システムまたは記憶デバイスにストアされたファイルや他の情報とは通常無関係であるアクションも含まれている。
拡張ドライバ２３６のように、拡張ドライバが入出力要求の処理責任を引き受けたときは、拡張ドライバはなんらかの処理を行うことができる。拡張ドライバは、該当するものがあれば、他のサービスまたはドライバを利用してそのタスクを完了することができる。図８に示すように、この他のドライバまたはサービスは拡張ドライバ・サービス２３８で示されている。拡張ドライバ・サービス２３８は、拡張ドライバ２３６がそのタスクを完了するために利用しなければならない他のドライバまたはサービスにすることができ、この中にはハードウェア・ドライバが含まれる。当然のことであるが、このような機能は、具体的にどのように実装し、その実装のためにどのような設計上の選択を行うかに応じて、単独にすることも、拡張ドライバ２３６に直接に組み込むことも可能である。
最後に、注目すべきことは、入出力要求を完了するために必要または望ましい情報は再解析ポイントからでも、オリジナル入出力要求からでも、あるいはその両方からでも得ることができることである。オリジナル入出力要求は、再解析ポイント内の情報と共に、拡張ドライバ２３６が利用することができる。
以上を要約すると、本発明は入出力要求の通常処理に割り込みをかけ、通常では入出力要求の通常処理に関与していないドライバが入出力要求の処理責任を引き受けることを可能にするメカニズムを提供している。本発明が定義している方法とシステムは柔軟性を備えていると同時に、拡張可能性も備えている。本発明は通常の処理シーケンスに介入することを可能にする方法だけは別として、入出力要求を処理するときの正確な詳細を定義していないので、本発明を利用すれば広範囲にわたる結果を達成することができる。基本的には、本発明のメカニズムによれば、特殊タイプのファイルまたはディレクトリを定義しておけば、その特殊ファイルまたはディレクトリが係わりをもつ入出力要求の処理コントロールを、特殊ファイルまたはディレクトリが係わりをもつ入出力要求を処理するのに適した特定のドライバに渡すことができる。本発明の用途として、分散ファイル・システムをシングル・ファイル・システムであるかのように管理する場合について説明してきたが、本発明は、階層ストレージを管理し、セキュアまたは暗号化ファイルまたはディレクトリを管理し、最新コンピュータで広く採用されている階層方式とは別の新規の方法でファイルまたはディレクトリのアクセスまたは編成を管理する場合にも利用することができ、特殊タイプのファイルまたはディレクトリが定義される場合には考案または開発が可能である他の用途にも利用が可能である。さらに、入出力要求を処理するのに適したドライバにコントロールが渡されたあと、それ以後に行われる処理はファイルまたはディレクトリが係わっている従来の入出力オペレーションとは無関係にすることができる。特殊ドライバは必要とするタスクに見合ったリソース、ドライバまたはシステムを使用してどのような処理でも行うことができる。
本発明は、本発明の精神または基本的特徴から逸脱しない限り、他の具体的実施形態で実現することが可能である。上述してきた実施形態はすべての点で例示的なものであり、その実施形態に限定されるものではない。従って、本発明の範囲は上述してきた説明に限定されるのではなく、請求の範囲の記載によってのみ限定されるものである。請求の範囲の意味と等価範囲内に属する変更はすべて本発明の範囲に包含されるものである。
本発明は、入出力（Ｉ／Ｏ）システム内の複数のドライバが入出力要求の処理に参加することを可能にするシステムおよび方法に関する。さらに具体的には、本発明によれば、あるドライバが通常の入出力処理シーケンスに割り込みをかけて別のドライバにコントロール（制御権）を引き渡し、以後の入出力要求処理をそのドライバに任せることを可能にしている。
２．従来技術の説明
関数型コンピュータ・システムは、３つの基本コンポーネントから構成されているのが一般である。第１のコンポーネントはコンピュータ・ハードウェアである。コンピュータ・ハードウェアとしては、中央処理ユニット（ＣＰＵ）などのデバイス、ＲＡＭやＲＯＭなどのシステム・メモリ、磁気または光ディスク・ストレージなどの大容量記憶装置、キーボードまたはその他の入力デバイス、およびディスプレイまたはその他の出力デバイスがある。コンピュータ・システムのユーザはユーザまたはアプリケーション・プログラムとやりとり（インタラクション−対話）しているのが一般である。そのようなプログラムとしては、なじみのあるワードプロセッシング・アプリケーション、スプレッドシート・アプリケーション、データベース・アプリケーションなどがある。最新の関数型コンピュータ・システムの最後のコンポーネントはオペレーティング・システムである。コンピュータ・オペレーティング・システムは、ユーザにアプリケーション・プログラムの実行を開始させる、といったように多数の関数を実行している。さらに、最新オペレーティング・システムは、アプリケーション・プログラムとコンピュータ・システム・ハードウェアとの間のインタフェースも提供している。以上のように、かつてはアプリケーション・プログラムがコンピュータ・システム・ハードウェアに直接にアクセスすることが普通であったが、最新オペレーティング・システムでは、標準化された統一インタフェースが用意されているため、ユーザ・アプリケーションが標準化された方法でコンピュータ・ハードウェアとのインタフェースとなったり、コンピュータ・ハードウェアに直接にアクセスしたりすることが可能になっている。
ユーザ・アプリケーションなどのプロセスと特定タイプのハードウェア・デバイスとを統一インタフェースで結ぶために、実際のハードウェアとプロセスの間にはいくつかのソフトウェア層が設けられている。例えば、プロセスはコールを行ってオペレーティング・システムに入り込むことが可能になっている。これに対して、オペレーティング・システムはハードウェア・ドライバ層が提供するサービスを利用することができる。この場合、ハードウェア・ドライバ層はハードウェアとの直接インタフェースとなっている。この階層化による方法の主な利点は、層の追加や置換が、残りの層に大きな影響を与えないで行えることである。例えば、新しいハードウェア・デバイスがシステムに追加されるとき、新しいドライバが追加できるので、オペレーティング・システムはそのハードウェアにアクセスすることが可能になる。これらの変更はすべて、既存のアプリケーション・プロセスに与える影響を最小限または皆無にして行うことができる。
ドライバがハードウェア・デバイスとのインタフェースとなるために使用されるとき、モノリシック（monolithic）なドライバを作り、オペレーティング・システムと特定のハードウェア・デバイスとのインタフェースになるために必要な、すべての機能をドライバに組み込んでおくのが従来の傾向であった。最近では、オペレーティング・システムは複数のドライバを使用して種々の入出力タスクを実行するように開発されている。これの特に顕著な例として、ディスクや他の大容量記憶装置に対する入出力要求を取り扱うときがある。
データは大容量記憶デバイスに階層的にストアされ、ディレクトリまたはファイルはツリー構造に似た階層に編成されているのが代表的である。任意のファイルまたはディレクトリのロケーションはファイルのパス名で指定されるのが代表的である。パス名はルートまたは開始ディレクトリで始まり、必要とするファイルまたはディレクトリに到達するまでの各サブディレクトリの名前を指定しているのが代表的である。例えば、“file.dat”と名づけたファイルはルート・ディレクトリ“root”のサブディレクトリである、ディレクトリ“temp”にストアすることができる。従って、パス名は/root/temp/file.datとなる。ファイル・システムでのファイル名の解決は、マルチステージ・プロシージャになっているのが代表的である。このプロシージャはファイル・システムに正しく識別させる必要のある、名前付き構成要素（named component）のすべてをデコードするステージから始まっているのが一般である。次に、このプロシージャは、ファイル名中の連続する構成要素を、通常は左から右に向かって識別する繰り返しプロセスが続いている。最後に、このプロシージャはこれらの名前解決の各々が成功したか、失敗したかを判別している。従って、この例では、パス名は連続する構成要素に分解され、解決プロセスはルート・ディレクトリ、tempディレクトリ、およびファイルfile.datを順番に識別していくことになる。
大部分のＵＮＩＸシステムでは、複数のデータ・マネージャが１つのシステム（installation：導入されたシステムのこと）内に共存することが可能になっている。これを達成するために、階層ファイル・ネーム・スペース（hierarchicalfile name space：ファイル名空間）はファイル名とディレクトリ名のサブツリーに分割されている。この場合、各サブツリーの管理は専用のデータ・マネージャが行っている。入出力要求が行われると、名前解決プロセスは名前を特定のサブツリーに変換するので、その入出力要求はそのサブツリーのデータ・マネージャによって処理されることになる。そのあと、データ・マネージャは組み込みＵＮＩＸファイル・システムをコールして、データの実際のストアとリトリーブを行うことができる。従って、データ・マネージャは特定ファイル・システムの能力を拡張する付加価値コンポーネントの働きをする。
複数のデータ・マネージャがＵＮＩＸ入出力システムに存在するときは、正しいデータ・マネージャへの要求のルーチング（routing: 経路選択）は「マウントポイント（mount point）」のメカニズムを通して達成されている。サブツリーの各々を表すために１つのマウントポイントがネームスペースに設定されている。名前解決プロセスの過程で、あるマウントポイントが現れると、ＵＮＩＸ入出力システムは、そのマウントポイントで表されたサブツリーの管理を担当する該当データ・マネージャに要求を送付する。要求を受け取ると、その該当データ・マネージャは名前解決プロセスを継続する。
標準ＵＮＩＸファイル・システムはシンボリックリンク（symbolic link）もサポートしている。シンボリックリンクは名前解決プロシージャが別の名前を使用して新たに開始されるという、組み込み型ケースのひとつである。シンボリックリンクが現れたとき、あるファイル名は別のファイル名に盲目的に置き換えられ、名前解決プロセスはその置換名を使用して新たに開始される。
以上のように、従来のファイル・システムは複数のデータ・マネージャを使用してアドレス空間の異なる部分を管理していた。これらのデータ・マネージャは入出力要求を処理するために、標準ファイル・システムとやりとりすることも可能であった。しかし、従来システムで使用されているモデルは相対的に決定論モデル（deterministic）であったため、モデル設計者が意図していなかったシナリオまでをカバーする拡張は不可能であった。言い換えれば、データ・マネージャとファイル・システムとのやりとりは相対的に固定しており、各々は定義された役割を実行していた。データ・マネージャまたはファイル・システムのどちらかを除去し、それを別のコンポーネントで置き換えて他のなんらかの関数を実行しようとしても、それは困難であった。同様に、別のマネージャをシステムに入れてサブツリーの管理以外の関数を実行させようとしても、それは、不可能ではないとしても、既存のドライバ・モデルを使用して行うことが困難であった。従って、複数のコンポーネントが協力し合って入出力要求を処理できるようにし、その場合、コンポーネントの数が固定されていないで、システムの設定時に意図していなかった関数を処理する新規コンポーネントを追加するように随意に拡張または変更できるようにする方法が望まれていた。また、いずれかのコンポーネントを置き換えても、残りのコンポーネントが大きな破壊を受けないようにすることも望まれていた。
従来技術のもう１つの問題は複数のデータ・マネージャが使用されていても、名前解決プロセスに参加することが、データ・マネージャが制御権をもつネームスペースに制限されていることである。言い換えれば、複数のマウントポイントを識別するためには、複数のデータ・マネージャは各々が特定のマウントポイントを取り扱うようにインストールされていなければならない。そこで、望まれることは、単一のデータ・マネージャが複数のマウントポイントまたはサブツリーの情報を管理できるようにすることである。
以上のように、望まれていることは、複数のデータ・マネージャまたはドライバを使用して入出力要求を処理する入出力システムを動的に拡張し、再構成するメカニズムである。また、望まれていることは、そのような再構成や拡張を行っても、システム内の他のデータ・マネージャやドライバに与える影響を最小限にすることである。
発明の概要
上述した従来技術の問題は、本発明によれば、入出力システムにおける通常の処理シーケンスに割り込みをかけ、コントロール（制御権）をあるデータ・マネージャまたはドライバから別のデータ・マネージャまたはドライバに移すようにするシステムおよび方法を提供することによって解決している。本発明は、入出力要求を満たす際に、複数のデータ・マネージャまたはドライバを使用して種々の処理関数を実行するようにした入出力システムで利用すると、特に好都合である。
複数のドライバまたはデータ・マネージャが協力し合って入出力要求を満たすようにしたシステムでは、ドライバまたはデータ・マネージャは階層関係にあって、各ドライバが種々タイプの関数を実行して入出力要求を処理していることがよくある。例えば、入出力システムはファイル・システム・ドライバがデバイス・ドライバの上に置かれた階層構造になっている場合がある。この場合、入出力要求を受けると、ファイル・システム・ドライバは、ファイル名を解決し、ファイル名をディスク上の特定のロケーションに変換するといった、ある種の関数を実行している。そのあと、ディスク上の特定ロケーションはデバイス・ドライバに渡され、デバイス・ドライバはディスク上の正しいロケーションを見つけ、必要とする情報を読み書きしている。他のデバイスも、階層構造上でファイル・システム・ドライバの上か下に置かれている。例えば、望ましい方法は、ファイル・システム・ドライバとデバイス・ドライバの間に別の（冗長）ファイル・システム・ドライバを置くことである。このようすると、この冗長ファイル・システム・ドライバはデータ・ミラーリング（data mirroring）を行って、データをディスク上の複数のロケーションにミラーリング（複製）したり、データを複数のディスクにミラーリング（複製）したりできる。
従来の階層ドライバ・モデルでは、情報はある層から別の層に渡され、各層が独自の種々タスクを実行してからその要求を別の層に渡すようにしている。ケースによっては、通常の処理シーケンスに割り込みをかけて、入出力要求の少なくとも一部を処理するためのコントロールを別のドライバに渡すようにすると、非常に好都合な場合がある。例えば、おそらく重要なことは、ある種のファイルを特殊なロケーションにストアしておくことである。その特殊ロケーションにストアされたファイルへのアクセス管理は、ドライバを開発することで行うことができる。従って、ファイル・システム・ドライバが名前を特殊ロケーションに変換するとき、望ましいことは、入出力要求を通常のデバイス・ドライバに渡すのではなく、入出力要求のコントロールをその情報を処理するドライバに渡すことである。
本発明によれば、通常の処理シーケンスに割り込みをかけ、入出力要求を特定のドライバに渡すことを可能にしている。本発明の方法は動的に拡張可能であり、システムは他のドライバのオペレーションを中断することなく、ドライバを追加または除去するように構成することができる。これを達成するために、新規のディレクトリとファイル属性が定義され、これは「再解析ポイント（reparsepoint）」属性と名づけられている。この再解析ポイントは付加的属性であるので、個別ファイルとディレクトリは、再解析ポイント属性のステータスに応じて再解析ポイントにすることも、しないことも可能になっている。
再解析ポイント属性は、好ましくは、タグとデータ値の両方をもっている。タグはどのドライバが再解析ポイントの所有者であるかを示すために使用される。一般的に、再解析ポイントの所有者はその再解析ポイントが係わりをもつ入出力要求の全部または一部を処理することを受け持っている。データ値は所有者によって再解析ポイントにストアされたデータである。従って、所有者は再解析ポイントの値を使用して、再解析ポイントが係わっている特定の入出力要求を完了するために必要または役立つデータをストアすることができる。
複数の階層化ドライバを含んでいる実施形態では、ある再解析ポイントが特定のドライバによって識別されると、そのドライバはその再解析ポイントのタグとデータ値を抜き出すようになっている。入出力要求は、再解析ポイントのタグとデータ値と一緒に、あるドライバが自分がその再解析ポイントの所有者であると認識するまで他のドライバに渡されていく。その所有者はコントロールを受け取り、入出力要求の処理を再開する。再解析ポイントの所有者は、入出力要求を最後まで処理することも、他のドライバを利用して入出力要求の処理を完了させることもできる。また、所有者は他のコンピュータを利用して、入出力要求の処理を完了させることも可能である。
各再解析ポイントはタグと値の両方をもっているので、再解析ポイント・メカニズムは、任意の数のドライバが使用して任意の数の関数を達成できるようにする、非常に柔軟性のある構造になっている。例えば、ローカル・ストレージからアーカイブ・ストレージに自動的に移行されるデータを管理するために、コントロールを階層記憶マネージャに渡すことができる。別の例として、複数の異なるディスク・ドライブにストアされているファイルを管理する分散ファイル・マネージャにコントロールを渡すこともできる。さらに別の例として、コントロールをセキュア・ファイル・マネージャに渡し、セキュア・ロケーションにストアされているファイルや暗号化フォーマットでストアされているファイルを管理させることもできる。基本的には、本発明によれば、通常の処理シーケンスに割り込みをかけ、コントロールを異なるドライバに渡して特殊タイプのファイルやディレクトリの特殊処理要求を処理させることができる。このメカニズムによれば、入出力システムがもつ能力を時間と共に変化する要求に見合うように、統一された方法で拡張することができる。
本発明は、入出力システムによって通常サポートされる標準入出力オペレーション以上に入出力システムの能力を拡張できるだけの、十分な幅広さをもっている。ドライバまたはマネージャは、ある標準入出力オペレーションから得られるアクションが標準入出力オペレーションとは関係のないアクションになるように開発することができる。例えば、ホーム・オートメーション環境では、再解析ポイントは任意の数の目標を達成するために使用できる。再解析ポイントは警察署や消防署を呼び出すために使用できる。例えば、１つの可能な実装例として、再解析ポイントを設定して、警察署や消防署の電話番号を再解析ポイントの一部としてストアしておくことができる。入出力システムが再解析ポイントにアクセスすると、その再解析ポイントを所有するドライバは、上述したように処理コントロールを受け取ることになる。そのあと、所有者は該当の電話番号をリトリーブして、モデムまたは他のシステムを通してその電話番号をダイヤルし、通知、情報、音声、その他を被呼び出し側エンティティに送信することができる。本発明は他のどうような状況においても使用できるので、標準入出力オペレーションとは関係のない結果を得るために標準入出力オペレーションを使用することができる。
本発明のその他の利点は以下の説明の中で明らかにされているが、そのいくつかは以下の説明を読むことで理解できるものと、本発明を実施することで理解できるものとがある。本発明の利点は請求の範囲に具体的に記載されている種々の手段とその組み合わせによって実現し、得ることができる。本発明の上記およびその他の特徴は以下の説明および請求の範囲を読めば十分に理解できるが、以下で説明するように本発明を実施することで知得することもできる。
【図面の簡単な説明】
本発明の上述した利点およびその他の利点がどのようにして得られるかを説明するために、以下では、要約して上述した本発明を、添付図面に図示されている具体的実施形態を参照して詳しく説明することにする。なお、添付図面に図示の実施形態は本発明の代表的な実施例であり、従って、本発明の範囲を限定するものではないとの了解のもとで、以下では、添付図面を参照してより具体的にかつ詳細に本発明を説明し、解説することにする。
図１は階層化されたドライバを採用する入出力システムを示す図である。
図２は、再解析ポイント属性に出会ったときある階層ドライバから別の階層ドライバにコントロールがどのように渡されるかを示す図である。
図３は、本発明で使用するのに適しているファイルまたはディレクトリの属性を示す図である。
図４は、２つの階層ドライバによって提供されるサービスを示すと共に、本発明によってドライバに組み込まれている全体機能を示す図である。
図５は、本発明がどのように使用されて、再解析ポイントが係わりをもつ入出力要求が処理されるかを示す例である。
図６は図５に示す例のディレクトリ構造を示す図である。
図７は、別のコンピュータを使用して入出力要求を完了する場合の例を示す図である。
図８は、本発明が入出力システムの能力をどのように拡張しているかを示す図である。
好ましい実施形態の詳細な説明
以下では、本発明のシステムおよび方法を実現するために使用される実施形態の構造または処理を図面を参照して具体的に説明しながら、本発明について説明する。上記のように図面を参照して本発明を説明するが、そのことは本発明の範囲を限定するものではない。本発明が目的とする方法とシステムは、どちらも、入出力システムにおける通常の処理シーケンスに割り込みをかけ、コントロール（制御権）を別のドライバに渡して入出力要求の以後の処理をそのドライバに任せるようにしたものである。本発明の実施形態では、特殊目的または汎用目的のコンピュータを含み、そのコンピュータは中央処理ユニット（ＣＰＵ）などの標準コンピュータ・ハードウェアまたはコンピュータ実行可能命令を実行する他の処理手段、実行可能命令をストアしておくためのコンピュータ読取可能媒体、情報を表示または出力するディスプレイまたは他の出力デバイス、情報を入力するためのキーボードまたは他の入力手段、その他を装備している。本発明はコントロールをあるドライバから別のドライバに渡すことを目的としているので、本発明の範囲に属する実施形態は一般的に入出力システムをもち、この入出力システムは複数のドライバまたはデータ・マネージャを使用して入出力要求を完了するようにしている。しかし、本発明は、特に断りがない限り、コンピュータ・ハードウェア上で実行される入出力システムのタイプに制約されるものではない。
本発明の範囲に属する実施形態には、実行可能命令を格納しているコンピュータ読取可能媒体も含まれている。かかるコンピュータ読取可能媒体としては、汎用目的または特殊目的コンピュータがアクセスできる媒体ならば、どのような媒体でも利用可能である。例を挙げると、そのようなコンピュータ読取可能媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭや他の光ディスク記憶装置、磁気ディスク記憶装置、または必要とする実行可能命令をストアするために使用できて、汎用目的または特殊目的コンピュータがアクセスできる他の媒体があるが、これらに限定されるものではない。コンピュータ読取可能媒体の範囲には、上記媒体を組み合わせたものも当然に含まれる。実行可能命令の例としては、ある種の関数または関数群を汎用目的コンピュータ、特殊目的コンピュータまたは特殊目的処理デバイスに実行させるための命令とデータがある。最後に、本発明の範囲に属する実施形態には、データ構造を表す複数のデータ・フィールドをそこにストアしておくコンピュータ読取可能媒体が含まれている。
本発明の背景をもっと理解しやすくするために、以下、図１を参照して説明するが、図１はクライアント・プロセスと、入出力要求を処理するために複数のドライバ手段を使用しているオペレーティング・システムとのやりとりを単純化して示したものである。この図は、Mircosoft Windows NT（登録商標）オペレーティング・システムの場合の例を示したものである。また、図１に示すオペレーティング・システムは、入出力要求を処理するために複数のドライバ手段を使用するオペレーティング・システムならば、どのオペレーティング・システムであっても構わない。
図１に示すように、クライアント・プロセス２０は入出力要求を実行するためにオペレーティング・システム・サービス２２を利用している。これは、オペレーティング・システムに用意されているアプリケーション・プログラム・インタフェース（Application Program Interface - API）の関数をクライアント・プロセス２０がコールすることによって行われるのが代表的である。該当のＡＰＩ関数をコールすると、最終的にオペレーティング・システムのサービス２２がコールされる。このコールは矢印２４で示されている。
図１において、クライアント・プロセス２０は「ユーザ」モードで稼働するものとして示され、オペレーティング・システム・サービスは「カーネル」モードで稼働するものとして示されている。最新のオペレーティング・システムは、種々のアプリケーション・プログラムと直観的ユーザ・インタフェースのための強固な環境を提供しているのが代表的である。このようなオペレーティング・システムは、オペレーティング・システムが精巧化されているレベルと、そのオペレーティング・システムに実装されているセキュリティ機能に応じて、異なる動作レベルまたは「モード」をもっているのが通常である。通常のアプリケーション・プログラムは最低プライオリティ（優先度）で実行され、他のアプリケーションとの干渉またはオペレーティング・システムの他の層との干渉を禁止するセキュリティ・デバイスが完備されているのが代表的である。オペレーティング・システムによって提供されるハードウエアやその他のサービスは制御されたインタフェースまたはメカニズムを通してのみアクセスされるようにして、ユーザ・モードのユーザ・アプリケーションや他のプロセスがシステムを「クラッシュ」する可能性を制限している。この最低プライオリティ・モードはユーザ・モードと呼ばれているのが普通で、大部分のコンピュータ・ユーザに親しみのあるモードである。ドライバとその関連ハードウェアは緊密に統合化されているため、また多くのドライバが実行するタスクはその性質上時間を重視しているため、ドライバはプライオリティがはるかに高く、セキュリティ保護がはるかに低いオペレーティング・システムのモードで実行されるのが代表的である。このモードは「カーネル」モードと呼ばれているのが一般である。ドライバおよび他のオペレーティング・システム・サービスをカーネル・モードにすると、オペレーティング・システムをより高いプライオリティで稼働させ、ユーザ・モードでは不可能である多数の関数を実行させることができる。
クライアント・プロセス２０が入出力要求を実行するためにオペレーティング・システム・サービス２２をコールすると、その入出力要求は入出力要求を処理する第１のドライバ手段に渡される。図１では、ファイル・システム・ドライバ２６とデバイス・ドライバ２８は入出力要求を処理するドライバ手段の例を示している。入出力要求が第１ドライバ手段にどのように渡されるかは、例えば、矢印３０で図１に示されている。ファイル・システム・ドライバ２６は入出力要求を受け取ると、入出力要求の一部を処理してからその入出力要求を次のドライバに渡すのが一般的である。本発明で「入出力要求」というときは、入出力システムがサポートする、どのタイプの入出力オペレーションも含まれる。なお、この中には、入出力システムに通常関連している通常のファイル・オペレーション以上のものが含まれることはもちろんである。また、この用語には、入出力システムの拡張機能も含まれる。従って、「入出力要求」という用語は広い意味で解釈されるものである。
１つの例として、クライアント・プロセス２０がディスク上の特定のファイルをオープンして、そのファイルから情報をリトリーブすることを望んでいるとする。この場合、入出力要求はクライアント・プロセス２０からオペレーティング・システム・サービス２２に渡されてからファイル・システム・ドライバ２６に渡される。そのあと、ファイル・システム・ドライバ２６は入出力要求をファイル名からディスク上の特定のロケーションに変換する。この変換プロセスには、特定ロケーションでディスクに読み書きされるデータ・ブロックの数を含めておくことも可能である。この場合、この情報は、例えば、デバイス・ドライバ２８のような、次のドライバに渡すことができる。デバイス・ドライバ２８が必要とする情報を渡すプロセスは図１に矢印３２と３４で示されている。デバイス・ドライバ２８は、読み書きされるデータ・ブロックのロケーションと数を受け取ると、それらを該当の制御信号に変換して必要とする情報をハードウェア・デバイス３６からリトリーブし、あるいは必要とする情報をそこにストアする。リトリーブされた情報はデバイス・ドライバ２８からファイル・システム・ドライバ２６に渡され、最終的には戻り矢印３８に示すようにクライアント・プロセス２０に戻されることになる。ステータス情報も同じように戻される。
図１では、入出力要求はファイル・システム・ドライバ２６とデバイス・ドライバ２８の間で直接に受け渡しされていない。むしろ、入出力要求は入出力マネージャ４０を介してドライバ相互間で受け渡しされている。しかし、どの実装でも入出力マネージャが存在している必要はない。入出力要求があるドライバから別のドライバに直接に渡されるようにする実施形態も可能である。
図１から理解されるように、重要な概念の１つは入出力要求がクライアント・プロセスによって作成されたとき、従来システムでの処理シーケンスが相対的に固定され、未変更のままになっていることである。言い換えれば、特定タイプの入出力要求はそのタイプの入出力要求が受け取られるたびに、まったく同じように処理されることである。入出力要求は最初にあるドライバに渡され、そこで部分的処理が行われてから、その入出力要求は別のドライバに転送され、そこでも入出力要求が部分的に処理されている。一般的に、このプロシージャは、各ドライバが後続のドライバに入出力要求を渡していき、入出力要求が最終的に処理されるまで続けられる。従来のシステムでは、通常の処理シーケンスに割り込みをかけ、コントロールを直前のドライバに戻すか、あるいは特殊タイプの入出力要求を処理する別のドライバに渡すようになっていない。
次に図２を参照して説明すると、図は本発明を実現しているシステムの概要図を示したものである。この場合も、クライアント・プロセス２０は矢印２４に示すように最終的にオペレーティング・システム・サービス２２に転送される入出力要求を行っている。本発明の入出力システムはそのような入出力要求を処理する複数のドライバ手段を含んでいる。例えば、図２では、かかるドライバ手段は層１のドライバ４２、層２のドライバ４４および層Ｎのドライバ４６で示されているが、これらは単なる例示である。
入出力要求はあるドライバ手段から別のドライバ手段に渡されるので、本発明の範囲に属する実施形態では、入出力要求をあるドライバから別のドライバに渡す手段を含めることができる。例えば、図２では、そのような手段は矢印４８と５０で示され、入出力要求があるドライバから別のドライバに直接に渡される様子を示している。この手段としては、図１に示すものと同じように、入出力要求をあるドライバから別のドライバに転送することを取り扱う入出力マネージャにすることも可能である。
図２に示すように、入出力マネージャ４０はクライアント・プロセス２０から受け取った入出力要求を層１のドライバ４２に転送している。この入出力要求は該当の情報を該当のドライバに転送する入出力マネージャや他のメカニズムによってコールされる関数またはサービスの形にすることができる。Microsoft Windows NT（登録商標）では、例えば、入出力システムの種々ドライバ間の通信のためにメッセージ駆動型メカニズムが使用されている。このシステムでは、入出力要求を行うと、入出力マネージャは入出力要求パケット（I/O request packet - IRP）を作成し、そのＩＲＰを該当のドライバに送っている。入出力要求が処理され、他のドライバに転送されるとき、情報がＩＲＰに追加され、そのＩＲＰが次のドライバに渡される。状況によっては、ＩＰＲが修正または「別の形に変換」されてから次のドライバに渡される場合もある。Microsoft Windows NT（登録商標）では、入出力マネージャはドライバ間でＩＲＰを転送することを担当している。他のシステムでは、他のメカニズムが使用可能になっている。これらをどのように実装するかの詳細は設計上の問題であり、本発明にとっては重要でない選択事項である。
図２に戻って説明すると、層１のドライバ４２が必要とされる処理を実行すると、入出力要求は層２のドライバ４４に渡され、そこで必要な処理が行われたあと、その入出力要求は次のドライバに転送される。なお、図２には各ドライバが入出力要求を順番に受け取ることが示されているが、実施形態によっては、あるドライバをスキップして、入出力要求を処理させる必要のあるドライバだけに入出力要求を実際に処理させることが望ましい場合がある。
本発明は通常の処理シーケンスに割り込みをかけ、コントロールを別のドライバに渡すシステムおよび方法を提供しているので、本発明の実施形態によれば、入出力要求の処理に割り込みをかける手段が含まれている。図２に示すように、そのような手段は、例えば、層Ｎのドライバ４６に組み込むことが可能である。本発明では、通常の処理シーケンスは特殊タイプのファイルまたはディレクトリが入出力要求を処理している途中で現れたとき割り込みがかけられる。このような特殊ファイルまたはディレクトリは「再解析ポイント（reparse point）」と呼ばれる。以下で詳しく説明するように、再解析ポイントは特殊な再解析ポイント属性をファイルまたはディレクトリに含めることで作成される。この特殊な再解析ポイント属性はその入出力要求の実行時にドライバによって認識される。この属性が認識されると、入出力要求を処理する通常シーケンスは一時中止され、入出力要求の処理を完了するためのステップがとられる。このステップでは、入出力要求を処理するコントロールが別のドライバに渡され、そのドライバが特殊タイプのファイルまたはディレクトリの入出力要求の処理に参加できるようにされる。従って、本発明の範囲に属する実施形態では、入出力要求を処理するコントロールをあるドライバから別のドライバに渡すための手段が含まれている。入出力要求の処理が途中で割り込まれたとき、コントロールを入出力要求を処理中のドライバから別のドライバに渡すメカニズムならば、どのメカニズムでも利用可能である。図２には、このメカニズムは、例えば、矢印５２で示され、入出力要求の処理の途中で再解析ポイントが現れたとき、入出力要求を処理するコントロールが層Ｎのドライバ４６から層１のドライバ４２に渡されることが示されている。以下で詳しく説明するように、コントロールをあるドライバから別のドライバに渡すメカニズムに要求されることは、ある種の情報を渡して、コントロールを受け取ったドライバが再解析ポイントを正しく処理できるようにすることである。従って、実施形態には、再解析ポイント情報を受け渡すための手段とステータス情報を受け渡すための手段を含めることも可能である。これらのメカニズムは以下で詳しく説明する。
コントロールが層Ｎのドライバ４６から層１のドライバ４２に渡された後、層１のドライバ４２は入出力要求の処理を進めるために再解析ポイントを正しく処理しなければならない。ある種の状況および実施形態では、再解析ポイントが現れたときコントロールを受け取ったドライバは入出力要求を自分で最後まで処理できる場合もある。
そのような状況では、ドライバが入出力要求を最後まで処理した後、結果および／またはステータス情報が必要に応じてクライアント・プロセスに戻されることになる。そのような結果の例を示したのが図２であるが、そこでは層１のドライバ４２は層１のドライバ４２から出た矢印５０で示すように入出力要求の結果を戻している。他方、再解析ポイントが現れたとき入出力要求を最後まで処理する場合でも、他のドライバの援助が必要になる場合がある。従って、本発明の範囲に属する実施形態では、オリジナル入出力要求の処理を継続するために第２の入出力要求を作成するための手段を含めることができる。図２に示すように、このような手段は、例えば、層１のドライバ４２に組み込んでおくことができる。層１のドライバ４２は第２の入出力要求を初めから作成することも、例えば、オリジナル入出力要求を別の形に変換してからその入出力要求を別のドライバに転送することもできる。例えば、Microsoft Windows NT（登録商標）では、このような手段は新しいＩＲＰを作成し、そのＩＲＰを該当のドライバに渡すことによって実現されている。また、この手段は既存のＩＲＰを別の形に変換してからそのＩＲＰを別のドライバに渡すことによっても実現できる。図２では、かかる手段は、例えば、矢印５４で示されており、そこでは作成された入出力要求が層１のドライバ４２から層２のドライバ４４に、最終的に層Ｎのドライバ４６に渡されることが示されている。図７を参照して以下で説明するように、入出力要求を最後まで処理するためには、他のコンピュータによる処理が必要になる場合がある。従って、第２の入出力要求を作成する手段は入出力要求を他のコンピュータに転送することもできる。
層１のドライバ４２が該当の再解析ポイントの処理を終え、オリジナル入出力要求の処理を終えるために別の入出力要求を作成したとすると、層Ｎのドライバ４６はその第２入出力要求を受け取り、該当のハードウェア５６とのインタフェースとなってオリジナル入出力要求を完了することができる。その結果は矢印５０で示すように入出力マネージャ４０に、最終的には矢印５８で示すようにクライアント・プロセスに戻すことができる。
以上を要約すると、本発明は、入出力要求を処理する通常のシーケンスに割り込みをかけて、通常では入出力要求の処理に関与していないドライバが入出力要求の処理に介入できるようにするシステムと方法を提供している。以下で詳しく説明するように、このようなメカニズムはある種の特殊タイプのファイルやディレクトリを実装するときに利用すると、非常に便利である。本発明では、ファイルまたはディレクトリのどちらかに関連づけられた再解析ポイント属性のメカニズムを使用して、通常の処理シーケンスに割り込みをかけ、再解析ポイントを処理するコントロールを特定のドライバに渡すようにしている。このドライバは入出力要求の処理を完了することも、他のドライバを使用して入出力要求の処理を終了するために別の入出力要求を作成することもできる。以下で詳しく説明するように、このメカニズムによると、入出力システムが初めて開発されたとき意図していなかった状況に対処するように、統一された方法で既存の入出力システムの能力を拡張することができる。このように柔軟性があるため、時間と共に進化していく、先進的ファイルとディレクトリ編成構造をサポートする能力が強化されることになる。
その開発当時、ＵＮＩＸオペレーティング・システムは単純化した新しい見方で入出力を定義していた。読み書きされるデータはすべて、仮想ファイルに送られる単純なバイトの流れとして扱われ、仮想ファイルはファイル記述子で表されていた。仮想ファイルとは、あたかもファイルとして扱われる入出力のソースまたはデスティネーションのことである。同様に、ファイルとディレクトリは区別されていなかった。ディレクトリは単純に特殊タイプのファイルとして見られていた。最新のオペレーティング・システムはこの基本的考え方を発展させ、そこではファイルとディレクトリは単純な「属性」の集まりと考えられている。属性は、最も抽象化されたレベルでは、単にデータ記憶ロケーションである。あるファイルまたはディレクトリの異なるプロパティを指定するために異なる属性が使用され、あるいは異なる情報ビットを格納するために異なる属性が使用され、オペレーティング・システムまたは他のプロセスがファイルまたはディレクトリを扱う必要のあるとき、そのファイルまたはディレクトリに関するある種の情報を知ることができるようにしている。例えば、ファイルはプロセスがファイルを特定できるようにする名前属性と、そのファイルにストアされたデータであるデータ属性をもつことができる。ファイルは、次のような他の属性をいくつでももつことができる。つまり、だれがファイルにアクセスでき、どのようにアクセスできるかを示すセキュリティ属性、タイムスタンプ属性、ファイルがどのディレクトリに格納されているかを示す属性などである。ディレクトリも、同じ種類の属性をもつことができるが、ディレクトリはユーザが大量のデータをストアできる場合にはデータ属性をもたないのが普通である。
次に図３を参照して説明すると、図は、本発明で使用するのに適しているファイルまたはディレクトリの属性を絵図で示したものである。これらの属性は、特にMicrosoft Windows NT（登録商標）用に開発されたＮＴＦＳファイル・システムで使用されている属性リストの修正版を示している。ＮＴＦＳファイル・システムは、Helen Custer著「インサイドWindows NTファイル・システム（Inside the Windows NT File System）」、Microsoft Press発行に詳しく説明されているが、その内容は引用により本明細書の一部を構成するものである。図３に示すように、ファイルまたはディレクトリを構成する属性は基本的に２つのグループに分類できる。第１の基本グループは全体が６０で示されており、ファイルとディレクトリの両方に共通の属性を表している。第２の基本グループは全体が６２で示されており、ファイルに固有の属性（図中の左側）またはディレクトリに固有の属性（図中の右側）を含んでいる。
ファイルとディレクトリの両方に共通の属性グループに属するものには、標準情報属性６４、属性リスト６６、名前属性６８、セキュリティ記述子属性７０および再解析ポイント属性７２がある。標準情報属性６４は、次のような“MS-DOS”の標準属性を表している。つまり、ファイルの場合の読取専用、読み書き、隠蔽など、ファイルまたはディレクトリのタイムスタンプ、いくつのディレクトリがファイルをポイントしているか、といった属性である。属性リスト６６は、ファイルまたはディレクトリがマスタファイル・テーブルに占める記憶レコードが２つ以上になったとき、ファイルまたはディレクトリを構成する追加属性のロケーションを特定するためにＮＴＦＳによって使用される属性である。マスタファイル・テーブルは、ファイルまたはディレクトリのすべての常駐属性がそこにストアされるロケーションである。名前属性６８はファイルまたはディレクトリの名前である。ファイルまたはディレクトリは、ＮＴＦＳでは複数の名前属性をもつことができる。例えば、長い名前、MS-DOSでの短い名前、などである。セキュリティ記述子属性７０は、だれがファイルまたはディレクトリを所有し、だれがそれにアクセスできるかを指定するためにWindows NT（登録商標）で使用されるデータ構造を含んでいる。これらの属性は前掲の「インサイドWindows NTファイル・システム」に詳しく説明されている。
再解析ポイント属性７２は本発明で追加された新規属性である。再解析ポイント属性７２はある特定ファイルまたはディレクトリが、入出力システム内の特定ドライバによる特殊処理を必要とする再解析ポイントであることを示している。再解析ポイントは、好ましくは、２つの目標が達成できるだけの十分な情報を収めている。第１の目標は、再解析ポイントを処理させる特定ドライバ（再解析ポイントの所有者）が特定できるようにすることである。さらに、最大限の柔軟性を得るために、好ましいことは再解析ポイントの所有者が再解析ポイントと一緒にデータをストアしておき、所有者があとでそのデータを使用して、再解析ポイントを正しく処理できるようにすることである。ある実施形態では、再解析ポイント属性は次のような構成になっている。
上記テーブルに示す再解析ポイント属性では、再解析ポイント・フラグが示されているが、これはオプションである。再解析ポイント・フラグが上に示されているのは、どのファイルまたはディレクトリが再解析ポイントであるかを特定できるようにするメカニズムの存在が必要であることを示すためである。このような指示は、例えば、有効な再解析ポイント属性を示す再解析ポイント・フラグを使用することで与えることができる。上記とは別に、他のメカニズムを使用することも可能である。例えば、ファイルまたはディレクトリが再解析ポイントでないことを示すために、１つまたは２つ以上のタグ値を予約しておくことも可能である。このようなメカニズムを使用すると、ファイルまたはディレクトリが再解析ポイントでないことを示すために、例えば、タグ０を予約しておくことが可能になる。
上に示した再解析ポイント属性は所有者制御（owner controlled）データ・フィールドも含んでいる。この所有者制御データ・フィールドは、再解析ポイントの所有者が再解析ポイントを正しく処理するために必要とされる、任意のタイプのデータをそこに置いておくことができるロケーションを示している。例えば、所有者がファイルまたはディレクトリの種々属性をリモートにストアすることを扱っていれば、ある種の属性がリモートにストアされるとき、リモートにストアされた属性のロケーションは再解析ポイント属性のデータ・フィールドにストアしておくことができる。
上に示した再解析ポイント属性では、データ・フィールドの前にデータ長インジケータが置かれている。このストレージ・フォーマットでは、データ・フィールドの長さは、データ・フィールドを完成するためにどれだけのデータを読み取る必要があるかを確かめるためにストアされている。別の方法として、実施形態によっては、固定長のデータ・フィールドまたはポインタまたはリンクで１つに連鎖された情報ブロックを使用するデータ・フィールドをストアしておくと、効率化する場合がある。基本的には、データ・フィールドを完成するためにどれだけのデータを読み取る必要があるかを確かめるメカニズムならば、どのメカニズムでも使用できる。所有者ドライバにどれだけのデータをストアさせるかについても考慮しておく必要がある。このような考慮はデータ・フィールドがストアされるときの方法およびデータ・フィールドの可能とされる最大長にも影響することになる。
図３に戻って、次にグループ６２について説明する。そこでは、ファイルで使用される属性とディレクトリで使用される属性との相違点が示されている。ファイルは図３にデータ属性７４で示すように、１つまたは２つ以上のデータ属性をもっているのが代表的である。データ属性７４はユーザ制御データをそこにストアできるロケーションを表している。これはユーザまたはユーザ・プロセスがそこにデータをストアする属性である。ユーザ・プロセスは他の属性にアクセスして、そこにデータをストアできるが、これらの属性はユーザ・プログラムによってだけでなく、ドライバのような他のシステム・リソースによっても理解されるのが一般的である。しかし、ドライバはデータ属性にストアされたデータを理解したり、扱ったりしないのが一般的である。ＮＴＦＳファイル・システムのような、ある種のファイル・システムは２つ以上のデータ属性をもつことが可能になっている。
データ属性７４のほかに、ファイルは他の属性７６で示すように、他の属性をもつこともできる。このような属性はファイルと共にストアされる、他の任意の属性を表している。システムによっては、ユーザ定義の属性を許しているものもあるが、その場合には、他の属性７６はユーザが定義して、ストアした任意の数またはタイプの属性を表している。
ディレクトリで使用される属性としては、例えば、インデックス・ルート属性７８、インデックス・アロケーション属性８０、およびビットマップ属性８２がある。これらの属性の詳しい説明は前掲の文献「インサイドWindows NTファイル・システム」に記載されているが（なお、その内容は引用により本明細書の一部を構成するものである）、基本的にはインデックス・ルート属性７８はディレクトリに格納されたファイルへのインデックスを収めており、インデックス・アロケーション属性８０はデータ・ブロックまたは「クラスタ」のマッピングに関する情報を収めており、ビットマップ属性８２はどのクラスタが使用中で、どのクラスタが解放されているかを記録している。他の属性も、他の属性８４で示すように、ディレクトリの一部として定義して、ストアすることができる。
ある特定タイプのファイルまたはディレクトリに関して若干詳しく上述してきたが、以上の説明は単なる例示的なものであり、本発明の範囲を限定するものではない。本発明は、ファイルまたはディレクトリの既存属性に再解析ポイント属性が追加されていれば、どのタイプのファイルまたはディレクトリでも有効である。別の方法として、既存属性を本発明に取り入れても、その既存属性を利用しても、再解析ポイント属性情報をストアすることができるので、この方法によっても、ファイルまたはディレクトリ内の既存属性の数を増やすことなく再解析ポイント属性を含めることが可能である。
次に、図４を参照して説明すると、図は入出力要求を処理する複数のドライバ手段を含んでいる入出力システムの詳細を示す図である。図４に示す入出力システムはMicrosoft Windows NT（登録商標）で利用されているものと同じ入出力システムにすることができる。入出力要求を処理するために複数のドライバ手段を使用する他のオペレーティング・システムも、同じような構成にすることが可能である。図４を参照して説明する概念は、入出力要求を処理する複数のドライバ手段を含んでいるシステムならば、どのシステムを使用しても実装することが可能である。図４に示す構造の使用は１つの可能な実装例を示したにすぎず、本発明の範囲を限定するものではない。
図４に示す実施形態では、入出力要求を処理する複数のドライバ手段が含まれている。図４において、そのようなドライバ手段は、例えば、全体を８６で示すドライバＡと全体を８８で示すドライバＢで示されている。また、本発明の範囲に属する実施形態では、入出力要求をあるドライバから別のドライバに渡す手段も含まれている。図４には、１つの例として、かかる手段は入出力マネージャ９０として示されているが、これに限定されるものではない。入出力マネージャ９０は、例えば、入出力システムで使用される複数のドライバ間で入出力要求を転送することを受け持つマネージャの代表例である。前述したように、実施形態によっては、入出力マネージャを利用していないものがあり、そこでは種々ドライバは直接に通信し合っている。このような実施形態では、入出力要求をあるドライバから別のドライバに渡す手段は、あるドライバが入出力要求を別のドライバに直接に渡すために使用されるメカニズムになっている。
図４に示すように、ドライバＡ ８６とドライバＢ ８８は、種々の関数を実行するために入出力マネージャ９０がアクセスできるサービスまたはルーチン群を提供している。図４に示すルーチンは利用できるルーチンのうち、Microsoft Windows NT（登録商標）の下で動作するドライバがもつことができる部分を示している。種々ルーチンに関する詳しい説明は、前掲のHelen Custer著「インサイドWindowsNT」、Microsoft Press発行に記載されており、その全内容は引用により本明細書の一部を構成するものである。
ある種のルーチンはドライバＡ ８６とドライバＢ ８８のどちらの場合も、類似の関数を実行している。これらのルーチンの正確な詳細は非常に異なることがあっても、ルーチンの全体目標は同じである。ドライバＡ ８６とドライバＢ８８のどちらの場合も類似の関数を実行するルーチンには、次のものがある。初期化ルーチン９２、スタートＩ／Ｏルーチン９４、割り込みサービス・ルーチン９６、遅延プロシージャ・コール・ルーチン９８、キャンセルＩ／Ｏルーチン１００およびアンロード・ルーチン１０２である。これらのルーチンはドライバがMicrosoft Windows NT（登録商標）などのオペレーティング・システムの下で動作するときに重要であるが、本発明では、一般的には、その目的上重要ではない。しかし、これらのルーチンの機能について、以下で簡単に説明することにする。
ドライバＡ ８６とドライバＢ ８８はどちらも初期化ルーチン９２をもっている。初期化ルーチンはドライバごとに異なることがあっても、初期化ルーチンは、入出力マネージャがドライバをオペレーティング・システムにロードするとき入出力マネージャによって実行される。このルーチンは必要とされる初期化を行って、入出力マネージャがドライバを使用し、アクセスできるようにする。スタートＩ／Ｏルーチン９４はデバイスとの間でやりとりされるデータの転送を開始するために使用される。割り込みサービス・ルーチン９６はドライバが特定ドライバに割り込みを引き起こしたときコールされる。Windows NT（登録商標）の下では、割り込みサービス・ルーチンでの処理は、低レベルの割り込みが必要以上にブロックされるのを防止するために最小限に保たれている。遅延プロシージャ・コール・ルーチン９８は、割り込みサービス・ルーチンが実行された後で、デバイス割り込みを取り扱うことに関係する処理の大部分を実行する。キャンセルＩ／Ｏルーチン１００は入出力オペレーションをキャンセルする必要が起こったときコールされる。アンロード・ルーチン１０２はシステム・リソースを解放して、入出力マネージャがドライバをメモリから除去できるようにする。
Microsoft Windows NT（登録商標）の下のドライバは、ドライバＡ ８６のディスパッチ・ルーチン１０４およびドライバＢ ８８のディスパッチ・ルーチン１０６といった、ディスパッチ・ルーチン群を含んでいる。ディスパッチ・ルーチンはデバイス・ドライバから提供されるメイン関数である。例をいくつか挙げると、読み書き関数や、デバイス、ファイル・システム、またはネットワークのドライバがサポートするその他の機能がある。入出力オペレーションがドライバによって処理されるとき、入出力マネージャ９０は入出力要求パケット（I/O Request Packet - IRP）を生成し、ドライバのディスパッチ・ルーチンの１つを通してドライバをコールする。従って、入出力要求は図４に示すように、ドライバ相互間でまたは入出力マネージャとドライバの間で受け渡しされるＩＲＰで表すことができる。
複数のドライバが使用されるときは、あるドライバは入出力要求の部分的処理を行ってからそのあとに続くドライバにその入出力要求を渡すことができる。このようなプロセスを示したのが図４であり、そこではＩＲＰ １０８がドライバＡ ８６に渡され、ＩＲＰ処理ブロック１１０で示すようにドライバＡによって部分的に処理され、ＩＲＰ １１２を通してドライバＢ ８８に渡されている。なお、ＩＲＰ １０８とＩＰＲ １１２は同じＩＲＰであっても構わない。しかし、ＩＲＰがドライバ間でどのように受け渡しされるかを分かりやすくするために、図４には別の番号が付けられている。また、ＩＲＰ １０８とＩＲＰ １１２が別のものとなるように新しいＩＲＰを作成する実施形態にすることも可能である。
関連の再解析ポイント属性をもつファイルまたはディレクトリの処理と係わりのない入出力要求であるときは、ドライバはその入出力要求を通常通りに処理して、入出力要求に関連する情報を通常通りに返却する。例えば、ＩＲＰ １１２がドライバＢ ８８によって受信されると、その入出力要求はＩＲＰ処理ブロック１１６によって通常通りに処理される。入出力要求を処理している途中で、ドライバＢ ８８はステータス情報および／またはＩＲＰをその前に置かれたドライバに戻すことがある。これは図４にＩＲＰ １１８とステータス１２０で示されている。図４に示されていないが、ＩＲＰ １１８および／またはステータス１２０はドライバＢ ８８による処理の後ドライバＡ ８６に戻される場合がある。これは通常の入出力処理の一部であり、前掲の「インサイドWindows NT」に詳しく解説されているが、その内容は引用により本明細書の一部を構成するものである。
ＩＲＰがドライバによって受信されたとき、ＩＲＰで表された入出力要求は関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている場合がある。図２を参照して前述したように、関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている入出力要求が現れたときは、通常の入出力要求処理に割り込みがかけられ、コントロールは別のドライバに移される。このプロセスを行うために、本発明の範囲に属する実施形態では、入出力要求の処理に割り込みをかける手段が含まれている。このような手段としては、関連の再解析ポイントをもつファイルまたはディレクトリが係わっている入出力要求であるとドライバが認識したとき、その入出力要求の処理を途中で終了してコントロールが別のドライバに渡されるようにするメカニズムならば、どのようなメカニズムであっても構わない。図４には、この手段は、例えば、再解析ポイント検出ブロック１１４で示されている。
入出力要求が関連の再解析ポイント属性をもつファイルまたはディレクトリと係わりがあると再解析ポイント検出ブロック１１４が判断したときは、通常の入出力要求処理は中止され、入出力要求処理責任を再解析ポイントの所有者に引き渡すステップがとられる。図４に示すように、これらのステップは再解析ポイント処理ブロック１２２によって実行される。
再解析ポイント処理ブロック１２２は、コントロールを現在のドライバから再解析ポイントの所有者に引き渡し、再解析ポイントの所有者が入出力要求の処理を継続できるようにするために必要な前処理を実行する。例えば、再解析ポイント属性が前述したようにタグとデータ・フィールドを含んでいれば、再解析ポイント処理ブロック１２２はそのタグとデータ・フィールドを再解析ポイント属性から抜き出し、それらを再解析ポイントの所有者に転送する準備状態に置くことができる。従って、本発明の範囲に属する実施形態では、再解析ポイント情報をドライバに渡すための手段を含めることができる。例えば、図４にはこの手段は解析データ１２４で示されているが、これに限定されるものではない。再解析データ１２４は再解析ポイント処理ブロック１２２で抜き出された再解析情報を表しているだけである。実施形態によっては、再解析ポイント属性を抜き出し、それを再解析ポイントの所有者に直接に渡すようにすることも可能である。基本的には、再解析ポイントの所有者が再解析ポイント属性にストアされた情報にアクセスすることを可能にするメカニズムならば、どのメカニズムでも再解析ポイント情報をドライバに渡す手段として利用することができる。この中には、再解析ポイント情報がそこにストアされているロケーションまたは再解析ポイント属性そのものを指すポインタを渡すことも含まれる。ある実施形態では、再解析データ１２４はＩＲＰに入れられて、別のドライバに渡されている。
以下で詳しく説明するように、ドライバが再解析ポイント情報を調べるとき好ましいことは、再解析ポイントが現れたことをドライバが即時に知ることができるようにすることである。従って、望ましいことは再解析ポイントが現れたことを示すステータス情報を渡すことである。従って、実施形態には、ステータス情報をあるドライバから別のドライバに渡す手段を含めることができる。図４にはこの手段は、例えば、ステータス１２６で示されている。なお、ステータス１２６は単独で渡すことも、解析データ１２４と結合してＩＲＰに入れ、ユニットとして渡すことも可能である。同様に、ステータス情報をＩＲＰに入れ、解析データ１２４を指すポインタまたはリンクをＩＲＰに入れることができる。もう１つの例として、ステータス１２６を渡した後、若干時間を置いてから再解析データを別のＩＲＰに入れて渡すようにすることも可能である。
関連の再解析ポイントをもつファイルまたはディレクトリが係わっている入出力要求であると分かったときは、入出力要求を処理する責任はあるドライバから別のドライバに移される。従って、本発明の範囲に属する実施形態では、入出力要求を処理するコントロールをあるドライバから別のドライバに移すための手段が含まれている。図４に示す実施形態では、この手段は、例えば、完了ルーチン１２８になっている。Windows NT（登録商標）オペレーティング・システム用に書かれたドライバは低レベルのドライバがＩＲＰの処理を終えたあと入出力マネージャによってコールされる１つまたは２つ以上の完了ルーチンを含んでいる場合がある。例えば、ファイル・システム・ドライバとデバイス・ドライバをもつ実施形態では、入出力マネージャは、デバイス・ドライバがファイルとの間でデータ転送を終えたあとファイル・システム・ドライバの完了ルーチンをコールするようになっている。完了ルーチンはオペレーションが成功したか、失敗したかあるいはキャンセルされたかをファイル・システム・ドライバに通知し、ファイル・システムがクリーンアップ（終結処置）オペレーションを実行できるようにしている。従って、通常処理のとき、ドライバＢ ８８がＩＲＰ １１２を受け取り、それを最後まで処理し、ＩＲＰ １１８を戻すと、入出力マネージャ９０はブロック１２８で完了ルーチンをコールし、完了ルーチンは入出力オペレーションが成功したか、失敗したかをドライバＡ ８６に通知し、ドライバＡ ８６がクリーンアップ処理を実行できるようにする。
入出力マネージャ９０は低レベルのドライバがその処理を完了したとき完了ルーチンをコールするので、その完了ルーチンは、関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている入出力要求処理のコントロールが移転したことを検出するメカニズムを置いておく理想的な場所になっている。従って、完了ルーチン１２８は再解析データ１２４および／またはステータス１２６を調べ、ドライバＡ ８６が再解析ポイントの所有者であり、入出力要求の処理責任を任せるべきかどうかを確かめるようになっている。
しかし、関連の再解析ポイント属性をもつファイルまたはディレクトリが係わっている入出力要求の処理責任をドライバが引き受ける前に、そのドライバはそれが再解析ポイントの所有者であるかどうかを確かめなければならない。本発明の範囲に属する実施形態では、特定のドライバによって受信された再解析ポイント情報がそのドライバによって所有されているかどうかを確かめる手段を含めることができる。例えば、図４にはこの手段は再解析ポイント検出ブロック１３０で示されているが、これに限定されるものではない。再解析ポイント検出ブロック１３０は再解析データ１２４および／またはステータス１２６を調べ、ドライバＡ ８６が再解析ポイントの所有者であるかどうかを確かめる。ドライバＡ ８６が再解析ポイントの所有者でなければ、ドライバＡ ８６は完了処理ブロック１３２で示すように、必要とされる通常完了処理を実行し、再解析データ１２４および／またはステータス１２６を入出力マネージャ９０に渡し、そこから別のドライバに転送されるようにする。
他方、ドライバＡ ８６が再解析ポイントの所有者であると再解析ポイント検出ブロック１３０が判断したときは、コントロールは再解析ポイント処理ブロック１３４に渡され、入出力要求の以後の処理が行われる。入出力要求の処理コントロールを受け取ること以外は、ドライバが自身が再解析ポイントの所有者であると判断されたときなにが行われるかは、本発明では未定義である。しかし、一般的には、ドライバは入出力要求の処理責任を引き受けて、入出力要求を完了させるステップをとることになる。ある実施形態では、再解析ポイントの所有者であるドライバは、入出力要求の処理を最後まで行うことが可能になっている。そのような実施形態では、ドライバが入出力要求の処理を終えると、通常の完了手続きがとられることになる。Microsoft Windows NT（登録商標）の場合には、この中には、必要な情報をＩＲＰに入れて入出力マネージャに送り返し、そこから転送されることが含まれている。上位レベルのドライバの完了ルーチンをコールして、ドライバに必要なクリーンアップ処理を行わせたり、入出力要求のステータスをドライバに通知したりすることを含めることも可能である。
実施形態によっては、再解析ポイントの所有者であるドライバは入出力要求の残り部分を単独で最後まで処理できない場合がある。そのような実施形態では、再解析ポイント処理ブロック１３４はＩＲＰを生成し、そのあとＩＲＰは他のドライバに渡されて入出力要求の処理を続けるようにしている。別の方法として、図７を参照して説明するように、入出力要求を生成したあと、別のコンピュータに渡して以後の処理を行わせることも可能である。従って、本発明の範囲に属する実施形態では、オリジナル入出力要求の処理を継続するために別の入出力要求を作成する手段を含めることが可能である。そのような手段としては、他のドライバの援助を得て入出力要求を完了するために特定の実施形態で利用されるメカニズムが利用できる。例えば、図４には、別の入出力要求を作成する手段は再解析ポイント処理ブロック１３４とＩＲＰ １３６で示されている。ＩＲＰ １３６は、例えば、図４のドライバＢ ８８と同じように、別のドライバに渡すことができる。ドライバＢ ８８はＩＲＰ １３６を受け取ると、それを他のＩＲＰと同じように処理する。再解析ポイント処理ブロック１３４はＩＲＰ １３６を作成するとき、そのＩＲＰを初めから作ることも、既存のＩＲＰを受け取ってそのＩＲＰを「別の形に変換」することもできる。この変換プロセスは既存のＩＲＰを受け取ると、そのＩＲＰ内の情報を変更して修正版または新規ＩＲＰを作成する。別の入出力要求を作成する手段はシステムが異なるごとに、異なる方法で実装することができる。例えば、あるドライバが別のドライバを直接にコールするようなシステムでは、別の入出力要求を作成する手段は、情報がアセンブルされたあと、直接コール・メカニズムを通して別のドライバに渡されるようにするメカニズムにすることができる。基本的には、必要なことは入出力要求を作成または修正したあと、別のドライバに渡して以後の処理を任せることである。
上記プロセスを具体的に説明するために、以下では、関連の再解析ポイント属性をもつディレクトリが係わっている入出力要求を処理する具体例について図５と図６を参照して説明する。まず、図５を参照して、入出力システムの全体構造について説明する。図５において、クライアント・プロセス１３８は入出力要求を処理する複数のドライバ手段を備えた入出力システムへのコールを行う。クライアント・プロセス１３８はオペレーティング・システム・サービス１４０へのコールを行う。入出力マネージャ１４２は入出力要求を受け取り、入出力要求の転送を入出力システムの種々ドライバ間で調整する。
図５には、入出力要求を処理する複数のドライバ手段が示されている。ドライバ手段はシンボリックリンク・デコーダ１４４、分散ファイル・マネージャ１４６、階層ファイル・システム・マネージャ１４８、ファイル・システム・ドライバ１５０、およびディスク・ドライバ１５２から構成されている。シンボリックリンク・ドライバ１４４は入出力要求にシンボリックリンクがあれば、それをデコードすることを担当する。分散ファイル・システム・マネージャ１４６は複数の物理ボリュームにまたがって分散されたファイルを、１つの統合ボリュームであるかのように管理する。階層ファイル・システム・マネージャ１４８はアクセス頻度の低いファイルを除去し、それらをテープ上などのリモート・ロケーションにストアする。また、階層ファイル・システム・マネージャ１４８はリモートにストアされたファイルをその必要時にリトリーブすることも担当する。ファイル・システム・ドライバ１５０はファイルまたはディレクトリへのアクセス要求をディスク上の物理ロケーションに変換することを担当する。ディスク・ドライバ１５２は情報をディスク１５４からリトリーブしたり、情報をディスク上に配置することを担当する。以上のように、図５の入出力システムは、各々が独自の関数または関数群を担当する複数のドライバを使用して強固な入出力環境を提供している。
次に図６を参照して説明すると、図は２つの異なるディスク・ボリュームの論理構造を示している。ボリューム１は図６に１５６で示すように、Ｃと名づけたルート・ディレクトリをもっている。ディレクトリＣは名前がＡで番号が１５８であるファイルと、名前がＢで番号が１６０であるディレクトリを収めている。図６に示すように、ファイルＡ １５８はタグが５で、なんらかのデータ値をもつ再解析ポイントである。ディレクトリＢ １６０はＥ １６２と名づけたファイルと、Ｄ １６４と名づけたディレクトリを収めている。図６に示すように、ディレクトリＤ １６４はタグがDFSMで値がＷである、関連の再解析ポイントをもっている。タグがDFSMであることは、再解析ポイントが分散ファイル・システム・マネージャ１４６によって所有されていることを示している。以下の例で説明するように、このタグと値はディレクトリＤでボリューム２に接ぎ木するマウントポイントを作るために使用される。このマウントポイントは図６に矢印１６６で示されている。ボリューム２はＷ １６８と名づけたルート・ディレクトリをもっている。ディレクトリＷ １６８はディレクトリＸ １７０とディレクトリＹ １７２を収めている。ディレクトリＹはファイルＺ １７４を収めている。
図５に戻り、クライアント・プロセス１３８がパス名C＼B＼D＼Y＼Zと係わりをもつ入出力要求を作成したとする。この入出力要求はファイルＺ １７４にデータを読み書きするものとする。この場合、パス名はファイルＺ １７４にアクセスするためにクライアント・プロセス１３８によって使用される。クライアント・プロセス１３８は、矢印１７６で示すようにサービス１４０をコールすることによってこの入出力要求を送信する。入出力マネージャ１４２はＩＲＰ１７８を作成し、ＩＲＰ １７８をシンボリックリンク・デコーダ１４４に渡す。図４と同じように、入出力マネージャ１４２は入出力要求をあるドライバから別のドライバに渡す手段の１つの例である。
クライアント・プロセス１３８から出された入出力要求を満たすためには、ファイルのパス名C＼B＼D＼Y＼Zを解決する必要がある。一般的に、名前解決はマルチステージ・プロセスであり、これによれば、名前はその構成要素に分解され、各構成要素は、通常左から右に向かって解決されていき、成功したか、失敗したかが解決プロセスの各ステージで判断される。ＩＲＰ １７８がシンボリックリンク・デコーダ１４４に渡されるとき、解決する必要のあるパス名がＩＲＰの一部として渡される。シンボリックリンク・デコーダ１４４がどのように実装されているかにもよるが、シンボリックリンク・デコーダ１４４はＩＲＰ１７８内のパス名をスキャンしてパス名の構成要素のどれかがシンボリックリンクであるかどうかを確かめることができる。他の実装も可能であり、どのように実装するかは入出力システムにおける設計上の考慮事項によって決まる。図６に示す例では、シンボリックリンクがないために、シンボリックリンク・デコーダ１４４はＩＲＰ １７８を分散ファイル・マネージャ１４６に渡すことになる。前述したように、Microsoft Windows NT（登録商標）では、ＩＲＰの受け渡しは入出力マネージャ１４２を経由して行われることになる。
ＩＲＰ １７８は分散ファイル・マネージャ１４６によって受信され、このマネージャは、前述したように、複数ボリュームのファイル・システムを管理し、それらを１つの論理ファイル・システムに統合化することを担当している。この例では、分散ファイル・システム１４６は、解決プロセスのこのステージではＩＲＰ １７８で多くの処理をしないことが想定されている。分散ファイル・システム１４６は、例えば、図６に示すように最初の構成要素Ｃがボリューム１に属するものと判断するだけにすることができる。そのあと、ＩＲＰ １７８は階層ファイル・システム・マネージャ１４８に渡される。この場合も、階層ファイル・システム・マネージャ１４８はＩＲＰ １７８の処理をほとんど、あるいはまったく行わないで、それをファイル・システム・ドライバ１５０に渡すことが想定されている。
そのあと、ファイル・システム・ドライバ１５０は名前解決プロセスを開始する。ファイル・システム・ドライバ１５０は図６のディレクトリＣ １５６から始めて、ディレクトリＣ １５６をディスク１５４上の物理ロケーションに変換する。この情報はＩＲＰ １７８に入れられ、ディスク・ドライバ１５２に渡される。そのあと、ディスク・ドライバ１５２はディスク１５４にアクセスし、ＩＲＰ １８０に情報を入れて戻し、ファイル・システム・ドライバ１５０が解決プロセスを継続することを可能にする。このプロセスはパス名の各構成要素ごとに繰り返される。
図６に戻って説明すると、ファイル・システム・ドライバ１５０はディレクトリＣ １５６から開始し、ディレクトリＢ １６０に移り、ディレクトリＤ １６４に進んでいく。ディレクトリＤ １６４がディスクからリトリーブされたときは、ファイル・システム・ドライバ１５０はディレクトリＤが関連の再解析ポイント属性をもつものと認識することになる。そのあと、ファイル・システム・ドライバ１５０に組み込まれていて、入出力要求の処理に割り込みをかける手段は入出力要求の通常の処理シーケンスに割り込みをかけることになる。図４を参照して上述したように、ファイル・システム・ドライバ１５０は、ディレクトリＤ １６４の再解析ポイント属性から再解析データを抜き出すことができる。再解析ポイント属性がタグとデータ値をもっているとすると、前述したように、この情報が抜き出され、次の上位レベル・ドライバに戻されることになる。図５には、これは再解析データ１８２で示されている。図５の再解析データ１８２は再解析ポイント情報をドライバに渡す手段のもう１つの例を示している。このケースでは、図６に示すように、タグはデータベースであり、値はＷになっている。この例では、タグDFSMは分散ファイル・システム・マネージャ１４６が再解析ポイントの所有者であることを示している。
図５の再解析ポイント・データ１８２は図示のように階層ファイル・システム・マネージャ１４８に転送される。階層ファイル・システム・マネージャ１４８によって受信される再解析ポイント情報がそのドライバによって所有されているかどうかを判別する手段は、再解析データ１８２が階層ファイル・システム・マネージャ１４８によって所有されているかどうかを判別することになる。この手段は図４を参照して前述したように、階層ファイル・システム・マネージャ１４８の完了ルーチンに実装させることができる。このケースでは、階層ファイル・システム・マネージャ１４８は図６の解析ポイント１６４の所有者となっていない。再解析データ１８２が階層ファイル・システム・マネージャ１４８によって所有されていないと判断したあと、階層ファイル・システム・マネージャ１４８は再解析データ１８２を図５に示す次の上位レベル・ドライバに転送する。
分散ファイル・システム・マネージャ１４６は再解析データ１８２を受け取ると、再解析データ１８２が分散ファイル・システム・マネージャ１４６によって所有されているかどうかを判別する。これは、分散ファイル・システム・マネージャ１４６によって受信された再解析ポイント情報がそのドライバによって所有されているかどうかを判別する手段を通して行われる。この手段は図４を参照して前述したように、完了ルーチンに実装させることができる。図６に示す例では、分散ファイル・システム・マネージャ１４６は再解析データ１８２を調べ、自分が所有者であると認識することになる。これは、特定のドライバが入出力要求の少なくとも一部を処理させるドライバであると判断する手段によって行うことができる。前述したように、かかる手段の例としては、再解析データ１８２のタグがある。言い換えれば、分散ファイル・システム・マネージャ１４６は、再解析データ１８２のタグ値を自身が所有するタグ値と突き合わせることで、再解析データ１８２が自分のものであると認識することができる。
ドライバが再解析データを自分が所有するものであると認識すると、そのドライバはその入出力要求の処理を継続する責任を引き受けることになる。入出力要求の処理を続けるために、ドライバは再解析ポイント属性のデータ値を調べ、そこにストアされている情報を使用して入出力要求を処理するのが代表的である。このケースでは、分散ファイル・システム・マネージャ１４６はマウントポイントのターゲットをデータ値にストアする。次に図６に戻って、ディレクトリＤ１６４に関連する再解析ポイントのデータ値を調べれば分かるように、データ値はＷになっている。これはボリューム２のディレクトリＷであることを示している。分散ファイル・システム・マネージャ１４６はデータ値を調べれば、ボリューム２のディレクトリＷがマウント・ポイントのターゲットであることを知ることができる。そのあと、分散ファイル・システム・マネージャ１４６は、ボリューム２のディレクトリＷから始まって、解決プロセスを継続していくＩＲＰを作成することができる。ボリューム２のディレクトリＷから始まって、名前解決プロセスを継続していく第２のＩＲＰを作成するためには、分散ファイル・システム・マネージャ１４６はオリジナル入出力要求の処理を継続する第２の入出力要求を作成するための手段を採用することができる。この手段は図４を参照して前述したように実装することができる。名前解決プロセスをどのように進めるかを判断するために非常に望ましいことは、再解析ポイントが現れる前に名前解決プロセスがどこまで進んだかを分散ファイル・システム・マネージャ１４６が判断できるようにすることである。従って、実施形態によっては、オリジナルのパス名とオフセットを戻して、再解析ポイントが現れる前に名前解決プロセスがどこまで進んだかを判断できるようにすることが望ましい場合がある。この例では、パス名はC＼B＼D＼Y＼Zになっている。この場合、オフセットがディレクトリＤを指しているのは、それが再解析ポイントが見つかった場所であるからである。名前解決プロセスを継続する別のＩＲＰを作成するとき、分散ファイル・システム・マネージャ１４６は名前のうちすでに解決されている部分を取り除き、解決プロセスをそこから継続させるロケーション、つまり、図６のディレクトリＷ １６８で再解析ポイントＤを置き換えることを選択することができる。そのような場合には、新しいパス名はW＼Y＼Zとなる。そのあと、分散ファイル・システム・マネージャ１４６はこの情報をＩＲＰ １８４に入れて、ＩＲＰ １８４を階層ファイル・システム・マネージャ１４８に渡すことができる。
そのあと、階層ファイル・システム・マネージャ１４８はＩＲＰ １８４をファイル・システム・ドライバ１５０に転送する。ファイル・システム・ドライバ１５０は図６のディレクトリＷから始まって名前解決プロセスを継続していく。名前解決プロセスはディレクトリＹ １７２に移り、ファイルＺ １７４に到達するまで続けられる。このプロセスでは、図５に示すように、ＩＲＰ １８４がディスク・ドライバ１５２に渡され、ＩＲＰ １８６がディスク・ドライバ１５２から戻されている。なお、名前解決プロセスでは、ファイル・システム・ドライバ１５０とディスク・ドライバ１５２の間でＩＲＰ １８４と１８６がなん度も受け渡しされる場合がある。また、ＩＲＰ １８６はＩＲＰ １８４と同じにすることができ、ＩＲＰ １７８はＩＲＰ １８０と同じにすることができる。これらが図５に異なる番号で示されているのは、ディスク・ドライバ１５２が入出力オペレーションの結果をそこに入れることでＩＲＰを修正できることを示すためにすぎない。
図６のファイルＺ １７４が係わりをもつ、必要とする入出力オペレーションが実行され、結果がＩＲＰ １８６に入ってファイル・システム・ドライバ１５０に戻されると、ファイル・システム・ドライバ１５０はＩＲＰ １８６を階層ファイル・システム・マネージャ１４８に返送することになる。図５に示すように、ＩＲＰ １８６は分散ファイル・システム・マネージャ１４６とシンボリックリンク・デコーダ１４４に連続的に渡されていき、最終的に結果は矢印１８８で示すようにクライアント・プロセス１３８に戻されることになる。
次に図７を参照して説明する。図７は再解析ポイント属性が現れたとき入出力要求が別のコンピュータ・システムに送られて処理を任せるようにした場合の例を示している。図７に示す実施形態では、クライアント・プロセス１９０はローカル・コンピュータ１９２で実行されている。ローカル・コンピュータ１９２はコンピュータ相互間を接続するネットワーク手段を介してリモート・コンピュータ１９４に接続されている。図７において、このネットワーク手段はネットワーク・カード１９６とコネクション１９８で示されている。ローカル・コンピュータ１９２の入出力システム２００は入出力要求を処理する複数のドライバ手段を含んでいる。図７において、このドライバ手段は、例えば、シンボリックリンク・デコーダ２０２、ファイル・システム・ドライバ２０４およびディスク・ドライバ２０６で示されている。入出力システム２００はオペレーティング・システム・サービス２０８と入出力マネージャ２１０も含んでいる。図５に示すと同じように、クライアント・プロセス１９０はオペレーティング・システム・サービス２０８へのコールを行う。入出力マネージャ２１０は入出力要求を受け取り、入出力システムの種々ドライバ手段相互間の入出力要求の転送を調整する。別の方法として、入出力システムの種々ドライバ手段は、種々ドライバ手段相互間の情報転送を調整する入出力マネージャや他のデバイスによらなくても、相互に直接に通信し合うようにすることも可能である。
この例では、クライアント・プロセス１９０は、リモート・コンピュータ１９４に接続されたディスク上に置かれたファイルまたはディレクトリを指すシンボリックリンクが係わりをもつ入出力要求を行うものと想定されている。例えば、クライアント・プロセス１９０が、リモート・コンピュータ１９４に接続されたディスク２１２に置かれているディレクトリへのシンボリックリンクをもつディレクトリの内容をリストするために入出力要求を行ったとする。この入出力要求は、例えば、クライアント・プロセス１９０が矢印２１４で示すようにオペレーティング・システム・サービス２０８をコールすることによって行われる。入出力要求はファイル・システム・ドライバ２０４に渡され、このドライバはディスク・ドライバ２０６を利用して名前解決プロセスを開始する。ディスク・ドライバ２０６はディスク・コントローラ２１８を使用してディスク２１６から情報を読み取る。名前解決プロセスは、前述したように、シンボリックリンクを表している再解析ポイントが見つかるまで続けられる。その個所で、再解析ポイント情報が抜き出され、他のドライバに渡されるが、これはあるドライバが自分が再解析ポイントの所有者であると認識するまで続けられる。この例では、シンボリックリンク・デコーダ２０２が、リモート・コンピュータ１９４へのシンボリックリンクを実装するために使用された再解析ポイントの所有者であると認識することになる。
シンボリックリンク・デコーダ２０２は自身が再解析ポイントの所有者であると認識すると、シンボリックリンク・デコーダ２０２は入出力要求を処理する責任を引き受けることになる。この例では、シンボリックリンク・デコーダ２０２が入出力要求を単独で最後まで処理できないのは、入出力要求を処理するためにリモート・コンピュータ１９４からディレクトリ情報をリトリーブする必要があるためである。そのような場合には、本発明の範囲に属する実施形態では、入出力要求をリモート接続のコンピュータに送って処理させる手段を含めることが可能である。図７に示すように、ローカル・コンピュータ１９２とリモート・コンピュータ１９４がネットワーク手段で接続されているような実施形態では、入出力要求をリモート接続のコンピュータに送る手段は、入出力要求をネットワーク経由でリモート・コンピュータ１９４に転送し、リモート・コンピュータ１９４に入出力要求を処理させ、要求を満たすようにするメカニズムならば、どのようなメニズムにすることもできる。例えば、図７において、入出力要求をリモート接続のコンピュータに送る手段はリディレクタ（redirector）２２０とネットワーク・トランスポート・ドライバ２２２で構成することが可能である。図７に示す実施形態では、リディレクタ２２０はローカル・コンピュータ１９２がネットワーク上の他のマシン上のリソースにアクセスするとき必要になる機能を備えている。ネットワーク・トランスポート・ドライバ２２２は、情報をローカル・コンピュータ１９２からネットワーク・カード１９６とコネクション１９８を経由してリモート・コンピュータ１９４へ転送できるようにするメカニズムを備えている。入出力要求をリモート接続のコンピュータに送る手段は他のメカニズムを使用して実装することも可能である。一般的に、この手段は入出力要求をあるコンピュータから別のコンピュータに転送するトランスポート・メカニズムを備えている。このようなメカニズムは、専用リンク、ローカルエリアネットワーク（LAN）、広域ネットワーク（WAN）、電話回線、ワイヤレス（無線）などのように、任意のタイプのコネクションで２コンピュータ間を結ぶことを可能にしているのが一般である。さらに、この手段は、あるコンピュータの入出力システムから入出力要求を受け取り、その入出力要求を別のコンピュータの入出力システムに発送するメカニズムを含むこともできる。このためには、種々タイプのソフトウェアやファームウェアまたはドライバが必要になる。入出力要求をリモート接続のコンピュータに送る手段に要求されることは、リモート・コンピュータで処理できるフォーマットで入出力要求を発送することである。
図７の実施形態では、シンボリックリンク・デコーダ２０２はリモート・コンピュータ１９４に入出力要求を行う必要があると認識したときは、シンボリックリンク・デコーダ２０２は入出力要求をリディレクタ２２０に渡せば、リディレクタ２２０がネットワーク・トランスポート・ドライバ２２２を使用して入出力要求をネットワーク・カード１９６とコネクション１９８経由でリモート・コンピュータ１９４に転送してくれる。この具体例では、入出力要求はシンボリックリンクが指しているディレクトリのディレクトリ内容に対するものである。
リモート・コンピュータ１９４に渡された入出力要求はネットワーク・トランスポート・ドライバ２２４によって受信され、サーバ・ファイル・システム２２６に渡される。サーバ・ファイル・システム２２６はリディレクタ２２０と通信して、リモート・コンピュータ１９４に送られた入出力要求を処理し、その要求満たすようにする。入出力要求を満たすためには、サーバ・ファイル・システム２２６はファイル・システム２２８やディスク・コントローラ２３０のような、リモート・コンピュータ１９４のドライバとハードウェアを利用することができる。この例では、サーバ・ファイル・システム２２６はファイル・システム・ドライバ２２８を利用して、該当のディレクトリ内容をディスク２１２からリトリーブし、そのディレクトリ内容をローカル・コンピュータ１９２に戻している。ディレクトリ内容が戻されたとき、シンボリックリンク・デコーダ２０２はそのディレクトリ内容をクライアント・プロセス１９０に送り返すことができる。
図７に示す実施形態では、ローカル・コンピュータ１９２とリモート・コンピュータ１９４の間で通信を行う特定のコンポーネントが含まれているが、そのようなコンポーネントはすべての点で例示的なものである。本発明で必要とされるものは、入出力要求がローカル・コンピュータ側のドライバからリモート・コンピュータに渡されて、そこで入出力要求が満たされ、該当の情報が戻されるようにするメカニズムである。上記機能を然るべき方法で実行するメカニズムであれば、どのメカニズムも本発明の範囲に属するものである。
本発明を全体にわたって理解するのを容易にするために、次に図８を参照して説明する。図８は、本発明を使用して入出力システムの能力を拡張する実施形態を示すトップレベル図である。一般的に、入出力システムはハードウェア・デバイスとの間でデータを送受信するために使用される。そのようなハードウェア・デバイスとしては、前述したように大容量記憶デバイスや、図７に示すようなネットワークを含む他のタイプのハードウェア・デバイス、またはデータの送信側またはデータの使用側となる他のタイプのデバイスがある。実際には、キーボードやディスプレイなどのデバイスであっても、具体的な実装と環境にもよるが、入出力システムの一部で制御することが可能である。一般的に、クライアント・プロセスはデータを特定のハードウェア・デバイスに送るために、あるいはデータを特定のハードウェア・デバイスからリトリーブするために、入出力要求を入出力システムに送っている。さらに、入出力システムはハードウェア・デバイスからの情報があるとき、そのことをクライアント・プロセスに通知することができる。前述したように、入出力要求は広義の意味に解釈されるものである。従って、入出力要求には、クライアント・プロセスと入出力システムとの間のすべてのやりとりを含めることができ、その中には、データを入出力要求を送り込んだり、データを入出力システムから受け取ったりする要求も含まれる。
図８に示すように、全体的ハードウェア・デバイスはハードウェア・デバイス２３２で示されている。上に示した例で説明したように、特定のハードウェア・デバイスにアクセスするためには、１つまたは２つ以上のドライバを入出力システムで使用することができる。図８に示すように、ハードウェア・デバイス２３２にアクセスするために使用されるドライバはハードウェア・アクセス・ドライバ２３４で示されている。ハードウェア・アクセス・ドライバ２３４は入出力要求を処理するドライバ手段のもう１つの例である。ハードウェア・アクセス・ドライバ２３４は、ハードウェア・デバイス２３２にアクセスするために必要とされる任意の数またはタイプのドライバにすることができる。ハードウェア・デバイス２３２が、例えば、ディスクであれば、ハードウェア・アクセス・ドライバ２３４はファイル・システム・ドライバとディスク・ドライバの一方または両方にすることができる。ハードウェア・デバイス２３２がネットワーク・デバイスであれば、ハードウェア・アクセス・ドライバ２３４はネットワークにアクセスするために必要とされる任意の数またはタイプのドライバにすることができる。このようなことが起こるのは、例えば、ネットワーク経由で大容量記憶デバイスにアクセスする場合である。
入出力システムの能力を拡張し、当初から入力システムに組み込まれていなかった別の機能を追加するためには、処理される入出力要求の特定タイプ別に１つまたは２つ以上の拡張デバイスを追加することができる。図８には、この特定タイプのドライバは拡張ドライバ２３６で示されている。拡張ドライバ２３６は可入出力要求を処理するドライバ手段のもう１つの例である。拡張ドライバ２３６は上記の例で前述した一般的原理に従って再解析データを処理するドライバ層を代表しているのが一般である。前述したように、通常の入出力オペレーション時には、拡張ドライバ２３６は入出力要求の処理の一部になっていない。しかし、再解析ポイントがハードウェア・アクセス・ドライバ２３４によって検出されたときは、コントロールが拡張ドライバ２３６に渡され、拡張ドライバ２３６が入出力要求の処理に介入できるようにする。
前述したように、拡張ドライバ２３６がコントロールを受け取ったとき、そのあと行われる処理は本発明では未定義になっている。本発明はどのタイプの処理を行うためにも使用できる。１つの例では、再解析ポイントはホーム・オートメーション環境で設定されている。再解析ポイントにアクセスするとき、コントロールが拡張ドライバに渡されると、拡張ドライバは再解析ポイントに見合ったアクションをとる。例えば、おそらくは、消防署または警察署の電話番号が再解析ポイント情報の一部としてストアされることになる。出された入出力要求が再解析ポイントと係わりがあるときは、コントロールを特定のドライバに渡すことができるので、その特定ドライバは再解析ポイントから電話番号を抜き出し、警察署または消防署にダイヤルすることになる。警察署または消防署に連絡をしたあと、合成音声は他のオーディオ情報を送信するといった、該当アクションがとられ、具体的状態が警察署または消防署に通知されることになる。基本的には、入出力システムが再解析ポイントを見つけ、コントロールが特定の拡張ドライバに渡されて処理が行われるとき、そのあとなんらかのアクションがとられる。このアクションには、入出力システムまたは記憶デバイスにストアされたファイルや他の情報とは通常無関係であるアクションも含まれている。
拡張ドライバ２３６のように、拡張ドライバが入出力要求の処理責任を引き受けたときは、拡張ドライバはなんらかの処理を行うことができる。拡張ドライバは、該当するものがあれば、他のサービスまたはドライバを利用してそのタスクを完了することができる。図８に示すように、この他のドライバまたはサービスは拡張ドライバ・サービス２３８で示されている。拡張ドライバ・サービス２３８は、拡張ドライバ２３６がそのタスクを完了するために利用しなければならない他のドライバまたはサービスにすることができ、この中にはハードウェア・ドライバが含まれる。当然のことであるが、このような機能は、具体的にどのように実装し、その実装のためにどのような設計上の選択を行うかに応じて、単独にすることも、拡張ドライバ２３６に直接に組み込むことも可能である。
最後に、注目すべきことは、入出力要求を完了するために必要または望ましい情報は再解析ポイントからでも、オリジナル入出力要求からでも、あるいはその両方からでも得ることができることである。オリジナル入出力要求は、再解析ポイント内の情報と共に、拡張ドライバ２３６が利用することができる。
以上を要約すると、本発明は入出力要求の通常処理に割り込みをかけ、通常では入出力要求の通常処理に関与していないドライバが入出力要求の処理責任を引き受けることを可能にするメカニズムを提供している。本発明が定義している方法とシステムは柔軟性を備えていると同時に、拡張可能性も備えている。本発明は通常の処理シーケンスに介入することを可能にする方法だけは別として、入出力要求を処理するときの正確な詳細を定義していないので、本発明を利用すれば広範囲にわたる結果を達成することができる。基本的には、本発明のメカニズムによれば、特殊タイプのファイルまたはディレクトリを定義しておけば、その特殊ファイルまたはディレクトリが係わりをもつ入出力要求の処理コントロールを、特殊ファイルまたはディレクトリが係わりをもつ入出力要求を処理するのに適した特定のドライバに渡すことができる。本発明の用途として、分散ファイル・システムをシングル・ファイル・システムであるかのように管理する場合について説明してきたが、本発明は、階層ストレージを管理し、セキュアまたは暗号化ファイルまたはディレクトリを管理し、最新コンピュータで広く採用されている階層方式とは別の新規の方法でファイルまたはディレクトリのアクセスまたは編成を管理する場合にも利用することができ、特殊タイプのファイルまたはディレクトリが定義される場合には考案または開発が可能である他の用途にも利用が可能である。さらに、入出力要求を処理するのに適したドライバにコントロールが渡されたあと、それ以後に行われる処理はファイルまたはディレクトリが係わっている従来の入出力オペレーションとは無関係にすることができる。特殊ドライバは必要とするタスクに見合ったリソース、ドライバまたはシステムを使用してどのような処理でも行うことができる。
本発明は、本発明の精神または基本的特徴から逸脱しない限り、他の具体的実施形態で実現することが可能である。上述してきた実施形態はすべての点で例示的なものであり、その実施形態に限定されるものではない。従って、本発明の範囲は上述してきた説明に限定されるのではなく、請求の範囲の記載によってのみ限定されるものである。請求の範囲の意味と等価範囲内に属する変更はすべて本発明の範囲に包含されるものである。
Claims (31)
- 複数のドライバ手段を使用して入出力要求を処理する入出力システムにおいて通常の処理シーケンスに割り込みをかける方法であって、前記複数のドライバ手段は第１ドライバ手段と第２ドライバ手段を含み、
該方法は、
指定された入出力オペレーションを実行する入出力要求を前記第１ドライバ手段によって受け取るステップと、
前記第１のドライバ手段が、前記入出力要求が関連の再解析ポイント属性をもつファイルまたはディレクトリのどちらかの少なくとも１つと係わりがあるかどうかを判別することによって、前記入出力要求が別のドライバ手段による少なくとも部分的処理を必要としているかどうかを判別するステップであって、前記再解析ポイント属性は、特定のファイル又はディレクトリが前記入出力システム内の特定のドライバによる特殊処理を必要とする再解析ポイントであることを示す、ステップと、
前記ファイルまたはディレクトリのどちらかの少なくとも１つが関連の再解析ポイント属性をもっていれば、該第１ドライバ手段が、
前記ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント情報を前記再解析ポイント属性から抜き出すステップであって、前記再解析ポイント情報は、前記再解析ポイントを処理すべき前記特定のドライバを特定する、ステップと、
前記抜き出した再解析ポイント情報を前記第２ドライバ手段に渡して処理させるステップと
を備えることを特徴とする方法。 - 請求項１に記載の通常の処理シーケンスに割り込みをかける方法において、前記抜き出した再解析ポイント情報を前記第１ドライバ手段から前記第２ドライバ手段によって受け取るステップと、
追加のドライバ手段を使用して前記入出力要求を処理するステップと
をさらに備えることを特徴とする方法。 - 請求項１または２に記載の通常の処理シーケンスに割り込みをかける方法において、前記複数のドライバ手段は他のドライバ手段を含み、
該方法は、
前記抜き出した再解析ポイント情報を前記第１ドライバ手段から前記第２ドライバ手段によって受け取るステップと、
入出力要求を前記他のドライバ手段に該第２ドライバ手段によって送信するステップと
をさらに備えることを特徴とする方法。 - 請求項１ないし３のいずれかに記載の通常の処理シーケンスに割り込みをかける方法において、前記ファイルまたはディレクトリのどちらかの少なくとも１つが関連の再解析ポイント属性をもっていれば、前記第１ドライバ手段は、前記ファイルまたはディレクトリのどちらかの少なくとも１つが関連の再解析ポイント属性をもっていたことを前記第２ドライバ手段に通知するステータス情報を該第２ドライバ手段に送信するステップをさらに実行することを特徴とする方法。
- 請求項１ないし４のいずれかに記載の通常の処理シーケンスに割り込みをかける方法において、前記ファイルまたはディレクトリのどちらかの少なくとも１つに関連する、抜き出した再解析ポイント情報を前記複数のドライバ手段の各々に頂番に渡していき、該複数のドライバ手段の１つが自分が前記抜き出した再解析ポイント情報の所有者であると認識して、前記入出力要求の処理を引き受けるまで続けていくステップをさらに備えることを特徴とする方法。
- 請求項１ないし５のいずれかに記載の通常の処理シーケンスに割れ込みをかける方法において、前記抜き出した再解析ポイント情報は、前記第２ドライバ手段を、前記入出力要求の少なくとも一部を処理すべきドライバであると判別する手段を含んでいることを特徴とする方法。
- 請求項１ないし６のいずれかに記載の通常の処理シーケンスに割り込みをかける方法において、前記抜き出した再解析ポイント情報は、前記入出力要求の少なくとも一部を処理するときに前記第２ドライバ手段によって使用されるストアされたデータを含んでいることを特徴とする方法。
- 複数の階層化ドライバを使用してハードウェア・デバイスにアクセスする入出力システムにおいて通常の処理シーケンスに割り込みをかけ、前記複数の階層化ドライバのあるドライバから該複数の階層化ドライバの別のドライバにコントロールを渡す方法であって、該複数の階層化ドライバは第１ドライバと、該第１ドライバと階層関係にある他のドライバとを含み、
該方法は、
入出力要求を該第１ドライバによって受け取るステップと、
前記入出力要求が関連の再解析ポイント属性をもつファイルまたはディレクトリのどちらかの少なくとも１つと係わりがあるかどうかを、該第１ドライバによって判別するステップであって、前記再解析ポイント属性は、特定のファイル又はディレクトリが入出力システム内の特定のドライバによる特殊処理を必要とする再解析ポイントであることを示す、ステップと、
前記ファイルまたはディレクトリのどちらかの少なくとも１つが関連の再解析ポイント属性をもっていれば、該第１ドライバが、
前記ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント情報を前記再解析ポイント属性から抜き出すステップであって、前記再解析ポイント情報は、前記再解析ポイントを処理すべき前記特定のドライバを特定する、ステップと、
前記抜き出した再解析ポイント情報を前記他のドライバに渡すステップとを備えることを特徴とする方法。 - 請求項８に記載の通常の処理シーケンスに割り込みをかける方法において、前記抜き出した再解析ポイント情報を前記他のドライバの各々によって順番に調べていき、該他のドライバの１つが該抜き出した再解析ポイント情報の所有者であると認識するまで続けていき、該抜き出した再解析ポイント情報の所有者である該他のドライバの１つが該抜き出した再解析ポイント情報を処理するステップをさらに備えることを特徴とする方法。
- 請求項９に記載の通常の処理シーケンスに割り込みをかける方法において、前記入出力要求は前記ファイルまたはディレクトリのどちらかの少なくとも１つを含んでいるパス名を収めていて、該方法は前記パス名を解決する際に前記第１ドライバの進捗状況を示す情報を、前記再解析ポイント属性が現れる前に前記他のドライバに渡しておくステップをさらに備えることを特徴とする方法。
- 請求項９に記載の通常の処理シーケンスに割り込みをかける方法において、前記入出力要求を処理するとき、抜き出した再解析ポイント情報に加えて該入出力要求からの情報も渡しておくステップをさらに含んでいることを特徴とする方法。
- 複数のドライバ手段を使用して入出力要求を処理する入出力システムにおいて通常の処理シーケンスに割り込みをかける方法であって、前記複数のドライバ手段は第１ドライバ手段と第２ドライバ手段を含み、該方法は、
ある内容をもち、前記第２ドライバ手段が理解できるフォーマットでストアされた情報を含んでいる再解析ポイントに係わっている入出力要求を前記第１ドライバ手段が受け取るステップであって、前記再解析ポイントは、入出力システム内の特定のドライバにより特殊処理を必要とする特定のファイル又はディレクトリである、ステップと、
前記入出力要求が再解析ポイントと係わりがあると該第１ドライバ手段が認識したとき、該第１ドライバ手段が該入出力要求の処理を中止するステップと、
該第１ドライバ手段が該入出力要求の処理責任を該第２ドライバ手段に引き渡すステップと、
該第２ドライバ手段が前記再解析ポイントの前記情報を調べると共に、該入出力要求を調べて、該入出力要求がどのように処理されるべきかを判断するステップと、
該第２ドライバ手段が該入出力要求を処理するステップと
を備えることを特徴とする方法。 - コンピュータを、
入出力システムにおいて入出力要求を処理する第１ドライバ手段と、
前記入出力システムにおいて入出力要求を処理する第２ドライバ手段と、
ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント属性が入出力要求の処理の途中で現れたとき、該入出力要求を処理するためのコントロールを該第２ドライバ手段から前記第１ドライバ手段に引き渡して、該第１ドライバ手段が該入出力要求の処理を継続できるようにする手段であって、前記再解析ポイント属性は、特定のファイル又はディレクトリが前記入出力システム内の特定のドライバによる特殊処理を必要とする再解析ポイントであることを示す、手段として機能させるためのプログラムを記録したコンピュータ読取可能記録媒体であって、
前記第２ドライバ手段は、該第２ドライバ手段が受け取った入出力要求の処理を該第２ドライバ手段が最後まで完了する前に、該入出力要求の処理に割り込みをかける手段であることを特徴とするプログラムを記録したコンピュータ読取可能媒体。 - 請求項１３に記載のコンピュータ読取可能媒体において、前記第２ドライバ手段は、ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント属性が該第２ドライバ手段によって検出されたことを示すステータス情報を、該第２ドライバ手段から前記第１ドライバ手段に渡す手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項１３または１４に記載のコンピュータ読取可能媒体において、前記第２ドライバ手段は、ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント属性を前記第１ドライバ手段に渡す手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項１５に記載のコンピュータ読取可能媒体において、前記再解析ポイント情報はタグと値を含み、前記タグは該再解析ポイント情報を所有しているドライバ手段のＩＤを示し、前記値は該再解析ポイント情報を処理するために前記所有者が必要とするデータを含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項１３ないし１６のいずれかに記載のコンピュータ読取可能媒体において、前記第１ドライバ手段は該第１ドライバ手段によって受け取られた再解析ポイント情報が該第１ドライバ手段によって所有されているかどうかを判別する手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項１７に記載のコンピュータ読取可能媒体において、前記判別する手段は前記第１ドライバ手段が前記再解析ポイント情報を所有しているかどうかを判別するために該再解析ポイント情報のタグを調べることを特徴とするコンピュータ読取可能媒体。
- 請求項１３ないし１８のいずれかに記載のコンピュータ読取可能媒体において、前記第１ドライバ手段は前記入出力要求の処理を継続するための第２の入出力要求を作成する手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項１９に記載のコンピュータ読取可能媒体において、前記第２入出力要求をリモート接続のコンピュータに送って処理させるための手段をさらに備えたことを特徴とするコンピュータ読取可能媒体。
- コンピュータを、
入出力システムにおいて入出力要求を処理する第１ドライバ手段と、
前記入出力システムにおいて入出力要求を処理する第２ドライバ手段と、
ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント属性が入出力要求に処理の途中で現れたとき、入出力要求を前記第１ドライバ手段から前記第２ドライバ手段に引き渡す手段であって、前記再解析ポイント属性は、特定のファイル又はディレクトリが前記入出力システム内の特定のドライバによる特殊処理を必要とする再解析ポイントであることを示す、手段と、
該入出力要求を処理するためのコントロールを該第２ドライバ手段から前記第１ドライバ手段に引き渡して該第１ドライバ手段が該入出力要求の処理を継続できるようにする手段として機能させるためのプログラムを記録したコンピュータ読取可能記録媒体であって、
前記第２ドライバ手段は、該第２ドライバ手段が受け取った入出力要求の処理を該第２ドライバ手段が最後まで完了する前に、該入出力要求の処理に割り込みをかける手段であることを特徴とするプログラムを記録したコンピュータ読取可能媒体。 - 請求項２１に記載のコンピュータ読取可能媒体において、前記第２ドライバ手段は、ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント属性が該第２ドライバ手段によって検出されたことを示すステータス情報を該第２ドライバ手段から前記第１ドライバ手段に渡す手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項２１または２２に記載のコンピュータ読取可能媒体において、前記第２ドライバ手段は、前記再解析ポイント属性から抜き出した再解析ポイント情報を前記第１ドライバ手段に渡す手段であって、前記再解析ポイント情報は、前記再解析ポイントを処理すべき前記特定のドライバを特定する、手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項２３に記載のコンピュータ読取可能媒体において、前記再解析ポイント情報はタグと値を含み、前記タグは該再解析ポイント情報を所有しているドライバ手段のＩＤを示し、前記値は該再解析ポイント情報を処理するために前記所有者が必要とするデータを含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項２１ないし２４のいずれかに記載のコンピュータ読取可能媒体において、前記第１ドライバ手段は該第１ドライバ手段によって受け取られた前記再解析ポイント情報が該第１ドライバ手段によって所有されているかどうかを判別する手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項２５に記載のコンピュータ読取可能媒体において、前記判別する手段は前記第１ドライバ手段が前記再解析ポイント情報を所有しているかどうかを判別するために該再解析ポイント情報のタグを調べることを特徴とするコンピュータ読取可能媒体。
- 請求項２１ないし２６のいずれかに記載のコンピュータ読取可能媒体において、前記第１ドライバ手段は前記入出力要求の処理を継続するための第２の入出力要求を作成する手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- コンピュータを、
入出力要求を処理する複数のドライバ手段と、
ファイルまたはディレクトリのどちらかの少なくとも１つに関連する再解析ポイント属性が入出力要求の処理の途中で現れたとき、前記ドライバ手段によって受け取られた前記入出力要求の通常の処理に割り込みをかける手段であって、前記再解析ポイント属性は、特定のファイル又はディレクトリが前記入出力システム内の特定のドライバによる特殊処理を必要とする再解析ポイントであることを示す、手段と、
前記再解析ポイント属性が該ドライバ手段によって検出されたとき、該入出力要求の処理を該ドライバ手段から前記複数のドライバ手段の他のドライバ手段に引き渡す手段として機能させるプログラムを記録したコンピュータ読取可能媒体。 - 請求項２８に記載のコンピュータ読取可能媒体において、前記再解析ポイント属性が現れたことを示すステータス情報を前記ドライバ手段から前記複数のドライバ手段の前記他のドライバ手段に渡す手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- 請求項２８または２９に記載のコンピュータ読取可能媒体において、前記再解析ポイント属性から抜き出した再解析ポイント情報を前記複数のドライバ手段の前記他のドライバ手段に渡す手段を含んでいることを特徴とするコンピュータ読取可能媒体。
- データ構造に基づいて複数のデータ・フィールドにデータが記録されたコンピュータ読取可能媒体であって、
前記データ構造に基づいて割り振られた、ある範囲の記憶アドレスの第１領域内にストアされた第１組のデータ・フィールドであって、ユーザ・データをストアするために利用可能であり、ストアされたデータをリトリーブするためにユーザによってアクセス可能であり、
前記第１領域内にストアされており、前記ユーザによってストアされたデータを収めている第１データ・フィールドを含んでいる第１組のデータ・フィールドと、
前記データ構造をストアするために割り振られた、ある範囲の記憶アドレスの第２領域内にストアされた第２組のデータ・フィールドであって、該データ構造の種々の属性をストアするために利用可能であり、前記属性は、該データ構造に関連する入出力要求を処理するためにドライバ手段によってアクセス可能であり、該第２組のデータ・フィールドは、
前記第２領域内にストアされており、データ構造の名前を表しているデータを収めている第２データ・フィールドと、
該第２領域内にストアされており、該データ構造が他のドライバ手段による処理が必要であるかどうかを判別するために前記ドライバが使用するように構成された再解析ポイント属性を表すデータを収めている第３データ・フィールドとを含んでいる第２組のデータ・フィールドであって、前記再解析ポイント属性は、特定のファイル又はディレクトリが入出力システム内の特定のドライバによる特殊処理を必要とする再解析ポイントであることを示す、第２組のデータ・フィールドと
にデータが記録されたコンピュータ読取可能媒体。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US83959397A | 1997-04-15 | 1997-04-15 | |
| US08/839,593 | 1997-04-15 | ||
| US08/862,025 US5931935A (en) | 1997-04-15 | 1997-05-22 | File system primitive allowing reprocessing of I/O requests by multiple drivers in a layered driver I/O system |
| US08/862,025 | 1997-05-22 | ||
| PCT/US1998/007595 WO1998047074A1 (en) | 1997-04-15 | 1998-04-14 | File system primitive allowing reprocessing of i/o requests by multiple drivers in a layered driver i/o system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001520774A JP2001520774A (ja) | 2001-10-30 |
| JP4060890B2 true JP4060890B2 (ja) | 2008-03-12 |
Family
ID=27126123
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP54426298A Expired - Fee Related JP4060890B2 (ja) | 1997-04-15 | 1998-04-14 | 階層化ドライバ入出力システム内の複数ドライバによる入出力要求の再処理を可能にするファイル・システム・プリミティブ |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1008045B1 (ja) |
| JP (1) | JP4060890B2 (ja) |
| AU (1) | AU7121698A (ja) |
| WO (1) | WO1998047074A1 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6694354B1 (en) | 1998-11-30 | 2004-02-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Host computer access to peripheral device drivers |
| JP5055492B2 (ja) * | 2001-05-07 | 2012-10-24 | サイエンスパーク株式会社 | 電子計算機のインターフェースドライバプログラム及びその記録媒体 |
| US8171483B2 (en) | 2007-10-20 | 2012-05-01 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
| US10223378B2 (en) | 2015-11-02 | 2019-03-05 | Microsoft Technology Licensing, Llc | Controlling reparse behavior associated with an intermediate directory |
| CN116136737B (zh) * | 2021-11-16 | 2024-06-11 | 华为技术有限公司 | Io处理方法和系统 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5175855A (en) * | 1987-07-27 | 1992-12-29 | Laboratory Technologies Corporation | Method for communicating information between independently loaded, concurrently executing processes |
| US5680618A (en) * | 1993-05-26 | 1997-10-21 | Borland International, Inc. | Driver query and substitution for format independent native data access |
-
1998
- 1998-04-14 EP EP98918254A patent/EP1008045B1/en not_active Expired - Lifetime
- 1998-04-14 JP JP54426298A patent/JP4060890B2/ja not_active Expired - Fee Related
- 1998-04-14 WO PCT/US1998/007595 patent/WO1998047074A1/en active IP Right Grant
- 1998-04-14 AU AU71216/98A patent/AU7121698A/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| EP1008045B1 (en) | 2007-11-21 |
| EP1008045A4 (en) | 2004-07-28 |
| EP1008045A1 (en) | 2000-06-14 |
| AU7121698A (en) | 1998-11-11 |
| JP2001520774A (ja) | 2001-10-30 |
| WO1998047074A1 (en) | 1998-10-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5931935A (en) | File system primitive allowing reprocessing of I/O requests by multiple drivers in a layered driver I/O system | |
| US5978815A (en) | File system primitive providing native file system support for remote storage | |
| US6119118A (en) | Method and system for extending file system metadata | |
| US7243346B1 (en) | Customized library management system | |
| US7765189B2 (en) | Data migration apparatus, method, and program for data stored in a distributed manner | |
| US7203774B1 (en) | Bus specific device enumeration system and method | |
| AU638138B2 (en) | Methods and apparatus for implementing data bases to provide object-oriented invocation of applications | |
| EP0471442B1 (en) | Method for implementing server functions in a distributed heterogeneous environment | |
| KR100243717B1 (ko) | 객체 지향 환경에서 객체에 대한 지속형 메타상태를 가능하게 하기위한 방법 및 장치 | |
| JP3756949B2 (ja) | ファイルシステムに記憶された情報に関する要求を処理する方法及び装置 | |
| KR100868410B1 (ko) | 관리화된 파일 시스템 필터 모델 및 아키텍쳐 | |
| US5619710A (en) | Method and apparatus for object-oriented invocation of a server application by a client application | |
| US4891785A (en) | Method for transferring data files between computers in a network response to generalized application program instructions | |
| CN101329636B (zh) | 虚拟化窗口信息的方法和设备 | |
| JPH07104808B2 (ja) | 設置可能なファイルシステムにおいてダイナミックボリュームトラッキングを行う方法及び装置 | |
| US7149865B2 (en) | Memory allocation using mask-bit pattern to encode metadata within memory address | |
| JPH06231022A (ja) | コンピュータシステムに用いる名前スペースの一部分を別の名前スペースの一部分として利用可能にするための装置及びその方法 | |
| JPH04246742A (ja) | 異なるファイル・システムにまたがる記憶管理システム | |
| JP2001517836A (ja) | １つの記憶媒体の名称空間を別の記憶媒体の名称空間に移植する場合に既定のアクションを実行するシステムおよび方法 | |
| EP1244017A1 (en) | Data structure managing device, data structure managing system, data structure managing method, and recorded medium where data structure managing program is stored | |
| JPH0644063A (ja) | 個別サブプログラムをメインプログラムに統合する方法 | |
| CN1326062C (zh) | 计算机系统和方法 | |
| JP4432087B2 (ja) | データベース更新管理システム、プログラムおよび方法 | |
| JP2002007182A (ja) | 外部記憶装置の共有ファイル管理方式 | |
| JP4060890B2 (ja) | 階層化ドライバ入出力システム内の複数ドライバによる入出力要求の再処理を可能にするファイル・システム・プリミティブ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050413 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050413 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060307 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060607 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061107 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070207 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071127 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071221 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101228 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101228 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111228 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111228 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131228 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |