(57)【特許請求の範囲】
【請求項１】
コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、
前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、
前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、
前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、
前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、
前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部と
を備え、
前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされている
ことを特徴とするデバイス制御システム。
【請求項２】
前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、所定値を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、
前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、前記所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれる
ことを特徴とする請求項１に記載のデバイス制御システム。
【請求項３】
前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、
前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれる
ことを特徴とする請求項１に記載のデバイス制御システム。
【請求項４】
前記コンピュータは、Ｌｉｎｕｘ（登録商標）をオペレーティングシステムとして備える
ことを特徴とする請求項１〜請求項３のいずれか一項に記載のデバイス制御システム。
【請求項５】
前記デバイスは、ＵＳＢマスストレージデバイス、ＭＭＣ（Multi Media Card）デバイス、又はＳＤ（Secure Digital）メモリカードデバイスである
ことを特徴とする請求項１〜請求項４のいずれか一項に記載のデバイス制御システム。
【請求項６】
コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、
前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、
前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、
前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、
前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、
前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部と
を備えるデバイス制御システムが機能する前記コンピュータを、さらに、前記コンピュータ上のユーザ空間において作動するプロセスとして機能させるプログラムであって、
前記コンピュータを、
前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取る読取手段、
前記読取手段によって読み取った情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定する判定手段、及び
前記判定手段による判定結果を、前記コンピュータ上のユーザ空間において作動する他のプロセスへ提供する情報提供手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ上で機能して、当該コンピュータに接続されたデバイスを制御するデバイス制御システムと、そのデバイス制御システムの一部を構成するためのプログラムに関する。
【背景技術】
【０００２】
近年、ＵＳＢ（Universal Serial Bus）マスストレージデバイス、ＭＭＣ（Multi Media Card）デバイス、ＳＤ（Secure Digital）メモリカードデバイスなどが広く普及している。また、これらのデバイスを、Ｌｉｎｕｘ（登録商標）が搭載されたコンピュータで制御することも行われている。例えば、下記特許文献１には、ＵＳＢマスストレージデバイスをＬｉｎｕｘ（登録商標）搭載コンピュータで制御する技術が提案されている（例えば、特許文献１参照。）。
【０００３】
Ｌｉｎｕｘ（登録商標）が搭載されたコンピュータでは、ＵＳＢマスストレージデバイスを制御する際に、コンピュータ上のカーネル空間においてデバイスドライバやデーモンプロセスが協働して必要な処理を実行する仕組みになっている。ＵＳＢマスストレージデバイスの他、ＭＭＣデバイスやＳＤメモリカードデバイスを制御する場合も同様である。
【０００４】
以下、ＵＳＢマスストレージデバイスの場合を例に説明を続ける。コンピュータ上のユーザ空間において作動するアプリケーションソフトウェアが、ＵＳＢマスストレージデバイス上にあるファイルをオープンすると、その情報はファイルシステム経由でデバイスドライバへと伝達される。このとき、デバイスドライバでは、オープンされたファイルごとにハンドルが確保される。
【０００５】
そして、アプリケーションソフトウェアからリードコマンド又はライトコマンドが発行されると、それらのコマンドがファイルシステム経由でデバイスドライバへと伝達される。このとき、デバイスドライバに伝達されたコマンドは、ハンドルごとの固有データとして確保されるコマンドスタックに積まれることとなる。デバイスドライバは、コマンドスタックに積まれたコマンドを、ハンドルごとの固有データとして確保されるメッセージキューに移すことで、コマンドをデーモンプロセスへと伝達する。
【０００６】
デーモンプロセスは、デバイスドライバによって確保されたすべてのハンドルを対象に、それらすべてのハンドルに対応するメッセージキューの中に格納されたコマンドを、適当な順序で処理してゆく。その結果、それらのコマンドが、ＵＳＢプロトコルスタック等によって構成される通信用インターフェース部を介してＵＳＢマスストレージデバイスへと伝達されることになる。
【０００７】
このような制御が行われる際、デバイスドライバは、コマンドスタックに積まれたコマンドをメッセージキューに移した後、デーモンプロセスでの処理の完了を待たずに、呼び出し元のアプリケーションソフトウェアにリターンする。
【０００８】
そのため、デーモンプロセスによって実行される処理は、アプリケーションソフトウェア側から見て、デバイスドライバからの応答よりも遅延したタイミングで実行される遅延処理となる。
【０００９】
このような遅延処理が行われれば、デバイスドライバは、デーモンプロセスによって実行される実際の処理が完了するのを待つことなくアプリケーションに応答を返し、その後は、別の処理を実行可能ともなるので、デバイスドライバでの処理効率が向上する。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００４−２７２４９９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかし、アプリケーションソフトウェアが、連続的に複数の処理を実行した際に、先に実行した処理で上述のような遅延処理が生じていると、それに起因して後から実行する処理でエラーが発生することがある。例えば、アプリケーションソフトウェアが、先にストレージデバイスのフォーマット処理を実行し、引き続いてフォーマット後のファイルシステムのマウント処理を連続的に行うと、上述のような遅延処理に起因した問題を招くおそれがある。
【００１２】
より詳しく説明すると、フォーマット処理での遅延書き込みが完了する前に、マウント処理が実行されると、管理領域データの書き込みが完了していないにもかかわらず、マウント処理において管理領域データが読み出されてしまう可能性がある。この場合、マウント処理では、フォーマット不正のストレージデバイスと認識されてしまうおそれがある。
【００１３】
しかも、そのようなエラーが発生した直後に、フォーマット処理の遅延書き込みが完了して管理領域が正しい状態になると、フォーマット不正では無い状態に更新されてしまうので、エラーの発生原因を事後的に解析することがきわめて難しいという問題がある。
【００１４】
この他、例えば、アプリケーションソフトウェア側でコンピュータの電源を切る場合にも、ストレージデバイスへの遅延書き込みが完了する前に電源を切ってしまうと、遅延書込予定となっていたデータの損失を招くおそれがある。
【００１５】
こうした問題を解消するには、アプリケーションソフトウェアが、デーモンプロセスによる遅延処理の完了を確実に待ってから、次の処理要求をデバイスドライバやデーモンプロセスに伝達することが重要となる。
【００１６】
しかし、Ｌｉｎｕｘ（登録商標）が搭載されたコンピュータでは、アプリケーションソフトウェア側からデーモンプロセスによる遅延処理が完了したか否かを確認できるような手段が用意されていない、という問題がある。
【００１７】
そのため、現状では、アプリケーションソフトウェアによって上述のようなフォーマット処理やマウント処理、あるいは電源断処理を行うに当たっては、遅延書き込みの完了が期待できる程度まで十分に待ってから、次の処理を行ったり電源を切ったりする、といった対策を取らざるを得ないのが実情であった。
【００１８】
また、このような対策を取ることならできるものの、どの程度待てば遅延書き込みが完了するのかは、単なる経験則に基づく想定に過ぎず、何ら保証される時間が規定されているわけではないので、非常に不確実な対策にしかなり得ないという問題があった。
【００１９】
さらに、多くの場合は、ごく短時間（例えば１秒足らず）だけ待てば遅延書き込みが完了しており、遅延書き込みが完了するまでに長時間（例えば２０秒程度）を要するのは、ごくまれなケースに過ぎない。しかし、このようなまれなケースにも対処するためには、常に十分に長時間（例えば３０秒程度）が経過してからしか、次の処理を行ったり電源を切ったりすることができないため、非常に効率が悪いという問題もあった。
【００２０】
本発明は、上記のような問題を解決するためになされたものであり、その目的は、デバイスドライバがデーモンプロセス経由でデバイスを制御するデバイス制御システムにおいて、デーモンプロセスでの処理が完了したか否かをアプリケーションソフトウェア側からでも確実に検知可能とすることにある。
【課題を解決するための手段】
【００２１】
以下、本発明において採用した構成について説明する。
本発明のデバイス制御システムは、コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備え、前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされていることを特徴とする。
【００２２】
このようなデバイス制御システムによれば、デバイスドライバからデーモンプロセスへコマンドが伝達される際、その旨を示す情報が、デバイスドライバによって第一記憶手段に書き込まれる。また、デーモンプロセスから通信用インターフェース部を介してデバイスへのコマンドの伝送が完了した際、その旨を示す情報が、デーモンプロセスによって第二記憶手段に書き込まれる。さらに、コンピュータには、これら第一記憶手段及び第二記憶手段に記憶された情報を、コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部が設けられている。
【００２３】
そのため、コンピュータ上のユーザ空間において作動するプロセス（例えば、アプリケーションソフトウェアのプロセス）は、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取ることができ、それら読み取った情報に基づいて、デバイスへのコマンドの伝送が完了したか否かを判定できる。
【００２４】
具体的には、例えば、前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、所定値を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、前記所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれるように構成されているとよい。この場合、第一記憶手段及び第二記憶手段それぞれに記憶されたカウンタ値が一致していれば、遅延処理が完了していると判断できる。また、この場合、カウンタ値はコマンドの発行回数に応じた値となるので、コマンドの発行回数をユーザ空間において作動するプロセス（例えば、アプリケーションソフトウェアのプロセス）側で検証することもできる。
【００２５】
また、例えば、前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれるように構成されているとよい。この場合も、第一記憶手段及び第二記憶手段それぞれに記憶されたカウンタ値が一致していれば、遅延処理が完了していると判断できる。また、この場合、カウンタ値はリード又はライト対象となったブロック数又はセクタ数に応じた値となるので、そのようなブロック数又はセクタ数をユーザ空間において作動するプロセス（例えば、アプリケーションソフトウェアのプロセス）側で検証することもできる。
【００２６】
以上のようなデバイス制御システムは、デバイスドライバから発行されるコマンドが、いったんデーモンプロセスに伝達されて、そのデーモンプロセスにおいて遅延処理が行われることとなるコンピュータであれば採用できるが、そのようなコンピュータの代表例としては、Ｌｉｎｕｘ（登録商標）をオペレーティングシステムとして備えるコンピュータを挙げることができる。
【００２７】
また、デバイス制御システムによる制御対象デバイスの代表例としては、ＵＳＢマスストレージデバイス、ＭＭＣデバイス、又はＳＤメモリカードデバイスを挙げることができる。
【００２８】
さらに、本発明のプログラムは、コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備えるデバイス制御システムが機能する前記コンピュータを、さらに、前記コンピュータ上のユーザ空間において作動するプロセスとして機能させるプログラムであって、前記コンピュータを、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取る読取手段、前記読取手段によって読み取った情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定する判定手段、及び前記判定手段による判定結果を、前記コンピュータ上のユーザ空間において作動する他のプロセスへ提供する情報提供手段として機能させることを特徴とする。
【００２９】
このようなプログラムに基づいて、コンピュータを上記各手段として機能させるプロセスを作動させれば、当該プロセスが、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取り、読み取った情報に基づいてデバイスへのコマンドの伝送が完了したか否かを判定し、その判定結果を、コンピュータ上のユーザ空間において作動する他のプロセスへ提供する。
【００３０】
したがって、このような判定結果を得るための処理を、他のプロセスが自ら実行できる仕組みを備えていなくても、他のプロセスは、上記判定結果を提供するプロセスを起動させて、そのプロセスから提供される判定結果を受け取ることができる。
【００３１】
そして、他のプロセスでは、受け取った判定結果に基づいて、デバイスへのコマンドの伝送が完了したことを確認した後、引き続いて次の処理を実行できるので、デバイスへのコマンドの伝送が完了していないにもかかわらず、次の処理を実行してしまうのを未然に防止することができる。
【図面の簡単な説明】
【００３２】
【図１】コンピュータが備えるデバイス制御システムの構成を示すブロック図。
【図２】デバイスドライバにおけるコマンド実行処理のフローチャート。
【図３】デーモンプロセスにおける処理のフローチャート。
【図４】動作完了確認ツールにおける処理のフローチャート。
【図５】ディスクの再初期化処理のフローチャート。
【図６】ディスクの使用停止処理のフローチャート。
【図７】（ａ）はｆｌｕｓｈｄｅｖｉｃｅ処理のフローチャート、（ｂ）はディスクの使用再開処理のフローチャート、（ｃ）は電源断処理のフローチャート。
【図８】／ｐｒｏｃから取得する情報の一例を示す説明図。
【発明を実施するための形態】
【００３３】
次に、本発明の実施形態について一例を挙げて説明する。
［デバイス制御システムの構成］
以下に例示するデバイス制御システムは、図１に示すように、コンピュータ１上で機能して、このコンピュータ１に接続されたデバイス（例えば、ＵＳＢ−ＨＵＢ２を介して接続されたＵＳＢマスストレージデバイス３など）を制御するシステムである。ＵＳＢ−ＨＵＢ２には、ＵＳＢ規格に準拠した他のデバイスＤ１，Ｄ２なども接続可能となっている。
【００３４】
また、図１においては図示を省略してあるが、コンピュータ１には、ＵＳＢマスストレージデバイス３以外のストレージデバイス（例えば、ＭＭＣデバイスやＳＤメモリカードデバイスなど）も接続可能で、これらのストレージデバイスも、以下に説明するデバイス制御システムによって制御可能となっている。なお、以下の説明では、ＵＳＢマスストレージデバイス３、ＭＭＣデバイス、及びＳＤメモリカードデバイスなどを総称して、ＵＳＢマスストレージデバイス３等のデバイスという。
【００３５】
コンピュータ１は、ＯＳとしてＬｉｎｕｘ（登録商標）が搭載されたものであり、このＯＳの機能により、コンピュータ１上には、ＯＳによって管理されるカーネル空間及びユーザ空間が構成されている。これらのうち、ユーザ空間では、アプリケーションＡ１〜Ａ３、ｓｆｄｉｓｋ，ｍｋｆｓなどの特殊アプリケーションＡ４、動作完了確認ツールＡ５などが機能する。
【００３６】
また、カーネル空間では、デバイス制御システムに関連するソフトウェアとして、ファイルシステム１１、デバイスドライバ１３、デーモンプロセス１５、及びバスマネージャ１７などが機能する。この他、コンピュータ１は、デバイス制御システムに関連するハードウェアとして、Ｉ／Ｆハードウェア１９などを備えている。
【００３７】
ファイルシステム１１は、ＯＳの一部として提供されるシステムで、ストレージデバイスなどが備える記憶領域に格納されるデータをファイルとして管理するとともに、そのファイルに対するリードやライトを行うためのアプリケーションインターフェースを提供する。本実施形態において、ファイルシステム１１は、ＦＡＴやＸＦＳなどの規格に対応したものとされている。アプリケーションＡ１などは、ファイルシステム１１によって提供されるアプリケーションインターフェースを利用して、ＵＳＢマスストレージデバイス３等のデバイスに格納されたファイルにアクセスすることができる。
【００３８】
デバイスドライバ１３は、ＵＳＢマスストレージデバイス３等のデバイスを制御するために、ＯＳに組み込まれるソフトウェアである。アプリケーションＡ１などからＵＳＢマスストレージデバイス３等のデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合、そのコマンドはデバイスドライバ１３へと伝達される。
【００３９】
デバイスドライバ１３は、自身が制御対象としているデバイスに対応する記憶領域を確保し、その記憶領域にデバイス固有データ１３Ａを格納する。デバイス制御システムに関連するデータとしては、６個のカウンタ（ｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）が、デバイス固有データ１３Ａ内に確保される。なお、詳しくは後述するが、デバイスドライバ１３は、２個のカウンタ（ｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄｒｖｅｎｔ）を更新する。
【００４０】
また、デバイスドライバ１３は、ファイルやデバイスに対するオープンコマンドが伝達されると、それに対応付けてハンドルと呼ばれる記憶領域（図１ではハンドルＨ１，Ｈ２を例示。）を確保し、その記憶領域にハンドル固有データ（図１ではハンドル固有データ１３Ｂ，１３Ｃを例示。）を格納する。
【００４１】
アプリケーションＡ１などからファイルシステム１１に対してファイルのオープンコマンドが発行された場合、オープンされたファイルに対応するデバイスをオープンするコマンドは、ファイルシステム１１からデバイスドライバ１３へと伝達される。また、アプリケーションの中には、デバイスに対して直接オープンコマンドを発行する特殊アプリケーションＡ４（例えば、ｓｆｄｉｓｋ，ｍｋｆｓ。）などもあり、このような特殊アプリケーションＡ４からはデバイスドライバ１３へ直接コマンドが伝達される。
【００４２】
なお、図１では、図を簡潔にする都合上、単一のデバイスドライバ１３を図示してあるが、実際は、個々のデバイス（例えば、ＵＳＢマスストレージデバイス３、ＭＭＣデバイス、ＳＤメモリカードデバイスなど）それぞれに対応するデバイスドライバ１３がコンピュータ１上で機能する。
【００４３】
デーモンプロセス１５は、デバイスドライバ１３同様、ＯＳの一部を構成するソフトウェアであり、上述のコマンドがデバイスドライバ１３へと伝達された際には、さらにデバイスドライバ１３からコマンドが伝達される。なお、詳しくは後述するが、このデーモンプロセス１５は、上述のデバイス固有データ１３Ａ内にある４個のカウンタ（ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）を更新する。
【００４４】
図１では、図を簡潔にする都合上、３つのＵＳＢデバイスに対応するデーモンプロセスを図示してあるが、これも、実際は、個々のデバイス（例えば、ＵＳＢマスストレージデバイス３、ＭＭＣデバイス、ＳＤメモリカードデバイスなど）それぞれに対応するデーモンプロセスがコンピュータ１上で機能する。ただし、デバイスの種別によっては、デバイスドライバが直接デバイスに対してコマンドを発行するものもあり、この場合はデバイスドライバとデバイスとの間に介在するデーモンプロセスは存在しない。
【００４５】
バスマネージャ１７及びＩ／Ｆハードウェア１９は、デーモンプロセス１５とＵＳＢマスストレージデバイス３等のデバイスとの間に介在する通信用インターフェース部（本発明でいう通信用インターフェース部。）を構成している。デーモンプロセス１５へコマンドが伝達された際には、そのコマンドがバスマネージャ１７及びＩ／Ｆハードウェア１９を介してデーモンプロセス１５からＵＳＢマスストレージデバイス３等のデバイスへと伝送される。
【００４６】
さらに、このコンピュータ１においては、上述の６個のカウンタ（ｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）に格納された値を、ユーザ空間で作動するプロセスから読み取り可能とするため、／ｐｒｏｃバイパスを利用した情報公開用インターフェース部（本発明でいう情報公開用インターフェース部に相当。）を設けてある。
【００４７】
／ｐｒｏｃは、Ｌｉｎｕｘ（登録商標）において、ＯＳの管理下にあるリソース関連の情報（例えば、カーネル空間に確保された記憶領域に格納された値）を、ファイルと同様の手順で読み出し可能とするために用意された仮想的なファイルシステムである。
【００４８】
Ｌｉｎｕｘ（登録商標）において、ＵＳＢマスストレージデバイス３に対応する／ｐｒｏｃバイパスとしては、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／Ｎ”（ただし、Ｎは０，１，２…などの数字。）が標準で用意されているので、本実施形態では、これを流用して、上述の６個のカウンタ値を読み出し可能に構成した。また、ＭＭＣデバイスやＳＤメモリカードデバイス用の／ｐｒｏｃバイパスについては、ＯＳ標準での用意がないので、本実施形態では、“／ｐｒｏｃ／ｄｒｉｖｅｒ／ｂｉｌ−ｍｍｃ−ｉｎｆｏ”を新設して、上述の６個のカウンタ値を読み出し可能とした。
【００４９】
なお、このような／ｐｒｏｃバイパスは、本実施形態では、動作完了確認ツールＡ５によって利用される。動作完了確認ツールＡ５の詳細については後述する。
［デバイスドライバにおいて実行される処理］
次に、デバイスドライバ１３において実行される処理について、図２のフローチャートに基づいて説明する。図２に示すデバイスドライバコマンド実行処理は、ＯＳ経由でデバイスドライバ１３へと伝達されるコマンドを対象に、そのコマンドに応じてデバイスドライバ１３が実行する処理である。
【００５０】
デバイスドライバ１３へと伝達されるコマンドは、例えば、アプリケーションＡ１などのコマンド発行元プロセスが、ＯＳの提供するアプリケーションインターフェースを介してコマンドを発行したような場合に、デバイスドライバ１３へと伝達されるものである。このようなコマンドは、ＯＳがデバイスドライバ１３に対して伝達する汎用形式のコマンドとされており、後述するＳＣＳＩ形式のコマンドとは形式が異なるものである。以下の説明の中では、ＳＣＳＩ形式のコマンドについて言及する場合は、ＳＣＳＩコマンドと明記する。
【００５１】
図２に示す処理が実行されるタイミングは、多数のデバイスが並列処理できるようにするため、ＯＳによってコントロールされている。デバイスドライバ１３は、デバイスハンドルをパラメータとして受け取っており、指定されたハンドル内「コマンドスタック」内に１以上のコマンドが積まれた際に、１つのコマンドを対象に図２に示す処理が実行される。
【００５２】
図２に示す処理を開始すると、デバイスドライバ１３（正確には、デバイスドライバ１３としての処理を実行するコンピュータ１；以下、単にデバイスドライバ１３という。）は、指定されたハンドルの「コマンドスタック」から１コマンドを取り出す（Ｓ１０５）。
【００５３】
そして、デバイスドライバ１３は、コマンドを判別して（Ｓ１１０）、リードコマンドであった場合は（Ｓ１１０：リードコマンド）、リードの「ＳＣＳＩコマンド」を生成し（Ｓ１１５）、カウンタｓｄｒ＿ｄｒｖｅｎｔをインクリメントする（Ｓ１２０）。
【００５４】
なお、カウンタｓｄｒ＿ｄｒｖｅｎｔは、デバイスドライバ１３の作動開始時に初期化（ゼロクリア）されており、その後は、Ｓ１２０が実行されるたびにインクリメントされることになる。
【００５５】
一方、Ｓ１１０において、ライトコマンドであった場合（Ｓ１１０：ライトコマンド）、デバイスドライバ１３は、ライトの「ＳＣＳＩコマンド」を生成し（Ｓ１２５）、カウンタｓｄｗ＿ｄｒｖｅｎｔをインクリメントする（Ｓ１３０）。
【００５６】
なお、カウンタｓｄｗ＿ｄｒｖｅｎｔは、デバイスドライバ１３の作動開始時に初期化（ゼロクリア）されており、その後は、Ｓ１３０が実行されるたびにインクリメントされることになる。
【００５７】
こうしてＳ１２０又はＳ１３０を終えたら、デバイスドライバ１３は、生成した「ＳＣＳＩコマンド」をメッセージキューに積んで（Ｓ１３５）、図２に示すデバイスドライバコマンド実行処理を完了する。
【００５８】
なお、Ｓ１１０において、リード・ライト以外のコマンドであった場合（Ｓ１１０：リード・ライト以外）、デバイスドライバ１３は、リード・ライト以外のコマンドに対応するの処理を実行し（Ｓ１４０）、図２に示すデバイスドライバコマンド実行処理を完了する。ただし、Ｓ１４０は本発明の要部とは関連性が低い処理となるので、これ以上の説明については省略する。
【００５９】
以上説明したように、図２に示した処理では、Ｓ１３５においてＳＣＳＩコマンドがメッセージキューに積まれることとなるたびに、Ｓ１２０又はＳ１３０においてカウンタｓｄｒ＿ｄｒｖｅｎｔ又はカウンタｓｄｗ＿ｄｒｖｅｎｔがインクリメントされる。したがって、カウンタｓｄｒ＿ｄｒｖｅｎｔ及びカウンタｓｄｗ＿ｄｒｖｅｎｔには、デバイスドライバ１３におけるリード又はライトのＳＣＳＩコマンドの発行回数が蓄積・保持されることになる。
【００６０】
［デーモンプロセスにおいて実行される処理］
次に、デーモンプロセス１５において実行される処理について、図３のフローチャートに基づいて説明する。デーモンプロセス１５はデバイスドライバ１３によって起動され、その後は、対応するデバイスが停止されるまでコンピュータ１に常駐する。図３に示す処理は、デーモンプロセス１５が起動されたときに開始される。
【００６１】
なお、以下、ディスクデバイスｓｄａ（／ｄｅｖ／ｓｄａ）に対応するデーモンプロセス１５を例に挙げて説明を続けるが、ｓｄａは単なる一例として例示するものであり、他のデバイスであっても同様の処理となるのはもちろんである。
【００６２】
図３に示す処理を開始すると、デーモンプロセス１５（正確には、デーモンプロセス１５としての処理を実行するコンピュータ１；以下、単にデーモンプロセス１５という。）は、他のデバイスにも時間を与えるため、所定時間ウエイトする（Ｓ２０５）。そして、ディスクデバイスｓｄａが取り外されたか否かを判断し（Ｓ２１０）、ディスクデバイスｓｄａが取り外されている場合は（Ｓ２１０：はい）、デーモンプロセス１５による処理を終了する。
【００６３】
一方、Ｓ２１０において、ディスクデバイスｓｄａが取り外されていないと判断された場合（Ｓ２１０：いいえ）、デーモンプロセス１５は、デバイス固有データから最初のオープン中ハンドルを取得する（Ｓ２１５）。
【００６４】
そして、オープン中のハンドルが無い場合は（Ｓ２２０：はい）、Ｓ２０５へと戻る一方、オープン中のハンドルがある場合（Ｓ２２０：いいえ）、デーモンプロセス１５は、取得中ハンドルのメッセージキューから１メッセージを取り出す（Ｓ２２５）。
【００６５】
続いて、デーモンプロセス１５は、メッセージ内のＳＣＳＩコマンドの種別を判断し（Ｓ２３０）、ＳＣＳＩコマンドがリードであった場合（Ｓ２３０：リード）、カウンタｓｄｒ＿ｄａｅｅｎｔをインクリメントする（Ｓ２３５）。
【００６６】
なお、カウンタｓｄｒ＿ｄａｅｅｎｔは、デバイスドライバ１３の作動開始時にデバイス固有データ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２３５が実行されるたびにインクリメントされることになる。
【００６７】
その後、デーモンプロセス１５は、デバイスに対してＳＣＳＩコマンド（リード）を発行して完了を待つ（Ｓ２４０）。Ｓ２４０において、完了を待つ間は他のデバイスに時間を解放する。そして、デバイスからの完了応答が返されたら、カウンタｓｄｒ＿ｄａｅｄｏｎをインクリメントする（Ｓ２４５）。
【００６８】
なお、カウンタｓｄｒ＿ｄａｅｄｏｎは、デバイスドライバ１３の作動開始時にデバイス固有データ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２４５が実行されるたびにインクリメントされることになる。
【００６９】
一方、Ｓ２３０において、ＳＣＳＩコマンドがライトであった場合（Ｓ２３０：ライト）、デーモンプロセス１５は、カウンタｓｄｗ＿ｄａｅｅｎｔをインクリメントする（Ｓ２５０）。
【００７０】
なお、カウンタｓｄｗ＿ｄａｅｅｎｔは、デバイスドライバ１３の作動開始時にデバイス固有データ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２５０が実行されるたびにインクリメントされることになる。
【００７１】
その後、デーモンプロセス１５は、デバイスに対してＳＣＳＩコマンド（ライト）を発行し完了を待つ（Ｓ２５５）。Ｓ２５５において、完了を待つ間は他のデバイスに時間を解放する。デバイスからの完了応答が返されたら、カウンタｓｄｗ＿ｄａｅｄｏｎをインクリメントする（Ｓ２６０）。
【００７２】
なお、カウンタｓｄｗ＿ｄａｅｄｏｎは、デバイスドライバ１３の作動開始時にデバイス固有データ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２６０が実行されるたびにインクリメントされることになる。
【００７３】
さらに一方、Ｓ２３０において、ＳＣＳＩコマンドがリード・ライト以外であった場合（Ｓ２３０：リード  ライト  以外）、デーモンプロセス１５は、デバイスに対してＳＣＳＩコマンド（リード・ライト以外）を発行し完了を待つ（Ｓ２６５）。Ｓ２６５において、完了を待つ間は他のデバイスに時間を解放する。
【００７４】
このようにしてＳ２４５，Ｓ２６０，又はＳ２６５を終えたら、デーモンプロセス１５は、デバイス固有データから次のオープン中ハンドルを取得する（Ｓ２７０）。そして、オープン中のハンドルが無い場合は（Ｓ２７５：はい）、Ｓ２０５へと戻る一方、オープン中のハンドルがある場合は（Ｓ２７５：いいえ）、Ｓ２２５へと戻る。
【００７５】
以上説明したように、図３に示した処理では、Ｓ２４０又はＳ２５５においてデバイスに対してＳＣＳＩコマンドが発行されることとなるたびに、その発行前後双方のタイミングとなるＳ２３５及びＳ２４５、もしくはＳ２５０及びＳ２６０において、カウンタｓｄｒ＿ｄａｅｅｎｔ及びカウンタｓｄｒ＿ｄａｅｄｏｎ、もしくはカウンタｓｄｗ＿ｄａｅｅｎｔ及びカウンタｓｄｗ＿ｄａｅｄｏｎがインクリメントされる。
【００７６】
したがって、これらのカウンタｓｄｒ＿ｄａｅｅｎｔ、ｓｄｒ＿ｄａｅｄｏｎ、ｓｄｗ＿ｄａｅｅｎｔ、ｓｄｗ＿ｄａｅｄｏｎには、デーモンプロセス１５におけるリード又はライトのＳＣＳＩコマンドの発行回数が、発行直前及び発行後の待機完了直後双方のタイミングで蓄積・保持されることになる。
【００７７】
［動作完了確認ツールにおいて実行される処理］
次に、動作完了確認ツールＡ５において実行される処理について、図４のフローチャートに基づいて説明する。動作完了確認ツールＡ５は、コマンド発行元プロセスからデバイスドライバ１３へと伝達されるコマンドが、ＵＳＢマスストレージデバイス３等のデバイスへ実際に伝達されたかどうかをコマンド発行元プロセス側で確認可能とするためのツールである。
【００７８】
この動作完了確認ツールＡ５はコマンド発行元プロセス側で必要なときに任意に起動され、その際、図４に示す処理が実行されることになる。なお、以下の説明では、説明を簡便にするため、ＵＳＢマスストレージデバイス３がコンピュータ１においてディスクデバイス“ｓｄａ”として認識されている場合を例に挙げて説明する。
【００７９】
ただし、動作完了確認ツールＡ５は、“ｓｄａ”以外のディスクデバイス（例えば“ｓｄｂ”、“ｓｄｃ”…）を対象にして所期の処理を行うこともできる。また、ＵＳＢマスストレージデバイス３以外のデバイス（ＭＭＣデバイスやＳＤメモリカードデバイス）を対象にして所期の処理を行うこともできる。
【００８０】
ＵＳＢマスストレージデバイス３とＭＭＣデバイスやＳＤメモリカードデバイスとでは、具体的な処理内容に若干相違する部分もあるので、そのような相違点については、以下の説明の中で言及することにする。
【００８１】
図４に示す処理を開始すると、動作完了確認ツールＡ５（正確には、動作完了確認ツールＡ５としての処理を実行するコンピュータ１；以下、単に動作完了確認ツールＡ５という。）は、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”フォルダ内の最初のファイルを検索する（Ｓ３０５）。
【００８２】
コンピュータ１にＵＳＢデバイスが接続されている場合、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”フォルダには、０，１，２，…などの数字をファイル名とする仮想的なファイルが生成されるので、Ｓ３０５では、そのようなファイル名を検索する。なお、ＭＭＣデバイスやＳＤメモリカードデバイスを対象とする場合は、“／ｐｒｏｃ／ｄｒｉｖｅｒ”フォルダ内のファイル“ｂｉｌ−ｍｍｃ−ｉｎｆｏ”を検索する。
【００８３】
ここで、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”フォルダ内（ＭＭＣデバイスやＳＤメモリカードデバイスの場合は、“／ｐｒｏｃ／ｄｒｉｖｅｒ”フォルダ内）にファイルがない場合（Ｓ３１０：はい）、動作完了確認ツールＡ５は、図４に示す処理を終了する（ｓｄａが見つからないエラー終了）。
【００８４】
一方、Ｓ３１０において、ファイルがある場合（Ｓ３１０：いいえ）、動作完了確認ツールＡ５は、検索されたファイル名（例えば、０，１，２，…など）で情報取得を行う（Ｓ３１５）。Ｓ３１５において、ファイル“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／Ｎ”からデータをリードすると、図８（ａ）に示すような形式の情報を読み込むことができる。なお、ＭＭＣデバイスやＳＤメモリカードデバイスの場合は、ファイル“／ｐｒｏｃ／ｄｒｉｖｅｒ／ｂｉｌ−ｍｍｃ−ｉｎｆｏ”からデータをリードすると、図８（ｂ）に示すような形式の情報を読み込むことができる。
【００８５】
そこで、動作完了確認ツールＡ５は、読み込んだ情報中に含まれる“ＢＩＬ−ＳＤｘＲＷｃ：”の行からディスク名を取得する（Ｓ３２０）。図８（ａ）に例示する情報の場合、“ＢＩＬ−ＳＤｘＲＷｃ：”の行は、最下行（“＃”のみの行）の１行上にあり、この行には、ディスク名（図８（ａ）では“ｓｄａ”）と上述の６個のカウンタ（ｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）に格納された値が列挙されている。
【００８６】
Ｓ３２０では、このような形式の情報であるとの前提で、先頭に列挙されたディスク名を取得する。なお、ＭＭＣデバイスやＳＤメモリカードデバイスの場合、動作完了確認ツールＡ５は、Ｓ３２０において、読み込んだ情報中に含まれる“ＢＩＬ−ＭｍｃＲｄＷｒＣ：”の行からディスク名を取得する。
【００８７】
図８（ｂ）に例示する情報の場合、“ＢＩＬ−ＭｍｃＲｄＷｒＣ：”の行は、最下行（“＃”のみの行）の１行上にあり、この行には、ディスク名（図８（ｂ）では“０”）と上述の６個のカウンタ（ｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）に格納された値が列挙されている。この情報中、ディスク名の“０”は、その前にあるべき文字列“ｍｍｃｂｌｋ”が省略された形式になっているものなので、実際のディスク名は“ｍｍｃｂｌｋ０”となる。
【００８８】
こうしてディスク名を取得したら、本実施形態ではディスクデバイス“ｓｄａ”を対象とした処理を例示しているので、動作完了確認ツールＡ５は、ディスク名が“ｓｄａ”であるか否かを判断する（Ｓ３２５）。もちろん、ディスクデバイス“ｓｄｂ”を対象とするのであれば、Ｓ３２５では、Ｓ３２０で取得したディスク名が“ｓｄｂ”であるか否かを判断することとなる。また、ディスクデバイス“ｍｍｃｂｌｋ０”を対象とするのであれば、Ｓ３２５では、Ｓ３２０で取得したディスク名が“０”であるか否かを判断することとなる。
【００８９】
Ｓ３２５において、ディスク名が“ｓｄａ”でない場合（Ｓ３２５：いいえ）、動作完了確認ツールＡ５は、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”フォルダ内（ＭＭＣデバイスやＳＤメモリカードデバイスを対象とする場合は、“／ｐｒｏｃ／ｄｒｉｖｅｒ”フォルダ内）の次のファイルを検索する（Ｓ３３０）。そして、ファイルがもう無い場合は（Ｓ３３５：はい）、動作完了確認ツールＡ５は、図４に示す処理を終了する（ｓｄａが見つからないエラー終了）。
【００９０】
一方、ファイルがまだある場合は（Ｓ３３５：いいえ）、Ｓ３１５へと戻る。これにより、フォルダ内にファイルがあり、且つ、その中から検索したファイルが“ｓｄａ”に対応するものでない場合は、Ｓ３１５〜Ｓ３３５が繰り返されることとなる。
【００９１】
そして、そのようなＳ３１５〜Ｓ３３５を実行する中、Ｓ３２５において、ディスク名が“ｓｄａ”であった場合（Ｓ３２５：はい）、動作完了確認ツールＡ５では、“ｓｄａ”につながるｐｒｏｃバイパス“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／Ｎ”（ただし、Ｎ＝０，１，２，…）が見つかったことになる（Ｓ３４０）。
【００９２】
そこで、この場合、動作完了確認ツールＡ５は、タイムアウトのカウンタとして所定時間（例えば１分程度）を設定し（Ｓ３４５）、一定時間（例えば１００ｍｓ）が経過するのを待つ（Ｓ３５０）。その後、タイムアウトのカウンタを上記一定時間分（上記例では１００ｍｓ）減らして（Ｓ３５５）、タイムアウトか否かを判断する（Ｓ３６０）。ここで、タイムアウトであった場合（Ｓ３６０：はい）、動作完了確認ツールＡ５は、図４に示す処理を終了する（タイムアウトエラー終了）。
【００９３】
一方、Ｓ３６０において、タイムアウトではない場合（Ｓ３６０：いいえ）、動作完了確認ツールＡ５は、ファイル“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／Ｎ”（ただしＮ＝０，１，２，…）から情報取得を行う（Ｓ３６５）。
【００９４】
そして、動作完了確認ツールＡ５は、カウンタｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎの値が全て一致するか否かを判断する（Ｓ３７０）。ここで、カウンタｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎの値が全て一致するのは、Ｓ１１５〜Ｓ１２０、Ｓ２３５〜Ｓ２４５がすべて実行されている場合に該当する。
【００９５】
これは、デバイスドライバ１３で発行されたリードのＳＣＳＩコマンドが、デーモンプロセス１５でもＵＳＢマスストレージデバイス３等のデバイスへと発行され、その応答がデバイスからデーモンプロセス１５へすでに返っていることを意味する。逆に、デバイスドライバ１３で発行されたリードのＳＣＳＩコマンドが、デーモンプロセス１５ではまだＵＳＢマスストレージデバイス３等のデバイスへと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス１５からＵＳＢマスストレージデバイス３等のデバイスへコマンドが発行されたものの、その応答がデバイスからデーモンプロセス１５へまだ返っていない場合も、上記カウンタ値は一致しない。
【００９６】
そこで、Ｓ３７０において、カウンタｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎの値が一致しない場合は（Ｓ３７０：いいえ）、Ｓ３５０へと戻る。これにより、Ｓ３４５で設定した時間が経過するまでは、Ｓ３５０〜Ｓ３７０が繰り返されることになる。
【００９７】
一方、Ｓ３７０において、カウンタｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎの値が全て一致した場合（Ｓ３７０：はい）、動作完了確認ツールＡ５は、カウンタｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎが全て一致するか否かを判断する（Ｓ３７５）。ここで、カウンタｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎの値が全て一致するのは、Ｓ１２５〜Ｓ１３０、Ｓ２５０〜Ｓ２６０がすべて実行されている場合に該当する。
【００９８】
これは、デバイスドライバ１３で発行されたライトのＳＣＳＩコマンドが、デーモンプロセス１５でもＵＳＢマスストレージデバイス３等のデバイスへと発行され、その応答がデバイスからデーモンプロセス１５へすでに返っていることを意味する。逆に、デバイスドライバ１３で発行されたライトのＳＣＳＩコマンドが、デーモンプロセス１５ではまだＵＳＢマスストレージデバイス３等のデバイスへと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス１５からＵＳＢマスストレージデバイス３等のデバイスへコマンドが発行されたものの、その応答がデバイスからデーモンプロセス１５へまだ返っていない場合も、上記カウンタ値は一致しない。
【００９９】
そこで、Ｓ３７５において、カウンタｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎの値が一致しない場合は（Ｓ３７５：いいえ）、Ｓ３５０へと戻る。これにより、Ｓ３４５で設定した時間が経過するまでは、Ｓ３５０〜Ｓ３７５が繰り返されることになる。
【０１００】
したがって、リード又はライトいずれかのコマンドが完全にデバイスへと伝わらない限り、Ｓ３５０〜Ｓ３７５が繰り返され、その繰り返しの中でタイムアウトとなった場合には（Ｓ３６０：はい）、タイムアウトでエラー終了となるのである。
【０１０１】
一方、Ｓ３７０において、カウンタｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎの値が全て一致し（Ｓ３７０：はい）、且つＳ３７５において、カウンタｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎの値が全て一致した場合（Ｓ３７５：はい）、動作完了確認ツールＡ５は、図４に示す処理を正常終了する。
【０１０２】
以上説明したように、動作完了確認ツールＡ５は、リード及びライトのＳＣＳＩコマンドがデバイスドライバ１３からデーモンプロセス１５経由でＵＳＢマスストレージデバイス３等のデバイスへと伝達され、デバイスからの応答がデーモンプロセス１５へ返っている場合に正常終了する。また、リード及びライトのＳＣＳＩコマンドがデバイスドライバ１３から発行されたものの、タイムアウトを待つ間にデバイスからの応答がデーモンプロセス１５へ返る状態に至らなければエラー終了する。
【０１０３】
正常終了したかエラー終了したかを示す情報は、動作完了確認ツールＡ５を起動した上位プロセス（例えば、アプリケーションなど）へと返される。したがって、上位プロセスでは、動作完了確認ツールＡ５を利用して、ＵＳＢマスストレージデバイス３等のデバイスに対して発行したコマンドが、デバイスドライバ１３やデーモンプロセス１５において処理済みとなっているか否かを確認することができる。
【０１０４】
［アプリケーションにおいて実行される処理の例（その１）］
次に、上述のような動作完了確認ツールＡ５を利用するアプリケーションの一例を、図５〜図７のフローチャートに基づいて説明する。以下に説明するアプリケーションＡ１は、ディスクデバイス“ｓｄａ”の再初期化を行ってから、引き続いてパーティションの切り直しを行い、さらに引き続いてファイルシステム“ｓｄａ１”のマウントを行うものである。
【０１０５】
なお、以下の処理でも、説明を簡潔にするために、ディスクデバイス“ｓｄａ”，ファイルシステム“ｓｄａ１”，マウントポイント“／ｍｎｔ／ｕｓｂ１”などの具体例を挙げながら説明を行うが、これらの具体例に限られないのはもちろんである。例えば、ディスクデバイス“ｓｄｂ”や“ｍｍｃｂｌｋ０”を対象とすることも可能である。
【０１０６】
図５に示すディスクの再初期化処理を開始すると、アプリケーションＡ１（正確には、アプリケーションＡ１としての処理を実行するコンピュータ１；以下、単にアプリケーションＡ１という。）は、“／ｄｅｖ／ｓｄａ”を対象にしてディスク使用停止処理を実行する（Ｓ４０５）。このディスク使用停止処理は、詳しくは図６に示すような処理となる。
【０１０７】
すなわち、図６に示す処理では、まず、アプリケーションＡ１からの指令により、全アプリケーションでマウントポイント“／ｍｎｔ／ｕｓｂ１”以下の全てのオープン中のファイルをクローズする（Ｓ５０５）。なお、この例は、“／ｄｅｖ／ｓｄａ１”が“／ｍｎｔ／ｕｓｂ１”にマウント中であることを想定している例であり、マウントポイントの具体的パス名は任意である。
【０１０８】
続いて、アプリケーションＡ１は、ｓｙｎｃコマンドを実行して、ディスクキャッシュ１１Ａに保持されているデータをＵＳＢマスストレージデバイス３等のデバイスへ書き出す（Ｓ５１０）。そして、“／ｍｎｔ／ｕｓｂ１”をアンマウントして、“／ｄｅｖ／ｓｄａ１”のマウントを解除する（Ｓ５１５）。これにより、“／ｄｅｖ／ｓｄａ１”に対しては、少なくともファイルシステム１１経由でのアクセスが行われない状態になる。
【０１０９】
次に、アプリケーションＡ１は、ディスクデバイス“ｓｄａ”のｆｌｕｓｈｄｅｖｉｃｅ処理を行い、デバイスドライバ１３の動作完了待ちになる（Ｓ５２０）。このｆｌｕｓｈｄｅｖｉｃｅ処理は、デバイスドライバ１３が内部的に保持（キャッシュ）しているデータをデバイス側へ掃き出させるために行われる処理であり、Ｌｉｎｕｘ（登録商標）搭載コンピュータではすでに行われている周知の処理である。
【０１１０】
具体的には、ｆｌｕｓｈｄｅｖｉｃｅ処理は、図７（ａ）に示すような処理となり、アプリケーションＡ１は、“／ｄｅｖ／ｓｄａ”をオープンしてハンドルをファイルディスクリプタｆｄに格納し（Ｓ６０５）、システムコール“ｉｏｃｔｌ（ｆｄ，ＢＬＫＦＬＳＢＵＦ，０）”を実行する（Ｓ６１０）。
【０１１１】
これにより、デバイスドライバ１３は、コマンドスタック内に未処理のコマンドが残されていたとしても、それらをすべてメッセージキューへ積み、これにより、それらのデータをデーモンプロセス１５へ引き渡す準備を完了する。Ｓ６１０を終えたら、アプリケーションＡ１は、ｆｄのクローズ（“／ｄｅｖ／ｓｄａ”のクローズ）を行って（Ｓ６１５）、図７（ａ）に示すを完了する。
【０１１２】
さて、こうしてｆｌｕｓｈｄｅｖｉｃｅ処理を完了したら、再び図６に戻って、アプリケーションＡ１は、動作確認完了ツールＡ５を起動して“ｓｄａ”の動作完了待ちになる（Ｓ５２５）。先に説明した通り、動作確認完了ツールＡ５は、デーモンプロセス１５がデバイスからの応答を受け取ったことを検出したときに正常終了するので、Ｓ５２５では、デーモンプロセス１５の動作完了待ちを行うことになる。
【０１１３】
ここで、動作確認完了ツールＡ５が正常終了すれば、デーモンプロセス１５が保持していたデータすべてがデバイスに掃き出されたことを意味するので、これにて図６に示すディスクの使用停止処理を完了する。なお、動作確認完了ツールＡ５がエラー終了した場合は、エラーメッセージを表示して処理を中止するなどの対処を行えばよいが、この種のエラー処理自体は一般的なものなので、これ以上の詳細な説明は省略する。
【０１１４】
図６に示すディスクの使用停止処理を完了したら、図５のＳ４０５を終えたことになるので、続いて、アプリケーションＡ１は、“ｓｆｄｉｓｋ”コマンドを実行し、パーティションの切り直しを行う（Ｓ４１０）。そして、“ｓｄａ”のｆｌｕｓｈｄｅｖｉｃｅ処理を行って、デバイスドライバ１３の動作完了待ちになり（Ｓ４１５）、続いて、動作確認完了ツールＡ５で“ｓｄａ”の動作完了待ち、すなわち、デーモンプロセス１５の動作完了待ちになる（Ｓ４２０）。
【０１１５】
Ｓ４１５，Ｓ４２０は、先に説明したＳ５２０，Ｓ５２５と同等な処理であり、これらの処理により、デバイスドライバ１３の保持するデータ、デーモンプロセス１５の保持するデータが、それぞれデバイス側へ確実に掃き出されるのを待つことになる。そして、Ｓ４２０を終えたら、“ｓｆｄｉｓｋ”コマンドの実行に伴ってＵＳＢマスストレージデバイス３等のデバイスへ書き込まれるべきデータが、確実にデバイスに書き込まれたことになる。
【０１１６】
そこで、アプリケーションＡ１は、ｍｋｆｓコマンドを実行し、パーティションのフォーマットを行う（Ｓ４２５）。そして、“ｓｄａ”のｆｌｕｓｈｄｅｖｉｃｅ処理を行って、デバイスドライバ１３の動作完了待ちとなり（Ｓ４３０）、続いて、動作確認完了ツールＡ５で“ｓｄａ”の動作完了待ち、すなわち、デーモンプロセス１５の動作完了待ちになる（Ｓ４３５）。Ｓ４３０，Ｓ４３５も、先に説明したＳ５２０，Ｓ５２５，Ｓ４１５，Ｓ４２０と同等な主旨で実行する処理である。
【０１１７】
Ｓ４３５を終えたら、“ｍｋｆｓ”コマンドの実行に伴ってＵＳＢマスストレージデバイス３等のデバイスへ書き込まれるべきデータが、確実にデバイスに書き込まれたことになるので、アプリケーションＡ１は、ディスクデバイス“／ｄｅｖ／ｓｄａ”の使用再開処理を行う（Ｓ４４０）。
【０１１８】
なお、Ｓ４４０は、詳しくは図７（ｂ）に示すような処理となる。すなわち、アプリケーションＡ１は、“／ｄｅｖ／ｓｄａ１”を“／ｍｎｔ／ｕｓｂ１”にマウントする（Ｓ７０５）。なお、この例は、“／ｄｅｖ／ｓｄａ１”が“／ｍｎｔ／ｕｓｂ１”にマウントされることを想定している例であり、マウントポイントの具体的パス名は任意である。このようなマウントが行われると、以降は、全アプリケーションで“／ｍｎｔ／ｕｓｂ１”以下のファイルが使用可能になり（Ｓ７１０）、図７（ｂ）に示すディスクの使用再開処理が完了する。そして、図７（ｂ）に示すディスクの使用再開処理が完了すると、図５のＳ４４０が完了するので、これにて図５に示すディスクの再初期化処理すべてが完了する。
【０１１９】
以上説明したように、上記のようなアプリケーションＡ１では、“ｓｆｄｉｓｋ”の実行後、ｆｌｕｓｈｄｅｖｉｃｅ処理を行ってデバイスドライバ１３の管理下にあるデータをデーモンプロセス１５へと引き渡している。しかも、動作確認完了ツールＡ５でデーモンプロセス１５の管理下にあるデータが、すべてデバイスに書き込まれたことを確認してから、“ｍｋｆｓ”を実行している。
【０１２０】
したがって、このような確認をすることなく“ｓｆｄｉｓｋ”や“ｍｋｆｓ”を連続的に実行するものや、“ｓｆｄｉｓｋ”の実行後にｆｌｕｓｈｄｅｖｉｃｅ処理は行うものの、デーモンプロセス１５の動作状況を確認することなく“ｍｋｆｓ”を実行するものなどとは異なり、ディスク上に生じた不整合なデータが残っているうちに、新たなコマンドが実行されてしまうことがなく、また、それを防止するために、経験則に基づく不確実な様子見を過剰に長時間にわたって行う必要もない。
【０１２１】
［アプリケーションにおいて実行される処理の例（その２）］
次に、アプリケーションにおいて実行される処理について、上述の一例とは別の例を図７（ｃ）のフローチャートに基づいて説明する。以下に説明する例は、アプリケーションＡ２が、コンピュータ１の電源断を行うために実行する処理である。なお、図７（ｃ）に例示する処理は、ストレージデバイスとして“／ｄｅｖ／ｓｄａ”のみの場合を想定しているが、“／ｄｅｖ／ｓｄａ”以外が存在していてもよいのはもちろんである。
【０１２２】
図７（ｃ）に示す処理を開始すると、アプリケーションＡ２は、電源断前の各種処理を実行し（Ｓ８０５）、続いて、ディスク“／ｄｅｖ／ｓｄａ”について使用停止処理を実行する（Ｓ８１０）。
【０１２３】
Ｓ８１０は、すでに説明した図６に示す処理と同等な処理であり、この処理の中でＳ５２０，Ｓ５２５が実行されることで、デバイスドライバ１３の保持するデータ、デーモンプロセス１５の保持するデータが、それぞれデバイス側へ確実に掃き出されるのを待つことになる。
【０１２４】
そして、Ｓ８１０を終えたら、アプリケーションＡ２は、パワーコントロールが可能なハードウェアの場合は電源を切って（Ｓ８１５）、図７（ｃ）に示す電源断処理を完了する。なお、Ｓ８１５において、パワーコントロールが不可能な場合は、電源を切って良いことを表示して、図７（ｃ）に示す電源断処理を完了する。
【０１２５】
以上説明したような処理を行えば、Ｓ５２０，Ｓ５２５相当の処理を実行することなく電源断を行うものや、Ｓ５２０のｆｌｕｓｈｄｅｖｉｃｅ処理相当の処理は行うものの、Ｓ５２５相当のデーモンプロセス１５の動作完了待機を行うことなく電源断を行うものなどとは異なり、ディスクに書き込まれていないデータが残っているうちに、電源断が行われてしまうことがなく、また、それを防止するために、経験則に基づく不確実な様子見を過剰に長時間にわたって行う必要もない。
【０１２６】
［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【０１２７】
例えば、上記実施形態では、より詳細なデータの流れを把握、分析しやすくするために、６個のカウンタ（ｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）を用いたが、中間のタイミングで更新される２個のカウンタ（ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ）を設けるか否かは任意である。
【０１２８】
また、上記実施形態では、リード・ライト双方を監視するために、６個のカウンタ（ｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｒ＿ｄａｅｅｎｔ，ｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）を用いたが、ライトだけを監視してもよく、その場合は、３個のカウンタ（ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）もしくは２個のカウンタ（ｓｄｗ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄａｅｄｏｎ）を用いるだけでもよい。
【０１２９】
ちなみに、上記実施形態においては、カウンタｓｄｒ＿ｄｒｖｅｎｔ，ｓｄｗ＿ｄｒｖｅｎｔが、それぞれ本発明でいう第一記憶手段に相当する。また、カウンタｓｄｒ＿ｄａｅｄｏｎ，ｓｄｗ＿ｄａｅｄｏｎが、それぞれ本発明でいう第二記憶手段に相当する。
【０１３０】
さらに、上記実施形態では、Ｓ１１５〜Ｓ１２０、Ｓ１２５〜Ｓ１３０、Ｓ２３５〜Ｓ２４５、Ｓ２５０〜Ｓ２６０において、コマンドを発行するごとにカウンタをインクリメントしていたので、カウンタにはコマンドの発行回数が蓄積されたが、コマンドの伝達状況を示す情報は、コマンドの発行回数に限らない。
【０１３１】
例えば、コマンド発行回数に代えて、データの転送量を蓄積してもよい。このデータの転送量も、どのような単位であってもよく、例えば、バイト数、セクタ数、ブロック数など、いずれを蓄積してもよい。このようなデータの転送量を蓄積すれば、蓄積された情報からデータ転送量も把握できるので、そのような分析が必要な場合には便利である。
【０１３２】
さらに、コマンド発行回数やデータ転送量をゼロから加算するだけではなく、所定の初期値から減算する計算方式を採用してもよく、必要があれば、それらの加算や減算をコマンド発行回数やデータ転送量の整数倍を単位として行ってもよい。
【符号の説明】
【０１３３】
１・・・コンピュータ、３・・・ＵＳＢマスストレージデバイス、１１・・・ファイルシステム、１３・・・デバイスドライバ、１５・・・デーモンプロセス、１７・・・バスマネージャ、１９・・・Ｉ／Ｆハードウェア、Ａ１〜Ａ３・・・アプリケーション、Ａ４・・・特殊アプリケーション、Ａ５・・・動作完了確認ツール。
【図１】
0005310770.tif 000002
【図２】
0005310770.tif 000003
【図３】
0005310770.tif 000004
【図４】
0005310770.tif 000005
【図５】
0005310770.tif 000006
【図６】
0005310770.tif 000007
【図７】
0005310770.tif 000008
【図８】
0005310770.tif 000009