JP3033935B2

JP3033935B2 - アダプタ・ハードウェアへのインターフェース方法

Info

Publication number: JP3033935B2
Application number: JP7074775A
Authority: JP
Inventors: ロバート・アレン・レイノルズ; デビッド・ウィリアム・シェフィールド
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1994-06-30
Filing date: 1995-03-31
Publication date: 2000-04-17
Anticipated expiration: 2015-04-17
Also published as: US5590313A; JPH0816495A; EP0690388A3; EP0690388A2

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はコンピュータに使用され
るサブシステムに関し、特に、複数プロトコル環境にあ
る装置のインターフェース・サブシステムに関する。

【０００２】

【従来の技術】最近のコンピュータ・システムでは、様
々の異なったアプリケーションやプロトコルを有する広
範囲の環境にそのシステムを拡張して使用することが当
たり前になってきている。例えば、ＩＰＩ−３およびＳ
ＣＳＩあるいはＴＣＰ／ＩＰをそれぞれサポートするフ
ァイバ・チャンネル・サブシステムのような媒体アプリ
ケーションおよび通信アプリケーションおよびプロトコ
ルをサポートするシステムが求められている。

【０００３】こうした常に増大する要求に対応させるた
めにコンピュータの役割が拡大すると同時に、産業界に
厳しい束縛を持続的に課すことにもなる。ユーザは融通
性と機能性が増大することを望んでいるが、同時に、よ
り低価格でそれを手に入れたいと望んでいる。

【０００４】こうしたことで起こり得る問題の代表的な
例として、あるアプリケーションでは媒体アプリケーシ
ョンと通信アプリケーションの両方をサポート可能な単
独のアダプタを設ける必要がある。しかし、これはコス
ト的な面での対処例であり、媒体、通信、および他のア
プリケーションにたいして別々のアダプタを設けること
を単純に実現できるものではない。むしろ、異なったア
プリケーションおよび関連のプロトコルをサポートでき
る複数目的用の単一のアダプタを提供する必要がある。
しかし、媒体アプリケーションと通信アプリケーション
のように２つ以上の大きく異なったアプリケーションや
プロトコルのタイプをサポートできる単一のアダプタ用
の単一装置ドライバ・インターフェースを提供するに
は、極めて困難な問題が存在する。

【０００５】ちなみに、媒体プロトコルと通信プロトコ
ル間の相違の重要点をまとめることは、複数のプロトコ
ルを扱う発明の重要性およびそうしたプロトコルの大き
な変化や特性に関連した問題を理解するうえで有益と思
われる。

【０００６】媒体プロトコルは通常、書込みと読取りが
出会う、例えば、書込みコマンドが送信され一定量のデ
ータが戻ると期待される同じブロックとリンク・サイズ
を有する送信データを含んでいる。逆に、通信プロトコ
ルは通常、データの受信が量的に不確定で、唐突かつ時
間的に不確定、例えば非同時性であるという特性を有す
る。ここに説明のインプリメンテーションは関連のＢＵ
ＦおよびＭＢＵＦ構造を有する媒体プロトコルと通信プ
ロトコルである異なったプロトコルに関するものである
が、本発明はこれに限定するものではない。本発明は、
前記した３つの共通リンク、つまりデータのポインタ、
データの長さ、ＤＭＡをセット・アップするためのクロ
ス／メモリ記述子等を有するインターフェースの異なっ
た構造を利用する複数のプロトコルのアプリケーション
を認めるものである。従って、前記３つの要素が存在す
る限り、異なった構造を利用する本発明の教示に従い同
じドライバと通信するために、経路における異なった構
造を使用するいかなるプロトコルも組み合わることがで
きる。

【０００７】より一般的な感覚では、媒体プロトコルと
通信プロトコルは非同期あるいは同期データを扱ってい
るか、また、固定データ・ブロックのサイズか可変デー
タ・ブロックのサイズであるかにより識別されるようで
ある。異なったプロトコルは、可変の特性を有するデー
タの管理を効率よく制御するため異なった構造を提供す
る必要性から生じ、ＢＵＦ構造を用いる媒体プロトコル
と、ＭＢＵＦ構造を用いる通信プロトコルを生じさせ
る。

【０００８】複数のプロトコルをサポートするこうした
問題にたいする従来のアプローチは、単一のデータ構造
に対して設けることと、ソフトウェア層間でデータをコ
ピーすることであった。しかし、当業界で公知のよう
に、高能力のインターフェースを実現する鍵は（例え
ば、媒体アプリケーションおよび通信アプリケーション
で求められるように）その反対、つまりソフトウェア層
間でのデータのコピーを避けることである。

【０００９】データの再コピーに関連した能力上の不利
をさけるために従来技術で取られた別の方法は、装置ド
ライバがその核に存在しない異なったアーキテクチャを
設けることであった。この例はシステム制御ブロック
（ＳＣＢ）アーキテクチャであった。データはＳＣＢフ
ォーマット内で設けられ、そのインターフェースとして
図２に示した方法で順次伝えた。このシステムで取られ
た方法はプロトコル・スタック・コードを書き換えて単
一の装置ドライバに作用することであった。この方法は
コードの本質的な部分の再インプリメンテーションを必
要とするという重大な欠点をもつばかりではなく、その
パフォーマンスのヒットはデータのコピーの例から得ら
れたものと合致させれないままであった。

【００１０】例えば（ＩＢＭ社製造のＰＳ／２コンピュ
ータ用のＳＣＢにより提供されるような）媒体プロトコ
ルおよび通信プロトコル用に、共通の装置ドライバのイ
ンターフェース構造に対する基盤の形で設けるため幾つ
かの試みがなされているが、他の環境においてはその問
題は未だに全く取り組まれていない。したがって、媒体
および通信のような複数のプロトコルに対する共通の装
置ドライバのインターフェース構造はＵＮＩＸベースの
システムについて現在のところ存在していない。

【００１１】

【発明が解決しようとする課題】上述のように、ソフト
ウェア層間でデータをコピーする必要性がない複数プロ
トコルの装置インターフェース・サブシステムをもたら
すための方法が望まれている。

【００１２】本発明の別の目的は、媒体およびアプリケ
ーション・プログラムの処理環境で単一のアダプタを用
いることの可能な低コストでインプリメンテーションが
容易なサブシステムをもたらすための方法を提供するこ
とである。

