JPS6364133A - 情報処理システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は情報処理システムのプログラミング・インタフ
ェースに係り、特にプログラミング・インタフェース上
で複数の機能を取扱うためのドライバ機構に係る。

Ｂ、従来技術 パーソナル・コンピュータに代表される小型処理の分野
では、一般にパーソナル・コンピュータに複数のアダプ
タ・カードを接続することによって、非同期通信や音声
・電話通信と云った機能を提供している。ホストのパー
ソナル・コンピュータは普通、一部のソフトウェアをＲ
Ａ　Ｍに持っており、それによりアプリケーション・プ
ログラム（以下、単にアプリケーションと云う）と所与
のアダプタ・カードとの通信を可能にしている。例えば
、ホスト・システムに音声アダプタ・カードが接続され
ていると、アプリケーションがこの音声アダプタ・カー
ドと通信できるようにするための音声ソフトウェア・サ
ブシステムがＲＡＭに格納されることになろう、ホスト
中の各ソフトウェア・サブシステムに関連してドライバ
機構が設けられ、これによりアプリケーションはソフト
ウェア・サブシステムとインタフェースできる。

上記のようなパーソナル・コンピュータにおいては、ア
プリケーションはアプリケーション・プログラミング・
インタフェース（以下、ＡＰＩと略称）を介してホスト
のソフトウェアとインタフェースする。具体的に云うと
、アプリケーションはＡＰＩを介してソフトウェア・ド
ライバ機構とインタフェースし、これが特定のアダプタ
・カードに対するソフトウェア・サブシステムとインタ
フェースする。ソフトウェア・サブシステムは謂ゆるハ
ードウェア・インタフェースを介してアダプタ・カード
と対話する。所与のアダプタ・カードをホストで機能さ
せるためには、ＡＰＩによる支援が必要である。ホスト
にロードされた各サブシステムは、ＡＰＩによって支援
される幾つかの機能を提供する。これらは複数の機能セ
ットに分けられる。まず、関連するアダプタ・カードの
ハードウェア資源を管理する基本機能セットがある。

この他に、各アダプタ・カードに対するオプションとし
て多数の任意機能セットがある。しかし、任意機能セッ
トのうちの幾つかのサブセットは、特定のソフトウェア
・サブシステムによって支援されるアダプタ・カード・
ファミリに属するアダプタ・カード上に装備されること
がある。

米国特許第４２６３６５０号明細書は、共通の両方向デ
ータ・バスに結合された複数の周辺インタフェース・ア
ダプタを有するディジタル・データ処理システムを開示
している。データ・バスはそれに接続されたマイクロプ
ロセッサにより制御される。マイクロプロセッサはＲＯ
Ｍ及びＲＡＭとインタフェースする。インタフェース・
アダプタは、周辺装置がデータ・バスと、従ってマイク
ロプロセッサ及び種々の記憶装置と通信できるようにす
る。各インタフェース・アダプタは、プログラム制御の
もとにロードされる制御レジスタを含み、その内容によ
りインタフェース・アダプタ内の諸レジスタの選択を制
御する。インタフェース・アダプタの他の機能（例えば
、インタフェース・アダプタの周辺バッファにおけるデ
ータ移動方向を決定すること）も制御レジスタにより制
御される。マイクロプロセッサは、各インタフェース・
アダプタの制御レジスタの内容を監視する。

米国特許第４１７４５３６号明細書は、マイクロプロセ
ッサを用いて、装置間通信のためのメツセージ経路指定
を可能にするディジタル通信制御装置を開示している。

アドレス・バス及びデータ・バスに接続された複数の直
列インタフェースがマイクロプロセッサと複数のポート
との間の通信を可能にする。

