(57)【特許請求の範囲】
【請求項１】
ユーザ・プロセス、動的に追加され移される中間処理エレメントであるモジュール、データ・パス、及びデバイス・ドライバとの間に双方向性データ・パスを提供するコンピュータ・システムであって、
前記デバイス・ドライバが、システム・カーネルの中に常駐し、前記カーネルとの間でデータを伝送する周辺装置を制御し、
前記ユーザ・プロセスによって書き込まれたデータが前記ドライバに向けてダウンストリーム方向に進み、
前記ドライバによって前記デバイスから受け取られたデータがユーザによって検索されるためにアップストリーム方向に進み、
特定のモジュール又はドライバのインスタンスを実行する通常機能手段と、
オプションのモジュール又はドライバのインスタンスを実行する１又は複数の代替機能手段と、
制御コマンドを生成するコントローラであって、
該制御コマンドは、前記通常機能と前記１又は複数の代替機能のアドレスを再設定し、
前記通常機能手段を前記１又は複数の代替機能手段に動的に置換する新たな機能のアドレスを定義し、前記オプションモジュールやドライバやインスタンスを前記コンピュータ・システムの実行挙動を動的に変化するよう実装し、前記モジュールと前記ドライバに変更を必要とすることなく、今まで通り通常の実行パスか、あるいは、新しい実行パスを実行する、コントローラと、
を有し、当該コンピュータ・システムは、各々のモジュール又はドライバがキューイニット構造を指すポインタを含むストリームタブ構造を定義するＳＴＲＥＡＭＳフレーム・ワークを使用して実行され、再設定することは、キューイニット構造を指すポインタを設定し直すことによって行われる、コンピュータ・システム。
【請求項２】
更に、特別な事象か特別な状況の下でだけトレースを行うシステム・トレーシング機能をカスタマイズする代替機能手段を有する請求項１記載のコンピュータ・システム。
【請求項３】
更に、特定のシステム問題を目的とするカスタム・フェイル・キャッチャを適用するサポート機能を提供する代替機能手段を有する請求項１記載のコンピュータ・システム。
【請求項４】
更に、インスタンス単位毎にパッチを適用する代替機能手段を有する請求項１記載のコンピュータ・システム。
【請求項５】
更に、シングルのデータ・パスでテストが可能となり、データ・パス実行の柔軟性と制御性が増加された代替機能手段を有する請求項１記載のコンピュータ・システム。
【請求項６】
ユーザ・プロセス、動的に追加され取り除かれる中間処理エレメントであるモジュール、データ・パス、及びデバイス・ドライバとの間に双方向性データ・パスを提供するコンピュータ・システムにおいて、ダイナミック機能置換を実施する方法であって、
前記デバイス・ドライバが、システム・カーネルの中に常駐し、前記カーネルとの間でデータを伝送する周辺装置を制御し、
前記ユーザ・プロセスによって書き込まれたデータが前記ドライバ方向へダウンストリーム上を進み、
前記ドライバによって前記デバイスから受け取られたデータがユーザによって検索されるためにアップストリーム上を進み、
前記システムは、各々のモジュール又はドライバがキューイニット構造を指すポインタを含むストリームタブ構造を定義するＳＴＲＥＡＭＳフレーム・ワークを使用して実行され、
特定のモジュール又はドライバのインスタンスを実行する通常機能を供給するステップと、
オプションのモジュール又はドライバのインスタンスを実行する１又は複数の代替機能を提供するステップと、
コントローラで制御コマンドを生成するステップであって、
該制御コマンドは、前記通常機能手段を前記１又は複数の代替機能手段に動的に置換する新たな機能のアドレスを定義するように、前記通常機能と前記１又は複数の代替機能のアドレスを再設定し、それによって、前記システムの実行挙動を動的に変化させるように前記オプションモジュールやドライバやインスタンスを実装し、前記モジュールと前記ドライバに変更を必要とすることなく、今まで通り通常の実行パスか、あるいは、新しい実行パスを実行するようにする、ステップと、
を有し、再設定することは、キューイニット構造を指すポインタを設定し直すことによって行われる、前記方法。
【請求項７】
前記キューイニット構造が前記ＳＴＲＥＡＭＳフレーム・ワークによってつくられる読取り、書込み、読取りマルチプレクサ、及び書込みマルチプレクサの待ち行列に使用される請求項６記載の方法。
【請求項８】
前記キューイニット構造が、前記ＳＴＲＥＡＭＳフレーム・ワークによってモジュール又はドライバ上で呼び出されたオープン、クローズ、プット、サービス、及び管理上の機能ための機能アドレスを含む請求項６記載の方法。
【請求項９】
前記方法が更に、
現在のアプリケーション実行パスに基づく前記ＳＴＲＥＡＭＳフレーム・ワークによって前記キューイニット構造の範囲内で定義される機能を自動的に実行するステップと、
代替ストリームタブへ前記構造のアドレスを再設定する制御コマンドと、新しい機能アドレスを定義するキューイニット構造を生成するステップと、
を有する請求項６記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ・エンタプライズで通信サービスのフレーム・ワークに関連する。特に、本発明は、ターミナルとホストコンピュータ間、同一コンピュータ内のプロセス間、及び、異なるコンピュータのプロセス間での通信を含む通信サービスを提供するストリーム・フレーム・ワークに関連する。
【０００２】
【従来の技術】
ＳＴＲＥＡＭＳは、ネットワーク・プロトコルと色々なタイプの文字デバイス・ドライバーを実行する産業上の基本のフレーム・ワークになった（S. Rago, UNIX System V Network Programming, Addison Wesley professional computing series (1993)）。ＳＴＲＥＡＭＳサブシステムは、異なる種類の文字ベースのＩ／Ｏを支援するために以前からＵＮＩＸオペレーティング・システムの中に存在した異種でしばしば互換性のないメカニズムを統一するために設計された。特に、ＳＴＲＥＡＭＳはターミナルＩ／Ｏのサポートを提供するシーリスト（ｃｌｉｓｔ）メカニズムに置き換わるものだった。
【０００３】
シーリストに基づくターミナル・サブシステムの中で、各ターミナル・ラインは、一つの関連する処理エレメント（伝送制御手順と呼ばれる）を持つことができる。伝送制御手順は、すべての特別な文字処理を扱う。このように、ユーザがターミナルのデータストリームの非定型的な処理を必要とするならば、伝送制御手順を変えてもよいが、一時点で一つの伝送制御手順のみが一つのターミナルと関連する。
【０００４】
ＳＴＲＥＡＭＳによってユーザは、データストリームからデータストリームへ、モジュールと呼ばれる中間の処理エレメントを「ｐｕｓｈ」によって加わえ、「ｐｏｐ」によって移すことができる。モジュールはスタックされ、１つ以上のモジュールをデータストリームの中で一度に使用することができる。これにより、単純なタスクを実行する独立のモジュールが、ＵＮＩＸコマンドがシェル・パイプラインを通して接続されるのと同じ方法で、より複雑なタスクを実行するのに有効な方法で結合することができる。
【０００５】
ストリームでのデータ転送は、隣接する処理エレメント間でメッセージをやりとりすることによって行う。データ・コピーによるコストのかかるオーバーヘッドを避けるため、メッセージのポインタだけが転送される。メッセージは、タイプと関連プライオリティーを持ち、その両方がメッセージの処理方法を示す。データ転送装置を操作（ドライブ）する要求を、異なる文字をベースとするサブシステムに関連付けるよりはむしろ、Ｉ／Ｏを実行するメッセージ転送の使用が、データ転送装置をドライブするデータを作り出す方が良い。
【０００６】
以前のＩ／０サブシステムでは、ユーザが装置からデータを読みたいときには、ドライバの読込ルーチンが起動され、同様に、ユーザがデータを書きたいときには、ドライバの書込ルーチンが起動される。ＳＴＲＥＡＭＳの中では、ドライバは通常、ユーザが、いつストリームから読取りを行い、いつ書込みを行うか知らない。書込みがメッセージとしてドライバに送り出されている間、データが有効になるまでその読取りが定型的にブロック化される。
【０００７】
単一なストリーム（図１参照）は、ユーザ11のレベルでのプロセス12とカーネル13の中のデバイス・ドライバ14との間に双方向性データパスを提供する。ユーザのプロセスによって書かれたデータはドライバへ向かってダウンストリーム15方向へ進む、そして、ドライバによってハードウェアから受け取られたデータはユーザによって検索されるためにアップストリーム16方向へ進む。データがメッセージ中をアップストリーム及びダウンストリームのどちらの方向に進むとしても、ドライバとモジュールは、データフローをバイト・ストリームとみなすことができる。
【０００８】
単一なストリームはストリーム・ヘッド17とドライバ14の２つの処理エレメントから成る。ストリーム・ヘッドは、ユーザ空間のアプリケーションとカーネル空間の他のストリームの間にインターフェースを提供する一組のルーチンから成る。アプリケーションがＳＴＲＥＡＭＳファイル記述子でシステム・コールをするとき、ストリームは、起動されるルーチンか、 データ・コピーの実行結果か、メッセージ生成か、又は制御操作かを有する。ストリーム・ヘッドが、ユーザ空間とカーネル空間の間にデータをコピーすることができるストリーム中の唯一のコンポーネントである。すべての他のコンポーネントは、単にメッセージを通過することによってデータ転送を達成し、ストリームのユーザと直接的な相互作用から分離される。
【０００９】
二番目の処理エレメントは、ストリーム・エンド又はテイルで見つけられるドライバである。ドライバは周辺装置を制御し、カーネルと装置間でデータを転送する。ドライバがハードウェアで相互に作用するので、ドライバはハードウェア・ドライバと呼ばれる。もう１種類のドライバ（ソフトウェア・ドライバ又はスード・ドライバと呼ばれる）は、ハードウェアと関連しない。その代わりに、そのようなドライバは、通信プロセス間でターミナルのようなインターフェースをエミュレートするようなアプリケーションに、サービスを提供する。
【００１０】
ストリーム・ヘッドの変更は、ドライバの変更と同じ方法ではできない。ドライバは、単にそれらのオブジェクトファイルをカーネル・オブジェクトファイルでリンクすることによってカーネルに加えられることができる。一方、ストリーム・ヘッドは、カーネル・プロパを供給されて、固定される。システムの中のあらゆるストリームで、同じストリーム・ヘッド処理ルーチンが使用される。しかし、各ストリーム・ヘッドは、それが支援する処理オプションを変えることによって小さい範囲へ変更可能である。
【００１１】
ストリーム内の基本成形ブロックが、待ち行列である（図２参照）。待ち行列は１つのコンポーネントを次にリンクし、それによって ストリームを形成する。ストリームの中の各コンポーネントは、少くとも１対の待ち行列、すなわち読取り用（アップストリーム）のための１つの待ち行列（21又は23）と書込み用（ダウンストリーム）のための１つの待ち行列（20又は22）を含む。それらが上下へ流れるように、待ち行列は、メッセージを記憶するための領域としての役目を果たし、状況情報を含んで、メッセージを処理するために使用されるルーチンのためにレジストリとして機能する。
【００１２】
一つのコンポーネントがストリームに沿ってメッセージを通したい時は、待ち行列は次のコンポーネントを識別するために使用される。それから、次のコンポーネント待ち行列は、そのコンポーネントにメッセージを渡すために呼び出す機能を識別するために使用される。このように、各コンポーネントの待ち行列は、コンポーネントと他のストリームとの間にインターフェースを供給する。
【００１３】
モジュール30（図３参照）は、ストリームに動的に付加されるか、ストリームから移される中間の処理エレメントである。モジュールは構造的にドライバに似ているが、通常は、ストリーム・ヘッドとドライバとの間で通過しているメッセージ上で、何らかのフィルタ処理を実行している。例えば、モジュールは１つのインターフェースと他との間でデータの暗号化や変換を実行する。
【００１４】
モジュールを追加し移動することが、ユーザがストリームをカスタマイズすることができる唯一の方法ではない。また、ユーザは多重構成を確立することができ、またそれを取り除くことができる。複数のストリームを、多重ドライバかマルチプレクサ40と呼ばれる特別な種類のソフトウェア・ドライバの下にリンクする（図４参照）。多重ドライバは、ドライバをアクセスするために開かれた上位のストリームとドライバの下にリンクされる下位のストリームとの間でメッセージを発送する。多重ドライバは、ウィンドウ・システムとでネットワーキング・プロトコルを実行することによく適している。ウィンドウ・システムは、複数のウィンドウと物理端末の間でデータを多重送信する。ネットワーキングは、複数のユーザと複数の伝送媒体との間に多重メッセージのプロトコルを作る。
【００１５】
ストリームがプロセスと装置を連結するために使用されている間、また、それらはプロセスと他のプロセスを連結するために使用される場合がある。パイプは、ストリームとしてＵＮＩＸ  Ｓｙｓｔｅｍ  Ｖ  リリース４の中で実行され、２種類のパイプ、すなわちネーミングされていないパイプとネーミングされたパイプがある。ネーミングされていないパイプ（または、匿名のパイプと呼ばれる）は、ファイルシステム・ネーム空間の中でエントリを持たない。パイプ・システム・コールが、２つのストリーム・ヘッド17a、17bを割り当て、各々の書込み待ち行列をもう一方の読取り待ち行列に向けることによってネーミングされていないパイプをつくる（図５参照）。
【００１６】
データがそこから先入れ先出し(first-in-first-out)方式で読み出される故にＦＩＦＯと呼ばれるネーミングされたパイプも、ｍｋｎｏｄシステム・コールを経てつくられる。それは、ファイルシステムの中で名前を持ち、オープン・システム・コールでアクセスされることができる。ネーミングされたパイプが、その読取り待ち行列でその書込み待ち行列をポインティングする１つのストリーム・ヘッド17である（図６参照）。ネーミングされたパイプに書かれたデータは、同じパイプの終端から読み出すことができる。
【００１７】
いくつかの利点が、ＳＴＲＥＡＭＳに基づくパイプにある。最初に、ローカルなプロセス間通信（ＩＰＣ）が、遠隔あるいはネットワークされたＩＰＣと同じメカニズムを使用する。これは、ローカルＩＰＣ接続を扱うために遠隔接続と同じものをアプリケーションに与える。したがって、ストリームに適用することができるほとんどのオペレーションは、パイプに適用することができる。例えば、モジュールはパイプ上でより多くの機能性を得るために後入れ先出しすることができる。次に、ＳＴＲＥＡＭＳに基づくパイプは、２つの代わりに１つのパイプで２つのプロセス間の双方向通信ができる全二重である。
【００１８】
ストリーム内のすべての通信は、ＳＴＲＥＡＭＳメッセージにポインタを渡すことによって発生する。メッセージはタイプ化され、そのタイプはメッセージの目的とそのプライオリティを示す。タイプに基づいて、メッセージは高いプライオリティか通常のプライオリティかが決まる。通常のプライオリティ・メッセージは、フロー制御とメッセージ待ち行列のために、さらにプライオリティ・バンドに細分化される。
【００１９】
ユーザがストリームの他の終わりに伝えたいデータは、ストリーム・ヘッドによるＭ＿ＤＡＴＡメッセージ中のパッケージである。これは、最も共通のメッセージ・タイプである。ユーザが制御情報を送り出すか受け取る必要がある場合に、Ｍ＿ＰＲＯＴＯメッセージが使用される。制御情報は、ストリームの中のモジュールかドライバから準備されて、そのコンポーネントによって解読されて、通常はコンポーネントを通しては送られない。特別なメッセージ・タイプであるＭ＿ＰＣＰＲＯＴＯは、インターフェース承認のような高い優先制御情報のために予約される。
【００２０】
単純なメッセージは１つのメッセージ・ブロックから成る。より複雑なメッセージは、複数のメッセージ・ブロックを結びつけることによってつくることができ、論理上これらはより大きいメッセージとみなされる。１つのメッセージ・ブロックの中のデータは、次のメッセージ・ブロックの中のデータに隣接しているように見られる。メッセージ構造は、通常、ユーザ・レベル・アプリケーションに透過的である。これに対する一つの例外は、制御情報とユーザ・データを含む複雑なメッセージを扱っているときである。
【００２１】
ＳＴＲＥＡＭＳメカニズムがＵＮＩＸカーネルのサブシステムであるので、カーネルによって供給されたシステム環境を理解することは、重要である。ＳＴＲＥＡＭＳドライバとモジュールは、ＳＴＲＥＡＭＳサブシステムと他のカーネルによって強要された制約を守らなければならない。Device Driver Interface/Driver-Kernel Reference Manual, Prentice-Hall, Englewood Cliffs, NJ ("DDI/DKI")は、エントリ・ポイント・ドライバとモジュールとがカーネルの中で作用するために定義されなければならないのと同様に、ドライバとモジュールによる使用のためにカーネルによって供給されたすべてのデータ構造とインタフェース・ルーチンとを定義する。
【００２２】
ＤＫＩ部分は、インプリメンテーション独立のインターフェースに言及する。それは、オペレーティング・システムの同じバージョンのために、異なるハードウェア・アーキテクチャに渡って互換性を促進する。ＤＤＩ部分が、プロセッサ特性とプラットホーム特性のインターフェースに言及する。それは、あるリリースから他のリリースまでの特別なハードウェア・アーキテクチャのために互換性を促進する。インターフェースは、ＤＤＩ、ＤＫＩ、又は両方に属すことができる。各システム・インプリメンテーションは、ＤＤＩ又はＤＫＩのそれ自身のバージョンを含む。すべてのシステムは、同じＤＫＩを共有する。同じプロセッサ・タイプを使用しているすべてのシステムは、いくつかのプラットホーム特性のインターフェースを除いて同じＤＤＩを持つ。
【００２３】
【発明が解決しようとする課題】
しかし、トレーシングとロギング機能を付加するようなＳＴＲＥＡＭＳ拡張に関して、サード・パーティ・プロバイダは、必然的に、そのようなトレーシングとロギングを可能にするマクロをＳＴＲＥＡＭＳに加えるためにそれらのコードのすべてを修正することを要求される。このことは、標準規格への書込みに対して開発者がそのようなプラットホームのために特別に何かをしなければならないので、特別なプラットホームに移行することを決める開発者の数を制限することとなる。このように、開発者は主に標準のコードを使用することを選択する。
【００２４】
また、その上に、ＳＴＲＥＡＭＳフレーム・ワークに拡張が加えられるときはいつでも、例えばシステムがトレーシングかロギングであるかどうかをチェックすることが必要になるので、パフォーマンス劣化が生じる。通常は参照されない幾つかのグローバル変数についてチェックする必要があるため、そのようなチェックが実行されるまで、キャッシュ・ミスやＣＰＵの機能停止といったようなパフォーマンス劣化が生じる。グローバル変数が参照されているならば、それは必然的にシステムのキャッシュになく、キャッシュ・ミスになる。高速処理プロセッサでのキャッシュ・ミスは、プロセッサ機能停止に至り、システムの効果的なパフォーマンスを損なうこととなる 。
【００２５】
従って、本願発明の目的は、追加する互換性の複雑性や欠落とパフォーマンス低下といった２つの劣化なく、いろいろな拡張又はオプションが容易に使用可能であるＳＴＲＥＡＭＳフレーム・ワークを提供することである。
【００２６】
また、本願発明の他の目的は、ＳＴＲＥＡＭＳフレーム・ワークに、ダイナミック機能置換として参照される拡張性を提供することである。
【００２７】
【課題を解決するための手段】
上述の目的を達成するために、ＳＴＲＥＡＭＳフレーム・ワークは、フレーム・ワークの変更を必要としないか又はこれらの機能がそれらの基礎の識別性を越えて実際にどの様に機能するかを理解することなく、ＳＴＲＥＡＭＳがいろいろなモジュールやドライバ機能を実行するのを許可する機能ポインタを含むデータ構造を使用する。ダイナミック機能置換は、これらの機能定義を置き換え、そして、モジュールやドライバの再書込又は修正を要求することなく、ＳＴＲＥＡＭＳモジュールとドライバの実行時の動作を変える、簡単でエレガントなメカニズムを提供する。ここで記述されている拡張性とともに、アプリケーションの開発者、サポータ、及びカスタマに、ＳＴＲＥＡＭＳモジュールとドライバを開発し、修正し、処理するためのダイナミック・メカニズムを提供する。
【００２８】
【発明の実施の形態】
本発明は、ここでダイナミック機能置換として参照されるＳＴＲＥＡＭＳフレーム・ワークに拡張性を供給する。上述のように、ＳＴＲＥＡＭＳフレーム・ワークは、フレーム・ワークの変更を必要としないか又はこれらの機能がそれらの基礎の識別性を越えて実際にどの様に機能するかを理解することなく、STREAMSがいろいろなモジュール又はドライバ機能を実行するのを許可する機能ポインタを含むデータ構造を使用する。ダイナミック機能置換は、これらの機能定義を置き換え、そして、モジュールやドライバの再書込又は修正を要求することなく、ＳＴＲＥＡＭＳモジュールとドライバの実行時の動作を変える、簡単でエレガントなメカニズムを提供する。
【００２９】
ここで記述されている拡張性とともに、アプリケーションの開発者、サポータ組織、及びカスタマは、ＳＴＲＥＡＭＳモジュールとドライバを開発し、修正し、処理するためのダイナミック・メカニズムを供給される。例えば、トレーシング又はロギング機能が実際にストリームの中で割込み可能な時に負わされる、トレーシング又はロギングと関連するパフォーマンス劣化のようなシステム効率が、全面的に最適化される。
【００３０】
例えば伝送中に新しい機能が必要な場合、そのシステムの内のすべてを変えることなく、開発者が、オリジナルの実行パスを増やし、又は完全に置き換えることができる。そのような新しい機能性は、例えばエラー・キャッチャであってもよく、あるいは、アプリケーションがＸ／Ｏｐｅｎの適合レベルを必要とし、モジュール又はドライバがこのレベルに一致しないデフォルト・バージョンを使用する時のような、モジュール又はドライバ特定の適合バージョンを使用する特別な場合であってもよい。開発者は、モジュール又はドライバの適合バージョンが、システム上で複数の要求を満たすのを手伝うアプリケーション・インスタンス単位毎に置換されることを許可する。これは、今日のＳＴＲＥＡＭＳインプリメンテーションで通常可能な特徴でない。
【００３１】
ＳＴＲＥＡＭＳが複雑なカーネル・サブシステムであるので、それに記載された技術の実際の用法は明らかに不明瞭であり、カーネル又はネットワーキングのプロトコルがどのように働くか理解することも明確でない。以下に本発明を理解するために十分な予備知識を持つ目的のためにサンプル例を示す。
【００３２】
ダイナミック機能置換の一つのアプリケーションは、与えられたネットワーク・ドライバかモジュールの範囲内でトレーシングとロギング機能を含むために要求に応答する。あらゆるメッセージのために、メッセージがトレースされるかロギングされる必要があるかどうかを決定することが必要であるので、コスト的にはかなり軽いウエイトであるこれらの機能が、まだパフォーマンス劣化を包含する。それに加えて、もしサード・パーティ・コードがこれらのマクロを追加するために修正されなければ、サード・パーティ・コードは、そのような価値のあるトレーシングとロギングのユーティリティを使用することができない。それはサポートとメンテナンスにコストがかかるので、ほとんどの開発者は、この修正をすることを好まない。
【００３３】
時々、それは、２つのシステム間を結合するような特別なＳＴＲＥＡＭＳインスタンスを検査するために要求されるだけである。今日のトレーシングとロギングのメカニズムにおいては、このことは可能でないし、特別なインスタンスのために応答するドライバやモジュールのために複雑なコードを書かないということは可能でない。ダイナミック機能置換は、すべてのモジュールかドライバのインスタンスの置換を許可するか、又はＳＴＲＥＡＭＳ待ち行列を基準に置換するかを許可する。これは、開発者、カスタマ、及びサポータが、特別なサブシステムのすべての他のユーザに影響を与えることなく、それらの置換機能を微調整することを許可する。特別なインスタンスのためのそのような微調整は、異なるストリーム・インスタンス上で実行している他のアプリケーションが従来通りにパフォーマンス劣化なしで実行し続けるように、他のインスタンスのパフォーマンスに影響を及ぼさない。
【００３４】
ダイナミック機能置換を使用することによって、ユーザは、モジュールかドライバに変更を必要とすることなく、まだオリジナルの実行パスを実行している間、すべてのトレーシングとロギング・サービスを含む新しい機能を供給することができる。実際、これらの新しい機能を拡張することによって、ドライバかモジュールに書き直すことを要求することなく、適宜に、よりフレキシブルなトレーシングとロギング機能を提供することが、可能である。これはまた、トレーシングとロギング機能が必要でないときには、パフォーマンス劣化がないことを意味する。
【００３５】
ダイナミック機能置換は、現在用いられている一般的な機能を手作業で置換する要求に対してカスタマイズされる新しいトレーシングとロギング機能を、サード・パーティ開発者が作ることを許可する。このことは、何千もの接続を管理している大きいネットワーク・システムのために、あるいは、多重コンピュータ構成の範囲内で、すべての他の接続かドライバ・インスタンスのためにパフォーマンス劣化を払うことなく、特別な事象のみをトレースするためか特別な条件の下でトレーシング機能をカスタマイズすることが可能であることを意味する。
【００３６】
本発明の一つの具体例として、サポート機能というこの新しい機能の実際の内容が開発者まで及んでいるので、このサポート機能は、特別な問題を目標とするために、トレーシングとロギングでないカスタム・エラー・キャッチャを適用することができる。実際、既知のＳＴＲＥＡＭＳインプリメンテーションでは現在不可能な非常に有益なカスタマー・サポートとパッチング戦略とに至るモジュールかドライバの大規模な置換の代わりにインスタンスを基準にして、パッチを適用することができる。
【００３７】
例外条件をテストできるかアプリケーション又は他のストリームのスタックの独立したモジュール若しくはドライバを操作することができるモジュールとドライバの範囲内で、問題のある状況をつくることは、カーネル開発者のための最も難しい問題の一つである。現在のテスト・メカニズムは、特別なパスのためのモジュールを操作する特別なテスト・ドライバとカスタムＩ／Ｏコントロール（ｉｏｃｔｌｓ）に依存しており、非常に限定的で、開発や保守が難しい。
【００３８】
ダイナミック機能置換によって、開発者は、作成されて送り出されたメッセージと内在するタイミングを制御することによって、モジュールやドライバをブラック・ボックス・テスト・ターゲットとしてみなすことができる。このようなカプセル化は、１つのパスへテストを集中させ、パス処理の柔軟性と制御性の増加が実現する。これはより高品質なモジュールやドライバを生み、総合的な開発とテスト回数が減らされる。
【００３９】
ダイナミック機能置換はまた、開発者がサード・パーティ会社から特別なツールを必要とすることなくＳＴＲＥＡＭＳに基づくモジュールやドライバを開発することを可能とする。ダイナミック・ロードの可能なカーネル・モジュールが一般的に有効になれば、ダイナミック機能置換は、アンロードやリロードによるカスタマの生産性ロスを引き起し、また可能な限りそのカスタマを速く簡単に支援するソフトウェア開発者の能力を限定するモジュールやかドライバを要求することなく、上述の用法のいずれかを適用するためのクイック・メカニズムを提供する。
【００４０】
上述の例からわかるように、ダイナミック機能置換の主要な利点は：
・パフォーマンス劣化なしで、トレーシングやロギング、又は他の機能タイプが実行される。
・トレーシングやロギングのような機能を利用するためのモジュールやドライバの特別な変更を要しない。
・サポータは、より簡単に特別なエラー・キャッチャを適用することができ、パッチが正しく働いているか否かを検査しているときシステムのすべてのユーザに影響を与えることなくパッチを適用することができ、それによって、カスタマのシステム上での影響を減らすこととなる。
・モジュール単位、ドライバ、又は待ち行列インスタンスのレベルまで下げた、起動のための特別な状況をターゲットとすることができる。
・製品品質を改善して、開発時間を短くする、新しいツールを提供する。
【００４１】
本発明の一実施例では、ダイナミック機能置換は、標準のSVR4.2 Device Driver ReferenceのＳＴＲＥＡＭＳデータ構造を使用するが、本発明は、アプリケーションのための他のデータ構造及び他のフレーム・ワークにも適用される。本発明の実施例の中で処理されたデータ構造は、ストリームタブ(streamtab)とキューイニット(qinit)構造である。各モジュールやドライバは、キューイニット構造にポインタを含むストリームタブ構造を定義する。
【００４２】
キューイニット構造は、ＳＴＲＥＡＭＳフレーム・ワークによってつくられる読取り、書込み、読取りマルチプレクサ、及び書込みマルチプレクサの待ち行列用である。
【００４３】
キューイニット構造は、オープン、クローズ、プット、サービス、及びＳＴＲＥＡＭＳフレーム・ワークによって待ち行列のオーナ、即ちモジュールかドライバ上で起動される管理上の機能のための機能アドレスを含む。
【００４４】
キューイニット構造内で定義された機能は、モジュールやドライバの開発者によって実際に書かれ、ストリーム上を上方や下方に流れるメッセージのような現在のアプリケーション実行パスに基づくフレーム・ワークによって、自動的に実行される。ＳＴＲＥＡＭＳフレーム・ワークがこれらのデータ構造のすべての領域を知っていて、アプリケーション又はモジュールやドライバと独立にそれらにアクセスするので、ダイナミック機能置換は、新しい機能アドレスを定義する代替ストリームタブとキューイニット構造にこれらの構造アドレスを再設定する。デフォルトとして、ＳＴＲＥＡＭＳフレーム・ワークは、トレーシングとロギング機能のための標準の代替ストリームタブのような拡張機能を提供することができる。
【００４５】
本発明のオペレーションに関係している基本法則を理解するために、以下に基本的なStreamsフレーム・ワーク・データ構造を示す。最も重要な３つのデータ構造は、以下の通りである。
【００４６】
【表１】
0003891612.tif 000002
【００４７】
【表２】
0003891612.tif 000003
【００４８】
【表３】
0003891612.tif 000004
【００４９】
これらのデータ構造内のこれらの基本フィールドは、一般にＤＤＩ（上記について論じたデバイス・ドライバ・インタフェース）として参照されるデバイス・ドライバ・リファレンス SVR4.2によって、標準化されている。
【００５０】
代替ストリームタブを構成するための外部仕様
新しいstr_alt_install()ルーチンは、Streamsモジュールやドライバのために代替ストリームタブのものを構成する。フラグ・パラメーターは、それがモジュールかドライバであるかどうか指定する：
【００５１】
【表４】
モジュールのためのSTR_IS_MODULEとドライバのためのSTR_IS_DEVICE。
0003891612.tif 000005
【００５２】
Str_alt_install()は、成功の場合は０で、失敗の場合は−１で返る。
【００５３】
例えば、Streamsドライバfooを考慮する。fooドライバは、トレーシング、デバッギングとパフォーマンスの測定のために以下の代替ルーチンを持つ：
【００５４】
【表５】
0003891612.tif 000006
【００５５】
同様に、希望する場合には、rsrv、wput、wsrv、open及びcloseそれぞれのルーチンを定義する。次に、キューイニット構造を、以下に示す：
【００５６】
【表６】
0003891612.tif 000007
,NULL}
【００５７】
同様に、書込み側のためのキューイニットのものが、定義される。次に、代替ストリームタブのものを定義する：
【００５８】
【表７】
0003891612.tif 000008
【００５９】
最後に、代替ストリームタブのものが、str_alt_install()によって構成される：
【００６０】
【表８】
0003891612.tif 000009
【００６１】
もし、以下の状況の内の一つが起こった場合は、str_alt_install(name,flags,n,streamtabs)が失敗となる：
・ネーム(name)が空である。
・nが否定である。
・nが肯定的であるが、ストリームタブ(streamtabs)が空である。
・フラグが、STR_IS_MODULE又はSTR_IS_DEVICEを含まない。
・ネームによって指定されたモジュールやドライバが、設置されなかった。
・代替ストリームタブがすでに設置されて、モジュールやドライバのアクティブ・インスタンスがある。
【００６２】
たとえモジュールやドライバのアクティブ・インスタンスがあっても現在設置された代替ストリームタブがない場合には、str_alt_install()は代替ストリームタブが設置されることを許可する。すでに設置された代替ストリームタブを変えるかアンインストールするために、モジュールやドライバのすべてのアクティブ・インスタンスは、最初に閉じられなければならない。代替ストリームタブをアンインストールすることは、str_alt_install(name,flags,0,NULL)を呼び出すことによってされる。
【００６３】
上記の開発者供給の代替ストリームタブの他に、通常のストリームタブが構成されるとき自動的に構成される各Streamsモジュールやドライバのために、ＳＴＲＥＡＭＳはデフォルト代替ストリームタブを自動的に供給する。たとえモジュールやドライバのための開発者供給の代替ストリームタブがなくても、このデフォルト代替ストリームタブが存在する。デフォルト代替ストリームタブのキューイニットのすべての内容は、通常のストリームタブのそれに置かれたルーチンを除いて同一である。デフォルト代替ストリームタブの置かれたルーチンを以下に示す：
【００６４】
【表９】
0003891612.tif 000010
【００６５】
動的代替ストリームタブの外部仕様
２つの新しいSTREAMS ioctlコマンドは、動的にモジュールやドライバのストリームタブが持つストリームを交替するために使用される。ioctlコマンドの中の一つがモジュールのアクティブ・インスタンスを変えるために使用され、そして、他のioctlコマンドは、モジュールの将来のインスタンスを変えるために使用される。
【００６６】
【表１０】
0003891612.tif 000011
【００６７】
I_ALTSTRTAB_ACTIVEが、新しいSTREAMS ioctlコマンドであり、そして、それは、ターゲット・ストリームのオーナか超特権のある管理者がモジュールやドライバの与えられたアクティブ・インスタンスのためにキューイニット・ルーチンを交替することを許可する。argは、以下のメンバを含むストラルトアクティブ(straltactive)構造を指さなければならない：
【００６８】
【表１１】
0003891612.tif 000012
【００６９】
・alt_nameは空白文字によって終了されたターゲット・モジュールやドライバのネームであり、そして、str_install()かstr_alt_install()の中で通過されたネームで突き合わされる。
・alt_flagsは、ターゲットがモジュールかドライバであることを示す。
・alt_majorとalt_minorの対は、ターゲット・モジュールやドライバが探索されるストリームを指定する。alt_majorがALT_OWN_MAJORであるならば、alt_minorは無視される、そして、このioctlが呼び出されるストリームはターゲット・ストリームである。alt_majorがALT_OWN_MAJORでないならば、呼出し元の証明がチェックされる、そして、特権ユーザーだけが次に進むことを許可される。alt_minorがALT_ALL_MINORSであるならば、alt_majorによって指定されたすべてのアクティブ・ストリームが、ターゲット・ストリームである。特権ユーザーは必然的に、任意のストリームのモジュールやドライバを変えるために、すべてのSTREAMSインプリメンテーションの標準部品であるストリーム管理ドライバ（「ＳＡＤ」）を使用することができる、しかし、それはＳＡＤドライバである必要はない。ＳＡＤドライバはシステムの中であらゆるストリームを知っているＳＴＲＥＡＭＳ管理ドライバである。そして、それは各ストリームがどこに位置するか知っている。
・alt_indexフィールドは、どの代替ルーチンが使用されることになっているか指定する。もしモジュール・コンフィギュアＮの代替ストリームタブがstr_alt_install()経由ならば、それは以下の値の中で一つである：
【００７０】
【表１２】
0003891612.tif 000013
【００７１】
フェイル時に、errnoには以下の値がセットされる：
EACCES  alt_majorはALT_OWN_MAJORでなく、ユーザはsuper_privilegeを持たない。
EFALUT  argは、割当られたアドレス空間の外側を示す。
EINVAL  alt_name、alt_major、alt_minor、alt_flags、又はalt_indexは、不適当である。
【００７２】
マルチプレクサの下にリンクされたストリームのモジュールやドライバのキューイニット・ルーチンを交替することを許可するために、I_ALTSTRTAB_ACTIVE ioctlは、マルチプレクサの下にリンクされたストリームに呼び出される。例えば下位のｍｕｘルーチンを交替するために、I_ALTSTRTAB_ACTIVE ioctlは、マルチプレクサのネームを指定している下位のストリームに呼び出される。
【００７３】
下位のマルチプレクサのキューイニット・ルーチンを交替するのを許可するために、マルチプレクサの下にリンクされるストリームに、I_ALTSTRTAB_ACTIVE ioctlは、呼び出される。
【００７４】
I_ALTSTRTAB_FUTUREはこれとは別のコマンドであり、それはモジュールやドライバのその後にオープンされたインスタンスのキューイニット・ルーチンを変える。このコマンドも代替ストリームタブによって指定されたモジュールに送り出されるモジュール情報を変える。即ち、モジュールやドライバの次のオープン・インスタンスは代替ストリームタブ（代替キューイニットのものと代替モジュール情報）を使用する。このioctlコマンドは、モジュールやドライバのアクティブ・インスタンスに影響を及ぼさない。argは、以下のメンバを含むストラルトフューチャ(straltfuture)構造を指さなければならない：
【００７５】
【表１３】
0003891612.tif 000014
【００７６】
alt_nameフィールドとalt_indexフィールドは、上述のように記述される。フェイル時、errnoは以下の値にセットされる：
EACCES  ユーザは、超特権を持たない。
EFALUT  argは、割当られたアドレス空間の外側を示す。
EINVAL  alt_name、alt_flags、又はalt_indexは、不適当である。
【００７７】
内部デザイン
以下の記述は、読取り側ルーチンのものである。別のルーチン、即ち、書込み側とmux読取り側とmux書込み側のために、ここで記述されたダイナミック機能置換メカニズムが同様に作動する。モジュールのインスタンスでなくモジュール毎に供給されるストリームタブのものを以下に示す。
・オリジナルの通常のストリームタブ。
・デフォルト代替ストリームタブ。モジュールがstr_alt_install()を通してインストールした代替ストリームタブのもの。
【００７８】
また、各インストールされたモジュールやドライバのための一つのｍｏｄｓｗ構造がある。新しいstruct modswを次に示す：
【００７９】
【表１４】
0003891612.tif 000015
【００８０】
ストラクト(struct)待ち行列は、内部に新しく記述されたQUEUE_KERNEL_FIELDSを持つ：
【００８１】
【表１５】
0003891612.tif 000016
【００８２】
I_ALTSTRTAB_ACTIVE ioctlとI_ALTSTRTABL_FUTRUE ioctlのためのアルゴリズムの要素を、次に示す：
【００８３】
【表１６】
0003891612.tif 000017
【００８４】
図７は、ＳＴＲＥＡＭＳフレーム・ワークのために本発明に従ってダイナミック機能置換を実行するデータ構造を示しているブロック構成図である。双方向性データパス13を供給するコンピューターシステム11の中で、データ構造10が、ユーザ・プロセスと、動的に追加されるか移される中間処理エレメントであるモジュール14と、前記データ経路と、及びデバイスドライバ15との間で実行される。デバイス・ドライバは、システム・カーネル18の中のレジデントであって、前記カーネルと装置16の間にデータを伝送するために前記装置16を制御する。ユーザ・プロセスによって書かれたデータはダウンストリームをドライバの方へ進む、そして、ドライバによって装置から受け取られたデータはユーザ20で検索されるためにアップストリームを進む。
【００８５】
システム、即ち、str_install()とstr_alt_install()にモジュールやドライバをインストールするために使用されるユーティリティを通して、モジュールやドライバがインストールされたあと、移動中に機能を置換することを簡単に図８に示している。図８に示されたデータ構造は、アプリケーション要求を基礎としている。本発明の実施例は、容易性を追加するだけでなくて、マルチプロセッサ・インプリメンテーションや標準化に関連する問題を回避するデータ構造を主に改善する。そのような構造がモジュールやドライバの開発者によってでなくＳＴＲＥＡＭＳフレーム・ワークによって制御されるので、これらのデータ構造は、時間の経過やタイミングを考慮せずに更新される。更に、標準の構造を使用することによって、開発者が専門のトレーニングをする必要がなく、ここで記述された本発明に従ってそれらのプロダクトが実行される。このように、本発明は開発時間の速度を上げて、費用を減らして、開発者の参入をより好適にする。
【００８６】
データ構造は、最低限、特別なモジュールかドライバのインスタンスを実行する通常機能110と、オプションのモジュールかドライバのインスタンスを実行する少くとも一つの代替機能120、130と、モジュールとドライバに変更を必要とすることなくオリジナルの実行パスか新しい実行パスを実行し、通常機能を少なくとも一つの代替機能で動的に置換する制御コマンドを生成するコントローラー140と、を含む。
【００８７】
データ構造が、代替機能、例えば、特別な事象だけを又は特別な状況の下にトレースするためにシステム・トレーシング機能をカスタマイズする機能や；指定されたシステム問題を対象とするためにカスタム・フェイル・キャッチャを適用するためにサポート機能を供給する機能や、インスタンス単位毎にパッチを適用する機能や、シングル・データ・パスをテストすることを許可しデータ・パス処理の柔軟性と制御性が増加することを許可する機能や、あるいは、すべてのモジュールやドライバのインスタンスの置換かインスタンス単位毎の置換を許可する機能、を含むことができる。
【００８８】
データ構造が、STREAMSフレーム・ワーク19の中で実行される。その中で、各モジュールかドライバがキューイニット構造にポインタを含むストリームタブ構造を定義する（図８参照）。データ構造の中で、キューイニット構造が読取り、書込み、及び読取りマルチプレクサのためにあり、キューイニット構造がopen、close、put、及びserviceの機能アドレスを含み、そして、管理機能がＳＴＲＥＡＭＳフレーム・ワークによってモジュールかドライバ上で呼び出される。キューイニット構造内で定義された機能は、現在のアプリケーション実行パスに基づくＳＴＲＥＡＭＳフレーム・ワークによって、自動的に実行される。
【００８９】
このように、コントローラー140は、代替ストリームタブへの前記構造のアドレスと新しい機能アドレスを定義するキューイニット構造を再設定する制御コマンドを生成する。本発明の一つの実施例の中で、デフォルト代替ストリームタブのキューイニット構造のすべての内容は、ｐｕｔルーチンを除いて通常のストリームタブのそれらと同一である。
【００９０】
コントローラーが、動的にモジュールやドライバのストリームタブが持つSTREAMSを代替するために使用される少くとも一つのＳＴＲＥＡＭＳ ioctlコマンドや、モジュールのアクティブ・インスタンスを変えるために使用されるioctlコマンドや、モジュールの将来のインスタンスを変えるために使用されるioctlコマンドを含む制御コマンドを生成する。
【００９１】
データ構造は、すべてのドライバ情報を定義するＭＯＤＳＷテーブル100を含む。ＭＯＤＳＷテーブルの中で、ポインタが異なるストリームタブ110、120、130にある。ここで記載されたデータ構造は、ＭＯＤＳＷテーブル（デフォルト代替ストリームタブ120を選択するために使用される例えばd_default_altエントリ）に少くとも一つの新しいストリームタブ・エントリを追加する。特別なドライバかモジュールがシステムにインストールされるとき、ユーザか開発者は、それらがそのデフォルトにあって欲しいことを定義することができる。それから、ここで記述されたデータ構造は、ストリームタブのリンク・リストを通して幾つかの代替ストリームタブを許可する。このように、ユーザが適合テストや機能テストを実行したい場合、システムをリロードすることは必要でない。むしろ、新しいストリームタブを選択することのみが必要となる。
【００９２】
データ構造を整理することによって、拡張機能かオプションのデータ構造を追加するすることができる。例えば、ストリームが各待ち行列側に開かれるとき、（上述のように）読取り待ち行列と書込み待ち行列がある。読取り待ち行列の中で、参照されたポインタが、待ち行列情報としてある。待ち行列情報が、他のストリームタブの後ろをポイントすることによって、移動中のこれらの代替ストリームタブのいずれかを選択することができる。デフォルトで、システムは特定のストリームタブ（例えばノーマル・ストリームタブ110）を選択する。しかし、望む場合、待ち行列ポインタを、システムの範囲内で構成される代替ストリームタブ120、130のいずれかにセットすることができる。ユーザ空間の見解からは、どのストリームタブが選択されることになっているか指定しろという１つ又は複数のＩＯＣＴＬコマンドを生成するコントローラーを実行することが必要なだけである。そのような選択の結果、ＳＴＲＥＡＭＳフレーム・ワークの変更、即ち、アプリケーションの停止は、必要でない。このように、ＳＴＲＥＡＭＳフレーム・ワーク自身が、そのような代替機能と拡張機能を実行するために適応させられる。付加ＩＯＣＴＬコマンドを使用可能にすることが必要なだけで、定義済み機能を含むデータ構造がつくられる。
【００９３】
ｍｏｄｓｗ（図８）の中で、ポインタd_curstrは、現在のストリームタブを示す。このように、代替ストリームタブが選択されて、システムが現在の状態に復帰されるとき、ポインタd_curstrは、システムを現在のストリームタブの後ろへセットする。それゆえに、例えば、トレーシングやデバッギングやタイム・スタンプのためのキューイニットや、拡張又はオプション機能をインストールするための代替ストリームタブや、特定のシステム・テストのためのユーザ又は開発者によって呼び出されたサンプル・コードの構造を含む本発明に従って、図８にテンプレートのブロック概要図を示す。
【００９４】
以下に、本発明の実施態様を示す。
（１）ユーザ・プロセス、動的に追加され移される中間処理エレメントであるモジュール、データ・パス、及びデバイス・ドライバとの間に双方向性データパスを提供するコンピュータ・システムで実行されるデータ構造であって、
前記デバイス・ドライバが、システム・カーネルの中に常駐し、前記カーネルとの間でデータを伝送する周辺装置を制御し、
前記ユーザ・プロセスによって書き込まれたデータが前記ドライバ方向へダウンストリーム上を進み、
前記ドライバによって前記デバイスから受け取られたデータがユーザによって検索されるためにアップストリーム上を進み、
特定のモジュール又はドライバのインスタンスを実行する通常機能手段と、
オプションのモジュール又はドライバのインスタンスを実行する１又は複数の代替機能手段と、
前記モジュールと前記ドライバに変更を必要とすることなく、今まで通り通常の実行パスか、あるいは、新しい実行パスによる処理で、前記通常機能手段を前記１又は複数の代替機能手段に動的に置換する制御コマンドを生成するコントローラと、
を有する前記データ構造。
【００９５】
（２）更に、特別な事象か特別な状況の下でだけトレースを行うシステム・トレーシング機能をカスタマイズする代替機能手段を有する（１）記載のデータ構造。
（３）更に、特定のシステム問題を目的とするカスタム・フェイル・キャッチャを適用するサポート機能を提供する代替機能手段を有する（１）又は（２）記載のデータ構造。
（４）更に、インスタンス単位毎にパッチを適用する代替機能手段を有する（１）乃至（３）記載のデータ構造。
（５）更に、シングルのデータ・パスでテストが可能となり、データ・パス実行の柔軟性と制御性が増加された代替機能手段を有する（１）乃至（４）記載のデータ構造。
（６）更に、モジュールかドライバ何れかの全てのインスタンスを置換するか、又はインスタンス単位毎に置換することができる代替機能手段を有する（１）乃至（５）記載のデータ構造。
（７）前記システムがＳＴＲＥＡＭＳフレーム・ワークの中で実行される（１）乃至（６）記載のデータ構造。
（８）各々のモジュール又はドライバが、キューイニット構造にポインタを含むストリームタブ構造を定義する（７）記載のデータ構造。
（９）前記キューイニット構造が前記ＳＴＲＥＡＭＳフレーム・ワークによってつくられる読取り、、書込み、読取りマルチプレクサ、及び書込みマルチプレクサの待ち行列に使用される（８）記載のデータ構造。
【００９６】
（１０）前記キューイニット構造が、前記ＳＴＲＥＡＭＳフレーム・ワークによってモジュール又はドライバ上で呼び出されたオープン、クローズ、プット、サービス、及び管理上の機能ための機能アドレスを含む（８）記載のデータ構造。
（１１）機能が、現在のアプリケーション実行パスに基づく前記ＳＴＲＥＡＭＳフレーム・ワークによって自動的に実行される前記キューイニット構造の範囲内で定義され、前記コントローラが、代替ストリームタブへ前記構造のアドレスを再設定する制御コマンドと新しい機能アドレスを定義するキューイニット構造を生成する（８）記載のデータ構造。
（１２）デフォルト代替ストリームタブの前記キューイニット構造の全ての内容が、プット・ルーチンを除いて通常のストリームタブのものと同一である（１１）記載のデータ構造。
（１３）更に、前記コントローラが、ＳＴＲＥＡＭＳモジュール又はドライバのストリームタブの内容を動的に代替するために使用される１又は複数のＳＴＲＥＡＭＳ ｉｏｃｔｌコマンドを有する（８）記載のデータ構造。
（１４）更に、前記コントローラが、モジュールのアクティブ・インスタンスを変えるために使用されるｉｏｃｔｌコマンドを有する（１３）記載のデータ構造。
（１５）更に、前記コントローラが、モジュールの将来のインスタンスを変えるために使用されるｉｏｃｔｌコマンドを有する（１３）記載のデータ構造。
【００９７】
（１６）ユーザ・プロセス、動的に追加され移される中間処理エレメントであるモジュール、データ・パス、及びデバイス・ドライバとの間に双方向性データパスを提供するコンピュータ・システムにおいて、データ構造を実行する方法であって、
前記デバイス・ドライバが、システム・カーネルの中に常駐し、前記カーネルとの間でデータを伝送する周辺装置を制御し、
前記ユーザ・プロセスによって書き込まれたデータが前記ドライバ方向へダウンストリーム上を進み、
前記ドライバによって前記デバイスから受け取られたデータがユーザによって検索されるためにアップストリーム上を進み、
前期システムが、キューイニット構造を示すポインタを含むストリームタブ構造を定義する各のモジュール又はドライバを有するＳＴＲＥＡＭＳフレーム・ワーク内で実行され、
特定のモジュール又はドライバのインスタンスを実行する通常機能を供給するステップと、
オプションのモジュール又はドライバのインスタンスを実行する１又は複数の代替機能を提供するステップと、
前記モジュールと前記ドライバに変更を必要とすることなく、今まで通り通常の実行パスか、あるいは、新しい実行パスによる処理で、前記通常機能を前記１又は複数の代替機能に動的に置換する制御コマンドを生成するステップと、
を有する前記方法。
【００９８】
（１７）前記キューイニット構造が前記ＳＴＲＥＡＭＳフレーム・ワークによってつくられる読取り、、書込み、読取りマルチプレクサ、及び書込みマルチプレクサの待ち行列に使用される（１６）記載の方法。
（１８）前記キューイニット構造が、前記ＳＴＲＥＡＭＳフレーム・ワークによってモジュール又はドライバ上で呼び出されたオープン、クローズ、プット、サービス、及び管理上の機能ための機能アドレスを含む（１６）記載の方法。
（１９）更に、現在のアプリケーション実行パスに基づく前記ＳＴＲＥＡＭＳフレーム・ワークによって前記キューイニット構造の範囲内で定義される機能を自動的に実行するステップと、
代替ストリームタブへ前記構造のアドレスを再設定する制御コマンドと、新しい機能アドレスを定義するキューイニット構造を生成するステップと、を有する（１６）乃至（１８）記載の方法。
【００９９】
（２０）デフォルト代替ストリームタブの前記キューイニット構造の全ての内容が、プット・ルーチンを除いて通常のストリームタブのものと同一である（１６）乃至（１９）記載の方法。
（２１）更に、ＳＴＲＥＡＭＳモジュール又はドライバのストリームタブの内容を動的に代替するために使用される１又は複数のＳＴＲＥＡＭＳ ｉｏｃｔｌコマンドを使用するステップを有する（１６）乃至（２０）記載の方法。
（２２）更に、モジュールのアクティブ・インスタンスを変えるために使用されるｉｏｃｔｌコマンドを使用するステップを有する（１６）乃至（２１）記載の方法。
【０１００】
【発明の効果】
上述のように、本発明によって、追加する互換性の複雑性や欠落とパフォーマンス低下といった２つの劣化なく、いろいろな拡張又はオプションが容易に使用可能であるＳＴＲＥＡＭＳフレーム・ワークが供給できることとなった。
【０１０１】
また、更に、本発明によって、ＳＴＲＥＡＭＳフレーム・ワークに、ダイナミック機能置換として参照される拡張性を提供することができるようになった。
【図面の簡単な説明】
【図１】単一なストリームを示すブロック図である。
【図２】ＳＴＲＥＡＭＳ待ち行列を示すブロック図である。
【図３】ストリーム上でのモジュールを示すブロック図である。
【図４】多重ドライバを示すブロック図である。
【図５】従来のパイプを示すブロック図である。
【図６】ＦＩＦＯを示すブロック図である。
【図７】ＳＴＲＥＡＭＳフレーム・ワークのために本発明に従ってダイナミック機能置換を実行するデータ構造を示しているブロック構成図である。
【図８】本発明に従ってダイナミック機能置換を含むＳＴＲＥＡＭＳフレーム・ワークのデータ構造を示しているブロック図である。
【図１】
0003891612.tif 000018
【図２】
0003891612.tif 000019
【図３】
0003891612.tif 000020
【図４】
0003891612.tif 000021
【図５】
0003891612.tif 000022
【図６】
0003891612.tif 000023
【図７】
0003891612.tif 000024
【図８】
0003891612.tif 000025