【００１３】本発明の他の目的は、前から存在するコア
構造を利用でき、装置ドライバ・コードを新しい構造用
に書き変える必要がない複数プロトコル環境で使用可能
な装置ドライバのサブシステム・インターフェースを提
供することである。

【００１４】さらに、本発明の他の目的は、従来のデー
タ・コピー技術で得るのが困難である高能力な多目的イ
ンターフェースを提供することである。

【００１５】

【課題を解決するための手段】本発明による方法は、媒
体および通信を含む複数のプロトコルを最小の経費で単
一のアダプタで同時に処理可能とするものである。

【００１６】媒体および通信装置への第１インターフェ
ース構造は、ＤＭＡ用の各々のバッファをマッピングす
るためのバッファ・アドレス、バッファ長さ、クロス・
メモリ記述子のそれぞれ類似の構成要素特性を有すると
定義される。この第１構造はチェーン可能であり、デー
タは単一操作用の複数の隣接しないデータ・バッファか
ら集められるか、それに分散させられる。プロトコル・
ヘッドが第１インターフェース構造のチェーンに対しポ
インタを用いて完成するように共通の構造が設けられ
る。このアーキテクチャは、各制御要素用に複数のバッ
ファ記述子を設けて種々のユーザのバッファに記述する
ように構成される。

【００１７】複数バッファ構造のチェーンは、第１構造
あるいはサポートすべき他の構造に対するポインタを含
み、この情報はそのアダプタに対するバッファをマップ
し、かつＤＭＡアドレスを得るようにアダプタ・ドライ
バに採用される。この方法では、積層アーキテクチャの
利点が得られると同時に、現在のインターフェースを利
用できるという柔軟性も合わせ持つ。従って、単一のア
ダプタ・ドライバを通じて処理する複数のプロトコルに
対する使い易さを実現でき、その単一アダプタではその
インターフェースをサポートする異なったアダプタで同
じプロトコル・ヘッド・コードが処理できる。

【００１８】本発明の方法は、既存のアーキテクチャへ
の統合を提供するものである。従って、バッファおよび
ＤＭＡのマネージメント、およびアダプタの取り扱いも
アダプタ・ドライバに集中させ、この機能の分散により
得られるものよりシステム資源のより効果的な配列を可
能にする。ハードウェア・インターフェースもアダプタ
・ドライバ内で孤立させ、集中アダプタへの変更はコー
ドの１セクションに限定させることが可能となる。

【００１９】

【実施例】図１は、本発明の操作を実施するための装置
ドライバ・サブシステム（図３、図４、表１）に関連し
て操作するコンピュータ・システムの望ましい実施例を
示す。このシステムは、ＣＰＵ１０、読取専用メモリ
（ＲＯＭ）１６、ランダム・アクセス・メモリ（ＲＡ
Ｍ）１４、Ｉ／Ｏアダプタ１８、ユーザ・インターフェ
ース・アダプタ２２、通信アダプタ３４、ディスプレイ
・アダプタ３６、それら全てを相互接続する共通アドレ
ス／データ／制御パスあるいはバス１２から構成され
る。前記構成要素の各々は当業界で公知の技術を使用し
て共通バスにアクセスし、また、ＣＰＵをバス・マスタ
としてこのシステム内の各構成要素に特定のアドレス・
レンジを専用としてあたえるような方法を有する。図１
のシステムに使用された当業界で公知の他の技術は、Ｄ
ＡＳＤ２０あるいはデータ処理システムのＲＡＭ１４に
見られるネットワークのような外部装置から高速でデー
タを転送するために使用したダイレクト・メモリ・アク
セス（ＤＭＡ）などがある。図１に示すように、これら
ＤＡＳＤ２０のような外部装置はＩ／０アダプタ１８の
ような各々のアダプタを通じて共通バス１２にインター
フェースする。ディスプレイ３８のような他の外部装置
も、ディスプレイ・アダプタのようなそれぞれのアダプ
タを同様に用い、バス１２とディスプレイ３８あるいは
他の装置とのデータの流れを得る。種々のユーザ側イン
ターフェース手段は相互接続用に設けられ、ユーザ側イ
ンターフェース・アダプタ２２を伴い、図ではジョイ・
スティク３２、マウス２６、キーボード２４、スピーカ
２８などのような代表的なユーザ入力装置をそのアダプ
タに接続している。それらは公知のものであり、その詳
細な説明は省略する。

【００２０】詳細は後述するが、表１および図３、図４
を参照にして説明するようにプログラム・コードのイン
プリメンテーションの際、図１のシステムは本発明によ
る複数プロトコル環境用の単一装置ドライバに対する設
備を効果的にするためプログラムを実行する。

【００２１】初めに、高レベルな説明を本発明の全体的
な操作について行い、図２から図４を参照にしてより詳
細な説明を行う。ここで説明するのは、図示する実施例
ではＳＣＢインターフェースをサポートする複数プロト
コル装置と共に使用する独特の装置ドライバ・サブシス
テムのインターフェースである。ＳＣＢアーキテクチャ
（ＩＢＭコーポレーションによるSCB Architecture Sup
plement To The IBM Personal System/2 Hardware Inte
rface Technical Reference Architecturesに定義され
ており、この文献は本願の引例として開示）は、一般的
な待ち行列制御ブロック・インターフェースをアダプタ
に与え、同じインターフェースを使用するアダプタを通
じ複数タイプのプロトコルを実行可能とする。ファイバ
・チャンネル・アダプタは、ＴＣＰ／ＩＰのような通信
プロトコルおよびＩＰＩ−３あるいはＳＣＳＩのような
媒体プロトコルをサポートするためにこのインターフェ
ースを採用するように設けることも可能である。ここで
説明するインプリメンテーションはＳＣＢアーキテクチ
ャおよびファイバ・チャンネル・サブシステムに関する
ものであるが、本発明はそうしたことに限定されるもの
ではなく、他のアーキテクチャおよびサブシステムへの
応用も可能である。本発明の主眼は、媒体と通信の両方
を含む複数のプロトコルを可能とする独特なインターフ
ェースであり、最小の経費で同一のアダプタを通じて実
行するものである。従って、例えば、ファイバ・チャン
ネルが利用され、インターフェースが他のＳＣＢ装置に
拡張可能であり、基本的にそのコンセプトはどの装置の
インターフェースにも拡張可能である。

