JP2016197446A - デバイスプロキシ装置及びそれを含む計算機システム - Google Patents

Abstract

【課題】ＯＳを駆動するＣＰＵの処理負担を軽減する。
【解決手段】プロセッサ間通信可能なマルチコアのマイクロプロセッサユニット（２１）と、デバイス設定情報を記述したファイルを記憶する記憶手段（２２）と、デバイスインターフェース（２３）とを備え、前記マイクロプロセッサユニットのスレッドを分離して第１のプロセッサコアでＯＳを駆動する一方、第２のプロセッサコアで前記デバイスインターフェースを制御するデバイスドライバを駆動し、前記デバイス設定情報を前記プロセッサ間通信により共有しつつ、前記デバイス設定情報に基づいて前記オペレーティングシステムのカーネルに前記設定情報を通知するための通知用ドライバインターフェースをロードして、前記通知用ドライバに前記シナリオ・シーケンス・ファイルを読み込むことにより、前記第２のプロセッサコアが前記デバイスインターフェースに接続されたデバイスを制御する。
【選択図】図４

Description

本発明は、オペレーティングシステム（ＯＳ）のカーネルに登録される任意のデバイスを中継するハードウェア（デバイスプロキシ装置）及びそれを含む計算機システムに関する。

パソコンやスマートフォンなどの計算機に周辺機器（以下、「デバイス」という。）を接続して使用するには計算機とデバイスとの物理的接続だけでなく、デバイスドライバによって計算機がデバイスを認識して双方で通信可能な状態にする、「論理的接続」が必要とされる。

デバイスドライバは、デバイスメーカー側でデバイスとＯＳの組合せ毎に専用プログラムとして作成されてデバイスと共にユーザ側に提供されることが一般的である。このような提供形態となる主な要因は、デバイスがそれぞれ固有の規格及び仕様に基づいて製造されているためであり、さらにいえば、デバイスドライバがデバイスだけでなくＯＳにも依存しているためである。

特開平１０−１１３８４号公報 特開２００４−７０９６４号公報

デバイスドライバは、デバイスごとに固有の規格や仕様に基づいて設計されるプログラムであり、端的に言えば、デバイスの構成（コンフィギュレーション）や設定に必要なパラメータ及び接続形式などの、ハードウェアに関する情報をカーネルに登録するためのプログラムである。すなわち、大部分がハードウェアに関する情報であり、ＯＳへの依存がほとんどない部分から構成されている。しかし、同時に、ＯＳとデバイスドライバとのインターフェース機能（これを本明細書では「ドライバインターフェース」という。）は、ＯＳのカーネルに組み込まれ、カーネルはＯＳ上で実行されている種々のプログラムとは別に、ドライバインターフェースを通じてコマンドやデータの通信や割り込み処理などを実行している。

そのため、デバイスドライバがカーネルに登録されると接続先のデバイスを制御するために計算機のリソースが奪われ、場合によってはＯＳの動作が不安定になることもある。

本発明は、上記に鑑みてなされたものであり、オペレーティングシステムを駆動するＣＰＵの処理負担を軽減することを主たる目的とする。

本発明に係る第１のデバイスプロキシ装置は、プロセッサ間通信が可能なマルチコアのマイクロプロセッサユニット（２１）と、デバイス設定情報が記述されたシナリオ・シーケンス・ファイルを記憶する記憶手段（２２）と、デバイスインターフェース（２３）と、を備え、
前記マイクロプロセッサユニットのスレッドが分離された状態で
第１のプロセッサコアにより第１のオペレーティングシステムが駆動される一方、
第２のプロセッサコアにより前記デバイスインターフェースを制御するためのデバイスドライバが駆動され、
前記デバイス設定情報が前記プロセッサ間通信により共有されつつ、
前記デバイス設定情報に基づいて前記第１のオペレーティングシステムのカーネルに前記設定情報を通知するための通知用ドライバインターフェースがロードされて、前記通知用ドライバに前記シナリオ・シーケンス・ファイルが読み込まれることにより、
前記第２のプロセッサコアにより前記デバイスインターフェースに接続されたデバイスが制御されることを特徴とする。

以上のように、マルチコアプロセッサの一つのマイクロプロセッサユニットを、デバイスを制御するための専用のプロセッサとして割り当てることで、デバイスの制御をＯＳ管理下の外に置くことが可能となり、オペレーティングシステムを駆動するＣＰＵの処理負担を軽減することができる。

本発明に係る第２のデバイスプロキシ装置は、第１のプロセッサ（２１）と、第２のプロセッサ（３１）と、デバイス設定情報を記述したシナリオ・シーケンス・ファイルを記憶する記憶手段（２２）と、デバイスインターフェース（２３）と、を備え、
第１のプロセッサにより第１のオペレーティングシステムが駆動される一方、
第２のプロセッサにより前記デバイスインターフェースを制御するためのデバイスドライバが駆動され、
前記デバイス設定情報がバス接続によりプロセッサ間で共有されつつ、
前記デバイス設定情報に基づいて前記オペレーティングシステムのカーネルに前記設定情報を通知するための通知用ドライバインターフェースがロードされて、前記通知用ドライバに前記シナリオ・シーケンス・ファイルが読み込まれることにより、
前記第２のプロセッサにより前記デバイスインターフェースに接続されたデバイスが制御されることを特徴とする。

本発明に係る第３のデバイスプロキシ装置は、第１のプロセッサ（２１）と、デバイス設定情報を記述したシナリオ・シーケンス・ファイルを記憶する記憶手段（２２）と、デバイスインターフェース（２３）とを備えた計算機に前記デバイスインターフェースを介して接続されるデバイスプロキシ装置であって、
前記デバイスプロキシ装置は、
第３のプロセッサ（６１）と、デバイスインターフェース（６３）とを具備し、
第３のプロセッサにより前記デバイスインターフェースを制御するためのデバイスドライバが駆動され、
前記デバイス設定情報が前記デバイスインターフェースを介して共有されつつ、
前記デバイス設定情報に基づいて前記第１のプロセッサが駆動するオペレーティングシステムのカーネルに前記設定情報を通知するための通知用ドライバインターフェースがロードされて、前記通知用ドライバに前記シナリオ・シーケンス・ファイルが読み込まれることにより、
前記第３のプロセッサにより前記デバイスインターフェースに接続されたデバイスが制御されることを特徴とする。

以上のような構成によれば、ＯＳ側からみるとデバイスが抽象化され、ＣＰＵの負荷を分散することにつながる。またデバイスプロキシ装置には一切情報が残らないことからデバイスがコンテンツを含む場合には耐タンパ性を高めることにもつながる。