米国特許第４２５０５６３号明細書及び同第４２５４４
７３号明細書は、複数のＩ１０インタフェース・ラック
が両方向通信チャネルを介して中央処理手段に接続され
るようなプログラマブル・コントローラを開示している
。Ｉ１０インタフェース・ラックは、ラック・アダプタ
上の直列Ｉ１０データ・ボートに接続された両方向直列
通信ケーブルによって相互接続される。中央処理装置が
インタフェース・アダプタを介してＩ１０インタフェー
ス・ラックの分散網を制御する。様々な数及び大きさの
Ｉ１０インタフェース・ラックを組合わせて通信チャネ
ルを構成することができる。

Ｃ０発明が解決しようとする問題点 問題は、２以上のアダプタ・カードがホストに設置され
ていると、複数のドライバ機構が必要になると云うこと
である。即ち、常駐アダプタ・カードと通信する各ソフ
トウェア・サブシステムとインタフェースするためには
別々のドライバが必要である。共通のＡＰＩを有する複
数のサブシステムを、所与のアダプタ・カード・ファミ
リに属する複数の異なったアダプタ・カード上で実施で
きるようなドライバ機構はない。

従って、本発明の目的は、情報処理システムにおいてプ
ログラミング・インタフェース上で複数の機構を取扱う
ための制御機構を提供することにある。

Ｄ０問題点を解決するための手段 本発明に従えば、ソフトウェアで実現され、ホスト計算
機にロードされるドライバ機構が、単一のＡＰＩのもと
で、ホスト計算機の複数のアダプタ・カードを支援する
。このドライバ機構は、共通のＡＰＩのもとで動くホス
トの複数のソフトウエア・サブシステムが、特定のアダ
プタ・カード・ファミリに厘する複数の異なったアダプ
タ・カード上で実施されるようにする。

ＡＰＩによって支援される各アダプタ・カードは、工／
○アドレスと、ホストに接続されたカードのタイプ、ハ
ードウェア割込みレベル、及びホストのＲＡＭにおける
任意の既存カード・アドレスを決めるＩ１０機構とを有
する。ホストもＲＡＭに幾つかのファイルを有する。工
１０アドレス・ファイルは、ＡＰＩを支援するホストに
接続された各カードのＩ１０アドレスを含む、このファ
イルはまた、カード・タイプと、ＡＰＩにおける対応す
るディレクトリ・ファイルの名前とを含む。

ＡＰＩディレクトリ・ファイルは、ホストに取付けられ
た各カード・タイプ毎に１つ設けられる。

このファイル中には、アダプタ・カードによって支援さ
れる各機能セット毎に１つのレコードがある。このレコ
ードは、所与の機能セットのためのプログラミング支援
をなすファイルの名前を含む。

各機能セット・ファイルは、特定の機能セットのために
ＡＰＩのよって定義された機能を実施する目的コード・
プログラムである。これらの機能セット・ファイルは、
関連する機能セットについて定義された割込みを発生す
る。

ホスト・システムのＩＰＬ時には、ドライバ機構は３つ
の機能を遂行する。第１に、ドライバ機構は、Ｉ１０ア
ドレス・ファイルをＲＡＭにロードして、アダプタ・カ
ードの存在及びタイプに関して各工／○アドレスを検査
する。第２に、ドライバ機構は、ＩＰＬ時にロードすべ
きことを示しているアダプタ・カードのタイプ毎に基本
機能セットをロードする。第３に、ドライバ機構は、ロ
ードされた各基本機能セットをその初期エントリ点のと
ころから呼出す。

ドライバ機構によって遂行されるキーとなる２つの機能
がある。即ち、初期設定機能及びオーブン機能である。

特定のアダプタ・カードの基本機能セットに対するエン
トリ点ベクトルの最初のエントリが初期設定エントリ点
である。このエントリ点はアプリケーションからはアク
セスできず、ドライバ機能によって呼出せるだけである
。特定のハードウェア実施に対するＡＰＩディレクトリ
のアドレスは、引数として初期設定機能に移され、初期
設定機能は成功又は失敗を示すコードを戻す。

