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

Description

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

近年、ＵＳＢ（Universal Serial Bus）マスストレージデバイス、ＩＣカードで知られているＭＭＣ（Multi Media Card）デバイス、ＳＤ（Secure Digital）メモリカードデバイスなどが広く普及している。また、これらのデバイスを、Linux（登録商標）が搭載されたコンピュータで制御することも行われている。例えば、下記特許文献１には、ＵＳＢマスストレージデバイスをLinux搭載コンピュータで制御する技術が提案されている（例えば、特許文献１参照。）。また、ＳＤメモリカードは、ＭＭＣの一種としても扱われている。（以下、ＭＭＣ／ＳＤメモリカードを、単にＭＭＣと称す。）
ところで、Linuxが搭載されたコンピュータで、上述のような各種ストレージデバイス（ＵＳＢマスストレージデバイス、ＭＭＣデバイス）を制御する際、コンピュータ上のカーネル空間では、デバイスドライバとデーモンプロセスが協働して必要な処理を実行している。

以下、ＳＤメモリカードデバイスの場合を例に説明を続ける。コンピュータ上のユーザ空間において作動するアプリケーションソフトウェアが、ＳＤメモリカードデバイス上にあるファイルをオープンすると、その情報はファイルシステム経由でデバイスドライバ（ＭＭＣドライバ）へと伝達される。このとき、デバイスドライバでは、オープンされたファイルごとにハンドルが確保される。

そして、アプリケーションソフトウェアからリードコマンド又はライトコマンドが発行されると、それらのコマンドがファイルシステム経由でデバイスドライバへと伝達される。このとき、デバイスドライバに伝達されたコマンドは、ハンドルごとの固有データとして確保されるコマンドスタックに積まれることとなる。

デーモンプロセスは、デバイスドライバによって確保された全てのハンドルを対象に、それら全てのハンドルに対応するコマンドスタックの中に格納されたコマンドを、適当な順序で取り出して処理してゆく。その結果、それらのコマンドが、ＳＤＩＯバスドライバ等によって構成される通信用インターフェース部を介してＳＤメモリカードデバイスへと伝達されることになる。

このような制御が行われる際、デバイスドライバは、コマンドがコマンドスタックに積まれた後、デーモンプロセスでの処理の完了を待たずに、呼び出し元のアプリケーションソフトウェアにリターンする。そのため、デーモンプロセスによって実行される処理は、アプリケーションソフトウェア側から見て、デバイスドライバからの応答よりも遅延したタイミングで実行される遅延処理となる。

このような遅延処理が行われれば、デバイスドライバは、デーモンプロセスによって実行される実際の処理が完了するのを待つことなくアプリケーションに応答を返し、その後は、別の処理を実行可能ともなるので、デバイスドライバでの処理効率が向上する。

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

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

より詳しく説明すると、フォーマット処理での遅延書き込みが完了する前に、マウント処理が実行されると、管理領域データの書き込みが完了していないにもかかわらず、マウント処理において管理領域データが読み出されてしまう可能性がある。この場合、マウント処理では、フォーマット不正のストレージデバイスと認識されてしまうおそれがある。

しかも、そのようなエラーが発生した直後に、フォーマット処理の遅延書き込みが完了して管理領域が正しい状態になると、フォーマット不正ではない状態に更新されてしまうので、エラーの発生原因を事後的に解析することがきわめて難しいという問題がある。

この他、例えば、アプリケーションソフトウェア側でコンピュータの電源を切る場合にも、ストレージデバイスへの遅延書き込みが完了する前に電源を切ってしまうと、遅延書き込み予定となっていたデータの損失を招くおそれがある。

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

しかし、Linuxが搭載されたコンピュータでは、アプリケーションソフトウェア側からデーモンプロセスによる遅延処理が完了したか否かを確認できるような手段が用意されていない、という問題がある。

そのため、現状では、アプリケーションソフトウェアによって上述のようなフォーマット処理やマウント処理、あるいは電源断処理を行うに当たっては、遅延書き込みの完了が期待できる程度まで十分に待ってから、次の処理を行ったり電源を切ったりする、といった対策を取らざるを得ないのが実情であった。

また、このような対策を取ることならできるものの、どの程度待てば遅延書き込みが完了するのかは、単なる経験則に基づく想定に過ぎず、何ら保証される時間が規定されているわけではないので、非常に不確実な対策にしかなり得ないという問題があった。

さらに、多くの場合は、ごく短時間（例えば１秒足らず）だけ待てば遅延書き込みが完了しており、遅延書き込みが完了するまでに長時間（例えば２０秒程度）を要するのは、ごくまれなケースに過ぎない。しかし、このようなまれなケースにも対処するためには、常に十分に長時間（例えば３０秒程度）が経過してからしか、次の処理を行ったり電源を切ったりすることができないため、非常に効率が悪いという問題もあった。

こうした背景のもと、本件発明者らは、ＭＭＣドライバを改修することにより、デーモンプロセスによる遅延処理の完了をより確実に検知することも可能となるのではないかと考えた。

しかし、ＭＭＣドライバの場合、ブロックデバイスアクセス用カーネルモジュールが備える汎用ルーチンをそのまま流用してドライバが構成されている。そのため、ＭＭＣドライバの機能改良のために、ブロックデバイスアクセス用カーネルモジュールのルーチンを修正するとしても、その修正量は最小限にとどめることが好ましいという実情がある。特に、既存のブロックデバイスアクセス用カーネルモジュールでは、所定のデータ構造を持つデータ格納領域を確保して利用しているが、上記のような改修に伴って、既存のデータ格納領域のデータ構造が変更されてしまうと、改修前のデータ構造を前提としてデータ格納領域にアクセスするモジュールでは、何らかのトラブルを誘発するおそれがある。