本発明に係る第４のデバイスプロキシ装置は、計算機上で動作するオペレーティングシステムのカーネルとデバイスの間に介在して前記デバイスを代理するデバイスプロキシ装置であって、
前記デバイスプロキシ装置自身及びその先に接続される後段のデバイスを動作させるために必要なデバイスドライバとしての機能と、
前記オペレーティングシステムとの間で前記デバイスの動作に必要な情報をやりとりする通信機能とを備え、
前記オペレーティングシステムに依存しない形式で記述されたデバイス設定情報を前記オペレーティングシステム側で保持しつつ、
前記通信機能を介して前記オペレーティングシステム側から前記デバイス設定情報を受け取り、
前記デバイス設定情報に基づいて前記オペレーティングシステムのカーネルに登録された前記デバイス設定情報を通知するための通知用ドライバを介してデバイスドライバが前記オペレーティングシステムのカーネルに登録されることを特徴とする。

上記第４のデバイスプロキシ装置において、前記デバイス設定情報は、デバイスにのみ依存するパラメータ及びＯＳに依存しないコマンドのみを含み、処理の手順を示すシナリオ・シーケンス・ファイルで記述されるように構成してもよくまた、前記デバイス設定情報を受け取るタイミングは、下記１）〜３）のいずれかであってもよい。
１）前記デバイスプロキシ装置にデバイスが接続された際、
２）前記オペレーティングシステム上で動作するアプリケーションプログラムが要求する時間内
３）デバイス側から割り込みイベントその他の処理要求があった場合

そして、オペレーティングシステムを実行する計算機と、上記第４のデバイスプロキシ装置とが前記通信機能を介して接続された、例えば図７（ａ）又は図７（ｂ）に示すような、計算機システムを構成することができる。

本発明に係るデバイスプロキシ装置によると、オペレーティングシステムを駆動するＣＰＵの処理負担を軽減することができる。

デバイスドライバの基本構成を示す概念図である。 カーネル−デバイス間及びデバイス−デバイス間の物理的又は論理的な接続態様を示す図 デバイスドライバの登録方法を示すフローチャート （ａ）マルチコアプロセッサユニットを含む同一筐体の計算機の基本構成を示す概念図、（ｂ）プロセッサを２基含む同一筐体の計算機の基本構成を示す概念図 計算機にデバイスプロキシ装置を接続した全体構成を示す概念図 デバイスプロキシ装置が、ＯＳからみて、独立したハードウェアとして接続されている態様を説明する概念図である。 図７（ａ）及び図７（ｂ）は、いずれも計算機システムのハードウェア構成を示す概念図である。

以下、図面を参照して本発明の各実施形態について説明する。同一又は同類の部材には同一の符号を用いるか又は添字のみ異ならせて表示するものとし、重複した説明を省略しているが、各実施形態の記載は本発明の技術的思想を理解するために合目的的に解釈され、実施形態の記載に限定解釈されるべきものではない。

本明細書における「デバイスプロキシ装置」は、アプリケーションプログラムを動作させるプラットフォームとなる第１のオペレーティングシステム（通常はヒューマンインターフェースを備えたオペレーティングシステム（ＯＳ）、例えば、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）或いは各種スマートフォンなどの携帯情報端末に搭載されるオペレーティングシステムなどが該当する。）を駆動するＣＰＵからデバイスの制御に特化したＣＰＵを分離して、デバイスの制御に特化したハードウェアを構成したものである。ＯＳ側からみると、デバイスは抽象化され、「デバイスプロキシ装置」というハードウェアが接続されていることになり、デバイスからみると、デバイスはオペレーティングシステムのカーネルにではなく、物理的には「デバイスプロキシ装置」に接続され、論理的には、デバイスプロキシ装置との間でデータを送受信し、デバイスプロキシ装置がそれをオペレーティングシステムのカーネルに中継する。

デバイスプロキシ装置に求められる最低限の処理機能は、デバイスを動作させるために必要な最低限のデバイスドライバとしての機能と、ＯＳとの間でデバイスの動作に必要な情報をやりとりする通信機能である。そのため、デバイスプロキシ装置の動作を原始的な機械語により直接記述すればオペレーティングシステムを持つ必要もなく、処理能力の低い（例えば２０ＭＨｚの１６ビットマイコンのような）プロセッサでも動作可能である。

このように、オペレーティングシステムのカーネルとデバイスの間に介在し、デバイスを代理するという意味において、このハードウェアを「デバイスプロキシ装置」と名付ける。なお、後述する実施例において説明するように、デバイスプロキシ装置からさらに別のデバイスプロキシ装置に接続して「多段プロキシ装置」のように構成することもできる。デバイスプロキシ装置自体が一つの「デバイス」だからである。多段プロキシの場合には安価なマイコンを用いてデバイスプロキシ装置を構成することができる。

デバイスプロキシ装置を実現するための一つの実施態様として、マルチコアプロセッサユニットを利用するという方法がある。近年の汎用的なパーソナルコンピュータやサーバーはマルチコアプロセッサユニットを搭載していることが多い。このマルチコアプロセッサユニットの少なくとも一つのマイクロプロセッサユニットを、デバイスプロキシ装置を動作させるために割り当てることができる。具体的には、オペレーティングシステムの起動プロセスの初期の段階で、ブートローダーとよばれるプログラムを起動させ、その際にマルチコアプロセッサの役割を、ＯＳを動作させるためのプロセッサ（又はプロセッサ群）と、デバイスプロキシ装置を動作させるためのプロセッサ（又はプロセッサ群）とに別々に割り当てることができる。

既に述べたように、デバイスプロキシ装置の動作に必要なプロセッサに高い処理能力は必要ないため、シングルコアで十分である。しかしながら、マルチコアプロセッサの一つのマイクロプロセッサユニットを利用する場合、それよりもはるかに高い処理能力を持つため、環境構築の容易さから、実験段階では組み込みオペレーティングシステム（いわゆるリアルタイム・オペレーティングシステム）の一つを用いて行った。

デバイスプロキシ装置は、ＯＳとは独立して動作し、通常はＯＳのユーザーからその存在が意識されることはない。ただし、マルチコアのマイクロプロセッサユニットは通常、マルチコアのプロセッサ間で通信を行うプロセッサ間通信（ＩＰＣ）の仕組みがあるため、相互にデータをやりとりすることが可能である。ＣＰＵが物理的に分かれている場合はデバイスインターフェースを介して相互にデータをやりとりすることが可能である。

