JP5505456B2 - デバイス制御システム及びプログラム - Google Patents

Description

本発明は、コンピュータ上で機能して、当該コンピュータに接続されたデバイスを制御するデバイス制御システムと、そのデバイス制御システムの一部を構成するためのプログラムに関する。

近年、ＵＳＢ（Universal Serial Bus）マスストレージデバイス、ＩＣカードで知られているＭＭＣ（Multi Media Card）デバイス、ＳＤ（Secure Digital）メモリカードデバイスなどが広く普及している。また、これらのデバイスを、Linux（登録商標）が搭載されたコンピュータで制御することも行われている。例えば、下記特許文献１には、ＵＳＢマスストレージデバイスをLinux搭載コンピュータで制御する技術が提案されている。また、ＭＭＣデバイスやＳＤメモリカードデバイスをLinux搭載コンピュータで制御する技術も存在する。なお、ＳＤメモリカードは、規格上、ＭＭＣとの互換性が考慮された仕様になっているため、Linux搭載コンピュータではＭＭＣの一種として認識される。そこで、以下の説明においては、ＭＭＣデバイスとＳＤメモリカードデバイスとを区別して説明をする必要がない限り、双方を総称してＭＭＣデバイスと呼ぶことにする。すなわち、以下の説明でいうＭＭＣデバイスは、ＳＤメモリカードデバイスではないＭＭＣデバイスとＳＤメモリカードデバイスの双方を含み、以下の説明でいうＭＭＣは、ＳＤメモリカードではないＭＭＣとＳＤメモリカードの双方を含む。

ところで、Linuxが搭載されたコンピュータで、上述のような各種ストレージデバイス（ＵＳＢマスストレージデバイス、ＭＭＣデバイス）を制御する際、コンピュータ上のカーネル空間では、デバイスドライバとデーモンプロセスが協働して必要な処理を実行している。以下、ＭＭＣデバイスの場合を例に説明を続ける。コンピュータ上のユーザ空間において作動するアプリケーションソフトウェアが、ＭＭＣデバイス上にあるファイルをオープンすると、その情報はファイルシステム経由でデバイスドライバ（ＭＭＣドライバ）へと伝達される。このとき、デバイスドライバでは、オープンされたファイルごとにハンドルが確保される。そして、アプリケーションソフトウェアからリードコマンド又はライトコマンドが発行されると、それらのコマンドがファイルシステム経由でデバイスドライバへと伝達される。このとき、デバイスドライバに伝達されたコマンド（以下、リクエストとも称する。）は、ハンドルごとの固有データとして確保されるリクエストキューに格納されることとなる。デーモンプロセスは、デバイスドライバによって確保された全てのハンドルを対象に、それら全てのハンドルに対応するリクエストキューの中に格納されたリクエストを、適当な順序で取り出して処理してゆく。その結果、それらのリクエストに対応するコマンドが、ＳＤＩＯバスドライバ等によって構成される通信用インターフェース部を介してＳＤメモリカードデバイスへと伝達されることになる。

このような制御が行われる際、デバイスドライバは、リクエストがリクエストキューに格納された後、デーモンプロセスでの処理の完了を待たずに、呼び出し元のアプリケーションソフトウェアにリターンする。そのため、デーモンプロセスによって実行される処理は、アプリケーションソフトウェア側から見て、デバイスドライバからの応答よりも遅延したタイミングで実行される遅延処理となる。このような遅延処理が行われれば、デバイスドライバは、デーモンプロセスによって実行される実際の処理が完了するのを待つことなくアプリケーションに応答を返し、その後は、別の処理を実行可能ともなるので、デバイスドライバでの処理効率が向上する。

特開２００４−２７２４９９号公報

しかし、アプリケーションソフトウェアが、連続的に複数の処理を実行した際に、先に実行した処理で上述のような遅延処理が生じていると、それに起因して後から実行する処理でエラーが発生することがある。例えば、アプリケーションソフトウェアが、先にストレージデバイスのフォーマット処理を実行し、引き続いてフォーマット後のファイルシステムのマウント処理を連続的に行うと、上述のような遅延処理に起因した問題を招くおそれがある。

より詳しく説明すると、フォーマット処理での遅延書き込みが完了する前に、マウント処理が実行されると、管理領域データの書き込みが完了していないにもかかわらず、マウント処理において管理領域データが読み出されてしまう可能性がある。この場合、マウント処理では、フォーマット不正のストレージデバイスと認識されてしまうおそれがある。しかも、そのようなエラーが発生した直後に、フォーマット処理の遅延書き込みが完了して管理領域が正しい状態になると、フォーマット不正ではない状態に更新されてしまうので、エラーの発生原因を事後的に解析することが極めて難しいという問題がある。この他、例えば、アプリケーションソフトウェア側でコンピュータの電源を切る場合にも、ストレージデバイスへの遅延書き込みが完了する前に電源を切ってしまうと、遅延書き込み予定となっていたデータの損失を招くおそれがある。

こうした問題を解消するには、アプリケーションソフトウェアが、デーモンプロセスによる遅延処理の完了を確実に待ってから、次の処理要求をデバイスドライバやデーモンプロセスに伝達することが重要となる。

しかし、Linuxが搭載されたコンピュータでは、アプリケーションソフトウェア側からデーモンプロセスによる遅延処理が完了したか否かを確認できるような手段が用意されていない、という問題がある。そのため、現状では、アプリケーションソフトウェアによって上述のようなフォーマット処理やマウント処理、あるいは電源断処理を行うに当たっては、遅延書き込みの完了が期待できる程度まで十分に待ってから、次の処理を行ったり電源を切ったりする、といった対策を取らざるを得ないのが実情であった。また、このような対策を取ることならできるものの、どの程度待てば遅延書き込みが完了するのかは、単なる経験則に基づく想定に過ぎず、何ら保証される時間が規定されているわけではないので、非常に不確実な対策にしかなり得ないという問題があった。さらに、多くの場合は、ごく短時間（例えば１秒足らず）だけ待てば遅延書き込みが完了しており、遅延書き込みが完了するまでに長時間（例えば２０秒程度）を要するのは、ごくまれなケースにすぎない。しかし、このようなまれなケースにも対処するためには、常に十分に長時間（例えば３０秒程度）が経過してからしか、次の処理を行ったり電源を切ったりすることができないため、非常に効率が悪いという問題もあった。

本発明は、上記のような問題を解決するためになされたものであり、その目的は、デバイスドライバがデーモンプロセス経由でデバイスを制御するデバイス制御システムにおいて、デーモンプロセスでの処理が完了したか否かをアプリケーションソフトウェア側からでも確実に検知可能とすることにある。

以下、本発明において採用した構成について説明する。
本発明のデバイス制御システムは、オペレーティングシステムによって制御されるコンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたブロックデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるとともに、当該コマンドが前記コンピュータに接続されたＭＭＣ（Multi Media Card）デバイスに対するデータのリード又はライトを要求するコマンドであった場合には、当該コマンドを所定のキューに格納するブロックデバイスアクセス用カーネルモジュールと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記ブロックデバイスアクセス用カーネルモジュールによって前記コマンドが前記キューに格納された場合に、当該キューから前記コマンドを取得するデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスが前記キューから前記コマンドを取得した場合に、当該コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記キューに前記コマンドが格納されている可能性がある状態及び当該可能性がない状態、いずれの状態であるのかを示す情報が、前記デーモンプロセスによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備え、前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされていることを特徴とする。

