(57)【特許請求の範囲】
【請求項１】
アプリケーションを動作させるオペレーティングシステムを含む上位側システムが動作する第１プロセッサと、
前記アプリケーションにより利用される機能プログラムを動作させるオペレーティングシステムを含む下位側システムであって、前記上位側システムからの通知が受取可能である一方、前記上位側システムに対して主体的に通知できない下位側システムが動作する第２プロセッサと、
を有し、
前記アプリケーションからの要求に応じて、前記上位側システムがデータを前記アプリケーションへ通知するための上位側通知機構と、前記機能プログラムがデータを前記下位側システムへ通知するための下位側通知機構と、を形成する手段と、
前記上位側システムが前記下位側システムにデータの通知指示を送ると共に、前記上位側システムを前記下位側システムからのデータの受信待ち状態にする通知指示手段と、
を有し、
前記下位側システムは、前記下位側通知機構を利用して前記機能プログラムにより出力されたデータを受け取ると、前記通知指示に応じて当該データを前記上位側システムへ返し、
前記上位側システムは、前記下位側システムから前記通知指示に応じて返されてきたデータを、前記上位側通知機構を利用して前記アプリケーションへ送り、
前記通知指示手段は、前記通知指示に応じてデータが前記下位側システムから返されてくると、前記下位側システムにデータの通知指示を自動的に送る、
ことを特徴とする片方向オペレーティングシステム間通信システム。
【請求項２】
前記下位側通知機構は、前記機能プログラムにより出力されたデータを一時的に保持する機能を有することを特徴とする請求項１に記載の片方向オペレーティングシステム間通信システム。
【請求項３】
前記上位側通知機構及び前記下位側通知機構は、コールバック関数を用いて実現されることを特徴とする請求項１に記載の片方向オペレーティングシステム間通信システム。
【請求項４】
アプリケーションを動作させるオペレーティングシステムを含む上位側システムが動作する第１プロセッサと、前記アプリケーションにより利用される機能プログラムを動作させるオペレーティングシステムを含む下位側システムであって、前記上位側システムからの通知が受取可能である一方、前記上位側システムに対して主体的に通知できない下位側システムが動作する第２プロセッサと、を有するコンピュータを、
前記アプリケーションからの要求に応じて、前記上位側システムがデータを前記アプリケーションへ通知するための上位側通知機構と、前記機能プログラムがデータを前記下位側システムへ通知するための下位側通知機構と、を形成する手段、
前記上位側システムが前記下位側システムにデータの通知指示を送ると共に、前記上位側システムを前記下位側システムからのデータの受信待ち状態にする通知指示手段、
として機能させ、
前記下位側システムは、前記下位側通知機構を利用して前記機能プログラムにより出力されたデータを受け取ると、前記通知指示に応じて当該データを前記上位側システムへ返し、
前記上位側システムは、前記下位側システムから前記通知指示に応じて返されてきたデータを、前記上位側通知機構を利用して前記アプリケーションへ送り、
前記通知指示手段は、前記通知指示に応じてデータが前記下位側システムから返されてくると、前記下位側システムにデータの通知指示を自動的に送る、
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、片方向オペレーティングシステム間通信システム及びプログラムに関する。
【背景技術】
【０００２】
従来から、マルチプロセッサを有するシステム構成において、上位のオペレーティングシステム（以下、「ＯＳ」）の機能に対応する下位のＯＳの機能を切り替えて呼び出すことで１つの機能の動作を実現するＯＳ間通信システム、いわゆる上位から下位への片方向ＯＳ間通信システムが存在する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−３４５７６８号公報
【特許文献２】特開２００３−１２２７３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
片方向ＯＳ間通信システムにおいては、下位のＯＳ側で発生した非同期のイベントを主体的に動作して上位のＯＳへ通知することができない。
【０００５】
本発明は、既存の片方向ＯＳ間通信システムにハードウェア上の変更を加えることなく双方向ＯＳ間通信システムを実現することを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係る片方向オペレーティングシステム間通信システムは、アプリケーションを動作させるオペレーティングシステムを含む上位側システムが動作する第１プロセッサと、前記アプリケーションにより利用される機能プログラムを動作させるオペレーティングシステムを含む下位側システムであって、前記上位側システムからの通知が受取可能である一方、前記上位側システムに対して主体的に通知できない下位側システムが動作する第２プロセッサと、を有し、前記アプリケーションからの要求に応じて、前記上位側システムがデータを前記アプリケーションへ通知するための上位側通知機構と、前記機能プログラムがデータを前記下位側システムへ通知するための下位側通知機構と、を形成する手段と、前記上位側システムが前記下位側システムにデータの通知指示を送ると共に、前記上位側システムを前記下位側システムからのデータの受信待ち状態にする通知指示手段と、を有し、前記下位側システムは、前記下位側通知機構を利用して前記機能プログラムにより出力されたデータを受け取ると、前記通知指示に応じて当該データを前記上位側システムへ返し、前記上位側システムは、前記下位側システムから前記通知指示に応じて返されてきたデータを、前記上位側通知機構を利用して前記アプリケーションへ送り、
前記通知指示手段は、前記通知指示に応じてデータが前記下位側システムから返されてくると、前記下位側システムにデータの通知指示を自動的に送ることを特徴とする。
【０００８】
また、前記下位側通知機構は、前記機能プログラムにより出力されたデータを一時的に保持する機能を有することを特徴とする。
【０００９】
また、前記上位側通知機構及び前記下位側通知機構は、コールバック関数を用いて実現されることを特徴とする。
【００１０】
本発明に係るプログラムは、アプリケーションを動作させるオペレーティングシステムを含む上位側システムが動作する第１プロセッサと、前記アプリケーションにより利用される機能プログラムを動作させるオペレーティングシステムを含む下位側システムであって、前記上位側システムからの通知が受取可能である一方、前記上位側システムに対して主体的に通知できない下位側システムが動作する第２プロセッサと、を有するコンピュータを、前記アプリケーションからの要求に応じて、前記上位側システムがデータを前記アプリケーションへ通知するための上位側通知機構と、前記機能プログラムがデータを前記下位側システムへ通知するための下位側通知機構と、を形成する手段、前記上位側システムが前記下位側システムにデータの通知指示を送ると共に、前記上位側システムを前記下位側システムからのデータの受信待ち状態にする通知指示手段、として機能させ、前記下位側システムは、前記下位側通知機構を利用して前記機能プログラムにより出力されたデータを受け取ると、前記通知指示に応じて当該データを前記上位側システムへ返し、前記上位側システムは、前記下位側システムから前記通知指示に応じて返されてきたデータを、前記上位側通知機構を利用して前記アプリケーションへ送り、前記通知指示手段は、前記通知指示に応じてデータが前記下位側システムから返されてくると、前記下位側システムにデータの通知指示を自動的に送ることを特徴とする。
【発明の効果】
【００１１】
請求項１に記載の発明によれば、既存の片方向ＯＳ間通信システムにハードウェア上の変更を加えることなく双方向ＯＳ間通信システムを実現することができる。また、データが連続して返されてくる場合にも対応することができる。
【００１３】
請求項２に記載の発明によれば、機能プログラムによりデータが連続して出力される場合にも取りこぼすことなく確実に受け取ることができる。
【００１４】
請求項３に記載の発明によれば、上位側システムと下位側システムとの間でやり取りされるデータの格納領域を削減することができる。
【００１５】
請求項４に記載の発明によれば、既存の片方向ＯＳ間通信システムにハードウェア上の変更を加えることなく双方向ＯＳ間通信システムを実現することができる。また、データが連続して返されてくる場合にも対応することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明に係る片方向ＯＳ間通信システムの一実施の形態を実現するハードウェアの要部及びソフトウェアの構成を示した概念図である。
【図２】本実施の形態において双方向ＯＳ間通信を実現する際のシーケンス図である。
【発明を実施するための形態】
【００１７】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００１８】
図１は、本発明に係る片方向ＯＳ間通信システムの一実施の形態を実現するハードウェアの要部及びソフトウェアの構成を示した概念図である。図１には、ハードウェア構成として、上位側のシステムが動作する第１プロセッサとしての上位ＣＰＵ１０と、下位側のシステムが動作する第２プロセッサとしての下位ＣＰＵ２０と、上位側システム及び下位側システムの双方からアクセス可能な共有メモリ４と、が搭載された基板２が示されている。なお、基板２を搭載するコンピュータは、その他にもＲＯＭ、共有されないＲＡＭ、ハードディスクドライブ（ＨＤＤ）、入力装置、表示装置、ネットワークやＦＡＸ等の装置を接続するインタフェースを有しているかもしれないが、本実施の形態の説明に用いないハードウェア構成については、図から省略している。なお、基板２を搭載するコンピュータは、ＦＡＸ機能、コピー機能、スキャナ機能等各種機能を搭載した画像形成装置に搭載されていてもよい。
【００１９】
また、図１には、ソフトウェア構成として、上位ＣＰＵ１０で動作するＯＳ（以下、「上位ＯＳ」）１１及び上位ＯＳ１１上で動作するアプリケーション（以下、「上位アプリ」）１２と、下位ＣＰＵ２０で動作するＯＳ（以下、「下位ＯＳ」）２１及び下位ＯＳ２１上で動作するアプリケーションのうち画像処理を行うアプリケーション（以下、「画像処理アプリ」）２２と、が示されている。本実施の形態における上位ＯＳ１１には、ライブラリ１３と、上位アプリ１２が使用する入力装置、出力装置等各種装置を動作させるデバイスドライバ（ＤＤ）１４と、が組み込まれているものとする。なお、「ライブラリ」とは、ある特定の機能を持ったプログラムを、他のプログラムから利用できるように部品化し、複数のプログラム部品を一つのファイルにまとめたもののことをいう。以上説明したライブラリ１３等を含む上位ＯＳ１１を、本実施の形態においては「上位側システム」とも称することにする。
【００２０】
本実施の形態における下位ＯＳ２１には、上位ＯＳ１１との通信を行うためのソフトウェアモジュールであるＯＳ間通信モジュール２３と、機能プログラムの一つとして、画像処理アプリ２２による画像の入出力に用いられる装置等各種装置を動作させるデバイスドライバ（ＤＤ）２４と、デバイスドライバ２４のうちＦＡＸ装置を動作させるＦＡＸデバイスドライバ２５と、が組み込まれているものとする。以上説明したＯＳ間通信モジュール２３等を含む下位ＯＳ２１を、本実施の形態においては「下位側システム」とも称することにする。下位側システムは、ハードウェア構成上、上位側システムからの通知を受け取ることが可能であり、また、その通知に応じて返答することは可能である。しかしながら、上位側システムに対して主体的に通知できない。このため、上位側システムから下位側システムへの片方向ＯＳ間通信システムが形成されることになる。
【００２１】
なお、本実施の形態においては、上位ＯＳ１１としてＬｉｎｕｘ（登録商標）、下位ＯＳ２１としてｖｘＷＯＲＫｓ（登録商標）をそれぞれ使用することを想定しているが、使用するＯＳはこれに限るものではない。
【００２２】
本実施の形態において特徴的なことは、前述した既存の片方向ＯＳ間通信システムにおいて、ハードウェア上の変更を加えることなく双方向ＯＳ間通信システムを実現することである。図２は、本実施の形態において上位アプリ１２、上位ＯＳ１１、ＯＳ間通信モジュール２３及びＦＡＸデバイスドライバ２５との間のやり取りを示すシーケンス図である。図２に示された各ソフトウェアの処理は、対応するＣＰＵ１０，２０との協調動作により実現される。以下、本実施の形態において既存の片方向ＯＳ間通信システムで双方向ＯＳ間通信システムを実現する方法について図２に示したシーケンス図を用いて説明する。本実施の形態では、上位アプリ１２が下位ＯＳ２１に搭載されたＦＡＸデバイスドライバ２５を利用したＦＡＸ機能を使用する場合を例にして説明する。
【００２３】
ステップ１００において、上位アプリ１２は、下位ＯＳ２１が提供するＦＡＸ機能を使いたいためにＦＡＸデバイスドライバ２５のＯＰＥＮ要求を発する。上位ＯＳ１１は、その要求を受け取ると下位ＯＳ２１へ送る。下位ＯＳ２１におけるＦＡＸデバイスドライバ２５は、その要求に応じてＯＫ（許可）を返信すると、上位アプリ１２は、その返信を、上位ＯＳ１１を介して受け取る。このようにして、上位アプリ１２は、ＦＡＸ機能を使用可能な状態になる。なお、以上のＦＡＸデバイスドライバ２５を使用可能とするための環境設定に関する処理は、従前と同じでよい。
【００２４】
ステップ１０１において、ＦＡＸデバイスドライバ２５が使用可能な状態になると、ＯＳ間通信モジュール２３は、イベント受信用のキューを作成する。
【００２５】
ステップ１０２において、上位アプリ１２は、ＦＡＸデバイスドライバ２５で発生した非同期イベントを受け取るためのコールバック関数の関数ポインタ（コールバック関数への参照情報）をライブラリ１３に通知する。
【００２６】
ステップ１０３において、ライブラリ１３は、上記通知を受けると、通知された関数ポインタをライブラリ内に保持した上で、ＯＳ間通信モジュール２３に対して、共有メモリ４を使用して非同期イベント登録コマンドを通知する。ライブラリ１３は、このようにして上位アプリ１２からの通知（要求）に応じて上位側システムがイベント通知パラメータを上位アプリ１２へ通知するための上位側通知機構を形成する。
【００２７】
ステップ１０４において、ＯＳ間通信モジュール２３は、非同期イベント登録コマンドを受け取ると、ＦＡＸデバイスドライバ２５で発生した非同期イベントを受信して下位側システムから上位側システムへ通知するためのコールバック関数を作成し、その関数ポインタ（コールバック関数への参照情報）をＦＡＸデバイスドライバ２５へ通知する。ＯＳ間通信モジュール２３は、このようにして上位アプリ１２からの通知（要求）に応じてライブラリ１３から通知されてきた非同期イベント登録コマンドに従い、ＦＡＸデバイスドライバ２５がイベント通知パラメータを下位側システムへ通知するための下位側通知機構を形成する。
【００２８】
ステップ１０５において、以上説明したコールバック関数のＦＡＸデバイスドライバ２５への登録が正常に終了すると、ＯＳ間通信モジュール２３は、非同期イベント登録コマンドに対する処理の結果として正常終了の旨を上位側システムに返す。
【００２９】
ステップ１０６において、ライブラリ１３は、その正常終了の通知を受けて正常終了の旨を上位アプリ１２に通知する。
【００３０】
本実施の形態においては、以上のようにして、ＦＡＸデバイスドライバ２５から非同期に通知されるイベントを、厳密にはイベントの発生によりＦＡＸデバイスドライバ２５から発せられるイベント通知パラメータを、ＯＳ間通信モジュール２３を介して上位側システムに通知できる仕組みを形成する。上位側及び下位側それぞれにコールバック関数を設定する一方、ＯＳ間を跨ぐ場合には互いのコールバック関数はアクセスできないため、本実施の形態におけるライブラリ１３は、上位アプリ１２から関数ポインタの通知を受けると、ＯＳ間通信モジュール２３に非同期イベント登録コマンドを通知する。ＯＳ間通信モジュール２３は、このコマンドに応じてコールバック関数を作成し、その関数ポインタをＦＡＸデバイスドライバへ通知することで登録させる。このように、本実施の形態では、上位側と下位側とにそれぞれコールバック関数を設定するようにした。
【００３１】
ステップ１０７において、上位アプリ１２は、ライブラリ１３に対して非同期イベント受信待ちコマンドを通知する。
【００３２】
ステップ１０８において、ライブラリ１３は、非同期イベント受信待ちコマンドの通知を受けると、ＯＳ間通信モジュール２３へ非同期イベント受信待ちコマンドを通知する。非同期イベント受信待ちコマンドは、非同期イベントが発生した場合には、そのイベントの発生を通知するように指示するためのコマンドであり、ライブラリ１３は、その通知指示に応じてＯＳ間通信モジュール２３からイベント通知パラメータが送られてくるまで受信待ち状態になる。より詳細には、非同期イベントの発生に応じてＯＳ間通信モジュール２３によってデータ（イベント通知パラメータ）が共有メモリ４の所定の領域に格納されるまでＲｅａｄ待ち状態に入ることを意味する。
【００３３】
なお、ライブラリ１３は、上位アプリ１２からの通知（ステップ１０７）に応じるのではなく、ステップ１０５における正常終了の旨を受けると、ＯＳ間通信モジュール２３へ非同期イベント受信待ちコマンドを自動的に通知するようにしてもよい。この場合、ステップ１０７における処理は不要となる。
【００３４】
ステップ１０９において、上位側システムが受信待ち状態のときに、ＦＡＸデバイスドライバ２５で非同期イベントが発生したとする。イベントとしては、例えば、省電力移行、省電力復帰、基板抜去等がある。イベント通知パラメータは、発生したイベントの内容種類を示すパラメータ値である。
【００３５】
ステップ１１０において、イベントが発生すると、ＦＡＸデバイスドライバ２５は、ステップ１０４においてＯＳ間通信モジュール２３から通知された関数ポインタにアクセスして（コールバック関数を呼び出して）、発生したイベントのイベント通知パラメータをＯＳ間通信モジュール２３へ送る。
【００３６】
ステップ１１１において、送られてきたイベント通知パラメータは、コールバック関数によりステップ１０１において作成されたキューに登録されることになる。イベント通知パラメータをキューによって一時保持するようにしたので、ＦＡＸデバイスドライバ２５からイベント通知パラメータが連続して送られてくる場合にも、取りこぼすことなく確実に受け取れる。ＯＳ間通信モジュール２３は、イベント通知パラメータがキューに登録されると、イベント通知パラメータ（非同期イベントデータ）を共有メモリ４の上記所定の格納領域に格納することによって通知する。つまり、ＯＳ間通信モジュール２３は、ライブラリ１３から通知された非同期イベント受信待ちコマンドに応じてイベント通知パラメータをライブラリ１３に返すことになる。
【００３７】
ステップ１１２において、受信待ち状態であったライブラリ１３は、イベント通知パラメータを受け取ると、ステップ１０２において上位アプリ１２から通知された関数ポインタにアクセスして（コールバック関数を呼び出して）、受信したイベントのイベント通知パラメータを上位アプリ１２へ送る。
【００３８】
本実施の形態においては、以上のようにして下位ＯＳ上で動作するＦＡＸデバイスドライバ２５で発生した非同期イベントを示すイベント通知パラメータを、上位ＯＳ１１上で動作する上位アプリ１２に通知する。
【００３９】
上位アプリ１２への通知後、ライブラリ１３は、ステップ１０８において説明したＯＳ間通信モジュール２３への非同期イベント受信待ちコマンドの通知を自動的に行うことで、イベント通知パラメータが連続して発生し、通知されてくる場合にも対応可能とする。その後、破線で囲んだステップ１２０を繰り返すことで、上位アプリ１２は、ＦＡＸデバイスドライバ２５から出力されるイベント通知パラメータを、来る返し取得することができる。
【００４０】
本実施の形態によれば、以上のようにして、上位ＯＳ１１から下位ＯＳ２１への片方向ＯＳ間通信システムであっても下位ＯＳ２１から上位ＯＳ１１への通信を可能とする双方向通信システムを実現できる。
【００４１】
なお、本実施の形態では、上位側システムがイベント通知パラメータを上位アプリ１２へ通知するための上位側通知機構と、ＦＡＸデバイスドライバ２５がイベント通知パラメータをＯＳ間通信モジュール２３へ通知するための下位側通知機構と、をコールバック関数を用いて実現するようにした。これにより、共有メモリ４において必要とする記憶領域を削減することができる。ただ、コールバック関数ではなく、他の手段、例えばキューにより上位側通知機構及び下位側通知機構を形成するようにしてもよい。
【００４２】
なお、本実施の形態では、主となる上位ＣＰＵ１０に対し、副となる下位ＣＰＵ２０をただ１つ含むマルチプロセッサにより片方向ＯＳ間通信システムが実現される場合を例にしたが、複数の下位ＣＰＵ２０を含むマルチプロセッサにより片方向ＯＳ間通信システムが実現される場合にも適用可能である。
【符号の説明】
【００４３】
４  共有メモリ、１０  上位ＣＰＵ、１１  上位ＯＳ、１２  上位アプリ、１３  ライブラリ、１４，２４       デバイスドライバ（ＤＤ）、２０  下位ＣＰＵ、２１  下位ＯＳ、２２  画像処理アプリ、２３  ＯＳ間通信モジュール、２５  ＦＡＸデバイスドライバ（ＤＤ）。
【図１】
0006617496.tif 000002
【図２】
0006617496.tif 000003