この仕組みを利用して、デバイスの動作に必要な設定情報を共有し、デバイスプロキシ装置やその先に接続されるデバイスの設定情報などを、ＯＳのカーネル側に送信したり、例えばヒューマンインターフェースを介して受け付けたデバイスに対する設定情報などを送信したり、することができる。

デバイスプロキシ装置を多段に接続するような場合、或いは、耐タンパ性を高めるといった目的から、接続するデバイスが機密情報を含む場合には、敢えてＯＳを搭載しないデバイスプロキシ装置を選択するのも一つの選択肢である。

以上のように、マルチコアプロセッサの一つのマイクロプロセッサユニットを、デバイスを制御するための専用のプロセッサとして割り当てることで、デバイスの制御をＯＳ管理下の外に置くことが可能となる。例えば、１Ｇｂｉｔ／ｓのイーサネット（登録商標）に接続されるネットワークカードデバイスは、１秒間に１０億回の割り込み処理信号をオペレーティングシステムのカーネルに送っているが、デバイスプロキシ装置を介して接続するとデバイスプロキシ装置がその動作をすべて処理するため、オペレーティングシステムを駆動するＣＰＵの処理負担を軽減することができる。

なお、マルチコアプロセッサは複数のスレッドを起動しているが、デュアルコアプロセッサにした場合に、シングルコアよりも動作速度が２倍になったとしても、クアッドコアプロセッサでは４倍以下となり、さらにコア数が増えても処理速度は比例して増加しない。このため、ＯＳからみてプロセッサが一つ程度減っても、その一つのタスクをデバイスの管理に特化させることで、ＯＳからみると「ギガビットワークカード」ではなく、「イーサネット（登録商標）経由でＴＣＰ／ＩＰプロトコルパケットを通信するための一つのデバイス」というようにデバイスが抽象化され、全体としてみるとＣＰＵの処理負担軽減につながる。

すでに述べたように、ＯＳ側からみると、デバイスプロキシ装置自体がデバイスであり、その一つ以上先に究極的な制御対象である本来のデバイスが接続されている。デバイスの制御は基本的に「デバイスドライバ」というプログラムによってデバイスの設定情報と接続経路などの情報をオペレーティングシステムのカーネルと通信するプログラムによって行うため、デバイスの設定情報の一部又は全部は、デバイスプロキシ装置にも通知されなければならない。これらの情報は、プロセッサ間通信やバス接続或いはデバイスインターフェースを介して互いに共有することができる。

次に、本発明のデバイスを動作させるためのプログラムである「デバイスドライバ」について説明する。ただし、下記の説明におけるデバイスの設定情報とは、デバイスプロキシ装置を介して接続される究極的な制御対象であるデバイスの設定情報を含むものとする。

（第１の実施形態）−デバイスドライバの基本構成−
図１は、デバイスドライバの基本構成を示す概念図である。デバイスドライバ１０は、ＯＳのカーネル１１とデバイス１２との間に位置するプログラムであり、基本構造は、
（ａ）ドライバインターフェース１０Ａ
（ｂ）デバイスドライバ本体１０Ｂ
（ｃ）デバイスインターフェース１０Ｃ
という３つの構造からなっている。

デバイスは実に数多くの種類が存在するが、どのようなデバイスであっても、基本的に、すべてのデバイスドライバがいずれも図１に示すような構造を有する。デバイス１２側からみて、ドライバインターフェース１０Ａよりも向こう側はユーザー権限で操作される領域（ユーザーエリア１３）、手前側は管理者権限で操作される領域（管理者エリア１４）である。

しかし、従来のデバイスドライバは、（ａ）〜（ｃ）のすべてが一つのプログラムとしてデバイスメーカー側で作成され、ユーザーに配布されていたが、本実施形態のデバイスドライバは、（ａ）の機能を実現するプログラムと、（ｂ）及び（ｃ）の動作に必要なデバイス設定情報を記述したファイルとに分離する構成を採用している。

（ａ）ドライバインターフェース
ドライバインターフェースはＯＳとデバイスドライバの境界に位置するインターフェースであり、基本的にはＯＳごとに異なるが、その機能はＯＳによらず同じである。ドライバインターフェースの主な機能（ファンクション）の例を以下に示す。
１．初期化（デバイスを初期化する）
２．オープン（デバイスをオープンする）
３．クローズ（デバイスをクローズする）
４．リード（デバイスからコマンドやデータを読み出す）
５．ライト（デバイスにコマンドやデータを書き込む）
６．Ｉ／Ｏコントロール（標準化されていないデバイスの制御）

デバイスとカーネルとのインターフェース機能は、デバイスハンドラ（以下「ハンドラ」という。）を用いて実現される。ハンドラとは、カーネルが管理するメモリ上に展開されるプログラムの一種である。普段は待機状態にあるが、通常のプログラムとは別に、特定の処理要求（イベントや割り込み）が発生したときに呼び出されるサブルーチンプログラムである。ドライバ設定情報をカーネルに登録する際には、このハンドラを用いてデバイスドライバの本体１０Ｂが保持している各種のデバイス設定情報をカーネルに通知する。

ドライバインターフェース１０Ａは、ＯＳに依存する部分であるが、基本的には、あるＯＳに対するデバイスドライバを実装する際に一度作成すれば、ＯＳ及びカーネルを動かすプロセッサが変わらない限り、以後変わることがない。これに対して、以下に説明するデバイスドライバ本体１０Ｂとデバイスインターフェース１０Ｃは、いずれもデバイスの構成に依存する部分であるため、デバイスやその接続方法（デバイスとのインターフェース）が同じであればＯＳに依らず、共通となる。デバイスドライバ１０の全体から見ると、ドライバインターフェース１０Ａはごくわずかな部分にすぎない。

（ｂ）デバイスインターフェース
デバイスインターフェースは、ＯＳのカーネル側からみたデバイスとのインターフェースであり、物理的インターフェースと論理的インターフェース（ロジカルパケットインターフェース）の２種類がある。デバイスインターフェースは、ハードウェアとの物理的な接続形式（結線上の問題）を扱う部分である。物理的インターフェースでは、登録されるデバイスのレジスタが、カーネルのメモリマップ上に展開される。それは主にメモリ共有と割り込み処理を扱う物理的なバス接続であり、デバイスの接続形式によって、例えば、メモリマップドレジスタ（ＰＣＩバス接続）、Ｉ２Ｃ（Inter-Integrated Circuit）バスインターフェースやＳＰＩ（Serial Peripheral Interface）バスインターフェースなどの通信型レジスタなどがある。