本発明は、上記のような諸問題を勘案して、これらの問題を解決するためになされたものであり、その目的は、デバイスドライバとデーモンプロセスが協働してＭＭＣデバイス又はＳＤメモリカードデバイスを制御するデバイス制御システムにおいて、ブロックデバイスアクセス用カーネルモジュールが確保する既存のデータ格納領域のデータ構造については維持したまま、新たな情報収集を可能とするとともに、その収集した情報をアプリケーションソフトウェア側に提供することで、デーモンプロセスでの処理が完了したか否かをアプリケーションソフトウェア側からでも確実に検知可能とすることにある。

以下、本発明において採用した構成について説明する。
請求項１に記載のデバイス制御システムによれば、ブロックデバイスアクセス用カーネルモジュールからデーモンプロセスへコマンドが伝達される際、その旨を示す情報が、ブロックデバイスアクセス用カーネルモジュールによって第一記憶手段に書き込まれる。また、デーモンプロセスから通信用インターフェース部を介してデバイスへのコマンドの伝送が完了した際、その旨を示す情報が、デーモンプロセスによって第二記憶手段に書き込まれる。さらに、コンピュータには、これら第一記憶手段及び第二記憶手段に記憶された情報を、コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部が設けられている。

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

また、このデバイス制御システムにおいて、ブロックデバイスアクセス用カーネルモジュールによって情報が書き込まれて当該情報を記憶する第一記憶手段は、コンピュータ上のカーネル空間において所定用途で使用するためにリザーブ済みとなっているリザーブ済み記憶領域のうち、所定用途での使用時にも未使用のまま残されることとなる余剰記憶領域を利用して構成されている。

そのため、このような第一記憶手段を設けるための改修をブロックデバイスアクセス用カーネルモジュールに対して施しても、既存のリザーブ済み記憶領域とは別の新たな記憶領域を第一記憶手段として確保しなくても済む。したがって、ブロックデバイスアクセス用カーネルモジュールの改修前には、上述のリザーブ済み記憶領域を含むいくつかの記憶領域で構成されていたデータ構造が、改修に伴ってさらに上述の新たな記憶領域をも含むデータ構造に変わってしまうことはなく、改修前のデータ構造を前提としてリザーブ済み記憶領域にアクセスするモジュールにおいてトラブルを誘発するおそれがない。

ところで、本発明のデバイス制御システムにおいて、リザーブ済み記憶領域の具体例は種々考え得るが、より具体的な一例を挙げれば、請求項２に記載のデバイス制御システムのように構成するとよい。

例えば、Linuxをオペレーティングシステムとして備えるコンピュータの場合、ブロックデバイスに対して付与されるディスクネームが文字列として格納される記憶領域としては、３２バイト分の記憶領域がリザーブ済みである。しかし、Linuxの現状の仕様では、最も長いディスクネームでも最大８バイトであり、その文字列の終端を示す１バイトのコードを加味しても、先頭から１０バイト目以降の記憶領域は、未使用のまま残される記憶領域になっている。したがって、このような未使用記憶領域を利用して第一記憶手段を構成すれば、既存のブロックデバイスアクセス用カーネルモジュールが確保していたデータ記憶領域以外に新たな記憶領域を追加で確保しなくても済む。

また、請求項３に記載のデバイス制御システムのような判定を行えば、アクセス対象がＭＭＣデバイスではないにもかかわらず、第一記憶手段に無用な情報を書き込んでしまうことはなく、その分、ブロックデバイスアクセス用カーネルモジュールでの処理効率が向上する。

また、請求項４に記載のデバイス制御システムのような判定を行えば、何らかの事情で、未使用領域と想定された範囲に達する長い文字列がリザーブ済み記憶領域に格納されていたとしても、その場合は、第一記憶手段に情報を書き込まないので、格納された文字列を壊すようなトラブルを招くことがない。

さらに、本発明のデバイス制御システムにおいて、第一記憶手段及び第二記憶手段に格納される情報の具体例は様々なものを考え得るが、一例としては、請求項５に記載のデバイス制御システムのような構成を採用すると好ましい。この場合、第一記憶手段及び第二記憶手段それぞれに記憶されたカウンタ値が一致していれば、遅延処理が完了していると判断できる。また、この場合、カウンタ値はコマンドの発行回数に応じた値となるので、コマンドの発行回数をユーザ空間において作動するプロセス（例えば、アプリケーションソフトウェアのプロセス）側で検証することもできる。

以上のようなデバイス制御システムは、ブロックデバイスアクセス用カーネルモジュールから発行されるコマンドが、いったんデーモンプロセスに伝達されて、そのデーモンプロセスにおいて遅延処理が行われることとなるコンピュータであれば採用できるが、そのようなコンピュータの代表例としては、Linuxをオペレーティングシステムとして備えるコンピュータを挙げることができる。

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

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

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

コンピュータが備えるデバイス制御システムの構成を示すブロック図。 ブロックデバイスアクセス用カーネルモジュール内リード・ライトコマンドスタック追加処理のフローチャート。 デーモンプロセスにおける処理のフローチャート。 動作完了確認ツールにおける処理のフローチャート。 ディスクの再初期化処理のフローチャート。 ディスクの使用停止処理のフローチャート。 （ａ）はフラッシュデバイス処理のフローチャート、（ｂ）はディスクの使用再開処理のフローチャート。 （ａ）は/proc/driver/bil-mmci処理のフローチャート、（ｂ）は/procから取得する情報の一例を示す説明図。

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

コンピュータ１は、ＯＳとしてLinuxが搭載されたものであり、このＯＳの機能により、コンピュータ１上には、ＯＳによって管理されるカーネル空間及びユーザ空間が構成されている。これらのうち、ユーザ空間では、アプリケーションＡ１〜Ａ３、sfdisk，mkfsなどの特殊アプリケーションＡ４、動作完了確認ツールＡ５などが機能する。

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

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