初期設定機能は２つのタスクを実行する。第１に、要求
されたハードウェア、即ちアダプタ・カードのハードウ
ェアを初期設定して、その受諾可能性をテストする。第
２に、要求に応じてロード可能な幾つかの機能セットを
ロードし且つ同時実行を行わせるために、アダプタ・カ
ードに対するソフトウェア制御ブロック構造を初期設定
する。

オーブン機能は、識別子をオーブン機能に与えることに
よってアプリケーションが要求されたハードウェア資源
にアクセスできるようにする。アダプタ・カードのハー
ドウェア資源は、複数のアプリケーションによって同時
にアクセスすることができる。

Ｅ、実施例 本発明で用いる情報処理システムの構成を第１図に示す
、アプリケーション１３はＡＰ　Ｉ　ｌ　１を介してホ
スト２０の種々のソフトウェア・モジュールと対話する
１本実施例では、ドライバ１４及びサブシステム１５〜
１７がソフトウェア・モジュールとして含まれている。

サブシステム１５〜１７の各々は、インプリメンテーシ
ョン・コード２８及び割込み経路指定部２９を含む、ホ
スト２０とアダプタ・カード１８．１９及び２１との間
の境界がハードウェア・インタフェース１２である。こ
のインタフェース１２はアダプタのタイプに応じて変え
ることができる。第１図には３つのアダプタ・カードが
示されているが、インタフェース１２を介してホスト２
０と対話できるアダプタ・カードの数は、ホスト２０に
おけるアダプタ・スロットの数によって決まる。サブシ
ステム１５及びアダプタ・カード１８を例にとると、ア
プリケーション・コマンドはパス２３を通ってアダプタ
・カード１８に行き、割込みはアダプタ・カード１８中
の命令メモリ・セクション（後述）で発生して、パス２
２を通ってサブシステム１５に行く、同様にサブシステ
ム１６及びアダプタ・カード１９の場合は、コマンド及
び割込みはパス２４及び２５を通り、サブシステム１７
及びアダプタ・カード２１の場合は、パス２６及び２７
を通る。

ＡＰＩＩＩは、特定のアダプタ・カード・セットで実施
される特定の機能クラスを提供する６例えば、音声通信
用のＡＰＩは種々の音声アダプタ・カードを支援し、非
同期通信用のＡＰＩは種々の通信アダプタ・カードを支
援する。一般に、所与のアダプタ・カードによりＡＰＩ
上で支援される機能は、第２図及び第３図に示すように
、幾つかの機能セットに分けられる。基本機能セットは
、特定のアダプタ・カードによって提供される論理資源
を管理する。他の多数の機能セットも所与のアダプタ・
カードにより提供される。その場合、それらの機能セッ
トのうちの成るサブセットを、所与のサブシステム（例
えば１５）によって支援されるアダプタ・カード・ノア
ミリ中のアダプタ・カード（例えば１８）上で実施でき
るようにされる。所与のアダプタ・カード上でのハード
ウェアによるサブセットの実施を可能にすると共に、如
何なる時にも必要な機能だけがメモリに格納されるよう
にするため、ＡＰＩＩＩはこのような機能セットに分割
される。かくして、使用されない機能のためにメモリ空
間が浪費されることはない。

ホスト２ｏにおけるファイル構造を第２図に示す、この
ファイル構造は一般にホスト２０のディスクで見られる
ものであり、工／○アドレス・ファイル３１、複数のデ
ィレクトリ４１．４３及び複数の基本機能セット・モジ
ュール４２．４４を含む、ディレクトリ４１．４３及び
モジュール４２．４４は各サブシステム１５．１６に含
まれる。