一方、論理的インターフェースでは、例えば文字列やバイナリストリームなどの、決められたプロトコルに従った一まとまりのデータ（プロトコルパケットデータ)によってデバイスの挙動を表現し制御するインターフェースである。単にデバイスインターフェースといった場合には、文脈により物理的インターフェースと論理的インターフェースのいずれか又は両方を表す。

また、デバイスインターフェースは、割り込み信号を送受信するための割り込みｌｉｎｅを有する。割り込み処理はデバイス側の状態変化を登録型のハンドラによって制御する役割を担う。例えば、デバイスがカメラモジュールである場合を例に取ると、「シャッターが押される」というイベントの処理は、割り込み処理で行っている。シャッターが押されると割り込みハンドラがカーネルから読み出され、その結果として、対応する関数（サブルーチン）が読み込まれる。

（ｃ）デバイスドライバ本体
本実施形態のデバイスドライバ本体１０Ｂは、主に以下の設定情報が記述されている。
１．デバイスの制御に関する設定情報
２．デバイスに設定する設定情報（デバイスに与えるパラメータ）

本明細書における「デバイス設定情報」とは、上記の１．（デバイスの制御に関する設定情報）と２．（デバイスに設定する設定情報）の両方を含む。また、設定情報にはデータだけでなくコマンドを含む。例えば、スクリプトで記述できるコマンド（インストラクション）例えば割り込み待ち、レジスタへの代入、ＤＭＡ転送の指示、Ｉ２Ｃ／ＳＰＩバスを経由した通信、メモリマップドレジスタへの書き込みや読み出しなどを含む。

デバイスの制御とは、デバイスの本質的な動作に関わる制御であり管理者権限で実行される制御、例えばデバイスのリセット、設定変更などを含む。一方、デバイスに設定するパラメータとは、ユーザー権限で設定されるデバイスの使用目的や使用状況等に応じた制御を行うためのパラメータをいう。例えば、同じ接続形式で同じプリンタでもプリンタの用紙を変更する、カメラのモード（センサとレンズは同じでもシーンによってパノラマ・動画・静止画モードを切り替える、など。）を設定するといった、デバイスから見ると（特別な場合を除いて）電気的には全く検知できないようなデバイスの設定情報を含む。デバイスドライバ本体は本来的にデバイスに依存する部分であるため、デバイスメーカー側から提供される情報に基づいて決まる。

以上のように、デバイスドライバの中核をなすデバイスドライバ本体はデバイスの各種パラメータやドライバインターフェース１０Ａやデバイスインターフェース１０Ｃへのコマンドなど、デバイスに合わせた各種の設定情報を保持している。この部分はデバイス（ハードウェア）への依存性が高いがＯＳへの依存は殆ど無い。しかし、従来のデバイスドライバは、構成の大部分がデバイスや接続方法に依存して決まる共通部分であるにも関わらず、構成の一部がＯＳに依存するために、デバイスドライバ全体がＯＳに依存するものとなっていた。

これに対して、本実施形態のデバイスドライバは、ＯＳに依存する「（ａ）ドライバインターフェース」の部分だけの機能を担う「通知用ドライバ」をＯＳごとに１つ準備し、これをカーネルに登録するところから開始し、デバイスの初期化の際にＯＳに依存しない（デバイスには依存する）デバイス設定情報を「通知用ドライバ」を介してカーネルに読み込ませることで、ユーザー権限で後からユーザーがデバイス設定情報を後から自由に書き換えることができるように構成されている。

このように、初期化の際にデバイス設定情報を読み込んで機能の並び（レジスタの並び）をメインスレッドの前に決定する。これは、ランタイム中に決定しようとすると時間がかかるためである。レジスタに書き込んだ際の振る舞いはデバイスの製造メーカーによって異なる場合も多いがユーザーのニーズは決まっており、レジスタの並びは違っていても実現される機能は大体同じであることが多い。たとえば、カメラモジュールを例にとると、
・カメラＡ
レジスタ＃１．ズーム
レジスタ＃２．フォーカス
・カメラＢ
レジスタ＃１．フォーカス
レジスタ＃２．ズーム

このようにレジスタの並びが違っている場合でも、デバイス設定情報で規定されるパラメータを変更してレジスタの並びを変えるだけでカメラＡ、Ｂの両方に対応できるようになる。

このように、本発明のデバイスドライバは、デバイスを特定しない、「デバイス設定情報の通知用ドライバ」をカーネルにロードし、デバイスを初期化する際にデバイス設定情報を通知用ドライバに読み込んでデバイス設定情報をカーネルに通知することで、自身のデバイスの動作を確定させることができる。なお、通知用ドライバはＣ言語などで作成（プログラミング）し、一度作成すればＯＳ及びプロセッサが変わらない限り、同じものを繰り返し用いることができる。

本実施形態では、デバイス設定情報を「シナリオ・シーケンス・ファイル」と呼ばれるスクリプト形式のファイルに記述する。通知用ドライバをロードしてデバイスを初期化する際に、例えば、「Ｉ２Ｃインターフェース経由で音声情報を通信するマイクデバイスである」というデバイス設定情報を記述したシナリオ・シーケンス・ファイルを読み込むことで、ＯＳのユーザーからみるとそれがマイクデバイスとして認識されうる。このシナリオ・シーケンス・ファイルはデバイスに依存するがＯＳには依存しない。

このように、初期化のたびごとに必要な機能をディスパッチしても、実際にカーネルに登録された際に占有するメモリ量は従来のデバイスドライバと変わらず、この点においては従来のデバイスドライバと比較して何らデメリットがない。

シナリオ・シーケンス・ファイルの読込処理は、従来のデバイスドライバにはない余分な処理といえるが、近年のパソコンやスマートフォンなどのように、処理能力が高いプロセッサと十分なメモリを有している場合には、多少ディスパッチの回数が増えてもデバイスが要求する時間内に処理（カーネルへの登録）が終わるので、特に問題が起こることはない。

さらに、シナリオ・シーケンス・ファイルに記述されるコマンドは、呼び出す機能の内容及び順序などからなるが、それぞれの機能は部品化されているため、頻繁に使用される一連の機能はマクロプログラムとして定義しておくと使い勝手がよい。

シナリオ・シーケンス・ファイルの読み込み処理の速度については主にシナリオ・シーケンス・ファイルから呼び出す機能のディスパッチに要する時間と関係する。あまり多くのコマンドを束ねると処理は速くなるが汎用性が損なわれて使いにくくなる。逆に、例えば「メモリ転送」のような頻繁に用いられるコマンドを扱うとディスパッチ回数が増え、非力なプロセッサで読み込む場合はデバイスが要求する時間内にデバイスの認識が完了せずエラーになるおそれもあり、注意が必要である。したがって、プロセッサの処理能力等から許容されるディスパッチ回数とシナリオ・シーケンス・ファイルの汎用性を考慮して、適宜設計するべきである。