ブロックデバイスアクセス用カーネルモジュール１３は、各種ブロックデバイスを制御するために、ＯＳが標準的に備えているソフトウェアである。デバイス制御システムに関連する機能としては、ＭＭＣデバイス２を制御するためのデバイスドライバも、上記ブロックデバイスアクセス用カーネルモジュール１３を流用して構成されている。そのため、アプリケーションＡ１などからＭＭＣデバイス２に対するデータのリード又はライトを要求するコマンドが発行された場合、そのコマンドはブロックデバイスアクセス用カーネルモジュール１３へと伝達される。

ブロックデバイスアクセス用カーネルモジュール１３は、自身が制御対象としているデバイスに対応する記憶領域を確保し、その記憶領域にブロックデバイス汎用デバイス固有データ１３Ａを格納する。デバイス制御システムに関連するデータとしては、複数のデータを備えるデータ構造とされたgendisk構造体が、ブロックデバイス汎用デバイス固有データ１３Ａ内に確保される。このgendisk構造体の中には、構造体メンバとして、３２バイト分の記憶領域であるディスクネーム記憶領域（disk_name[32]）や、デバイス番号記憶領域（デバイスを示すメジャー番号及びマイナー番号が格納される記憶領域）が含まれている。

また、ブロックデバイスアクセス用カーネルモジュール１３は、ファイルやデバイスに対するオープンコマンドが伝達されると、それに対応付けてハンドルと呼ばれる記憶領域（図１ではハンドルＨ１，Ｈ２を例示。）を確保し、その記憶領域にハンドル固有データ（図１ではハンドル固有データ１３Ｂ，１３Ｃを例示。）を格納する。

アプリケーションＡ１などからファイルシステム１１に対してファイルのオープンコマンドが発行された場合、オープンされたファイルに対応するデバイスをオープンするコマンドは、ファイルシステム１１からブロックデバイスアクセス用カーネルモジュール１３へと伝達される。また、アプリケーションの中には、デバイスに対して直接オープンコマンドを発行する特殊アプリケーションＡ４（例えば、sfdisk，mkfs。）などもあり、このような特殊アプリケーションＡ４からはブロックデバイスアクセス用カーネルモジュール１３へ直接コマンドが伝達される。

なお、図１では、図を簡潔にする都合上、単一のブロックデバイスアクセス用カーネルモジュール１３を図示してあるが、実際は、複数のデバイスがあれば、それら個々のデバイスそれぞれに対応する複数のデバイスドライバがコンピュータ１上で機能し、各デバイスドライバにおいてブロックデバイスアクセス用カーネルモジュール１３が利用される。

デーモンプロセス１５は、ブロックデバイスアクセス用カーネルモジュール１３同様、ＯＳの一部を構成するソフトウェアであり、上述のコマンドがブロックデバイスアクセス用カーネルモジュール１３へと伝達された際には、さらにブロックデバイスアクセス用カーネルモジュール１３からコマンドが伝達される。

また、デーモンプロセス１５も、記憶領域を確保し、その記憶領域にＭＭＣ用デバイス固有データ１５Ａを格納する。デバイス制御システムに関連するデータとしては、６個のカウンタ（ｒ１，ｒ２，ｒ３，ｗ１，ｗ２，ｗ３）が、ＭＭＣ用デバイス固有データ１５Ａ内に確保される。

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

さらに、このコンピュータ１においては、上述の６個のカウンタ（ｒ１，ｒ２，ｒ３，ｗ１，ｗ２，ｗ３）に格納された値を、ユーザ空間で作動するプロセスから読み取り可能とするため、/procバイパスを利用した情報公開用インターフェース部（本発明でいう情報公開用インターフェース部に相当。）を設けてある。

/procは、Linuxにおいて、ＯＳの管理下にあるリソース関連の情報（例えば、カーネル空間に確保された記憶領域に格納された値）を、ファイルと同様の手順で読み出し可能とするために用意された仮想的なファイルシステムである。

Linuxにおいて、ＭＭＣデバイス用の/procバイパスについては、ＯＳ標準での用意がないので、本実施形態では“/proc/driver/bil-mmci”を新設して、上述の６個のカウンタ値を読み出し可能としてある。

なお、このような/procバイパスは、本実施形態では、動作完了確認ツールＡ５によって利用される。動作完了確認ツールＡ５の詳細については後述する。
［ブロックデバイスアクセス用カーネルモジュールにおいて実行される処理］
次に、ブロックデバイスアクセス用カーネルモジュール１３において実行される処理について、図２のフローチャートに基づいて説明する。図２に示すリード・ライトコマンドスタック追加処理は、ＯＳ経由でブロックデバイスアクセス用カーネルモジュール１３へと伝達されるコマンドを対象に、そのコマンドに応じてブロックデバイスアクセス用カーネルモジュール１３が実行する処理である。

ブロックデバイスアクセス用カーネルモジュール１３へと伝達されるコマンドは、例えば、アプリケーションＡ１などのコマンド発行元プロセスが、ＯＳの提供するアプリケーションインターフェースを介してコマンドを発行したような場合に、ブロックデバイスアクセス用カーネルモジュール１３へと伝達されるものである。

図２に示す処理が実行されるタイミングは、多数のデバイスが並列処理できるようにするため、ＯＳによってコントロールされている。ブロックデバイスアクセス用カーネルモジュール１３は、デバイスハンドルをパラメータとして受け取っており、指定されたハンドル内にある「コマンドスタック」内に１以上のコマンドが積まれた際に、１つのコマンドを対象に図２に示す処理が実行される。

図２に示す処理を開始すると、ブロックデバイスアクセス用カーネルモジュール１３（正確には、ブロックデバイスアクセス用カーネルモジュール１３としての処理を実行するコンピュータ１；以下、単にカーネルモジュール１３という。）は、パラメータとして与えられる情報（リード要求、ライト要求の区別及びリード・ライトのバイト数）を受け取り、物理デバイスと１対１対応しているブロックデバイスの場合はgendisk構造体（本発明でいうリザーブ済み記憶領域に相当。）へのポインタも受け取る（Ｓ１０５）。

