"オペレーティングシステムによって制御されるコンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたブロックデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるブロックデバイスアクセス用カーネルモジュールと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたMMCMultiMediaCardデバイスに対するデータのリード又はライトを要求するコマンドが発行され、当該コマンドが前記コマンド発行元プロセスから前記ブロックデバイスアクセス用カーネルモジュールへと伝達された場合に、前記ブロックデバイスアクセス用カーネルモジュールから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間において所定用途で使用するためにリザーブ済みとなっているリザーブ済み記憶領域のうち、前記所定用途での使用時にも未使用のまま残されることとなる余剰記憶領域を利用して構成され、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記ブロックデバイスアクセス用カーネルモジュールによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備え、前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされていることを特徴とするデバイス制御システム。前記リザーブ済み記憶領域は、個々の前記ブロックデバイスを一意に識別可能とするために、前記オペレーティングシステムによって前記ブロックデバイスに対して付与されるディスクネームが文字列として格納される記憶領域であり、前記余剰記憶領域は、前記オペレーティングシステムが付与し得る最多文字数の前記ディスクネームが前記リザーブ済み記憶領域に格納されたときにも、未使用のまま残されることとなる記憶領域であることを特徴とする請求項1に記載のデバイス制御システム。前記ブロックデバイスアクセス用カーネルモジュールは、前記第一記憶手段に情報を書き込む前に、アクセス対象が前記MMCデバイスであるか否かを判定し、アクセス対象が前記MMCデバイスであると判定された場合には、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報を前記第一記憶手段に書き込むことを特徴とする請求項1又は請求項2に記載のデバイス制御システム。前記ブロックデバイスアクセス用カーネルモジュールは、前記第一記憶手段に情報を書き込む前に、前記リザーブ済み記憶領域に格納された文字列が所定の文字数以下か否かを判定し、前記リザーブ済み記憶領域に格納された文字列が所定の文字数以下であると判定された場合には、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報を前記第一記憶手段に書き込むことを特徴とする請求項1~請求項3のいずれか一項に記載のデバイス制御システム。前記第一記憶手段は、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達されるたびに、所定値を加算又は減算した値に更新されるカウンタ値が、前記ブロックデバイスアクセス用カーネルモジュールによって書き込まれ、前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、前記所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれることを特徴とする請求項1~請求項4のいずれか一項に記載のデバイス制御システム。オペレーティングシステムによって制御されるコンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたブロックデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるブロックデバイスアクセス用カーネルモジュールと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたMMCMultiMediaCardデバイスに対するデータのリード又はライトを要求するコマンドが発行され、当該コマンドが前記コマンド発行元プロセスから前記ブロックデバイスアクセス用カーネルモジュールへと伝達された場合に、前記ブロックデバイスアクセス用カーネルモジュールから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間において所定用途で使用するためにリザーブ済みとなっているリザーブ済み記憶領域のうち、前記所定用途での使用時にも未使用のまま残されることとなる余剰記憶領域を利用して構成され、前記ブロックデバイスアクセス用カーネルモジュールから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記ブロックデバイスアクセス用カーネルモジュールによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備えるデバイス制御システムが機能する前記コンピュータを、さらに、前記コンピュータ上のユーザ空間において作動するプロセスとして機能させるプログラムであって、前記コンピュータを、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取る読取手段、前記読取手段によって読み取った情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定する判定手段、及び前記判定手段による判定結果を、前記コンピュータ上のユーザ空間において作動する他のプロセスへ提供する情報提供手段として機能させることを特徴とするプログラム。しかし、アプリケーションソフトウェアが、連続的に複数の処理を実行した際に、先に実行した処理で上述のような遅延処理が生じていると、それに起因して後から実行する処理でエラーが発生することがある。例えば、アプリケーションソフトウェアが、先にストレージデバイスのフォーマット処理を実行し、引き続いてフォーマット後のファイルシステムのマウント処理を連続的に行うと、上述のような遅延処理に起因した問題を招くおそれがある。より詳しく説明すると、フォーマット処理での遅延書き込みが完了する前に、マウント処理が実行されると、管理領域データの書き込みが完了していないにもかかわらず、マウント処理において管理領域データが読み出されてしまう可能性がある。この場合、マウント処理では、フォーマット不正のストレージデバイスと認識されてしまうおそれがある。しかも、そのようなエラーが発生した直後に、フォーマット処理の遅延書き込みが完了して管理領域が正しい状態になると、フォーマット不正ではない状態に更新されてしまうので、エラーの発生原因を事後的に解析することがきわめて難しいという問題がある。この他、例えば、アプリケーションソフトウェア側でコンピュータの電源を切る場合にも、ストレージデバイスへの遅延書き込みが完了する前に電源を切ってしまうと、遅延書き込み予定となっていたデータの損失を招くおそれがある。こうした問題を解消するには、アプリケーションソフトウェアが、デーモンプロセスによる遅延処理の完了を確実に待ってから、次の処理要求をデバイスドライバやデーモンプロセスに伝達することが重要となる。しかし、Linuxが搭載されたコンピュータでは、アプリケーションソフトウェア側からデーモンプロセスによる遅延処理が完了したか否かを確認できるような手段が用意されていない、という問題がある。そのため、現状では、アプリケーションソフトウェアによって上述のようなフォーマット処理やマウント処理、あるいは電源断処理を行うに当たっては、遅延書き込みの完了が期待できる程度まで十分に待ってから、次の処理を行ったり電源を切ったりする、といった対策を取らざるを得ないのが実情であった。また、このような対策を取ることならできるものの、どの程度待てば遅延書き込みが完了するのかは、単なる経験則に基づく想定に過ぎず、何ら保証される時間が規定されているわけではないので、非常に不確実な対策にしかなり得ないという問題があった。さらに、多くの場合は、ごく短時間例えば1秒足らずだけ待てば遅延書き込みが完了しており、遅延書き込みが完了するまでに長時間例えば20秒程度を要するのは、ごくまれなケースに過ぎない。しかし、このようなまれなケースにも対処するためには、常に十分に長時間例えば30秒程度が経過してからしか、次の処理を行ったり電源を切ったりすることができないため、非常に効率が悪いという問題もあった。こうした背景のもと、本件発明者らは、MMCドライバを改修することにより、デーモンプロセスによる遅延処理の完了をより確実に検知することも可能となるのではないかと考えた。しかし、MMCドライバの場合、ブロックデバイスアクセス用カーネルモジュールが備える汎用ルーチンをそのまま流用してドライバが構成されている。そのため、MMCドライバの機能改良のために、ブロックデバイスアクセス用カーネルモジュールのルーチンを修正するとしても、その修正量は最小限にとどめることが好ましいという実情がある。特に、既存のブロックデバイスアクセス用カーネルモジュールでは、所定のデータ構造を持つデータ格納領域を確保して利用しているが、上記のような改修に伴って、既存のデータ格納領域のデータ構造が変更されてしまうと、改修前のデータ構造を前提としてデータ格納領域にアクセスするモジュールでは、何らかのトラブルを誘発するおそれがある。本発明は、上記のような諸問題を勘案して、これらの問題を解決するためになされたものであり、その目的は、デバイスドライバとデーモンプロセスが協働してMMCデバイス又はSDメモリカードデバイスを制御するデバイス制御システムにおいて、ブロックデバイスアクセス用カーネルモジュールが確保する既存のデータ格納領域のデータ構造については維持したまま、新たな情報収集を可能とするとともに、その収集した情報をアプリケーションソフトウェア側に提供することで、デーモンプロセスでの処理が完了したか否かをアプリケーションソフトウェア側からでも確実に検知可能とすることにある。以下、本発明において採用した構成について説明する。請求項1に記載のデバイス制御システムによれば、ブロックデバイスアクセス用カーネルモジュールからデーモンプロセスへコマンドが伝達される際、その旨を示す情報が、ブロックデバイスアクセス用カーネルモジュールによって第一記憶手段に書き込まれる。また、デーモンプロセスから通信用インターフェース部を介してデバイスへのコマンドの伝送が完了した際、その旨を示す情報が、デーモンプロセスによって第二記憶手段に書き込まれる。さらに、コンピュータには、これら第一記憶手段及び第二記憶手段に記憶された情報を、コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部が設けられている。そのため、コンピュータ上のユーザ空間において作動するプロセス例えば、アプリケーションソフトウェアのプロセスは、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取ることができ、それら読み取った情報に基づいて、デバイスへのコマンドの伝送が完了したか否かを判定できる。また、このデバイス制御システムにおいて、ブロックデバイスアクセス用カーネルモジュールによって情報が書き込まれて当該情報を記憶する第一記憶手段は、コンピュータ上のカーネル空間において所定用途で使用するためにリザーブ済みとなっているリザーブ済み記憶領域のうち、所定用途での使用時にも未使用のまま残されることとなる余剰記憶領域を利用して構成されている。そのため、このような第一記憶手段を設けるための改修をブロックデバイスアクセス用カーネルモジュールに対して施しても、既存のリザーブ済み記憶領域とは別の新たな記憶領域を第一記憶手段として確保しなくても済む。したがって、ブロックデバイスアクセス用カーネルモジュールの改修前には、上述のリザーブ済み記憶領域を含むいくつかの記憶領域で構成されていたデータ構造が、改修に伴ってさらに上述の新たな記憶領域をも含むデータ構造に変わってしまうことはなく、改修前のデータ構造を前提としてリザーブ済み記憶領域にアクセスするモジュールにおいてトラブルを誘発するおそれがない。ところで、本発明のデバイス制御システムにおいて、リザーブ済み記憶領域の具体例は種々考え得るが、より具体的な一例を挙げれば、請求項2に記載のデバイス制御システムのように構成するとよい。例えば、Linuxをオペレーティングシステムとして備えるコンピュータの場合、ブロックデバイスに対して付与されるディスクネームが文字列として格納される記憶領域としては、32バイト分の記憶領域がリザーブ済みである。しかし、Linuxの現状の仕様では、最も長いディスクネームでも最大8バイトであり、その文字列の終端を示す1バイトのコードを加味しても、先頭から10バイト目以降の記憶領域は、未使用のまま残される記憶領域になっている。したがって、このような未使用記憶領域を利用して第一記憶手段を構成すれば、既存のブロックデバイスアクセス用カーネルモジュールが確保していたデータ記憶領域以外に新たな記憶領域を追加で確保しなくても済む。また、請求項3に記載のデバイス制御システムのような判定を行えば、アクセス対象がMMCデバイスではないにもかかわらず、第一記憶手段に無用な情報を書き込んでしまうことはなく、その分、ブロックデバイスアクセス用カーネルモジュールでの処理効率が向上する。また、請求項4に記載のデバイス制御システムのような判定を行えば、何らかの事情で、未使用領域と想定された範囲に達する長い文字列がリザーブ済み記憶領域に格納されていたとしても、その場合は、第一記憶手段に情報を書き込まないので、格納された文字列を壊すようなトラブルを招くことがない。さらに、本発明のデバイス制御システムにおいて、第一記憶手段及び第二記憶手段に格納される情報の具体例は様々なものを考え得るが、一例としては、請求項5に記載のデバイス制御システムのような構成を採用すると好ましい。この場合、第一記憶手段及び第二記憶手段それぞれに記憶されたカウンタ値が一致していれば、遅延処理が完了していると判断できる。また、この場合、カウンタ値はコマンドの発行回数に応じた値となるので、コマンドの発行回数をユーザ空間において作動するプロセス例えば、アプリケーションソフトウェアのプロセス側で検証することもできる。以上のようなデバイス制御システムは、ブロックデバイスアクセス用カーネルモジュールから発行されるコマンドが、いったんデーモンプロセスに伝達されて、そのデーモンプロセスにおいて遅延処理が行われることとなるコンピュータであれば採用できるが、そのようなコンピュータの代表例としては、Linuxをオペレーティングシステムとして備えるコンピュータを挙げることができる。さらに、請求項6に記載のプログラムに基づいて、コンピュータを上記各手段として機能させるプロセスを作動させれば、当該プロセスが、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取り、読み取った情報に基づいてデバイスへのコマンドの伝送が完了したか否かを判定し、その判定結果を、コンピュータ上のユーザ空間において作動する他のプロセスへ提供する。したがって、このような判定結果を得るための処理を、他のプロセスが自ら実行できる仕組みを備えていなくても、他のプロセスは、上記判定結果を提供するプロセスを起動させて、そのプロセスから提供される判定結果を受け取ることができる。そして、他のプロセスでは、受け取った判定結果に基づいて、デバイスへのコマンドの伝送が完了したことを確認した後、引き続いて次の処理を実行できるので、デバイスへのコマンドの伝送が完了していないにもかかわらず、次の処理を実行してしまうのを未然に防止することができる。次に、本発明の実施形態について一例を挙げて説明する。[デバイス制御システムの構成]以下に例示するデバイス制御システムは、図1に示すように、コンピュータ1上で機能して、このコンピュータ1に接続されたMMCデバイス2を制御するシステムである。MMCデバイス2は、カードスロット2Aと、このカードスロット2Aに装填されるMMC/SDメモリカード2Bとで構成される。コンピュータ1は、OSとしてLinuxが搭載されたものであり、このOSの機能により、コンピュータ1上には、OSによって管理されるカーネル空間及びユーザ空間が構成されている。これらのうち、ユーザ空間では、アプリケーションA1~A3、sfdisk,mkfsなどの特殊アプリケーションA4、動作完了確認ツールA5などが機能する。また、カーネル空間では、デバイス制御システムに関連するソフトウェアとして、ファイルシステム11、ブロックデバイスアクセス用カーネルモジュール13、MMC用デーモンプロセス15以下、単にデーモンプロセス15と称する。、及びSDIOバスドライバ17などが機能する。この他、コンピュータ1は、デバイス制御システムに関連するハードウェアとして、I/Fハードウェア19などを備えている。ファイルシステム11は、OSの一部として提供されるシステムで、ストレージデバイスなどが備える記憶領域に格納されるデータをファイルとして管理するとともに、そのファイルに対するリードやライトを行うためのアプリケーションインターフェースを提供する。本実施形態において、ファイルシステム11は、FATやXFSなどの規格に対応したものとされている。アプリケーションA1などは、ファイルシステム11によって提供されるアプリケーションインターフェースを利用して、MMCデバイス2に格納されたファイルにアクセスすることができる。ブロックデバイスアクセス用カーネルモジュール13は、各種ブロックデバイスを制御するために、OSが標準的に備えているソフトウェアである。デバイス制御システムに関連する機能としては、MMCデバイス2を制御するためのデバイスドライバも、上記ブロックデバイスアクセス用カーネルモジュール13を流用して構成されている。そのため、アプリケーションA1などからMMCデバイス2に対するデータのリード又はライトを要求するコマンドが発行された場合、そのコマンドはブロックデバイスアクセス用カーネルモジュール13へと伝達される。ブロックデバイスアクセス用カーネルモジュール13は、自身が制御対象としているデバイスに対応する記憶領域を確保し、その記憶領域にブロックデバイス汎用デバイス固有データ13Aを格納する。デバイス制御システムに関連するデータとしては、複数のデータを備えるデータ構造とされたgendisk構造体が、ブロックデバイス汎用デバイス固有データ13A内に確保される。このgendisk構造体の中には、構造体メンバとして、32バイト分の記憶領域であるディスクネーム記憶領域diskname32や、デバイス番号記憶領域デバイスを示すメジャー番号及びマイナー番号が格納される記憶領域が含まれている。また、ブロックデバイスアクセス用カーネルモジュール13は、ファイルやデバイスに対するオープンコマンドが伝達されると、それに対応付けてハンドルと呼ばれる記憶領域図1ではハンドルH1,H2を例示。を確保し、その記憶領域にハンドル固有データ図1ではハンドル固有データ13B,13Cを例示。を格納する。アプリケーションA1などからファイルシステム11に対してファイルのオープンコマンドが発行された場合、オープンされたファイルに対応するデバイスをオープンするコマンドは、ファイルシステム11からブロックデバイスアクセス用カーネルモジュール13へと伝達される。また、アプリケーションの中には、デバイスに対して直接オープンコマンドを発行する特殊アプリケーションA4例えば、sfdisk,mkfs。などもあり、このような特殊アプリケーションA4からはブロックデバイスアクセス用カーネルモジュール13へ直接コマンドが伝達される。なお、図1では、図を簡潔にする都合上、単一のブロックデバイスアクセス用カーネルモジュール13を図示してあるが、実際は、複数のデバイスがあれば、それら個々のデバイスそれぞれに対応する複数のデバイスドライバがコンピュータ1上で機能し、各デバイスドライバにおいてブロックデバイスアクセス用カーネルモジュール13が利用される。デーモンプロセス15は、ブロックデバイスアクセス用カーネルモジュール13同様、OSの一部を構成するソフトウェアであり、上述のコマンドがブロックデバイスアクセス用カーネルモジュール13へと伝達された際には、さらにブロックデバイスアクセス用カーネルモジュール13からコマンドが伝達される。また、デーモンプロセス15も、記憶領域を確保し、その記憶領域にMMC用デバイス固有データ15Aを格納する。デバイス制御システムに関連するデータとしては、6個のカウンタr1,r2,r3,w1,w2,w3が、MMC用デバイス固有データ15A内に確保される。SDIOバスドライバ17及びI/Fハードウェア19は、デーモンプロセス15とMMCデバイス2との間に介在する通信用インターフェース部本発明でいう通信用インターフェース部。を構成している。デーモンプロセス15へコマンドが伝達された際には、そのコマンドがSDIOバスドライバ17及びI/Fハードウェア19を介してデーモンプロセス15からMMCデバイス2へと伝送される。さらに、このコンピュータ1においては、上述の6個のカウンタr1,r2,r3,w1,w2,w3に格納された値を、ユーザ空間で作動するプロセスから読み取り可能とするため、procバイパスを利用した情報公開用インターフェース部本発明でいう情報公開用インターフェース部に相当。を設けてある。procは、Linuxにおいて、OSの管理下にあるリソース関連の情報例えば、カーネル空間に確保された記憶領域に格納された値を、ファイルと同様の手順で読み出し可能とするために用意された仮想的なファイルシステムである。Linuxにおいて、MMCデバイス用のprocバイパスについては、OS標準での用意がないので、本実施形態ではprocdriverbilmmciを新設して、上述の6個のカウンタ値を読み出し可能としてある。なお、このようなprocバイパスは、本実施形態では、動作完了確認ツールA5によって利用される。動作完了確認ツールA5の詳細については後述する。[ブロックデバイスアクセス用カーネルモジュールにおいて実行される処理]次に、ブロックデバイスアクセス用カーネルモジュール13において実行される処理について、図2のフローチャートに基づいて説明する。図2に示すリードライトコマンドスタック追加処理は、OS経由でブロックデバイスアクセス用カーネルモジュール13へと伝達されるコマンドを対象に、そのコマンドに応じてブロックデバイスアクセス用カーネルモジュール13が実行する処理である。ブロックデバイスアクセス用カーネルモジュール13へと伝達されるコマンドは、例えば、アプリケーションA1などのコマンド発行元プロセスが、OSの提供するアプリケーションインターフェースを介してコマンドを発行したような場合に、ブロックデバイスアクセス用カーネルモジュール13へと伝達されるものである。図2に示す処理が実行されるタイミングは、多数のデバイスが並列処理できるようにするため、OSによってコントロールされている。ブロックデバイスアクセス用カーネルモジュール13は、デバイスハンドルをパラメータとして受け取っており、指定されたハンドル内にあるコマンドスタック内に1以上のコマンドが積まれた際に、1つのコマンドを対象に図2に示す処理が実行される。図2に示す処理を開始すると、ブロックデバイスアクセス用カーネルモジュール13正確には、ブロックデバイスアクセス用カーネルモジュール13としての処理を実行するコンピュータ1;以下、単にカーネルモジュール13という。は、パラメータとして与えられる情報リード要求、ライト要求の区別及びリードライトのバイト数を受け取り、物理デバイスと1対1対応しているブロックデバイスの場合はgendisk構造体本発明でいうリザーブ済み記憶領域に相当。へのポインタも受け取るS105。gendisk構造体は、ディスクデバイスに関する複数のデータを格納するためにOSが確保する汎用のデータ格納領域で、そのデータ構造はOS側で定義されている。S105で受け取るgendisk構造体へのポインタは、OSが確保したデータ格納領域のアドレスであり、物理デバイスと1対1対応しているブロックデバイスへのアクセス指令が上位モジュールにおいて発行された場合には、OSによって確保されたgendisk構造体のアドレスが、上位モジュールから与えられることになる。一方、物理デバイスと1対1対応しているブロックデバイス以外例えばディスクデバイス上に設定されたパーティションへのアクセス指令が上位モジュールにおいて発行された場合、上位モジュールからはgendisk構造体へのポインタが与えられない。そこで、カーネルモジュール13は、gendisk構造体へのポインタを受け取ったか否かを判断しS110、MMCデバイス2に対するリードライトコマンドが発行された可能性があるか否かを判断する。具体的には、gendisk構造体へのポインタを受け取っていればS110:はい、アクセス対象は、少なくとも物理デバイスと1対1対応しているブロックデバイスであると判断できる。したがって、MMCデバイス2に対するリードライトコマンドが発行された可能性もあり、そうであれば本デバイス制御システム特有の処理が必要となる可能性があるので、この場合は、S115へ進む。一方、gendisk構造体へのポインタを受け取っていなければS110:いいえ、アクセス対象は物理デバイスと1対1対応しているブロックデバイスではないと判断できる。したがって、MMCデバイス2に対するリードライトコマンドが発行された可能性はなく、本デバイス制御システム特有の処理は不要なので、この場合は、S140へ進む。S115へ進んだ場合、カーネルモジュール13は、デバイス番号メジャーがMMCBLOCKMAJORか否かを判断するS115。デバイス番号メジャーは、上述のgendisk構造体に含まれるメンバの一つに格納されるデータであり、あらかじめ定義されている定数であるMMCBLOCKMAJORであれば、MMCデバイス2に対するリードライトコマンドが発行されたものと判断できる。そこで、S115では、デバイス番号メジャーがMMCBLOCKMAJORであればS115:はい、S120へ進む一方、デバイス番号メジャーがMMCBLOCKMAJORでなければS115:いいえ、S140へ進む。さらに、S120へ進んだ場合、カーネルモジュール13は、ディスクネームが23文字以下か否かを判断するS120。ディスクネームも、上述のgendisk構造体に含まれるメンバの一つに格納されるデータである。MMCデバイス2に対してOSが付与するディスクネームは、文字列mmcblkの末尾に1桁又は2桁の数字列0~31を付加してなる文字列mmcblk0~mmcblk31とされることが、OSの仕様として決まっている。したがって、これらのディスクネームは、現状の仕様では最大でも8文字以下であり、このディスクネームが格納されるgendisk構造体のメンバdiskname32文字型配列の一部は、未使用領域として残されている。そこで、このデバイス制御システムでは、上述の文字型配列diskname32のうち、少なくとも末尾の8バイトが未使用領域として残されていれば、その未使用領域を利用することとし、S120では、ディスクネームが23文字以下か否かを確認している。ディスクネームが23文字以下であることが確認できれば、その文字列の終端に文字列の終わりを示す制御コード通常はNULLが付加されていても、それらの格納に必要な記憶領域は24バイト以下となるので、文字型配列diskname32には、少なくとも8バイト以上の未使用領域が存在することになる。そこで、S120では、ディスクネームが23文字以下であればS120:はい、S125へ進む一方、ディスクネームが23文字超過であればS120:いいえ、S140へ進む。S125では、カーネルモジュール13は、リードライト要求を判別するS125。そして、リード要求であった場合はS125:リード要求、文字型配列diskname32の24~27の4バイトを、32ビット整数とみなしてインクリメントし、最上位ビットを0にするS130。すなわち、このS130が実行されるたびに、32ビット整数とみなされた4バイトの記憶領域では、整数値のインクリメントが行われ、しかも、常に最上位ビットを0にしているので、インクリメントに伴って最上位ビットが1になるタイミングで整数値が0に戻り、以降、再びインクリメントが継続される。一方、S125において、ライト要求であった場合はS125:ライト要求、文字型配列diskname32の28~31の4バイトを、32ビット整数とみなしてインクリメントし、最上位ビットを0にするS135。すなわち、このS135が実行されるたびに、32ビット整数とみなされた4バイトの記憶領域では、整数値のインクリメントが行われ、しかも、常に最上位ビットを0にしているので、インクリメントに伴って最上位ビットが1になるタイミングで整数値が0に戻り、以降、再びインクリメントが継続される。このように、文字型配列diskname32の24~31の8バイトは、2つの32ビット整数を格納する記憶領域として利用され、これら2つの32ビット整数により、リード要求及びライト要求それぞれの発行回数をカウントする。つまり、MMCデバイス2に対するリードライト要求が発行された場合にのみ、リード要求及びライト要求それぞれの発行回数がカウントされるのである。そして、S130又はS135によるカウントを終えたらS140へ進む。S140では、通常のリードライトコマンドスタック追加処理を実行するS140。このS140により、アクセス対象となるデバイスに対応したハンドル固有データ内のコマンドスタックには、リードコマンド又はライトコマンドが積まれることとなる。ただし、このS140は、Linuxにおける周知の処理なので、これ以上の詳細な説明については省略する。なお、S140を終えたら、図2に示すブロックデバイスアクセス用カーネルモジュール内リードライトコマンドスタック追加処理を終了する。以上説明した通り、図2に示すブロックデバイスアクセス用カーネルモジュール内リードライトコマンドスタック追加処理では、ブロックデバイスアクセス用カーネルモジュール13がすでに利用している既存の記憶領域である文字型配列diskname32の未使用部分を利用して、リードコマンド及びライトコマンドの発行回数をカウントする。したがって、既存のデータ格納領域であるgendisk構造体に含まれるメンバを新たに追加しなくても、リードコマンド及びライトコマンドの発行回数を記憶でき、gendisk構造体のデータ構造を変更しなくてもよい。よって、gendisk構造体に新たなメンバを追加するような改修を加えた場合に比べ、既存のデータ構造を前提としてgendisk構造体にアクセスするモジュールで予期しないトラブルを誘発するのを抑制することができる。[MMC用デーモンプロセス15において実行される処理]次に、MMC用デーモンプロセス15以下、単にデーモンプロセス15と称する。において実行される処理について、図3のフローチャートに基づいて説明する。デーモンプロセス15は、MMCデバイス2の作動開始に伴って起動され、その後は、MMCデバイス2の作動が停止されるまでコンピュータ1に常駐する。図3に示す処理は、デーモンプロセス15が起動されたときに開始される。なお、以下、ディスクデバイスmmcblk0devmmcblk0に対応するデーモンプロセス15を例に挙げて説明を続けるが、mmcblk0は単なる一例として例示するものであり、別のディスクデバイスmmcblk1~mmcblk31のいずれかであっても同様の処理となるのはもちろんである。図3に示す処理を開始すると、デーモンプロセス15正確には、デーモンプロセス15としての処理を実行するコンピュータ1;以下、単にデーモンプロセス15という。は、他のデバイスにも時間を与えるため、所定時間ウエイトするS205。そして、ディスクデバイスmmcblk0が取り外されたか否かを判断しS210、ディスクデバイスmmcblk0が取り外されている場合はS210:はい、デーモンプロセス15による処理を終了する。一方、S210において、ディスクデバイスmmcblk0が取り外されていないと判断された場合S210:いいえ、デーモンプロセス15は、デバイス固有データから最初のオープン中ハンドルを取得するS215。そして、オープン中のハンドルがない場合はS220:はい、S205へと戻る一方、オープン中のハンドルがある場合S220:いいえ、デーモンプロセス15は、取得中ハンドルのコマンドスタックから1コマンドを取り出すS225。続いて、デーモンプロセス15は、取り出したコマンドの種別を判断しS230、コマンドがリードコマンドであった場合S230:リード、カウンタr2をインクリメントし、最上位ビットを0にするS235。なお、カウンタr2は、デーモンプロセス15の作動開始時にMMC用デバイス固有データ15A内に確保されて初期化ゼロクリアされており、その後は、S235が実行されるたびにインクリメントされることになる。また、常に最上位ビットを0にしているので、インクリメントに伴って最上位ビットが1になるタイミングでカウンタ値が0に戻り、以降、再びインクリメントが継続される。その後、デーモンプロセス15は、MMCデバイス2に対してMMC形式リードコマンドを発行して完了を待つS240。S240において、完了を待つ間は他のデバイスに時間を解放する。そして、MMCデバイス2からの完了応答が返されたら、カウンタr3をインクリメントし、最上位ビットを0にするS245。なお、カウンタr3は、デーモンプロセス15の作動開始時にMMC用デバイス固有データ15A内に確保されて初期化ゼロクリアされており、その後は、S245が実行されるたびにインクリメントされることになる。また、常に最上位ビットを0にしているので、インクリメントに伴って最上位ビットが1になるタイミングでカウンタ値が0に戻り、以降、再びインクリメントが継続される。一方、S230において、コマンドがライトコマンドであった場合S230:ライト、デーモンプロセス15は、カウンタw2をインクリメントし、最上位ビットを0にするS250。なお、カウンタw2は、デーモンプロセス15の作動開始時にMMC用デバイス固有データ15A内に確保されて初期化ゼロクリアされており、その後は、S250が実行されるたびにインクリメントされることになる。また、常に最上位ビットを0にしているので、インクリメントに伴って最上位ビットが1になるタイミングでカウンタ値が0に戻り、以降、再びインクリメントが継続される。その後、デーモンプロセス15は、MMCデバイス2に対してMMC形式ライトコマンドを発行し完了を待つS255。S255において、完了を待つ間は他のデバイスに時間を解放する。MMCデバイス2からの完了応答が返されたら、カウンタw3をインクリメントし、最上位ビットを0にするS260。なお、カウンタw3は、デーモンプロセス15の作動開始時にMMC用デバイス固有データ15A内に確保されて初期化ゼロクリアされており、その後は、S260が実行されるたびにインクリメントされることになる。また、常に最上位ビットを0にしているので、インクリメントに伴って最上位ビットが1になるタイミングでカウンタ値が0に戻り、以降、再びインクリメントが継続される。このようにしてS245又はS260を終えたら、デーモンプロセス15は、MMC用デバイス固有データ15Aから次のオープン中ハンドルを取得するS270。そして、オープン中のハンドルがない場合はS275:はい、S205へと戻る一方、オープン中のハンドルがある場合はS275:いいえ、S225へと戻る。以上説明したように、図3に示した処理では、S240又はS255においてデバイスに対してリードコマンド又はライトコマンドが発行されることとなるたびに、その発行前後双方のタイミングとなるS235及びS245、もしくはS250及びS260において、カウンタr2及びカウンタr3、もしくはカウンタw2及びカウンタw3がインクリメントされる。したがって、これらのカウンタr2、r3、w2、w3には、デーモンプロセス15におけるリード又はライトのSCSIコマンドの発行回数が、発行直前及び発行後の待機完了直後双方のタイミングで蓄積保持されることになる。[procdriverbilmmci処理]次に、procdriverbilmmci処理について、図8aのフローチャートに基づいて説明する。図8aに示すフローチャートは、procdriverbilmmciに対するリードが行われた場合に実行される処理であり、この処理が実行されることで、図8bに示すような形式の情報がリード結果として出力されることになる。より詳しく説明すると、procdriverbilmmci処理を開始すると、コンピュータ1は、まず、図8bに示すような情報のうち、先頭2行にある情報BIL-MmcInfo:~を出力するS905。そして、カウンタNに0ゼロをセットしてS907、ディスクデバイスmmcblkNNは0~3の整数があるか否かを判断するS910。本実施形態においては、mmcblk0~mmcblk3までをサポートしており、そのためNは0~3の整数とされているが、このカウンタNの最大値は3以上とされていてもよい。S910において、ディスクデバイスmmcblkNNは0~3の整数があった場合S910:ある、コンピュータ1は、ブロックデバイス汎用デバイス固有データ13A中に含まれるgendisk構造体中の文字型配列diskname32を参照するS915。そして、文字型配列diskname32に格納されたディスクネームが23文字以下であるか否かを判断するS920。S920において、ディスクネームが23文字を超過している場合S920:いいえ、上述したS130又はS135によるカウント図2参照。が実施されていないので、この場合は、カウンタr1とw1に、無効値であることを示す定数0xF001000232ビット整数を代入するS925。一方、S920において、ディスクネームが23文字以下であった場合S920:はい、文字型配列diskname32の24~27の4バイトを、32ビット整数とみなしてカウンタr1に代入しS930、同じく文字型配列diskname32の28~31の4バイトを、32ビット整数とみなしてカウンタw1に代入するS935。すなわち、これらS930及びS935により、S130及びS135でカウントされた値は図2参照。、それぞれカウンタr1,w1に代入されることとなる。したがって、S130及びS135において、カウンタr1,w1のインクリメントを実施することはできないものの、S930及びS935が実行されることで、カウンタr1,w1にリードライトコマンドの発行回数をセットすることができる。また、上述のS235、S245、S250、及びS260において、カウンタr2、r3、w2、w3にも値がセットされているので、これらの処理により、6個のカウンタr1,r2,r3,w1,w2,w3全てに、リードライトコマンドの発行回数がセットされることになる。こうしてS925又はS935を終えたら、コンピュータ1は、BILMmcRdWrCN~の行を出力するS940。図8bに例示した情報の場合、N=0となる行が出力されている。S940で出力される行には、図8bに例示した通り、文字列BILMmcRdWrCに引き続いて、ディスクネームの末尾の文字に相当する数字N、及び6個のカウンタr1,r2,r3,w1,w2,w3の値が列挙される。そして、S940を終えるか、S910でディスクデバイスmmcblkNNは0~3の整数がないと判断された場合はS910:ない、変数NをインクリメントしS950、変数Nが3以下か否かを判断するS960。変数Nが3以下であればS960:はい、S910へと戻る。これにより、S910以降の処理が繰り返され、N=0~3の順にディスクデバイスmmcblkNに対応する処理が繰り返される。そして、変数Nが3を超えたらS960:いいえ、procdriverbilmmci処理を終了する。[動作完了確認ツールにおいて実行される処理]次に、動作完了確認ツールA5において実行される処理について、図4のフローチャートに基づいて説明する。動作完了確認ツールA5は、コマンド発行元プロセスからブロックデバイスアクセス用カーネルモジュール13へと伝達されるコマンドが、MMCデバイス2へ実際に伝達されたかどうかをコマンド発行元プロセス側で確認可能とするためのツールである。この動作完了確認ツールA5はコマンド発行元プロセス側で必要なときに任意に起動され、その際、図4に示す処理が実行されることになる。なお、以下の説明では、説明を簡便にするため、MMCデバイス2がコンピュータ1においてディスクデバイスmmcblk0として認識されている場合を例に挙げて説明する。ただし、動作完了確認ツールA5は、mmcblk0以外のディスクデバイス本実施形態であれば、mmcblk1~mmcblk3のいずれかを対象にして所期の処理を行うこともできる。図4に示す処理を開始すると、動作完了確認ツールA5正確には、動作完了確認ツールA5としての処理を実行するコンピュータ1;以下、単に動作完了確認ツールA5という。は、procdriverbilmmciファイルをオープンするS305。ここで、procdriverbilmmciファイルがない場合S310:はい、動作完了確認ツールA5は、図4に示す処理を終了するmmcblk0が見つからないエラー終了。一方、S310において、ファイルがある場合S310:いいえ、動作完了確認ツールA5がファイルprocdriverbilmmciからデータをリードすると、すでに説明したprocdriverbilmmci処理図8a参照。が実行され、その結果、動作完了確認ツールA5は、図8bに示すような形式の情報を読み込むことができる。そこで、動作完了確認ツールA5は、読み込んだ情報中に含まれるキーワードBILMmcRdWrCの最初の行を検索するS315。図8bに例示する情報の場合、BILMmcRdWrCの行には、ディスク名図8bでは0と上述の6個のカウンタr1,r2,r3,w1,w2,w3に格納された値が列挙されている。ここで、BILMmcRdWrCの行が見つからなければS317:いいえ、動作完了確認ツールA5は、図4に示す処理を終了するmmcblk0が見つからないエラー終了。一方、S317において、BILMmcRdWrCの行が見つかればS317:はい、その行の先頭の数値がディスク番号を示しているのでS320、ディスク番号が0であるか否かを判断するS325。S325において、ディスク番号が0でない場合はS325:いいえ、図4に例示した処理の処理対象となるディスクデバイスではないので、その場合、動作完了確認ツールA5は、キーワードBILMmcRdWrCの次の行を検索してS330、S317へと戻る。これにより、ディスク番号が0である行が見つかるまでキーワードBILMmcRdWrCの行が順に検索されることになり、該当する行が見つからない場合S317:いいえ、動作完了確認ツールA5は、図4に示す処理を終了することになるmmcblk0が見つからないエラー終了。また、S325において、ディスク番号が0であった場合はS325:はい、mmcblk0が接続中であることが確認されたことになるS340。そこで、この場合、動作完了確認ツールA5は、カウンタr1,w1の最上位ビットが0か否かを判断するS342。このS342では、BILMmcRdWrCの行に含まれるカウンタr1,w1の値がS930及びS935で代入された値となっていれば肯定判断がなされ、S925で代入された値となっていれば否定判断がなされることになる。カウンタr1,w1の最上位ビットが0ではなかった場合S342:いいえ、ディスクネームが23文字を超過しており、その場合、カウンタr1,w1に適正な値を代入できていないので、この場合、動作完了確認ツールA5をエラー終了するディスクネームエラー。一方、S342において、カウンタr1,w1の最上位ビットが0であった場合はS342:はい、カウンタr1,w1に適正な値を代入できている。そこで、この場合は、タイムアウトのカウンタとして所定時間例えば1分程度を設定しS345、一定時間例えば100msが経過するのを待つS350。その後、タイムアウトのカウンタを上記一定時間分上記例では100ms減らしてS355、タイムアウトか否かを判断するS360。ここで、タイムアウトであった場合S360:はい、動作完了確認ツールA5は、図4に示す処理を終了するタイムアウトエラー終了。一方、S360において、タイムアウトではない場合S360:いいえ、動作完了確認ツールA5は、ファイルprocdriverbilmmciのBILMmcRdWrC0~の行から情報取得を行うS365。そして、動作完了確認ツールA5は、カウンタr1,r2,r3の値が全て一致するか否かを判断するS370。ここで、カウンタr1,r2,r3の値が全て一致するのは、S130、S235~S245が全て実行されている場合に該当する。これは、ブロックデバイスアクセス用カーネルモジュール13でコマンドスタックに積まれたリードコマンドが、デーモンプロセス15でもMMCデバイス2へと発行され、その応答がデバイスからデーモンプロセス15へすでに返っていることを意味する。逆に、ブロックデバイスアクセス用カーネルモジュール13でコマンドスタックに積まれたリードコマンドが、デーモンプロセス15ではまだMMCデバイス2へと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス15からMMCデバイス2へコマンドが発行されたものの、その応答がデバイスからデーモンプロセス15へまだ返っていない場合も、上記カウンタ値は一致しない。そこで、S370において、カウンタr1,r2,r3の値が一致しない場合はS370:いいえ、S350へと戻る。これにより、S345で設定した時間が経過するまでは、S350~S370が繰り返されることになる。一方、S370において、カウンタr1,r2,r3の値が全て一致した場合S370:はい、動作完了確認ツールA5は、カウンタw1,w2,w3が全て一致するか否かを判断するS375。ここで、カウンタw1,w2,w3の値が全て一致するのは、S135、S250~S260が全て実行されている場合に該当する。これは、ブロックデバイスアクセス用カーネルモジュール13でコマンドスタックに積まれたライトコマンドが、デーモンプロセス15でもMMCデバイス2へと発行され、その応答がデバイスからデーモンプロセス15へすでに返っていることを意味する。逆に、ブロックデバイスアクセス用カーネルモジュール13でコマンドスタックに積まれたライトコマンドが、デーモンプロセス15ではまだMMCデバイス2へと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス15からMMCデバイス2へコマンドが発行されたものの、その応答がデバイスからデーモンプロセス15へまだ返っていない場合も、上記カウンタ値は一致しない。そこで、S375において、カウンタw1,w2,w3の値が一致しない場合はS375:いいえ、S350へと戻る。これにより、S345で設定した時間が経過するまでは、S350~S375が繰り返されることになる。したがって、リード又はライトいずれかのコマンドが完全にデバイスへと伝わらない限り、S350~S375が繰り返され、その繰り返しの中でタイムアウトとなった場合にはS360:はい、タイムアウトでエラー終了となるのである。一方、S370において、カウンタr1,r2,r3の値が全て一致しS370:はい、且つS375において、カウンタw1,w2,w3の値が全て一致した場合S375:はい、動作完了確認ツールA5は、図4に示す処理を正常終了する。以上説明したように、動作完了確認ツールA5は、リードコマンド及びライトコマンドがブロックデバイスアクセス用カーネルモジュール13からデーモンプロセス15経由でMMCデバイス2へと伝達され、デバイスからの応答がデーモンプロセス15へ返っている場合に正常終了する。また、リードコマンド及びライトコマンドがブロックデバイスアクセス用カーネルモジュール13から発行されたものの、タイムアウトを待つ間にデバイスからの応答がデーモンプロセス15へ返る状態に至らなければエラー終了する。正常終了したかエラー終了したかを示す情報は、動作完了確認ツールA5を起動した上位プロセス例えば、アプリケーションなどへと返される。したがって、上位プロセスでは、動作完了確認ツールA5を利用して、MMCデバイス2に対して発行したコマンドが、ブロックデバイスアクセス用カーネルモジュール13やデーモンプロセス15において処理済みとなっているか否かを確認することができる。[アプリケーションにおいて実行される処理の例その1]次に、上述のような動作完了確認ツールA5を利用するアプリケーションの一例を、図5~図7のフローチャートに基づいて説明する。以下に説明するアプリケーションA1は、ディスクデバイスmmcblk0の再初期化を行ってから、引き続いてパーティションの切り直しを行い、さらに引き続いてファイルシステムmmcblk0p1のマウントを行うものである。なお、以下の処理でも、説明を簡潔にするために、ディスクデバイスmmcblk0,ファイルシステムmmcblk0p1,マウントポイントmntmmc1などの具体例を挙げながら説明を行うが、これらの具体例に限られないのはもちろんである。図5に示すディスクの再初期化処理を開始すると、アプリケーションA1正確には、アプリケーションA1としての処理を実行するコンピュータ1;以下、単にアプリケーションA1という。は、devmmcblk0を対象にしてディスク使用停止処理を実行するS405。このディスク使用停止処理は、詳しくは図6に示すような処理となる。すなわち、図6に示す処理では、まず、アプリケーションA1からの指令により、全アプリケーションでマウントポイントmntmmc1以下の全てのオープン中のファイルをクローズするS505。なお、この例は、devmmcblk0p1がmntmmc1にマウント中であることを想定している例であり、マウントポイントの具体的パス名は任意である。続いて、アプリケーションA1は、syncコマンドを実行して、ディスクキャッシュ11Aに保持されているデータをMMCデバイス2へ書き出すS510。そして、mntmmc1をアンマウントして、devmmcblk0p1のマウントを解除するS515。これにより、devmmcblk0p1に対しては、少なくともファイルシステム11経由でのアクセスが行われない状態になる。次に、アプリケーションA1は、ディスクデバイスmmcblk0のフラッシュデバイスflushdevice処理を行い、ブロックデバイスアクセス用カーネルモジュール13の動作完了待ちになるS520。このフラッシュデバイス処理は、ブロックデバイスアクセス用カーネルモジュール13が内部的に保持キャッシュしているデータをデバイス側へ掃き出させるために行われる処理であり、Linux搭載コンピュータではすでに行われている周知の処理である。具体的には、フラッシュデバイス処理は、図7aに示すような処理となり、アプリケーションA1は、devmmcblk0をオープンしてハンドルをファイルディスクリプタfdに格納しS605、システムコールioctlを実行するS610。これにより、ブロックデバイスアクセス用カーネルモジュール13は、コマンドスタック内に未処理のコマンドが残されていたとしても、それらを全てコマンドスタックへ積み、これにより、それらのデータをデーモンプロセス15へ引き渡す準備を完了する。S610を終えたら、アプリケーションA1は、fdのクローズdevmmcblk0のクローズを行ってS615、図7aに示すを完了する。さて、こうしてフラッシュデバイス処理を完了したら、再び図6に戻って、アプリケーションA1は、動作確認完了ツールA5を起動してmmcblk0の動作完了待ちになるS525。先に説明した通り、動作確認完了ツールA5は、デーモンプロセス15がデバイスからの応答を受け取ったことを検出したときに正常終了するので、S525では、デーモンプロセス15の動作完了待ちを行うことになる。ここで、動作確認完了ツールA5が正常終了すれば、デーモンプロセス15が保持していたデータ全てがデバイスに掃き出されたことを意味するので、これにて図6に示すディスクの使用停止処理を完了する。なお、動作確認完了ツールA5がエラー終了した場合は、エラーメッセージを表示して処理を中止するなどの対処を行えばよいが、この種のエラー処理自体は一般的なものなので、これ以上の詳細な説明は省略する。図6に示すディスクの使用停止処理を完了したら、図5のS405を終えたことになるので、続いて、アプリケーションA1は、sfdiskコマンドを実行し、パーティションの切り直しを行うS410。そして、mmcblk0のフラッシュデバイス処理を行って、ブロックデバイスアクセス用カーネルモジュール13の動作完了待ちになりS415、続いて、動作確認完了ツールA5でmmcblk0の動作完了待ち、すなわち、デーモンプロセス15の動作完了待ちになるS420。S415,S420は、先に説明したS520,S525と同等な処理であり、これらの処理により、ブロックデバイスアクセス用カーネルモジュール13の保持するデータ、デーモンプロセス15の保持するデータが、それぞれデバイス側へ確実に掃き出されるのを待つことになる。そして、S420を終えたら、sfdiskコマンドの実行に伴ってMMCデバイス2へ書き込まれるべきデータが、確実にデバイスに書き込まれたことになる。そこで、アプリケーションA1は、mkfsコマンドを実行し、パーティションのフォーマットを行うS425。そして、mmcblk0のフラッシュデバイス処理を行って、ブロックデバイスアクセス用カーネルモジュール13の動作完了待ちとなりS430、続いて、動作確認完了ツールA5でmmcblk0の動作完了待ち、すなわち、デーモンプロセス15の動作完了待ちになるS435。S430,S435も、先に説明したS520,S525,S415,S420と同等な主旨で実行する処理である。S435を終えたら、mkfsコマンドの実行に伴ってMMCデバイス2へ書き込まれるべきデータが、確実にデバイスに書き込まれたことになるので、アプリケーションA1は、ディスクデバイスdevmmcblk0の使用再開処理を行うS440。なお、S440は、詳しくは図7bに示すような処理となる。すなわち、アプリケーションA1は、devmmcblk0p1をmntmmc1にマウントするS705。なお、この例は、devmmcblk0p1がmntmmc1にマウントされることを想定している例であり、マウントポイントの具体的パス名は任意である。このようなマウントが行われると、以降は、全アプリケーションでmntmmc1以下のファイルが使用可能になりS710、図7bに示すディスクの使用再開処理が完了する。そして、図7bに示すディスクの使用再開処理が完了すると、図5のS440が完了するので、これにて図5に示すディスクの再初期化処理全てが完了する。以上説明したように、上記のようなアプリケーションA1では、sfdiskの実行後、フラッシュデバイス処理を行ってブロックデバイスアクセス用カーネルモジュール13の管理下にあるデータをデーモンプロセス15へと引き渡している。しかも、動作確認完了ツールA5でデーモンプロセス15の管理下にあるデータが、全てデバイスに書き込まれたことを確認してから、mkfsを実行している。したがって、このような確認をすることなくsfdiskやmkfsを連続的に実行するものや、sfdiskの実行後にフラッシュデバイス処理は行うものの、デーモンプロセス15の動作状況を確認することなくmkfsを実行するものなどとは異なり、ディスク上に生じた不整合なデータが残っているうちに、新たなコマンドが実行されてしまうことがなく、また、それを防止するために、経験則に基づく不確実な様子見を過剰に長時間にわたって行う必要もない。ちなみに、上記実施形態においては、文字型配列diskname32中の8バイト分の未使用領域24~27バイト、28~31バイトが、本発明でいう第一記憶手段に相当する。また、カウンタr3,w3が、それぞれ本発明でいう第二記憶手段に相当する。以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。"