一般に、プロトコルパケットの処理などはマクロシーケンス化しやすいが、バス接続で割り込み処理の多いものはマクロシーケンス化することはやや非効率であると考えられる。いずれにせよ使いやすい単位でマクロ化することでシナリオ・シーケンス・ファイルは更に使いやすくなっていく。

図２は、カーネル−デバイス間及びデバイス−デバイス間の物理的又は論理的な接続態様を示す図である。図中の実線はバスインターフェース接続を表し、破線は論理的インターフェース接続を表す。例えば、カーネルとＵＳＢホストコントローラとはバス接続で接続されるが、ＵＳＢホストコントローラに接続されるＵＳＢデバイスはプロトコルパケットで通信される論理的インターフェースということになる。例えば、図中のＳＤホストデバイスは、カーネルとＰＣＩバスなどの外部バスで接続され、ＳＤホストデバイスの先にはＷｉＦｉ（無線ＬＡＮ）モジュールなどの無線通信デバイスやメモリカードなどが「ＳＤバス（或いはその上位互換であるＳＤＩＯバス）」と呼ばれる外部バスを通じて接続されうることを示している。

このように、デバイスがどのようなデバイスインターフェースを持つものであっても、通知用ドライバをカーネルに読み込んだ後、デバイスの初期化の際に、カーネルに対するデバイスの登録方法をデバイス設定情報として通知することで、あらゆるデバイスに対応したデバイスドライバを実現することができる。

そして、この「シナリオ・シーケンス・ファイル」、より正確には少なくとも実際に接続される機器に関する情報を、ＯＳのカーネル側から下段のデバイスプロキシ装置に通知する仕組みを持つことで、理論的には何段でも、デバイスプロキシ装置を接続していくことができる。マルチプロセッサ場合はスレッドを分離してプロセッサ間通信で共有し、下段には論理的インターフェースを介して通信経路や通信プロトコルを用いて通知していくことができる。

（第２の実施形態）−デバイスドライバの登録方法−
図３は、第２の実施形態のデバイスドライバの登録方法を示すフローチャートである。

−ステップＳ１−
ステップＳ１では、第１の実施形態で説明した通知用ドライバをカーネルにロードする。ＯＳ起動後にデバイスドライバをロードする方法はＯＳによって異なっている。例えば、ＯＳがＬｉｎｕｘ（登録商標）である場合は、”ｉｎｓｍｏｄ”などのコマンドを用いる。ＯＳがＷｉｎｄｏｗｓ（登録商標）である場合には、「．ｓｙｓ」というドライバ定義ファイルを作成してプラグ・アンド・プレイでＯＳにデバイスドライバの読み込みを行わせることで必要なデバイス設定情報をレジストリに登録する方法が簡便である。その他のＯＳでもデバイスドライバをカーネルにロードするコマンドがある場合にはそれを利用する。

−ステップＳ２−
次に、デバイスを初期化を開始して（ステップＳ２）、シナリオ・シーケンス・ファイルを読み込む。ステップＳ１で通知用ドライバのロードが終了し、デバイスは待機状態にある。ここで、初期化を開始して、シナリオ・シーケンス・ファイルの読込を開始する。
この初期化ステップは、具体的には、例えば、デバイスの設定情報（パラメータ）を初期値に設定することや、デバイスの動作を決定する実行スクリプトに記述された実行コマンドを初期化する、或いは、シナリオ・シーケンス・ファイルを基にデバイスドライバを生成するための準備としてメモリ上に作業領域を確保することなどを含む。

この初期化ステップをデバイス側とカーネル側のそれぞれからみた動作は、具体的には、例えば以下の通りとなる。
Ｓ２−１．レジスタのデフォルト値を設定 ＜ＯＵＴ側（デバイス側）＞
Ｏｕｔ側のセンサ部のレジスタ（例えば、デバイスがカメラモジュールであるとした場合、画面サイズ、フォーカスをどこから開始するか（通常は無限大側）、ホワイトバランス（画調）、露出時間などの各種デバイスパレメータ）を初期値に設定する。なお、カメラモジュールは一例であり、あらゆるデバイスの設定値が初期値に設定されることを意味する。
Ｓ２−２．ワークメモリのクリア（ワークメモリをゼロで埋める） ＜ＩＮ側＞
以上のステップにより、デバイスドライバをカーネルに登録した際には、常に同じ動作が保証されることになる。

シナリオ・シーケンス・ファイルを読み込むことで初期化が完了する。

−ステップＳ３−
次に、シナリオ・シーケンス・ファイルを基にハンドラを生成するメインスレッドを実行する（ステップＳ３）。このステップＳ３は特にリードとライトとＩ／Ｏコントロールの機能とシーケンスを生成するステップであり、ユーザー権限で実施することができる。たとえば、ユーザー権限でＩ／Ｏコントロールを使ってファイルの書き込み属性を変えることもできる。デバイスドライバはこの時点ではじめて自身の動作が確定する。

−ステップＳ４−
次に、生成された上記各ハンドラの内容をデバイスドライバとしてカーネルに登録する（ステップＳ４）。このデバイスドライバは、ＯＳ上で利用できるような状態で登録されていればよく、方式や利用形態などを問わず、ＯＳのカーネルに組み込まれていればよい。

すなわち、通知用ドライバがカーネルに読み込まれた時点（ステップＳ１）では、デバイスドライバとしての動作は確定しておらず、そこからデバイスを初期化してシナリオ・シーケンス・ファイルを読み込んでハンドラを生成し、カーネルに登録された時点（ステップＳ４）で初めて、デバイスドライバとして機能するようになる。本実施形態のデバイスドライバは、デバイス側からみた場合には、従来のデバイスドライバと何ら変わりない動作をすることはいうまでもない。

以上のステップＳ１〜Ｓ４により、計算機システムは、シナリオ・シーケンス・ファイルに記述されたデバイス設定情報（デバイスパラメータ及びデバイスの動作を決定する実行スクリプト）を読み込むことでＯＳに依存しないデバイスドライバ１０を生成することができ、そのデバイスドライバ１０を用いることでデバイスインターフェースに接続されたデバイスを制御して使用することができるようになる。また、デバイスドライバ１０は従来のようなコンパイルが不要であるため、計算機システムでデバイスドライバ１０を容易に生成することができる。

−ステップＳ５−
デバイスを取り外すときは終了（Ｔｅｒｍｉｎａｔｅ）する。