このように構成されたデバイス制御システムによれば、ブロックデバイスアクセス用カーネルモジュールがコマンドをキューに格納するとともに、そのコマンドをデーモンプロセスへコマンドがキューから取得する。その際、キューにコマンドが格納されている可能性がある状態及び当該可能性がない状態、いずれの状態であるのかを示す情報が、デーモンプロセスによって第一記憶手段に書き込まれる。また、デーモンプロセスから通信用インターフェース部を介してデバイスへのコマンドの伝送が完了した際、その旨を示す情報が、デーモンプロセスによって第二記憶手段に書き込まれる。さらに、コンピュータには、これら第一記憶手段及び第二記憶手段に記憶された情報を、コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部が設けられている。

そのため、コンピュータ上のユーザ空間において作動するプロセス（例えば、アプリケーションソフトウェアのプロセス）は、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取ることができ、それら読み取った情報に基づいて、キューにコマンドが残っていないかどうか、デバイスへのコマンドの伝送が完了したか否かを判定することができる。

ところで、請求項２に記載の構成を備えていれば、第一カウンタ及び第二カウンタのカウンタ値の増減に基づいて、コマンドの伝送が行われたか否かを判断することができる。また、第一カウンタ及び第二カウンタのカウンタ値を比較し、両者が一致していればコマンドに対応する処理が完了していると判断することができる。

また、請求項３に記載の構成を備えていれば、スケジューラによってキューに対するアクセスが行われている場合には、コマンドが格納されている可能性がある状態を示す情報が、デーモンプロセスによって第一記憶手段に書き込まれる。したがって、スケジューラによる管理対象となっているコマンドが残っているか否かを判定することができる。

さらに、請求項４に記載のプログラムに基づいて、コンピュータを上記各手段として機能させるプロセスを作動させれば、当該プロセスが、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取り、読み取った情報に基づいてデバイスへのコマンドの伝送が完了したか否かを判定し、その判定結果を、コンピュータ上のユーザ空間において作動する他のプロセスへ提供する。

したがって、このような判定結果を得るための処理を、他のプロセスが自ら実行できる仕組みを備えていなくても、他のプロセスは、上記判定結果を提供するプロセスを起動させて、そのプロセスから提供される判定結果を受け取ることができる。

そして、他のプロセスでは、受け取った判定結果に基づいて、デバイスへのコマンドの伝送が完了したことを確認した後、引き続いて次の処理を実行できるので、デバイスへのコマンドの伝送が完了していないにもかかわらず、次の処理を実行してしまうのを未然に防止することができる。

コンピュータが備えるデバイス制御システムの構成を示すブロック図。 （ａ）はＩ／Ｏスケジューラにおける処理のフローチャート、（ｂ）はＩ／Ｏスケジューリング処理の一例として挙げる処理のフローチャート。 デーモンプロセスにおける処理のフローチャート。 動作完了確認ツールにおける処理のフローチャート。 ディスクの再初期化処理のフローチャート。 ディスクの使用停止処理のフローチャート。 （ａ）はフラッシュデバイス処理のフローチャート、（ｂ）はディスクの使用再開処理のフローチャート。 （ａ）は/proc/driver/mmc-info処理のフローチャート、（ｂ）は/procから取得する情報の一例を示す説明図。

次に、本発明の実施形態について一例を挙げて説明する。
［デバイス制御システムの構成］
以下に例示するデバイス制御システムは、図１に示すように、コンピュータ１上で機能して、このコンピュータ１に接続されたＭＭＣデバイス２を制御するシステムである。ＭＭＣデバイス２は、カードスロット２Ａと、このカードスロット２Ａに装填されるＭＭＣ／ＳＤメモリカード２Ｂとで構成される。

コンピュータ１は、ＯＳとしてLinuxが搭載されたものであり、このＯＳの機能により、コンピュータ１上には、ＯＳによって管理されるカーネル空間及びユーザ空間が構成されている。これらのうち、ユーザ空間では、アプリケーションＡ１〜Ａ３、sfdisk，mkfsなどの特殊アプリケーションＡ４、動作完了確認ツールＡ５などが機能する。なお、詳しくは後述するが、動作完了確認ツールＡ５は、本実施形態で例示するデバイス制御システムに関連するデータとして、２個のカウンタ（ｒ１，ｗ１）を記憶領域上に確保する。

また、カーネル空間では、デバイス制御システムに関連するソフトウェアとして、ファイルシステム１１、ブロックデバイスアクセス用カーネルモジュール１３、ＭＭＣ用デーモンプロセス１５（以下、単にデーモンプロセス１５と称する。）、ＳＤＩＯバスドライバ１７、及びＩ／Ｏスケジューラ１８などが機能する。この他、コンピュータ１は、デバイス制御システムに関連するハードウェアとして、Ｉ／Ｆハードウェア１９などを備えている。

ファイルシステム１１は、ＯＳの一部として提供されるシステムで、ストレージデバイスなどが備える記憶領域に格納されるデータをファイルとして管理するとともに、そのファイルに対するリードやライトを行うためのアプリケーションインターフェースを提供する。本実施形態において、ファイルシステム１１は、ＦＡＴやＸＦＳなどの規格に対応したものとされている。アプリケーションＡ１などは、ファイルシステム１１によって提供されるアプリケーションインターフェースを利用して、ＭＭＣデバイス２に格納されたファイルにアクセスすることができる。