gendisk構造体は、ディスクデバイスに関する複数のデータを格納するためにＯＳが確保する汎用のデータ格納領域で、そのデータ構造はＯＳ側で定義されている。Ｓ１０５で受け取るgendisk構造体へのポインタは、ＯＳが確保したデータ格納領域のアドレスであり、物理デバイスと１対１対応しているブロックデバイスへのアクセス指令が上位モジュールにおいて発行された場合には、ＯＳによって確保されたgendisk構造体のアドレスが、上位モジュールから与えられることになる。

一方、物理デバイスと１対１対応しているブロックデバイス以外（例えばディスクデバイス上に設定されたパーティション）へのアクセス指令が上位モジュールにおいて発行された場合、上位モジュールからはgendisk構造体へのポインタが与えられない。

そこで、カーネルモジュール１３は、gendisk構造体へのポインタを受け取ったか否かを判断し（Ｓ１１０）、ＭＭＣデバイス２に対するリード・ライトコマンドが発行された可能性があるか否かを判断する。

具体的には、gendisk構造体へのポインタを受け取っていれば（Ｓ１１０：はい）、アクセス対象は、少なくとも物理デバイスと１対１対応しているブロックデバイスであると判断できる。したがって、ＭＭＣデバイス２に対するリード・ライトコマンドが発行された可能性もあり、そうであれば本デバイス制御システム特有の処理が必要となる可能性があるので、この場合は、Ｓ１１５へ進む。

一方、gendisk構造体へのポインタを受け取っていなければ（Ｓ１１０：いいえ）、アクセス対象は物理デバイスと１対１対応しているブロックデバイスではないと判断できる。したがって、ＭＭＣデバイス２に対するリード・ライトコマンドが発行された可能性はなく、本デバイス制御システム特有の処理は不要なので、この場合は、Ｓ１４０へ進む。

Ｓ１１５へ進んだ場合、カーネルモジュール１３は、デバイス番号（メジャー）がMMC_BLOCK_MAJORか否かを判断する（Ｓ１１５）。デバイス番号（メジャー）は、上述のgendisk構造体に含まれるメンバの一つに格納されるデータであり、あらかじめ定義されている定数であるMMC_BLOCK_MAJORであれば、ＭＭＣデバイス２に対するリード・ライトコマンドが発行されたものと判断できる。

そこで、Ｓ１１５では、デバイス番号（メジャー）がMMC_BLOCK_MAJORであれば（Ｓ１１５：はい）、Ｓ１２０へ進む一方、デバイス番号（メジャー）がMMC_BLOCK_MAJORでなければ（Ｓ１１５：いいえ）、Ｓ１４０へ進む。

さらに、Ｓ１２０へ進んだ場合、カーネルモジュール１３は、ディスクネームが２３文字以下か否かを判断する（Ｓ１２０）。ディスクネームも、上述のgendisk構造体に含まれるメンバの一つに格納されるデータである。

ＭＭＣデバイス２に対してＯＳが付与するディスクネームは、文字列“mmcblk”の末尾に１桁又は２桁の数字列“０”〜“３１”を付加してなる文字列“mmcblk0”〜“mmcblk31”とされることが、ＯＳの仕様として決まっている。したがって、これらのディスクネームは、現状の仕様では最大でも８文字以下であり、このディスクネームが格納されるgendisk構造体のメンバdisk_name[32]（文字型配列）の一部は、未使用領域として残されている。

そこで、このデバイス制御システムでは、上述の文字型配列disk_name[32]のうち、少なくとも末尾の８バイトが未使用領域として残されていれば、その未使用領域を利用することとし、Ｓ１２０では、ディスクネームが２３文字以下か否かを確認している。

ディスクネームが２３文字以下であることが確認できれば、その文字列の終端に文字列の終わりを示す制御コード（通常はＮＵＬＬ）が付加されていても、それらの格納に必要な記憶領域は２４バイト以下となるので、文字型配列disk_name[32]には、少なくとも８バイト以上の未使用領域が存在することになる。

そこで、Ｓ１２０では、ディスクネームが２３文字以下であれば（Ｓ１２０：はい）、Ｓ１２５へ進む一方、ディスクネームが２３文字超過であれば（Ｓ１２０：いいえ）、Ｓ１４０へ進む。

Ｓ１２５では、カーネルモジュール１３は、リード・ライト要求を判別する（Ｓ１２５）。そして、リード要求であった場合は（Ｓ１２５：リード要求）、文字型配列disk_name[32]の２４〜２７の４バイトを、３２ビット整数とみなしてインクリメントし、最上位ビットを０にする（Ｓ１３０）。

すなわち、このＳ１３０が実行されるたびに、３２ビット整数とみなされた４バイトの記憶領域では、整数値のインクリメントが行われ、しかも、常に最上位ビットを０にしているので、インクリメントに伴って最上位ビットが１になるタイミングで整数値が０に戻り、以降、再びインクリメントが継続される。

一方、Ｓ１２５において、ライト要求であった場合は（Ｓ１２５：ライト要求）、文字型配列disk_name[32]の２８〜３１の４バイトを、３２ビット整数とみなしてインクリメントし、最上位ビットを０にする（Ｓ１３５）。

すなわち、このＳ１３５が実行されるたびに、３２ビット整数とみなされた４バイトの記憶領域では、整数値のインクリメントが行われ、しかも、常に最上位ビットを０にしているので、インクリメントに伴って最上位ビットが１になるタイミングで整数値が０に戻り、以降、再びインクリメントが継続される。

このように、文字型配列disk_name[32]の２４〜３１の８バイトは、２つの３２ビット整数を格納する記憶領域として利用され、これら２つの３２ビット整数により、リード要求及びライト要求それぞれの発行回数をカウントする。つまり、ＭＭＣデバイス２に対するリード・ライト要求が発行された場合にのみ、リード要求及びライト要求それぞれの発行回数がカウントされるのである。