【００２２】図示の実施例では、基本構造はＳＣＢアダ
プタ装置を最下層に設けるようにしたものであり、ＳＣ
Ｂ制御要素を実際に待ち行列としたり、待ち行列解除と
し、またアダプタから全ての割込みを処理するものであ
る。アダプタ・ドライバも入力してくる求められてない
データに対するバッファ・マネージメントを処理し、さ
らにＤＭＡに対するバッファの全てのマッピングを処理
する。アダプタ・ドライバはアダプタ特定のものであ
り、異なったアダプタ間のＳＣＢインプリメンテーショ
ンにおける相違を処理するように作られる。これはハー
ドウェアに影響を受ける唯一の層である。この構造その
ものは固有の物ではなく、例えば、ＩＢＭコーポレーシ
ョンにより提示されたＡＩＸ（ＩＢＭの商標）処理シス
テムのＳＣＳＩサブシステムに基づいている。このサブ
システムＳＣＳＩでは、装置ヘッド（ディスク、テー
プ、およびＣＤ−ＲＯＭ装置ドライバ）は、いろいろな
装置に特定のアダプタ・ドライバを通して走行しても
よい。

【００２３】本発明で取り扱う問題は、ＳＣＢアダプタ
のような複数プロトコル・アダプタを通じて前記システ
ムのサポートに関する、それは例えば、通信プロトコル
および媒体プロトコルをサポートするものである。媒体
装置および通信装置への標準インターフェースは後述す
るＢＵＦおよびＭＢＵＦ構造である。構造が異なって
も、その両方は後述する共通の特性を幾つか有する。両
構造の重要な部分はバッファ・アドレス、バッファ長、
ＤＭＡに対しバッファをマッピングするため必要とされ
るクロス・メモリ記述子である。さらに、両構造はチェ
ーン化可能であり、複数の隣接しないデータ・バッファ
あるいは分散した複数のディスク隣接データ・バッファ
から単一操作に対する入力データ用にデータを集めるこ
とができる。

【００２４】高能力なインターフェースを得るための鍵
は、ソフトウェア層間でのデータのコピーを避けること
である。本発明では、プロトコル・ヘッド（通信あるい
はＩＰＩ−３あるいはＳＣＳＩのような）をＢＵＦある
いはＭＢＵＦ構造のチェーンにたいするポインタで記入
するという共通のＣＴＬ＿ＥＬＥＭ＿ＢＬＫ構造を設け
ることにより達成される。ここで説明するファイバ・チ
ャンネルのインプリメンテーションはそれら２つのタイ
プのバッファをサポートするが、前記した基本要素を有
する他の種類も同様に可能である。ＣＴＬ＿ＥＬＥＭ＿
ＢＬＫ構造の定義は表１に示してあり、以下に詳細に説
明する。

