JP2009205655A - 情報処理装置 - Google Patents

情報処理装置 Download PDF

Info

Publication number
JP2009205655A
JP2009205655A JP2008050260A JP2008050260A JP2009205655A JP 2009205655 A JP2009205655 A JP 2009205655A JP 2008050260 A JP2008050260 A JP 2008050260A JP 2008050260 A JP2008050260 A JP 2008050260A JP 2009205655 A JP2009205655 A JP 2009205655A
Authority
JP
Japan
Prior art keywords
usb
storage device
drive name
information
processing apparatus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008050260A
Other languages
English (en)
Other versions
JP4946919B2 (ja
Inventor
Fumitoshi Uno
文敏 宇野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Brother Industries Ltd
Original Assignee
Brother Industries Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brother Industries Ltd filed Critical Brother Industries Ltd
Priority to JP2008050260A priority Critical patent/JP4946919B2/ja
Publication of JP2009205655A publication Critical patent/JP2009205655A/ja
Application granted granted Critical
Publication of JP4946919B2 publication Critical patent/JP4946919B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Stored Programmes (AREA)

Abstract

【課題】ドライブ名が変動しても、適切に所期のUSBストレージデバイスから緊急起動を行うことができる情報処理装置を提供すること。
【解決手段】ハードディスク上のファイルシステムを所定のマウントポイントにマウントし(S605)、マウントに成功したら(S610:成功)、マウントしたボリューム内のスクリプトを実行し(S615)、これにより、通常起動が行われることになる。一方、マウントに失敗したら(S610:失敗)、緊急起動用USBポートからドライブ名を割り出し(S620)、緊急起動用USBストレージデバイス上のファイルシステムを所定のマウントポイントにマウントする(S625)。このマウントに成功したら(S630:成功)、マウントしたボリューム内のスクリプトを実行し(S615)、これにより、緊急起動が行われることになる。
【選択図】図7

Description

本発明は、IDEストレージデバイスからのプログラムの読み込みができない緊急時に、USBストレージデバイスからプログラムを読み込むことで、少なくとも一部の機能が作動不能となるのを回避可能な情報処理装置に関する。
従来、外付記憶装置からプログラムを読み込んで、所定の処理を実行するように構成された情報処理装置は、既に提案されている(例えば、特許文献1参照)。
上記特許文献1に記載の技術においては、USBストレージデバイスを外付けし、そこからプログラムを読み込んで装置を起動することが行われている。
特開2006−331380号公報
ところで、上記のようなUSBストレージデバイスからの起動技術は、単独で利用する以外に、内蔵ハードディスク装置からの起動技術と組み合わせることも可能である。例えば、内蔵ハードディスク装置からの起動(以下、通常起動と称する。)に失敗した場合には、USBストレージデバイスからの起動(以下、緊急起動と称する。)を行うように構成することで、情報処理装置の信頼性向上を図ることもできる。
このような仕組みを構成した場合、緊急起動時に、USBストレージデバイス上のファイルを利用するには、USBストレージデバイスに割り当てられたドライブ名を特定し、そのドライブ名を利用したパス名などで、所期のファイルシステムやファイルにアクセスする必要がある。
しかし、USBストレージデバイスが複数存在する場合、それら複数のデバイスを認識する順序は、情報処理装置のOS(Operating System)任せになっていることが多く、認識順によっては、ドライブ名が入れ替わってしまうこともある。特に、抜き差しが容易なUSBストレージデバイスの場合、情報処理装置への追加・削除が行われる可能性も高く、それに伴ってドライブ名が変動する可能性も高い。
そのため、USBストレージデバイスに割り当てられるドライブ名を勝手に決めつけて、それを利用したパス名で、緊急起動時にアクセスしたいファイルシステムやファイルを指定しておいても、ドライブ名が変動してしまうと、ファイルシステムやファイルにアクセスできなくなってしまうおそれがあった。
また、第1のUSBストレージデバイスと同等なファイル構成を持つ第2のUSBストレージデバイスが存在すれば、第2のストレージデバイスを第1のUSBストレージデバイスと誤認し、第2のストレージデバイス上のファイルにアクセスするおそれもある。
この場合、第2のストレージデバイスが悪意を持って用意されたものであれば、第2のストレージデバイスから不適切なプログラムを読み込んでしまうなどの問題を招くおそれもあった。
ちなみに、特定のUSBポートを上記緊急起動専用のUSBポートとし、そこに緊急起動専用のUSBストレージデバイスを装着しておくことで、物理的には、緊急起動専用のUSBデバイスを他のUSBデバイスと別扱いにすることはできる。
しかし、このような物理的な区別をしても、ファイルシステムやファイルへのアクセスを行う際には、上述の通り、OSが付与するドライブ名を利用することになる。そのため、ドライブ名が付与された後に、そのドライブ名がどのUSBデバイスに割り当てられたものなのかがわからないと問題となるが、OSによっては、ドライブ名に基づいて、そのドライブ名に対応するUSBポートやUSBデバイスを調べることができなかった。
本発明は、上記問題を解決するためになされたものであり、その目的は、緊急起動用のUSBストレージデバイスに割り当てられるドライブ名が変動しても、適切に所期のUSBストレージデバイスから緊急起動を行うことができる情報処理装置を提供することにある。
以下、本発明において採用した構成について説明する。
請求項1に記載の情報処理装置は、IDE方式で接続されたハードディスクドライブとして機能するIDEストレージデバイスと、それぞれにUSBストレージデバイスを接続可能な複数のUSBポートとを備え、前記複数のUSBポートの内、少なくとも1つのUSBポートは管理者だけが利用可能な管理者用USBポート、残りのUSBポートは管理者以外でも利用可能な一般用USBポートとされている情報処理装置であって、前記情報処理装置の起動時に、前記IDEストレージデバイスおよび前記USBポートに接続されたUSBストレージデバイスを検出すると、検出した前記IDEストレージデバイスないし前記USBストレージデバイスそれぞれに対して、ユニークなドライブ名を割り当てるドライブ名割り当て手段と、前記ドライブ名割り当て手段によって前記IDEストレージデバイスに対して割り当てられた前記ドライブ名を利用して、前記IDEストレージデバイス上にある第1ファイルシステムを特定するとともに、当該特定した前記第1ファイルシステムを所定のマウントポイントにマウントする第1マウント手段と、前記第1マウント手段が前記第1ファイルシステムのマウントに成功したか否かを判定する判定手段と、前記判定手段によって前記第1ファイルシステムのマウントに失敗したと判定された場合に、前記管理者用USBポートに接続された前記USBストレージデバイスに対して前記ドライブ名割り当て手段が割り当てた前記ドライブ名を取得するドライブ名取得手段と、前記ドライブ名取得手段によって取得された前記ドライブ名を利用して、前記管理者用USBポートに接続された前記USBストレージデバイス上にある第2ファイルシステムを特定するとともに、当該特定した前記第2ファイルシステムを前記マウントポイントにマウントする第2マウント手段と、前記第1マウント手段または前記第2マウント手段のいずれかによって前記第1ファイルシステムまたは第2ファイルシステムが前記マウントポイントにマウントされたら、前記マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する処理実行手段とを備えたことを特徴とする。
この情報処理装置において、IDEストレージデバイスとは、IDE方式で接続されたハードディスクドライブとして機能するものである。より詳しくは、情報処理装置の制御部側から見た接続方式としてはIDE方式を利用しており、且つ、情報処理装置の制御部側ではデバイス種別をハードディスク装置として認識するものを、本発明においてはIDEストレージデバイスと称する。
このようなIDEストレージデバイスの最も代表的な例としては、IDE方式(パラレルATA(Advanced Technology Attachment)方式)の接続用インターフェースを内蔵するハードディスク装置を挙げることができる。
また、ハードディスク装置そのものがIDE方式とは異なる他方式の内蔵インターフェースを備えている場合であっても、他方式をIDE方式に変換可能なアダプタを付加すれば、IDE方式で接続が可能なハードディスク装置を構成できる。すなわち、このような変換アダプタ付きのハードディスク装置も、本発明でいうIDEストレージデバイスに含まれる。
ハードディスク装置の場合、上記のようなIDE方式とは異なる他方式の代表例としては、例えば、SCSI方式、SATA(Serial Advanced Technology Attachment)方式などを挙げることができる。あるいは、USB方式、IEEE(Institute of Electrical and Electronic Engineers)1394方式のインターフェースを挙げることもできる。これらどのような方式のインターフェースをIDE方式に変換してあってもよい。
さらに、情報処理装置の制御部側から見て、IDE方式で接続されたハードディスクドライブと同等な挙動をエミュレートするデバイスであれば、構造的にはハードディスク装置とは異なる構成を採用していても、本発明でいうIDEストレージデバイスに含まれる。具体例を挙げれば、例えば、半導体メモリを利用したストレージデバイスなど、ハードディスク装置とは異なる各種記憶媒体を利用して構成されたストレージデバイスであってもよい。
一方、この情報処理装置において、USBストレージデバイスとは、USBポートへ接続した際に、情報処理装置の制御部側からUSBマスストレージクラスのデバイスとして認識されるものである。
このUSBストレージデバイスについても、情報処理装置の制御部側から見た接続方式としてはUSB方式を利用していれば、デバイス側で上述のような変換アダプタを利用しているか否かについては問わない。
以上のように構成された情報処理装置において、情報処理装置の起動時には、まず、ドライブ名割り当て手段が、IDEストレージデバイスおよびUSBストレージデバイスを検出し、それぞれに対してユニークなドライブ名を割り当てる。
具体例を交えて説明すると、例えば情報処理装置のOSがLinux(登録商標)の場合、情報処理装置は、装置の起動時にIDEストレージデバイスに対して、hda,hdb,hdc,…といったドライブ名を割り当てる。また、USBストレージデバイスに対して、sda,sdb,sdc,…といったドライブ名を割り当てる。これらのドライブ名割り当て処理は、情報処理装置が備えるCPU等を中心とする制御部によって実行されるものであり、これが本発明でいうドライブ名割り当て手段に相当する構成となる。
そして、このようなドライブ名割り当て手段によってドライブ名が割り当てられたら、第1マウント手段は、IDEストレージデバイスに対して割り当てられたドライブ名を利用して、IDEストレージデバイス上にある第1ファイルシステムを特定する。そして、その特定した第1ファイルシステムを所定のマウントポイントにマウントする。
これも具体例を交えて説明すると、例えば情報処理装置のOSがLinux(登録商標)の場合、ドライブ名“hda”が割り当てられたIDEストレージデバイス上にあるファイルシステム名は、hda1,hda2,hda3,…と決められている。
そのため、情報処理装置において、IDEストレージデバイス上に存在するファイルシステムが、設計通りに用意されている場合、ドライブ名(例えば“hda”)を利用して第1ファイルシステムを(例えば“hda1”であると)特定できる。そして、第1ファイルシステムを特定できれば、その第1ファイルシステム(例えば“hda1”)を所定のマウントポイント(例えば“/main”)にマウントすることもできる。このようなマウント処理も、情報処理装置が備えるCPU等を中心とする制御部によって実行されるものであり、これが本発明でいう第1マウント手段に相当する構成となる。
続いて、情報処理装置は、第1ファイルシステムのマウントに成功したか否かを判定する処理を実行する。この判定処理も、情報処理装置が備えるCPU等を中心とする制御部によって実行されるものであり、これが本発明でいう判定手段に相当する構成となる。
この判定の結果、マウントに成功したと判定された場合、情報処理装置の制御部は、マウントポイント下にある第1ファイルシステム上のファイル群にアクセスできる状態となる。
そこで、情報処理装置の制御部は、第1マウント手段によって第1ファイルシステムがマウントポイントにマウントされたら、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。この処理も、情報処理装置が備えるCPU等を中心とする制御部によって実行されるものであり、これが本発明でいう処理実行手段に相当する。
さて、以上のような情報処理装置の挙動が、IDEストレージデバイスに問題がない場合の挙動となるが、IDEストレージデバイスに問題がある場合は、第1マウント手段による第1ファイルシステムのマウントに失敗する場合がある。この場合、マウントポイント下にあるファイル群からプログラムを読み込むことができず、情報処理装置は、当該プログラムに基づく処理を実行することができなくなる。
そこで、本発明の情報処理装置においては、判定手段によってマウントに失敗したと判定された場合には、次のような処理を行う。すなわち、まず、ドライブ名取得手段が、管理者用USBポートに接続されたUSBストレージデバイスに対してドライブ名割り当て手段が割り当てたドライブ名を取得する。
このようなドライブ名取得手段を採用しているのは、ドライブ名割り当て手段が、管理者用USBポートに接続されたUSBストレージデバイスに対してどのようなドライブ名を割り当てるのかが不定だからである。
これも具体例を交えて説明すると、例えば情報処理装置のOSがLinux(登録商標)の場合、USBストレージデバイスには、上述の通り、ドライブ名割り当て手段により、sda,sdb,sdc,…といったドライブ名が割り当てられる。
ここで、本発明の情報処理装置においては、管理者用USBポートにUSBストレージデバイスが接続され、そのUSBストレージデバイス上に第2ファイルシステムが用意してある。そのため、他にUSBストレージデバイスが存在しない場合に限れば、例えば、管理者用USBポートに接続されたUSBストレージデバイスのドライブ名は“sda”に決まる。また、それ故、第2ファイルシステムは、例えば1番目のファイルシステムがターゲットの場合、“sda1”となるはずであり、第2ファイルシステムを特定することもできる。
しかし、一般用USBポートにもUSBストレージデバイスが接続されている場合には、上述のsda,sdb,sdc,…といったドライブ名の内、どれが管理者用USBポートに接続されたUSBストレージデバイスに割り当てられるかが不定となる。もちろん、どれが一般用USBポートに接続されたUSBストレージデバイスに割り当てられるかも不定である。
そこで、本発明の情報処理装置では、判定手段によってマウントに失敗したと判定された場合、まず、管理者用USBポートに接続されたUSBストレージデバイスに対してドライブ名割り当て手段が割り当てたドライブ名を取得する処理を実行するのである。この処理も、情報処理装置が備えるCPU等を中心とする制御部によって実行されるものであり、これが本発明でいうドライブ名取得手段に相当する。
このようなドライブ名取得手段により、管理者用USBポートに接続されたUSBストレージデバイスのドライブ名“sda”が取得できれば、例えば1番目のファイルシステムがターゲットの場合、第2ファイルシステムは“sda1”であると特定できる。また、ドライブ名“sdb”が取得できれば、例えば1番目のファイルシステムがターゲットの場合、第2ファイルシステムは“sdb1”であると特定できることになる。
したがって、情報処理装置は、上記のように特定された第2ファイルシステム(例えば“sda1”)を所定のマウントポイント(例えば“/main”)にマウントする処理を実行することができるようになる。このようなマウント処理も、情報処理装置が備えるCPU等を中心とする制御部によって実行されるものであり、これが本発明でいう第2マウント手段に相当する。
そして、情報処理装置の制御部は、第2マウント手段によって第2ファイルシステムがマウントポイントにマウントされたら、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。この処理は、第1ファイルシステムをマウントした場合と同等な処理であり、既に説明した通り、本発明でいう処理実行手段に相当する。
以上説明したような情報処理装置によれば、通常は、第1ファイルシステムから各種処理を起動することができる。一方、何らかの原因(例えば故障等)により、第1ファイルシステムマウントに失敗した場合は、第2ファイルシステムから緊急時用の代替処理を起動することができる。
しかも、複数のUSBストレージデバイスが存在すると、それらのドライブ名は不定となっているものの、本発明では、ドライブ名取得手段によって、管理者用USBポートに接続されたUSBストレージデバイスに割り当てられたドライブ名を取得できる。また、第2マウント手段は、ドライブ名取得手段によって取得されたドライブ名を利用して、管理者用USBポートに接続されたUSBストレージデバイス上にある第2ファイルシステムを適切に特定することができる。
そのため、第2マウント手段は、適切な第2ファイルシステムを所定のマウントポイントにマウントすることができ、管理者用USBポート以外に接続されたUSBストレージデバイス上のファイルシステムを誤ってマウントしてしまうことはない。
したがって、適切な第2ファイルシステムがマウントされた後、処理実行手段は、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行することができる。よって、必要なファイルが読み込めないとか、不適切なファイルを読み込んでしまうといったトラブルを、未然に防止することができる。
なお、以上本発明の情報処理装置について説明したが、本発明の情報処理装置は、さらに次のように構成されていてもよい。
まず、請求項2に記載の情報処理装置は、請求項1に記載の情報処理装置において、前記USBストレージデバイスを検出したときに、前記USBストレージデバイスへのアクセス時に利用する仮想的なSCSIインターフェースと、前記SCSIインターフェースおよび前記USBストレージデバイスに関する情報にアクセスするための情報公開用インターフェースとを、前記USBストレージデバイス毎に生成するインターフェース生成手段を備え、前記ドライブ名割り当て手段は、前記インターフェース生成手段によって生成された前記SCSIインターフェースを検出する毎に、前記SCSIインターフェースを介してアクセス可能な前記USBストレージデバイスに対して、前記ドライブ名を割り当てるとともに、前記SCSIインターフェースを介して前記USBストレージデバイスにアクセスする際には、アクセス対象となる前記USBストレージデバイスに対して割り当てた前記ドライブ名を、前記SCSIインターフェースに伝達することにより、前記SCSIインターフェースが備える記憶領域に前記ドライブ名を保存し、前記ドライブ名取得手段は、前記情報公開用インターフェースを介して前記SCSIインターフェースが備える記憶領域に格納された情報を読み出し、その読み出した情報中から前記管理者用USBポートと前記ドライブ名との対応関係を示す情報を取得することを特徴とする。
このように構成された情報処理装置によれば、仮想的なSCSIインターフェース(SCSIホストアダプタ)を介してUSBストレージデバイスにアクセスする際に、USBストレージデバイスに割り当てられたドライブ名が、SCSIインターフェースの備える記憶領域に保存される。
そのため、ドライブ名取得手段が、情報公開用インターフェースを介して情報を取得すると、SCSIインターフェースおよびUSBストレージデバイスに関する情報に加え、ドライブ名の情報をも取得することができる。これにより、管理者用USBポートとドライブ名との対応関係を容易に把握することができる。
なお、より具体的な例を交えて説明すると、例えば情報処理装置のOSがLinux(登録商標)の場合、USBストレージデバイスを検出したときには、USBストレージデバイスへのアクセス時に利用する仮想的なSCSIインターフェースが生成される。また、SCSIインターフェースおよびUSBストレージデバイスに関する情報にアクセスするための情報公開用インターフェース(/procファイルシステム下にある擬似的なファイル)が生成される。これらを生成する処理は、USBストレージデバイス毎に実行される。これらの処理は、情報処理装置が備えるCPU等を中心とする制御部によって実行されるものであり、これが本発明でいうインターフェース生成手段に相当する。
そして、上述したドライブ名割り当て手段は、仮想的なSCSIインターフェースを検出する毎に、そのSCSIインターフェースを介してアクセス可能なUSBストレージデバイスに対して、ドライブ名を割り当てる処理を実行する。
ただし、一般的なLinux(登録商標)の場合、SCSIインターフェースを介してUSBストレージデバイスにアクセスする際、アクセス対象となるUSBストレージデバイスに対して割り当てたドライブ名が、SCSIインターフェースに伝達されることはない。それ故、SCSIインターフェースが備える記憶領域にドライブ名が保存されることもない。
そのため、一般的なLinux(登録商標)の場合、ドライブ名に基づいて、それに対応するSCSIインターフェースは特定できるものの、SCSIインターフェースに基づいて、それに対応するドライブ名を特定することはできない仕様となっている。これは、一般的なLinux(登録商標)の場合、本発明でいう管理者用USBポートに対応するSCSIインターフェースに基づいて、それに対応するUSBストレージデバイスのドライブ名(例えば“sda”)を特定できない仕様であることを意味する。
この点、本発明の場合は、上述の通り、SCSIインターフェースを介してUSBストレージデバイスにアクセスする際、アクセス対象となるUSBストレージデバイスに対して割り当てたドライブ名は、SCSIインターフェースが備える記憶領域に保存される。
したがって、管理者用USBポートに対応するSCSIインターフェースが備える記憶領域から、その記憶領域に保存されたドライブ名を読み取って、そのドライブ名に基づいて、所期のドライブ名ないしファイルシステム名を特定することができるのである。
ちなみに、一般的なSCSIインターフェースの場合は、単一のSCSIインターフェースに対して複数のストレージデバイスが接続される可能性がある。そのため、上記のようにSCSIインターフェースが備える記憶領域にドライブ名を保存しても、SCSIインターフェースとストレージデバイスとの1対1の関係を特定するには至らない。
しかし、USBストレージデバイスの接続に伴って生成される仮想的なSCSIインターフェースは、SCSIインターフェースとUSBストレージデバイスとが1対1の関係になっている。そのため、上記のようにSCSIインターフェースが備える記憶領域にドライブ名を保存すれば、そのドライブ名が「1対1の関係にあるUSBストレージデバイス」に割り当てられたものであると特定できる。
次に、請求項3に記載の情報処理装置は、請求項2に記載の情報処理装置において、前記ドライブ名割り当て手段は、前記USBストレージデバイスに対して前記ドライブ名を割り当てた後、前記USBストレージデバイスの容量に関する情報を取得するため、SCSI規格で規定されたSCSIコマンドの1種であるリードキャパシティコマンドを発行しており、当該リードキャパシティコマンドに対応する処理の中で、前記ドライブ名が前記SCSIインターフェースに伝達されることを特徴とする。
この情報処理装置において、USBストレージデバイスの容量に関する情報の取得は、デバイス認識後に必須の処理であり、SCSI規格に準拠した仕様となっているUSBストレージデバイスの場合、必ずリードキャパシティコマンドが発行される。
したがって、リードキャパシティコマンドが発行された際に実行される処理の中で、ドライブ名がSCSIインターフェースに伝達されれば、例えば、ドライブ名をSCSIインターフェースに伝達するための専用コマンドを新設するといった対処をしなくても済む。また、リードキャパシティコマンドを発行していた既存の処理については、何ら改修しなくてもリードキャパシティコマンドを発行するだけで、新たな機能が付加されることになる。
さらに、請求項4に記載の情報処理装置は、請求項2または請求項3に記載の情報処理装置において、前記ドライブ名取得手段は、前記情報公開用インターフェースを介して情報を取得可能なすべての前記USBストレージデバイスについて、順次情報の読み出しを繰り返すとともに、読み出した情報中に含まれるUSBポートに関する情報があらかじめ決められた前記管理者用USBポートに該当する情報か否かを判断し、前記管理者用USBポートに該当する情報であった場合に、読み出した情報中に含まれる前記ドライブ名を取得することを特徴とする。
このように構成された情報処理装置によれば、複数のUSBストレージデバイスが存在していても、それらを順に処理対象として情報を読み出しながら、管理者用USBポートに対応するドライブ名を選び出すことができる。
加えて、請求項5に記載の情報処理装置は、請求項1〜請求項4のいずれかに記載の情報処理装置において、前記管理者用USBポートは、情報処理装置の筐体内部に収容されていて、前記筐体が備えるパネルを開放したときにUSBデバイスを抜き挿し可能となるものであり、前記一般用USBポートは、前記筐体の外部に露出していて、前記パネルを開放しなくてもUSBデバイスを抜き挿し可能となっていることを特徴とする。
このように構成された情報処理装置によれば、管理者用USBポートは、パネルを開放しないとUSBデバイスを抜き挿しできない場所にあるので、管理者以外の利用者が誤って管理者用USBポートにUSBデバイスを装着してしまうのを未然に防止することができる。
次に、本発明の実施形態について一例を挙げて説明する。
[情報処理装置の内部構造]
図1は、本発明の一実施形態として例示する情報処理装置1の内部構造を示すブロック図である。
以下に説明する情報処理装置1は、電源投入後に自動的に所定のプログラム群を実行することで、この情報処理装置1が備える特定の機能が作動するように構成された特定機能専用の装置である。より具体的には、本実施形態の場合、情報処理装置1はカラオケコマンダーとして構成されたものであり、電源投入後に自動的に所定のプログラム群を実行することで、カラオケコマンダーとして各種機能が作動するように構成されている。この点で、実行対象となるプログラムが利用者の操作に応じて任意に変わり得るパーソナルコンピュータのような汎用的な装置とは異なるものである。
この情報処理装置1は、CPU11、ROM13、RAM15、ハードディスク装置17、およびUSBインターフェース20などを備えている。USBインターフェース20は、1つの内部USBポート21と、2つの外部USBポート22,23とを備え、内部USBポート21には、USBストレージデバイス25が接続されている。すなわち、この情報処理装置1には、ハードディスク装置17およびUSBストレージデバイス25、これら2種類のストレージデバイスが内蔵されている。
これらの内、ハードディスク装置17は、IDE方式の内蔵インターフェースを介して接続され、情報処理装置1の起動時には、通常、ハードディスク装置17に格納されたプログラムが読み込まれる仕組みになっている。また、詳しくは後述するが、ハードディスク装置17からプログラムを読み込むことができない状況に陥った場合、代替手段として、USBストレージデバイス25に格納されたプログラムが読み込まれる仕組みになっている。すなわち、ハードディスク装置17は通常の起動時に利用され、USBストレージデバイス25は通常の起動ができない緊急時に利用される。
また、この情報処理装置1は筐体31を備え、上記CPU11、ROM13、RAM15、およびハードディスク装置17等は筐体31の内部に収納されている。また、USBインターフェース20の内、内部USBポート21は筐体31の内部に収納される一方、外部USBポート22,23は筐体31の外部に露出する状態になっている。
筐体31には、開口部33が設けられていて、この開口部33はパネル35によって塞がれている。このパネル35は、固定具37によって筐体31に固定され、この固定具37は、専用治具(図示略)を利用した場合にのみ取り外すことができる構造になっている。
この固定具37を取り外してパネル35を開放できるのは、専用治具を所持する管理者だけであり、筐体31に内蔵された機器に直接触れることができるのは管理者のみである。したがって、内部USBポート21に接続されたUSBストレージデバイス25の抜き挿しなども、管理者しか実施することができない。一方、外部USBポート22,23は、上述の通り、筐体31の外部に露出しており、管理者以外の一般利用者であっても任意に各種USBデバイスを抜き挿しすることができる。
つまり、内部USBポート21は、管理者だけが利用可能な管理者用USBポートとされており、外部USBポート22,23は、管理者以外でも利用可能な一般用USBポートとされているのである。
さらに、これらのハードウェアを制御するため、情報処理装置1には、OSが搭載されている。本実施形態において、OSとしてはLinux(登録商標)が搭載されている。ただし、一般的なLinux(登録商標)が備える機能のみでは、本発明を実施する上で必要となる機能が十分に揃っていないため、一部独自の機能を追加してある。この追加機能の具体的な内容に関しては後から詳述するが、その他一般的なLinux(登録商標)と差異のない機能については、その説明を省略する。
[情報処理装置の起動時に実行される処理]
次に、上記情報処理装置1の起動時に実行される処理について説明する。
図2は、情報処理装置1の電源ONに伴って実行される処理のフローチャートである。
情報処理装置1の電源がONにされると、情報処理装置1では、まず、OSのカーネルがCPU11のメモリにロードされる(S105)。OSのカーネルはROM13内に格納されていて、S105では、CPU11がRAM15の一部をRAMディスクとして確保し、このRAMディスクにカーネルをロードする。これにより、このRAMディスクがルートボリュームとなってOSが起動し、OSの備える少なくとも一部の機能が作動を開始する。
こうしてOSの少なくとも一部が機能し始めると、続いて、情報処理装置1は、IDE方式で接続されたハードディスク装置17を認識する(S110)。このS110において、ハードディスク装置17にはドライブ名が割り当てられ、本実施形態の場合、ハードディスク装置17のドライブ名は“hda”となる。
続いて、情報処理装置1では、SCSIドライブ接続監視が開始される(S115)。本実施形態の場合、このS115では、SCSIドライブ接続監視プロセスが起動され、以降、このプロセスが常駐することにより、情報処理装置1の電源がOFFにされるまで、概ね6秒周期でSCSIドライブの接続/切断が監視される。
このSCSIドライブ接続監視の処理内容は、詳しくは図3に示すような処理となる。
すなわち、図3に示す「OS内SCSIドライブ接続監視」を開始すると、情報処理装置1は、まず、「SCSI−I/F接続テーブル(以下、SITBと称する。)」の初期化を行う(S205)。SITBは、情報処理装置1において現在接続中のSCSIインターフェース(以下、SCSI−I/Fと称する。)を登録するためのテーブルである。S205では、例えばハードウェアとして装着されているSCSI−I/Fが存在する場合に、その情報がSITBに登録する処理などが実行される。
そして、S205で登録したI/Fに接続されているドライブが存在する場合は、そのドライブをシステムに登録する(S210)。このS210により、登録されたドライブには“sda”,“sdb”,…といったドライブ名が割り当てられる。
続いて、情報処理装置1は、一定時間(例えば6秒)が経過したか否かを判断し(S215)、経過していなければ(S215:いいえ)、S215へと戻ることにより、時間経過を待つ。そして、一定時間が経過したら(S215:はい)、現在接続中のSCSI−I/Fを確認する(S220)。
その後、情報処理装置1は、新しく接続されたSCSI−I/Fの有無を判断し(S225)、新しく接続されたSCSI−I/Fが無い場合は(S225:無い)、今回切断されたSCSI−I/Fの有無を判断する(S230)。そして、今回切断されたSCSI−I/Fが無い場合は(S230:無い)、S215へ戻る。これにより、S215〜S230は、概ね6秒ごとに繰り返し実行されることになる。
そして、このようなS215〜S230の繰り返し処理が実行される中で、新しく接続されたSCSI−I/Fが有った場合(S225:有る)、情報処理装置1は、新規SCSI−I/Fを上述のSITBに登録し、そのI/Fに接続されているドライブをシステムに登録する(S235)。
このS235により、登録されたドライブには“sda”,“sdb”,…といったドライブ名が割り当てられる。また、ドライブの登録時には、そのドライブの容量に関する情報も必要となるので、その情報を取得するため、SCSI規格で規定されたSCSIコマンドの1種であるリードキャパシティコマンドを発行する。
このとき、この情報処理装置1では、リードキャパシティコマンドの発行対象となったドライブ名が、SCSI−I/F毎に用意された記憶領域に格納される。このような処理は、一般的なLinux(登録商標)では実施されていない特殊な処理であり、この情報処理装置1特有の処理である。
ちなみに、一つのSCSI−I/Fに複数のSCSIドライブが接続されている場合、上述のリードキャパシティコマンドは、複数のSCSIドライブに対して順に発行されてゆく。そのため、リードキャパシティコマンドの発行対象となったドライブ名も、順に変わってゆくので、SCSI−I/F毎に用意された記憶領域には、最後にリードキャパシティコマンドの発行対象となったドライブ名が格納されることになる。
ただし、一つのSCSI−I/Fに一つのSCSIドライブが接続されている場合であれば、上述のリードキャパシティコマンドは、一つのSCSIドライブに対してしか発行されない。そのため、リードキャパシティコマンドの発行対象となるドライブ名が変わることはなく、SCSI−I/F毎に用意された記憶領域には、そのSCSI−I/Fに接続されたドライブ名が格納されることになる。
さて、S235を終えたら、情報処理装置1は、今回接続の全SCSI−I/Fの処理が終了したか否かを判断し(S240)、終了していなければ(S240:いいえ 次のI/Fへ)、S235へと戻ることにより、残りのSCSI−I/FについてもS235を繰り返す。そして、今回接続の全SCSI−I/Fの処理が終了したら(S240:はい)、S230へと進む。
また、S215〜S230の繰り返し処理が実行される中で、今回切断されたSCSI−I/Fが有った場合(S230:有る)、情報処理装置1は、切断SCSI−I/FをSITBから削除し、そのI/Fに接続されているドライブをシステムから削除する(S245)。このS245により、削除されたドライブに対応するドライブ名はシステムから消滅する。
そして、情報処理装置1は、今回切断の全SCSI−I/Fの処理が終了したか否かを判断し(S250)、終了していなければ(S250:いいえ 次のI/Fへ)、S245へと戻ることにより、残りのSCSI−I/FについてもS245を繰り返す。そして、今回切断の全SCSI−I/Fの処理が終了したら(S240:はい)、S215へと戻る。
さて、以上説明したような処理がS115によって開始される処理となるが、ここで再び図2に戻り、S115を終えた時点からの説明を続ける。S115を終えると、情報処理装置1では、USB接続監視が開始される(S120)。本実施形態の場合、このS120では、USB接続監視プロセスが起動され、以降、このプロセスが常駐することにより、情報処理装置1の電源がOFFにされるまで、概ね100ミリ秒周期でUSBデバイスの接続/切断が監視される。
このUSB接続監視の処理内容は、詳しくは図4に示すような処理となる。
すなわち、図3に示す「OS内USB接続監視」を開始すると、情報処理装置1は、まず、「USBデバイス接続テーブル(以下、UDTBと称する。)」の初期化を行う(S305)。UDTBは、情報処理装置1において現在接続中のUSBデバイスを登録するためのテーブルである。なお、S305では、USBデバイスは何も接続されていない状態として扱われる。
続いて、情報処理装置1は、一定時間(例えば100ミリ秒)が経過したか否かを判断し(S315)、経過していなければ(S315:いいえ)、S315へと戻ることにより、時間経過を待つ。そして、一定時間が経過したら(S315:はい)、現在接続中のUSBデバイスを確認する(S320)。
その後、情報処理装置1は、新しく接続されたUSBデバイスの有無を判断し(S325)、新しく接続されたUSBデバイスが無い場合は(S325:無い)、今回切断されたUSBデバイスの有無を判断する(S330)。そして、今回切断されたUSBデバイスが無い場合は(S330:無い)、S315へ戻る。これにより、S315〜S330は、概ね6秒ごとに繰り返し実行されることになる。
そして、このようなS315〜S330の繰り返し処理が実行される中で、新しく接続されたUSBデバイスが有った場合(S325:有る)、情報処理装置1は、新規USBデバイスを上述のUDTBに登録し、デバイスドライバをシステムに登録する(S335)。このS335は、詳しくは図5に示すような処理となる。
すなわち、情報処理装置1は、図5に示すように、まず、USBデバイスの種類を判断する(S405)。ここで、USBストレージクラスのデバイスであると判断されれば(S405:USBストレージクラス)、仮想SCSI−I/F(仮想SCSIホストアダプタ)をシステムに登録し、“SCSIm”のシンボルをシステムから与えられる(S410)。なお、上記“SCSIm”中にある“m”は「0」からの通し番号で、切断後は再利用される番号である。
また、情報処理装置1は、“/proc/scsi/usb−storage”に情報公開手段をシステム登録、“/proc/scsi/usb−storage/n”のシンボルをシステムから与えられる(S415)。なお、上記“/proc/scsi/usb−storage/n”中にある“n”は「0」からの通し番号で、こちらは切断後の再利用はされない番号である。
一方、S405において、USBストレージクラス以外のデバイスであると判断されれば(S405:USBストレージクラス以外)、情報処理装置1は、各USBデバイス用の登録処理を行う(S420)。このS420の処理は、USBデバイスの種類によってさらに何通りかの処理にわかれるが、この処理の詳細は本発明の要部ではないので、これ以上の説明は省略する。
以上説明したようなS405〜S420の処理(図5参照)を終えると、図4に示したS335を終えたことになり、その場合、情報処理装置1は、今回接続の全USBデバイスの処理が終了したか否かを判断する(S340)。
ここで、今回接続の全USBデバイスの処理が終了していなければ(S340:いいえ 次のI/Fへ)、S335へと戻ることにより、残りのUSBデバイスについてもS335を繰り返す。そして、今回接続の全USBデバイスの処理が終了したら(S340:はい)、S330へと進む。
また、S315〜S330の繰り返し処理が実行される中で、今回切断されたUSBデバイスが有った場合(S330:有る)、情報処理装置1は、切断USBデバイスをUDTBから削除し、そのI/Fに接続されているドライブをシステムから削除する(S345)。このS345は、詳しくは図6に示すような処理となる。
すなわち、情報処理装置1は、図6に示すように、まず、USBデバイスの種類を判断する(S505)。ここで、USBストレージクラスのデバイスであると判断されれば(S505:USBストレージクラス)、“/proc/scsi/usb−storage/n”の情報公開手段をシステムから削除する(S510)。なお、既に説明した通り、この番号“n”が再利用されることはない。
また、“SCSIm”の仮想SCSI−I/F(仮想SCSIホストアダプタ)をシステムから削除する(S515)。なお、既に説明した通り、この番号“m”は以降も必要に応じて再利用されることがある。
一方、S505において、USBストレージクラス以外のデバイスであると判断されれば(S505:USBストレージクラス以外)、情報処理装置1は、各USBデバイス用の削除処理を行う(S520)。このS520の処理は、USBデバイスの種類によってさらに何通りかの処理にわかれるが、この処理の詳細は本発明の要部ではないので、これ以上の説明は省略する。
以上説明したようなS505〜S520の処理(図6参照)を終えると、図4に示したS345を終えたことになり、その場合、情報処理装置1は、今回切断の全USBデバイスの処理が終了したか否かを判断する(S350)。ここで、今回切断の全USBデバイスの処理が終了していなければ(S350:いいえ 次のI/Fへ)、S345へと戻ることにより、残りのUSBデバイスについてもS345を繰り返す。そして、今回切断の全USBデバイスの処理が終了したら(S340:はい)、S315へと戻る。
さて、以上説明したような処理が、S120によって開始される処理となるが、ここで再び図2に戻り、S120を終えた時点からの説明を続ける。S120を終えると、情報処理装置1では、電源ON時に接続されているUSBデバイスが一括で認識される(S125)。このような認識が行われるのは、上記S120により、USB接続監視の処理を開始しているからである。
そして、認識されたUSBデバイスの中に、USBストレージデバイスが有る場合は、その中に存在するドライブがSCSIドライブと認識される(S130)。このような認識が行われるのは、上記S115により、SCSIドライブ接続監視の処理を開始しているからである。
続いて、情報処理装置1では、カーネルの初期化を終了し、最初のスクリプトが実行される(S135)。そして、メインで使用するボリュームのマウント処理を実行する(S140)。
このS140は、詳しくは図7に示すような処理となる。すなわち、図7に示す処理を開始すると、情報処理装置1は、“/dev/hda1”のファイルシステムを、所定のマウントポイント“/main”にマウントする(S605)。ここで、ドライブ名が“hda”になること、および、ファイルシステム名が“hda1”になることは、情報処理装置1の構成上、事前に決まっている事項である。
そして、S605を終えたら、マウント成功か否かを判断する(S610)。ここで、マウント成功であれば(S610:成功)、マウントしたボリューム内のスクリプト“/main/prog/startup.sh”を実行する(S615)。
一方、S610において、マウント失敗であれば(S610:成功)、このままではスクリプト“/main/prog/startup.sh”を実行できず、情報処理装置1は通常通りに起動できなくなる。
そこで、この場合は、バックアップ動作用USBポートからSCSIドライブ名を割り出す(S620)。このS620は、詳しくは図8に示すような処理となる。すなわち、図8に示す処理を開始すると、情報処理装置1は、まず、“/proc/scsi/usb−storage”の下のファイルを検索する(S705)。
そして、ファイルが有るかどうかを判断する(S710)。ここで、ファイルが有る場合は(S710:はい)、見つかったファイルをリードする(S715)。ここでリード対象となるファイル“/proc/scsi/usb−storage/n”は、USBストレージデバイスおよびUSBポートに関する情報を提供する情報公開手段である。
S715では、上記ファイルをリードすることにより、USBポートの情報やUSBストレージデバイスの情報などを取得することができる。また、こうしたUSBポートの情報やUSBストレージデバイスの情報などは、一般的なLinux(登録商標)でも取得可能な情報であるが、この情報処理装置1において、S715では、USBストレージデバイスに割り当てられたドライブ名をも取得することができる。
このドライブ名は、上記S235の処理により、SCSI−I/F毎に用意された記憶領域に格納されたドライブ名そのものである。一般的なLinux(登録商標)の場合、SCSI−I/Fを利用する際に、SCSI−I/Fにドライブ名が通知されることはないので、SCSI−I/Fに接続されたSCSIドライブに、どのようなドライブ名が割り当てられているのかを、SCSI−I/F側で知る術はない。
しかし、この情報処理装置1では、上述の通り、リードキャパシティコマンドが発行される毎に、コマンドの発行対象となったドライブ名がSCSI−I/F側に伝達されて、そのドライブ名がSCSI−I/F側の記憶領域に残される。
したがって、この記憶領域に残された情報を見れば、SCSI−I/Fに接続されたSCSIドライブに、どのようなドライブ名が割り当てられているのかを、SCSI−I/F側で知ることができる。
また、SCSI−I/Fに複数のSCSIドライブが接続されている場合、上記SCSI−I/F側の記憶領域には、その内の一つのSCSIドライブに割り当てられた名前だけしか残されない。しかし、USBストレージデバイスの場合、一つのUSBストレージデバイスに対して一つの仮想SCSI−I/Fが生成される。そのため、このSCSI−I/Fに対応する記憶領域に残されるのは、必ず一つのドライブ名のみとなるので、USBストレージデバイスに割り当てられたドライブ名を問題なく特定できる。
つまり、S715で取得した情報を見れば、一般的なLinux(登録商標)同様、その情報がどのUSBポートに対応する情報なのかを特定できる。しかも、一般的なLinux(登録商標)とは異なり、その情報がどのようなドライブ名に対応する情報なのかをも特定できるのである。
そこで、S715を終えたら、情報処理装置1は、まず、接続ポートを判断して(S720)、内部USBポート21に対応する情報か否かを確認する。ここで、内部USBポート21に対応する情報でなければ(S720:USBポートが違う)、S710へと戻る。ちなみに、このようにS710へと戻ることになるのは、外部USBポート22,23のいずれかにもUSBストレージデバイスが接続されている場合である。
一方、S720において、内部USBポート21に対応する情報であれば(S720:探していたUSBポート)、最後にリードキャパシティを実行したドライブ名を取得する(S725)。すなわち、S715でリードした情報の中からドライブ名を抽出する。
このドライブ名は、“sda”,“sdb”,…といったドライブ名であるが、その末尾の文字“a”,“b”,…は、どのような文字になるのか保証がない。具体的には、内部USBポート21にUSBストレージデバイス25が接続され、さらに外部USBポート22,23にもUSBストレージデバイスが接続されている場合、先に認識されたデバイスにはドライブ名“sda”が付与される。また、その後に認識されたデバイスにはドライブ名“sdb”が付与される。しかし、どのデバイスが先に認識されるかは不定であるため、例えばドライブ名“sda”が付与されたデバイスがUSBストレージデバイス25なのかどうかは不定となる。
この点、S710〜S720により、内部USBポート21に対応する情報を探し出し、S725により、ドライブ名を抽出すれば、内部USBポート21に接続されたUSBストレージデバイス25に割り当てられたドライブ名を確実に取得できるのである。
なお、S710で、所期のUSBポートが見つかる前にリード対象となるファイルが無くなった場合は(S710:いいえ)、図8に示す処理を終了する。これは、内部USBポート21にUSBストレージデバイス25が接続されていない場合の処理に相当する。
さて、以上説明したような処理を終えると、図7に示したS620の処理を終えたことになるので、その場合、情報処理装置1は、“/dev/sdx1”のファイルシステムを、所定のマウントポイント“/main”にマウントする(S625)。ここで、“sdx”は、S725で取得したドライブ名である。つまり、S725までの処理で割り出したSCSIドライブのドライブ名を利用して、SCSIドライブ上のパーティション(ファイルシステム)を指定し、そのパーティションを“/main”にマウントしているのである。
そして、S625を終えたら、マウントに成功したか否かを判断し(S630)、成功していれば(S630:成功)、既に説明したS615へと進むことにより、マウントしたボリューム内のスクリプト“/main/prog/startup.sh”を実行する(S615)。また、マウントに失敗した場合は(S630:失敗)、図7に示す処理を終了する。
さて、以上説明したような処理を終えると、図2に示すS140を終えたことになるので、続いて、情報処理装置1では、メインで使用するボリューム内のスタートアッププログラムが起動する(S145)。すなわち、“/main”に“hda1”または“sdx1”のいずれがマウントされるかは、状況によって分かれるものの、いずれにしても、いずれかのボリューム内のスタートアッププログラムが起動するのである。
そして、情報処理装置1では、システムが専用装置として動作し(S150)、以降は、利用者からのシャットダウン指示が有るまで(S155:いいえ)、専用装置としての動作を継続する。一方、利用者からのシャットダウン指示があった場合は(S155:はい)、シャットダウン処理を実行し(S160)、電源OFFに至る。
[効果]
以上説明した情報処理装置1によれば、まず、S605を実行する手段(第1マウント手段)が、“/dev/hda1”のファイルシステム(第1ファイルシステム)を“/main”(所定のマウントポイント)にマウントし、マウントできたら、S615,S145を実行する手段(処理実行手段)は、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。
一方、“/dev/hda1”のファイルシステムのマウントに失敗した場合は、S625を実行する手段(第2マウント手段)が、“/dev/sdx1”のファイルシステム(第2ファイルシステム)を“/main”(所定のマウントポイント)にマウントし、マウントできたら、S615,S145を実行する手段(処理実行手段)は、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する。
したがって、通常は、“/dev/hda1”のファイルシステム(第1ファイルシステム)から各種処理を起動する一方、何らかの原因(例えば故障等)により、“/dev/hda1”のマウントに失敗した場合は、“/dev/sdx1”のファイルシステム(第2ファイルシステム)から緊急時用の代替処理を起動することができる。
また、複数あるUSBポートに2以上のUSBストレージデバイスが接続されていると、S235を実行する手段(ドライブ名割り当て手段)が、それら複数のUSBストレージデバイスに対してどのようなドライブ名を割り当てるのかは不定となる。そのため、内部USBポート21(管理者用USBポート)に接続されたUSBストレージデバイス25に対して割り当てられたドライブ名も不定となる。
しかし、S620を実行する手段(ドライブ名取得手段)は、内部USBポート21に接続されたUSBストレージデバイス25に対して割り当てられたドライブ名を取得する。そのため、S625を実行する手段(第2マウント手段)は、S620で取得されたドライブ名を利用して、USBストレージデバイス25上にあるファイルシステムを適切に特定することができる。
したがって、S625では、適切なファイルシステムを“/main”にマウントすることができ、外部USBポート22,23のいずれかに接続されたUSBストレージデバイス上のファイルシステムを誤ってマウントしてしまうことはない。
よって、適切なファイルシステムがマウントされた後、S615,S145では、マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく適切な処理を実行することができる。
さらに、上記情報処理装置1においては、S235で、SCSIインターフェースを介してUSBストレージデバイスにアクセスする際に、USBストレージデバイスに割り当てられたドライブ名が、SCSIインターフェースの備える記憶領域に保存される。
そのため、S625では、“/proc/scsi/usb−storage/n”の情報公開手段(情報公開用インターフェース)を介して情報を取得すると、SCSIインターフェースおよびUSBストレージデバイスに関する情報に加え、ドライブ名の情報をも取得することができる。したがって、一般的なLinux(登録商標)とは異なり、きわめて容易にUSBポートに対応するドライブ名の情報を得ることができる。
しかも、このようなドライブ名の情報をSCSIインターフェースの備える記憶領域に保存する処理は、リードキャパシティコマンドに対応する処理の中で実行するので、リードキャパシティコマンドを発行する上位プログラムには手を加えなくても、ドライブ名を記憶領域に残す仕組みを導入できる。したがって、ドライブ名をSCSIインターフェースに伝達するための専用コマンドを新設しなくてもよく、大がかりなプログラムの改修は不要となる。
加えて、上記情報処理装置1においては、S710〜S720を繰り返すので、複数のUSBストレージデバイスが存在していても、それらを順に処理対象として情報を読み出しながら、管理者用USBポートに対応するドライブ名を選び出すことができる。
また、内部USBポート21は、パネル35を開放しないとUSBストレージデバイス25を抜き挿しできない場所にあるので、管理者以外の利用者が誤って内部USBポート21にUSBデバイスを装着してしまうのを未然に防止することができる。
つまり、内部USBポート21からはプログラムを起動できるものの、管理者以外が容易に利用できる状態にはなく、外部USBポート22,23は管理者以外でも容易に利用できるものの、ここからプログラムを起動することはできない仕組みになっている。
したがって、緊急時にUSBストレージデバイス25からの起動を実施できる仕組みを実装しているにもかかわらず、外部USBポート22,23からの起動を防止でき、システムが正常に起動しなくなったり、予期しないプログラムが実行されてしまったりするのを、未然に防止することができる。
[変形例等]
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
例えば、上記実施形態では、カラオケコマンダーとしての機能を備えた情報処理装置1を例示したが、通常はIDEストレージデバイスからの起動を行い、緊急時にUSBストレージデバイスからの起動を行うように構成されていれば、自動起動される機能をどのような機能とするかは任意である。すなわち、カラオケコマンダー以外にも、各種特定用途での専用情報処理装置において、本発明の構成を採用することができる。
情報処理装置の内部構造を示すブロック図。 情報処理装置の電源ONに伴って実行される処理のフローチャート。 OS内SCSIドライブ接続監視のフローチャート。 OS内USBデバイス接続監視のフローチャート。 S335の詳細を示すフローチャート。 S345の詳細を示すフローチャート。 S140の詳細を示すフローチャート。 S620の詳細を示すフローチャート。
符号の説明
1・・・情報処理装置、11・・・CPU、13・・・ROM、15・・・RAM、17・・・ハードディスク装置、20・・・USBインターフェース、21・・・内部USBポート、22,23・・・外部USBポート、25・・・USBストレージデバイス、31・・・筐体、33・・・開口部、35・・・パネル、37・・・固定具。

Claims (5)

  1. IDE(Integrated Drive Electronics)方式で接続されたハードディスクドライブとして機能するIDEストレージデバイスと、それぞれにUSB(Universal Serial Bus)ストレージデバイスを接続可能な複数のUSBポートとを備え、前記複数のUSBポートの内、少なくとも1つのUSBポートは管理者だけが利用可能な管理者用USBポート、残りのUSBポートは管理者以外でも利用可能な一般用USBポートとされている情報処理装置であって、
    前記情報処理装置の起動時に、前記IDEストレージデバイスおよび前記USBポートに接続されたUSBストレージデバイスを検出すると、検出した前記IDEストレージデバイスないし前記USBストレージデバイスそれぞれに対して、ユニークなドライブ名を割り当てるドライブ名割り当て手段と、
    前記ドライブ名割り当て手段によって前記IDEストレージデバイスに対して割り当てられた前記ドライブ名を利用して、前記IDEストレージデバイス上にある第1ファイルシステムを特定するとともに、当該特定した前記第1ファイルシステムを所定のマウントポイントにマウントする第1マウント手段と、
    前記第1マウント手段が前記第1ファイルシステムのマウントに成功したか否かを判定する判定手段と、
    前記判定手段によって前記第1ファイルシステムのマウントに失敗したと判定された場合に、前記管理者用USBポートに接続された前記USBストレージデバイスに対して前記ドライブ名割り当て手段が割り当てた前記ドライブ名を取得するドライブ名取得手段と、
    前記ドライブ名取得手段によって取得された前記ドライブ名を利用して、前記管理者用USBポートに接続された前記USBストレージデバイス上にある第2ファイルシステムを特定するとともに、当該特定した前記第2ファイルシステムを前記マウントポイントにマウントする第2マウント手段と、
    前記第1マウント手段または前記第2マウント手段のいずれかによって前記第1ファイルシステムまたは第2ファイルシステムが前記マウントポイントにマウントされたら、前記マウントポイント下にあるファイル群からプログラムを読み込んで、当該プログラムに基づく処理を実行する処理実行手段と
    を備えたことを特徴とする情報処理装置。
  2. 前記USBストレージデバイスを検出したときに、前記USBストレージデバイスへのアクセス時に利用する仮想的なSCSI(Small Computer System Interface)インターフェースと、前記SCSIインターフェースおよび前記USBストレージデバイスに関する情報にアクセスするための情報公開用インターフェースとを、前記USBストレージデバイス毎に生成するインターフェース生成手段
    を備え、
    前記ドライブ名割り当て手段は、前記インターフェース生成手段によって生成された前記SCSIインターフェースを検出する毎に、前記SCSIインターフェースを介してアクセス可能な前記USBストレージデバイスに対して、前記ドライブ名を割り当てるとともに、前記SCSIインターフェースを介して前記USBストレージデバイスにアクセスする際には、アクセス対象となる前記USBストレージデバイスに対して割り当てた前記ドライブ名を、前記SCSIインターフェースに伝達することにより、前記SCSIインターフェースが備える記憶領域に前記ドライブ名を保存し、
    前記ドライブ名取得手段は、前記情報公開用インターフェースを介して前記SCSIインターフェースが備える記憶領域に格納された情報を読み出し、その読み出した情報中から前記管理者用USBポートと前記ドライブ名との対応関係を示す情報を取得する
    ことを特徴とする請求項1に記載の情報処理装置。
  3. 前記ドライブ名割り当て手段は、前記USBストレージデバイスに対して前記ドライブ名を割り当てた後、前記USBストレージデバイスの容量に関する情報を取得するため、SCSI規格で規定されたSCSIコマンドの1種であるリードキャパシティコマンドを発行しており、当該リードキャパシティコマンドに対応する処理の中で、前記ドライブ名が前記SCSIインターフェースに伝達される
    ことを特徴とする請求項2に記載の情報処理装置。
  4. 前記ドライブ名取得手段は、前記情報公開用インターフェースを介して情報を取得可能なすべての前記USBストレージデバイスについて、順次情報の読み出しを繰り返すとともに、読み出した情報中に含まれるUSBポートに関する情報があらかじめ決められた前記管理者用USBポートに該当する情報か否かを判断し、前記管理者用USBポートに該当する情報であった場合に、読み出した情報中に含まれる前記ドライブ名を取得する
    ことを特徴とする請求項2または請求項3に記載の情報処理装置。
  5. 前記管理者用USBポートは、情報処理装置の筐体内部に収容されていて、前記筐体が備えるパネルを開放したときにUSBデバイスを抜き挿し可能となるものであり、
    前記一般用USBポートは、前記筐体の外部に露出していて、前記パネルを開放しなくてもUSBデバイスを抜き挿し可能となっている
    ことを特徴とする請求項1〜請求項4のいずれかに記載の情報処理装置。
JP2008050260A 2008-02-29 2008-02-29 情報処理装置 Expired - Fee Related JP4946919B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008050260A JP4946919B2 (ja) 2008-02-29 2008-02-29 情報処理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008050260A JP4946919B2 (ja) 2008-02-29 2008-02-29 情報処理装置

Publications (2)

Publication Number Publication Date
JP2009205655A true JP2009205655A (ja) 2009-09-10
JP4946919B2 JP4946919B2 (ja) 2012-06-06

Family

ID=41147802

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008050260A Expired - Fee Related JP4946919B2 (ja) 2008-02-29 2008-02-29 情報処理装置

Country Status (1)

Country Link
JP (1) JP4946919B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104679676A (zh) * 2014-11-27 2015-06-03 汉柏科技有限公司 Usb设备的挂载方法及系统
JP7473287B2 (ja) 2019-09-16 2024-04-23 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータ・システムの複数のインスタンスと関連付けられたリソースをプロビジョニングするための方法、装置及びコンピュータ・プログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004032308A (ja) * 2002-06-25 2004-01-29 Toshiba Corp ポート接続状態表示方法および通信装置および通信システム
JP2005174241A (ja) * 2003-12-15 2005-06-30 Canon Inc 記憶装置
JP2005250742A (ja) * 2004-03-03 2005-09-15 Ricoh Co Ltd プリントシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004032308A (ja) * 2002-06-25 2004-01-29 Toshiba Corp ポート接続状態表示方法および通信装置および通信システム
JP2005174241A (ja) * 2003-12-15 2005-06-30 Canon Inc 記憶装置
JP2005250742A (ja) * 2004-03-03 2005-09-15 Ricoh Co Ltd プリントシステム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104679676A (zh) * 2014-11-27 2015-06-03 汉柏科技有限公司 Usb设备的挂载方法及系统
JP7473287B2 (ja) 2019-09-16 2024-04-23 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータ・システムの複数のインスタンスと関連付けられたリソースをプロビジョニングするための方法、装置及びコンピュータ・プログラム

Also Published As

Publication number Publication date
JP4946919B2 (ja) 2012-06-06

Similar Documents

Publication Publication Date Title
US9778844B2 (en) Installation of operating system on host computer using virtual storage of BMC
US8612803B2 (en) Information processing apparatus and driver execution control method
US8751783B2 (en) Booting computing devices with EFI aware operating systems
US9239725B2 (en) System and method for installing an OS via a network card supporting PXE
US12001285B2 (en) System booting method and apparatus, node device, and computer-readable storage medium
US9152492B2 (en) Performing recovery of a headless computer
CN109426613B (zh) 在uefi中检索调试数据的方法及其电脑系统
EP2189906A1 (en) Method and apparatus for abnormality recovering of data card, and data card
JP2009140194A (ja) 障害回復環境の設定方法
JP2007133544A (ja) 障害情報解析方法及びその実施装置
JP2020187725A (ja) 管理コントローラへの通信チャネルの方法及びシステム
US10491736B2 (en) Computer system and method thereof for bluetooth data sharing between UEFI firmware and OS
WO2012097574A1 (zh) 一种无线通讯终端及其自启动的方法
JP4759941B2 (ja) 起動イメージ提供システム及び方法、ブートノード装置、ブートサーバ装置並びにプログラム
JP4946919B2 (ja) 情報処理装置
JP6599725B2 (ja) 情報処理装置およびログ管理方法、並びにコンピュータ・プログラム
JP5056567B2 (ja) 情報処理装置
CN109086085B (zh) 一种操作系统启动管理方法和装置
TWI518594B (zh) 計算機系統與計算機系統啓動方法
TWI754221B (zh) 軟體存留性關閉技術
JPWO2018216068A1 (ja) ストレージシステム及びマッピング方法
CN109254800B (zh) 一种设备信息处理方法、电子设备及服务器
JP2011145827A (ja) 仮想バスシステム、およびデバイス管理方法
JP2013206001A (ja) 制御プログラム、制御方法および記憶装置
EP1914628B1 (en) Method for changing booting sources of computer system and related backup/restore method thereof

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100118

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120130

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120207

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120220

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150316

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4946919

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees