(57)【要約】【課題】効率性、上位プラットフォームに依存しないこと、かつ、ユーザビリティを考慮した入出力制御装置を提供する。【解決手段】複数のＯＳの同時実行機能を備えるホストシステム上で、少なくとも２つ以上のＯＳが同時に動作する計算機に配置される入力デバイス及び出力デバイスの入出力を制御する入出力制御装置１００は、入力デバイス或いは出力デバイスを占有するＯＳを切り替えるように要求する切り替え要求を受理する要求受理部１１０と、切り替え要求に応じて入力先情報２３０或いは出力可否情報２４０を含む制御情報１２１を生成する制御情報生成部１２０と、入力先情報２３０或いは出力可否情報２４０を出力する制御情報出力部１３０とを備える。【選択図】図１
2007220086.tif 000002
【特許請求の範囲】
【請求項１】
複数のオペレーティングシステムの同時実行機能を備えるホストシステム上で、少なくとも２つ以上のオペレーティングシステムが同時に動作する計算機に配置される入力デバイス及び出力デバイスの入出力を制御する入出力制御装置であって、
前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、
前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、
前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを特徴とする入出力制御装置。
【請求項２】
前記要求受理部は、前記計算機により予め備えられている第１の入力デバイスを制御する第１の制御ソフトウェアからの切り替え要求を受理することを特徴とする請求項１に記載の入出力制御装置。
【請求項３】
前記要求受理部は、オペレーティングシステムからの切り替え要求を受理することを特徴とする請求項１に記載の入出力制御装置。
【請求項４】
前記切り替え要求に対する処理を規定する要求規則が与えられた場合に、前記要求受理部は、前記要求規則に基づいて前記切り替え要求を受理或いは非受理とすることを特徴とする請求項１に記載の入出力制御装置。
【請求項５】
前記要求規則は、前記切り替え要求の受理に秘密情報の入力を要求し、
前記要求受理部は、前記秘密情報が正しい時のみ、前記切り替え要求を受理することを特徴とする請求項４に記載の入出力制御装置。
【請求項６】
前記要求規則は、不正な切り替え要求を定義し、
前記要求受理部は、前記切り替え要求が不正であった場合には、該切り替え要求を受理しないことを特徴とする請求項４に記載の入出力制御装置。
【請求項７】
前記要求規則は、前記切り替え要求の受理に、ユーザからの特定の動作によるユーザの許可/不許可の判定を必要とし、
前記要求受理部は、前記特定の動作による許可を以って、前記切り替え要求を受理することを特徴とする請求項４に記載の入出力制御装置。
【請求項８】
一定時間、前記特定の動作による許可/不許可のいずれの判定もユーザから得られなかった場合、前記要求受理部は、前記切り替え要求を受理することを特徴とする請求項７に記載の入出力制御装置。
【請求項９】
前記要求規則は、特定の切り替え要求を特権要求とし、
前記要求受理部は、前記特権要求による制御情報の生成後、特定の条件を満たすまでは、前記特権要求により特定のオペレーティングシステムに占有された入力デバイス或いは出力デバイスに対する切り替え要求を非受理とすることを特徴とする請求項４に記載の入出力制御装置。
【請求項１０】
要求受理部は、前記ホストシステムからの切り替え要求を受理することを特徴とする請求項１に記載の入出力制御装置。
【請求項１１】
前記計算機上の第１のオペレーティングシステム或いは前記ホストシステムが、前記計算機上で動作するオペレーティングシステムの特定の状態変化を検知する状態変化検知機能を備える場合に、前記要求受理部は、前記状態変化検知機能が、入力デバイス或いは出力デバイスを占有する第２のオペレーティングシステムの前記状態変化に応じて発行する切り替え要求を受理することを特徴とする請求項３又は１０に記載の入出力制御装置。
【請求項１２】
少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、
前記入出力制御装置は、
前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、
前記ホストシステム上で動作する前記複数のオペレーティングシステム中の特定の１つのオペレーティングシステムは、
前記出力された入力先情報を以って、前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定し、該入力先オペレーティングシステムへ前記入力情報を入力する入力デバイス制御部と、
前記出力された出力可否情報を以って、前記出力デバイスへ出力可能なオペレーティングシステムを特定し、該オペレーティングシステムから受け取った出力情報を前記出力デバイスへ出力する出力デバイス制御部とを備え、
前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、
前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを特徴とする入出力制御システム。
【請求項１３】
少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、
前記入出力制御装置は、
前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、
前記ホストシステム上で動作する前記複数のオペレーティングシステムの各々は、
前記入出力制御装置により出力された入力先情報を参照することで、前記入力デバイスからの入力情報を、前記オペレーティングシステムへ入力するか否かについて決定する入力デバイス制御部と、
前記入出力制御装置により出力された出力可否情報を以って、前記オペレーティングシステムからの出力情報を出力するか否かについて決定する出力デバイス制御部とを備えることを特徴とする入出力制御システム。
【請求項１４】
少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、
前記入出力制御装置は、
前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、
前記複数のオペレーティングシステムの各々は、
前記入力デバイスを制御可能な入力デバイス制御部と、
前記出力デバイスを制御可能な出力デバイス制御部とを備え、
前記ホストシステムは、
前記入出力制御装置により出力された入力先情報を以って、前記オペレーティングシステムの前記入力デバイス制御部を有効化或いは無効化し、
前記入出力制御装置により出力された出力可否情報を以って、前記オペレーティングシステムの前記出力制御部を有効化或いは無効化する入出力制御部を備えることを特徴とする入出力制御システム。
【請求項１５】
少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、
前記入出力制御装置は、
前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、
前記ホストシステムは、
前記入力デバイスに対する割り込みが発生した場合に、前記割り込みを前記オペレーティングシステムへ通知する割り込み通知部を備え、
前記割り込み通知部は、前記入出力制御装置が出力した入力先情報を以って、前記割り込みの通知先を特定することを特徴とする入出力制御システム。
【請求項１６】
少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、
前記入出力制御装置は、
前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、
前記ホストシステムは、
前記入出力制御装置により出力された入力先情報或いは出力可否情報に応じて、前記オペレーティングシステムに対するＱｏＳ制御を行うＱｏＳ制御部を備えることを特徴とする入出力制御システム。
【請求項１７】
複数のオペレーティングシステムの同時実行機能を備えるホストシステム上で、少なくとも２つ以上のオペレーティングシステムが同時に動作する計算機に配置される入力デバイス及び出力デバイスの入出力を制御する入出力制御方法であって、
前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理するステップと、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成するステップと、
前記入力先情報及び前記出力可否情報を出力するステップとを備え、
前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、
前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを特徴とする入出力制御方法。
【請求項１８】
前記特定のオペレーティングシステムとは別の第１のオペレーティングシステムは、仮想入力デバイス制御部と、仮想出力デバイス制御部とを備え、
前記仮想入力デバイス制御部は、前記特定のオペレーティングシステムの前記入力デバイス制御部より入力された入力情報を受け取り、前記第１のオペレーティングシステム上で動作するプログラムへ入力し、
前記仮想出力デバイス制御部は、前記第１のオペレーティングシステム上で動作するプログラムからの出力情報について、前記出力可否情報を以って、前記第１のオペレーティングシステムが、前記出力デバイスに対して前記出力情報を出力可能か判断し、前記出力デバイスに対して前記出力情報を出力可能である場合に限り、前記出力情報を前記特定のオペレーティングシステムの前記出力デバイス制御部に対して出力することを特徴とする請求項１２記載の入出力制御システム。
【請求項１９】
少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能を含むホストシステムとを備える入出力制御システムであって、
前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、
前記オペレーティングシステム上で動作するプログラムは、
前記入力先情報により、前記プログラムが動作するオペレーティングシステムが、前記入力デバイスからの入力先オペレーティングシステムである場合に限り、前記オペレーティングシステムに対して入力を要求するシステムコールを発行し、
前記出力可否情報により、前記プログラムが動作するオペレーティングシステムが、前記出力デバイスに対して出力可能である場合に限り、前記オペレーティングシステムに対して出力を要求するシステムコールを発行し、
前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、
前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを特徴とする入出力制御システム。
【請求項２０】
前記オペレーティングシステムは、前記要求規則により、前記切り替え要求が許可される場合に限り、前記切り替え要求を発行することを特徴とする請求項３又は４に記載の入出力制御装置。
【請求項２１】
前記ホストシステムは、前記要求規則により、前記切り替え要求が許可される場合に限り、前記切り替え要求を発行することを特徴とする請求項４又は１０に記載の入出力制御装置。
【請求項２２】
少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能を含むホストシステムとを備える入出力制御システムであって、
前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、
前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、
前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、
前記オペレーティングシステム上で動作するプログラムは、前記オペレーティングシステムに対して、前記入出力制御装置に対する切り替え要求の発行を要求し、
前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、
前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを特徴とする入出力制御システム。
【請求項２３】
前記プログラムは、前記要求規則により、前記切り替え要求が許可される場合に限り、前記オペレーティングシステムに対して、前記入出力制御装置に対する切り替え要求の発行を要求することを特徴とする請求項２２に記載の入出力制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のオペレーティングシステム（以下、ＯＳ）による入出力デバイスの共有利用を制御する入出力制御装置、入出力制御システム及び入出力制御方法に関する。
【背景技術】
【０００２】
単一のＯＳが動作する計算機において、当該ＯＳや当該ＯＳ上で動作するプログラムは、当該ＯＳに適時組み込まれる入出力デバイスの制御ソフトウェア（以下、デバイスドライバ）によって、当該計算機が備える入出力デバイスにアクセスすることができる。
【０００３】
ここで、当該計算機は、少なくとも、当該計算機の外部から当該ＯＳへ情報を入力する際に利用する入力デバイス（キーボード等）と、当該ＯＳが当該計算機外部へ情報を出力する際に利用する出力デバイス（ディスプレイ等）とを備える。
【０００４】
デバイスドライバは、ＯＳに組み込まれる際に、自らが制御するデバイスの情報を、当該ＯＳに対して登録する。このようなデバイスの情報には、例えば、当該デバイス用の割り込み番号が挙げられる。
【０００５】
計算機の外部からの入力デバイスを介した情報の入力が発生した場合、第１に、割り込みコントローラは、ＣＰＵに対して、割り込み信号と割り込み番号とを通知する。
【０００６】
第２に、ＣＰＵは、かかる割り込み信号を受けて、現在行っている処理を中断し、当該割り込み番号に対応するデバイスドライバを呼び出す。
【０００７】
第３に、デバイスドライバは、対応するデバイスへアクセスして、入力された情報を、ＯＳへ渡す。
【０００８】
また、ＯＳは、特定情報を出力する際、かかる特定情報の内容に従い、適切な出力デバイスを特定する。その後、ＯＳは、予め登録されている当該出力デバイスに対応するデバイスドライバを呼び出して当該特定情報を出力させる。
【０００９】
上述のように、計算機上で単独のＯＳが動作する場合には、当該ＯＳが、入出力デバイスの使用について管理して、当該ＯＳ上で動作するプログラムが同時に入出力デバイスへアクセスする競合状態が発生しないようにすれば良い。
【００１０】
一方で、近年、計算機上で複数ＯＳが同時に実行可能な環境が広がりつつある。このような環境は、図１２に示すように、「バーチャルマシンモニタ（以下、ＶＭＭ）」と呼ばれるホストシステムが、「バーチャルマシン（以下、ＶＭ）と呼ばれるゲストシステムを構成し、ＶＭ上で、各ＯＳを動作することにより実現される（例えば、特許文献１や非特許文献１や非特許文献２参照）。
【００１１】
例えば、かかる環境の利用例としては、リアルタイム処理に特化した「リアルタイムＯＳ（以下、ＲＴＯＳ）」及び汎用的に利用する「汎用ＯＳ（以下、ＧＰＯＳ）」を１つの計算機上で同時に動作させるといった例や、１つのサーバ上で複数ＯＳを動作させて、各ＯＳで当該ＯＳ用に特化されたサービスをクライアントに提供するといった例が考えられる。
【００１２】
このような環境では、入出力デバイスを始めとする、限られたハードウェア資源を、複数ＯＳで共有しなければならない。
【００１３】
ＶＭＭの役割の１つは、静的或いは動的に、ハードウェア資源を各ＯＳに割り当てることである。例えば、ＶＭＭは、各ＯＳに対して動的にＣＰＵの制御権を渡し、静的に主記憶を論理分割して各ＯＳに割り当てることで、複数ＯＳの同時実行を実現する。
【００１４】
また、ＶＭＭの中には、同時に実行される複数ＯＳ間でのデータ通信を実現するものもある。代表的な実現方法は、複数ＯＳが参照可能な共有メモリを提供する方法である。
【００１５】
ＶＭＭは、共有メモリの管理、或いは、共有メモリへの書き込みや読み込みのＯＳへの通知といった処理を行う。
【００１６】
このようなＯＳ間通信機能は、単純なデータ通信時だけではなく、ハードウェア資源を複数ＯＳ間で共有する際にも利用される。
【００１７】
例えば、ネットワークインタフェースを１つしか備えない計算機において、複数ＯＳが、外部との通信を行う場合を考える。
【００１８】
この場合、各ＯＳが、独自にネットワークインタフェースのデバイスドライバを持つ構成は考えにくい。なぜなら、データ受信時に発生するハードウェア割り込みに対して、どのＯＳのドライバが呼び出されるべきかについて事前に判断するのが不可能なためである。
【００１９】
したがって、あるＯＳが、唯一のデバイスドライバの保持者となり、データ送受信及び各ＯＳへのデータ割り振りを行う必要がある。
【００２０】
このようなハードウェア資源の共有利用時には、上述のＯＳ間通信機能は、必須となる。
【特許文献１】ＵＳ２００４/０２０５７５５
【非特許文献１】「Xen and the Art of Virtulization」 In Proc. of Symposium on operating systems Principles (SOSP) 2003 (http://www.Cl.cam.ac.uk/ReＳearch/SRG/netos/papers/2003-xensosp.pdf)
【非特許文献２】「A 600MIPS 120mW 70μA Leakage Triple-CPU Mobile Application Processor Chip」 In Proc. of IEEE International Solid-State Circuits Conference (ISSCC) 2005
【発明の開示】
【発明が解決しようとする課題】
【００２１】
ＶＭＭ上で実現された複数ＯＳ環境において、任意の時点で特定ＯＳによって排他的に占有されるデバイスについて考える。
【００２２】
このようなデバイスの一例として、ヒューマンインタフェースデバイス（以下、ＨＩＤ）が挙げられる。例えば、ＨＩＤとして、入力デバイスであるキーボードや、出力デバイスであるディスプレイ等が挙げられる。
【００２３】
これらのデバイスは、ユーザが利用しているＯＳによって排他的に占有される必要がある。
【００２４】
例えば、ユーザが、特定プログラムを利用している際には、ユーザによりキーボードより入力された結果は、基本的には、当該プログラムに対して入力され、ディスプレイには、当該プログラムの出力結果が表示される必要があるため、キーボードからの入力結果は、当該プログラムが動作するＯＳに渡されなければならず、同様に、当該ＯＳからの出力結果が、ディスプレイに表示されなければならない。
【００２５】
ユーザが、あるＯＳを利用しているということと、ＣＰＵが、当該ＯＳによって制御されているということは必ずしも一致しない。
【００２６】
ＶＭＭは、ユーザが当該ＯＳを利用している間であっても、ＯＳ間でコンテキストスイッチを行い、別のＯＳに対してＣＰＵを割り当て、或いは、ＶＭＭ自身の処理を行う可能性がある。
【００２７】
ＶＭＭは、ＣＰＵの割り当てを管理するため、任意の時点で、どのＯＳがＣＰＵを制御しているかについて把握することが可能であるが、任意の時点で、ユーザがどのＯＳを利用しているかについては把握することができない。
【００２８】
したがって、例えば、ＶＭＭは、キーボードからデータが入力されて割り込みが発生した際に、かかる割り込みがどのＯＳに対する割り込みであるのかについて認識することができない。
【００２９】
例えば、ネットワークインタフェースが共有されている際には、受信したデータに、ＩＰアドレスやポート番号等の行き先のＯＳを識別するためのデータが付与されているために、一旦、あるＯＳが、当該データを受信した後で、当該データを割り振れば良い。
【００３０】
しかし、キーボードから入力されたデータについて、同様の処理を行うことは困難である。
【００３１】
同様に、ディスプレイへの出力時にも問題が発生する。
【００３２】
全てのＯＳが、ディスプレイドライバを個別に保持し、勝手に出力すれば、当然当該ディスプレイへの競合が発生する。
【００３３】
あるＯＳに対して出力すべきデータを集約した場合でも、その時点で、どのＯＳが当該データを出力すべきかについて認識できなければ、ユーザに正しい出力結果を表示することができない。
【００３４】
以上のような問題に対して、特許文献１で述べられた複数ＯＳ環境では、特別の機能を用意していない。
【００３５】
特許文献１は、ＲＴＯＳとＧＰＯＳとの同時実行環境を想定しており、常にＧＰＯＳが、ＨＩＤを占有するものとしているためである。
【００３６】
一方、非特許文献１或いは非特許文献２で述べられた複数ＯＳ環境では、図１３に示すように、１つのホストＯＳを用意し、ホストＯＳのＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）サーバが、他の全てのゲストＯＳのＨＩＤに対する入出力を処理することで、ＨＩＤの共有を実現している。
【００３７】
具体的には、ホストＯＳのみが、ＨＩＤに対するデバイスドライバ（ＨＩＤＤＤ）を保有し、かかるデバイスドライバは、ホストＯＳのＧＵＩサーバからの入出力だけを処理可能とする。
【００３８】
ホストＯＳのＧＵＩサーバは、ホストＯＳ以外の各ゲストＯＳ用にウィンドウ（Ｗｉｎｄｏｗ）を生成し、対応するゲストＯＳのＧＵＩサーバからＶＭＭのＯＳ間通信により受け取った出力結果を出力する。
【００３９】
また、当該ウィンドウが、アクティブな場合には、入力デバイスからの入力結果を、かかるＯＳ間通信によって、対応するゲストＯＳのＧＵＩサーバに渡す。
【００４０】
しかしながら、このようなＧＵＩサーバによる解決方法には問題点がある。
【００４１】
第１の問題点は、全てのＯＳの全てのＧＵＩクライアントアプリケーションが別々に入出力処理を行うため、ＯＳ間に跨るコンテキストスイッチが多発する点である。
【００４２】
複数ＯＳ環境におけるＯＳ間に跨るコンテキストスイッチは、コンテキストの保存処理及び復元処理に時間がかかり、特に速度が重要なディスプレイへの出力処理の際には、大きなボトルネックとなってしまう。
【００４３】
また、携帯端末のような省電力処理が必須となる環境においては、電力消費の大きな要因ともなる。
【００４４】
第２の問題点は、各ＯＳのプラットフォームやアプリケーションに大きく依存する点である。
【００４５】
このようなＧＵＩサーバ間の入出力を実現するためには、ホストＯＳのＧＵＩサーバ及びゲストＯＳのＧＵＩサーバの双方が、当該機能に対応する必要がある。
【００４６】
また、特に、ＧＵＩサーバが動作する環境が著しく異なる場合には、ＧＵＩサーバ間で通信する際に、アプリケーションレベルでのデータの変換が必要となる。
【００４７】
第３の問題点は、ＧＵＩサーバに、全ての入出力処理を委ねることによるセキュリティ上の危険性である。
【００４８】
ＧＵＩサーバは、「非特権プロセス（ユーザ権限）」であるため、「特権プロセス（カーネル権限）」であるＯＳと比較して、耐タンパ性が弱い。
【００４９】
ＧＵＩサーバが、改ざんされた場合、ＯＳの入出力を適切に処理できなくなり、誤った入力先へ入力結果が渡されたり、表示されてはならないＯＳの出力結果が表示されたりしてしまう可能性がある。
【００５０】
さらに、ＨＩＤを占有するＯＳの切り替えにおいて、ユーザビリティを向上するためには、いくつもの切り替えパターンを考え、各切り替えパターンについて、切り替え方法の提供や、不正な切り替え及びＨＩＤ占有の防止等を考慮しなければならない。
【００５１】
切り替えパターンとしては、例えば、以下のような例が考えられる。
【００５２】
・  特定ＯＳ上で特定プログラムが起動した場合
・  キーボード等に用意された切り替えボタンが押された場合
・  ＨＩＤを占有しているＯＳに異常が発生した場合
・  デバッグ等の目的で、外部から強制的に特定プログラムが起動された場合
また、ＯＳの切り替え時に考慮しなければならないこととしては、以下のような例が考えられる。
【００５３】
・  特定ＯＳや特定あるプログラムによる不正なHID占有の防止
・  ユーザビリティを損なうほどの、度重なる切り替えの防止
・  優先度の高いプログラムを利用している場合の、切り替えの防止
そこで、本発明は、以上の点に鑑みてなされたもので、効率性や、上位プラットフォームに依存しないことや、ユーザビリティを考慮した入出力制御装置、入出力制御システム及び入出力制御方法を提供することを目的とする。
【課題を解決するための手段】
【００５４】
本発明の第１の特徴は、複数のオペレーティングシステムの同時実行機能を備えるホストシステム上で、少なくとも２つ以上のオペレーティングシステムが同時に動作する計算機に配置される入力デバイス及び出力デバイスの入出力を制御する入出力制御装置であって、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを要旨とする。
【００５５】
本発明の第１の特徴において、前記要求受理部は、前記計算機により予め備えられている第１の入力デバイスを制御する第１の制御ソフトウェアからの切り替え要求を受理してもよい。
【００５６】
本発明の第１の特徴において、前記要求受理部は、オペレーティングシステムからの切り替え要求を受理してもよい。
【００５７】
本発明の第１の特徴において、前記切り替え要求に対する処理を規定する要求規則が与えられた場合に、前記要求受理部は、前記要求規則に基づいて前記切り替え要求を受理或いは非受理としてもよい。
【００５８】
本発明の第１の特徴において、前記要求規則は、前記切り替え要求の受理に秘密情報の入力を要求し、前記要求受理部は、前記秘密情報が正しい時のみ、前記切り替え要求を受理してもよい。
【００５９】
本発明の第１の特徴において、前記要求規則は、不正な切り替え要求を定義し、前記要求受理部は、前記切り替え要求が不正であった場合には、該切り替え要求を受理しなくてもよい。
【００６０】
本発明の第１の特徴において、前記要求規則は、前記切り替え要求の受理に、ユーザからの特定の動作によるユーザの許可/不許可の判定を必要とし、前記要求受理部は、前記特定の動作による許可を以って、前記切り替え要求を受理してもよい。
【００６１】
本発明の第１の特徴において、一定時間、前記特定の動作による許可/不許可のいずれの判定もユーザから得られなかった場合、前記要求受理部は、前記切り替え要求を受理してもよい。
【００６２】
本発明の第１の特徴において、前記要求規則は、特定の切り替え要求を特権要求とし、前記要求受理部は、前記特権要求による制御情報の生成後、特定の条件を満たすまでは、前記特権要求により特定のオペレーティングシステムに占有された入力デバイス或いは出力デバイスに対する切り替え要求を非受理としてもよい。
【００６３】
本発明の第１の特徴において、要求受理部は、前記ホストシステムからの切り替え要求を受理してもよい。
【００６４】
本発明の第１の特徴において、前記オペレーティングシステムは、前記要求規則により、前記切り替え要求が許可される場合に限り、前記切り替え要求を発行してもよい。
【００６５】
本発明の第１の特徴において、前記ホストシステムは、前記要求規則により、前記切り替え要求が許可される場合に限り、前記切り替え要求を発行してもよい。
【００６６】
本発明の第１の特徴において、前記計算機上の第１のオペレーティングシステム或いは前記ホストシステムが、前記計算機上で動作するオペレーティングシステムの特定の状態変化を検知する状態変化検知機能を備える場合に、前記要求受理部は、前記状態変化検知機能が、入力デバイス或いは出力デバイスを占有する第２のオペレーティングシステムの前記状態変化に応じて発行する切り替え要求を受理してもよい。
【００６７】
本発明の第２の特徴は、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、前記ホストシステム上で動作する前記複数のオペレーティングシステム中の特定の１つのオペレーティングシステムは、前記出力された入力先情報を以って、前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定し、該入力先オペレーティングシステムへ前記入力情報を入力する入力デバイス制御部と、前記出力された出力可否情報を以って、前記出力デバイスへ出力可能なオペレーティングシステムを特定し、該オペレーティングシステムから受け取った出力情報を前記出力デバイスへ出力する出力デバイス制御部とを備え、前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを要旨とする。
【００６８】
本発明の第２の特徴において、前記特定のオペレーティングシステムとは別の第１のオペレーティングシステムは、仮想入力デバイス制御部と、仮想出力デバイス制御部とを備え、前記仮想入力デバイス制御部は、前記特定のオペレーティングシステムの前記入力デバイス制御部より入力された入力情報を受け取り、前記第１のオペレーティングシステム上で動作するプログラムへ入力し、前記仮想出力デバイス制御部は、前記第１のオペレーティングシステム上で動作するプログラムからの出力情報について、前記出力可否情報を以って、前記第１のオペレーティングシステムが、前記出力デバイスに対して前記出力情報を出力可能か判断し、前記出力デバイスに対して前記出力情報を出力可能である場合に限り、前記出力情報を前記特定のオペレーティングシステムの前記出力デバイス制御部に対して出力してもよい。
【００６９】
本発明の第３の特徴は、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、前記ホストシステム上で動作する前記複数のオペレーティングシステムの各々は、前記入出力制御装置により出力された入力先情報を参照することで、前記入力デバイスからの入力情報を、前記オペレーティングシステムへ入力するか否かについて決定する入力デバイス制御部と、前記入出力制御装置により出力された出力可否情報を以って、前記オペレーティングシステムからの出力情報を出力するか否かについて決定する出力デバイス制御部とを備えることを要旨とする。
【００７０】
本発明の第４の特徴は、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、前記複数のオペレーティングシステムの各々は、前記入力デバイスを制御可能な入力デバイス制御部と、前記出力デバイスを制御可能な出力デバイス制御部とを備え、前記ホストシステムは、前記入出力制御装置により出力された入力先情報を以って、前記オペレーティングシステムの前記入力デバイス制御部を有効化或いは無効化し、前記入出力制御装置により出力された出力可否情報を以って、前記オペレーティングシステムの前記出力制御部を有効化或いは無効化する入出力制御部を備えることを要旨とする。
【００７１】
本発明の第５の特徴は、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、前記ホストシステムは、前記入力デバイスに対する割り込みが発生した場合に、前記割り込みを前記オペレーティングシステムへ通知する割り込み通知部を備え、前記割り込み通知部は、前記入出力制御装置が出力した入力先情報を以って、前記割り込みの通知先を特定することを要旨とする。
【００７２】
本発明の第６の特徴は、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能及び前記複数のオペレーティングシステム間における通信機能を含むホストシステムとを備える入出力制御システムであって、前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報及び前記出力可否情報を出力する制御情報出力部とを備え、前記ホストシステムは、前記入出力制御装置により出力された入力先情報或いは出力可否情報に応じて、前記オペレーティングシステムに対するＱｏＳ制御を行うＱｏＳ制御部を備えることを要旨とする。
【００７３】
本発明の第７の特徴は、複数のオペレーティングシステムの同時実行機能を備えるホストシステム上で、少なくとも２つ以上のオペレーティングシステムが同時に動作する計算機に配置される入力デバイス及び出力デバイスの入出力を制御する入出力制御方法であって、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理するステップと、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成するステップと、前記入力先情報及び前記出力可否情報を出力するステップとを備え、前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを要旨とする。
【００７４】
本発明の第８の特徴は、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能を含むホストシステムとを備える入出力制御システムであって、前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、前記オペレーティングシステム上で動作するプログラムは、前記入力先情報により、前記プログラムが動作するオペレーティングシステムが、前記入力デバイスからの入力先オペレーティングシステムである場合に限り、前記オペレーティングシステムに対して入力を要求するシステムコールを発行し、前記出力可否情報により、前記プログラムが動作するオペレーティングシステムが、前記出力デバイスに対して出力可能である場合に限り、前記オペレーティングシステムに対して出力を要求するシステムコールを発行し、前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを要旨とする。
【００７５】
本発明の第９の特徴は、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、前記入力デバイス及び前記出力デバイスの入出力を制御する入出力制御装置と、複数のオペレーティングシステムの同時実行機能を含むホストシステムとを備える入出力制御システムであって、前記入出力制御装置は、前記入力デバイス或いは前記出力デバイスを占有するオペレーティングシステムを切り替えるように要求する切り替え要求を受理する要求受理部と、前記切り替え要求に応じて、入力先情報或いは出力可否情報を含む制御情報を生成する制御情報生成部と、前記入力先情報或いは前記出力可否情報を出力する制御情報出力部とを備え、前記オペレーティングシステム上で動作するプログラムは、前記オペレーティングシステムに対して、前記入出力制御装置に対する切り替え要求の発行を要求し、前記入力先情報は、少なくとも前記入力デバイスからの入力情報の入力先オペレーティングシステムを特定するための情報を含み、前記出力可否情報は、少なくともオペレーティングシステムに対する前記出力デバイスへの出力可否を特定するための情報を含むことを要旨とする。
【００７６】
本発明の第９の特徴において、前記プログラムは、前記要求規則により、前記切り替え要求が許可される場合に限り、前記オペレーティングシステムに対して、前記入出力制御装置に対する切り替え要求の発行を要求してもよい。
【発明の効果】
【００７７】
以上説明したように、本発明によれば、効率性や、上位プラットフォームに依存しないことや、ユーザビリティを考慮した入出力制御装置、入出力制御システム及び入出力制御方法を提供することができる。
【発明を実施するための最良の形態】
【００７８】
次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。ただし、図面は、模式的なものであることに留意すべきである。
【００７９】
＜第１の実施の形態＞
（入出力制御システム）
図１は、第１の実施形態に係る入出力制御装置１００のシステム構成である。入出力制御装置１００は、例えば、複数ＯＳが、ＶＭＭ上で動作しており、当該複数ＯＳのうちの特定ＯＳが、任意の時点において特定デバイスを占有して利用するような場合に、当該特定デバイスを占有するＯＳの判定や切り替え等の処理を行う。
【００８０】
このような特定デバイスとしては、例えば、キーボード等の入力デバイス或いはディスプレイ等の出力デバイスに代表されるＨＩＤが挙げられる。
【００８１】
例えば、ユーザが、別のＯＳで動作するプログラムを利用する際に、予め計算機に用意されている切り替えボタンを押下した場合、入出力制御装置１００は、その旨を検知し、当該プログラムが動作するＯＳが入出力デバイスを占有するための制御情報を生成する。
【００８２】
具体的には、入出力制御装置１００は、入力デバイスからの入力情報の入力先ＯＳを特定する入力先情報２３０、及び、出力デバイスへ出力情報を出力可能なＯＳを特定する出力可否情報２４０を出力する。
【００８３】
入出力制御装置１００は、図１に示すように、要求受理部１１０と、制御情報生成部１２０と、制御情報出力部１３０とを備える。以下、各部の処理について述べる。
【００８４】
要求受理部１１０は、入出力デバイスを占有するＯＳを切り替えることを要求する切り替え要求２１０が、特定の要求元から発行された場合に、以下の処理を行うように構成されている。
【００８５】
１.  切り替え要求２１０の検知
要求受理部１１０は、特定の要求元から発行された切り替え要求２１０を検知する。
【００８６】
このような切り替え要求２１０が発行される要因として、例えば、外部入力２１１や、ＯＳ処理２１２や、ＶＭＭ処理２１３や、ＯＳ状態変化２１４が、挙げられる。
【００８７】
例えば、ユーザが、計算機に予め備えられている切り替えボタンを押した場合に、ハードウェア割り込みとして、「外部入力２１１」を要因とする切り替え要求２１１が発生する。
【００８８】
ハードウェア割り込みが発生した場合には、特許文献１の［０１３８］から始まる「Interrupt and Event Handling」の章等で記述されている従来のＶＭＭの動作に従い、当該切り替えボタンを制御するデバイスドライバによる制御が開始されるため、かかる切り替え要求２１０は、当該デバイスドライバによって発行される。
【００８９】
また、例えば、その時点で入出力デバイスを占有していないＯＳや、当該ＯＳ上で動作するプログラムが、入出力デバイスの占有を要求した場合に、当該ＯＳが、「ＯＳ処理２１２」を要因とする切り替え要求２１０を発行する。
【００９０】
ＶＭＭが、ＯＳ間のイベント等のＯＳより下の処理を検知することで、必要に応じて、入出力デバイスを占有するＯＳを切り替えるために、「ＶＭＭ処理２１３」を要因とする切り替え要求２１０は発行される。
【００９１】
例えば、特許文献１の［０１５９］から始まる「Debugging」の章で記述されているＶＭＭのＯＳデバッグ機能実行時に、ＶＭＭが、かかる切り替え要求２１０を発行する。 
入出力デバイスを占有するＯＳにおいて、特定の状態変化が起こった場合に、「ＯＳ状態変化２１４」を要因とする切り替え要求２１０は発生する。
【００９２】
特に、当該ＯＳや別のＯＳやＶＭＭ等が、状態変化検知機能を備える場合において、当該状態変化検知機能が、かかる切り替え要求２１０を発行する。
【００９３】
このような状態変化の一例としては、ＯＳの再起動やＯＳのフリーズが考えられる。
【００９４】
また、状態変化検知機能の一例は、特許文献１の［０１２２］から始まる「Hot Reboot of Ｓecondary Operating ＳyＳtem」の章で記述されている。
【００９５】
具体的に、各プログラムや各ＯＳやデバイスドライバやＶＭＭ等によって発行された切り替え要求２１０が、どのようにして要求受理部１１０へ通知されるかについては、デバイスドライバや入出力制御装置１００等の配置方法に依存する。
【００９６】
詳細については、第２〜第４の実施形態に記述するが、少なくとも、切り替え要求２１０は、要求元を特定可能な情報と、要求内容（例えば、どのＯＳが入出力デバイスを占有するための要求であるのか、或いは、どの入出力デバイスを占有するための要求であるのか等）とを含むものとする。
【００９７】
２.  切り替え要求２１０の受理/非受理
要求受理部１１０は、検知された全ての切り替え要求２１０を受理することはできない。
【００９８】
例えば、悪意のあるプログラムが、連続して切り替え要求２１０を発行し、要求受理部１１０が、かかる切り替え要求の全てを受理した場合、画面の切り替えが多発したり、特定ＯＳに入出力デバイスが長時間占有されたりすることで、ユーザビリティが著しく低下してしまう可能性があるためである。
【００９９】
要求受理部１１０は、検知した切り替え要求２１０を受理すべきか否かについて判定するための要求規則２５０が与えられた場合、当該要求規則２５０に従って、かかる切り替え要求２１０に対する受理判定を行う。
【０１００】
表１に、かかる要求規則２５０の一例を示す。
【０１０１】
表１の例では、信頼度の低い一般ＯＳ及び信頼度の高いセキュアＯＳが動作しており、一般ＯＳでは一般プログラムだけが動作しており、セキュアＯＳでは、一般プログラム及び特権プログラムが動作しているものとする。
【０１０２】
セキュアＯＳと一般ＯＳとの違いは、セキュアＯＳは、非常に強固なセキュリティが確保されており、一般ＯＳは、当該ＯＳや当該ＯＳ上で動作するプログラムに、不具合や悪意が存在する可能性があるというものである。
【表１】
2007220086.tif 000003
【０１０３】
要求受理部１１０は、常に無条件で、ＶＭＭからの切り替え要求２１０について受理するように構成されている。
【０１０４】
これは、ＶＭＭからの切り替え要求２１０が、上述したようなデバッグ機能の起動等に起因して発行されるクリティカルな要求であるためである。
【０１０５】
また、ＶＭＭは、セキュアＯＳと同様に、バグや脆弱性を含んでいないものと想定されるためである。
【０１０６】
同様に、要求受理部１１０は、セキュアＯＳの特権プログラムによって発行された切り替え要求２１０についても無条件で受理するように構成されている。
【０１０７】
特権プログラムとしては、例えば、システムの状態変化時に起動するプログラムが想定される。具体的には、特権プログラムの一例として、ハードウェアの故障をユーザに通知するプログラムや、バッテリー量の低下をユーザに通知するプログラムや、ウィルスの検知をユーザに通知するプログラム等が挙げられる。
【０１０８】
セキュアＯＳ自体は、安全性が保障されており、不必要な切り替えによるユーザビリティの低下を極力避けるように設計されているため、要求受理部１１０は、これらの重要な情報を通知するようなプログラムからの切り替え要求２１０については、無条件で受理するように構成されている。
【０１０９】
要求受理部１１０は、セキュアＯＳの一般プログラムによって発行された切り替え要求２１０については、ユーザによって許可された場合に限り、受理するように構成されている。
【０１１０】
例えば、セキュアＯＳ側のメーラが、メールを受信した場合に、その旨をユーザに通知するために切り替え要求２１０を発行する場合について考える。
【０１１１】
この時、ユーザは、一般ＯＳの特定プログラムを利用しているが、ＯＳを切り替えることにより、当該特定プログラムの利用が妨げられることを避けたいかもしれない。
【０１１２】
そこで、要求受理部１１０は、一旦、受信した切り替え要求２１０を保留し、一般ＯＳに対して、ユーザに対してＯＳの切り替えの可否について判断させるための通知を行う。
【０１１３】
具体的には、要求受理部１１０が、ユーザへの許諾を問う当該ＯＳ上に存在するユーザ許諾プログラムを起動させ、当該ユーザ許諾プログラムが、ユーザに対する上述の判断を問う。
【０１１４】
このような特定ＯＳとの通信には、特許文献１の［０１４９］から始まる「Inter-operating ＳyＳtem CommunicationＳ-Virtual buＳ」に記述されているＯＳ間通信機能等を利用する。
【０１１５】
もし、ユーザが、ＯＳの切り替えを許諾した場合には、要求受理部１１０は、保留していた切り替え要求２１０を受理する。
【０１１６】
また、ユーザが、ＯＳの切り替えを許諾しなかった場合には、要求受理部１１０は、保留していた切り替え要求２１０を受理しない。
【０１１７】
ここで、ユーザが、ＯＳの切り替えを許諾したか否かについての反応がなかった場合を考える。
【０１１８】
例えば、一般ＯＳ上で動作するユーザ許諾プログラムが、不具合により正常に動作しない場合等が考えられる。
【０１１９】
このような場合に対応するために、要求受理部１１０は、一定時間、切り替え要求２１０が保留された場合、かかる切り替え要求２１０を受理するように構成されていてもよい。これにより、保留されている切り替え要求２１０が蓄積されたままになることを防止することができる。
【０１２０】
要求受理部１１０は、一般ＯＳの一般プログラムにより発行された切り替え要求２１０については、基本的には、セキュアＯＳの一般プログラムと同等の判断を行う。
【０１２１】
すなわち、要求受理部１１０は、ユーザによってＯＳの切り替えが許諾された場合に、当該切り替え要求２１０を受理するように構成されている。
【０１２２】
ただし、一定時間、切り替え要求２１０が保留されている場合であっても、要求受理部１１０は、かかる切り替え要求２１０について受理しないように構成されている。
【０１２３】
セキュアＯＳ上のユーザ許諾プログラムは、不具合等によりフリーズすることはないため、ユーザが、計算機を利用している限り、基本的には、切り替え要求２１０が保留状態になることはない。
【０１２４】
また、一般ＯＳ上で動作する一般プログラムとしては、ユーザが勝手サイトからダウンロードしたようなプログラムも想定される。
【０１２５】
この場合、かかるプログラムが、不具合や悪意を持ち、不当な切り替え要求２１０を発行する場合も考えられる。
【０１２６】
例えば、かかるプログラムが、連続して切り替え要求２１０を発行したり、入出力デバイスを占有する必要がない場合であっても、切り替え要求２１０を発行したりするケースが想定される。
【０１２７】
ユーザは、ユーザ許諾プログラムによって、ＯＳの切り替えを拒否することが可能であるが、毎回、ＯＳの切り替えを許諾するか否かについて判断することは、ユーザビリティの低下を招く。
【０１２８】
以上のような不当な切り替え要求２１０を防止するため、ユーザ等が、予め不当な切り替え要求２１０と看做される条件について設定しておき、要求受理部１１０は、かかる条件に合致する切り替え要求２１０については自動的に非受理するように構成されていてもよい。
【０１２９】
要求受理部１１０は、例えば、一定時間内に一定回数以上の切り替え要求２１０を発行するようなプログラムからの切り替え要求２１０について非受理とするように構成されていてもよい。
【０１３０】
また、ユーザが、プログラムのインストール時に、当該プログラムにより発行される切り替え要求２１０を必ず非受理とするか否かについて設定可能とすることで、自動的に切り替え要求２１０を非受理とする条件を生成してもよい。
【０１３１】
この場合、プログラムのインストール中のユーザによる指定によって、一般ＯＳは、ＯＳ間通信機能等を利用して、当該プログラムからの切り替え要求２１０を非受理とするように要求規則２５０を書き換えることができる。
【０１３２】
切り替えボタンにより発行される切り替え要求２１０は、ユーザの意思による切り替え要求２１０であるため、要求受理部１１０は、基本的には、かかる切り替え要求２１０については受理するように構成されている。
【０１３３】
ただし、第３者によって、セキュアＯＳ上のプログラムを勝手に起動されることにより、システムの根幹に係る特権プログラムを起動される可能性もある。
【０１３４】
したがって、セキュアＯＳへの切り替えには、ユーザからのパスワード（秘密情報）の入力を促す。これにより、当該計算機の正規のユーザだけが、セキュアＯＳへの切り替えを行うことができる。
【０１３５】
なお、パスワードの入力を促すプログラムの呼び出し方法や取り扱い方法については、ユーザ許諾プログラムと同じものとする。
【０１３６】
また、要求規則２５０は、上述のように要求元によって規定される規則とは別に、要求される入出力デバイスを規定する場合もある。
【０１３７】
例えば、通常、標準入力であるキーボード及び標準出力であるディスプレイは、プログラムから同時に利用されるのが一般的である。
【０１３８】
したがって、例えば、要求規則２５０は、キーボードのみの占有を要求された場合には、かかる切り替え要求２１０について非受理としてもよい。
【０１３９】
これによって、特定プログラムが、キーボードを占有している状態で、ディスプレイの占有を要求し、同時に、別のプログラムが、ディスプレイを占有している状態で、キーボードの占有を要求するようなデッドロック状態を回避することが可能である。
【０１４０】
また、要求規則２５０は、ＶＭＭ及びセキュアＯＳの特権プログラムにより発行された切り替え要求２１０を、特権要求として扱ってもよい。
【０１４１】
特権要求とは、当該特権要求に従って入出力デバイスが特定ＯＳに占有された場合に、特定の条件を満たすまでは、当該入出力デバイスを別のＯＳが占有するための切り替え要求２１０が無条件で非受理とされるように規定されている切り替え要求である。
【０１４２】
例えば、セキュアＯＳの特権プログラムであるウィルス検知ソフトが、入出力デバイスを占有している場合、当該特権プログラムが、明示的に、当該入出力デバイスを開放するまでは、当該入出力デバイスを占有するために一般プログラムにより発行された切り替え要求２１０は、無条件で非受理とされる。
【０１４３】
なお、明示的な開放の通知は、ＯＳ間通信機能等といった切り替え要求２１０の通知と同様の仕組みで実現される。
【０１４４】
また、上述のＶＭＭやＯＳやプログラムが、予め要求規則２５０を参照することにより、切り替え要求２１０を発行してもよいかどうかについて判断してもよい。この結果、無駄な切り替え要求２１０の発行を制限することが可能となる。
【０１４５】
切り替え要求２１０の発行は、入出力制御装置１００が動作するＯＳやＶＭＭへのＯＳ間のスイッチが発生する。
【０１４６】
したがって、このように、切り替え要求２１０の発行前に、予め受理されるか否かについて判断することにより、無駄なＯＳ間のスイッチを削減可能であり、オーバヘッドを軽減することが可能となる。
【０１４７】
ただし、上述の一般プログラムは、非受理になると分かっていても切り替え要求２１０を発行することが考えられるため、要求受理部１１０は、切り替え要求２１０の発行元に応じて、要求規則２５０の再チェックが必要となる場合もある。
【０１４８】
３.  切り替え要求２１０の通知
要求受理部１１０は、受理した切り替え要求２１０を、制御情報生成部１２０に通知するように構成されている。
【０１４９】
制御情報生成部１２０は、要求受理部１１０によって受理された切り替え要求２１０に従って、制御情報１２１を生成するように構成されている。
【０１５０】
ここで、制御情報１２１は、現在、入出力デバイスを占有するＯＳが、どのＯＳであるかについて規定する状態情報である。
【０１５１】
制御情報生成部１２０は、入力として、少なくとも入出力デバイスリスト２２０を有する。
【０１５２】
制御情報１２１は、例えば、表２に示すように、入出力デバイスリスト２２０により指定された全てのデバイスについて、現時点で、どのＯＳが占有しているかについて規定する。
【０１５３】
切り替え要求２１０は、少なくとも制御情報を更新する入出力デバイスと、当該入出力デバイスを占有するＯＳとを指定するため、制御情報生成部１２０は、当該切り替え要求２１０に従って、当該制御情報１２１を生成することが可能となる。
【０１５４】
ここで、マスク状態は、上述したように、特権要求の発行により、制御情報１２１を変更するような切り替え要求２１０が無条件で非受理となる状態を表している。
【表２】
2007220086.tif 000004
【０１５５】
制御情報出力部１３０は、生成された制御情報１２１を出力するように構成されている。
【０１５６】
具体的には、制御情報出力部１３０は、入力先ＯＳを特定するための入力先情報２３０、及び、ＯＳに対する出力可否を決定する出力可否情報２４０を、適切なコンポーネントへ出力する。
【０１５７】
出力先は、デバイスドライバや、ＶＭＭや、ウィンドウマネージャ（Ｗｉｎｄｏｗ  Ｍａｎａｇｅｒ）等のＧＵＩサーバ用プログラム等が想定される。
【０１５８】
なお、制御情報出力部１３０の動作については、後述する。
【０１５９】
（入出力制御方法）
第１の実施の形態に係る入出力制御方法について、図２を用いて説明する。具体的には、複数ＯＳの同時実行機能を備えるホストシステム上で、少なくとも２つ以上のＯＳが同時に動作する計算機において、当該計算機が備える入力デバイス或いは出力デバイスの入出力を制御する方法について説明する。
【０１６０】
図２に示すように、ステップＳ１０１において、入出力制御装置１００は、入力デバイス或いは出力デバイスを占有するＯＳを切り替えるように要求する切り替え要求２１０を受理する。
【０１６１】
ここで、入出力制御装置１００は、計算機により予め具備されている第１の入力デバイスを制御する第１の制御ソフトウェア（デバイスドライバ）からの切り替え要求２１０を受理してもよく、ＯＳからの切り替え要求２１０を受理してもよく、或いは、ホストシステムからの切り替え要求２１０を受理してもよい。
【０１６２】
また、ステップＳ１０１において、切り替え要求２１０に対する処理を規定する要求規則２５０が与えられている場合には、入出力制御装置１００は、かかる要求規則２５０に基づいて、切り替え要求２１０についての受理又は非受理を決定する。
【０１６３】
さらに、要求規則２５０が、切り替え要求２１０の受理に際して秘密情報（パスワード）の入力を要求する場合、ステップＳ１０１において、入出力制御装置１００は、秘密情報が正しい時のみ、かかる切り替え要求２１０を受理する。
【０１６４】
或いは、要求規則２５０が、不正な切り替え要求を定義する場合、ステップＳ１０１において、入出力制御装置１００は、検知した切り替え要求２１０が不正であった場合には、当該切り替え要求２１０を受理しない。
【０１６５】
ここで、「不正な切り替え要求」とは、例えば、一定時間内の連続した切り替え要求２１０、或いは、切り替え要求２１０の発行が許可されないＯＳによって発行された切り替え要求２１０等が挙げられる。
【０１６６】
また、さらに、要求規則２５０が、切り替え要求２１０を受理する際に、ユーザからの特定の動作によるユーザの許可/不許可の判定を必要する場合、ステップＳ１０１において、入出力制御装置１００は、特定の動作による許可を以って、当該切り替え要求２１０を受理する。
【０１６７】
また、一定時間、特定の動作による許可/不許可についてのいずれの判定もユーザから得られなかった場合、ステップＳ１０１において、入出力制御装置１００は、かかる切り替え要求２１０を受理する。
【０１６８】
また、要求規則２５０が、特定の切り替え要求２１０を「特権要求」とする場合、ステップＳ１０１において、入出力制御装置１００は、当該特権要求による制御情報の生成後、特定の条件を満たすまでは、当該特権要求により特定ＯＳに占有された入力デバイス或いは出力デバイスに対する切り替え要求２１０を非受理とする。
【０１６９】
ここで、「特定の条件」とは、例えば、特権要求を発行したプログラムの処理が終了した場合等が挙げられる。
【０１７０】
また、計算機上の第１のＯＳ或いはホストシステムが、当該計算機上で動作するＯＳの特定の状態変化を検知する状態変化検知機能を備える場合に、ステップＳ１０１において、入出力制御装置１００は、入力デバイス或いは出力デバイスを占有する第２のＯＳの状態変化に応じて当該状態変化検知機能により発行された切り替え要求２１０を受理してもよい。
【０１７１】
ここで、「状態変化」とは、上述したように、例えば、フリーズや終了等による第２のＯＳの正常動作が不可能な状態への変化である。
【０１７２】
ステップＳ１０２において、入出力制御装置１００は、切り替え要求２１０に応じて、少なくとも入力デバイスからの入力先ＯＳを特定する情報を含む入力先情報２３０、或いは、少なくともＯＳに対する出力デバイスへの出力可否を特定する情報を含む出力可否情報２４０を生成する。
【０１７３】
ステップＳ１０３において、入出力制御装置１００は、入力先情報２３０及び出力可否情報２４０を適切なコンポーネントへ出力する。出力先は、デバイスドライバやＶＭＭやウィンドウマネージャ等のＧＵＩサーバプログラムである。
【０１７４】
（作用及び効果）
本実施形態によれば、様々な要因で発生する切り替え要求２１０に対して制御情報１２１を逐次生成していくことで、入出力デバイスを占有するＯＳを逐次切り替えることができる。
【０１７５】
この結果、任意のタイミングで行われる入出力について、入力デバイスからの入力情報を適切なＯＳへ入力し、出力情報のうち適切なＯＳからの出力情報だけを、出力デバイスへ出力することが可能となる。
【０１７６】
また、ＯＳの切り替え後は、占有ＯＳ以外からの入出力については処理しないため、ＯＳ間のコンテキストスイッチを減少させ、パフォーマンスを向上することが可能となる。
【０１７７】
さらに、入出力デバイスとＯＳと間のインタフェースの切り替えのみ行うため、上位アプリケーションに依存しないという利点もある。
【０１７８】
また、本実施形態によれば、入出力制御装置１００の要求受理部１１０が、計算機により予め具備されている第１の入力デバイスを制御する第１の制御ソフトウェア（デバイスドライバ）からの切り替え要求２１０を受理するように構成されているため、当該計算機に備えられた入力デバイスからの入力により制御情報１２１を生成することが可能となる。
【０１７９】
この結果、最も単純な例では、特殊な切り替えボタンが用意された計算機において、ユーザが当該切り替えボタンを押すことにより、ＯＳの切り替えが可能となる。ここで、キーボードの特定のボタンを、かかる切り替えボタンとして割り当てて使用してもよい。
【０１８０】
また、本実施形態によれば、入出力制御装置１００の要求受理部１１０が、ＯＳからの切り替え要求２１０を受理するように構成されているため、当該ＯＳの特定の処理に応じて制御情報１２１を生成することが可能となる。
【０１８１】
この結果、例えば、当該ＯＳ上で、特定のＧＵＩアプリケーションが起動した場合に、ＨＩＤの制御を、当該特定のＧＵＩアプリケーションに移動することが可能となる。
【０１８２】
また、本実施形態によれば、入出力制御装置１００の要求受理部１１０が、切り替え要求２１０に対する処理を規定する要求規則２５０が与えられた場合に、当該要求規則２５０に基づいて、当該切り替え要求２１０を受理するか否かについて判定するように構成されているため、様々な要因で発生する切り替え要求２１０について全て受理することによるユーザビリティの低下やセキュリティ上の危険性といった脅威を防止することができる。
【０１８３】
また、本実施形態によれば、入出力制御装置１００において、要求規則２５０が、切り替え要求２１０の受理に秘密情報（パスワード）の入力を要求し、要求受理部１１０が、当該秘密情報が正しい時のみ、当該切り替え要求を受理するように構成されているため、特定ＯＳへの切り替えをパスワード等により制限することができる。
【０１８４】
例えば、計算機の基本設定が可能なセキュアＯＳが用意されているような場合、当該計算機のユーザにより予め設定されているパスワードにより、第３者による当該セキュアＯＳへの切り替えを制限することが可能となる。
【０１８５】
また、本実施形態によれば、入出力制御装置１００において、要求規則２５０が、不正な切り替え要求を定義し、要求受理部１１０が、切り替え要求２１０が不正であった場合には、当該切り替え要求２１０を受理しないように構成されているため、不正な切り替え要求２１０を制限することができる。
【０１８６】
特に、不正なＯＳの誤動作や悪意のある動作による不正な切り替え要求２１０を制限し、特定ＯＳによるデバイスの占有や、度重なるＯＳの切り替えによるユーザビリティの低下を防止することが可能となる。
【０１８７】
また、本実施形態によれば、入出力制御装置１００において、要求規則２５０が、切り替え要求２１０の受理に、ユーザからの特定の動作によるユーザの許可/不許可の判定を必要とし、要求受理部１１０が、当該特定の動作による許可を以って、当該切り替え要求２１０を受理するように構成されているため、ユーザの許可/不許可の判定を以って、ＯＳの切り替えを行うことができる。
【０１８８】
この結果、ユーザが、特定アプリケーションを利用中に、ＯＳが突然切り替わることによるユーザビリティの低下を防止することが可能となる。
【０１８９】
ここで、ユーザから許可/不許可のいずれの判定も得られなかった場合、当該許可/不許可を問い合わせるプログラム部分に何らかの異常が発生している可能性がある。
【０１９０】
例えば、ＧＵＩアプリケーションが、フリーズしていたり、デバイス占有を目的としてユーザにわざと問い合わせなかったりしている可能性がある。
【０１９１】
したがって、本実施形態によれば、入出力制御装置１００において、一定時間、特定の動作による許可/不許可のいずれの判定もユーザから得られなかった場合、要求受理部１１０が、切り替え要求２１０を受理するように構成されているため、すなわち、当該許可/不許可の応答にタイムアウトを設けるように構成されているため、上述のような問題の発生を防止することが可能となる。
【０１９２】
また、本実施形態によれば、入出力制御装置１００において、要求規則２５０が、特定の切り替え要求２１０を特権要求とし、要求受理部１１０が、当該特権要求による制御情報１２１の生成後、特定の条件を満たすまでは、当該特権要求により特定ＯＳに占有された入力デバイス或いは出力デバイスに対する切り替え要求２１０を非受理とするように構成されているため、特定の切り替え要求２１０を特権要求と看做し、当該特権要求に応じて最優先で入出力デバイスを割り当てることができる。
【０１９３】
このような特権要求は、例えば、端末に対するセキュリティチェックやデバッグチェック等の強制的に起動する場合が考えられるプログラムの起動時に発生する。なお、かかる特権要求は、その後に発生する一般の切り替え要求２１０よりも優先され、処理が終わるまで、入出力デバイスの占有が解かれることはない。
【０１９４】
また、本実施形態によれば、入出力制御装置１００の要求受理部１１０が、ホストシステムからの切り替え要求２１０を受理するように構成されているため、ＶＭＭ等のホストシステムにより発行される切り替え要求２１０を受理することが可能となる。
【０１９５】
この結果、ＶＭＭにより制御される各ＯＳより下のレイヤの処理に起因して、制御情報１２１を生成することが可能となる。
【０１９６】
また、本実施形態によれば、入出力制御装置１００において、計算機上の第１のＯＳ或いはホストシステムが、当該計算機上で動作するＯＳの特定の状態変化を検知する状態変化検知機能を備える場合に、要求受理部１１０が、当該状態変化検知機能が、入力デバイス或いは出力デバイスを占有する第２のＯＳの状態変化に応じて発行される切り替え要求２１０を受理するように構成されているため、ＯＳやＶＭＭが、特定ＯＳの状態変化を検知した場合に、かかる状態変化に起因して制御情報１２１を生成することができる。
【０１９７】
このような状態変化としては、ＯＳの終了やＯＳのフリーズが考えられ、状態変化検知機構自体は、特許文献１に詳しい。この結果、正常動作を行っていないＯＳに、入出力デバイスが占有されることを防止することが可能となる。
【０１９８】
また、本実施形態によれば、ＯＳは、切り替え要求２１０を発行する前に、要求規則２５０を読み、当該切り替え要求２１０が入出力制御装置１００の要求受理部１１０により受理される場合に限り、当該切り替え要求２１０を発行するように構成されているため、当該切り替え要求２１０に係わるＯＳ間のスイッチの処理コストや、入出力制御装置１００が動作するＯＳやＮＭＭ等のホストシステムの処理コストを削減することが可能となる。
【０１９９】
また、本実施形態によれば、ホストシステムが、切り替え要求２１０を発行する前に、要求規則２５０を読み、当該切り替え要求２１０が入出力制御装置１００の要求受理部１１０により受理される場合に限り、当該切り替え要求２１０を発行するように構成されているため、当該切り替え要求２１０に係わるＯＳ間のスイッチの処理コストや、入出力制御装置１００が動作するＯＳやＶＭＭM等のホストシステムの処理コストを削減することが可能となる。
【０２００】
また、本実施形態によれば、入出力デバイスを占有していないＯＳ上で動作するプログラムが、ＯＳに対して切り替え要求２１０の発行を要求する前に、要求規則２５０を読み、当該切り替え要求２１０が入出力制御装置１００の要求受理部１００により受理される場合に限り、当該切り替え要求２１０を発行するように構成されているため、当該切り替え要求２１０に係わる当該ＯＳ上のプログラムと当該ＯＳと間でのコンテキストスイッチに係わる処理コストや、入出力制御装置１００が動作するＯＳやＶＭＭ等のホストシステムの処理コストを削減することが可能となる。
【０２０１】
＜第２の実施の形態＞
（入出力制御システム）
図３は、第２の実施形態に係る入出力制御装置１００を含んだ複数ＯＳ環境のシステム構成である。
【０２０２】
第２の実施形態に係る入出力制御システムは、ＯＳ３４０と、ＯＳ３５０と、当該ＯＳ３４０上で動作するプログラム３６０と、当該ＯＳ３５０上で動作するプログラム３７０と、入力デバイス３１０と、出力デバイス３２０と、ＶＭＭ３３０とを備える。
【０２０３】
また、ＯＳ３４０は、入出力制御装置１００と、出力デバイス３２０を制御可能な出力デバイス制御部３４２と、入力デバイス３１０を制御可能な入力デバイス制御部３４１とを備える。
【０２０４】
また、ＯＳ３５０は、仮想入力デバイス制御部３５１と、仮想出力デバイス制御部３５２とを備える。
【０２０５】
ここで、ＯＳ３４０は、例えば、第１の実施形態で述べたようなセキュアＯＳであり、ＯＳ３５０は、一般ＯＳであるものとする。
【０２０６】
入力デバイス制御部３４１及び出力デバイス制御部３４２は、デバイスを制御するデバイスドライバとしての機能を持ち、入出力制御装置１００と連携して動作するための拡張を施してあるものとする。
【０２０７】
また、仮想入力デバイス制御部３５１及び仮想出力デバイス制御部３５２は、ＯＳ３５０やプログラム３７０に対して、あたかもデバイスドライバであるかの如く振舞う。
【０２０８】
実際には、仮想入力デバイス制御部３５１は、入力デバイス制御部３４１とＯＳ３５０とのインタフェースであり、入力デバイス３１０とＯＳ３５０とのデータのやり取りを中継する。
【０２０９】
また、仮想出力デバイス制御部３５２は、出力デバイス制御部３４２とＯＳ３５０とのインタフェースであり、出力デバイス３２０とＯＳ３５０とのデータのやり取りを中継する。
【０２１０】
すなわち、仮想入力デバイス制御部３５１は、入力デバイス制御部３４１から渡された入力デバイス３１０からの入力情報をＯＳ３５０へ入力するように構成されている。
【０２１１】
また、仮想出力デバイス制御部３５２は、ＯＳ３５０からの出力情報を出力デバイス制御部３４２に渡すように構成されている。
【０２１２】
実際に、これらのＯＳ間を跨いだデータのやり取りは、ＶＭＭ３３０によって提供されるＯＳ間通信機能を利用して行われる。
【０２１３】
第２の実施形態では、まず、入力デバイス制御部３４１及び出力デバイス制御部３４２が、入力先情報２３０及び出力可否情報２４０を利用して、どのように動作するかについて述べる。
【０２１４】
入出力制御装置１００は、入力先情報２３０を入力デバイス制御部３４１へ出力し、出力可否情報２４０を出力デバイス制御部３４２へ出力する。
【０２１５】
入力デバイス制御部３４１は、外部から入力デバイス３１０へ入力情報が入力されることによって駆動する。
【０２１６】
入力についてのハードウェア割り込みが発生して、入力デバイス制御部３４１へ動作の制御が移るまでの過程は、ＶＭＭ３３０の動作に依存するが、一例は、特許文献１の［０１３８］から始まる「Interrupt and Event Handling」に詳しい。
【０２１７】
入力デバイス制御部３４１は、入力先情報２３０に基づき、どのＯＳが現在入力デバイス３１０を占有しているのか特定することができるため、当該ＯＳへ入力情報を入力する。
【０２１８】
例えば、ＯＳ３４０が入力デバイス３１０を占有している場合には、入力デバイス制御部３４１は、通常のデバイスドライバと同様の動作をし、ＯＳ３５０が入力デバイス３１０を占有している場合には、入力デバイス制御部３４１は、仮想入力デバイス制御部３５１へ入力情報を入力する。
【０２１９】
出力デバイス制御部３４２は、出力可否情報２４０により、現在、どのＯＳが出力デバイス３２０を占有しているのかについて特定することができる。
【０２２０】
ＯＳ３４０が出力デバイス３２０を占有している場合には、出力デバイス制御部３４２は、通常のデバイスドライバと同様の動作をする。
【０２２１】
また、ＯＳ３５０が出力デバイス３２０を占有している場合には、出力デバイス制御部３４２は、その旨をＯＳ３５０の仮想出力デバイス制御部３５２に通知し、仮想出力デバイス制御部３５２からＯＳ３５０の出力情報を受け取って出力デバイス３２０へ出力する。
【０２２２】
また，入出力制御装置１００は、入力先情報２３０或いは出力可否情報２４０を、それぞれ仮想入力デバイス制御部３５１或いは仮想出力デバイス制御部３５２へ出力してもよい。
【０２２３】
かかる場合、ＯＳ３５０が、入力デバイス３１０を占有している場合に限り、仮想入力デバイス制御部３５１は、入力デバイス制御部３４０から入力情報を受け取り、ＯＳ３５０が、出力デバイス３２０を占有している場合に限り、仮想出力デバイス制御部３５２は、出力情報を出力デバイス制御部３４２へ出力する。
【０２２４】
この結果、入力デバイス制御部３４１と仮想入力デバイス制御部３５１との間で、或いは、出力デバイス制御部３４２と仮想出力デバイス制御部３５２との間で、無駄なＯＳ間通信が発生することを防止することが可能となる。
【０２２５】
次に、第２の実施形態に係る入出力制御システム構成において、どのようにして入出力デバイスの占有ＯＳを切り替えるように要求する切り替え要求２１０が発行されるかについて、図４に基づいて説明する。
【０２２６】
図４では、ＯＳ３５０が、仮想入出力制御装置３５１Ａを新たに備えるものとしている。第１の実施形態で述べた通り、切り替え要求２１０は、大きく分けて、外部入力２１１を要因とする切り替え要求と、ＯＳ処理２１２を要因とする切り替え要求と、ＶＭＭ処理２１３を要因とする切り替え要求と、ＯＳ状態変化２１４を要因とする切り替え要求とに分類される。
【０２２７】
例えば、ユーザが、計算機により予め備えられている切り替えボタンを押すことにより、外部入力２１１を要因とする切り替え要求２１０が発行され、占有ＯＳの切り替えが行われる。
【０２２８】
かかる場合、切り替えボタンが押されたことを、当該切り替えボタンを制御する切り替えボタン制御ドライバ３４３が検知し、その旨を入出力制御装置１００へ通知すればよい。
【０２２９】
かかる切り替えボタンと入力デバイスとが同一であった場合には、切り替えボタン制御ドライバ３４３は、入力された情報が、切り替え要求２１０に係るものであれば、当該切り替え要求２１０を発行し、そうでなければ、入力デバイス制御部３４１として動作する。
【０２３０】
ＯＳ処理２１２を要因とする切り替え要求２１０については、例えば、ＯＳにおいて、ＧＵＩを利用するプログラム３６０又は３７０によって発行される場合を考える。
【０２３１】
プログラム３６０が、当該切り替え要求２１０を発行する場合は、同じＯＳ内であるため、入出力制御装置１００に対してシステムコールを発行することで、当該切り替え要求２１０を発行する。
【０２３２】
例えば、ＵＮＩＸ（登録商標）系ＯＳを想定した場合には、予め入出力制御装置１００を、デバイスファイル（/dev/ioctrl等）として、ＯＳ３４０に対して抽象化しておき、プログラム３６０が、当該デバイスファイルに対するioctrlシステムコールを発行する。
【０２３３】
ioctrlシステムコールは、各デバイスファイルに対して独自のリクエストを送信することが可能であるため、実施形態１で述べたような切り替え要求２１０を生成して発行することができる。
【０２３４】
プログラム３７０は、入出力制御装置１００とは別のＯＳに存在するため直接システムコールを発行することができない。
【０２３５】
そこで、ＯＳ３５０に対して切り替え要求２１０を中継する仮想入出力制御装置３５１Ａを設け、仮想入出力制御装置３５１Ａが、ＯＳ間通信機能を利用することにより、当該切り替え要求２１０を入出力制御装置１００へ通知する。
【０２３６】
プログラム３７０と仮想入出力制御装置３５１との通信については、プログラム３６０と入出力制御装置１００と同様の手段で実現可能である。
【０２３７】
ＶＭＭ処理２１３を要因とする切り替え要求２１０を発行する際には、ＶＭＭ３３０よりsignal等の単純な通信手段を利用する。
【０２３８】
或いは、特許文献１の［００９５］より始まる「Handling Virtualized Processor Exceptions」の章で記述されているＶＭＭからＯＳへ発行される仮想例外を利用してもよい。
【０２３９】
ＶＭＭ３３０は、システムに１つしか存在しないため、このようなsignal等を固定的に定義しても構わない。
【０２４０】
入出力制御装置１００は、当該signalの発行元がＶＭＭ３３０であることを確認すればよい。
【０２４１】
ＯＳ状態変化を要因とする切り替え要求２１０については、状態変化検知機能が、特定ＯＳ或いはＶＭＭにある場合を想定する。この場合、上述したいずれかの手段で、切り替え要求２１０の通知を実現可能である。
【０２４２】
（作用及び効果）
本実施形態によれば、特定ＯＳ３４０が、入力デバイス３１０及び出力デバイス３２０を制御する手段（入力デバイス制御部３４１及び出力デバイス制御部３４２）を有することにより、全てのＯＳ３４０、３５０が、入力デバイス３１０及び出力デバイス３２０を共有することができる。
【０２４３】
また、本実施形態によれば、特定のＯＳ３４０のみが、安全に動作すれば、その他のＯＳ３５０の誤動作や悪意のある動作等により、入力デバイス３１０或いは出力デバイス３２０が不正に占有されることを防止することができる。
【０２４４】
また、本実施形態によれば、各ＯＳが備える仮想入力デバイス制御部３５１或いは仮想出力デバイス制御部３５２により、当該ＯＳが、入力デバイス３１０或いは出力デバイス３２０を占有している場合に限り、入力デバイス制御部３４１或いは出力デバイス制御部３４２との通信によるＯＳ間の通信が発生することとなり、無駄なＯＳ間通信を抑えることが可能となる。
【０２４５】
また、本実施形態によれば、入出力デバイスを占有していないＯＳ上で動作するプログラムが、当該ＯＳが切り替え要求２１０を発行するように要求することが可能となる。
【０２４６】
例えば、あるプログラムが、ディスプレイ上に画像や文字等の出力情報を出力する場合になって初めて、ＯＳに対して、切り替え要求２１０を発行するように要求する。
【０２４７】
かかる要求を受けて、当該ＯＳは、入出力制御装置１００に対して、当該切り替え要求２１０を発行する。
【０２４８】
この結果、当該プログラムの動作時であっても、入出力イベントが発生するぎりぎりまで、別のＯＳが、入出力デバイスを占有することが可能となる。
【０２４９】
（第３の実施の形態）
第３の実施形態では、各ＯＳが入出力デバイス制御部を備える場合について述べる。
【０２５０】
第３の実施形態に係る入出力制御システムは、図５に示すように、ＯＳ４４０と、ＯＳ４５０と、当該ＯＳ４４０上で動作するプログラム４６０と、当該ＯＳ４５０上で動作するプログラム４７０と、入力デバイス４１０と、出力デバイス４２０と、ＶＭＭ４３０とを備える。
【０２５１】
ＯＳ４４０は、入力デバイス制御部４４１と、出力デバイス制御部４４２とを備え、ＯＳ４５０は、入力デバイス制御部４５１と、出力デバイス制御部４５２とを備える。
【０２５２】
また、ＶＭＭ４３０は、入出力制御装置１００を備える。
【０２５３】
第３の実施形態では、全てのＯＳ４４０、４５０が、それぞれ入出力デバイスを制御する入力デバイス制御部４４１或いは出力デバイス制御部４４２を備える。
【０２５４】
このような構成をとることにより、第２の実施形態で述べたシステムと比較して、入出力に係るパフォーマンスが向上する。  具体的には、入出力の速度向上やリソース使用削減を見込むことができる。
【０２５５】
なぜなら、各デバイスドライバは、自分が属するＯＳ以外の別のＯＳについては気にする必要がなく、直接、入出力デバイスを制御することが可能となり、ＯＳ間のスイッチに係る処理を省くことができるためである。
【０２５６】
このようなシステム構成においては、複数ＯＳに属する入力デバイス制御部或いは出力デバイス制御部が、単一の入出力デバイスを同時に参照する、所謂、ハードウェアの競合状態を解決しなければならない。
【０２５７】
そのために、入出力制御装置１００は、制御情報１２１を生成した際に、全ての入力デバイス制御部４４１、４５１或いは出力デバイス制御部４４２、４５２に対して、入力先情報２３０或いは出力可否情報２４０を出力する。
【０２５８】
例えば、全てのＯＳ４４０、４５０が読み取り可能であり、ＶＭＭ４３０が読み書き可能な主記憶装置に対して、入力先情報２３０或いは出力可否情報２４０を出力するといった方法が考えられる。
【０２５９】
各入力デバイス制御部４４１、４５１或いは出力デバイス制御部４４２、４５２は、入力先情報２３０或いは出力可否情報２４０により、自分が属するＯＳ４４０、４５０が、入力デバイス４１０或いは出力デバイス４２０を占有しているか否かについて特定し、占有している場合に限り、当該入力デバイス４１０或いは出力デバイス４２０を制御する。
【０２６０】
入力デバイス制御部４４１は、第２の実施形態と同様に、入力デバイス４１０からのハードウェア割り込みの発生に応じて駆動される。
【０２６１】
特許文献１或いは非特許文献１で述べられたＶＭＭは、本システム構成のように、１つのＩＲＱ（Ｉｎｔｅｒｒｕｐｔ  ＲｅＱｕｅｓｔ）ラインに、複数ＯＳ上で操作する入力デバイス制御部が対応している場合、順次、それらの入力デバイス制御部を駆動し、呼び出された入力デバイス制御部が、入力デバイス４１０を参照するか否かについて判断可能としている。
【０２６２】
この仕組みを利用し、駆動された入力デバイス制御部４４１は、入力先情報２３０を以って、ＯＳ４４０が、入力デバイス４１０を占有していれば、対応するデバイスドライバとしての処理を駆動する。なお、入力デバイス制御部４５１も、同様の操作を行う。
【０２６３】
出力デバイス制御部４４２は、出力可否情報２４０により、ＯＳ４４０が出力デバイス４２０を占有していれば、ＯＳ４４０の出力情報を出力デバイス４２０へ出力する。なお、出力デバイス制御部４５２も、同様の操作を行う。
【０２６４】
各ＯＳが、入力デバイス制御部或いは出力デバイス制御部を備える場合の別の構成として、図６に示す構成も考えられる。図６に示す構成は、上述した図５に示す構成とほぼ同じであるが、ＶＭＭ４３０が、新たに入出力制御部４３１を備える。
【０２６５】
入出力制御部４３１は、signalや仮想例外等といった各ＯＳとの通信手段を持ち、それらの通信機能を以って、各ＯＳの入力デバイス制御部４４１、４５１或いは出力デバイス制御部４４２、４５２を有効化或いは無効化する。
【０２６６】
例えば、ＯＳ４４０或いは４５０が、Ｌｉｎｕｘであった場合、Ｌｉｎｕｘは、カーネル動作中に、動的にデバイスドライバの組み込み或いは取り外しを行うことが可能である。
【０２６７】
そこで、例えば、入出力制御装置１００により、ＯＳ４４０が、入力デバイス４１０を占有する場合に、入出力制御部４３１は、ＯＳ４４０の入力デバイス制御部４４１を有効化するように、ＯＳ４４０へ通知する。
【０２６８】
ＯＳ４４０は、かかる通知を受けて、入力デバイス制御部４４１をカーネルコードに組み込む。
【０２６９】
他のＯＳ４５０の入力デバイス制御部４５１或いは出力デバイス制御部４５１、４５２に対しても同様の処理を行う。
【０２７０】
また、さらに、別の構成例として、図７に示す構成も考えられる。図７に示す構成では、ＶＭＭ４３０が、新たに割り込み通知部４３２を備える。
【０２７１】
割り込み通知部４３２は、特許文献１或いは非特許文献１等で記述されているＶＭＭが一般的に備える割り込みハンドラを拡張したものである。
【０２７２】
一般的な割り込みハンドラは、ハードウェア割り込みが発生した際、その割り込み番号を以って、どのＯＳに対応するデバイスドライバが存在するかについて判断し、当該ＯＳに対して割り込みを通知する。
【０２７３】
ＩＲＱ番号に対応するデバイスが複数あり、当該デバイスを制御するデバイスドライバが複数ＯＳ間に分散していた場合には、当該割り込みハンドラは、順にＯＳに対して割り込み通知を行う。
【０２７４】
割り込み通知部４３２は、入力デバイス４１０からの割り込み要求の発生時に、入出力制御装置１００における入力先情報２３０を利用することにより、割り込みを通知するＯＳを特定する。
【０２７５】
すなわち、割り込み通知部４３２は、割り込み発生時点で、入力デバイス４１０を占有するＯＳを特定し、当該ＯＳに対して割り込みを通知する。
【０２７６】
次に、第３の実施形態に係るシステム構成において、どのようにして入出力デバイスを占有するＯＳを切り替えるように要求する切り替え要求２１０が発行されるかについて、図８に基づいて説明する。
【０２７７】
図８では、ＯＳ４４０、４５０が、新たに仮想入出力制御装置４４３、４５３を備え、ＯＳ４４０が、さらに切り替えボタン用のデバイスドライバである切り替えボタン制御ドライバ４４４を備える。
【０２７８】
プログラム４６０、４７０が、それぞれ仮想入出力制御装置４４３、４５３に対して切り替え要求２１０を発行する処理は、第２の実施形態において、プログラム３７０が、仮想入出力制御装置３５１に対して切り替え要求２１０を発行する処理と同様である。
【０２７９】
また、切り替えボタン制御ドライバ４４４が、仮想入出力制御装置４４３に対して切り替え要求２１０を発行する処理は、第２の実施形態において、切り替えボタン制御ドライバ３４３が、入出力制御装置１００に対して切り替え要求２１０を発行する処理と同様である。
【０２８０】
さらに、ＶＭＭのデバッグ機能４３３及び入出力制御装置１００は、ＶＭＭ４３０によって制御される同一メモリ空間内に存在するため、切り替え要求２１０の発行に際して、特別な機能を必要としない。
【０２８１】
仮想入出力制御装置４４３、４５３が、入出力制御装置１００に対して切り替え要求２１０を発行する際には、ＶＭＭ４３０が、ＯＳ４４０に対して提供するインタフェースである「hyper call」を利用する。
【０２８２】
hyper callについては、同名で、非特許文献１の３.１節に説明があり、「trap call」という名前で、特許文献１の［００６２］に説明がある。
【０２８３】
これらのＶＭＭ-ＯＳインタフェースは、従来技術では、システムコールと同様の使われ方をしている。すなわち、かかるＶＭＭ-ＯＳインタフェースは、ＶＭ上のＯＳの権限では処理できない特権命令をＶＭＭに依頼する際に発行する。
【０２８４】
本実施形態におけるhyper callは、これらの従来技術によって備えられるインタフェース機能を利用したものである。
【０２８５】
hyper callで実際に通知される情報については、第１の実施形態で述べた通りである。
【０２８６】
入出力制御装置１００は、受け取ったhyper callに対して、当該切り替え要求２１０が受理されれば、第１の実施形態で述べた通りの処理を行い、何らかの理由で、非受理となれば、当該ＯＳへエラーを返す。
【０２８７】
次に、ＶＭＭ４３０が、入出力制御装置１００と連動して動作するＱＯＳ制御部４３４を備える場合の動作例について、図９に基づいて述べる。
【０２８８】
ＱＯＳ制御部４３４は、例えば、特許文献１の［００９３］より始まるschedulerの章に記述されているようなＣＰＵスケジューラを拡張したものであり、各ＯＳに対して割り当てるハードウェア資源を、各ＯＳの処理の優先度に応じて決定するものである。
【０２８９】
例えば、ＣＰＵスケジューラは、各ＯＳの処理の優先度に応じて、ＣＰＵ制御を割り当てるために存在する。
【０２９０】
本実施形態のＱＯＳ制御部４３４は、入出力制御装置１００により出力された入力先情報２３０及び出力可否情報２４０に応じて、入力デバイス４１０或いは出力デバイス４２０を占有するＯＳに高い優先度を設定し、優先的にＣＰＵ等のハードウェア資源を割り当てる。
【０２９１】
この結果、例えば、ＨＩＤを占有し、実際にユーザが利用しているＯＳの処理が優先的に処理されることとなり、ユーザビリティが向上する。
【０２９２】
（作用及び効果）
本実施形態によれば、各ＯＳ４４０、４５０が、それぞれ入出力デバイスを制御可能な手段（入力デバイス制御部４４１、４５１及び出力デバイス制御部４４２、４５２）を有することにより、入出力制御装置１００によって入力可能と判定された場合のみ、入力デバイス制御部４４１、４５１が、入力デバイス４１０からの入力情報を当該ＯＳ４４０、４５０へ入力し、入出力制御装置１００によって出力可能と判定された場合のみ、出力デバイス制御部４４２、４５２が、出力デバイス４２０へ当該ＯＳ４４０、４５０からの出力情報を出力し、当該制御対象入出力デバイスの競合状態を防止することが可能となる。
【０２９３】
また、各ＯＳ４４０、４５０は、直接、入出力デバイスを制御可能となり、入出力時の速度が向上する。
【０２９４】
また、ＶＭＭ４３０は、入出力制御装置１００により出力された入力先情報２３０を以って、ＯＳ４４０、４５０の入力デバイス制御部４４１、４５１を有効化或いは無効化し、入出力制御装置１００により出力された出力可否情報２４０を以って、ＯＳ４４０、４５０の出力デバイス制御部４４２、４５２を有効化或いは無効化するように構成されている入出力制御部４３１を備える。
【０２９５】
この結果、各ＯＳ４４０、４５０が、それぞれ特定の入力デバイス４１０を制御可能な入力デバイス制御部４４１、４５１或いは出力デバイス４２０を制御可能な出力デバイス制御部４４２、４５２を備える場合でも、入出力制御装置１００によって入出力可能と判定されたＯＳのみが、入力デバイス４１０或いは出力デバイス４２０を占有することで、入力デバイス４１０或いは出力デバイス４２０の競合状態を防ぐことが可能となる。
【０２９６】
また、各ＯＳ４４０、４５０は、直接、入出力デバイスを制御可能となり、入出力時の速度が向上する。
【０２９７】
さらに、入力デバイス４１０或いは出力デバイス４２０の占有は、ホストシステムの許可によってのみ可能となるため、ＯＳの誤動作等による、入力デバイス４１０或いは出力デバイス４２０の不正な占有を防止することが可能となる。
【０２９８】
また、ＶＭＭ４３０は、入力デバイス４１０に対する割り込みが発生した場合に、当該割り込みをＯＳ４４０、４５０へ通知する割り込み通知部４３２を備え、割り込み通知部４３２は、入出力制御装置１００により出力された入力先情報を以って、当該割り込みの通知先を特定する。
【０２９９】
このため、入力デバイス４１０からの割り込みの発生時、ホストシステムが、入出力制御装置１００を利用して、当該割り込みを通知するＯＳを選択することができる。
【０３００】
この結果、各ＯＳ４４０、４５０は、直接、入力デバイス４１０を制御可能となり、入力時の速度が向上する。
【０３０１】
また、入力デバイス４１０からの入力情報は、確実に当該入力デバイス４１０を占有するＯＳへ入力するため、ＯＳの誤作動等による入力デバイス４１０の不正な利用を防止することが可能となる。
【０３０２】
また、ＶＭＭ４３０は、入出力制御装置１００により出力された入力先情報２３０或いは出力可否情報２４０に応じて、ＯＳに対するＱＯＳ制御を行うＱＯＳ制御部４３４を備える。
【０３０３】
このため、入出力制御装置１００により出力される入力先情報２３０或いは出力可否情報２４０により、ホストシステムが、各ＯＳに対するＱＯＳ制御を行うことができる。例えば、ＨＩＤを占有するＯＳの処理に、高いＣＰＵ優先度を割り当てる。
【０３０４】
この結果、ユーザが実際に操作しているプログラムに高いＣＰＵ優先度が割り当てられることとなり、ユーザビリティが向上する。
【０３０５】
（第４の実施の形態）
図１０は、第４の実施形態に係る入出力制御装置１００を含む複数ＯＳ環境のシステム構成である。
【０３０６】
第４の実施形態に係る入出力制御システムは、ＯＳ５４０と、ＯＳ５５０と、当該ＯＳ５４０上で動作するＧＵＩサーバ５６０と、当該ＯＳ５５０上で動作するＧＵＩサーバ５７０と、当該ＧＵＩサーバ５６０上で動作するＧＵＩクライアント５８０と、当該ＧＵＩサーバ５７０上で動作するＧＵＩクライアント５９０と、入力デバイス５１０と、出力デバイス５２０と、ＶＭＭ５３０とを備える。
【０３０７】
また、ＯＳ５４０は、入出力制御装置１００と、出力デバイス５２０を制御可能な出力デバイス制御部５４２と、入力デバイス５１０を制御可能な入力デバイス制御部５４１とを備える。
【０３０８】
ここで、第４の実施形態に係るシステム構成は、第２の実施形態で述べたシステム構成と同様であるため、両者の相違点について主として説明する。
【０３０９】
第４の実施形態に係るシステムでは、各ＯＳ５４０、５５０上に、ＧＵＩサーバ５６０、５７０並びにＧＵＩクライアント５８０、５９０が存在する。
【０３１０】
ＧＵＩサーバ５６０、５７０は、ウィンドウマネージャ相当のものであり、当該ＯＳ５４０、５５０上における全てのＧＵＩプログラムの入出力を一括して処理する。
【０３１１】
ＧＵＩクライアント５８０、５９０は、ＧＵＩサーバ５６０、５７０に入出力を託す任意のＧＵＩプログラムである。
【０３１２】
ＧＵＩサーバ５６０は、ＧＵＩクライアント５８０から受け取った入出力処理要求に従って、当該入出力を処理する。
【０３１３】
すなわち、ＧＵＩサーバ５６０は、ＧＵＩクライアント５８０へ入力デバイス５１０からの入力情報を入力し、ＧＵＩクライアント５８０からの出力情報を出力デバイス５２０へ出力するように構成されている。
【０３１４】
さらに、ＧＵＩサーバ５６０は、ＧＵＩサーバ５７０をＧＵＩクライアントとして、ＧＵＩクライアント５８０に対する処理と同様の処理を行うように構成されている。
【０３１５】
ＧＵＩサーバ５６０とＧＵＩサーバ５７０と間の通信は、ＶＭＭ５３０によって備えられているＯＳ間通信機能を以って実現される。
【０３１６】
ＧＵＩサーバ５７０は、ＧＵＩクライアント５９０から受け取った入出力要求に従って、当該入出力を処理する。
【０３１７】
すなわち、ＧＵＩサーバ５７０は、ＧＵＩクライアント５９０に対して、ＧＵＩサーバ５６０を介して入力デバイス５１０から受け取った入力情報を入力し、ＧＵＩクライアント５９０からの出力情報を、ＧＵＩサーバ５６０を介して出力デバイス５２０へ出力するように構成されている。
【０３１８】
ＧＵＩサーバ５６０は、さらに、入出力制御装置１００における入力先情報２３０或いは出力可否情報２４０を元に動作する。
【０３１９】
すなわち、これらの情報により、ＯＳ５４０が、入力デバイス５１０或いは出力デバイス５２０を占有する場合には、ＧＵＩサーバ５６０は、ＧＵＩクライアント５８０の入出力を処理する。
【０３２０】
また、ＯＳ５５０が、入力デバイス５１０或いは出力デバイス５２０を占有する場合には、ＧＵＩサーバ５６０は、その旨をＧＵＩサーバ５７０へ通知する。
【０３２１】
当該通知により、ＯＳ５５０が、入力デバイス５１０或いは出力デバイス５２０を占有することが判明した場合に限り、ＧＵＩサーバ５７０は、入出力処理をＯＳ５５０へ託す。
【０３２２】
逆に、ＯＳ５５０が、当該デバイスを占有しない場合には、ＧＵＩクライアント５９０の入出力を、ＯＳ５５０へ託さない。
【０３２３】
ＧＵＩサーバ５６０と入出力制御装置１００との間の通信は、例えば、system callにより実現される。
【０３２４】
（第５の実施の形態）
図１１は、第５の実施形態に係る入出力制御装置１００を含んだ複数ＯＳ環境のシステム構成である。
【０３２５】
第５の実施形態に係る入出力制御システムは、第２の実施形態で示した入出力制御システムとほぼ同じ構成である。
【０３２６】
すなわち、ＯＳ６５０や、当該ＯＳ６５０上で動作するプログラム６７０は、仮想入力デバイス制御ソフトウェア６５１を通じて、制御対象の入力デバイス６１０からの入力情報を受け取り、仮想出力デバイス制御ソフトウェア６５２を通じて、出力デバイス制御ソフトウェア６４２へ出力情報を出力するように構成されている。
【０３２７】
本実施形態が、第２の実施形態と異なる部分は、プログラム６６０及びプログラム６７０である。以下、本実施形態に係るプログラム６６０及びプログラム６７０の動作について説明する。
【０３２８】
なお、以下、プログラム６６０を対象として説明をするが、プログラム６６０と入力デバイス制御ソフトウェア６４１との関係、或いは、プログラム６６０と出力デバイス制御ソフトウェア６４２との関係を、プログラム６７０と仮想入力デバイス制御ソフトウェア６５１との関係、或いは、プログラム６７０と仮想出力デバイス制御ソフトウェア６５２との関係に置き換えることで、プログラム６７０についても当てはまることを明記しておく。
【０３２９】
一般的な汎用ＯＳであるＬｉｎｕｘやＷｉｎｄｏｗｓ（登録商標）等は、プログラムからの要求を受け取り、ＯＳ権限でのみ可能な特権処理を実行するためのインタフェースを備える。このインタフェースに対して、プログラムは、システムコールを発行する。
【０３３０】
プログラム６６０が、入力デバイス制御ソフトウェア６４１や出力デバイス制御ソフトウェア６４２を介して、入力情報を受け取り、出力情報を出力するためには、それぞれ専用のシステムコールが必要となる。
【０３３１】
例えば、Ｌｉｎｕｘでは、入力情報を受け取るためのシステムコールは、readシステムコールに相当し、出力情報を出力するためのシステムコールは、writeシステムコールに相当する。
【０３３２】
これらのシステムコールの処理は、システムコールを発行したプログラムとＯＳとの間でのコンテキストスイッチを要するため、大きな処理コストが発生する。
【０３３３】
本実施形態では、プログラム６６０が、特別な処理を行うことにより、システムコールの発行回数を減らし、システム全体のオーバヘッドを削減することが可能となる。
【０３３４】
本実施形態における入出力制御装置１００は、制御情報１２１を、プログラム６６０が参照可能な領域に出力する。例えば、入出力制御装置１００は、制御情報１２１を、上述したようなＯＳ間通信時に利用される共有メモリへ出力する。
【０３３５】
この結果、プログラム６６０は、制御情報１２１を読むことが可能となり、制御情報１２１の内容に応じて、システムコールを発行するかどうかについて決定することができる。
【０３３６】
すなわち、制御情報１２１により、ＯＳ６４０が、制御対象である入力デバイス６１０或いは出力デバイス６２０を占有している場合に限り、プログラム６６０は、対応するシステムコールを発行する。
【０３３７】
この結果、システムコールを発行したとしても、占有権がないことから入出力デバイスに対する入出力が実行不可能な場合には、システムコールの発行を抑えることができ、オーバヘッドを削減可能となる。
【０３３８】
このようなシステムコールの発行の削減が可能なデバイスには、例えば、オーディオデバイスが挙げられる。
【０３３９】
通常は、オーディオデバイスへの出力は、プログラムからリアルタイムに発生すべきである。
【０３４０】
つまり、ある時点で、ＯＳが、オーディオデバイスを占有していなかったため、音楽データを出力できなかった場合、その音楽データを蓄積し、当該ＯＳが、当該オーディオデバイスを占有した際に出力するということは、通常利用時には考えにくい。
【０３４１】
したがって、音楽情報を出力するプログラム６６０は、ＯＳ６４０が、オーディオデバイスを占有していなかった場合には、出力するはずであった音楽情報を無視してしまって構わず、無駄なシステムコールを発行する必要はない。
【０３４２】
一方で、このようなシステムコールの発行の削減が不可能なデバイスには、ディスプレイが挙げられる。
【０３４３】
各ＯＳが持つディスプレイへの出力情報は、当該ＯＳがディスプレイを占有していようがいまいが、当該ＯＳのフレームバッファメモリへ蓄積・更新されていかなければならない。
【０３４４】
こうすることで、ディスプレイの占有権が切り替わった場合でも、ユーザは、その時点でのＯＳの状況をディスプレイから正確に把握することが可能となる。
【０３４５】
そのためには、当該ＯＳは、常に自フレームバッファメモリを更新していかなければならず、制御情報１２１の内容に関わらず、プログラム６６０から出力情報を受け取り続けなければならない。
【０３４６】
上述のように、制御情報１２１を参照して動作を変更するためには、プログラム６６０への改造を施せばよい。
【０３４７】
すなわち、プログラム６６０は、入出力が発生する部分のコードについて、制御情報１２１を参照するステップと、制御情報１２１の内容に応じて、システムコールを発行するか否かについて決定するステップを有すればよい。
【０３４８】
しかし、システムに応じて、プログラム６６０の内容を変更することは、プログラマにとって負担が大きく、また、プログラム６６０の変更無しに動作可能とするというＶＭＭの利点を消してしまう。
【０３４９】
さらに、上述したようなデバイスの違いによる改造の要不要をプログラマが判断するのは非常に難しい。
【０３５０】
本実施形態を実装する上での現実的な手段は、プログラム６６０を直接改造することではなく、プログラム６６０が入出力の際に呼び出すＡＰＩ６６１を改造することである。
【０３５１】
一般的に、プログラマは、システムコールを直接コードに組み込むことはせず、システムが用意したＡＰＩを呼び出すことで、間接的にシステムコールを発行するようにプログラムを作成する。
【０３５２】
ＡＰＩを利用することは、システムコールを直接呼び出すようなコードと比較して、プログラミングが容易となり、また利便性も向上する。
【０３５３】
また、このようなＡＰＩは、デバイス毎に用意されている。したがって、システムコールの発行の要不要の判断が必要なデバイスを呼び出すためのＡＰＩにのみ改造を施し、当該ＡＰＩが、制御情報１２１を参照するステップと、参照結果に応じて、システムコールの発行を行うか否かについて決定するステップと、当該決定に応じてシステムコールを発行するステップとを備えるようにすればよい。
【０３５４】
これにより、プログラム６６０の作成者は、本実施形態に関わる如何なる変更も必要なくなり、しかも、システムコールの発行回数を抑えられることで、システム全体のパフォーマンスが向上することとなる。
【０３５５】
（作用及び効果）
本実施形態によれば、ＯＳ６４０上で動作するプログラム６６０が、制御情報１２１を参照し、その時点で、当該ＯＳ６４０が、入力デバイス６１０或いは出力デバイス６２０を占有しているか否かについて判断し、占有している場合に限り、当該ＯＳに対して入出力に関わるシステムコールを発行することにより、無駄なシステムコールの発行に係る処理コストを削減することが可能となる。
【０３５６】
以上、上述の実施形態を用いて本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。従って、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【図面の簡単な説明】
【０３５７】
【図１】第１の実施形態に係る入出力制御システムの構成ブロック図である。
【図２】第１の実施形態に係る入出力制御方法を示すフローチャートである。
【図３】第２の実施形態に係る入出力制御システムの構成ブロック図である（その１）。
【図４】第２の実施形態に係る入出力制御システムの構成ブロック図である（その２）。
【図５】第３の実施形態に係る入出力制御システムの構成ブロック図である（その１）。
【図６】第３の実施形態に係る入出力制御システムの構成ブロック図である（その２）。
【図７】第３の実施形態に係る入出力制御システムの構成ブロック図である（その３）。
【図８】第３の実施形態に係る入出力制御システムの構成ブロック図である（その４）。
【図９】第３の実施形態に係る入出力制御システムの構成ブロック図である（その５）。
【図１０】第４の実施形態に係る入出力制御システムの構成ブロック図である。
【図１１】第５の実施形態に係る入出力制御システムの構成ブロック図である。
【図１２】従来の入出力制御システムの構成ブロック図である（その１）。
【図１３】従来の入出力制御システムの構成ブロック図である（その２）。
【符号の説明】
【０３５８】
１００…入出力制御装置
１１０…要求受理部
１２０…制御情報生成部
１２１…制御情報
１３０…制御情報出力部
２１０…切り替え要求
２１１…外部入力
２１２…ＯＳ処理
２１３…ＶＭＭ処理
２１４…ＯＳ状態変化
２２０…入出力デバイスリスト
２３０…入力先情報
２４０…出力可否情報
２５０…要求規則
３１０、４１０、５１０…入力デバイス
３２０、４２０、５２０…出力デバイス
３３０、４３０、５３０…ＶＭＭ
３３１、４３３…デバッグ機能
３４０、３５０、４４０、４５０、５４０、５５０…ＯＳ
３４１、４４１、４５１、５４１…入力デバイス制御部
３４２、４４２、４５２、５４２…出力デバイス制御部
３４３、４４４…切り替えボタン制御ドライバ
３５１Ａ、４４３、４５３…仮想入出力制御装置
３５１…仮想入力デバイス制御部
３５２…仮想出力デバイス制御部
３６０、３７０、４６０、４７０…プログラム
４３１…入出力制御部
４３２…割り込み通知部
４３４…ＱＯＳ制御部
５６０、５７０…ＧＵＩサーバ
５８０、５９０…ＧＵＩクライアント
【図１】
2007220086.tif 000005
【図２】
2007220086.tif 000006
【図３】
2007220086.tif 000007
【図４】
2007220086.tif 000008
【図５】
2007220086.tif 000009
【図６】
2007220086.tif 000010
【図７】
2007220086.tif 000011
【図８】
2007220086.tif 000012
【図９】
2007220086.tif 000013
【図１０】
2007220086.tif 000014
【図１１】
2007220086.tif 000015
【図１２】
2007220086.tif 000016
【図１３】
2007220086.tif 000017