ブロックデバイスアクセス用カーネルモジュール１３は、各種ブロックデバイスを制御するために、ＯＳが標準的に備えているソフトウェアである。デバイス制御システムに関連する機能としては、ＭＭＣデバイス２を制御するためのデバイスドライバも、上記ブロックデバイスアクセス用カーネルモジュール１３を流用して構成されている。そのため、アプリケーションＡ１などからＭＭＣデバイス２に対するデータのリード又はライトを要求するコマンドが発行された場合、そのコマンドはブロックデバイスアクセス用カーネルモジュール１３へと伝達される。ブロックデバイスアクセス用カーネルモジュール１３は、自身が制御対象としているデバイスに対応する記憶領域を確保し、その記憶領域にブロックデバイス汎用デバイス固有データ１３Ａを格納する。デバイス制御システムに関連するデータとしては、複数のデータを備えるデータ構造とされたgendisk構造体が、ブロックデバイス汎用デバイス固有データ１３Ａ内に確保される。このgendisk構造体の中には、構造体メンバとして、３２バイト分の記憶領域であるディスクネーム記憶領域（disk＿name[32]）や、デバイス番号記憶領域（デバイスを示すメジャー番号及びマイナー番号が格納される記憶領域）が含まれている。また、ブロックデバイスアクセス用カーネルモジュール１３は、ファイルやデバイスに対するオープンコマンドが伝達されると、それに対応付けてハンドルと呼ばれる記憶領域（図１ではハンドルＨ１，Ｈ２を例示。）を確保し、その記憶領域にハンドル固有データ（図１ではハンドル固有データ１３Ｂ，１３Ｃを例示。）を格納する。アプリケーションＡ１などからファイルシステム１１に対してファイルのオープンコマンドが発行された場合、オープンされたファイルに対応するデバイスをオープンするコマンドは、ファイルシステム１１からブロックデバイスアクセス用カーネルモジュール１３へと伝達される。また、アプリケーションの中には、デバイスに対して直接オープンコマンドを発行する特殊アプリケーションＡ４（例えば、sfdisk，mkfs。）などもあり、このような特殊アプリケーションＡ４からはブロックデバイスアクセス用カーネルモジュール１３へ直接コマンドが伝達される。ブロックデバイスアクセス用カーネルモジュール１３は、アプリケーションＡ１等からコマンドが伝達されると、そのコマンド（リクエスト）を、ハンドルごとの固有データとして確保されるＩ／Ｏリクエストキューに格納する。なお、図１では、図を簡潔にする都合上、単一のブロックデバイスアクセス用カーネルモジュール１３を図示してあるが、実際は、複数のデバイスがあれば、それら個々のデバイスそれぞれに対応する複数のデバイスドライバがコンピュータ１上で機能し、各デバイスドライバにおいてブロックデバイスアクセス用カーネルモジュール１３が利用される。

デーモンプロセス１５は、ブロックデバイスアクセス用カーネルモジュール１３同様、ＯＳの一部を構成するソフトウェアである。ブロックデバイスアクセス用カーネルモジュール１３によってＩ／Ｏリクエストキューにコマンド（リクエスト）格納されると、そのコマンド（リクエスト）は、デーモンプロセス１５へと伝達される。また、デーモンプロセス１５は、自身で必要な記憶領域を確保し、その記憶領域にＭＭＣ用デバイス固有データ１５Ａを格納する。デバイス制御システムに関連するデータとしては、１個のフラグ（flag）、及び４個のカウンタ（ｒ２，ｒ３，ｗ２，ｗ３）が、ＭＭＣ用デバイス固有データ１５Ａ内に確保される。

ＳＤＩＯバスドライバ１７及びＩ／Ｆハードウェア１９は、デーモンプロセス１５とＭＭＣデバイス２との間に介在する通信用インターフェース部（本発明でいう通信用インターフェース部。）を構成している。デーモンプロセス１５へコマンドが伝達された際には、そのコマンドがＳＤＩＯバスドライバ１７及びＩ／Ｆハードウェア１９を介してデーモンプロセス１５からＭＭＣデバイス２へと伝送される。

Ｉ／Ｏスケジューラ１８は、Ｉ／Ｏリクエストキューに格納されたコマンド（リクエスト）を効率良く処理するために、ＯＳが標準的に備えているソフトウェアである。Ｉ／Ｏスケジューラ１８によるスケジューリングの方式には、いくつかの異なる方式が存在するが、その具体的な方式の違いは本発明の要部ではないので、ここでの説明は省略する。代表的なスケジューリングの一例としては、例えば、コマンドの処理順をソートしたり複数のコマンドをマージしたりすることで、ストレージデバイスにおけるシーク量を抑制するなどの効率化・最適化を図っている。

さらに、このコンピュータ１においては、上述の１個のフラグ（flag）、及び４個のカウンタ（ｒ２，ｒ３，ｗ２，ｗ３）に格納された値を、ユーザ空間で作動するプロセスから読み取り可能とするため、/procバイパスを利用した情報公開用インターフェース部（本発明でいう情報公開用インターフェース部に相当。）を設けてある。/procは、Linuxにおいて、ＯＳの管理下にあるリソース関連の情報（例えば、カーネル空間に確保された記憶領域に格納された値）を、ファイルと同様の手順で読み出し可能とするために用意された仮想的なファイルシステムである。Linuxにおいて、ＭＭＣデバイス用の/procバイパスについては、ＯＳ標準での用意がないので、本実施形態では“/proc/driver/mmc-info”を新設して、上述の１個のフラグ及び４個のカウンタ値を読み出し可能としてある。なお、このような/procバイパスは、本実施形態では、動作完了確認ツールＡ５によって利用される。動作完了確認ツールＡ５の詳細については後述する。

［Ｉ／Ｏスケジューラにおいて実行される処理］
次に、Ｉ／Ｏスケジューラ１８において実行される処理の一例について、図２（ａ）及び図２（ｂ）のフローチャートに基づいて説明する。Ｉ／Ｏスケジューラ１８において実際に実行されている処理の内容は、図２（ａ）及び図２（ｂ）のフローチャートに例示したものよりも更に複雑かつ高度なものとされているが、Ｉ／Ｏスケジューラ１８そのものは公知であり、その処理内容全てを説明しなくても本発明の特徴を理解することは可能なので、ここでは、Ｉ／Ｏスケジューラ１８の処理の一部を抜粋して例示するにとどめる。

図２（ａ）に示す処理は、コンピュータ１の起動に伴ってＩ／Ｏスケジューラ１８が稼働を開始すると実行され、その後は、コンピュータ１の作動が停止されるまでコンピュータ１に常駐する。図２（ａ）に示す処理を開始すると、Ｉ／Ｏスケジューラ１８（正確には、Ｉ／Ｏスケジューラ１８としての処理を実行するコンピュータ１；以下、単にＩ／Ｏスケジューラ１８という。）は、まず、システムからＩ／Ｏリクエストキューを取得する（Ｓ１０５）。ここでは、システム上で何らかのファイルがオープンされ、そのファイルに対応するＩ／Ｏリクエストキューが生成されていれば、Ｉ／Ｏスケジューラ１８は、Ｉ／Ｏリクエストキューの取得に成功する。

そこで、Ｉ／Ｏスケジューラ１８は、Ｉ／Ｏリクエストキューを取得できたか否かを判断し（Ｓ１１０）、Ｉ／Ｏリクエストキューを取得できなかった場合は（Ｓ１１０：いいえ）、Ｓ１０５へと戻る。なお、この場合、Ｉ／Ｏスケジューラ１８は、所定の待機時間が経過するのを待ってから、Ｓ１０５を再試行する。一方、Ｓ１０５を実行した結果、Ｉ／Ｏリクエストキューを取得できた場合は（Ｓ１１０：はい）、取得中のＩ／Ｏリクエストキューに対してＩ／Ｏスケジューリングを行う（Ｓ１１５）。なお、Ｓ１１５で実行されるＩ／Ｏスケジューリングの具体的処理は、既に述べた通り複雑な処理になるので、ここでは、図２（ｂ）に処理の一部だけを例示して説明を続けることにする。

