(57)【特許請求の範囲】
【請求項１】
ＩＤＥ（Integrated Drive Electronics）方式で接続されたハードディスクドライブとして機能するＩＤＥストレージデバイスと、それぞれにＵＳＢ（Universal Serial Bus）ストレージデバイスを接続可能な複数のＵＳＢポートとを備え、前記複数のＵＳＢポートの内、少なくとも１つのＵＳＢポートは管理者だけが利用可能な管理者用ＵＳＢポート、残りのＵＳＢポートは管理者以外でも利用可能な一般用ＵＳＢポートとされている情報処理装置であって、
前記情報処理装置の起動時に、前記ＩＤＥストレージデバイスおよび前記ＵＳＢポートに接続されたＵＳＢストレージデバイスを検出すると、検出した前記ＩＤＥストレージデバイスないし前記ＵＳＢストレージデバイスそれぞれに対して、ユニークなドライブ名を割り当てるドライブ名割り当て手段と、
前記ドライブ名割り当て手段によって前記ＩＤＥストレージデバイスに対して割り当てられた前記ドライブ名を利用して、前記ＩＤＥストレージデバイス上にある第１ファイルシステムを特定するとともに、当該特定した前記第１ファイルシステムを所定のマウントポイントにマウントする第１マウント手段と、
前記第１マウント手段が前記第１ファイルシステムのマウントに成功したか否かを判定する判定手段と、
前記判定手段によって前記第１ファイルシステムのマウントに失敗したと判定された場合に、前記管理者用ＵＳＢポートに接続された前記ＵＳＢストレージデバイスに対して前記ドライブ名割り当て手段が割り当てた前記ドライブ名を取得するドライブ名取得手段と、
前記ドライブ名取得手段によって取得された前記ドライブ名を利用して、前記管理者用ＵＳＢポートに接続された前記ＵＳＢストレージデバイス上にある第２ファイルシステムを特定するとともに、当該特定した前記第２ファイルシステムを前記マウントポイントにマウントする第２マウント手段と、
前記第１マウント手段または前記第２マウント手段のいずれかによって前記第１ファイルシステムまたは第２ファイルシステムが前記マウントポイントにマウントされたら、前記マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する処理実行手段と
を備えたことを特徴とする情報処理装置。
【請求項２】
前記ＵＳＢストレージデバイスを検出したときに、前記ＵＳＢストレージデバイスへのアクセス時に利用する仮想的なＳＣＳＩ（Small Computer System Interface）インターフェースと、前記ＳＣＳＩインターフェースおよび前記ＵＳＢストレージデバイスに関する情報にアクセスするための情報公開用インターフェースとを、前記ＵＳＢストレージデバイス毎に生成するインターフェース生成手段
を備え、
前記ドライブ名割り当て手段は、前記インターフェース生成手段によって生成された前記ＳＣＳＩインターフェースを検出する毎に、前記ＳＣＳＩインターフェースを介してアクセス可能な前記ＵＳＢストレージデバイスに対して、前記ドライブ名を割り当てるとともに、前記ＳＣＳＩインターフェースを介して前記ＵＳＢストレージデバイスにアクセスする際には、アクセス対象となる前記ＵＳＢストレージデバイスに対して割り当てた前記ドライブ名を、前記ＳＣＳＩインターフェースに伝達することにより、前記ＳＣＳＩインターフェースが備える記憶領域に前記ドライブ名を保存し、
前記ドライブ名取得手段は、前記情報公開用インターフェースを介して前記ＳＣＳＩインターフェースが備える記憶領域に格納された情報を読み出し、その読み出した情報中から前記管理者用ＵＳＢポートと前記ドライブ名との対応関係を示す情報を取得する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ドライブ名割り当て手段は、前記ＵＳＢストレージデバイスに対して前記ドライブ名を割り当てた後、前記ＵＳＢストレージデバイスの容量に関する情報を取得するため、ＳＣＳＩ規格で規定されたＳＣＳＩコマンドの１種であるリードキャパシティコマンドを発行しており、当該リードキャパシティコマンドに対応する処理の中で、前記ドライブ名が前記ＳＣＳＩインターフェースに伝達される
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記ドライブ名取得手段は、前記情報公開用インターフェースを介して情報を取得可能なすべての前記ＵＳＢストレージデバイスについて、順次情報の読み出しを繰り返すとともに、読み出した情報中に含まれるＵＳＢポートに関する情報があらかじめ決められた前記管理者用ＵＳＢポートに該当する情報か否かを判断し、前記管理者用ＵＳＢポートに該当する情報であった場合に、読み出した情報中に含まれる前記ドライブ名を取得する
ことを特徴とする請求項２または請求項３に記載の情報処理装置。
【請求項５】
前記管理者用ＵＳＢポートは、情報処理装置の筐体内部に収容されていて、前記筐体が備えるパネルを開放したときにＵＳＢデバイスを抜き挿し可能となるものであり、
前記一般用ＵＳＢポートは、前記筐体の外部に露出していて、前記パネルを開放しなくてもＵＳＢデバイスを抜き挿し可能となっている
ことを特徴とする請求項１〜請求項４のいずれかに記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＤＥストレージデバイスからのプログラムの読み込みができない緊急時に、ＵＳＢストレージデバイスからプログラムを読み込むことで、少なくとも一部の機能が作動不能となるのを回避可能な情報処理装置に関する。
【背景技術】
【０００２】
従来、外付記憶装置からプログラムを読み込んで、所定の処理を実行するように構成された情報処理装置は、既に提案されている（例えば、特許文献１参照）。
上記特許文献１に記載の技術においては、ＵＳＢストレージデバイスを外付けし、そこからプログラムを読み込んで装置を起動することが行われている。
【特許文献１】特開２００６−３３１３８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、上記のようなＵＳＢストレージデバイスからの起動技術は、単独で利用する以外に、内蔵ハードディスク装置からの起動技術と組み合わせることも可能である。例えば、内蔵ハードディスク装置からの起動（以下、通常起動と称する。）に失敗した場合には、ＵＳＢストレージデバイスからの起動（以下、緊急起動と称する。）を行うように構成することで、情報処理装置の信頼性向上を図ることもできる。
【０００４】
このような仕組みを構成した場合、緊急起動時に、ＵＳＢストレージデバイス上のファイルを利用するには、ＵＳＢストレージデバイスに割り当てられたドライブ名を特定し、そのドライブ名を利用したパス名などで、所期のファイルシステムやファイルにアクセスする必要がある。
【０００５】
しかし、ＵＳＢストレージデバイスが複数存在する場合、それら複数のデバイスを認識する順序は、情報処理装置のＯＳ（Operating System）任せになっていることが多く、認識順によっては、ドライブ名が入れ替わってしまうこともある。特に、抜き差しが容易なＵＳＢストレージデバイスの場合、情報処理装置への追加・削除が行われる可能性も高く、それに伴ってドライブ名が変動する可能性も高い。
【０００６】
そのため、ＵＳＢストレージデバイスに割り当てられるドライブ名を勝手に決めつけて、それを利用したパス名で、緊急起動時にアクセスしたいファイルシステムやファイルを指定しておいても、ドライブ名が変動してしまうと、ファイルシステムやファイルにアクセスできなくなってしまうおそれがあった。
【０００７】
また、第１のＵＳＢストレージデバイスと同等なファイル構成を持つ第２のＵＳＢストレージデバイスが存在すれば、第２のストレージデバイスを第１のＵＳＢストレージデバイスと誤認し、第２のストレージデバイス上のファイルにアクセスするおそれもある。
【０００８】
この場合、第２のストレージデバイスが悪意を持って用意されたものであれば、第２のストレージデバイスから不適切なプログラムを読み込んでしまうなどの問題を招くおそれもあった。
【０００９】
ちなみに、特定のＵＳＢポートを上記緊急起動専用のＵＳＢポートとし、そこに緊急起動専用のＵＳＢストレージデバイスを装着しておくことで、物理的には、緊急起動専用のＵＳＢデバイスを他のＵＳＢデバイスと別扱いにすることはできる。
【００１０】
しかし、このような物理的な区別をしても、ファイルシステムやファイルへのアクセスを行う際には、上述の通り、ＯＳが付与するドライブ名を利用することになる。そのため、ドライブ名が付与された後に、そのドライブ名がどのＵＳＢデバイスに割り当てられたものなのかがわからないと問題となるが、ＯＳによっては、ドライブ名に基づいて、そのドライブ名に対応するＵＳＢポートやＵＳＢデバイスを調べることができなかった。
【００１１】
本発明は、上記問題を解決するためになされたものであり、その目的は、緊急起動用のＵＳＢストレージデバイスに割り当てられるドライブ名が変動しても、適切に所期のＵＳＢストレージデバイスから緊急起動を行うことができる情報処理装置を提供することにある。
【課題を解決するための手段】
【００１２】
以下、本発明において採用した構成について説明する。
請求項１に記載の情報処理装置は、ＩＤＥ方式で接続されたハードディスクドライブとして機能するＩＤＥストレージデバイスと、それぞれにＵＳＢストレージデバイスを接続可能な複数のＵＳＢポートとを備え、前記複数のＵＳＢポートの内、少なくとも１つのＵＳＢポートは管理者だけが利用可能な管理者用ＵＳＢポート、残りのＵＳＢポートは管理者以外でも利用可能な一般用ＵＳＢポートとされている情報処理装置であって、前記情報処理装置の起動時に、前記ＩＤＥストレージデバイスおよび前記ＵＳＢポートに接続されたＵＳＢストレージデバイスを検出すると、検出した前記ＩＤＥストレージデバイスないし前記ＵＳＢストレージデバイスそれぞれに対して、ユニークなドライブ名を割り当てるドライブ名割り当て手段と、前記ドライブ名割り当て手段によって前記ＩＤＥストレージデバイスに対して割り当てられた前記ドライブ名を利用して、前記ＩＤＥストレージデバイス上にある第１ファイルシステムを特定するとともに、当該特定した前記第１ファイルシステムを所定のマウントポイントにマウントする第１マウント手段と、前記第１マウント手段が前記第１ファイルシステムのマウントに成功したか否かを判定する判定手段と、前記判定手段によって前記第１ファイルシステムのマウントに失敗したと判定された場合に、前記管理者用ＵＳＢポートに接続された前記ＵＳＢストレージデバイスに対して前記ドライブ名割り当て手段が割り当てた前記ドライブ名を取得するドライブ名取得手段と、前記ドライブ名取得手段によって取得された前記ドライブ名を利用して、前記管理者用ＵＳＢポートに接続された前記ＵＳＢストレージデバイス上にある第２ファイルシステムを特定するとともに、当該特定した前記第２ファイルシステムを前記マウントポイントにマウントする第２マウント手段と、前記第１マウント手段または前記第２マウント手段のいずれかによって前記第１ファイルシステムまたは第２ファイルシステムが前記マウントポイントにマウントされたら、前記マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する処理実行手段とを備えたことを特徴とする。
【００１３】
この情報処理装置において、ＩＤＥストレージデバイスとは、ＩＤＥ方式で接続されたハードディスクドライブとして機能するものである。より詳しくは、情報処理装置の制御部側から見た接続方式としてはＩＤＥ方式を利用しており、且つ、情報処理装置の制御部側ではデバイス種別をハードディスク装置として認識するものを、本発明においてはＩＤＥストレージデバイスと称する。
【００１４】
このようなＩＤＥストレージデバイスの最も代表的な例としては、ＩＤＥ方式（パラレルＡＴＡ（Advanced Technology Attachment）方式）の接続用インターフェースを内蔵するハードディスク装置を挙げることができる。
【００１５】
また、ハードディスク装置そのものがＩＤＥ方式とは異なる他方式の内蔵インターフェースを備えている場合であっても、他方式をＩＤＥ方式に変換可能なアダプタを付加すれば、ＩＤＥ方式で接続が可能なハードディスク装置を構成できる。すなわち、このような変換アダプタ付きのハードディスク装置も、本発明でいうＩＤＥストレージデバイスに含まれる。
【００１６】
ハードディスク装置の場合、上記のようなＩＤＥ方式とは異なる他方式の代表例としては、例えば、ＳＣＳＩ方式、ＳＡＴＡ（Serial Advanced Technology Attachment）方式などを挙げることができる。あるいは、ＵＳＢ方式、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）１３９４方式のインターフェースを挙げることもできる。これらどのような方式のインターフェースをＩＤＥ方式に変換してあってもよい。
【００１７】
さらに、情報処理装置の制御部側から見て、ＩＤＥ方式で接続されたハードディスクドライブと同等な挙動をエミュレートするデバイスであれば、構造的にはハードディスク装置とは異なる構成を採用していても、本発明でいうＩＤＥストレージデバイスに含まれる。具体例を挙げれば、例えば、半導体メモリを利用したストレージデバイスなど、ハードディスク装置とは異なる各種記憶媒体を利用して構成されたストレージデバイスであってもよい。
【００１８】
一方、この情報処理装置において、ＵＳＢストレージデバイスとは、ＵＳＢポートへ接続した際に、情報処理装置の制御部側からＵＳＢマスストレージクラスのデバイスとして認識されるものである。
【００１９】
このＵＳＢストレージデバイスについても、情報処理装置の制御部側から見た接続方式としてはＵＳＢ方式を利用していれば、デバイス側で上述のような変換アダプタを利用しているか否かについては問わない。
【００２０】
以上のように構成された情報処理装置において、情報処理装置の起動時には、まず、ドライブ名割り当て手段が、ＩＤＥストレージデバイスおよびＵＳＢストレージデバイスを検出し、それぞれに対してユニークなドライブ名を割り当てる。
【００２１】
具体例を交えて説明すると、例えば情報処理装置のＯＳがＬｉｎｕｘ（登録商標）の場合、情報処理装置は、装置の起動時にＩＤＥストレージデバイスに対して、ｈｄａ，ｈｄｂ，ｈｄｃ，…といったドライブ名を割り当てる。また、ＵＳＢストレージデバイスに対して、ｓｄａ，ｓｄｂ，ｓｄｃ，…といったドライブ名を割り当てる。これらのドライブ名割り当て処理は、情報処理装置が備えるＣＰＵ等を中心とする制御部によって実行されるものであり、これが本発明でいうドライブ名割り当て手段に相当する構成となる。
【００２２】
そして、このようなドライブ名割り当て手段によってドライブ名が割り当てられたら、第１マウント手段は、ＩＤＥストレージデバイスに対して割り当てられたドライブ名を利用して、ＩＤＥストレージデバイス上にある第１ファイルシステムを特定する。そして、その特定した第１ファイルシステムを所定のマウントポイントにマウントする。
【００２３】
これも具体例を交えて説明すると、例えば情報処理装置のＯＳがＬｉｎｕｘ（登録商標）の場合、ドライブ名“ｈｄａ”が割り当てられたＩＤＥストレージデバイス上にあるファイルシステム名は、ｈｄａ１，ｈｄａ２，ｈｄａ３，…と決められている。
【００２４】
そのため、情報処理装置において、ＩＤＥストレージデバイス上に存在するファイルシステムが、設計通りに用意されている場合、ドライブ名（例えば“ｈｄａ”）を利用して第１ファイルシステムを（例えば“ｈｄａ１”であると）特定できる。そして、第１ファイルシステムを特定できれば、その第１ファイルシステム（例えば“ｈｄａ１”）を所定のマウントポイント（例えば“／ｍａｉｎ”）にマウントすることもできる。このようなマウント処理も、情報処理装置が備えるＣＰＵ等を中心とする制御部によって実行されるものであり、これが本発明でいう第１マウント手段に相当する構成となる。
【００２５】
続いて、情報処理装置は、第１ファイルシステムのマウントに成功したか否かを判定する処理を実行する。この判定処理も、情報処理装置が備えるＣＰＵ等を中心とする制御部によって実行されるものであり、これが本発明でいう判定手段に相当する構成となる。
【００２６】
この判定の結果、マウントに成功したと判定された場合、情報処理装置の制御部は、マウントポイント下にある第１ファイルシステム上のファイル群にアクセスできる状態となる。
【００２７】
そこで、情報処理装置の制御部は、第１マウント手段によって第１ファイルシステムがマウントポイントにマウントされたら、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。この処理も、情報処理装置が備えるＣＰＵ等を中心とする制御部によって実行されるものであり、これが本発明でいう処理実行手段に相当する。
【００２８】
さて、以上のような情報処理装置の挙動が、ＩＤＥストレージデバイスに問題がない場合の挙動となるが、ＩＤＥストレージデバイスに問題がある場合は、第１マウント手段による第１ファイルシステムのマウントに失敗する場合がある。この場合、マウントポイント下にあるファイル群からプログラムを読み込むことができず、情報処理装置は、当該プログラムに基づく処理を実行することができなくなる。
【００２９】
そこで、本発明の情報処理装置においては、判定手段によってマウントに失敗したと判定された場合には、次のような処理を行う。すなわち、まず、ドライブ名取得手段が、管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイスに対してドライブ名割り当て手段が割り当てたドライブ名を取得する。
【００３０】
このようなドライブ名取得手段を採用しているのは、ドライブ名割り当て手段が、管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイスに対してどのようなドライブ名を割り当てるのかが不定だからである。
【００３１】
これも具体例を交えて説明すると、例えば情報処理装置のＯＳがＬｉｎｕｘ（登録商標）の場合、ＵＳＢストレージデバイスには、上述の通り、ドライブ名割り当て手段により、ｓｄａ，ｓｄｂ，ｓｄｃ，…といったドライブ名が割り当てられる。
【００３２】
ここで、本発明の情報処理装置においては、管理者用ＵＳＢポートにＵＳＢストレージデバイスが接続され、そのＵＳＢストレージデバイス上に第２ファイルシステムが用意してある。そのため、他にＵＳＢストレージデバイスが存在しない場合に限れば、例えば、管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイスのドライブ名は“ｓｄａ”に決まる。また、それ故、第２ファイルシステムは、例えば１番目のファイルシステムがターゲットの場合、“ｓｄａ１”となるはずであり、第２ファイルシステムを特定することもできる。
【００３３】
しかし、一般用ＵＳＢポートにもＵＳＢストレージデバイスが接続されている場合には、上述のｓｄａ，ｓｄｂ，ｓｄｃ，…といったドライブ名の内、どれが管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイスに割り当てられるかが不定となる。もちろん、どれが一般用ＵＳＢポートに接続されたＵＳＢストレージデバイスに割り当てられるかも不定である。
【００３４】
そこで、本発明の情報処理装置では、判定手段によってマウントに失敗したと判定された場合、まず、管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイスに対してドライブ名割り当て手段が割り当てたドライブ名を取得する処理を実行するのである。この処理も、情報処理装置が備えるＣＰＵ等を中心とする制御部によって実行されるものであり、これが本発明でいうドライブ名取得手段に相当する。
【００３５】
このようなドライブ名取得手段により、管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイスのドライブ名“ｓｄａ”が取得できれば、例えば１番目のファイルシステムがターゲットの場合、第２ファイルシステムは“ｓｄａ１”であると特定できる。また、ドライブ名“ｓｄｂ”が取得できれば、例えば１番目のファイルシステムがターゲットの場合、第２ファイルシステムは“ｓｄｂ１”であると特定できることになる。
【００３６】
したがって、情報処理装置は、上記のように特定された第２ファイルシステム（例えば“ｓｄａ１”）を所定のマウントポイント（例えば“／ｍａｉｎ”）にマウントする処理を実行することができるようになる。このようなマウント処理も、情報処理装置が備えるＣＰＵ等を中心とする制御部によって実行されるものであり、これが本発明でいう第２マウント手段に相当する。
【００３７】
そして、情報処理装置の制御部は、第２マウント手段によって第２ファイルシステムがマウントポイントにマウントされたら、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。この処理は、第１ファイルシステムをマウントした場合と同等な処理であり、既に説明した通り、本発明でいう処理実行手段に相当する。
【００３８】
以上説明したような情報処理装置によれば、通常は、第１ファイルシステムから各種処理を起動することができる。一方、何らかの原因（例えば故障等）により、第１ファイルシステムマウントに失敗した場合は、第２ファイルシステムから緊急時用の代替処理を起動することができる。
【００３９】
しかも、複数のＵＳＢストレージデバイスが存在すると、それらのドライブ名は不定となっているものの、本発明では、ドライブ名取得手段によって、管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイスに割り当てられたドライブ名を取得できる。また、第２マウント手段は、ドライブ名取得手段によって取得されたドライブ名を利用して、管理者用ＵＳＢポートに接続されたＵＳＢストレージデバイス上にある第２ファイルシステムを適切に特定することができる。
【００４０】
そのため、第２マウント手段は、適切な第２ファイルシステムを所定のマウントポイントにマウントすることができ、管理者用ＵＳＢポート以外に接続されたＵＳＢストレージデバイス上のファイルシステムを誤ってマウントしてしまうことはない。
【００４１】
したがって、適切な第２ファイルシステムがマウントされた後、処理実行手段は、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行することができる。よって、必要なファイルが読み込めないとか、不適切なファイルを読み込んでしまうといったトラブルを、未然に防止することができる。
【００４２】
なお、以上本発明の情報処理装置について説明したが、本発明の情報処理装置は、さらに次のように構成されていてもよい。
まず、請求項２に記載の情報処理装置は、請求項１に記載の情報処理装置において、前記ＵＳＢストレージデバイスを検出したときに、前記ＵＳＢストレージデバイスへのアクセス時に利用する仮想的なＳＣＳＩインターフェースと、前記ＳＣＳＩインターフェースおよび前記ＵＳＢストレージデバイスに関する情報にアクセスするための情報公開用インターフェースとを、前記ＵＳＢストレージデバイス毎に生成するインターフェース生成手段を備え、前記ドライブ名割り当て手段は、前記インターフェース生成手段によって生成された前記ＳＣＳＩインターフェースを検出する毎に、前記ＳＣＳＩインターフェースを介してアクセス可能な前記ＵＳＢストレージデバイスに対して、前記ドライブ名を割り当てるとともに、前記ＳＣＳＩインターフェースを介して前記ＵＳＢストレージデバイスにアクセスする際には、アクセス対象となる前記ＵＳＢストレージデバイスに対して割り当てた前記ドライブ名を、前記ＳＣＳＩインターフェースに伝達することにより、前記ＳＣＳＩインターフェースが備える記憶領域に前記ドライブ名を保存し、前記ドライブ名取得手段は、前記情報公開用インターフェースを介して前記ＳＣＳＩインターフェースが備える記憶領域に格納された情報を読み出し、その読み出した情報中から前記管理者用ＵＳＢポートと前記ドライブ名との対応関係を示す情報を取得することを特徴とする。
【００４３】
このように構成された情報処理装置によれば、仮想的なＳＣＳＩインターフェース（ＳＣＳＩホストアダプタ）を介してＵＳＢストレージデバイスにアクセスする際に、ＵＳＢストレージデバイスに割り当てられたドライブ名が、ＳＣＳＩインターフェースの備える記憶領域に保存される。
【００４４】
そのため、ドライブ名取得手段が、情報公開用インターフェースを介して情報を取得すると、ＳＣＳＩインターフェースおよびＵＳＢストレージデバイスに関する情報に加え、ドライブ名の情報をも取得することができる。これにより、管理者用ＵＳＢポートとドライブ名との対応関係を容易に把握することができる。
【００４５】
なお、より具体的な例を交えて説明すると、例えば情報処理装置のＯＳがＬｉｎｕｘ（登録商標）の場合、ＵＳＢストレージデバイスを検出したときには、ＵＳＢストレージデバイスへのアクセス時に利用する仮想的なＳＣＳＩインターフェースが生成される。また、ＳＣＳＩインターフェースおよびＵＳＢストレージデバイスに関する情報にアクセスするための情報公開用インターフェース（／ｐｒｏｃファイルシステム下にある擬似的なファイル）が生成される。これらを生成する処理は、ＵＳＢストレージデバイス毎に実行される。これらの処理は、情報処理装置が備えるＣＰＵ等を中心とする制御部によって実行されるものであり、これが本発明でいうインターフェース生成手段に相当する。
【００４６】
そして、上述したドライブ名割り当て手段は、仮想的なＳＣＳＩインターフェースを検出する毎に、そのＳＣＳＩインターフェースを介してアクセス可能なＵＳＢストレージデバイスに対して、ドライブ名を割り当てる処理を実行する。
【００４７】
ただし、一般的なＬｉｎｕｘ（登録商標）の場合、ＳＣＳＩインターフェースを介してＵＳＢストレージデバイスにアクセスする際、アクセス対象となるＵＳＢストレージデバイスに対して割り当てたドライブ名が、ＳＣＳＩインターフェースに伝達されることはない。それ故、ＳＣＳＩインターフェースが備える記憶領域にドライブ名が保存されることもない。
【００４８】
そのため、一般的なＬｉｎｕｘ（登録商標）の場合、ドライブ名に基づいて、それに対応するＳＣＳＩインターフェースは特定できるものの、ＳＣＳＩインターフェースに基づいて、それに対応するドライブ名を特定することはできない仕様となっている。これは、一般的なＬｉｎｕｘ（登録商標）の場合、本発明でいう管理者用ＵＳＢポートに対応するＳＣＳＩインターフェースに基づいて、それに対応するＵＳＢストレージデバイスのドライブ名（例えば“ｓｄａ”）を特定できない仕様であることを意味する。
【００４９】
この点、本発明の場合は、上述の通り、ＳＣＳＩインターフェースを介してＵＳＢストレージデバイスにアクセスする際、アクセス対象となるＵＳＢストレージデバイスに対して割り当てたドライブ名は、ＳＣＳＩインターフェースが備える記憶領域に保存される。
【００５０】
したがって、管理者用ＵＳＢポートに対応するＳＣＳＩインターフェースが備える記憶領域から、その記憶領域に保存されたドライブ名を読み取って、そのドライブ名に基づいて、所期のドライブ名ないしファイルシステム名を特定することができるのである。
【００５１】
ちなみに、一般的なＳＣＳＩインターフェースの場合は、単一のＳＣＳＩインターフェースに対して複数のストレージデバイスが接続される可能性がある。そのため、上記のようにＳＣＳＩインターフェースが備える記憶領域にドライブ名を保存しても、ＳＣＳＩインターフェースとストレージデバイスとの１対１の関係を特定するには至らない。
【００５２】
しかし、ＵＳＢストレージデバイスの接続に伴って生成される仮想的なＳＣＳＩインターフェースは、ＳＣＳＩインターフェースとＵＳＢストレージデバイスとが１対１の関係になっている。そのため、上記のようにＳＣＳＩインターフェースが備える記憶領域にドライブ名を保存すれば、そのドライブ名が「１対１の関係にあるＵＳＢストレージデバイス」に割り当てられたものであると特定できる。
【００５３】
次に、請求項３に記載の情報処理装置は、請求項２に記載の情報処理装置において、前記ドライブ名割り当て手段は、前記ＵＳＢストレージデバイスに対して前記ドライブ名を割り当てた後、前記ＵＳＢストレージデバイスの容量に関する情報を取得するため、ＳＣＳＩ規格で規定されたＳＣＳＩコマンドの１種であるリードキャパシティコマンドを発行しており、当該リードキャパシティコマンドに対応する処理の中で、前記ドライブ名が前記ＳＣＳＩインターフェースに伝達されることを特徴とする。
【００５４】
この情報処理装置において、ＵＳＢストレージデバイスの容量に関する情報の取得は、デバイス認識後に必須の処理であり、ＳＣＳＩ規格に準拠した仕様となっているＵＳＢストレージデバイスの場合、必ずリードキャパシティコマンドが発行される。
【００５５】
したがって、リードキャパシティコマンドが発行された際に実行される処理の中で、ドライブ名がＳＣＳＩインターフェースに伝達されれば、例えば、ドライブ名をＳＣＳＩインターフェースに伝達するための専用コマンドを新設するといった対処をしなくても済む。また、リードキャパシティコマンドを発行していた既存の処理については、何ら改修しなくてもリードキャパシティコマンドを発行するだけで、新たな機能が付加されることになる。
【００５６】
さらに、請求項４に記載の情報処理装置は、請求項２または請求項３に記載の情報処理装置において、前記ドライブ名取得手段は、前記情報公開用インターフェースを介して情報を取得可能なすべての前記ＵＳＢストレージデバイスについて、順次情報の読み出しを繰り返すとともに、読み出した情報中に含まれるＵＳＢポートに関する情報があらかじめ決められた前記管理者用ＵＳＢポートに該当する情報か否かを判断し、前記管理者用ＵＳＢポートに該当する情報であった場合に、読み出した情報中に含まれる前記ドライブ名を取得することを特徴とする。
【００５７】
このように構成された情報処理装置によれば、複数のＵＳＢストレージデバイスが存在していても、それらを順に処理対象として情報を読み出しながら、管理者用ＵＳＢポートに対応するドライブ名を選び出すことができる。
【００５８】
加えて、請求項５に記載の情報処理装置は、請求項１〜請求項４のいずれかに記載の情報処理装置において、前記管理者用ＵＳＢポートは、情報処理装置の筐体内部に収容されていて、前記筐体が備えるパネルを開放したときにＵＳＢデバイスを抜き挿し可能となるものであり、前記一般用ＵＳＢポートは、前記筐体の外部に露出していて、前記パネルを開放しなくてもＵＳＢデバイスを抜き挿し可能となっていることを特徴とする。
【００５９】
このように構成された情報処理装置によれば、管理者用ＵＳＢポートは、パネルを開放しないとＵＳＢデバイスを抜き挿しできない場所にあるので、管理者以外の利用者が誤って管理者用ＵＳＢポートにＵＳＢデバイスを装着してしまうのを未然に防止することができる。
【発明を実施するための最良の形態】
【００６０】
次に、本発明の実施形態について一例を挙げて説明する。
［情報処理装置の内部構造］
図１は、本発明の一実施形態として例示する情報処理装置１の内部構造を示すブロック図である。
【００６１】
以下に説明する情報処理装置１は、電源投入後に自動的に所定のプログラム群を実行することで、この情報処理装置１が備える特定の機能が作動するように構成された特定機能専用の装置である。より具体的には、本実施形態の場合、情報処理装置１はカラオケコマンダーとして構成されたものであり、電源投入後に自動的に所定のプログラム群を実行することで、カラオケコマンダーとして各種機能が作動するように構成されている。この点で、実行対象となるプログラムが利用者の操作に応じて任意に変わり得るパーソナルコンピュータのような汎用的な装置とは異なるものである。
【００６２】
この情報処理装置１は、ＣＰＵ１１、ＲＯＭ１３、ＲＡＭ１５、ハードディスク装置１７、およびＵＳＢインターフェース２０などを備えている。ＵＳＢインターフェース２０は、１つの内部ＵＳＢポート２１と、２つの外部ＵＳＢポート２２，２３とを備え、内部ＵＳＢポート２１には、ＵＳＢストレージデバイス２５が接続されている。すなわち、この情報処理装置１には、ハードディスク装置１７およびＵＳＢストレージデバイス２５、これら２種類のストレージデバイスが内蔵されている。
【００６３】
これらの内、ハードディスク装置１７は、ＩＤＥ方式の内蔵インターフェースを介して接続され、情報処理装置１の起動時には、通常、ハードディスク装置１７に格納されたプログラムが読み込まれる仕組みになっている。また、詳しくは後述するが、ハードディスク装置１７からプログラムを読み込むことができない状況に陥った場合、代替手段として、ＵＳＢストレージデバイス２５に格納されたプログラムが読み込まれる仕組みになっている。すなわち、ハードディスク装置１７は通常の起動時に利用され、ＵＳＢストレージデバイス２５は通常の起動ができない緊急時に利用される。
【００６４】
また、この情報処理装置１は筐体３１を備え、上記ＣＰＵ１１、ＲＯＭ１３、ＲＡＭ１５、およびハードディスク装置１７等は筐体３１の内部に収納されている。また、ＵＳＢインターフェース２０の内、内部ＵＳＢポート２１は筐体３１の内部に収納される一方、外部ＵＳＢポート２２，２３は筐体３１の外部に露出する状態になっている。
【００６５】
筐体３１には、開口部３３が設けられていて、この開口部３３はパネル３５によって塞がれている。このパネル３５は、固定具３７によって筐体３１に固定され、この固定具３７は、専用治具（図示略）を利用した場合にのみ取り外すことができる構造になっている。
【００６６】
この固定具３７を取り外してパネル３５を開放できるのは、専用治具を所持する管理者だけであり、筐体３１に内蔵された機器に直接触れることができるのは管理者のみである。したがって、内部ＵＳＢポート２１に接続されたＵＳＢストレージデバイス２５の抜き挿しなども、管理者しか実施することができない。一方、外部ＵＳＢポート２２，２３は、上述の通り、筐体３１の外部に露出しており、管理者以外の一般利用者であっても任意に各種ＵＳＢデバイスを抜き挿しすることができる。
【００６７】
つまり、内部ＵＳＢポート２１は、管理者だけが利用可能な管理者用ＵＳＢポートとされており、外部ＵＳＢポート２２，２３は、管理者以外でも利用可能な一般用ＵＳＢポートとされているのである。
【００６８】
さらに、これらのハードウェアを制御するため、情報処理装置１には、ＯＳが搭載されている。本実施形態において、ＯＳとしてはＬｉｎｕｘ（登録商標）が搭載されている。ただし、一般的なＬｉｎｕｘ（登録商標）が備える機能のみでは、本発明を実施する上で必要となる機能が十分に揃っていないため、一部独自の機能を追加してある。この追加機能の具体的な内容に関しては後から詳述するが、その他一般的なＬｉｎｕｘ（登録商標）と差異のない機能については、その説明を省略する。
【００６９】
［情報処理装置の起動時に実行される処理］
次に、上記情報処理装置１の起動時に実行される処理について説明する。
図２は、情報処理装置１の電源ＯＮに伴って実行される処理のフローチャートである。
【００７０】
情報処理装置１の電源がＯＮにされると、情報処理装置１では、まず、ＯＳのカーネルがＣＰＵ１１のメモリにロードされる（Ｓ１０５）。ＯＳのカーネルはＲＯＭ１３内に格納されていて、Ｓ１０５では、ＣＰＵ１１がＲＡＭ１５の一部をＲＡＭディスクとして確保し、このＲＡＭディスクにカーネルをロードする。これにより、このＲＡＭディスクがルートボリュームとなってＯＳが起動し、ＯＳの備える少なくとも一部の機能が作動を開始する。
【００７１】
こうしてＯＳの少なくとも一部が機能し始めると、続いて、情報処理装置１は、ＩＤＥ方式で接続されたハードディスク装置１７を認識する（Ｓ１１０）。このＳ１１０において、ハードディスク装置１７にはドライブ名が割り当てられ、本実施形態の場合、ハードディスク装置１７のドライブ名は“ｈｄａ”となる。
【００７２】
続いて、情報処理装置１では、ＳＣＳＩドライブ接続監視が開始される（Ｓ１１５）。本実施形態の場合、このＳ１１５では、ＳＣＳＩドライブ接続監視プロセスが起動され、以降、このプロセスが常駐することにより、情報処理装置１の電源がＯＦＦにされるまで、概ね６秒周期でＳＣＳＩドライブの接続／切断が監視される。
【００７３】
このＳＣＳＩドライブ接続監視の処理内容は、詳しくは図３に示すような処理となる。
すなわち、図３に示す「ＯＳ内ＳＣＳＩドライブ接続監視」を開始すると、情報処理装置１は、まず、「ＳＣＳＩ−Ｉ／Ｆ接続テーブル（以下、ＳＩＴＢと称する。）」の初期化を行う（Ｓ２０５）。ＳＩＴＢは、情報処理装置１において現在接続中のＳＣＳＩインターフェース（以下、ＳＣＳＩ−Ｉ／Ｆと称する。）を登録するためのテーブルである。Ｓ２０５では、例えばハードウェアとして装着されているＳＣＳＩ−Ｉ／Ｆが存在する場合に、その情報がＳＩＴＢに登録する処理などが実行される。
【００７４】
そして、Ｓ２０５で登録したＩ／Ｆに接続されているドライブが存在する場合は、そのドライブをシステムに登録する（Ｓ２１０）。このＳ２１０により、登録されたドライブには“ｓｄａ”，“ｓｄｂ”，…といったドライブ名が割り当てられる。
【００７５】
続いて、情報処理装置１は、一定時間（例えば６秒）が経過したか否かを判断し（Ｓ２１５）、経過していなければ（Ｓ２１５：いいえ）、Ｓ２１５へと戻ることにより、時間経過を待つ。そして、一定時間が経過したら（Ｓ２１５：はい）、現在接続中のＳＣＳＩ−Ｉ／Ｆを確認する（Ｓ２２０）。
【００７６】
その後、情報処理装置１は、新しく接続されたＳＣＳＩ−Ｉ／Ｆの有無を判断し（Ｓ２２５）、新しく接続されたＳＣＳＩ−Ｉ／Ｆが無い場合は（Ｓ２２５：無い）、今回切断されたＳＣＳＩ−Ｉ／Ｆの有無を判断する（Ｓ２３０）。そして、今回切断されたＳＣＳＩ−Ｉ／Ｆが無い場合は（Ｓ２３０：無い）、Ｓ２１５へ戻る。これにより、Ｓ２１５〜Ｓ２３０は、概ね６秒ごとに繰り返し実行されることになる。
【００７７】
そして、このようなＳ２１５〜Ｓ２３０の繰り返し処理が実行される中で、新しく接続されたＳＣＳＩ−Ｉ／Ｆが有った場合（Ｓ２２５：有る）、情報処理装置１は、新規ＳＣＳＩ−Ｉ／Ｆを上述のＳＩＴＢに登録し、そのＩ／Ｆに接続されているドライブをシステムに登録する（Ｓ２３５）。
【００７８】
このＳ２３５により、登録されたドライブには“ｓｄａ”，“ｓｄｂ”，…といったドライブ名が割り当てられる。また、ドライブの登録時には、そのドライブの容量に関する情報も必要となるので、その情報を取得するため、ＳＣＳＩ規格で規定されたＳＣＳＩコマンドの１種であるリードキャパシティコマンドを発行する。
【００７９】
このとき、この情報処理装置１では、リードキャパシティコマンドの発行対象となったドライブ名が、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域に格納される。このような処理は、一般的なＬｉｎｕｘ（登録商標）では実施されていない特殊な処理であり、この情報処理装置１特有の処理である。
【００８０】
ちなみに、一つのＳＣＳＩ−Ｉ／Ｆに複数のＳＣＳＩドライブが接続されている場合、上述のリードキャパシティコマンドは、複数のＳＣＳＩドライブに対して順に発行されてゆく。そのため、リードキャパシティコマンドの発行対象となったドライブ名も、順に変わってゆくので、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域には、最後にリードキャパシティコマンドの発行対象となったドライブ名が格納されることになる。
【００８１】
ただし、一つのＳＣＳＩ−Ｉ／Ｆに一つのＳＣＳＩドライブが接続されている場合であれば、上述のリードキャパシティコマンドは、一つのＳＣＳＩドライブに対してしか発行されない。そのため、リードキャパシティコマンドの発行対象となるドライブ名が変わることはなく、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域には、そのＳＣＳＩ−Ｉ／Ｆに接続されたドライブ名が格納されることになる。
【００８２】
さて、Ｓ２３５を終えたら、情報処理装置１は、今回接続の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したか否かを判断し（Ｓ２４０）、終了していなければ（Ｓ２４０：いいえ  次のＩ／Ｆへ）、Ｓ２３５へと戻ることにより、残りのＳＣＳＩ−Ｉ／ＦについてもＳ２３５を繰り返す。そして、今回接続の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したら（Ｓ２４０：はい）、Ｓ２３０へと進む。
【００８３】
また、Ｓ２１５〜Ｓ２３０の繰り返し処理が実行される中で、今回切断されたＳＣＳＩ−Ｉ／Ｆが有った場合（Ｓ２３０：有る）、情報処理装置１は、切断ＳＣＳＩ−Ｉ／ＦをＳＩＴＢから削除し、そのＩ／Ｆに接続されているドライブをシステムから削除する（Ｓ２４５）。このＳ２４５により、削除されたドライブに対応するドライブ名はシステムから消滅する。
【００８４】
そして、情報処理装置１は、今回切断の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したか否かを判断し（Ｓ２５０）、終了していなければ（Ｓ２５０：いいえ  次のＩ／Ｆへ）、Ｓ２４５へと戻ることにより、残りのＳＣＳＩ−Ｉ／ＦについてもＳ２４５を繰り返す。そして、今回切断の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したら（Ｓ２４０：はい）、Ｓ２１５へと戻る。
【００８５】
さて、以上説明したような処理がＳ１１５によって開始される処理となるが、ここで再び図２に戻り、Ｓ１１５を終えた時点からの説明を続ける。Ｓ１１５を終えると、情報処理装置１では、ＵＳＢ接続監視が開始される（Ｓ１２０）。本実施形態の場合、このＳ１２０では、ＵＳＢ接続監視プロセスが起動され、以降、このプロセスが常駐することにより、情報処理装置１の電源がＯＦＦにされるまで、概ね１００ミリ秒周期でＵＳＢデバイスの接続／切断が監視される。
【００８６】
このＵＳＢ接続監視の処理内容は、詳しくは図４に示すような処理となる。
すなわち、図３に示す「ＯＳ内ＵＳＢ接続監視」を開始すると、情報処理装置１は、まず、「ＵＳＢデバイス接続テーブル（以下、ＵＤＴＢと称する。）」の初期化を行う（Ｓ３０５）。ＵＤＴＢは、情報処理装置１において現在接続中のＵＳＢデバイスを登録するためのテーブルである。なお、Ｓ３０５では、ＵＳＢデバイスは何も接続されていない状態として扱われる。
【００８７】
続いて、情報処理装置１は、一定時間（例えば１００ミリ秒）が経過したか否かを判断し（Ｓ３１５）、経過していなければ（Ｓ３１５：いいえ）、Ｓ３１５へと戻ることにより、時間経過を待つ。そして、一定時間が経過したら（Ｓ３１５：はい）、現在接続中のＵＳＢデバイスを確認する（Ｓ３２０）。
【００８８】
その後、情報処理装置１は、新しく接続されたＵＳＢデバイスの有無を判断し（Ｓ３２５）、新しく接続されたＵＳＢデバイスが無い場合は（Ｓ３２５：無い）、今回切断されたＵＳＢデバイスの有無を判断する（Ｓ３３０）。そして、今回切断されたＵＳＢデバイスが無い場合は（Ｓ３３０：無い）、Ｓ３１５へ戻る。これにより、Ｓ３１５〜Ｓ３３０は、概ね６秒ごとに繰り返し実行されることになる。
【００８９】
そして、このようなＳ３１５〜Ｓ３３０の繰り返し処理が実行される中で、新しく接続されたＵＳＢデバイスが有った場合（Ｓ３２５：有る）、情報処理装置１は、新規ＵＳＢデバイスを上述のＵＤＴＢに登録し、デバイスドライバをシステムに登録する（Ｓ３３５）。このＳ３３５は、詳しくは図５に示すような処理となる。
【００９０】
すなわち、情報処理装置１は、図５に示すように、まず、ＵＳＢデバイスの種類を判断する（Ｓ４０５）。ここで、ＵＳＢストレージクラスのデバイスであると判断されれば（Ｓ４０５：ＵＳＢストレージクラス）、仮想ＳＣＳＩ−Ｉ／Ｆ（仮想ＳＣＳＩホストアダプタ）をシステムに登録し、“ＳＣＳＩｍ”のシンボルをシステムから与えられる（Ｓ４１０）。なお、上記“ＳＣＳＩｍ”中にある“ｍ”は「０」からの通し番号で、切断後は再利用される番号である。
【００９１】
また、情報処理装置１は、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”に情報公開手段をシステム登録、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”のシンボルをシステムから与えられる（Ｓ４１５）。なお、上記“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”中にある“ｎ”は「０」からの通し番号で、こちらは切断後の再利用はされない番号である。
【００９２】
一方、Ｓ４０５において、ＵＳＢストレージクラス以外のデバイスであると判断されれば（Ｓ４０５：ＵＳＢストレージクラス以外）、情報処理装置１は、各ＵＳＢデバイス用の登録処理を行う（Ｓ４２０）。このＳ４２０の処理は、ＵＳＢデバイスの種類によってさらに何通りかの処理にわかれるが、この処理の詳細は本発明の要部ではないので、これ以上の説明は省略する。
【００９３】
以上説明したようなＳ４０５〜Ｓ４２０の処理（図５参照）を終えると、図４に示したＳ３３５を終えたことになり、その場合、情報処理装置１は、今回接続の全ＵＳＢデバイスの処理が終了したか否かを判断する（Ｓ３４０）。
【００９４】
ここで、今回接続の全ＵＳＢデバイスの処理が終了していなければ（Ｓ３４０：いいえ  次のＩ／Ｆへ）、Ｓ３３５へと戻ることにより、残りのＵＳＢデバイスについてもＳ３３５を繰り返す。そして、今回接続の全ＵＳＢデバイスの処理が終了したら（Ｓ３４０：はい）、Ｓ３３０へと進む。
【００９５】
また、Ｓ３１５〜Ｓ３３０の繰り返し処理が実行される中で、今回切断されたＵＳＢデバイスが有った場合（Ｓ３３０：有る）、情報処理装置１は、切断ＵＳＢデバイスをＵＤＴＢから削除し、そのＩ／Ｆに接続されているドライブをシステムから削除する（Ｓ３４５）。このＳ３４５は、詳しくは図６に示すような処理となる。
【００９６】
すなわち、情報処理装置１は、図６に示すように、まず、ＵＳＢデバイスの種類を判断する（Ｓ５０５）。ここで、ＵＳＢストレージクラスのデバイスであると判断されれば（Ｓ５０５：ＵＳＢストレージクラス）、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”の情報公開手段をシステムから削除する（Ｓ５１０）。なお、既に説明した通り、この番号“ｎ”が再利用されることはない。
【００９７】
また、“ＳＣＳＩｍ”の仮想ＳＣＳＩ−Ｉ／Ｆ（仮想ＳＣＳＩホストアダプタ）をシステムから削除する（Ｓ５１５）。なお、既に説明した通り、この番号“ｍ”は以降も必要に応じて再利用されることがある。
【００９８】
一方、Ｓ５０５において、ＵＳＢストレージクラス以外のデバイスであると判断されれば（Ｓ５０５：ＵＳＢストレージクラス以外）、情報処理装置１は、各ＵＳＢデバイス用の削除処理を行う（Ｓ５２０）。このＳ５２０の処理は、ＵＳＢデバイスの種類によってさらに何通りかの処理にわかれるが、この処理の詳細は本発明の要部ではないので、これ以上の説明は省略する。
【００９９】
以上説明したようなＳ５０５〜Ｓ５２０の処理（図６参照）を終えると、図４に示したＳ３４５を終えたことになり、その場合、情報処理装置１は、今回切断の全ＵＳＢデバイスの処理が終了したか否かを判断する（Ｓ３５０）。ここで、今回切断の全ＵＳＢデバイスの処理が終了していなければ（Ｓ３５０：いいえ  次のＩ／Ｆへ）、Ｓ３４５へと戻ることにより、残りのＵＳＢデバイスについてもＳ３４５を繰り返す。そして、今回切断の全ＵＳＢデバイスの処理が終了したら（Ｓ３４０：はい）、Ｓ３１５へと戻る。
【０１００】
さて、以上説明したような処理が、Ｓ１２０によって開始される処理となるが、ここで再び図２に戻り、Ｓ１２０を終えた時点からの説明を続ける。Ｓ１２０を終えると、情報処理装置１では、電源ＯＮ時に接続されているＵＳＢデバイスが一括で認識される（Ｓ１２５）。このような認識が行われるのは、上記Ｓ１２０により、ＵＳＢ接続監視の処理を開始しているからである。
【０１０１】
そして、認識されたＵＳＢデバイスの中に、ＵＳＢストレージデバイスが有る場合は、その中に存在するドライブがＳＣＳＩドライブと認識される（Ｓ１３０）。このような認識が行われるのは、上記Ｓ１１５により、ＳＣＳＩドライブ接続監視の処理を開始しているからである。
【０１０２】
続いて、情報処理装置１では、カーネルの初期化を終了し、最初のスクリプトが実行される（Ｓ１３５）。そして、メインで使用するボリュームのマウント処理を実行する（Ｓ１４０）。
【０１０３】
このＳ１４０は、詳しくは図７に示すような処理となる。すなわち、図７に示す処理を開始すると、情報処理装置１は、“／ｄｅｖ／ｈｄａ１”のファイルシステムを、所定のマウントポイント“／ｍａｉｎ”にマウントする（Ｓ６０５）。ここで、ドライブ名が“ｈｄａ”になること、および、ファイルシステム名が“ｈｄａ１”になることは、情報処理装置１の構成上、事前に決まっている事項である。
【０１０４】
そして、Ｓ６０５を終えたら、マウント成功か否かを判断する（Ｓ６１０）。ここで、マウント成功であれば（Ｓ６１０：成功）、マウントしたボリューム内のスクリプト“／ｍａｉｎ／ｐｒｏｇ／ｓｔａｒｔｕｐ．ｓｈ”を実行する（Ｓ６１５）。
【０１０５】
一方、Ｓ６１０において、マウント失敗であれば（Ｓ６１０：成功）、このままではスクリプト“／ｍａｉｎ／ｐｒｏｇ／ｓｔａｒｔｕｐ．ｓｈ”を実行できず、情報処理装置１は通常通りに起動できなくなる。
【０１０６】
そこで、この場合は、バックアップ動作用ＵＳＢポートからＳＣＳＩドライブ名を割り出す（Ｓ６２０）。このＳ６２０は、詳しくは図８に示すような処理となる。すなわち、図８に示す処理を開始すると、情報処理装置１は、まず、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”の下のファイルを検索する（Ｓ７０５）。
【０１０７】
そして、ファイルが有るかどうかを判断する（Ｓ７１０）。ここで、ファイルが有る場合は（Ｓ７１０：はい）、見つかったファイルをリードする（Ｓ７１５）。ここでリード対象となるファイル“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”は、ＵＳＢストレージデバイスおよびＵＳＢポートに関する情報を提供する情報公開手段である。
【０１０８】
Ｓ７１５では、上記ファイルをリードすることにより、ＵＳＢポートの情報やＵＳＢストレージデバイスの情報などを取得することができる。また、こうしたＵＳＢポートの情報やＵＳＢストレージデバイスの情報などは、一般的なＬｉｎｕｘ（登録商標）でも取得可能な情報であるが、この情報処理装置１において、Ｓ７１５では、ＵＳＢストレージデバイスに割り当てられたドライブ名をも取得することができる。
【０１０９】
このドライブ名は、上記Ｓ２３５の処理により、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域に格納されたドライブ名そのものである。一般的なＬｉｎｕｘ（登録商標）の場合、ＳＣＳＩ−Ｉ／Ｆを利用する際に、ＳＣＳＩ−Ｉ／Ｆにドライブ名が通知されることはないので、ＳＣＳＩ−Ｉ／Ｆに接続されたＳＣＳＩドライブに、どのようなドライブ名が割り当てられているのかを、ＳＣＳＩ−Ｉ／Ｆ側で知る術はない。
【０１１０】
しかし、この情報処理装置１では、上述の通り、リードキャパシティコマンドが発行される毎に、コマンドの発行対象となったドライブ名がＳＣＳＩ−Ｉ／Ｆ側に伝達されて、そのドライブ名がＳＣＳＩ−Ｉ／Ｆ側の記憶領域に残される。
【０１１１】
したがって、この記憶領域に残された情報を見れば、ＳＣＳＩ−Ｉ／Ｆに接続されたＳＣＳＩドライブに、どのようなドライブ名が割り当てられているのかを、ＳＣＳＩ−Ｉ／Ｆ側で知ることができる。
【０１１２】
また、ＳＣＳＩ−Ｉ／Ｆに複数のＳＣＳＩドライブが接続されている場合、上記ＳＣＳＩ−Ｉ／Ｆ側の記憶領域には、その内の一つのＳＣＳＩドライブに割り当てられた名前だけしか残されない。しかし、ＵＳＢストレージデバイスの場合、一つのＵＳＢストレージデバイスに対して一つの仮想ＳＣＳＩ−Ｉ／Ｆが生成される。そのため、このＳＣＳＩ−Ｉ／Ｆに対応する記憶領域に残されるのは、必ず一つのドライブ名のみとなるので、ＵＳＢストレージデバイスに割り当てられたドライブ名を問題なく特定できる。
【０１１３】
つまり、Ｓ７１５で取得した情報を見れば、一般的なＬｉｎｕｘ（登録商標）同様、その情報がどのＵＳＢポートに対応する情報なのかを特定できる。しかも、一般的なＬｉｎｕｘ（登録商標）とは異なり、その情報がどのようなドライブ名に対応する情報なのかをも特定できるのである。
【０１１４】
そこで、Ｓ７１５を終えたら、情報処理装置１は、まず、接続ポートを判断して（Ｓ７２０）、内部ＵＳＢポート２１に対応する情報か否かを確認する。ここで、内部ＵＳＢポート２１に対応する情報でなければ（Ｓ７２０：ＵＳＢポートが違う）、Ｓ７１０へと戻る。ちなみに、このようにＳ７１０へと戻ることになるのは、外部ＵＳＢポート２２，２３のいずれかにもＵＳＢストレージデバイスが接続されている場合である。
【０１１５】
一方、Ｓ７２０において、内部ＵＳＢポート２１に対応する情報であれば（Ｓ７２０：探していたＵＳＢポート）、最後にリードキャパシティを実行したドライブ名を取得する（Ｓ７２５）。すなわち、Ｓ７１５でリードした情報の中からドライブ名を抽出する。
【０１１６】
このドライブ名は、“ｓｄａ”，“ｓｄｂ”，…といったドライブ名であるが、その末尾の文字“ａ”，“ｂ”，…は、どのような文字になるのか保証がない。具体的には、内部ＵＳＢポート２１にＵＳＢストレージデバイス２５が接続され、さらに外部ＵＳＢポート２２，２３にもＵＳＢストレージデバイスが接続されている場合、先に認識されたデバイスにはドライブ名“ｓｄａ”が付与される。また、その後に認識されたデバイスにはドライブ名“ｓｄｂ”が付与される。しかし、どのデバイスが先に認識されるかは不定であるため、例えばドライブ名“ｓｄａ”が付与されたデバイスがＵＳＢストレージデバイス２５なのかどうかは不定となる。
【０１１７】
この点、Ｓ７１０〜Ｓ７２０により、内部ＵＳＢポート２１に対応する情報を探し出し、Ｓ７２５により、ドライブ名を抽出すれば、内部ＵＳＢポート２１に接続されたＵＳＢストレージデバイス２５に割り当てられたドライブ名を確実に取得できるのである。
【０１１８】
なお、Ｓ７１０で、所期のＵＳＢポートが見つかる前にリード対象となるファイルが無くなった場合は（Ｓ７１０：いいえ）、図８に示す処理を終了する。これは、内部ＵＳＢポート２１にＵＳＢストレージデバイス２５が接続されていない場合の処理に相当する。
【０１１９】
さて、以上説明したような処理を終えると、図７に示したＳ６２０の処理を終えたことになるので、その場合、情報処理装置１は、“／ｄｅｖ／ｓｄｘ１”のファイルシステムを、所定のマウントポイント“／ｍａｉｎ”にマウントする（Ｓ６２５）。ここで、“ｓｄｘ”は、Ｓ７２５で取得したドライブ名である。つまり、Ｓ７２５までの処理で割り出したＳＣＳＩドライブのドライブ名を利用して、ＳＣＳＩドライブ上のパーティション（ファイルシステム）を指定し、そのパーティションを“／ｍａｉｎ”にマウントしているのである。
【０１２０】
そして、Ｓ６２５を終えたら、マウントに成功したか否かを判断し（Ｓ６３０）、成功していれば（Ｓ６３０：成功）、既に説明したＳ６１５へと進むことにより、マウントしたボリューム内のスクリプト“／ｍａｉｎ／ｐｒｏｇ／ｓｔａｒｔｕｐ．ｓｈ”を実行する（Ｓ６１５）。また、マウントに失敗した場合は（Ｓ６３０：失敗）、図７に示す処理を終了する。
【０１２１】
さて、以上説明したような処理を終えると、図２に示すＳ１４０を終えたことになるので、続いて、情報処理装置１では、メインで使用するボリューム内のスタートアッププログラムが起動する（Ｓ１４５）。すなわち、“／ｍａｉｎ”に“ｈｄａ１”または“ｓｄｘ１”のいずれがマウントされるかは、状況によって分かれるものの、いずれにしても、いずれかのボリューム内のスタートアッププログラムが起動するのである。
【０１２２】
そして、情報処理装置１では、システムが専用装置として動作し（Ｓ１５０）、以降は、利用者からのシャットダウン指示が有るまで（Ｓ１５５：いいえ）、専用装置としての動作を継続する。一方、利用者からのシャットダウン指示があった場合は（Ｓ１５５：はい）、シャットダウン処理を実行し（Ｓ１６０）、電源ＯＦＦに至る。
【０１２３】
［効果］
以上説明した情報処理装置１によれば、まず、Ｓ６０５を実行する手段（第１マウント手段）が、“／ｄｅｖ／ｈｄａ１”のファイルシステム（第１ファイルシステム）を“／ｍａｉｎ”（所定のマウントポイント）にマウントし、マウントできたら、Ｓ６１５，Ｓ１４５を実行する手段（処理実行手段）は、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。
【０１２４】
一方、“／ｄｅｖ／ｈｄａ１”のファイルシステムのマウントに失敗した場合は、Ｓ６２５を実行する手段（第２マウント手段）が、“／ｄｅｖ／ｓｄｘ１”のファイルシステム（第２ファイルシステム）を“／ｍａｉｎ”（所定のマウントポイント）にマウントし、マウントできたら、Ｓ６１５，Ｓ１４５を実行する手段（処理実行手段）は、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。
【０１２５】
したがって、通常は、“／ｄｅｖ／ｈｄａ１”のファイルシステム（第１ファイルシステム）から各種処理を起動する一方、何らかの原因（例えば故障等）により、“／ｄｅｖ／ｈｄａ１”のマウントに失敗した場合は、“／ｄｅｖ／ｓｄｘ１”のファイルシステム（第２ファイルシステム）から緊急時用の代替処理を起動することができる。
【０１２６】
また、複数あるＵＳＢポートに２以上のＵＳＢストレージデバイスが接続されていると、Ｓ２３５を実行する手段（ドライブ名割り当て手段）が、それら複数のＵＳＢストレージデバイスに対してどのようなドライブ名を割り当てるのかは不定となる。そのため、内部ＵＳＢポート２１（管理者用ＵＳＢポート）に接続されたＵＳＢストレージデバイス２５に対して割り当てられたドライブ名も不定となる。
【０１２７】
しかし、Ｓ６２０を実行する手段（ドライブ名取得手段）は、内部ＵＳＢポート２１に接続されたＵＳＢストレージデバイス２５に対して割り当てられたドライブ名を取得する。そのため、Ｓ６２５を実行する手段（第２マウント手段）は、Ｓ６２０で取得されたドライブ名を利用して、ＵＳＢストレージデバイス２５上にあるファイルシステムを適切に特定することができる。
【０１２８】
したがって、Ｓ６２５では、適切なファイルシステムを“／ｍａｉｎ”にマウントすることができ、外部ＵＳＢポート２２，２３のいずれかに接続されたＵＳＢストレージデバイス上のファイルシステムを誤ってマウントしてしまうことはない。
【０１２９】
よって、適切なファイルシステムがマウントされた後、Ｓ６１５，Ｓ１４５では、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく適切な処理を実行することができる。
【０１３０】
さらに、上記情報処理装置１においては、Ｓ２３５で、ＳＣＳＩインターフェースを介してＵＳＢストレージデバイスにアクセスする際に、ＵＳＢストレージデバイスに割り当てられたドライブ名が、ＳＣＳＩインターフェースの備える記憶領域に保存される。
【０１３１】
そのため、Ｓ６２５では、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”の情報公開手段（情報公開用インターフェース）を介して情報を取得すると、ＳＣＳＩインターフェースおよびＵＳＢストレージデバイスに関する情報に加え、ドライブ名の情報をも取得することができる。したがって、一般的なＬｉｎｕｘ（登録商標）とは異なり、きわめて容易にＵＳＢポートに対応するドライブ名の情報を得ることができる。
【０１３２】
しかも、このようなドライブ名の情報をＳＣＳＩインターフェースの備える記憶領域に保存する処理は、リードキャパシティコマンドに対応する処理の中で実行するので、リードキャパシティコマンドを発行する上位プログラムには手を加えなくても、ドライブ名を記憶領域に残す仕組みを導入できる。したがって、ドライブ名をＳＣＳＩインターフェースに伝達するための専用コマンドを新設しなくてもよく、大がかりなプログラムの改修は不要となる。
【０１３３】
加えて、上記情報処理装置１においては、Ｓ７１０〜Ｓ７２０を繰り返すので、複数のＵＳＢストレージデバイスが存在していても、それらを順に処理対象として情報を読み出しながら、管理者用ＵＳＢポートに対応するドライブ名を選び出すことができる。
【０１３４】
また、内部ＵＳＢポート２１は、パネル３５を開放しないとＵＳＢストレージデバイス２５を抜き挿しできない場所にあるので、管理者以外の利用者が誤って内部ＵＳＢポート２１にＵＳＢデバイスを装着してしまうのを未然に防止することができる。
【０１３５】
つまり、内部ＵＳＢポート２１からはプログラムを起動できるものの、管理者以外が容易に利用できる状態にはなく、外部ＵＳＢポート２２，２３は管理者以外でも容易に利用できるものの、ここからプログラムを起動することはできない仕組みになっている。
【０１３６】
したがって、緊急時にＵＳＢストレージデバイス２５からの起動を実施できる仕組みを実装しているにもかかわらず、外部ＵＳＢポート２２，２３からの起動を防止でき、システムが正常に起動しなくなったり、予期しないプログラムが実行されてしまったりするのを、未然に防止することができる。
【０１３７】
［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【０１３８】
例えば、上記実施形態では、カラオケコマンダーとしての機能を備えた情報処理装置１を例示したが、通常はＩＤＥストレージデバイスからの起動を行い、緊急時にＵＳＢストレージデバイスからの起動を行うように構成されていれば、自動起動される機能をどのような機能とするかは任意である。すなわち、カラオケコマンダー以外にも、各種特定用途での専用情報処理装置において、本発明の構成を採用することができる。
【図面の簡単な説明】
【０１３９】
【図１】情報処理装置の内部構造を示すブロック図。
【図２】情報処理装置の電源ＯＮに伴って実行される処理のフローチャート。
【図３】ＯＳ内ＳＣＳＩドライブ接続監視のフローチャート。
【図４】ＯＳ内ＵＳＢデバイス接続監視のフローチャート。
【図５】Ｓ３３５の詳細を示すフローチャート。
【図６】Ｓ３４５の詳細を示すフローチャート。
【図７】Ｓ１４０の詳細を示すフローチャート。
【図８】Ｓ６２０の詳細を示すフローチャート。
【符号の説明】
【０１４０】
１・・・情報処理装置、１１・・・ＣＰＵ、１３・・・ＲＯＭ、１５・・・ＲＡＭ、１７・・・ハードディスク装置、２０・・・ＵＳＢインターフェース、２１・・・内部ＵＳＢポート、２２，２３・・・外部ＵＳＢポート、２５・・・ＵＳＢストレージデバイス、３１・・・筐体、３３・・・開口部、３５・・・パネル、３７・・・固定具。
【図１】
0004946919.tif 000002
【図２】
0004946919.tif 000003
【図３】
0004946919.tif 000004
【図４】
0004946919.tif 000005
【図５】
0004946919.tif 000006
【図６】
0004946919.tif 000007
【図７】
0004946919.tif 000008
【図８】
0004946919.tif 000009