JPH09218844A - ダイナミック機能置換を有するデータ構造 - Google Patents

Abstract

(57)【要約】 【課題】フレーム・ワークの変更を必要とせず、それぞ
れの機能の基礎的な識別性を意識せずに、ＳＴＲＥＡＭ
Ｓがいろいろなモジュール又はドライバの機能を実行す
ることを可能にする。 【解決手段】 ダイナミック機能置換として参照される
ＳＴＲＥＡＭＳフレーム・ワークへの拡張性は、フレー
ム・ワークの変更を必要とせず、それぞれの機能の基礎
的な識別性を意識せずに、ＳＴＲＥＡＭＳがいろいろな
モジュール又はドライバの機能を実行することを可能に
する機能ポインタを含むデータ構造を使用する。これに
より、モジュールやドライバの書直しや修正の必要な
く、これらの機能の定義を置換し、ＳＴＲＥＡＭＳモジ
ュールとドライバの実行時の動作を変更する、単純でエ
レガントなメカニズムが提供される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ・エンタプ
ライズで通信サービスのフレーム・ワークに関連する。
特に、本発明は、ターミナルとホストコンピュータ間、
同一コンピュータ内のプロセス間、及び、異なるコンピ
ュータのプロセス間での通信を含む通信サービスを提供
するストリーム・フレーム・ワークに関連する。

【０００２】