図２（ｂ）に例示した処理を開始すると、Ｉ／Ｏスケジューラ１８は、まず、Ｉ／Ｏリクエストキューを排他的に利用するため、Ｉ／Ｏリクエストキューを閉鎖する（Ｓ１５５）。これは、Ｉ／Ｏスケジューリングの最中に新たなリクエストがＩ／Ｏリクエストキューに格納されるのを防止するための措置である。そして、Ｉ／Ｏスケジューラ１８は、Ｉ／Ｏリクエストキューの閉鎖に成功したか否かを判断し（Ｓ１６０）、Ｉ／Ｏリクエストキュー閉鎖に失敗した場合は（Ｓ１６０：いいえ）、図２（ｂ）に示すＩ／Ｏスケジューリングを終了する。一方、Ｉ／Ｏリクエストキュー閉鎖に成功した場合（Ｓ１６０：はい）、Ｉ／Ｏスケジューラ１８は、処理開始前のリクエストが２個以上か否かを判断する（Ｓ１６５）。

ここで、リクエストが２個以上ある場合は（Ｓ１６５：はい）、続いてマージ可能なリクエストがあるか否かを判断する（Ｓ１７０）。ここで、マージ可能なリクエストの一例を挙げれば、例えば、複数のリクエストのうち、連続したブロックへのアクセスを要求する２以上のリクエストが存在すれば、それら２以上のリクエストは、マージ可能なリクエストであると判断される。また、このような判断の際には、必要に応じてリクエストの処理順もマージを行う上で好適な順序に変更される。マージ可能なリクエストがある場合（Ｓ１７０：はい）、Ｉ／Ｏスケジューラ１８は、２つのリクエストをマージして、１つのリクエストにする（Ｓ１７５）。そして、マージ可能なリクエストがまだあるか否かを判断し（Ｓ１８０）、まだある場合は（Ｓ１８０：はい）、Ｓ１７５へと戻る。これにより、マージ可能なリクエストがある間は、Ｓ１７５〜Ｓ１８０が繰り返されて、リクエストの総数が削減されるとともに、リクエストの処理順が最適化される。

Ｓ１７５を実行した結果、マージ可能なリクエストがなくなった場合（Ｓ１８０：いいえ）、Ｉ／Ｏスケジューラ１８は、Ｉ／Ｏリクエストキューを解放して（Ｓ１８５）、図２（ｂ）に示すＩ／Ｏスケジューリングを終了する。また、最初からリクエストが２個以上なかった場合（Ｓ１６５：いいえ）、又はマージ可能なリクエストがなかった場合も（Ｓ１７０：いいえ）、Ｉ／Ｏスケジューラ１８は、Ｉ／Ｏリクエストキューを解放して（Ｓ１８５）、図２（ｂ）に示すＩ／Ｏスケジューリングを終了する。

以上説明した通り、図２（ａ）及び図２（ｂ）に示すＩ／Ｏスケジューラ１８の処理では、Ｉ／Ｏリクエストキューに複数のリクエストが格納された場合に、可能であれば、リクエストの総数を削減するとともに、リクエストの処理順を最適化する。これにより、ストレージデバイス（本実施形態の場合はＭＭＣデバイス２）に対して発行されるコマンド数を削減するとともに、無駄なシークの発生を抑制することができる。

［ＭＭＣ用デーモンプロセス１５において実行される処理］
次に、ＭＭＣ用デーモンプロセス１５（以下、単にデーモンプロセス１５と称する。）において実行される処理について、図３のフローチャートに基づいて説明する。デーモンプロセス１５は、ＭＭＣデバイス２の作動開始に伴って起動され、その後は、ＭＭＣデバイス２の作動が停止されるまでコンピュータ１に常駐する。図３に示す処理は、デーモンプロセス１５が起動されたときに開始される。なお、以下、ディスクデバイスmmcblk0（/dev/mmcblk0）に対応するデーモンプロセス１５を例に挙げて説明を続けるが、mmcblk0は単なる一例として例示するものであり、別のディスクデバイス（mmcblk１〜mmcblk31のいずれか）であっても同様の処理となるのはもちろんである。

図３に示す処理を開始すると、デーモンプロセス１５（正確には、デーモンプロセス１５としての処理を実行するコンピュータ１；以下、単にデーモンプロセス１５という。）は、フラグflagの初期化（ゼロクリア）を行い（Ｓ２０３）、他のデバイスにも時間を与えるため、所定時間ウエイトする（Ｓ２０５）。そして、ディスクデバイスmmcblk0が取り外されたか否かを判断し（Ｓ２１０）、ディスクデバイスmmcblk0が取り外されている場合は（Ｓ２１０：はい）、フラグflagの初期化（ゼロクリア）を行って（Ｓ２１３）、デーモンプロセス１５による処理を終了する。

一方、Ｓ２１０において、ディスクデバイスmmcblk0が取り外されていないと判断された場合（Ｓ２１０：いいえ）、デーモンプロセス１５は、デバイス固有データから最初のオープン中ハンドルを取得する（Ｓ２１５）。そして、オープン中のハンドルがない場合は（Ｓ２２０：いいえ）、フラグflagのビット７−０をクリアして（Ｓ２２１）、Ｓ２０５へと戻る。一方、オープン中のハンドルがある場合（Ｓ２２０：いいえ）、デーモンプロセス１５は、フラグflagのビット７をセットした後、フラグflagのビット６−０をクリアして（Ｓ２２２）、取得中ハンドルのＩ／Ｏリクエストキューが閉鎖中か否かを判断する（Ｓ２２３）。ここで、取得中ハンドルのＩ／Ｏリクエストキューが閉鎖中でなければ（Ｓ２２３：いいえ）、デーモンプロセス１５は、取得中ハンドルのＩ／Ｏリクエストキューから１リクエストを取り出す（Ｓ２２５）。

続いて、デーモンプロセス１５は、取り出したリクエストの種別を判断し（Ｓ２３０）、リクエストがリードであった場合（Ｓ２３０：リード）、フラグflagのビット４をセットし、カウンタｒ２をインクリメントする（Ｓ２３５）。なお、カウンタｒ２は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２３５が実行されるたびにインクリメントされることになる。

その後、デーモンプロセス１５は、ＭＭＣデバイス２に対してＭＭＣ形式リードコマンドを発行して完了を待つ（Ｓ２４０）。Ｓ２４０において、完了を待つ間は他のデバイスに時間を解放する。そして、ＭＭＣデバイス２からの完了応答が返されたら、カウンタｒ３をインクリメントして（Ｓ２４５）、Ｓ２７０へ進む。なお、カウンタｒ３は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２４５が実行されるたびにインクリメントされることになる。

一方、Ｓ２３０において、リクエストがライトであった場合（Ｓ２３０：ライト）、デーモンプロセス１５は、フラグflagのビット４をセットし、カウンタｗ２をインクリメントする（Ｓ２５０）。なお、カウンタｗ２は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２５０が実行されるたびにインクリメントされることになる。

その後、デーモンプロセス１５は、ＭＭＣデバイス２に対してＭＭＣ形式ライトコマンドを発行し完了を待つ（Ｓ２５５）。Ｓ２５５において、完了を待つ間は他のデバイスに時間を解放する。ＭＭＣデバイス２からの完了応答が返されたら、カウンタｗ３をインクリメントして（Ｓ２６０）、Ｓ２７０へ進む。なお、カウンタｗ３は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２６０が実行されるたびにインクリメントされることになる。