そして、Ｓ１３０又はＳ１３５によるカウントを終えたらＳ１４０へ進む。Ｓ１４０では、通常のリード・ライトコマンドスタック追加処理を実行する（Ｓ１４０）。このＳ１４０により、アクセス対象となるデバイスに対応したハンドル固有データ内のコマンドスタックには、リードコマンド又はライトコマンドが積まれることとなる。ただし、このＳ１４０は、Linuxにおける周知の処理なので、これ以上の詳細な説明については省略する。なお、Ｓ１４０を終えたら、図２に示すブロックデバイスアクセス用カーネルモジュール内リード・ライトコマンドスタック追加処理を終了する。

以上説明した通り、図２に示すブロックデバイスアクセス用カーネルモジュール内リード・ライトコマンドスタック追加処理では、ブロックデバイスアクセス用カーネルモジュール１３がすでに利用している既存の記憶領域である文字型配列disk_name[32]の未使用部分を利用して、リードコマンド及びライトコマンドの発行回数をカウントする。したがって、既存のデータ格納領域であるgendisk構造体に含まれるメンバを新たに追加しなくても、リードコマンド及びライトコマンドの発行回数を記憶でき、gendisk構造体のデータ構造を変更しなくてもよい。よって、gendisk構造体に新たなメンバを追加するような改修を加えた場合に比べ、既存のデータ構造を前提としてgendisk構造体にアクセスするモジュールで予期しないトラブルを誘発するのを抑制することができる。

［ＭＭＣ用デーモンプロセス１５において実行される処理］
次に、ＭＭＣ用デーモンプロセス１５（以下、単にデーモンプロセス１５と称する。）において実行される処理について、図３のフローチャートに基づいて説明する。デーモンプロセス１５は、ＭＭＣデバイス２の作動開始に伴って起動され、その後は、ＭＭＣデバイス２の作動が停止されるまでコンピュータ１に常駐する。図３に示す処理は、デーモンプロセス１５が起動されたときに開始される。

なお、以下、ディスクデバイスmmcblk0（/dev/mmcblk0）に対応するデーモンプロセス１５を例に挙げて説明を続けるが、mmcblk0は単なる一例として例示するものであり、別のディスクデバイス（mmcblk１〜mmcblk31のいずれか）であっても同様の処理となるのはもちろんである。

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

一方、Ｓ２１０において、ディスクデバイスmmcblk0が取り外されていないと判断された場合（Ｓ２１０：いいえ）、デーモンプロセス１５は、デバイス固有データから最初のオープン中ハンドルを取得する（Ｓ２１５）。

そして、オープン中のハンドルがない場合は（Ｓ２２０：はい）、Ｓ２０５へと戻る一方、オープン中のハンドルがある場合（Ｓ２２０：いいえ）、デーモンプロセス１５は、取得中ハンドルのコマンドスタックから１コマンドを取り出す（Ｓ２２５）。

続いて、デーモンプロセス１５は、取り出したコマンドの種別を判断し（Ｓ２３０）、コマンドがリードコマンドであった場合（Ｓ２３０：リード）、カウンタｒ２をインクリメントし、最上位ビットを０にする（Ｓ２３５）。

なお、カウンタｒ２は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２３５が実行されるたびにインクリメントされることになる。また、常に最上位ビットを０にしているので、インクリメントに伴って最上位ビットが１になるタイミングでカウンタ値が０に戻り、以降、再びインクリメントが継続される。

その後、デーモンプロセス１５は、ＭＭＣデバイス２に対してＭＭＣ形式リードコマンドを発行して完了を待つ（Ｓ２４０）。Ｓ２４０において、完了を待つ間は他のデバイスに時間を解放する。そして、ＭＭＣデバイス２からの完了応答が返されたら、カウンタｒ３をインクリメントし、最上位ビットを０にする（Ｓ２４５）。

なお、カウンタｒ３は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２４５が実行されるたびにインクリメントされることになる。また、常に最上位ビットを０にしているので、インクリメントに伴って最上位ビットが１になるタイミングでカウンタ値が０に戻り、以降、再びインクリメントが継続される。

一方、Ｓ２３０において、コマンドがライトコマンドであった場合（Ｓ２３０：ライト）、デーモンプロセス１５は、カウンタｗ２をインクリメントし、最上位ビットを０にする（Ｓ２５０）。

なお、カウンタｗ２は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２５０が実行されるたびにインクリメントされることになる。また、常に最上位ビットを０にしているので、インクリメントに伴って最上位ビットが１になるタイミングでカウンタ値が０に戻り、以降、再びインクリメントが継続される。

その後、デーモンプロセス１５は、ＭＭＣデバイス２に対してＭＭＣ形式ライトコマンドを発行し完了を待つ（Ｓ２５５）。Ｓ２５５において、完了を待つ間は他のデバイスに時間を解放する。ＭＭＣデバイス２からの完了応答が返されたら、カウンタｗ３をインクリメントし、最上位ビットを０にする（Ｓ２６０）。

なお、カウンタｗ３は、デーモンプロセス１５の作動開始時にＭＭＣ用デバイス固有データ１５Ａ内に確保されて初期化（ゼロクリア）されており、その後は、Ｓ２６０が実行されるたびにインクリメントされることになる。また、常に最上位ビットを０にしているので、インクリメントに伴って最上位ビットが１になるタイミングでカウンタ値が０に戻り、以降、再びインクリメントが継続される。

このようにしてＳ２４５又はＳ２６０を終えたら、デーモンプロセス１５は、ＭＭＣ用デバイス固有データ１５Ａから次のオープン中ハンドルを取得する（Ｓ２７０）。そして、オープン中のハンドルがない場合は（Ｓ２７５：はい）、Ｓ２０５へと戻る一方、オープン中のハンドルがある場合は（Ｓ２７５：いいえ）、Ｓ２２５へと戻る。