【従来の技術】ＳＴＲＥＡＭＳは、ネットワーク・プロ
トコルと色々なタイプの文字デバイス・ドライバーを実
行する産業上の基本のフレーム・ワークになった（S. R
ago, UNIX System V Network Programming, Addison We
sley professional computingseries (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/Driv
er-Kernel Reference Manual, Prentice-Hall, Englewo
od Cliffs, NJ ("DDI/DKI")は、エントリ・ポイント・
ドライバとモジュールとがカーネルの中で作用するため
に定義されなければならないのと同様に、ドライバとモ
ジュールによる使用のためにカーネルによって供給され
たすべてのデータ構造とインタフェース・ルーチンとを
定義する。

【００２２】ＤＫＩ部分は、インプリメンテーション独
立のインターフェースに言及する。それは、オペレーテ
ィング・システムの同じバージョンのために、異なるハ
ードウェア・アーキテクチャに渡って互換性を促進す
る。ＤＤＩ部分が、プロセッサ特性とプラットホーム特
性のインターフェースに言及する。それは、あるリリー
スから他のリリースまでの特別なハードウェア・アーキ
テクチャのために互換性を促進する。インターフェース
は、ＤＤＩ、ＤＫＩ、又は両方に属すことができる。各
システム・インプリメンテーションは、ＤＤＩ又はＤＫ
Ｉのそれ自身のバージョンを含む。すべてのシステム
は、同じＤＫＩを共有する。同じプロセッサ・タイプを
使用しているすべてのシステムは、いくつかのプラット
ホーム特性のインターフェースを除いて同じＤＤＩを持
つ。

【００２３】

【発明が解決しようとする課題】しかし、トレーシング
とロギング機能を付加するようなＳＴＲＥＡＭＳ拡張に
関して、サード・パーティ・プロバイダは、必然的に、
そのようなトレーシングとロギングを可能にするマクロ
をＳＴＲＥＡＭＳに加えるためにそれらのコードのすべ
てを修正することを要求される。このことは、標準規格
への書込みに対して開発者がそのようなプラットホーム
のために特別に何かをしなければならないので、特別な
プラットホームに移行することを決める開発者の数を制
限することとなる。このように、開発者は主に標準のコ
ードを使用することを選択する。

【００２４】また、その上に、ＳＴＲＥＡＭＳフレーム
・ワークに拡張が加えられるときはいつでも、例えばシ
ステムがトレーシングかロギングであるかどうかをチェ
ックすることが必要になるので、パフォーマンス劣化が
生じる。通常は参照されない幾つかのグローバル変数に
ついてチェックする必要があるため、そのようなチェッ
クが実行されるまで、キャッシュ・ミスやＣＰＵの機能
停止といったようなパフォーマンス劣化が生じる。グロ
ーバル変数が参照されているならば、それは必然的にシ
ステムのキャッシュになく、キャッシュ・ミスになる。
高速処理プロセッサでのキャッシュ・ミスは、プロセッ
サ機能停止に至り、システムの効果的なパフォーマンス
を損なうこととなる 。

【００２５】従って、本願発明の目的は、追加する互換
性の複雑性や欠落とパフォーマンス低下といった２つの
劣化なく、いろいろな拡張又はオプションが容易に使用
可能であるＳＴＲＥＡＭＳフレーム・ワークを提供する
ことである。

【００２６】また、本願発明の他の目的は、ＳＴＲＥＡ
ＭＳフレーム・ワークに、ダイナミック機能置換として
参照される拡張性を提供することである。

【００２７】

【課題を解決するための手段】上述の目的を達成するた
めに、ＳＴＲＥＡＭＳフレーム・ワークは、フレーム・
ワークの変更を必要としないか又はこれらの機能がそれ
らの基礎の識別性を越えて実際にどの様に機能するかを
理解することなく、ＳＴＲＥＡＭＳがいろいろなモジュ
ールやドライバ機能を実行するのを許可する機能ポイン
タを含むデータ構造を使用する。ダイナミック機能置換
は、これらの機能定義を置き換え、そして、モジュール
やドライバの再書込又は修正を要求することなく、ＳＴ
ＲＥＡＭＳモジュールとドライバの実行時の動作を変え
る、簡単でエレガントなメカニズムを提供する。ここで
記述されている拡張性とともに、アプリケーションの開
発者、サポータ、及びカスタマに、ＳＴＲＥＡＭＳモジ
ュールとドライバを開発し、修正し、処理するためのダ
イナミック・メカニズムを提供する。

【００２８】

【発明の実施の形態】本発明は、ここでダイナミック機
能置換として参照されるＳＴＲＥＡＭＳフレーム・ワー
クに拡張性を供給する。上述のように、ＳＴＲＥＡＭＳ
フレーム・ワークは、フレーム・ワークの変更を必要と
しないか又はこれらの機能がそれらの基礎の識別性を越
えて実際にどの様に機能するかを理解することなく、ST
REAMSがいろいろなモジュール又はドライバ機能を実行
するのを許可する機能ポインタを含むデータ構造を使用
する。ダイナミック機能置換は、これらの機能定義を置
き換え、そして、モジュールやドライバの再書込又は修
正を要求することなく、ＳＴＲＥＡＭＳモジュールとド
ライバの実行時の動作を変える、簡単でエレガントなメ
カニズムを提供する。

【００２９】ここで記述されている拡張性とともに、ア
プリケーションの開発者、サポータ組織、及びカスタマ
は、ＳＴＲＥＡＭＳモジュールとドライバを開発し、修
正し、処理するためのダイナミック・メカニズムを供給
される。例えば、トレーシング又はロギング機能が実際
にストリームの中で割込み可能な時に負わされる、トレ
ーシング又はロギングと関連するパフォーマンス劣化の
ようなシステム効率が、全面的に最適化される。

【００３０】例えば伝送中に新しい機能が必要な場合、
そのシステムの内のすべてを変えることなく、開発者
が、オリジナルの実行パスを増やし、又は完全に置き換
えることができる。そのような新しい機能性は、例えば
エラー・キャッチャであってもよく、あるいは、アプリ
ケーションがＸ／Ｏｐｅｎの適合レベルを必要とし、モ
ジュール又はドライバがこのレベルに一致しないデフォ
ルト・バージョンを使用する時のような、モジュール又
はドライバ特定の適合バージョンを使用する特別な場合
であってもよい。開発者は、モジュール又はドライバの
適合バージョンが、システム上で複数の要求を満たすの
を手伝うアプリケーション・インスタンス単位毎に置換
されることを許可する。これは、今日のＳＴＲＥＡＭＳ
インプリメンテーションで通常可能な特徴でない。

【００３１】ＳＴＲＥＡＭＳが複雑なカーネル・サブシ
ステムであるので、それに記載された技術の実際の用法
は明らかに不明瞭であり、カーネル又はネットワーキン
グのプロトコルがどのように働くか理解することも明確
でない。以下に本発明を理解するために十分な予備知識
を持つ目的のためにサンプル例を示す。

【００３２】ダイナミック機能置換の一つのアプリケー
ションは、与えられたネットワーク・ドライバかモジュ
ールの範囲内でトレーシングとロギング機能を含むため
に要求に応答する。あらゆるメッセージのために、メッ
セージがトレースされるかロギングされる必要があるか
どうかを決定することが必要であるので、コスト的には
かなり軽いウエイトであるこれらの機能が、まだパフォ
ーマンス劣化を包含する。それに加えて、もしサード・
パーティ・コードがこれらのマクロを追加するために修
正されなければ、サード・パーティ・コードは、そのよ
うな価値のあるトレーシングとロギングのユーティリテ
ィを使用することができない。それはサポートとメンテ
ナンスにコストがかかるので、ほとんどの開発者は、こ
の修正をすることを好まない。

【００３３】時々、それは、２つのシステム間を結合す
るような特別なＳＴＲＥＡＭＳインスタンスを検査する
ために要求されるだけである。今日のトレーシングとロ
ギングのメカニズムにおいては、このことは可能でない
し、特別なインスタンスのために応答するドライバやモ
ジュールのために複雑なコードを書かないということは
可能でない。ダイナミック機能置換は、すべてのモジュ
ールかドライバのインスタンスの置換を許可するか、又
はＳＴＲＥＡＭＳ待ち行列を基準に置換するかを許可す
る。これは、開発者、カスタマ、及びサポータが、特別
なサブシステムのすべての他のユーザに影響を与えるこ
となく、それらの置換機能を微調整することを許可す
る。特別なインスタンスのためのそのような微調整は、
異なるストリーム・インスタンス上で実行している他の
アプリケーションが従来通りにパフォーマンス劣化なし
で実行し続けるように、他のインスタンスのパフォーマ
ンスに影響を及ぼさない。

【００３４】ダイナミック機能置換を使用することによ
って、ユーザは、モジュールかドライバに変更を必要と
することなく、まだオリジナルの実行パスを実行してい
る間、すべてのトレーシングとロギング・サービスを含
む新しい機能を供給することができる。実際、これらの
新しい機能を拡張することによって、ドライバかモジュ
ールに書き直すことを要求することなく、適宜に、より
フレキシブルなトレーシングとロギング機能を提供する
ことが、可能である。これはまた、トレーシングとロギ
ング機能が必要でないときには、パフォーマンス劣化が
ないことを意味する。

【００３５】ダイナミック機能置換は、現在用いられて
いる一般的な機能を手作業で置換する要求に対してカス
タマイズされる新しいトレーシングとロギング機能を、
サード・パーティ開発者が作ることを許可する。このこ
とは、何千もの接続を管理している大きいネットワーク
・システムのために、あるいは、多重コンピュータ構成
の範囲内で、すべての他の接続かドライバ・インスタン
スのためにパフォーマンス劣化を払うことなく、特別な
事象のみをトレースするためか特別な条件の下でトレー
シング機能をカスタマイズすることが可能であることを
意味する。

【００３６】本発明の一つの具体例として、サポート機
能というこの新しい機能の実際の内容が開発者まで及ん
でいるので、このサポート機能は、特別な問題を目標と
するために、トレーシングとロギングでないカスタム・
エラー・キャッチャを適用することができる。実際、既
知のＳＴＲＥＡＭＳインプリメンテーションでは現在不
可能な非常に有益なカスタマー・サポートとパッチング
戦略とに至るモジュールかドライバの大規模な置換の代
わりにインスタンスを基準にして、パッチを適用するこ
とができる。

【００３７】例外条件をテストできるかアプリケーショ
ン又は他のストリームのスタックの独立したモジュール
若しくはドライバを操作することができるモジュールと
ドライバの範囲内で、問題のある状況をつくることは、
カーネル開発者のための最も難しい問題の一つである。
現在のテスト・メカニズムは、特別なパスのためのモジ
ュールを操作する特別なテスト・ドライバとカスタムＩ
／Ｏコントロール（ｉｏｃｔｌｓ）に依存しており、非
常に限定的で、開発や保守が難しい。

【００３８】ダイナミック機能置換によって、開発者
は、作成されて送り出されたメッセージと内在するタイ
ミングを制御することによって、モジュールやドライバ
をブラック・ボックス・テスト・ターゲットとしてみな
すことができる。このようなカプセル化は、１つのパス
へテストを集中させ、パス処理の柔軟性と制御性の増加
が実現する。これはより高品質なモジュールやドライバ
を生み、総合的な開発とテスト回数が減らされる。

【００３９】ダイナミック機能置換はまた、開発者がサ
ード・パーティ会社から特別なツールを必要とすること
なくＳＴＲＥＡＭＳに基づくモジュールやドライバを開
発することを可能とする。ダイナミック・ロードの可能
なカーネル・モジュールが一般的に有効になれば、ダイ
ナミック機能置換は、アンロードやリロードによるカス
タマの生産性ロスを引き起し、また可能な限りそのカス
タマを速く簡単に支援するソフトウェア開発者の能力を
限定するモジュールやかドライバを要求することなく、
上述の用法のいずれかを適用するためのクイック・メカ
ニズムを提供する。

【００４０】上述の例からわかるように、ダイナミック
機能置換の主要な利点は： ・パフォーマンス劣化なしで、トレーシングやロギン
グ、又は他の機能タイプが実行される。 ・トレーシングやロギングのような機能を利用するため
のモジュールやドライバの特別な変更を要しない。 ・サポータは、より簡単に特別なエラー・キャッチャを
適用することができ、パッチが正しく働いているか否か
を検査しているときシステムのすべてのユーザに影響を
与えることなくパッチを適用することができ、それによ
って、カスタマのシステム上での影響を減らすこととな
る。 ・モジュール単位、ドライバ、又は待ち行列インスタン
スのレベルまで下げた、起動のための特別な状況をター
ゲットとすることができる。 ・製品品質を改善して、開発時間を短くする、新しいツ
ールを提供する。

【００４１】本発明の一実施例では、ダイナミック機能
置換は、標準のSVR4.2 Device Driver ReferenceのＳＴ
ＲＥＡＭＳデータ構造を使用するが、本発明は、アプリ
ケーションのための他のデータ構造及び他のフレーム・
ワークにも適用される。本発明の実施例の中で処理され
たデータ構造は、ストリームタブ(streamtab)とキュー
イニット(qinit)構造である。各モジュールやドライバ
は、キューイニット構造にポインタを含むストリームタ
ブ構造を定義する。

【００４２】キューイニット構造は、ＳＴＲＥＡＭＳフ
レーム・ワークによってつくられる読取り、書込み、読
取りマルチプレクサ、及び書込みマルチプレクサの待ち
行列用である。

【００４３】キューイニット構造は、オープン、クロー
ズ、プット、サービス、及びＳＴＲＥＡＭＳフレーム・
ワークによって待ち行列のオーナ、即ちモジュールかド
ライバ上で起動される管理上の機能のための機能アドレ
スを含む。

【００４４】キューイニット構造内で定義された機能
は、モジュールやドライバの開発者によって実際に書か
れ、ストリーム上を上方や下方に流れるメッセージのよ
うな現在のアプリケーション実行パスに基づくフレーム
・ワークによって、自動的に実行される。ＳＴＲＥＡＭ
Ｓフレーム・ワークがこれらのデータ構造のすべての領
域を知っていて、アプリケーション又はモジュールやド
ライバと独立にそれらにアクセスするので、ダイナミッ
ク機能置換は、新しい機能アドレスを定義する代替スト
リームタブとキューイニット構造にこれらの構造アドレ
スを再設定する。デフォルトとして、ＳＴＲＥＡＭＳフ
レーム・ワークは、トレーシングとロギング機能のため
の標準の代替ストリームタブのような拡張機能を提供す
ることができる。

【００４５】本発明のオペレーションに関係している基
本法則を理解するために、以下に基本的なStreamsフレ
ーム・ワーク・データ構造を示す。最も重要な３つのデ
ータ構造は、以下の通りである。

【００４６】

【表１】 /* Streams queue initialization structure */ struct qinit { int (*qi_putp)(); /* Queue put procedure */ int (*qi_srvp)(); /* Queue service procedure */ int (*qi_qopen)(); /* Queue open procedure */ int (*qi_qclose)(); /* Queue close procedure */ int (*qi_qadmin)(); /* Queue administrative procedure */ struct module_info * qi_minfo; struct module_stat * qi_mstat; };

【００４７】

【表２】 /* Streams driver and module declaration structure */ struct streamtab { struct qinit * st_rdinit; /* defines readQUEUE */ struct qinit * st_wrinit; /* defines write QUEUE */ struct qinit * st_muxrinit; /* for multiplexing drivers only */ struct qinit * st_muxwinit; /* ditto */ };

【００４８】

【表３】 /* Streams queue structure */ struct queue { struct qinit * q_qinfo; /* procedures and limits for queue */ struct msgb * q_first; /* head of message queue */ struct msgb * q_last; /* tail of message queue */ struct queue * q_next; /* next QUEUE in Stream */ struct queue * q_link; /* link to scheduling queue */ void * q_ptr; /* to private data structure */ ulong q_count; /* weighted count of characters on q */ ulong q_flag; /* QUEUE state */ long q_minpsz; /* min packet size accepted */ long q_maxpsz; /* max packet size accepted */ ulong q_h iwat; /* high water mark, for flow control */ ulong q_lowat; /* low water mark */ struct qband * q_bandp; /* band information */ unsigned charq_nband; /* number of bands */ unsigned char q_pad1[3] /* reserved */ struct queue * q_other; /* pointer to other Q in queuepair */ QUEUE_KERNEL_FIELDS };

【００４９】これらのデータ構造内のこれらの基本フィ
ールドは、一般にＤＤＩ（上記について論じたデバイス
・ドライバ・インタフェース）として参照されるデバイ
ス・ドライバ・リファレンス SVR4.2によって、標準化
されている。

【００５０】代替ストリームタブを構成するための外部
仕様 新しいstr_alt_install()ルーチンは、Streamsモジュー
ルやドライバのために代替ストリームタブのものを構成
する。フラグ・パラメーターは、それがモジュールかド
ライバであるかどうか指定する：

【００５１】

【表４】 モジュールのためのSTR_IS_MODULEとドライバのためのSTR_IS_DEVICE。 str_alt_install(name,flags,n,streamtabs) char *name; /* name of module or driver */ unsigned int flags; /* STR-IS-MODULE/DEVICE */ int n; /* number of alternative streamtabs */ struct streamtab *streamtabs[]; /* array of pointers to streamtabs */

【００５２】Str_alt_install()は、成功の場合は０
で、失敗の場合は−１で返る。

【００５３】例えば、Streamsドライバfooを考慮する。
fooドライバは、トレーシング、デバッギングとパフォ
ーマンスの測定のために以下の代替ルーチンを持つ：

【００５４】

【表５】 foo_rput_trace(q, mp) { ktrc_write(); /* call NETTL packet tracing routine */ foo_rput(q, mp); /* call original rput routine */ } foo_rput_debug(q, mp) { /* * Original rput routine plus debugging code. */ } foo_rput_timestamp(q, mp) { timestamp(); /* record entry timestamp */ foo_rput(q, mp); /* call original rput routine */ timestamp(); /* record exit timestamp */ }

【００５５】同様に、希望する場合には、rsrv、wput、
wsrv、open及びcloseそれぞれのルーチンを定義する。
次に、キューイニット構造を、以下に示す：

【００５６】

【表６】 struct qinit foo_rinit_trace = { foo_rput_trace,foo_rsrv_trace,foo_open,foo_close,NULL,&foo_minfo,NULL} struct qinit foo_rinit_debug = { foo_rput_debug,foo_rsrv_debug,foo_open,foo_close,NULL,&foo_minfo,NULL} struct qinit foo_rinit_timestamp = { foo_rput_timestamp,foo_rsrv_timestamp,foo_open,foo_close,NULL,&foo_minfo ,NULL}

【００５７】同様に、書込み側のためのキューイニット
のものが、定義される。次に、代替ストリームタブのも
のを定義する：

【００５８】

【表７】 struct streamtab foo_trace_info ={&foo_rinit_trace, &foo_winit_trace}; struct streamtab foo_debug_info ={&foo_rinit_debug, &foo_winit_debug}; struct streamtab foo_timestamp_info ={&foo_rinit_timestamp, &foo_winit_timestamp};

【００５９】最後に、代替ストリームタブのものが、st
r_alt_install()によって構成される：

【００６０】

【表８】 struct streamtab * streamtabs[3] ={ &foo_trace_info, &foo_debug_info, &foo_timnestamp_info } str_alt_install("foo",STR_IS_DEVICE,3,streamtabs);

【００６１】もし、以下の状況の内の一つが起こった場
合は、str_alt_install(name,flags,n,streamtabs)が失
敗となる： ・ネーム(name)が空である。 ・nが否定である。 ・nが肯定的であるが、ストリームタブ(streamtabs)が
空である。 ・フラグが、STR_IS_MODULE又はSTR_IS_DEVICEを含まな
い。 ・ネームによって指定されたモジュールやドライバが、
設置されなかった。 ・代替ストリームタブがすでに設置されて、モジュール
やドライバのアクティブ・インスタンスがある。

【００６２】たとえモジュールやドライバのアクティブ
・インスタンスがあっても現在設置された代替ストリー
ムタブがない場合には、str_alt_install()は代替スト
リームタブが設置されることを許可する。すでに設置さ
れた代替ストリームタブを変えるかアンインストールす
るために、モジュールやドライバのすべてのアクティブ
・インスタンスは、最初に閉じられなければならない。
代替ストリームタブをアンインストールすることは、st
r_alt_install(name,flags,0,NULL)を呼び出すことによ
ってされる。

【００６３】上記の開発者供給の代替ストリームタブの
他に、通常のストリームタブが構成されるとき自動的に
構成される各Streamsモジュールやドライバのために、
ＳＴＲＥＡＭＳはデフォルト代替ストリームタブを自動
的に供給する。たとえモジュールやドライバのための開
発者供給の代替ストリームタブがなくても、このデフォ
ルト代替ストリームタブが存在する。デフォルト代替ス
トリームタブのキューイニットのすべての内容は、通常
のストリームタブのそれに置かれたルーチンを除いて同
一である。デフォルト代替ストリームタブの置かれたル
ーチンを以下に示す：

【００６４】

【表９】 - Call network tracing and logging ("NETTL") to trace the message: ktrc_ write() with subsys_id = STREAMS kind = PDU_IN for M_DATA at read-side, HDR_IN for other message types at read-side, PDU_OUT for M_DATA at write-side, HDR_OUT for other message types at write-side. path_id = module id - Call the original routine.

【００６５】動的代替ストリームタブの外部仕様 ２つの新しいSTREAMS ioctlコマンドは、動的にモジュ
ールやドライバのストリームタブが持つストリームを交
替するために使用される。ioctlコマンドの中の一つが
モジュールのアクティブ・インスタンスを変えるために
使用され、そして、他のioctlコマンドは、モジュール
の将来のインスタンスを変えるために使用される。

【００６６】

【表１０】 #include <sys/types.h> #include <stropts.h> #include <stream.h> int ioctl (int fd,int command,arg);

【００６７】I_ALTSTRTAB_ACTIVEが、新しいSTREAMS io
ctlコマンドであり、そして、それは、ターゲット・ス
トリームのオーナか超特権のある管理者がモジュールや
ドライバの与えられたアクティブ・インスタンスのため
にキューイニット・ルーチンを交替することを許可す
る。argは、以下のメンバを含むストラルトアクティブ
(straltactive)構造を指さなければならない：

【００６８】

【表１１】 long alt_major; /* major number */ long alt_minor; /* minor number */ int alt_index; /* alternative streamtab index */ unsigned int alt_flags; /* STR_IS_MODULE/DEVICE */ char aft_name[FMNAMESZ+1]; /* name of module or driver */

【００６９】・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_m
ajorによって指定されたすべてのアクティブ・ストリー
ムが、ターゲット・ストリームである。特権ユーザーは
必然的に、任意のストリームのモジュールやドライバを
変えるために、すべてのSTREAMSインプリメンテーショ
ンの標準部品であるストリーム管理ドライバ（「ＳＡ
Ｄ」）を使用することができる、しかし、それはＳＡＤ
ドライバである必要はない。ＳＡＤドライバはシステム
の中であらゆるストリームを知っているＳＴＲＥＡＭＳ
管理ドライバである。そして、それは各ストリームがど
こに位置するか知っている。 ・alt_indexフィールドは、どの代替ルーチンが使用さ
れることになっているか指定する。もしモジュール・コ
ンフィギュアＮの代替ストリームタブがstr_alt_instal
l()経由ならば、それは以下の値の中で一つである：

【００７０】

【表１２】 NORMAL_STRTAB オリジナルのストリームタブの中のルーチン。 DEFAULT_ALT_STRTAB デフォルト代替ストリームタブの中のルーチン。 ０ str_alt_installを通して通過した最初のストリームタブ の中のルーチン。 １ str_alt_installを通して通過した二番目のストリームタ ブの中のルーチン。 ・ ・ ・ Ｎ−１ str_alt_installを通して通過した第Ｎ番目のストリーム タブの中のルーチン。

【００７１】フェイル時に、errnoには以下の値がセッ
トされる： EACCES alt_majorはALT_OWN_MAJORでなく、ユーザはsu
per_privilegeを持たない。 EFALUT argは、割当られたアドレス空間の外側を示
す。 EINVAL alt_name、alt_major、alt_minor、alt_flag
s、又はalt_indexは、不適当である。

【００７２】マルチプレクサの下にリンクされたストリ
ームのモジュールやドライバのキューイニット・ルーチ
ンを交替することを許可するために、I_ALTSTRTAB_ACTI
VE ioctlは、マルチプレクサの下にリンクされたストリ
ームに呼び出される。例えば下位のｍｕｘルーチンを交
替するために、I_ALTSTRTAB_ACTIVE ioctlは、マルチプ
レクサのネームを指定している下位のストリームに呼び
出される。

【００７３】下位のマルチプレクサのキューイニット・
ルーチンを交替するのを許可するために、マルチプレク
サの下にリンクされるストリームに、I_ALTSTRTAB_ACTI
VE ioctlは、呼び出される。

【００７４】I_ALTSTRTAB_FUTUREはこれとは別のコマン
ドであり、それはモジュールやドライバのその後にオー
プンされたインスタンスのキューイニット・ルーチンを
変える。このコマンドも代替ストリームタブによって指
定されたモジュールに送り出されるモジュール情報を変
える。即ち、モジュールやドライバの次のオープン・イ
ンスタンスは代替ストリームタブ（代替キューイニット
のものと代替モジュール情報）を使用する。このioctl
コマンドは、モジュールやドライバのアクティブ・イン
スタンスに影響を及ぼさない。argは、以下のメンバを
含むストラルトフューチャ(straltfuture)構造を指さな
ければならない：

【００７５】

【表１３】 int alt_index; /* alternative streamtab index */ unsigned int alt_flags; /* STR_IS_MODULE/DEVICE */ char alt_name[FMNAMESZ+1]; /* name of module or driver */

【００７６】alt_nameフィールドとalt_indexフィール
ドは、上述のように記述される。フェイル時、errnoは
以下の値にセットされる： EACCES ユーザは、超特権を持たない。 EFALUT argは、割当られたアドレス空間の外側を示
す。 EINVAL alt_name、alt_flags、又はalt_indexは、不適
当である。

【００７７】内部デザイン 以下の記述は、読取り側ルーチンのものである。別のル
ーチン、即ち、書込み側とmux読取り側とmux書込み側の
ために、ここで記述されたダイナミック機能置換メカニ
ズムが同様に作動する。モジュールのインスタンスでな
くモジュール毎に供給されるストリームタブのものを以
下に示す。 ・オリジナルの通常のストリームタブ。 ・デフォルト代替ストリームタブ。モジュールがstr_al
t_install()を通してインストールした代替ストリーム
タブのもの。

【００７８】また、各インストールされたモジュールや
ドライバのための一つのｍｏｄｓｗ構造がある。新しい
struct modswを次に示す：

【００７９】

【表１４】 struct modsw { struct modsw * d_next; /* next modsw */ struct modsw * d_prev; /* previous modsw */ char d_name[FMNAMESZ+1]; /* unique module name */ char d_flaos; /* OLD_OPEN,UP_MODE */ SQHP d_sqh; /* for module/elsewhere synch */ int d_curstr; /* current streamtab index */ struct streamtab * d_str; /* normal streamtab */ struct streamtab * d_default_alt; /* default alternative streamtab */ int d_naltstr; /* # of alternative streamtabs */ struct streamtab d_altstr; /* alternative streamtab array */ int d_sq_level /* synch level */ int d_nrefcnt; /* reference count */ int d_major; /* major # (should be unique) */ };

【００８０】ストラクト(struct)待ち行列は、内部に新
しく記述されたQUEUE_KERNEL_FIELDSを持つ：

【００８１】

【表１５】 struct modsw * q_modsw; /* pointer to struct modsw */

【００８２】I_ALTSTRTAB_ACTIVE ioctlとI_ALTSTRTABL
_FUTRUE ioctlのためのアルゴリズムの要素を、次に示
す：

【００８３】

【表１６】 I_ALTSTRTAB_ACTIVE ioctl if(alt_major == ALT_OWN_MAJOR) { current sth is the target stream: } else { check the caller's credentials; find sth for [alt_major,alt_minor]; } acquire mult_sqh lock to prevent plumbing; search for the target queue specified by alt_name[]; q->q-qinfo = pointer to the appropriate alternative qinit; I_ALTSTRTABL_FUTRUE ioctl check the caller's credentials find modsw for module specified by alt_name[]; modsw.d_curstr= alt_index;

【００８４】図７は、ＳＴＲＥＡＭＳフレーム・ワーク
のために本発明に従ってダイナミック機能置換を実行す
るデータ構造を示しているブロック構成図である。双方
向性データパス13を供給するコンピューターシステム11
の中で、データ構造10が、ユーザ・プロセスと、動的に
追加されるか移される中間処理エレメントであるモジュ
ール14と、前記データ経路と、及びデバイスドライバ15
との間で実行される。デバイス・ドライバは、システム
・カーネル18の中のレジデントであって、前記カーネル
と装置16の間にデータを伝送するために前記装置16を制
御する。ユーザ・プロセスによって書かれたデータはダ
ウンストリームをドライバの方へ進む、そして、ドライ
バによって装置から受け取られたデータはユーザ20で検
索されるためにアップストリームを進む。

【００８５】システム、即ち、str_install()とstr_alt
_install()にモジュールやドライバをインストールする
ために使用されるユーティリティを通して、モジュール
やドライバがインストールされたあと、移動中に機能を
置換することを簡単に図８に示している。図８に示され
たデータ構造は、アプリケーション要求を基礎としてい
る。本発明の実施例は、容易性を追加するだけでなく
て、マルチプロセッサ・インプリメンテーションや標準
化に関連する問題を回避するデータ構造を主に改善す
る。そのような構造がモジュールやドライバの開発者に
よってでなくＳＴＲＥＡＭＳフレーム・ワークによって
制御されるので、これらのデータ構造は、時間の経過や
タイミングを考慮せずに更新される。更に、標準の構造
を使用することによって、開発者が専門のトレーニング
をする必要がなく、ここで記述された本発明に従ってそ
れらのプロダクトが実行される。このように、本発明は
開発時間の速度を上げて、費用を減らして、開発者の参
入をより好適にする。

【００８６】データ構造は、最低限、特別なモジュール
かドライバのインスタンスを実行する通常機能110と、
オプションのモジュールかドライバのインスタンスを実
行する少くとも一つの代替機能120、130と、モジュール
とドライバに変更を必要とすることなくオリジナルの実
行パスか新しい実行パスを実行し、通常機能を少なくと
も一つの代替機能で動的に置換する制御コマンドを生成
するコントローラー140と、を含む。

【００８７】データ構造が、代替機能、例えば、特別な
事象だけを又は特別な状況の下にトレースするためにシ
ステム・トレーシング機能をカスタマイズする機能や；
指定されたシステム問題を対象とするためにカスタム・
フェイル・キャッチャを適用するためにサポート機能を
供給する機能や、インスタンス単位毎にパッチを適用す
る機能や、シングル・データ・パスをテストすることを
許可しデータ・パス処理の柔軟性と制御性が増加するこ
とを許可する機能や、あるいは、すべてのモジュールや
ドライバのインスタンスの置換かインスタンス単位毎の
置換を許可する機能、を含むことができる。

【００８８】データ構造が、STREAMSフレーム・ワーク1
9の中で実行される。その中で、各モジュールかドライ
バがキューイニット構造にポインタを含むストリームタ
ブ構造を定義する（図８参照）。データ構造の中で、キ
ューイニット構造が読取り、書込み、及び読取りマルチ
プレクサのためにあり、キューイニット構造がopen、cl
ose、put、及びserviceの機能アドレスを含み、そし
て、管理機能がＳＴＲＥＡＭＳフレーム・ワークによっ
てモジュールかドライバ上で呼び出される。キューイニ
ット構造内で定義された機能は、現在のアプリケーショ
ン実行パスに基づくＳＴＲＥＡＭＳフレーム・ワークに
よって、自動的に実行される。

【００８９】このように、コントローラー140は、代替
ストリームタブへの前記構造のアドレスと新しい機能ア
ドレスを定義するキューイニット構造を再設定する制御
コマンドを生成する。本発明の一つの実施例の中で、デ
フォルト代替ストリームタブのキューイニット構造のす
べての内容は、ｐｕｔルーチンを除いて通常のストリー
ムタブのそれらと同一である。

【００９０】コントローラーが、動的にモジュールやド
ライバのストリームタブが持つSTREAMSを代替するため
に使用される少くとも一つのＳＴＲＥＡＭＳ ioctlコマ
ンドや、モジュールのアクティブ・インスタンスを変え
るために使用されるioctlコマンドや、モジュールの将
来のインスタンスを変えるために使用されるioctlコマ
ンドを含む制御コマンドを生成する。

【００９１】データ構造は、すべてのドライバ情報を定
義するＭＯＤＳＷテーブル100を含む。ＭＯＤＳＷテー
ブルの中で、ポインタが異なるストリームタブ110、12
0、130にある。ここで記載されたデータ構造は、ＭＯＤ
ＳＷテーブル（デフォルト代替ストリームタブ120を選
択するために使用される例えばd_default_altエント
リ）に少くとも一つの新しいストリームタブ・エントリ
を追加する。特別なドライバかモジュールがシステムに
インストールされるとき、ユーザか開発者は、それらが
そのデフォルトにあって欲しいことを定義することがで
きる。それから、ここで記述されたデータ構造は、スト
リームタブのリンク・リストを通して幾つかの代替スト
リームタブを許可する。このように、ユーザが適合テス
トや機能テストを実行したい場合、システムをリロード
することは必要でない。むしろ、新しいストリームタブ
を選択することのみが必要となる。

【００９２】データ構造を整理することによって、拡張
機能かオプションのデータ構造を追加するすることがで
きる。例えば、ストリームが各待ち行列側に開かれると
き、（上述のように）読取り待ち行列と書込み待ち行列
がある。読取り待ち行列の中で、参照されたポインタ
が、待ち行列情報としてある。待ち行列情報が、他のス
トリームタブの後ろをポイントすることによって、移動
中のこれらの代替ストリームタブのいずれかを選択する
ことができる。デフォルトで、システムは特定のストリ
ームタブ（例えばノーマル・ストリームタブ110）を選
択する。しかし、望む場合、待ち行列ポインタを、シス
テムの範囲内で構成される代替ストリームタブ120、130
のいずれかにセットすることができる。ユーザ空間の見
解からは、どのストリームタブが選択されることになっ
ているか指定しろという１つ又は複数のＩＯＣＴＬコマ
ンドを生成するコントローラーを実行することが必要な
だけである。そのような選択の結果、ＳＴＲＥＡＭＳフ
レーム・ワークの変更、即ち、アプリケーションの停止
は、必要でない。このように、ＳＴＲＥＡＭＳフレーム
・ワーク自身が、そのような代替機能と拡張機能を実行
するために適応させられる。付加ＩＯＣＴＬコマンドを
使用可能にすることが必要なだけで、定義済み機能を含
むデータ構造がつくられる。

【００９３】ｍｏｄｓｗ（図８）の中で、ポインタd_cu
rstrは、現在のストリームタブを示す。このように、代
替ストリームタブが選択されて、システムが現在の状態
に復帰されるとき、ポインタd_curstrは、システムを現
在のストリームタブの後ろへセットする。それゆえに、
例えば、トレーシングやデバッギングやタイム・スタン
プのためのキューイニットや、拡張又はオプション機能
をインストールするための代替ストリームタブや、特定
のシステム・テストのためのユーザ又は開発者によって
呼び出されたサンプル・コードの構造を含む本発明に従
って、図８にテンプレートのブロック概要図を示す。

【００９４】以下に、本発明の実施態様を示す。 （１）ユーザ・プロセス、動的に追加され移される中間
処理エレメントであるモジュール、データ・パス、及び
デバイス・ドライバとの間に双方向性データパスを提供
するコンピュータ・システムで実行されるデータ構造で
あって、前記デバイス・ドライバが、システム・カーネ
ルの中に常駐し、前記カーネルとの間でデータを伝送す
る周辺装置を制御し、前記ユーザ・プロセスによって書
き込まれたデータが前記ドライバ方向へダウンストリー
ム上を進み、前記ドライバによって前記デバイスから受
け取られたデータがユーザによって検索されるためにア
ップストリーム上を進み、特定のモジュール又はドライ
バのインスタンスを実行する通常機能手段と、オプショ
ンのモジュール又はドライバのインスタンスを実行する
１又は複数の代替機能手段と、前記モジュールと前記ド
ライバに変更を必要とすることなく、今まで通り通常の
実行パスか、あるいは、新しい実行パスによる処理で、
前記通常機能手段を前記１又は複数の代替機能手段に動
的に置換する制御コマンドを生成するコントローラと、
を有する前記データ構造。

【００９５】（２）更に、特別な事象か特別な状況の下
でだけトレースを行うシステム・トレーシング機能をカ
スタマイズする代替機能手段を有する（１）記載のデー
タ構造。 （３）更に、特定のシステム問題を目的とするカスタム
・フェイル・キャッチャを適用するサポート機能を提供
する代替機能手段を有する（１）又は（２）記載のデー
タ構造。 （４）更に、インスタンス単位毎にパッチを適用する代
替機能手段を有する（１）乃至（３）記載のデータ構
造。 （５）更に、シングルのデータ・パスでテストが可能と
なり、データ・パス実行の柔軟性と制御性が増加された
代替機能手段を有する（１）乃至（４）記載のデータ構
造。 （６）更に、モジュールかドライバ何れかの全てのイン
スタンスを置換するか、又はインスタンス単位毎に置換
することができる代替機能手段を有する（１）乃至
（５）記載のデータ構造。 （７）前記システムがＳＴＲＥＡＭＳフレーム・ワーク
の中で実行される（１）乃至（６）記載のデータ構造。 （８）各々のモジュール又はドライバが、キューイニッ
ト構造にポインタを含むストリームタブ構造を定義する
（７）記載のデータ構造。 （９）前記キューイニット構造が前記ＳＴＲＥＡＭＳフ
レーム・ワークによってつくられる読取り、、書込み、
読取りマルチプレクサ、及び書込みマルチプレクサの待
ち行列に使用される（８）記載のデータ構造。

【００９６】（１０）前記キューイニット構造が、前記
ＳＴＲＥＡＭＳフレーム・ワークによってモジュール又
はドライバ上で呼び出されたオープン、クローズ、プッ
ト、サービス、及び管理上の機能ための機能アドレスを
含む（８）記載のデータ構造。 （１１）機能が、現在のアプリケーション実行パスに基
づく前記ＳＴＲＥＡＭＳフレーム・ワークによって自動
的に実行される前記キューイニット構造の範囲内で定義
され、前記コントローラが、代替ストリームタブへ前記
構造のアドレスを再設定する制御コマンドと新しい機能
アドレスを定義するキューイニット構造を生成する
（８）記載のデータ構造。 （１２）デフォルト代替ストリームタブの前記キューイ
ニット構造の全ての内容が、プット・ルーチンを除いて
通常のストリームタブのものと同一である（１１）記載
のデータ構造。 （１３）更に、前記コントローラが、ＳＴＲＥＡＭＳモ
ジュール又はドライバのストリームタブの内容を動的に
代替するために使用される１又は複数のＳＴＲＥＡＭＳ
ｉｏｃｔｌコマンドを有する（８）記載のデータ構
造。 （１４）更に、前記コントローラが、モジュールのアク
ティブ・インスタンスを変えるために使用されるｉｏｃ
ｔｌコマンドを有する（１３）記載のデータ構造。 （１５）更に、前記コントローラが、モジュールの将来
のインスタンスを変えるために使用されるｉｏｃｔｌコ
マンドを有する（１３）記載のデータ構造。

【００９７】（１６）ユーザ・プロセス、動的に追加さ
れ移される中間処理エレメントであるモジュール、デー
タ・パス、及びデバイス・ドライバとの間に双方向性デ
ータパスを提供するコンピュータ・システムにおいて、
データ構造を実行する方法であって、前記デバイス・ド
ライバが、システム・カーネルの中に常駐し、前記カー
ネルとの間でデータを伝送する周辺装置を制御し、前記
ユーザ・プロセスによって書き込まれたデータが前記ド
ライバ方向へダウンストリーム上を進み、前記ドライバ
によって前記デバイスから受け取られたデータがユーザ
によって検索されるためにアップストリーム上を進み、
前期システムが、キューイニット構造を示すポインタを
含むストリームタブ構造を定義する各のモジュール又は
ドライバを有するＳＴＲＥＡＭＳフレーム・ワーク内で
実行され、特定のモジュール又はドライバのインスタン
スを実行する通常機能を供給するステップと、オプショ
ンのモジュール又はドライバのインスタンスを実行する
１又は複数の代替機能を提供するステップと、前記モジ
ュールと前記ドライバに変更を必要とすることなく、今
まで通り通常の実行パスか、あるいは、新しい実行パス
による処理で、前記通常機能を前記１又は複数の代替機
能に動的に置換する制御コマンドを生成するステップ
と、を有する前記方法。

【００９８】（１７）前記キューイニット構造が前記Ｓ
ＴＲＥＡＭＳフレーム・ワークによってつくられる読取
り、、書込み、読取りマルチプレクサ、及び書込みマル
チプレクサの待ち行列に使用される（１６）記載の方
法。 （１８）前記キューイニット構造が、前記ＳＴＲＥＡＭ
Ｓフレーム・ワークによってモジュール又はドライバ上
で呼び出されたオープン、クローズ、プット、サービ
ス、及び管理上の機能ための機能アドレスを含む（１
６）記載の方法。 （１９）更に、現在のアプリケーション実行パスに基づ
く前記ＳＴＲＥＡＭＳフレーム・ワークによって前記キ
ューイニット構造の範囲内で定義される機能を自動的に
実行するステップと、代替ストリームタブへ前記構造の
アドレスを再設定する制御コマンドと、新しい機能アド
レスを定義するキューイニット構造を生成するステップ
と、を有する（１６）乃至（１８）記載の方法。

【００９９】（２０）デフォルト代替ストリームタブの
前記キューイニット構造の全ての内容が、プット・ルー
チンを除いて通常のストリームタブのものと同一である
（１６）乃至（１９）記載の方法。 （２１）更に、ＳＴＲＥＡＭＳモジュール又はドライバ
のストリームタブの内容を動的に代替するために使用さ
れる１又は複数のＳＴＲＥＡＭＳ ｉｏｃｔｌコマンド
を使用するステップを有する（１６）乃至（２０）記載
の方法。 （２２）更に、モジュールのアクティブ・インスタンス
を変えるために使用されるｉｏｃｔｌコマンドを使用す
るステップを有する（１６）乃至（２１）記載の方法。

【０１００】

【発明の効果】上述のように、本発明によって、追加す
る互換性の複雑性や欠落とパフォーマンス低下といった
２つの劣化なく、いろいろな拡張又はオプションが容易
に使用可能であるＳＴＲＥＡＭＳフレーム・ワークが供
給できることとなった。

【０１０１】また、更に、本発明によって、ＳＴＲＥＡ
ＭＳフレーム・ワークに、ダイナミック機能置換として
参照される拡張性を提供することができるようになっ
た。

【図面の簡単な説明】

【図１】単一なストリームを示すブロック図である。

【図２】ＳＴＲＥＡＭＳ待ち行列を示すブロック図であ
る。

【図３】ストリーム上でのモジュールを示すブロック図
である。

【図４】多重ドライバを示すブロック図である。

【図５】従来のパイプを示すブロック図である。

【図６】ＦＩＦＯを示すブロック図である。

【図７】ＳＴＲＥＡＭＳフレーム・ワークのために本発
明に従ってダイナミック機能置換を実行するデータ構造
を示しているブロック構成図である。

【図８】本発明に従ってダイナミック機能置換を含むＳ
ＴＲＥＡＭＳフレーム・ワークのデータ構造を示してい
るブロック図である。

Claims (1)

【特許請求の範囲】
1. 【請求項１】ユーザ・プロセス、動的に追加され移され
   る中間処理エレメントであるモジュール、データ・パ
   ス、及びデバイス・ドライバとの間に双方向性データパ
   スを提供するコンピュータ・システムで実行されるデー
   タ構造であって、 前記デバイス・ドライバが、システム・カーネルの中に
   常駐し、前記カーネルとの間でデータを伝送する周辺装
   置を制御し、 前記ユーザ・プロセスによって書き込まれたデータが前
   記ドライバ方向へダウンストリーム上を進み、 前記ドライバによって前記デバイスから受け取られたデ
   ータがユーザによって検索されるためにアップストリー
   ム上を進み、 特定のモジュール又はドライバのインスタンスを実行す
   る通常機能手段と、 オプションのモジュール又はドライバのインスタンスを
   実行する１又は複数の代替機能手段と、 前記モジュールと前記ドライバに変更を必要とすること
   なく、今まで通り通常の実行パスか、あるいは、新しい
   実行パスによる処理で、前記通常機能手段を前記１又は
   複数の代替機能手段に動的に置換する制御コマンドを生
   成するコントローラと、 を有する前記データ構造。