さらに、Ｓ２３０において、リクエストがなかった場合は（Ｓ２３０：リクエスト無し）、そのままＳ２７０へ進む。また、Ｓ２２３において、取得中ハンドルのＩ／Ｏリクエストキューが閉鎖中であれば（Ｓ２２３：はい）、Ｉ／Ｏスケジューラ１８がスケジューリング中である可能性があるので、その場合は、フラグflagのビット１をセットして（Ｓ２６５）、Ｓ２７０へ進む。

以上のようにしてＳ２４５，Ｓ２６０，Ｓ２３０：リクエスト無し，又はＳ２６５を終えたら、デーモンプロセス１５は、ＭＭＣ用デバイス固有データ１５Ａから次のオープン中ハンドルを取得する（Ｓ２７０）。そして、オープン中のハンドルがない場合は（Ｓ２７５：はい）、フラグflagのビット７をクリアして（Ｓ２８０）、Ｓ２０５へと戻る一方、オープン中のハンドルがある場合は（Ｓ２７５：いいえ）、Ｓ２２３へと戻る。

以上説明したように、図３に示した処理では、Ｓ２４０又はＳ２５５においてデバイスに対してリードコマンド又はライトコマンドが発行されることとなるたびに、その発行前後双方のタイミングとなるＳ２３５及びＳ２４５、若しくはＳ２５０及びＳ２６０において、カウンタｒ２及びカウンタｒ３、若しくはカウンタｗ２及びカウンタｗ３がインクリメントされる。したがって、これらのカウンタｒ２、ｒ３、ｗ２、ｗ３には、デーモンプロセス１５におけるリード又はライトのＳＣＳＩコマンドの発行回数が、発行直前及び発行後の待機完了直後双方のタイミングで蓄積・保持されることになる。

また、フラグflagのビット７は、オープン中のハンドルがあれば（Ｓ２２０：はい）、直ちにセットされる一方、オープン中のハンドルがなければ（Ｓ２２０：いいえ、又はＳ２７５：いいえ）、クリアされる。そして、ＭＭＣに対してリードコマンド又はライトコマンドが発行される場合は、フラグflagのビット４がセットされる一方、Ｉ／Ｏリクエストキューが閉鎖中の場合は（Ｓ２２３：はい）、フラグflagのビット１がセットされる。したがって、このフラグflagに基づいて、Ｉ／Ｏリクエストキューの状態を判断することができ、特にビット７−０が全てゼロクリアされているか否かに基づいて、現在処理中のリクエストが存在するか否かを判断することができる。

［/proc/driver/mmc-info処理］
次に、/proc/driver/mmc-info処理について、図８（ａ）のフローチャートに基づいて説明する。図８（ａ）に示すフローチャートは、“/proc/driver/mmc-info”に対するリードが行われた場合に実行される処理であり、この処理が実行されることで、図８（ｂ）に示すような形式の情報がリード結果として出力されることになる。

より詳しく説明すると、/proc/driver/mmc-info処理を開始すると、コンピュータ１は、まず、図８（ｂ）に示すような情報のうち、先頭１行にある情報「Ｉｎｆｏ：〜」を出力する（Ｓ９０５）。そして、カウンタＮに０（ゼロ）をセットして（Ｓ９０７）、Ｎ枚目のＭＭＣ（Ｎは０〜３の整数）があるか否かを判断する（Ｓ９１０）。本実施形態においては、“mmcblk0〜mmcblk3”までをサポートしており、そのためＮは０〜３の整数とされているが、このカウンタＮの最大値は３以上とされていてもよい。

Ｓ９１０において、Ｎ枚目のＭＭＣ（Ｎは０〜３の整数）があった場合（Ｓ９１０：ある）、コンピュータ１は、ブロックデバイス汎用デバイス固有データ１３Ａ中に含まれるgendisk構造体中の文字型配列disk＿name[32]を参照し（Ｓ９１５）、ＭＭＣに対して割り当てられるディスクデバイス名“mmcblkN”を取得する。

続いて、コンピュータ１は、「ｃｉｄＮ：〜」（Ｎは０〜３の整数）の行を出力し（Ｓ９３０）、「ｃｓｄＮ：〜」（Ｎは０〜３の整数）の行を出力し（Ｓ９３５）、「ＦＲＷｃＮ：〜」の行を出力する（Ｓ９４０）。そして、Ｓ９４０を終えるか、Ｓ９１０でＮ枚目のＭＭＣ（Ｎは０〜３の整数）がないと判断された場合は（Ｓ９１０：ない）、変数Ｎをインクリメントし（Ｓ９５０）、変数Ｎが３以下か否かを判断する（Ｓ９６０）。変数Ｎが３以下であれば（Ｓ９６０：はい）、Ｓ９１０へと戻る。これにより、Ｓ９１０以降の処理が繰り返され、Ｎ＝０〜３の順にディスクデバイス“mmcblkN”に対応する処理が繰り返される。変数Ｎが３を超えたら（Ｓ９６０：いいえ）、/proc/driver/mmc-info処理を終了する。

以上のような/proc/driver/mmc-info処理により、図８（ｂ）に例示するような情報が出力される。図８（ｂ）に例示した情報の場合、Ｎ＝０に対応する情報が３行分、Ｎ＝１に対応する情報が３行分、それぞれ出力されている。Ｓ９４０で出力される行には、図８（ｂ）に例示した通り、文字列「ＦＲＷｃＮ：〜」に引き続いて、ディスクネーム、フラグflag、及び４個のカウンタ（ｒ２，ｒ３，ｗ２，ｗ３）の値が列挙される。

［動作完了確認ツールにおいて実行される処理］
次に、動作完了確認ツールＡ５において実行される処理について、図４のフローチャートに基づいて説明する。動作完了確認ツールＡ５は、コマンド発行元プロセスからブロックデバイスアクセス用カーネルモジュール１３へと伝達されるコマンドが、ＭＭＣデバイス２へ実際に伝達されたかどうかをコマンド発行元プロセス側で確認可能とするためのツールである。

この動作完了確認ツールＡ５はコマンド発行元プロセス側で必要なときに任意に起動され、その際、図４に示す処理が実行されることになる。なお、以下の説明では、説明を簡便にするため、ＭＭＣデバイス２がコンピュータ１においてディスクデバイス“mmcblk0”として認識されている場合を例に挙げて説明する。ただし、動作完了確認ツールＡ５は、“mmcblk0”以外のディスクデバイス（本実施形態であれば、mmcblk１〜mmcblk3のいずれか）を対象にして所期の処理を行うこともできる。

図４に示す処理を開始すると、動作完了確認ツールＡ５（正確には、動作完了確認ツールＡ５としての処理を実行するコンピュータ１；以下、単に動作完了確認ツールＡ５という。）は、“/proc/driver/mmc-info”ファイルをオープンする（Ｓ３０５）。ここで、“/proc/driver/mmc-info”ファイルをオープンできない場合（Ｓ３１０：いいえ）、動作完了確認ツールＡ５は、図４に示す処理を終了する（mmcblk0が見つからない エラー終了）。