Ｉ１０アドレス・ファイル３１は４つの情報列を有する
１列３４は、特定のアプリケーションによって要求され
るアダプタ・カードを識別する０列３５は、アプリケー
ションによって要求されるアダプタ・カードのタイプ（
音声アダプタ・カード、非同期通信カード等）を示す０
列３６は、要求されたアダプタのためのディレクトリ、
即ち、当該アダプタのために要求されるソフトウェア・
サポートを指し示す０例えば、ブロック３８はサブシス
テム１５のディレクトリ４１を指し示す、同様に、ブロ
ック３９はサブシステム１６のディレクトリ４３を指し
示す。最後の列３７は、初期プログラム・ロード（ＩＰ
Ｌ）時又は所与のアプリケーションによるサブシステム
の最初の使用時に、当該サブシステムを初期設定すべき
かどうかを示す。ディレクトリ４１．４３は、当該サブ
システムにおける機能セット毎に１つのエントリを含む
。

ディレクトリ４１．４３におけるすべての機能セットは
、関連するサブシステムのための基本機能セットを支援
しなければならない、基本機能セット・モジュール４２
．４４は、所与のアダプタ・カード・ファミリのための
基本機能セットが何を含んでいるかを記述する。

ＡＰＩＩＩは、一意的な識別子（Ｉ１０アドレス）によ
って各アダプタ・カードを識別する。アプリケーション
１３は、この識別子を基本機能セットのオープン機能に
与えることにより、Ｉ１０アドレス・ファイル３１内で
特定のアダプタ・カードにアクセスする。各アダプタ・
カードは、成る所定数のアプリケーションが当該アダプ
タ・カード上のハードウェアを同時にアクセスすること
を許してもよい、ハードウェアによるオープン機能の実
施においては、複数のベクトルの間接アドレスが第３図
に示したオープン・パラメータ構造ブロック５１に格納
される。最初のベクトルは、アダプタの基本機能へのエ
ントリ点のベクトルであり、そのアドレスは［基本ＩＤ
Ｊと呼ばれる。

その他のベクトルは、アダプタによって同時に支援され
る他の機能セットに対応し、それらのアドレスは「結合
ＩＤＪと呼ばれる。

第３図はアダプタ・カードのための制御構造で、ドライ
バ１４とサブシステム（例えば１５）の関係を示してい
る。この制御構造はホスト２０中に位置している。アプ
リケーションはブロック５１に含まれる基本ＩＤ及び結
合ＩＤを用いて、オープンされた特定のサブシステムの
ためにどの機能セットをロードして使用すべきかを指示
する。ブロック５２は、アプリケーションによって要求
された活動機能セットを指し示す複数のベクトル５５．
５６を含む。例えば、ベクトル５５は機能セットＮ　（
５４）を指し示し、ベクトル５６は機能セットＭ（５３
）を指し示す。また、機能セット５３は自身が提供する
機能を指し示す複数のベクトル（例えば５７）を含む、
第３図の例では、ベクトル５７はブロック５９内に位置
する機能セットＭの機能Ａを指し示す０機能セット５４
も同様である。

機能セットにおける各ソフトウェア手段、即ちサブシス
テム１５．１６及び１７は、ドライバ１４とインタフェ
ースすることに関して幾つかの制約を受ける。ドライバ
１４とインタフェースする際にサブシステム１５〜１７
が従わなければならない段切の制約は、機能セット・ロ
ード・モジュールにより定義される。ロード・モジュー
ルはホスト２ｏにある独立したコード・セットであって
、アプリケーション１３からの要求に応じて基本機能セ
ット（例えば４２）によりロードされる。各機能セット
は、独立したロード・モジュールとして具体化される。

各ロード・モジュールは、当該機能セットにおける機能
（例えばブロック５９のところに示した機能セットＭの
機能Ａ）を支援するためのコードを含む。ロード・モジ
ュールは、各機能セットで設定された機能定義に従って
任意のアダプタ・カード１８．１９．２１上のハードウ
ェアを駆動するためのコードも含む、各ロード・モジュ
ールの先頭部には、関連する機能セット中の機能に対応
するエントリ点アドレスのベクトル（例えば５７）があ
る、これらのベクトルは、ＡＰＩ機能コードの定義に従
って並べられる。ドライバ１４は、すべてのハードウェ
ア・アダプタ・カードについてベクトル中の任意のエン
トリを呼出すことができる。