以上説明したように、図３に示した処理では、Ｓ２４０又はＳ２５５においてデバイスに対してリードコマンド又はライトコマンドが発行されることとなるたびに、その発行前後双方のタイミングとなるＳ２３５及びＳ２４５、もしくはＳ２５０及びＳ２６０において、カウンタｒ２及びカウンタｒ３、もしくはカウンタｗ２及びカウンタｗ３がインクリメントされる。

したがって、これらのカウンタｒ２、ｒ３、ｗ２、ｗ３には、デーモンプロセス１５におけるリード又はライトのＳＣＳＩコマンドの発行回数が、発行直前及び発行後の待機完了直後双方のタイミングで蓄積・保持されることになる。

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

より詳しく説明すると、/proc/driver/bil-mmci処理を開始すると、コンピュータ１は、まず、図８（ｂ）に示すような情報のうち、先頭２行にある情報「ＢＩＬ−ＭｍｃＩｎｆｏ：〜」を出力する（Ｓ９０５）。そして、カウンタＮに０（ゼロ）をセットして（Ｓ９０７）、ディスクデバイス“mmcblkN”（Ｎは０〜３の整数）があるか否かを判断する（Ｓ９１０）。

本実施形態においては、“mmcblk0〜mmcblk3”までをサポートしており、そのためＮは０〜３の整数とされているが、このカウンタＮの最大値は３以上とされていてもよい。
Ｓ９１０において、ディスクデバイス“mmcblkN”（Ｎは０〜３の整数）があった場合（Ｓ９１０：ある）、コンピュータ１は、ブロックデバイス汎用デバイス固有データ１３Ａ中に含まれるgendisk構造体中の文字型配列disk_name[32]を参照する（Ｓ９１５）。そして、文字型配列disk_name[32]に格納されたディスクネームが２３文字以下であるか否かを判断する（Ｓ９２０）。

Ｓ９２０において、ディスクネームが２３文字を超過している場合（Ｓ９２０：いいえ）、上述したＳ１３０又はＳ１３５によるカウント（図２参照。）が実施されていないので、この場合は、カウンタｒ１とｗ１に、無効値であることを示す定数0xF0010002（３２ビット整数）を代入する（Ｓ９２５）。

一方、Ｓ９２０において、ディスクネームが２３文字以下であった場合（Ｓ９２０：はい）、文字型配列disk_name[32]の２４〜２７の４バイトを、３２ビット整数とみなしてカウンタｒ１に代入し（Ｓ９３０）、同じく文字型配列disk_name[32]の２８〜３１の４バイトを、３２ビット整数とみなしてカウンタｗ１に代入する（Ｓ９３５）。

すなわち、これらＳ９３０及びＳ９３５により、Ｓ１３０及びＳ１３５でカウントされた値は（図２参照。）、それぞれカウンタｒ１，ｗ１に代入されることとなる。したがって、Ｓ１３０及びＳ１３５において、カウンタｒ１，ｗ１のインクリメントを実施することはできないものの、Ｓ９３０及びＳ９３５が実行されることで、カウンタｒ１，ｗ１にリード・ライトコマンドの発行回数をセットすることができる。

また、上述のＳ２３５、Ｓ２４５、Ｓ２５０、及びＳ２６０において、カウンタｒ２、ｒ３、ｗ２、ｗ３にも値がセットされているので、これらの処理により、６個のカウンタ（ｒ１，ｒ２，ｒ３，ｗ１，ｗ２，ｗ３）全てに、リード・ライトコマンドの発行回数がセットされることになる。

こうしてＳ９２５又はＳ９３５を終えたら、コンピュータ１は、「BIL-MmcRdWrC:N〜」の行を出力する（Ｓ９４０）。図８（ｂ）に例示した情報の場合、Ｎ＝０となる行が出力されている。Ｓ９４０で出力される行には、図８（ｂ）に例示した通り、文字列“BIL-MmcRdWrC:”に引き続いて、ディスクネームの末尾の文字に相当する数字Ｎ、及び６個のカウンタ（ｒ１，ｒ２，ｒ３，ｗ１，ｗ２，ｗ３）の値が列挙される。

そして、Ｓ９４０を終えるか、Ｓ９１０でディスクデバイス“mmcblkN”（Ｎは０〜３の整数）がないと判断された場合は（Ｓ９１０：ない）、変数Ｎをインクリメントし（Ｓ９５０）、変数Ｎが３以下か否かを判断する（Ｓ９６０）。変数Ｎが３以下であれば（Ｓ９６０：はい）、Ｓ９１０へと戻る。これにより、Ｓ９１０以降の処理が繰り返され、Ｎ＝０〜３の順にディスクデバイス“mmcblkN”に対応する処理が繰り返される。そして、変数Ｎが３を超えたら（Ｓ９６０：いいえ）、/proc/driver/bil-mmci処理を終了する。

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

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

ただし、動作完了確認ツールＡ５は、“mmcblk0”以外のディスクデバイス（本実施形態であれば、mmcblk１〜mmcblk3のいずれか）を対象にして所期の処理を行うこともできる。

図４に示す処理を開始すると、動作完了確認ツールＡ５（正確には、動作完了確認ツールＡ５としての処理を実行するコンピュータ１；以下、単に動作完了確認ツールＡ５という。）は、“/proc/driver/bil-mmci”ファイルをオープンする（Ｓ３０５）。

ここで、“/proc/driver/bil-mmci”ファイルがない場合（Ｓ３１０：はい）、動作完了確認ツールＡ５は、図４に示す処理を終了する（mmcblk0が見つからない エラー終了）。

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

そこで、動作完了確認ツールＡ５は、読み込んだ情報中に含まれるキーワード“BIL-MmcRdWrC:”の最初の行を検索する（Ｓ３１５）。図８（ｂ）に例示する情報の場合、“BIL-MmcRdWrC:”の行には、ディスク名（図８（ｂ）では“０”）と上述の６個のカウンタ（ｒ１，ｒ２，ｒ３，ｗ１，ｗ２，ｗ３）に格納された値が列挙されている。