一方、Ｓ３１０において、ファイルをオープンできた場合（Ｓ３１０：はい）、動作完了確認ツールＡ５がファイル“/proc/driver/mmc-info”からデータをリードすると、既に説明した/proc/driver/mmc-info処理（図８（ａ）参照。）が実行され、その結果、動作完了確認ツールＡ５は、図８（ｂ）に示すような形式の情報を読み込むことができる。

そこで、動作完了確認ツールＡ５は、読み込んだ情報中からキーワード「ＦＲＷｃ」を含む、最初の行を検索する（Ｓ３１５）。図８（ｂ）に例示する情報の場合、キーワード「ＦＲＷｃ」を含む、最初の行は「FRWc0: mmcblk0 07001000 0000008f 0000008f 00000002 00000002」という行であり、この行には、ディスク名“mmcblk0”と上述のフラグflag、及び４個のカウンタ（ｒ２，ｒ３，ｗ２，ｗ３）に格納された値が列挙されている。

ここで、「ＦＲＷｃ」の行が見つからなければ（Ｓ３１７：いいえ）、動作完了確認ツールＡ５は、図４に示す処理を終了する（mmcblk0が見つからない エラー終了）。一方、Ｓ３１７において、「ＦＲＷｃ」の行が見つかれば（Ｓ３１７：はい）、「ＦＲＷｃＮ：」の次の文字列がディスク名disk＿name[32]なので（Ｓ３２０）、ディスク名が“mmcblk0”であるか否かを判断する（Ｓ３２５）。

Ｓ３２５において、ディスク名が“mmcblk0”でない場合は（Ｓ３２５：いいえ）、図４に例示した処理の処理対象となるディスクデバイスではないので、その場合、動作完了確認ツールＡ５は、キーワード「ＦＲＷｃ」を含む、次の行を検索して（Ｓ３３０）、Ｓ３１７へと戻る。これにより、ディスク名が“mmcblk0”である行が見つかるまでキーワード「ＦＲＷｃ」の行が順に検索されることになり、該当する行が見つからない場合（Ｓ３１７：いいえ）、動作完了確認ツールＡ５は、図４に示す処理を終了することになる（mmcblk0が見つからない エラー終了）。

また、Ｓ３２５において、ディスク名が“mmcblk0”であった場合は（Ｓ３２５：はい）、“mmcblk0”が接続中であることが確認されたことになる（Ｓ３４０）。そこで、この場合、動作完了確認ツールＡ５は、タイムアウトのカウンタとして所定時間（例えば１分程度）を設定し（Ｓ３４５）、カウンタｒ２，ｗ２の値を、それぞれカウンタｒ１，ｗ１に保存する（Ｓ３４８）。そして、一定時間（例えば１００ｍｓ）が経過するのを待って、タイムアウトのカウンタを上記一定時間分（上記例では１００ｍｓ）減らして（Ｓ３５０）、タイムアウトか否かを判断する（Ｓ３６０）。ここで、タイムアウトであった場合（Ｓ３６０：はい）、動作完了確認ツールＡ５は、図４に示す処理を終了する（タイムアウトエラー終了）。

一方、Ｓ３６０において、タイムアウトではない場合（Ｓ３６０：いいえ）、動作完了確認ツールＡ５は、ファイル“/proc/driver/mmc-info”ファイルを再読み込みして、“FRWcN: mmcblk0 …”の行から情報取得を行う（Ｓ３６５）。そして、動作完了確認ツールＡ５は、フラグflagの下位８ビット（ビット７−０）が全てゼロか否かを判断する（Ｓ３６７）。ここで、フラグflagの下位８ビットが全てゼロとなるのは、デーモンプロセス１５において、オープン中のハンドルがないと判断されている場合であり（Ｓ２２０：いいえ、又はＳ２７５：いいえ）、この場合、少なくともデーモンプロセス１５は、ＭＭＣデバイス２に対するコマンドを発行しないことを意味する。逆に、フラグflagの下位８ビットが全てゼロでなければ、デーモンプロセス１５は、ＭＭＣデバイス２に対するコマンドを発行する可能性がある。そこで、Ｓ３６７において、フラグflagの下位８ビットが全てゼロでない場合は（Ｓ３６７：いいえ）、Ｓ３４８へと戻る。これにより、Ｓ３４５で設定した時間が経過するまでは、Ｓ３４８〜Ｓ３６７が繰り返されることになる。

一方、Ｓ３６７において、フラグflagの下位８ビットが全てゼロであった場合（Ｓ３６７：はい）、動作完了確認ツールＡ５は、カウンタｒ１，ｒ２，ｒ３の値が全て一致するか否かを判断する（Ｓ３７０）。ここで、カウンタｒ１，ｒ２，ｒ３の値が全て一致するのは、Ｓ２３５及びＳ２４５が実行されてｒ２，ｒ３の値が確定した後、Ｓ３４８でｒ２がｒ１に保存され、Ｓ３５０で少なくとも１００ｍｓ待機した後、Ｓ３６５で再読み込みを行った結果、ｒ２の値に変化がなかった、という場合に該当する。

これは、ブロックデバイスアクセス用カーネルモジュール１３でリクエストキューに格納されたリクエスト（リードコマンド）が、デーモンプロセス１５でもＭＭＣデバイス２へと発行され、その応答がデバイスからデーモンプロセス１５へ既に返っており、かつ、その後、少なくとも１００ｍｓにわたって、デーモンプロセス１５はコマンドを発行していないことを意味する。逆に、デーモンプロセス１５からＭＭＣデバイス２へコマンドが発行されたものの、その応答がデバイスからデーモンプロセス１５へまだ返っていない場合や、１００ｍｓ待機している間に、デーモンプロセス１５からＭＭＣデバイス２へ新たにコマンドを発行している場合、上記カウンタ値は一致しない。

そこで、Ｓ３７０において、カウンタｒ１，ｒ２，ｒ３の値が一致しない場合は（Ｓ３７０：いいえ）、Ｓ３５０へと戻る。これにより、Ｓ３４５で設定した時間が経過するまでは、Ｓ３４８〜Ｓ３７０が繰り返されることになる。一方、Ｓ３７０において、カウンタｒ１，ｒ２，ｒ３の値が全て一致した場合（Ｓ３７０：はい）、動作完了確認ツールＡ５は、カウンタｗ１，ｗ２，ｗ３が全て一致するか否かを判断する（Ｓ３７５）。ここで、カウンタｗ１，ｗ２，ｗ３の値が全て一致するのは、Ｓ２５０及びＳ２６０が実行されてｗ２，ｗ３の値が確定した後、Ｓ３４８でｗ２がｗ１に保存され、Ｓ３５０で少なくとも１００ｍｓ待機した後、Ｓ３６５で再読み込みを行った結果、ｗ２の値に変化がなかった、という場合に該当する。