（第３の実施形態）
図４（ａ）、（ｂ）は、（ａ）マルチコアプロセッサを含む同一筐体の計算機の基本構成を示す概念図、（ｂ）プロセッサを２基含む同一筐体の計算機の基本構成を示す概念図である。計算機２０はマルチコアプロセッサのマイクロプロセッサユニット（ＭＰＵ）２１とメモリ２２とデバイスインターフェース２３（図１の１０Ｃ）を具備する。マイクロプロセッサユニット２１は、主にＣＰＵ（Central Processing Unit）であり、ＦＰＧＡ（field-programmable gate array）やマイコンなど、各種のロジックＩＣを用いてもよい。メモリ２２は、ＲＡＭ（Random Access Memory）などの一時記憶装置を指す。

図４（ａ）は、複数のプロセッサコア（２１ａ、２１ｂ、・・・）からなるマルチコアのマイクロプロセッサユニットのスレッドを分離して一つのプロセッサコア２１ａをデバイスプロキシ装置の動作に割り当て、残りをＯＳに割り当てる態様である。計算機２０は、マルチコアのマイクロプロセッサユニット２１、メモリ２２、デバイスインターフェース２３を具備し、デバイスインターフェース２３を介してデバイス１２に接続される。このとき、シナリオ・シーケンス・ファイルはプロセッサ間通信により共有する。

図５は、図４（ａ）を更に詳しく説明した構成図である。計算機２０内で、ユーザーインターフェースを管理するオペレーティングシステムのカーネルはプロセッサ１Ａ（図４（ａ）における２１ｂ、２１ｃ、・・・）と、デバイスプロキシ装置を管理するプロセッサ１Ｂとでスレッドを分離してプロセッサ間通信でデータを共有できることを表している。デバイスプロキシ装置はシナリオ・シーケンス・ファイルを受け取りデバイスドライバ１０を介してデバイス１２に接続する。

図４（ｂ）は、ＣＰＵが物理的に分離している場合である。この場合、プロセッサ間通信は使用できないが、同じ筐体内（回路基板上）にある場合は一般にバスで接続されており、このバス接続によりシナリオ・シーケンス・ファイルを共有することができる。

図６は、デバイスプロキシ装置６０が、ＯＳからみて、独立したハードウェアとして、デバイスインターフェース２３（特に、論理的インターフェース）を介して接続されている態様を説明する概念図である。デバイスプロキシ装置６０は、プロセッサ６１とメモリ６２とデバイスインターフェース６３とを具備し、一つ又は複数のデバイス６２に接続される。プロセッサ６１のプロセッサコア数は１つ以上であればよい。

デバイスインターフェース２３、６３は、マイクロプロセッサユニット２１が制御する周辺機器用のものであればよく、具体的には、例えば図２に示すような各種デバイスに接続するものであればよい。ＰＣＩ（Peripheral Component Interconnect）カード、ネットワークカード、マイク、カメラ、ＵＳＢ、ＳＤカード、ＷｉＦｉ（Wireless Fidelity）内蔵機器、ＡＤＣ（Analog to Digital Converter）、Ｂｌｕｅｔｏｏｔｈ（登録商標）内蔵機器、ＧＰＳ内蔵機器、プリンタ、ＦＡＸ、スキャナなどである。デバイスインターフェース２３は、メモリ２２のような一時記憶装置又はハードディスクなどの記憶装置を接続するためのインターフェースであってもよく、キーボードやマウス或いはジョイスティックを接続するための入力インターフェース、ディスプレイその他表示装置を接続するための出力インターフェースであってもよい。なお、メモリ２２も周辺機器であるため、例えば、メモリ２２は図示しないデバイスインターフェースであるメモリスロットに接続され、マイクロプロセッサユニット２１がメモリ２２用のデバイスドライバでメモリ２２を管理する。

計算機２０にはオペレーティングシステムがインストールされており、さらに、そのＯＳのカーネルに上記ステップＳ１〜Ｓ５により生成されたデバイスドライバ１０が登録されている。そして、計算機２０のデバイスインターフェース２３の先にデバイス１２が接続されている。

図１に示すドライバインターフェース１０Ａは、ＯＳの上記各ハンドラである。ドライバ１０は、ドライバインターフェース１０Ａ（各ハンドラ）とデバイス毎に決まったデバイスインターフェース１０Ｃの間でデータを送受信する役割を果たす。具体的には、ドライバ１０（１０Ｂ）は、上記ステップＳ３により確定された各ハンドラの処理を実施するためのプログラムである。

以上のようなデバイスドライバ１０をシナリオ・シーケンス・ファイルを基に生成することにより、計算機２０は、デバイス１２との間でデバイスとの通信データを送受信することができる。

（実施例）−シナリオ・シーケンス・ファイルの具体例−
以下に、デバイス設定情報を記述したシナリオ・シーケンス・ファイルの一例を挙げる。
シナリオ・シーケンス・ファイルはデバイスインターフェースに接続されるデバイスのデバイスパラメータとハンドラを生成するための実行スクリプトを記述したファイルであり、スクリプト形式のファイルであるため、テキストエディタで編集できる程度の非常に小さな（例えば２キロバイト以下のような）ファイルサイズのテキストデータで構成することもできる。実装により、ＪａｖａＳｃｒｉｐｔ（登録商標）やＸＭＬなど、ＯＳや計算機のハードウェア（ＭＰＵ）に依存しない中間言語の形式で記述してもよい。

デバイスをカーネルに登録するために必要な情報は、
（ａ）デバイスインターフェースに関する情報
（ｂ）デバイスの動作内容に関する情報
（ｃ）接続先デバイスに関する情報
である。これらの情報をシナリオ・シーケンス・ファイルに記述し、通知用ドライバを介してカーネルに登録すればよい。

構成情報のわずかな変更があっても従来のようにデバイスドライバをソースコードから書き換えて再度コンパイルする必要はなく、シナリオ・シーケンス・ファイルの一部を書き換えてデバイスを初期化しなおすだけでよい。

例えば、プリンタのように、同じデバイスでも複数の接続形式が可能なデバイスが存在する。ネットワークに接続できるプリンタが、ＵＳＢ接続あるいはシリアル接続可能な場合、ドライバインターフェースとデバイスドライバ本体の構成は変わらず、デバイスインターフェースだけが異なっている。接続形態が決まれば以後変わることがないため、実装前にどのデバイスインターフェースを実装するかを決定すればよい。ＵＳＢ接続からネットワーク接続（Ｅｔｈｅｒｎｅｔ（登録商標）接続）に変更したい場合は、ＯＳを起動した状態でしかもデバイスドライバもクローズすることなく、再度デバイスを初期化して、単に経路情報が変更されたことを示すデバイスインターフェースの部分を修正したシナリオ・シーケンス・ファイルを通知用ドライバ読み込むだけでよい。