【００２５】表１（表中に現れる英文字の列はコマンドなどを表す記号であり、翻訳できない） struct ctl_elem_blk{ struct ctl_elem_blk *next; struct ctl_elem_blk *prev; uchar flags; /*このctl_elem_blkに対するフラッグ*/ int key; /*プロトコル・ヘッドにより使用 */ int status; /*制御要素状態 */ int num_pd_info; /*pd_info構造の数 */ int pds_data_len; /*pd_infosにおけるデータの長さ */ caddr_t reply_elem; /*回答要素 */ int reply_elem_len; /*回答要素バッファの長さ */ caddr_t ctl_elem; /*ctl elemへのポインタ */ struct pd_info *pd_info; /*PD-1情報 */ }; struct pd_info{ struct pd_info *next; uint buf_type; /*p_buf_listのバッファのタイプ */ uint pd_ctl_info; /*PD-1の初めの語 */ uint mapped_addr; /*バス・アドレス */ int total_len; /*PDの全長 */ int num_tcws; /*TCWsの数 */ caddr_t p_buf_list; /*このPD用のバッファのリスト */ ;

【００２６】ＳＣＢアーキテクチャは、各制御要素に対
し、種々のユーザ側バッファを記述するために利用され
る複数のバッファ記述子（「タイプ１パラメータ記述
子」として識別される）が存在しえるように構成する。
このＰＤ＿ＩＮＦＯ構造のチェーンはＢＵＦあるいはＭ
ＢＵＦ構造（あるいは、サポートするための特定なアダ
プタ・ドライバに適した他の構造）に対するポインタを
含む。アダプタ・ドライバはこの情報を利用してバッフ
ァをマップし、かつ、アダプタ用のＤＭＡアドレスを得
る。

【００２７】従って、前記サブシステムは現在のインタ
ーフェースを利用できる柔軟性を有し、同時に積層アー
キテクチャの利点を提供する。これは、また、複数プロ
トコルが単一のアダプタ・ドライバを通じて実行可能で
あり、同じプロトコル・ヘッドがこのインターフェース
をサポートする異なったアダプタを通じて実行可能であ
ることを意味する。

【００２８】本発明のインターフェース・サブシステム
から他にも利点が得られる。それは既存のアーキテクチ
ャに一体化できることである。例えば、既存のＳＣＳＩ
アダプタ装置ドライバを通じて実行するＳＣＳＩ装置ヘ
ッドを利用して、ＳＣＳＩプロトコル・ヘッドを通じて
実行し、また、ＳＣＳＩプロトコル・ヘッドもこのＳＣ
Ｂインターフェースを有するＳＣＳＩプロトコルをサポ
ートするどのアダプタを通じて実行する。

【００２９】さらに、バッファ・マネージメント、ＤＭ
Ａマネージメント、およびアダプタ操作は全てアダプタ
・ドライバに集中させることができる。これは、分散に
より得られるものよりシステム資源の効果的な配列を可
能とする。さらに、ハードウェア・インターフェースも
アダプタ・ドライバ内で隔離でき、統合アダプタにおけ
る変動をコードの一片に隔離させるようにする。

【００３０】図２には、従来の複数プロトコル・スタッ
クを示す機能ブロック図が示されている。この図は縦線
５３で二つに分けられている。左の部分は、通常、ディ
スク、テープ、あるいは同様な装置を通じて実行する媒
体アプリケーション４０の典型的なプロトコル・スタッ
クを示している。右の部分は、ＴＣＰ／ＩＰ、ＮＦＳ等
を通じて実行する通信アプリケーション５２の典型的な
プロトコル・スタックを示している。また、水平線５５
は媒体あるいは通信スタックのソフトウェアおよびハー
ドウェア間を分けるためのものである。図３の説明でよ
り明らかになるが、本発明は図２のインターフェース層
４２、５４に主眼をおいている。

【００３１】ここで使用の「スタック」という用語は、
例えばアプリケーション４０に起因するハードウェアで
の所望の結果をもたらすための一連の機能呼出しの概念
を意味し、従って、このスタックという用語はプロセス
機能呼出しスタックに関する。従来の操作では、ユーザ
・アプリケーション４０は通常、システム呼出しを発
し、このシステム呼出しも図１のコンピュータ・システ
ムを用いた処理システムの核における装置ドライバを呼
出し、そしてその核は所望の結果が得られるようにハー
ドウェアに対する呼出しを最終的に発する。図２はこれ
らの装置ドライバとハードウェアの種々の層を示したも
のである。特に、代表的なＳＣＳＩテープ装置ドライバ
４４とＳＣＳＩディスク装置ドライバ４６が示されてお
り、これらは後に詳細を説明するＢＵＦ構造を有するイ
ンターフェース４２によって特定のアプリケーション４
０にインターフェースを行う。このために、インターフ
ェース４２のＢＵＦ構造は３つの主たる構成要素、つま
り、読取りあるいは書込みをするデータのポインタ、こ
のデータのサイズ、そして直接メモリ・アクセスに利用
されるクロス・メモリ記述子等を有する。

【００３２】図２では、従来のシステムはＳＣＳＩアダ
プタ装置ドライバ４８を有し、これは通過した装置ドラ
イバ４４、４６とは別の構造を有する。装置ドライバ４
８の機能は図２ではＳＣＳＩアダプタ５０のようなハー
ドウェアに直接インターフェースすることであり、ＳＣ
ＳＩアダプタ５０はソフトウェア・ハードウェア境界線
５５より下にあるので、この装置ドライバ４８が実際の
ハードウェアにインターフェースを行うことを示してい
る。

【００３３】図２では、プロトコル・スタックの代表的
セットはＳＣＳＩについて示されているが、本発明はそ
れに限定するものではないことに注意すべきである。す
なわち、別の標準媒体プロトコルは当業界で公知のＩＰ
Ｉ−３のような同じように使用することが可能である。

【００３４】複数の個別ＳＣＳＩ装置５１が図２に示さ
れており、これはディスク・ドライブ、テープ・ドライ
ブ、ＣＤ−ＲＯＭドライブ等、の形をとり、その各々の
ＳＣＳＩアダプタ５０に物理的に相互接続させてある。
前記により、ソフトウェア・ハードウェア・チェーンあ
るいは媒体スタックが設けられ、それにより装置５１で
所望の結果を図１のシステムで実行する媒体アプリケー
ション４０と同じ機能となることが分かるであろう。

【００３５】図２の縦線５３の右側では、通信アプリケ
ーション５２の相関プロトコル・スタックが示されてお
り、媒体アプリケーション・スタックに関する前述の説
明に類似したものである。媒体アプリケーションと同様
に、通信アプリケーション５２がイーサネット装置ドラ
イバ５６あるいはトークン・リング装置ドライバ５８の
ようなそれぞれの装置ドライバと通信する。これらの装
置ドライバと通信アプリケーション間のインターフェー
ス５４は、詳細は後述するＭＢＵＦ構造を有するように
設ける。そのために、このＭＢＵＦ構造は媒体スタック
に関するＢＵＦ構造とは異なっている（例えば、フィー
ルドを異なった名にするなど）。しかし、また３つの構
成要素はＢＵＦ構造のものと共通にＭＢＵＦ構造に設け
る。すなわち、ＭＢＵＦ構造がデータのポインタ、この
データのサイズ、そしてＤＭＡ用のクロス・メモリ記述
子等を有するようにする。ＳＣＳＩ装置ドライバ４４、
４６の場合のように、通信装置ドライバ５６、５８はイ
ンターフェース５４のＭＢＵＦ構造の情報を採用し、ソ
フトウェア・ハードウェア線５５を越えて各々のハード
ウェア・アダプタ、つまり、イーサネット装置ドライバ
５６はイーサネット・アダプタ６０とトークン・リング
装置ドライバ５８はトークン・リング・アダプタ６２に
それぞれつながる。これは、装置ドライバとその装置と
の間に１：１の対応がある。

【００３６】本発明が取り組んだ異なった構造およびプ
ロトコルの３つの共通した特徴（データのポインタ、こ
のデータのサイズ、そしてＤＭＡ用のクロス・メモリ記
述子）の重要性のために、その重要性を簡単に説明す
る。装置ドライバは全体の機能に基づき「通信」ドライ
バあるいは「媒体」ドライバと特徴づけることが可能で
ある。しかし、そのように特徴づけることより、その利
用する構造のためそれらは本来的に異なっており、異な
った方法でデータをマネージメントすることを単純に認
識することがより重要である。

【００３７】例えば、テレタイプあるいはＴＴＹドライ
バが通信ドライバと考えることができるが、実際には通
信ドライバの機能に、その機能を実行する独自の特性構
造を有するスクリーン・エミュレーションなどのような
別の機能を追加して行う。同様に、マウス・ドライバや
キーボード・ドライバも従来の通信ドライバと同様の機
能を使用する。

【００３８】しかし、これは中央部には無関係であり、
他のドライバとは異なった方法でデータを管理しなくて
はならないという事実により、それらは単純に識別され
る。つまり、その下のアダプタと通信する方法、および
そのデータを管理するため利用したデータ構造が実質的
に異なっており、これが本発明が取り組んだ問題を起こ
している。オペレーティング・システムからアダプタ
へ、例えば、グラフィック・ディスプレイ・アダプタの
場合にデータを得るため、異なったアプリケーションが
異なったデータの必要性を持っている。どのようにデー
タが書かれ、アダプタに転送され、そしてアプリケーシ
ョン、装置ドライバおよびデータがどのように送られる
かにより異なっている。このデータを全てコピーし、ホ
スト・オペレーティング・システムから所望のアダプタ
・メモリにバスを通じて送られる（この機能は従来から
ＤＭＡにより行われている）。従って、異なった構造を
採用する異なった全ての装置はあるメカニズムを持たな
くてはならず、それにより、一度、最低レベルの装置ド
ライバにアクセスしており、ＤＭＡがセット・アップさ
れてアダプタに送られ、そしてアダプタがそのデータを
ＤＭＡすることができる。この機能はデータのポイン
タ、データの長さ、そしてクロス・メモリ記述子を要す
る。従って、本発明の利点を享受するためになぜ前述の
３つの要因、つまり、データのポインタ、このデータの
サイズ、そしてクロス・メモリ記述子が装置ドライバ構
造に存在しなくてはならないか理解できるだろう。

【００３９】図３には、複数プロトコル装置インターフ
ェース・サブシステムを提供する本発明のシステムのブ
ロック図が示されている。ソフトウェア・ハードウェア
分割線７５（図２の線５５と類似）より下にハードウェ
アがあり、ＳＣＳＩ装置、通信リンク、あるいは図１の
システムで操作する他のハードウェア等を有する。さら
に、分割線７５より上には種々の装置ドライバ、アプリ
ケーション、および図１のシステムで操作する後述のソ
フトウェアでインプリメンテーションを行う他のコード
・モジュールが示されている。

【００４０】図２と図３の比較は、複数プロトコル・ア
プリケーション、たとえば、媒体アプリケーション６４
および通信アプリケーション７２にたいする条項のよう
な従来システムといくつかの類似を示すことになる。別
の類似点も、ＳＣＳＩディスク装置ドライバ６６および
ＳＣＳＩテープ装置ドライバ６８、また図２のＳＣＳＩ
装置５１と類似のＳＣＳＩ装置８０のようなハードウェ
ア装置にたいする図３の条項内にある。一般的なハード
ウェア・ブロック７８が、それから延長するＳＣＳＩ装
置８０および通信リンク８２を伴って分割線７５より下
に示されている。この延長は、ハードウェア・ブロック
７８がどのハードウェアにたいする一般的なアダプタで
あることを表しており、またＳＣＳＩ装置８０あるいは
通信リンク８２のような種々の装置に接続させることも
可能である。

【００４１】続いて、図３のシステムからは、媒体プロ
トコルと通信プロトコルのような複数のプロトコルをサ
ポートするために図１のシステムが採用しなくてはなら
ないアダプタを設けてあると想定される。しかし、本発
明によれば、図２の従来システムにない別の構成要素が
図３に設けられている。ＳＣＳＩプロトコル・ヘッド７
０は装置ドライバ６６、６８と媒体アプリケーション６
４間のインターフェースを行うように設けられている。
このインターフェースは、今までと同様に図２のインタ
ーフェース４２のＢＵＦ構造インターフェースである。
同様に、通信プロトコル・ヘッド７４は図２のインター
フェース５４に関係したＭＢＵＦインターフェースおよ
び通信アプリケーション５２を行うように設けられてい
る。ＳＣＳＩプロトコル・アダプタ・ヘッド７０および
通信プロトコル・アダプタ・ヘッド７４を使用して後述
する新しい構造（図３には示してない、制御要素ブロッ
ク）を構築する。

【００４２】アダプタ・ドライバ７６（例えば、ハード
ウェア・ブロック７８として示されたハードウェア・ア
ダプタに直接接続する装置ドライバ）は、前述の新規な
制御要素ブロック構造を実行するインターフェースを有
する。制御要素ブロック構造に含まれるのはバッファ記
述子（Ｐ＿ＢＵＦ＿ＬＩＳＴ）に対する一般的なポイン
タである。それは後述するバッファ・ポインタのリスト
に対するポインタである。このポインタは幾つかの方法
でインプリメンテーションできるが、望ましい実施例で
はＢＵＦ構造のチェーンあるいはＭＢＵＦ構造のチェー
ンに対するポインタである。ＢＵＦ構造（プロトコル・
ヘッド７０の場合）またＭＢＵＦ構造（プロトコル・ヘ
ッド７４の場合）に対するポインタをセットすることに
よりプロトコル・ヘッド７０、７４がこの制御要素ブロ
ックを作ることがキー・ポイントである。そうすること
により、データをコピーする必要がなく、上述したよう
に、データのコピーは媒体データや通信データを必要と
する高能力のインターフェースに逆効果となる。従っ
て、本発明のシステムのみがそのチェーンへのポインタ
をセットアップするために必要である。詳細は後述する
が、フラッグを用いるＢＵＦあるいはＭＢＵＦ構造に対
するポインタの２つの異なったタイプを区別するため
に、アダプタ・ドライバ７６に論理を与えてある。プロ
トコル・ヘッド７０あるいは７４によりセットされたフ
ラッグがポインタのタイプを示し、ＢＵＦあるいはＭＢ
ＵＦ構造に対するポインタであるかを識別する。

【００４３】前記のように、前記３つの主な特性が設け
られるかぎり、例えばデータのポイント、このデータの
サイズ、そしてＤＭＡ目的のクロス・メモリ記述子のた
めにポインタをもうける限り、本発明は複数の異なった
ポインタあるいは構造の採用を認めている。従って、こ
れらの特徴に合致するどの構造も、（あるインプリメン
テーション中に、アダプタ・ドライバ７６が関連のポイ
ンタのタイプを認識する限り）どのタイプのポインタで
あるかを示すフラッグを有するＰ＿ＢＵＦ＿ＬＩＳＴの
リスト・ポインタ内にある。本発明は特定のバッファ
記述子あるいはＭＢＵＦあるいはＢＵＦ構造のような構
造に限定されるものではない。

【００４４】より明白にするために、コンピュータ業界
の従来の技術用語によれば、バッファ記述子はデータ・
バッファを記述するために使用したＢＵＦおよびＭＢＵ
Ｆのような構造にたいする単なる一般的な名称である。
データそのものはページあるいは他の長さのバッファで
あり、バッファ記述子は単にこうしたデータ（前記のデ
ータ長、クロス・メモリ記述子、および必要におうじて
他の情報を含む）に対するポインタを含むものである。

【００４５】また、「クロス・メモリ記述子」という語
は公知の翻訳メカニズムに対する単に従来の名称である
が、さらに詳細な説明をおこなう。ＵＮＩＸベースのシ
ステムにおいて公知のように、２つの基本メモリ領域が
設けられている。すなわち、核メモリとユーザ・メモリ
であり、ユーザ・アプリケーションはユーザ・メモリを
用い、核アプリケーションはこの核メモリを用いる。ユ
ーザ・メモリに対しＤＭＡで例えばアダプタ・カードに
対しパス・データが望ましいなら、この例ではクロス・
メモリ生成を行う必要があり、たとえば、翻訳機構にこ
のユーザ・メモリが核メモリのように見えるように依頼
する。というのは、アドレス機構が核メモリとユーザメ
モリで異なっているので必要とされる。この方法では、
アダプタ・カードがフェッチを必要とすると、そのシス
テムがユーザ・メモリの正しいデータにアクセスするこ
とができる。クロス・メモリ記述子は単にデータがどこ
にあるか示すだけである。

【００４６】従って、核メモリがパスされると、このク
ロス・メモリ記述子は単にそれが核メモリであり、翻訳
は必要ないことを示す。一方、それがユーザ・メモリで
あるなら、クロス・メモリ記述子を用いることにより実
行される翻訳機構がこのメモリがユーザ・メモリ（ＤＭ
Ａ論理とサービスにより実行される）内にあることを示
す。クロス・メモリ記述子はＤＭＡがセット・アップさ
れるとパスされ、従ってユーザあるいは核メモリに直接
のＤＭＡに使用される。

【００４７】前述のように、図３のハードウェア７８
は、典型的なインプリメンテーションにおいて、ファイ
バ・チャンネルＦＣＳあるいはＨＩＰＰＩに採用された
もののような実アダプタ・カードを表している。このフ
ァイバ・チャンネルは通信リンク８２により示されたネ
ットワークとして表示され、マルチプル・スイッチ、直
接接続等の形を取ることができる。リンク８２のような
ネットワークを通じての接続は必要に応じてＳＣＳＩあ
るいは他の装置８０がある。リンク８２は、通信が行わ
れているなら、通信中の別のファイバ・チャンネル・ア
ダプタをも有することが可能な目的マシーンを示してい
る。

【００４８】制御要素ブロック（ＣＴＬ＿ＥＬＥＭ＿Ｂ
ＬＫ）および、それに含まれる構造（ＰＤ＿ＩＮＦＯ）
をＣＴＬ＿ＥＬＥＭ＿ＢＬＫおよびＰＤ＿ＩＮＦＯ構造
の定義を示した表１を参照にして詳細に説明する。

【００４９】表１の内容の説明を続けると、ＰＤ＿ＩＮ
ＦＯ構造はＰＤ＿ＩＮＦＯに含まれたバッファをリスト
化するＰ＿ＢＵＦ＿ＬＩＳＴポインタを有している。ま
た、ＰＤ＿ＩＮＦＯ構造は、Ｐ＿ＢＵＦ＿ＬＩＳＴが位
置決めするバッファのタイプを記述するセットを得るフ
ラッグを含んでいる。ＰＤ＿ＩＮＦＯのＢＵＦ＿ＴＹＰ
Ｅパラメータは、Ｐ＿ＢＵＦ＿ＬＩＳＴにより位置決め
されるバッファのタイプを定義する。表１で説明した構
造は、前述したＭＢＵＦおよびＢＵＦ構造のようなアプ
リケーションによりサポートさせなければならないバッ
ファのタイプを説明するさいの、一般的であり、かつイ
ンプリメンテーション特定であることが本発明の特徴で
ある。

【００５０】ここで説明した代表的なインプリメンテー
ションでは、装置ドライバ・サブシステム・インターフ
ェースは通信プロトコルと媒体プロトコルの両方をサポ
ートする複数プロトコルＳＣＢアダプタ用に設けられ
る。本発明はこのＳＣＢアーキテクチャに限定されない
が、理解を容易にするためにこれを簡単に説明する。こ
のサブシステム制御ブロック（ＳＣＢ）アーキテクチャ
は、装置に対するインターフェースの一般的アーキテク
チャを提供することにより、拡大するコンピュータ・シ
ステムのコストおよび制御の単純さを維持するという問
題に対応するため考案したものである。従って、ＣＴＬ
＿ＥＬＥＭ＿ＢＬＫおよびＰＤ＿ＩＮＦＯ構造のあるフ
ィールドはＳＣＢアーキテクチャで特に扱うＳＣＢ特定
（例えば、ＲＥＰＬＹ＿ＥＬＥＭ、ＲＥＰＬＹ＿ＥＬＥ
Ｍ＿ＬＥＮ、ＣＴＬ＿ＥＬＥＭ、ＰＤ＿ＣＴＬ＿ＩＮＦ
Ｏ）である。しかし、前記より、本発明はＳＣＢ特定で
ある必要はなく、これらのフィールドは本発明のインプ
リメンテーションに必要ではないことは容易に分かるで
あろう。すなわち、本発明はＳＣＢアーキテクチャに特
定したものではなく、ここに説明したインプリメンテー
ションにのみ特定され、他のアーキテクチャに対するア
プリケーションを有効とする。

【００５１】表１に関する前述の説明で、フラッグがバ
ッファのタイプ（例えば、ＢＵＦ、ＭＢＵＦ）を記述す
るセットであり、ある時間内に採用されることを述べ
た。これはデータを図３の上部レベルのドライバから下
部レベルのドライバを介して、１度以上のコピー（従来
技術のシステムでの場合）をすることなく底部のハード
ウェア７８に流すことが可能である。これにより、制御
要素ブロックはＢＵＦおよびＭＢＵＦのような既存の構
造を採用するように作る必要があることが明らかであ
る。この制御要素ブロックはドライバ６６、６８、７
０、７４等により作り、図３のアダプタ・ドライバ７６
に提供されなければならない。ドライバ７６はどちらの
タイプの構造がパスされてきたのか認識し、その構造に
よるデータを適切にハードウェア装置７８に転送する。
明らかに、前述のように、図３のシステムのハードウェ
ア７８は、本発明の長所を得るために複数のプロトコル
をサポートしなくてはならない。

【００５２】図４には本発明の一続きの操作が示されて
おり、第１ステップではプロトコル・ヘッド７０あるい
は７４が入力として、プロトコル・スタック（媒体スタ
ック６４あるいは通信スタック７２等）、データに対す
るポインタ、データ長、クロス・メモリ記述子の３要素
を有する構造（代表的なＢＵＦあるいはＭＢＵＦ等）か
らパスされる。

【００５３】次のステップとして、ＣＴＬ＿ＥＬＥＭ＿
ＢＬＫが表１に示されたように作られる。このブロック
は前にパスした構造（例えば、ここで説明した特定のイ
ンプリメンテーションの場合にはＢＵＦあるいはＭＢＵ
Ｆ）に対するポインタを含む。このポインタは表１のＰ
＿ＢＵＥ＿ＬＩＳＴポインタとして認識される。

【００５４】一度、この制御要素ブロックが作られる
と、制御要素ブロックのデータを使いその構造が作ら
れ、その後、必要に応じてデータをアクセスし、ハード
ウェア・アダプタ７８にそれをコピーする。

【００５５】前記のように、従来技術のシステムに存在
しない本発明による独特のステップのインプリメンテー
ションが行われることが分かる。初めに、例えば、前記
の制御要素構造が作られる。さらに、データの再コピー
の必要性なく、装置データ・チェーンを通じてデータを
ハードウェアに伝えるために、２つの異なった予め存在
する構造を組合せ、それを同じ共通の制御要素構造内で
利用させる。つまり、単一のアダプタ・ドライバ用に機
能を設け、そのドライバは複数のプロトコル・タイプか
らの情報を扱う。データを記述するための制御要素ブロ
ックをカードに転送し、その制御要素構造内のデータ・
ポインタは、データがどのようにフォーマットされてい
るのか記述するようにフラッグを単にセットできるとい
う意味で、一般的である。

【００５６】従来技術のシステムにおいてシステムの各
ハードウェア装置は１つの構造のみと通信し、それのみ
を認識するということであった。しかし、本発明によれ
ば、途中データが一般的方法でＣＴＬ＿ＥＬＥＭ＿ＢＬ
Ｋ内に書き込まれるので、ＣＴＬ＿ＥＬＥＭ＿ＢＬＫ構
造を採用することにより同じ装置ドライバに複数個の異
なった構造を送ることが容易になる。ＣＴＬ＿ＥＬＥＭ
＿ＢＬＫは、真にデータ・ポインタであるか、あるいは
装置ドライバに送るべきいくつかの異なった構造の一つ
にたいするポインタなのか識別する。従って、このポイ
ンタは特定の定義を持たず、どちらかと言えば真に一般
的であり、あるタイプのポインタは前述のプロトコル・
ヘッドによりセットしたフラッグにより定義される。従
って、アダプタ・ドライバ７６は、インプリメンテーシ
ョンを行う必要がある際に送るべき異なった構造に対応
する多くの異なったフラッグとして認識可能である。

【００５７】ＰＤ＿ＩＮＦＯＳに関して、前述したよう
に集合位置を記述するために、これらは互いにチェーン
化させる。プロトコル・チェーンに送る必要があるデー
タの１単位は、必要あればメモリの異なったエリアに分
割することができる。そこでは、各ＰＤ＿ＩＮＦＯＳが
互いにリンクした異なったメモリ位置を含んでいる。つ
まり、ＣＴＬ＿ＥＬＥＭ＿ＢＬＫ構造は複数のＰＤ＿Ｉ
ＮＦＯＳを提供可能で、異なったバッファ・タイプの各
々は関連の異なった位置を有する。従って、はじめのＰ
Ｄ＿ＩＮＦＯ内のバッファ・タイプはＡタイプとするこ
とが可能で（つまり、Ｐ＿ＢＵＦ＿ＬＩＳＴはこの構造
Ａを位置決めできる）、一方、このチェーンの次のＰＤ
＿ＩＮＦＯは同様な方法で、異なった構造Ｂを位置決め
可能である。

【００５８】本発明の柔軟性を設ける際、データの各ユ
ニットは複数の位置として分散させ、一方をＢＵＦ構造
および他方をＭＢＵＦ構造とすることができる。さら
に、１ユニットを作るデータの各部品は異なったタイプ
とし、細分化が進んだ複数の構造をサポートすることが
可能である。表記法が同じ制御要素ブロックでの異なっ
たタイプのバッファのチェーンをパスすることなので、
本発明は特別なタイプあるいはグループのバッファをパ
スすることに限定されるものではない。

【００５９】図４には、表１に関して説明した種々のイ
ンターフェース構造に図３の構成要素を相互関連づける
混成した説明を示してある。ソフトウェア／ハードウェ
ア境界線７５が図示されており、線より上は前述した媒
体データおよび通信データに関連したプロトコル・スタ
ックが示されている。

【００６０】さらに詳細には、ＳＣＳＩディスク・ドラ
イバ６６およびＳＣＳＩテープ・ドライバ６８が示され
ており、それらは従来の方法でＳＣＢＵＦ構造のインタ
ーフェース１００を採用するＳＣＳＩアダプタ４８を介
してＳＣＳＩハードウェア８０にインターフェースを行
う。図３の場合のように、前述の媒体アプリケーション
用のＳＣＳＩプロトコル・ヘッド７０および通信アプリ
ケーション用の通信プロトコル・ヘッド７４が示されて
いる。媒体アプリケーションおよび通信アプリケーショ
ンの各々はそれぞれ対応のデータ構造、つまり、ＢＵＦ
構造（媒体の場合）およびＭＢＵＦ構造（通信の場合）
に組み合わされている。媒体ＳＣＳＩドライバ６６、６
８の共通インターフェースがＢＵＦ構造インターフェー
ス９８として示されており、そのインターフェースはＳ
ＣＢＵＦ構造インターフェース１０２を介してＳＣＳＩ
媒体プロトコル・ヘッド７０にインターフェースを行
う。同様に、通信プロトコル・ヘッド７４がＭＢＵＦ構
造インターフェース１０４と組み合わされている。

【００６１】本発明の特徴を思い起こすと、種々のプロ
トコル・ヘッド（図４に示した通信ヘッドあるいは媒体
ヘッドのような）がＢＵＦ構造あるいはＭＢＵＦ構造の
ような異なった構造のチェーンにポインタを書きいれる
ことができる共通のＣＴＬ＿ＥＬＥＭ＿ＢＬＫ構造を設
けることである。従って、プロトコル・ヘッド７０、７
４が書きいれることになるこの共通の構造を設けるよう
に、このＣＴＬ＿ＥＬＥＭ＿ＢＬＫ構造のインターフェ
ース１０６（詳細は表１）が図４に示されている。そし
て、この共通のＣＴＬ＿ＥＬＥＭ＿ＢＬＫ構造は前述の
方法により、ＦＣＳアダプタ・ドライバ９０のような種
々のハードウェア・ドライバ、およびＳＣＢアダプタ・
ドライバ９２のような他のアダプタ・ドライバに採用さ
れ、それぞれのハードウェア（同様な例として図４に示
された対応のＦＣＳハードウェア９４および他のＳＣＢ
ハードウェア９６）を駆動する。

【００６２】制御要素ブロックはパラメータ記述子情報
のチェーン化したリストを有し、ＭＢＵＦおよびＢＵＦ
構造のような構造の前述のチェーン化したリストに対応
することを述べた。このシステムは１パケットのデータ
を転送することを要求されていると考えられる。また、
このデータはメモリの異なったエリアに分散されている
と考えられる。このＰＤ＿ＩＮＦＯの各々はこのエリア
の１つを表示するために採用され、これにより全てのＰ
Ｄ＿ＩＮＦＯはひとまとめにして、どのシステムが転送
の要求を出しているかというデータのユニットあるいは
パケットを定義する。ＢＵＦおよびＭＢＵＦ構造の定義
は従来技術で公知であり、ＢＵＦ．ＨファイルおよびＭ
ＢＵＦ．Ｈファイルに含まれる従来の形でＵＮＩＸシス
テム内で提供される。従って、ここでは詳細な説明は省
略する。

【００６３】ここで説明したアプリケーションはＤＭＡ
をインプリメンテーションする実施例に関連したもので
あるが、本発明はそれに限定されるものではない。当業
界で公知のように、バスを通じてアダプタにデータを転
送する別の従来の方法はプログラムしたＩＯ（ＰＩＯ）
による、これは単にチャンネルを通じてデータをコピー
する異なった方法であり、ＣＰＵをバイパスしメモリか
らデータを直接得る装置に代わりバスを通じてコピーす
ることをＣＰＵが制御する。本発明はＤＭＡ環境と同様
にこのＰＩＯでも操作するので、ＤＭＡ環境に限定され
るものではないことは明らかである。（ＰＩＯインプリ
メンテーションにおいては差があり、前記クロス・メモ
リ記述子は不要である。）

【００６４】

【００６５】

【００６６】

【発明の効果】積層アーキテクチャの利点が得られると
同時に、現在のインターフェースを利用できるという柔
軟性も合わせ持つ。従って、単一のアダプタ・ドライバ
を通じて処理する複数のプロトコルに対する使い易さを
実現でき、その単一アダプタではそのインターフェース
をサポートする異なったアダプタで同じプロトコル・ヘ
ッド・コードが処理できる。

【図面の簡単な説明】

【図１】本発明の装置ドライバ・サブシステムに関連し
て操作するコンピュータ・システムを示す説明図であ
る。

【図２】従来技術の装置ドライバ・インターフェース・
サブシステムのブロック図である。

【図３】本発明の装置ドライバ・インターフェース・サ
ブシステムのブロック図である。

【図４】本発明の装置インターフェース・サブシステム
の別のブロック図である。

【符号の説明】

１０ＣＰＵ１２バス１４ＲＡＭ１６ＲＯＭ１８Ｉ／Ｏアダプタ２０外部装置２２ユーザ側インターフェース・アダプタ２４キーボード２６マウス２８スピーカ３２ジョイ・スティク３４通信アダプタ３６ディスプレイ・アダプタ３８ディスプレイ

───────────────────────────────────────────────────── フロントページの続き (72)発明者デビッド・ウィリアム・シェフィールドアメリカ合衆国78728 テキサス州、オースチン、クリスタル・ショア・ドライブ 2010 (56)参考文献特開平５−159078（ＪＰ，Ａ) 特開平５−308396（ＪＰ，Ａ) 特開昭56−24626（ＪＰ，Ａ) 特開平６−187259（ＪＰ，Ａ) 特開平４−336729（ＪＰ，Ａ) 特表平５−505266（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 13/10 - 13/14 G06F 13/00 H04L 29/10