これは、ブロックデバイスアクセス用カーネルモジュール１３でリクエストキューに格納されたリクエスト（ライトコマンド）が、デーモンプロセス１５でもＭＭＣデバイス２へと発行され、その応答がデバイスからデーモンプロセス１５へ既に返っており、かつ、その後、少なくとも１００ｍｓにわたって、デーモンプロセス１５はコマンドを発行していないことを意味する。逆に、デーモンプロセス１５からＭＭＣデバイス２へコマンドが発行されたものの、その応答がデバイスからデーモンプロセス１５へまだ返っていない場合や、１００ｍｓ待機している間に、デーモンプロセス１５からＭＭＣデバイス２へ新たにコマンドを発行している場合、上記カウンタ値は一致しない。

そこで、Ｓ３７５において、カウンタｗ１，ｗ２，ｗ３の値が一致しない場合は（Ｓ３７０：いいえ）、Ｓ３５０へと戻る。これにより、Ｓ３４５で設定した時間が経過するまでは、Ｓ３４８〜Ｓ３７５が繰り返されることになる。したがって、リード又はライトいずれかのコマンドが完全にデバイスへと伝わって、その後、１００ｍｓ待機しても新たなコマンドが発行されない、という状態にならない限り、Ｓ３４８〜Ｓ３７５が繰り返され、その繰り返しの中でタイムアウトとなった場合には（Ｓ３６０：はい）、タイムアウトでエラー終了となるのである。

一方、Ｓ３６７において、フラグflagの下位８ビットが全てゼロで、かつＳ３７０において、カウンタｒ１，ｒ２，ｒ３の値が全て一致し（Ｓ３７０：はい）、かつＳ３７５において、カウンタｗ１，ｗ２，ｗ３の値が全て一致した場合（Ｓ３７５：はい）、動作完了確認ツールＡ５は、図４に示す処理を正常終了する。

以上説明したように、動作完了確認ツールＡ５は、リードコマンド及びライトコマンドがブロックデバイスアクセス用カーネルモジュール１３からデーモンプロセス１５経由でＭＭＣデバイス２へと伝達され、デバイスからの応答がデーモンプロセス１５へ返っていて、その後、所定時間にわたってデーモンプロセス１５からコマンドが発行されない状況下では正常終了し、そのような状況になければエラー終了する。正常終了したかエラー終了したかを示す情報は、動作完了確認ツールＡ５を起動した上位プロセス（例えば、アプリケーションなど）へと返される。したがって、上位プロセスでは、動作完了確認ツールＡ５を利用して、ＭＭＣデバイス２に対して発行したコマンドが、デーモンプロセス１５において処理済みとなっているか否かを確認することができる。

［アプリケーションにおいて実行される処理の一例］
次に、上述のような動作完了確認ツールＡ５を利用するアプリケーションの一例を、図５〜図７のフローチャートに基づいて説明する。以下に説明するアプリケーションＡ１は、ディスクデバイス“mmcblk0”の再初期化を行ってから、引き続いてパーティションの切り直しを行い、更に引き続いてファイルシステム“mmcblk0p1”のマウントを行うものである。

なお、以下の処理でも、説明を簡潔にするために、ディスクデバイス“mmcblk0”，ファイルシステム“mmcblk0p1”，マウントポイント“/mnt/mmc1”などの具体例を挙げながら説明を行うが、これらの具体例に限られないのはもちろんである。

図５に示すディスクの再初期化処理を開始すると、アプリケーションＡ１（正確には、アプリケーションＡ１としての処理を実行するコンピュータ１；以下、単にアプリケーションＡ１という。）は、“/dev/mmcblk0”を対象にしてディスク使用停止処理を実行する（Ｓ４０５）。このディスク使用停止処理は、詳しくは図６に示すような処理となる。

すなわち、図６に示す処理では、まず、アプリケーションＡ１からの指令により、全アプリケーションでマウントポイント“/mnt/mmc1”以下の全てのオープン中のファイルをクローズする（Ｓ５０５）。なお、この例は、“/dev/mmcblk0p1”が“/mnt/mmc1”にマウント中であることを想定している例であり、マウントポイントの具体的パス名は任意である。続いて、アプリケーションＡ１は、ｓｙｎｃコマンドを実行して、ディスクキャッシュ１１Ａに保持されているデータをＭＭＣデバイス２へ書き出す（Ｓ５１０）。そして、“/mnt/mmc1”をアンマウントして、“/dev/mmcblk0p1”のマウントを解除する（Ｓ５１５）。これにより、“/dev/mmcblk0p1”に対しては、少なくともファイルシステム１１経由でのアクセスが行われない状態になる。

次に、アプリケーションＡ１は、ディスクデバイス“mmcblk0”のフラッシュデバイス（flushdevice）処理を行い、ブロックデバイスアクセス用カーネルモジュール１３の動作完了待ちになる（Ｓ５２０）。このフラッシュデバイス処理は、ブロックデバイスアクセス用カーネルモジュール１３が内部的に保持（キャッシュ）しているデータをデバイス側へ掃き出させるために行われる処理であり、Linux搭載コンピュータでは既に行われている周知の処理である。具体的には、フラッシュデバイス処理は、図７（ａ）に示すような処理となり、アプリケーションＡ１は、“/dev/mmcblk0”をオープンしてハンドルをファイルディスクリプタｆｄに格納し（Ｓ６０５）、システムコール“ioctl(fd,BLKFLSBUF,0)”を実行する（Ｓ６１０）。これにより、ブロックデバイスアクセス用カーネルモジュール１３は、リクエストキュー内に未処理のコマンドが残されていたとしても、それらを全てリクエストキューへ積み、これにより、それらのデータをデーモンプロセス１５へ引き渡す準備を完了する。Ｓ６１０を終えたら、アプリケーションＡ１は、ｆｄのクローズ（“/dev/mmcblk0”のクローズ）を行って（Ｓ６１５）、図７（ａ）に示すを完了する。

さて、こうしてフラッシュデバイス処理を完了したら、再び図６に戻って、アプリケーションＡ１は、動作完了確認ツールＡ５を起動して“mmcblk0”の動作完了待ちになる（Ｓ５２５）。先に説明した通り、動作完了確認ツールＡ５は、デーモンプロセス１５がデバイスからの応答を受け取ったことを検出したときに正常終了するので、Ｓ５２５では、デーモンプロセス１５の動作完了待ちを行うことになる。ここで、動作完了確認ツールＡ５が正常終了すれば、デーモンプロセス１５が保持していたデータ全てがデバイスに掃き出されたことを意味するので、これにて図６に示すディスクの使用停止処理を完了する。なお、動作完了確認ツールＡ５がエラー終了した場合は、エラーメッセージを表示して処理を中止するなどの対処を行えばよいが、この種のエラー処理自体は一般的なものなので、これ以上の詳細な説明は省略する。

図６に示すディスクの使用停止処理を完了したら、図５のＳ４０５を終えたことになるので、続いて、アプリケーションＡ１は、“sfdisk”コマンドを実行し、パーティションの切り直しを行う（Ｓ４１０）。そして、“mmcblk0”のフラッシュデバイス処理を行って、ブロックデバイスアクセス用カーネルモジュール１３の動作完了待ちになり（Ｓ４１５）、続いて、動作完了確認ツールＡ５で“mmcblk0”の動作完了待ち、すなわち、デーモンプロセス１５の動作完了待ちになる（Ｓ４２０）。