以下、シナリオ・シーケンス・ファイルで定義するデバイス設定情報（コマンドとパラメータ等）の例について説明する。

[処理命令定義]
処理命令定義は、シナリオそのものの記述を行う実行コマンドが記述される。なお、デバイス（ハードウェア）に依存して決まっている割り込み番号は「int1」などの予約語として扱う。
処理命令 ： 処理内容
wait intr(n) ： 割り込みID n の割り込みを待つ
write $addr ： ＯＳから受け取ったデータを$addrに書き込む
write $addr,size ： ＯＳから受け取ったデータを$addrから書き込む
write data,$addr ： dataを$addrに書き込む
read $addr,size ： $addrからsizeだけのデータをＯＳに返す
copy $add1,$add2,size ： $add1から$add2にsizeバイト データを転送する
copy $add1,$add2,size ： $add1から$add2にsizeバイト データを転送する
copy #dataset(n) ： データセットID n を転送する
res data ： dataをＯＳに返す
and mask,$addr ： $addrのデータとmaskの論理積を取り、条件分岐式に反映する
or mask,$addr ： $addrのデータとmaskの論理和を取り、条件分岐式に反映する
if else endif ： シナリオの条件分岐
while endwhile ： while〜endwhile間を条件ループする
for n endfor ： for〜endfor間をn回ループする
exit ： インターフェースを終了する
処理命令定義には、その他、ＤＭＡ転送やｍｕｔｅｘなどを含む同期の仕組みなどの処理命令が記述される。

[データセット定義]
データセット定義は、１つ又は複数のデータを１セットとしたデータセットの定義が記述される。データセットは任意の名前のデータ列を定義することができる。データ列には、レジスタと定義内容、書き込み後のタイミングなどを記述する。データセットは複数パターンを登録しておき、目的や場合に合わせて使い分ける。

データセットの定義 ： 定義内容
b $addr and mask n ： データセットbを「$addrの内容にmaskの論理積を１バイト書き込み n ミリ秒待つ」データ列と定義する
w $addr or mask n ： データセットwを「$addrの内容にmaskの論理和を２バイト書き込み n ミリ秒待つ」データ列と定義する
l $addr data n ： データセットlを「$addrの内容にdataを４バイト書き込み n ミリ秒待つ」データ列と定義する

次に、シナリオ・シーケンス・ファイルを基にＯＳの各ハンドラ（[init]、[term]、[open]、[close]、[I/O-ctrl]、[read]、[write]、[main_thread]）にデバイスパラメータ並びに処理命令定義及びデータセット定義を含む実行スクリプトを割り当てて各ハンドラの処理を構成したデバイスドライバの一例を以下に挙げる。このデバイスドライバを用いることで、決まったサイズのパケットを任意タイミングで送受信するデバイス、例えば、加速度センサーに対してメモリマップドレジスタへの読み書きを制御することができる。なお、以下の一部には「// コメント」を追記している。

[init]
allocate $buffer 16;
allocate $flag 1;
exit;
[term]
free buffer;
free $flag;
exit;
[open] // 何もしない
exit;
[close] // 何もしない
exit;
[I/O-ctrl] // 何もしない
exit;
[read]
or.w #0001,$flag;
if // バッファにデータが有れば
read $recive_data,16; // データを読み出す
write.w 1,$flag
endif
exit;
[write]
write $send_reg,16; // デバイス読み込み開始
wait int1; // 完了割り込み待ち
exit;
[main_thread] // 受信割り込みを待ってバッファに読み出す
while;
wait int1; // 完了割り込み待ち
read $recive_data,buffer,16; // デバイスからバッファにデータを読み出しておく
write.w 1,$flag;
endwhile;

インストラクションは上記のとおり比較的簡単なプログラムである。デバイスドライバとしての機能を確定させるために、テキストエディタでシナリオ・シーケンス・ファイルにシナリオ（インストラクションの順序）を記述し、パーシングしたシナリオにより記述した処理内容（例えばルックアップテーブルを持ったもの）をそれぞれのインターフェース（６種)をコールバックハンドラとして割り当てる。シナリオ・シーケンス・ファイルを読み込む方法はオープン・リード・ライト・クローズなどの機能を用いる。また、割り込みがある場合は割り込み待ちを行う。

なお、一連の作業をデバイスメーカーではないユーザー等の第三者がデバイスメーカーからデバイス設定に必要なパラメータを得てシナリオ・シーケンス・ファイルを作成する場合、シナリオのスクリプト内容自体を変更するとドライバの動作が狂うおそれがある。従って、このような場合はテキストファイルではなく、他のアプリケーションツールなどを介してシナリオ・シーケンス・ファイルを作成・修正できるようにして、不要な設定を変更しないようにするなどの工夫をしてもよい。

（第４の実施形態）
図７（ａ）及び図７（ｂ）は、いずれも計算機システムのハードウェア構成を示す概念図である。計算機Ａは、ＯＳを駆動し、高い計算処理能力を要求されるプログラムを主に実行するが、デバイスの制御は抽象化されたデバイスＢが行うため、割り込み処理などの計算を中断させるイベントをデバイス側から直接受け取ることがなくなる。デバイスプロキシ装置Ｂ〜Ｅは、いずれも組み込みオペレーティングシステムが搭載されたデバイスプロキシ装置であり、それぞれのデバイスプロキシ装置に例えば入力デバイス、音響デバイス、ハードディスクなどのストレージデバイス、ネットワークデバイスといった各種のデバイスａ、ｂ、ｃ、ｄ、ｅがそれぞれ接続されている。本実施態様では、デバイスプロキシ装置のプロセッサは、下段ほど低速なものが用いられている。例えば、デバイスプロキシ装置Ｂには安価な１００ＭＨｚの１６ビットマイコンが用いられており、デバイスプロキシ装置Ｃ、Ｄ及びＥには更に安価２０ＭＨｚの１６ビットマイコンが用いられる。或いは、デバイスプロキシ装置Ｂのプロセッサは、計算機Ａがマルチコアのマイクロプロセッサユニットを持つ場合にはその一つのプロセッサコアとしてもよい。

計算機Ａは、デバイスａ〜ｅを動作させるために必要なすべてのデバイス設定情報を含むシナリオ・シーケンス・ファイルを保持している。一つのシナリオ・シーケンス・ファイルが１つのデバイス設定情報を保持するように構成した場合、デバイスが５種類であれば５つのシナリオ・シーケンス・ファイルということになる。もちろん設計次第では複数のデバイスを動作させるためのそれぞれのデバイス設定情報を１つのシナリオ・シーケンス・ファイルにまとめても良い。