基本機能セット・モジュール４２．４４のためのエント
リ点ベクトルにおける最初のエントリは、第２図に示す
ように、初期設定エントリである。

このエントリ点はアプリケーション１３からはアクセス
できず、ドライバ１４によって呼出せるだけである。成
るアダプタ・カードについて要求されたディレクトリの
アドレスが引数として機能の方へ転送され、機能は成功
又は失敗を示すコードをＡＰＩＩＩへ戻す、初期設定機
能は２つのタスクを実行する。まず、アダプタ・カード
上のハードウェアを初期設定してその受諾可能性をテス
トする。次に、アプリケーション１３によって実行を要
求された機能セットをロードして同時実行を行わせるた
め、ソフトウェア制御ブロック構造を初期設定する。こ
れらの機能セットはこの時ロードすることができる。

次に第４〜６図を参照しながら、ドライバ１４のオペレ
ーションについて説明する。第４図は、ホスト２０の電
源が投入されて、ＩＰＬが実行される時のドライバ１４
のオペレーションを示している。ステップ７１での最初
のオペレーションは、Ｉ１０アドレス・ファイル３１に
おける全エントリの読取りである。ステップ７２はファ
イル３１の終りに達したかどうかを判断し、もし達して
いると、即ち全エントリが読取られてしまうと、終了ス
テップ７３に進み、ＩＰＬオペレーションが終了する。

まだ終りに達していなければステップ７４に進んで、Ｉ
１０アドレス・ファイル３１から読取ったエントリをこ
のＩＰＬ時に初期設定すべきかどうかを調べる。初期設
定が不要であれば、ステップ７１に戻ってエントリの読
取りを続ける。

しかし、初期設定すべきであれば、ステップ７５に進ん
で、当該エントリについてサブシステム・ディレクトリ
を読取る。然る後、ステップ７６で基本機能をロードし
、ステップ７７でそれらを初期設定する。これらの基本
機能は、使用すべきアダプタ・カードに従ってＩ１０ア
ドレス・ファイル３１により識別された特定のサブシス
テム中にある。

第５図は、オープン機能実行時のドライバ１４のオペレ
ーションを示している。最初のステップ８１で、Ｉ１０
アドレス・ファイル３１のエントリを読取る１次にステ
ップ８２で、このエントリが有効かどうかを調べる。エ
ントリが無効であれば、何らかの誤りが生じたことを示
しており、この時点でエントリの処理を打°切る。エン
トリが有効であれば、ステップ８４に進んで、このエン
ドリが初期設定されているかどうかを調べる。既に初期
設定されていると、ホスト２０のメモリで基本機能をア
クセスしくステップ８６）、それに対してオープン機能
を遂行する（ステップ８７）。

しかし、読取ったエントリがまだ初期設定されていなけ
れば、ステップ８４から８５に進んで、ディレクトリ４
１又は４３を読取る。然る後、ステップ８８で基本機能
をロードし、ステップ８９でそれを初期設定してオープ
ンする。エントリをオープンしてしまうと、ステップ９
ｏに進んで、ベクトル・アドレスを個々の機能セット５
３．５４に戻す。

第６図は、所与の機能セット中の機能を呼出す時のドラ
イバ１４のオペレーションを示している。