ここで、“BIL-MmcRdWrC:”の行が見つからなければ（Ｓ３１７：いいえ）、動作完了確認ツールＡ５は、図４に示す処理を終了する（mmcblk0が見つからない エラー終了）。一方、Ｓ３１７において、“BIL-MmcRdWrC:”の行が見つかれば（Ｓ３１７：はい）、その行の先頭の数値がディスク番号を示しているので（Ｓ３２０）、ディスク番号が０であるか否かを判断する（Ｓ３２５）。

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

また、Ｓ３２５において、ディスク番号が０であった場合は（Ｓ３２５：はい）、“mmcblk0”が接続中であることが確認されたことになる（Ｓ３４０）。そこで、この場合、動作完了確認ツールＡ５は、カウンタｒ１，ｗ１の最上位ビットが０か否かを判断する（Ｓ３４２）。

このＳ３４２では、“BIL-MmcRdWrC:”の行に含まれるカウンタｒ１，ｗ１の値がＳ９３０及びＳ９３５で代入された値となっていれば肯定判断がなされ、Ｓ９２５で代入された値となっていれば否定判断がなされることになる。

カウンタｒ１，ｗ１の最上位ビットが０ではなかった場合（Ｓ３４２：いいえ）、ディスクネームが２３文字を超過しており、その場合、カウンタｒ１，ｗ１に適正な値を代入できていないので、この場合、動作完了確認ツールＡ５をエラー終了する（ディスクネームエラー）。

一方、Ｓ３４２において、カウンタｒ１，ｗ１の最上位ビットが０であった場合は（Ｓ３４２：はい）、カウンタｒ１，ｗ１に適正な値を代入できている。
そこで、この場合は、タイムアウトのカウンタとして所定時間（例えば１分程度）を設定し（Ｓ３４５）、一定時間（例えば１００ｍｓ）が経過するのを待つ（Ｓ３５０）。その後、タイムアウトのカウンタを上記一定時間分（上記例では１００ｍｓ）減らして（Ｓ３５５）、タイムアウトか否かを判断する（Ｓ３６０）。ここで、タイムアウトであった場合（Ｓ３６０：はい）、動作完了確認ツールＡ５は、図４に示す処理を終了する（タイムアウトエラー終了）。

一方、Ｓ３６０において、タイムアウトではない場合（Ｓ３６０：いいえ）、動作完了確認ツールＡ５は、ファイル“/proc/driver/bil-mmci”の“BIL-MmcRdWrC:0〜”の行から情報取得を行う（Ｓ３６５）。

そして、動作完了確認ツールＡ５は、カウンタｒ１，ｒ２，ｒ３の値が全て一致するか否かを判断する（Ｓ３７０）。ここで、カウンタｒ１，ｒ２，ｒ３の値が全て一致するのは、Ｓ１３０、Ｓ２３５〜Ｓ２４５が全て実行されている場合に該当する。

これは、ブロックデバイスアクセス用カーネルモジュール１３でコマンドスタックに積まれたリードコマンドが、デーモンプロセス１５でもＭＭＣデバイス２へと発行され、その応答がデバイスからデーモンプロセス１５へすでに返っていることを意味する。逆に、ブロックデバイスアクセス用カーネルモジュール１３でコマンドスタックに積まれたリードコマンドが、デーモンプロセス１５ではまだＭＭＣデバイス２へと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス１５からＭＭＣデバイス２へコマンドが発行されたものの、その応答がデバイスからデーモンプロセス１５へまだ返っていない場合も、上記カウンタ値は一致しない。

そこで、Ｓ３７０において、カウンタｒ１，ｒ２，ｒ３の値が一致しない場合は（Ｓ３７０：いいえ）、Ｓ３５０へと戻る。これにより、Ｓ３４５で設定した時間が経過するまでは、Ｓ３５０〜Ｓ３７０が繰り返されることになる。

一方、Ｓ３７０において、カウンタｒ１，ｒ２，ｒ３の値が全て一致した場合（Ｓ３７０：はい）、動作完了確認ツールＡ５は、カウンタｗ１，ｗ２，ｗ３が全て一致するか否かを判断する（Ｓ３７５）。ここで、カウンタｗ１，ｗ２，ｗ３の値が全て一致するのは、Ｓ１３５、Ｓ２５０〜Ｓ２６０が全て実行されている場合に該当する。

これは、ブロックデバイスアクセス用カーネルモジュール１３でコマンドスタックに積まれたライトコマンドが、デーモンプロセス１５でもＭＭＣデバイス２へと発行され、その応答がデバイスからデーモンプロセス１５へすでに返っていることを意味する。逆に、ブロックデバイスアクセス用カーネルモジュール１３でコマンドスタックに積まれたライトコマンドが、デーモンプロセス１５ではまだＭＭＣデバイス２へと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス１５からＭＭＣデバイス２へコマンドが発行されたものの、その応答がデバイスからデーモンプロセス１５へまだ返っていない場合も、上記カウンタ値は一致しない。

そこで、Ｓ３７５において、カウンタｗ１，ｗ２，ｗ３の値が一致しない場合は（Ｓ３７５：いいえ）、Ｓ３５０へと戻る。これにより、Ｓ３４５で設定した時間が経過するまでは、Ｓ３５０〜Ｓ３７５が繰り返されることになる。

したがって、リード又はライトいずれかのコマンドが完全にデバイスへと伝わらない限り、Ｓ３５０〜Ｓ３７５が繰り返され、その繰り返しの中でタイムアウトとなった場合には（Ｓ３６０：はい）、タイムアウトでエラー終了となるのである。

一方、Ｓ３７０において、カウンタｒ１，ｒ２，ｒ３の値が全て一致し（Ｓ３７０：はい）、且つＳ３７５において、カウンタｗ１，ｗ２，ｗ３の値が全て一致した場合（Ｓ３７５：はい）、動作完了確認ツールＡ５は、図４に示す処理を正常終了する。