各デバイスプロキシ装置Ｂ〜Ｅは、入力側（上段側）からデバイスインターフェースを介してシナリオ・シーケンス・ファイルを受け取る。たとえば、Ｉ２Ｃ、ＳＰＩ、Ｗｉ−Ｆｉ、ＵＡＲＴといった各種インターフェースの情報により接続経路や通信プロトコルが記述されたシナリオ・シーケンス・ファイルから必要なデータを取り込み、デバイスを設定する。ただし、シナリオ・シーケンス・ファイルを上段から受け取らず直接自身のデバイスプロキシ装置にデバイス設定情報を記述したデータを保持してもよい。

ロジカルパケットは連続的なストリーミングデータであるため、制御対象のデバイス名を示す「シンボル」を例えば８バイトのアスキーキャラクターのデータ形式で表現し、必要な情報をロジカルパケットのヘッダーに記述してデータを送信することができる。実験では、「サイズ・シンボル・可変長データ」というデータ列の形式でロジカルパケットデータを構成してもよい。

このように、シナリオ・シーケンス・ファイルを共有しながら計算機の処理からデバイスに関する処理を分離して、デバイスプロキシ装置側でデバイスの制御を行わせることで、オペレーティングシステムを駆動するＣＰＵの処理負担を軽減できる。また、デバイスの接続態様を例えば図７（ａ）から図７（ｂ）に変更する場合でも、計算機から見るとデバイスはすでに抽象化されているため、アプリケーションプログラムが要求する時間内に必要なデータを受け取れる限り、下段のデバイスがどのようなものであっても、シナリオ・シーケンス・ファイルは変わらず、動作に影響がない。さらに、ハードディスクなどコンテンツを含むデバイスを接続する場合、デバイスプロキシ装置は何ら情報を保持しないため、計算機とハードディスク間で暗号化しておけば、ハードディスクを持ち去られたとしても情報漏洩のおそれもない。このようなシステムは銀行の現金自動預け払い機（ＡＴＭ）など、高度な機密情報を扱う端末において効果を発揮する。

１０ デバイスドライバ
１０Ａ ドライバインターフェース
１０Ｂ デバイスドライバ本体
１０Ｃ デバイスインターフェース
１１ カーネル
１２ デバイス
２１ マルチコアのマイクロプロセッサユニット（ＭＰＵ）
２２ メモリ
２３ デバイスインターフェース（物理的インターフェース及び／又は論理的インターフェース）
３１、６１ プロセッサ（シングルコア又はマルチコア）
６２ メモリ
６３ デバイスインターフェース
Ａ 計算機
Ｂ，Ｃ，Ｄ，Ｅ デバイスプロキシ装置
ａ，ｂ，ｃ，ｄ，ｅ デバイス

Claims (10)

1. 計算機上で動作するオペレーティングシステムのカーネルとデバイスの間に介在して前記デバイスを代理するデバイスプロキシ装置であって、
   前記デバイスプロキシ装置自身及びその先に接続される後段のデバイスを動作させるために必要なデバイスドライバとしての機能と、
   前記オペレーティングシステムとの間で前記デバイスの動作に必要な情報をやりとりする通信機能とを備え、
   前記オペレーティングシステムに依存しない形式で記述されたデバイス設定情報を前記オペレーティングシステム側で保持しつつ、
   前記通信機能を介して前記オペレーティングシステム側から前記デバイス設定情報を受け取り、
   前記デバイス設定情報に基づいて前記オペレーティングシステムのカーネルに登録された前記デバイス設定情報を通知するための通知用ドライバを介してデバイスドライバが前記オペレーティングシステムのカーネルに登録されることを特徴とするデバイスプロキシ装置。
2. 前記デバイス設定情報は、デバイスにのみ依存するパラメータ及びＯＳに依存しないコマンドのみを含み、処理の手順を示すシナリオ・シーケンス・ファイルで記述されることを特徴とする請求項１記載のデバイスプロキシ装置。
3. 前記デバイス設定情報を受け取るタイミングは、下記１）〜３）のいずれかであることを特徴とする請求項１又は請求項２記載のデバイスプロキシ装置。
   １）前記デバイスプロキシ装置にデバイスが接続された際、
   ２）前記オペレーティングシステム上で動作するアプリケーションプログラムが要求する時間内
   ３）デバイス側から割り込みイベントその他の処理要求があった場合
4. オペレーティングシステムを実行する計算機と請求項１乃至請求項３のいずれか１項記載のデバイスプロキシ装置とが前記通信機能を介して接続された計算機システム。
5. 前記通信機能はプロセッサ間通信又はデバイスインターフェースを介した通信により実現されることを特徴とする請求項４記載の計算機システム。
6. 請求項１乃至請求項３のいずれか１項記載のデバイスプロキシ装置に、さらに別のデバイスプロキシ装置が多段に直列及び／又は並列に接続された計算機システムであって、
   それぞれのデバイスプロキシ装置及びそれらに接続される１つ又は複数のデバイスのデバイス設定情報が、いずれも前記計算機のオペレーティンスシステムに依存しない形式で記述されていると共に、前記計算期内又は前記いずれかのデバイスプロキシ装置内に保持されていることを特徴とする請求項４又は請求項５記載の計算機システム。
7. 前記デバイスプロキシ装置の少なくとも１つは、オペレーティンスシステムを有しないことを特徴とする請求項６記載の計算機システム。
8. 複数のデバイスプロキシ装置が多段に直列接続された構成を具備する計算機システムにおいて、
   下段側のデバイスプロキシ装置ほど低速なプロセッサが用いられていることを特徴とする請求項６記載の計算機システム。
9. マルチコアプロセッサユニットを搭載する計算機システムにおいて、少なくとも一つのプロセッサユニットが請求項１記載のデバイスプロキシ装置を動作させるために割り当てられる一方、
   その他のプロセッサユニットがオペレーティンスシステムを実行するために割り当てられることを特徴とする請求項４乃至８のいずれか１項記載の計算機システム。
10. 前記デバイスプロキシ装置に接続されるデバイスから前記オペレーティングシステムにロジカルパケットが送信される際には、
    前記デバイスプロキシ装置が、サイズ、制御対象のデバイス名を示すシンボル、可変長その他必要な情報をロジカルパケットのヘッダーに記述して前記オペレーティングシステム側にデータを送信することを特徴とする請求項６記載の計算機システム。

Images