Claims

(57)【特許請求の範囲】

【請求項１】複数の異なったインターフェースを有する
複数プロトコルのコンピュータ・システム環境におい
て、複数の異なったプロトコル・スタックからの２つ以上の
異なった構造を対応する複数の異なったプロトコル・ヘ
ッドにパスするステップと、前記２つ以上の異なった構造に対するポインタを含む前
記複数の異なったプロトコル・ヘッドで共通のインター
フェース構造を生成するステップと、前記共通のインターフェース構造を前記複数の異なった
インターフェースを介して前記コンピュータ・システム
環境内のアダプタ・ハードウェアにパスするステップと
を含み、前記２つ以上の異なった構造の各々が、バッファ・アド
レスに対するポインタと、バッファ長に対するポインタ
と、クロス・メモリ記述子を有することを特徴とするア
ダプタ・ハードウェアへのインターフェース方法。
【請求項２】前記共通のインターフェース構造が、制御
要素ブロックであることを特徴とする請求項１に記載の
方法。
【請求項３】前記共通のインターフェース構造を前記ア
ダプタ・ハードウェアにパスする前記ステップに応じて
前記アダプタ・ハードウェアを作動させるステップをさ
らに含むことを特徴とする請求項２に記載の方法。
【請求項４】前記複数の異なったインターフェースが、
第１インターフェースおよび第２インターフェースを有
し、前記２つ以上の異なった構造が、前記第１インター
フェース用の構造と前記第２インターフェース用の構造
を有することを特徴とする請求項１に記載の方法。
【請求項５】前記第１インターフェースが、前記アダプ
タ・ハードウェアを有する通信装置に対するものである
ことを特徴とする請求項４に記載の方法。
【請求項６】前記第２インターフェースが、前記アダプ
タ・ハードウェアを有する媒体装置に対するものである
ことを特徴とする請求項４に記載の方法。
【請求項７】前記２つ以上の異なった構造が、ＢＵＦ構
造とＭＢＵＦ構造を有することを特徴とする請求項１に
記載の方法。
【請求項８】複数の制御要素を生成するステップと、前記複数の制御要素の各々ごとに、対応する複数のユー
ザ・バッファを記述するための複数のバッファ・パラメ
ータ記述子を生成するステップと、をさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】前記複数のバッファ・パラメータ記述子
が、複数のパラメータ記述子情報構造のチェーンを有す
ることを特徴とする請求項８に記載の方法。
【請求項１０】前記複数のパラメータ記述子情報構造の
各々が、前記２つ以上の異なった構造に対するポインタ
を有することを特徴とする請求項９に記載の方法。
【請求項１１】前記複数の異なったプロトコル・スタッ
クが、媒体スタックおよび通信スタックを有することを
特徴とする請求項１に記載の方法。