以上説明したように、動作完了確認ツールＡ５は、リードコマンド及びライトコマンドがブロックデバイスアクセス用カーネルモジュール１３からデーモンプロセス１５経由でＭＭＣデバイス２へと伝達され、デバイスからの応答がデーモンプロセス１５へ返っている場合に正常終了する。また、リードコマンド及びライトコマンドがブロックデバイスアクセス用カーネルモジュール１３から発行されたものの、タイムアウトを待つ間にデバイスからの応答がデーモンプロセス１５へ返る状態に至らなければエラー終了する。

正常終了したかエラー終了したかを示す情報は、動作完了確認ツールＡ５を起動した上位プロセス（例えば、アプリケーションなど）へと返される。したがって、上位プロセスでは、動作完了確認ツールＡ５を利用して、ＭＭＣデバイス２に対して発行したコマンドが、ブロックデバイスアクセス用カーネルモジュール１３やデーモンプロセス１５において処理済みとなっているか否かを確認することができる。

［アプリケーションにおいて実行される処理の例（その１）］
次に、上述のような動作完了確認ツールＡ５を利用するアプリケーションの一例を、図５〜図７のフローチャートに基づいて説明する。以下に説明するアプリケーションＡ１は、ディスクデバイス“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”を実行するものなどとは異なり、ディスク上に生じた不整合なデータが残っているうちに、新たなコマンドが実行されてしまうことがなく、また、それを防止するために、経験則に基づく不確実な様子見を過剰に長時間にわたって行う必要もない。

ちなみに、上記実施形態においては、文字型配列disk_name[32]中の８バイト分の未使用領域（２４〜２７バイト、２８〜３１バイト）が、本発明でいう第一記憶手段に相当する。また、カウンタｒ３，ｗ３が、それぞれ本発明でいう第二記憶手段に相当する。

以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。

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

Claims (6)

1. オペレーティングシステムによって制御されるコンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたブロックデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるブロックデバイスアクセス用カーネルモジュールと、
   前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたＭＭＣ（Multi Media Card）デバイスに対するデータのリード又はライトを要求するコマンドが発行され、当該コマンドが前記コマンド発行元プロセスから前記ブロックデバイスアクセス用カーネルモジュールへと伝達された場合に、前記ブロックデバイスアクセス用カーネルモジュールから前記コマンドが伝達されるデーモンプロセスと、
   前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、
   前記コンピュータ上のカーネル空間において所定用途で使用するためにリザーブ済みとなっているリザーブ済み記憶領域のうち、前記所定用途での使用時にも未使用のまま残されることとなる余剰記憶領域を利用して構成され、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記ブロックデバイスアクセス用カーネルモジュールによって書き込まれて当該情報を記憶する第一記憶手段と、
   前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、
   前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部と
   を備え、
   前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされている
   ことを特徴とするデバイス制御システム。
2. 前記リザーブ済み記憶領域は、個々の前記ブロックデバイスを一意に識別可能とするために、前記オペレーティングシステムによって前記ブロックデバイスに対して付与されるディスクネームが文字列として格納される記憶領域であり、
   前記余剰記憶領域は、前記オペレーティングシステムが付与し得る最多文字数の前記ディスクネームが前記リザーブ済み記憶領域に格納されたときにも、未使用のまま残されることとなる記憶領域である
   ことを特徴とする請求項１に記載のデバイス制御システム。
3. 前記ブロックデバイスアクセス用カーネルモジュールは、前記第一記憶手段に情報を書き込む前に、アクセス対象が前記ＭＭＣデバイスであるか否かを判定し、アクセス対象が前記ＭＭＣデバイスであると判定された場合には、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報を前記第一記憶手段に書き込む
   ことを特徴とする請求項１又は請求項２に記載のデバイス制御システム。
4. 前記ブロックデバイスアクセス用カーネルモジュールは、前記第一記憶手段に情報を書き込む前に、前記リザーブ済み記憶領域に格納された文字列が所定の文字数以下か否かを判定し、前記リザーブ済み記憶領域に格納された文字列が所定の文字数以下であると判定された場合には、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報を前記第一記憶手段に書き込む
   ことを特徴とする請求項１〜請求項３のいずれか一項に記載のデバイス制御システム。
5. 前記第一記憶手段は、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達されるたびに、所定値を加算又は減算した値に更新されるカウンタ値が、前記ブロックデバイスアクセス用カーネルモジュールによって書き込まれ、
   前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、前記所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれる
   ことを特徴とする請求項１〜請求項４のいずれか一項に記載のデバイス制御システム。
6. オペレーティングシステムによって制御されるコンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたブロックデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるブロックデバイスアクセス用カーネルモジュールと、
   前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたＭＭＣ（Multi Media Card）デバイスに対するデータのリード又はライトを要求するコマンドが発行され、当該コマンドが前記コマンド発行元プロセスから前記ブロックデバイスアクセス用カーネルモジュールへと伝達された場合に、前記ブロックデバイスアクセス用カーネルモジュールから前記コマンドが伝達されるデーモンプロセスと、
   前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、
   前記コンピュータ上のカーネル空間において所定用途で使用するためにリザーブ済みとなっているリザーブ済み記憶領域のうち、前記所定用途での使用時にも未使用のまま残されることとなる余剰記憶領域を利用して構成され、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記ブロックデバイスアクセス用カーネルモジュールによって書き込まれて当該情報を記憶する第一記憶手段と、
   前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、
   前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部と
   を備えるデバイス制御システムが機能する前記コンピュータを、さらに、前記コンピュータ上のユーザ空間において作動するプロセスとして機能させるプログラムであって、
   前記コンピュータを、
   前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取る読取手段、
   前記読取手段によって読み取った情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定する判定手段、及び
   前記判定手段による判定結果を、前記コンピュータ上のユーザ空間において作動する他のプロセスへ提供する情報提供手段
   として機能させることを特徴とするプログラム。

Images