Ｓ４１５，Ｓ４２０は、先に説明したＳ５２０，Ｓ５２５と同等な処理であり、これらの処理により、ブロックデバイスアクセス用カーネルモジュール１３の保持するデータ、デーモンプロセス１５の保持するデータが、それぞれデバイス側へ確実に掃き出されるのを待つことになる。そして、Ｓ４２０を終えたら、“sfdisk”コマンドの実行に伴ってＭＭＣデバイス２へ書き込まれるべきデータが、確実にデバイスに書き込まれたことになる。

そこで、アプリケーションＡ１は、mkfsコマンドを実行し、パーティションのフォーマットを行う（Ｓ４２５）。そして、“mmcblk0”のフラッシュデバイス処理を行って、ブロックデバイスアクセス用カーネルモジュール１３の動作完了待ちとなり（Ｓ４３０）、続いて、動作完了確認ツールＡ５で“mmcblk0”の動作完了待ち、すなわち、デーモンプロセス１５の動作完了待ちになる（Ｓ４３５）。Ｓ４３０，Ｓ４３５も、先に説明したＳ５２０，Ｓ５２５，Ｓ４１５，Ｓ４２０と同等な主旨で実行する処理である。

Ｓ４３５を終えたら、“mkfs”コマンドの実行に伴ってＭＭＣデバイス２へ書き込まれるべきデータが、確実にデバイスに書き込まれたことになるので、アプリケーションＡ１は、ディスクデバイス“/dev/mmcblk0”の使用再開処理を行う（Ｓ４４０）。なお、Ｓ４４０は、詳しくは図７（ｂ）に示すような処理となる。すなわち、アプリケーションＡ１は、“/dev/mmcblk0p1”を“/mnt/mmc1”にマウントする（Ｓ７０５）。なお、この例は、“/dev/mmcblk0p1”が“/mnt/mmc1”にマウントされることを想定している例であり、マウントポイントの具体的パス名は任意である。このようなマウントが行われると、以降は、全アプリケーションで“/mnt/mmc1”以下のファイルが使用可能になり（Ｓ７１０）、図７（ｂ）に示すディスクの使用再開処理が完了する。そして、図７（ｂ）に示すディスクの使用再開処理が完了すると、図５のＳ４４０が完了するので、これにて図５に示すディスクの再初期化処理全てが完了する。

以上説明したように、上記のようなアプリケーションＡ１では、“sfdisk”の実行後、フラッシュデバイス処理を行ってブロックデバイスアクセス用カーネルモジュール１３の管理下にあるデータをデーモンプロセス１５へと引き渡している。しかも、動作完了確認ツールＡ５でデーモンプロセス１５の管理下にあるデータが、全てデバイスに書き込まれたことを確認してから、“mkfs”を実行している。

したがって、このような確認をすることなく“sfdisk”や“mkfs”を連続的に実行するものや、“sfdisk”の実行後にフラッシュデバイス処理は行うものの、デーモンプロセス１５の動作状況を確認することなく“mkfs”を実行するものなどとは異なり、ディスク上に生じた不整合なデータが残っているうちに、新たなコマンドが実行されてしまうことがなく、また、それを防止するために、経験則に基づく不確実な様子見を過剰に長時間にわたって行う必要もない。

ちなみに、上記実施形態においては、フラグflagが、本発明でいう第一記憶手段に相当する。また、カウンタｒ３，ｗ３が、それぞれ本発明でいう第二記憶手段に相当する。
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。

１・・・コンピュータ、２・・・ＭＭＣデバイス、１１・・・ファイルシステム、１３・・・ブロックデバイスアクセス用カーネルモジュール、１５・・・ＭＭＣ用デーモンプロセス、１７・・・ＳＤＩＯバスドライバ、１８・・・Ｉ／Ｏスケジューラ、１９・・・Ｉ／Ｆハードウェア、Ａ１〜Ａ３・・・アプリケーション、Ａ４・・・特殊アプリケーション、Ａ５・・・動作完了確認ツール。

Claims (4)

1. オペレーティングシステムによって制御されるコンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたブロックデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるとともに、当該コマンドが前記コンピュータに接続されたＭＭＣ（Multi Media Card）デバイスに対するデータのリード又はライトを要求するコマンドであった場合には、当該コマンドを所定のキューに格納するブロックデバイスアクセス用カーネルモジュールと、
   前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記ブロックデバイスアクセス用カーネルモジュールによって前記コマンドが前記キューに格納された場合に、当該キューから前記コマンドを取得するデーモンプロセスと、
   前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスが前記キューから前記コマンドを取得した場合に、当該コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、
   前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記キューに前記コマンドが格納されている可能性がある状態及び当該可能性がない状態、いずれの状態であるのかを示す情報が、前記デーモンプロセスによって書き込まれて当該情報を記憶する第一記憶手段と、
   前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、
   前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部と
   を備え、
   前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされている
   ことを特徴とするデバイス制御システム。
2. 前記第二記憶手段は、
   前記通信用インターフェース部を介して前記デーモンプロセスから前記デバイスへ前記コマンドを伝送する直前に、所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれる第一カウンタと、
   前記通信用インターフェース部を介して前記デーモンプロセスから前記デバイスへ前記コマンドを伝送した後、当該コマンドに対応する処理が完了した直後に、所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれる第二カウンタと
   を備えることを特徴とする請求項１に記載のデバイス制御システム。
3. 前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記キューに格納された前記コマンドの処理順を管理、最適化するスケジューラを備えており、
   前記第一記憶手段には、前記スケジューラによって前記キューに対するアクセスが行われている場合に、前記コマンドが格納されている可能性がある状態を示す情報が、前記デーモンプロセスによって書き込まれる
   ことを特徴とする請求項１又は請求項２に記載のデバイス制御システム。
4. オペレーティングシステムによって制御されるコンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたブロックデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるとともに、当該コマンドが前記コンピュータに接続されたＭＭＣ（Multi Media Card）デバイスに対するデータのリード又はライトを要求するコマンドであった場合には、当該コマンドを所定のキューに格納するブロックデバイスアクセス用カーネルモジュールと、
   前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記ブロックデバイスアクセス用カーネルモジュールによって前記コマンドが前記キューに格納された場合に、当該キューから前記コマンドを取得するデーモンプロセスと、
   前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスが前記キューから前記コマンドを取得した場合に、当該コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、
   前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記キューに前記コマンドが格納されている可能性がある状態及び当該可能性がない状態、いずれの状態であるのかを示す情報が、前記デーモンプロセスによって書き込まれて当該情報を記憶する第一記憶手段と、
   前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、
   前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部と
   を備えるデバイス制御システムが機能する前記コンピュータを、さらに、前記コンピュータ上のユーザ空間において作動するプロセスとして機能させるプログラムであって、
   前記コンピュータを、
   前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取る読取手段、
   前記読取手段によって読み取った情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定する判定手段、及び
   前記判定手段による判定結果を、前記コンピュータ上のユーザ空間において作動する他のプロセスへ提供する情報提供手段
   として機能させることを特徴とするプログラム。

Images