例えば、記録・再生機能を持った音声通信アダプタ・カ
ードの場合、音声データを記録又は再生する時に第６図
のオペレーションが実行される。最初のステップ９１は
、機能セット・ベクトルのアドレスを見つける。第３図
の例で説明すると、機能セット５ｉ（５３）へのベクト
ルはブロック５６に含まれ、機能セットＮ　（５４）へ
のベクトルはブロック５５に含まれている。これらのブ
ロックは、ブロック５１中の対応する結合ＩＤによって
アクセスされる０次のステップ９２では、機能よりをベ
クトル（例えば第３図に示した機能セット５４のベクト
ル５８）へのインデックスとして使用する。続いてステ
ップ９４で、エントリ点アドレスをロードする。これに
より、要求された機能を呼出すための実際のコードが指
し示される。最後にステップ９４で、ドライバ１４はエ
ントリ点アドレスを呼出し、オペレーションに必要なエ
ントリ点パラメータを機能に与える。第３図の例で説明
すると、ドライバ１４によって呼出されるのが機能Ｂで
あった場合には、エントリ点パラメータはブロック６ｏ
中に機能Ｂに与えられる。これが終るとリターンが行わ
れ、次の機能呼出しを待つ。

第７図は、アダプタ・カード１８の概略を示したもので
ある。このアダプタ・カード１８は、ホスト・プロセッ
サ１８９に対するコプロセッサとして動く信号プロセッ
サ１８８を含んでいる。信号プロセッサ１８８は、テキ
サス・インストルメンツ社のＴＭＳ３２０１０の如き市
販の信号プロセッサでよい。信号プロセッサ１８８はホ
スト・プロセッサ１８９の完全な制御下にあり、オペレ
ーションに先立って自身のＣＰＵに命令をロードしなけ
ればならない。信号プロセッサ１８８は命令メモリ１２
１及びデータ・メモリ１８７を使用する。ホスト・プロ
セッサ１８９もこれらのメモリをアクセスできるが、信
号プロセッサ１８８と同時にはできない。命令メモリ１
２１は、信号プロセッサ１８８がターンオフ、即ちリセ
ットされている場合にのみ、ホスト・プロセッサ１８９
からのアクセスが可能である。その時ホスト・プロセッ
サ１８９は、命令メモリ１２１からロードした後、デー
タ・メモリ１８７に切換えることができる。データ・メ
モリ１８７は、常時、信号プロセッサ１８８及びホスト
・プロセッサ１８９により動的に共用される。プロセッ
サ１８８及び１８９はいずれもホスト・プロセッサ１８
９の制御のもとに互いに割込みをかけることができる。

この割込みはマスク可能である。

第８図は、アプリケーション１３とアダプタ・カード１
８との間でのコマンド及び割込みを流れを機能的に示し
たものである。アプリケーション１３は、ＡＰＩＩＩを
介してドライバ１４、インプリメンテーション・コード
２８及び々ハードウェア割込み経路指定部２９と対話す
る。１４．２８及び２９はいずれもホスト２０にある。

ホスト２０とアダプタ・カード１８の境界がハードウェ
ア・インタフェース１２である。アプリケーション・コ
マンドの最終目的地は命令メモリ１２１の区画１２４で
あり、一方、割込みは区画１２４から発生する０区画１
２４は信号プロセッサ制御プログラムを含んでいる。こ
の制御プログラムは、命令メモリ１２１の区画１１２．
１１３及び１１４を管理し、それらに含まれる信号処理
コードの同時実行を可能にする。これにより、アダプタ
・カード１８の資源が共用される。

【図面の簡単な説明】

第１図は本発明に従う情報処理システムのブロック図。 第２図はホストにおけるファイル構造のブロック図。 第３図は複数のアダプタ・カードでドライバを共用する
ためにホストで用いる制御構造のブロック図。 第４図乃至第６図はドライバのオペレーションを示す流
れ図。 第７図はアダプタ・カードの概略を示すブロック図。 第８図はアプリケーションとアダプタ・カードとの間で
のコマンド及び割込みの流れを示すブロック図。 ＦＩＧ、　　２

Claims (1)

1. 【特許請求の範囲】 複数のハードウェア資源及びソフトウェア・サブシステ
   ムと、 少なくとも１つのアプリケーション・プログラムと前記
   複数のハードウェア資源及びソフトウェア・サブシステ
   ムのうちの少なくとも２つとをインタフェースすること
   により同時に複数の処理機能を提供する手段と、 を具備することを特徴とする情報処理システム。