JP2006085702A - コンソールなしでブートする方法 - Google Patents

Abstract

【課題】 コンピュータシステムにおいて、たとえばＵＡＲＴが機能していないためにコンソールが故障しことにより、システムがシャットダウンしたときに、正常にリブートまたは初期化できるようにする。
【解決手段】 本発明にかかる少なくとも１つのコンソール（１０５）を含むコンピューティングデバイス（１００）のためのシステムは、前記コンソール（１０５）との通信が機能しているか否かを検出し、前記コンピューティングデバイス（１００）が機能してないコンソールでのブートを可能にするように構成されるブートロジック（１１０）を具備する。
【選択図】図１

Description

本発明は、コンソールなしでブートする方法に関する。

コンピュータシステムには、情報を表示することができるとともにキーボードまたは他の入力デバイスを用いる情報の入力を可能にする場合もある、コンソールを有するものがある。
コンソールを、たとえば汎用非同期送受信装置（ＵＡＲＴ）を有する通信ポートを介してコンピュータシステムに接続することができる。
ＵＡＲＴは、シリアルポートを管理することができ、接続されたシリアルデバイスへの非同期シリアル通信を処理することができる、コンピュータコンポーネントである。

多くのコンピュータシステムでは、たとえばＵＡＲＴが機能していないためにコンソールが故障した場合、システムはシャットダウンし、リブートしようと試みる。
しかしながら、リブートプロセス中、システムは、機能しているコンソールがないために、うまくリブートまたは初期化しない場合がある。
したがって、オペレーティングシステムをロードすることができず、コンピュータシステムは動作可能にならない。

上記目的を達成するために、本発明にかかる少なくとも１つのコンソール（１０５）を含むコンピューティングデバイス（１００）のためのシステムは、前記コンソール（１０５）との通信が機能しているか否かを検出し、前記コンピューティングデバイス（１００）が機能してないコンソールでのブートを可能にするように構成されるブートロジック（１１０）を具備する。

明細書に組み込まれかつ明細書の一部を構成する添付図面は、本発明のさまざまな態様のさまざまな例としてのシステム、方法および他の例としての実施形態を示す。
図において示される要素の境界（たとえば、ボックス、ボックス群、または他の形状）は境界の一例を表す、ということが理解されよう。
当業者は、１つの要素を複数の要素として設計してもよく、または複数の要素を１つの要素として設計してもよい、ということを理解するであろう。
別の要素の内部構成要素として示す要素を、外部構成要素として実施してもよく、その逆も可能である。さらに、要素は、一定比例尺になっていない場合がある。

本明細書では、コンピューティングシステムのシステムブートに関連付けることができる、例としてのシステム、方法、媒体および他の実施形態について説明する。
少なくとも１つのコンソールを含むコンピューティングデバイスのためのシステムの一例では、そのシステム例は、コンソールとの通信が機能しているか機能していないかを検出するように構成されたブートロジックを含み、かつ、コンピューティングシステムが機能していないコンソールでブートすることができるようにする。

上記システム例は、機能しているコンソールなしにその負荷を十分に実行することができるコンピューティングシステムに対し有用であり得る。
たとえば、コンソールが故障し、または汎用非同期送受信装置（ＵＡＲＴ）が故障することによる等、コンソールとコンピューティングシステムとの間の通信が喪失する場合、コンピューティングデバイスは動作を停止しリブートを試みる場合がある。
システム例は、機能しているＵＡＲＴがない場合、したがって機能しているコンソールがない場合に、リブートを失敗させるのではなく、コンピューティングシステムがうまくリブートするのを助けることができる。
したがって、コンピューティングデバイスの全可用性を向上させることができる。

以下は、本明細書で採用する選択された用語の定義を含む。
それら定義には、１つの用語の範囲内に含まれるとともに実施のために使用してもよい構成要素のさまざまな例および／または形態が含まれる。
それら例は、限定するようには意図されていない。
用語の単数形および複数形はともに、それら定義内にあり得る。

本明細書で使用する「コンピュータコンポーネント」という用語は、ハードウェア、ファームウェア、ソフトウェア、それらの組合せまたは実行中のソフトウェアのいずれかである、コンピュータ関連エンティティを言う。
たとえば、コンピュータコンポーネントは、限定されないが、プロセッサで実行しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラムおよびコンピュータであってもよい。
例として、サーバで実行しているアプリケーションとサーバとはともに、コンピュータコンポーネントであり得る。
１つまたは複数のコンピュータコンポーネントが、プロセスおよび／または実行のスレッド内に存在してもよく、コンピュータコンポーネントを１つのコンピュータに局所化してもよく、かつ／または２つ以上のコンピュータ間に分散させてもよい。

本明細書で使用する「コンピュータ読取可能媒体」とは、信号、命令および／またはデータを直接または間接的に提供することに関与する媒体を言う。
コンピュータ読取可能媒体は、限定されないが不揮発性媒体、揮発性媒体および伝送媒体を含む形態をとってもよい。
不揮発性媒体には、限定されないが、光ディスクまたは磁気ディスク、ファームウェア等が含まれてもよい。
揮発性媒体には、たとえば、半導体メモリ、ダイナミックメモリ等が含まれてもよい。
伝送媒体には、同軸ケーブル、銅線、光ファイバケーブル等が含まれてもよい。
伝送媒体は、電波データ通信および赤外線データ通信中に生成されるもののような電磁放射の形態をとることも可能であり、もしくは１つまたは複数の信号群の形態をとることも可能である。
コンピュータ読取可能媒体の一般的な形態には、限定されないが、フロッピーディスク（登録商標）、フレキシブルディスク、ハードディスク、磁気テープ、他の磁気媒体、ＣＤ−ＲＯＭ、他の光媒体、パンチカード、紙カード、穴のパターンを有する他の物理媒体、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、または他のメモリチップまたはカード、メモリスティック、搬送波／パルス、およびコンピュータ、プロセッサまたは他の電子デバイスが読出しをすることができる他の媒体が含まれる。
インターネットのようなネットワークにより命令または他のソフトウェアを伝播するために使用される信号も、「コンピュータ読取可能媒体」とみなすことができる。

本明細書で使用する「ロジック」には、限定されないが、機能（複数可）または動作（複数可）を実行し、かつ／もしくは別のロジック、方法および／またはシステムから機能または動作をもたらす、ハードウェア、ファームウェア、ソフトウェアおよび／または各々の組合せが含まれる。
たとえば、所望のアプリケーションまたはニーズに基づき、ロジックには、ソフトウェア制御マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）のようなディスクリートロジック、アナログ回路、デジタル回路、プログラムされたロジックデバイス、命令を含むメモリデバイス等が含まれてもよい。
ロジックには、１つまたは複数のゲート、ゲートの組合せまたは他の回路コンポーネントが含まれてもよい。
また、ロジックをソフトウェアとして完全に具現化してもよい。
複数の論理ロジックについて述べる場合に、複数の論理ロジックを１つの物理ロジックに組み込むことも可能であり得る。
同様に、単一の論理ロジックについて述べる場合に、その単一の論理ロジックを複数の物理ロジック間で分散させることも可能であり得る。

「動作可能接続」、またはエンティティが「動作可能に接続される」ようにする接続は、信号、物理的通信および／または論理的通信を送信および／または受信してもよい接続である。
通常、動作可能接続には、物理インタフェース、電気インタフェースおよび／またはデータインタフェースが含まれるが、動作可能接続には、動作可能制御を可能にするために十分な、これらまたは他のタイプの接続の異なる組合せが含まれてもよい、ということに留意しなければならない。
たとえば、２つのエンティティを、直接、もしくはプロセッサ、オペレーティングシステム、ロジック、ソフトウェアまたは他のエンティティのような１つまたは複数の中間エンティティを介して、互いに信号を通信することができるようにすることにより、動作可能に接続することができる。
論理および／または物理通信チャネルを使用して動作可能接続を生成してもよい。

本明細書で使用する「信号」には、限定されないが、１つまたは複数の電気または光信号、アナログまたはデジタル信号、データ、１つまたは複数のコンピュータまたはプロセッサ命令、メッセージ、ビットまたはビットストリーム、フラグ、パラメータ、もしくは受信、送信および／または検出することができる他の手段が含まれる。

本明細書で使用する「ソフトウェア」には、限定されないが、読み出し、解釈し、コンパイルし、かつ／または実行することができるとともに、コンピュータ、プロセッサまたは他の電子デバイスに対し機能、動作を実行させかつ／または所望の方法で振る舞わせる、１つまたは複数のコンピュータまたはプロセッサ命令が含まれる。
命令を、ルーチン、アルゴリズム、モジュール、メソッド、スレッド、および／または動的にリンクされたライブラリからの個別のアプリケーションまたはコードを含むプログラムのようなさまざまな形式で具現化してもよい。
また、ソフトウェアを、限定されないがスタンドアロンプログラム、ファンクションコール（ローカルおよび／またはリモート）、サーブレット、アプレット、メモリに格納された命令、オペレーティングシステムの一部または他のタイプの実行可能命令を含む種々の実行可能かつ／またはロード可能な形式で実施してもよい。
当業者には、ソフトウェアの形式が、たとえば所望のアプリケーションの要件、それが実行する環境、および／またはデザイナ／プログラマ等の要求によって決まってもよい、ということが理解されよう。
また、コンピュータ読取可能かつ／または実行可能命令を、１つのロジックに配置してもよく、かつ／または２つ以上の通信、協働および／または並列処理するロジック間に分散させてもよく、そのため直列、並列、超並列および他の方法でロードおよび／または実行することができる、ということも理解されよう。

本明細書で説明するシステムおよび方法例のさまざまなコンポーネントを実施する適当なソフトウェアには、Ｊａｖａ（登録商標）、Ｐａｓｃａｌ、Ｃ＃、Ｃ＋＋、Ｃ、ＣＧＩ、Ｐｅｒｌ、ＳＱＬ、ＡＰＩ、ＳＤＫ、アセンブリ、ファームウェア、マイクロコードならびに／または他の言語およびツールのような、プログラミング言語およびツールが含まれる。
システム全体であるかシステムのコンポーネントであるかに関わらず、ソフトウェアを、製品の一部として具現化し、かつ、先に定義したようなコンピュータ読取可能媒体の一部として維持または提供してもよい。
ソフトウェアの別の形態には、ソフトウェアのプログラムコードを、ネットワークまたは他の通信媒体により受信側に送信する信号が含まれてもよい。
したがって、一例では、コンピュータ読取可能媒体は、ウェブサーバからユーザにダウンロードされるソフトウェア／ファームウェアを表す信号の形態を有する。
別の例では、コンピュータ読取可能媒体は、ウェブサーバに維持されるソフトウェア／ファームウェアの形態を有する。
他の形式を使用してもよい。

本明細書で使用する「ユーザ」には、限定されないが、１人または複数の人、１つまたは複数のソフトウェア、コンピュータまたは他のデバイス、もしくはこれらの組合せが含まれる。

以下の詳細な説明のいくつかの部分を、メモリ内のデータビットに対する動作のアルゴリズムおよび記号表現に関して示す。
これらのアルゴリズム的説明および表現は、当業者が自身の作業の内容を他人に伝達するために使用する手段である。
アルゴリズムは、ここでは、かつ一般に、結果をもたらす一続きの動作であると考えられる。
これら動作には、物理量の物理的操作が含まれてもよい。
通常、必ずしもではないが、物理量は、格納され、転送され、結合され、比較され、かつロジック等において他の方法で操作されることが可能な電気信号または磁気信号の形態をとる。

時に、主に一般的に使用されているという理由で、これらの信号をビット、値、要素、シンボル、キャラクタ、項、数等と呼ぶことが都合がよいことが分かっている。
しかしながら、これらおよび同様の用語は、適当な物理量に関連付けられるべきであり、かつ、これらの量に適用される単に都合のよいラベルである、ということを留意しなければならない。
特に他に指定のない限り、説明を通して、処理する、検出する、継続する、確定する、識別する、マップする等のような用語は、物理（電子）量として表されるデータを操作および変換するコンピュータシステム、ロジック、プロセッサまたは同様の電子デバイスの動作およびプロセスを指す、ということが理解される。

図１に、表示端末等である少なくとも１つのコンソール１０５を有するコンピューティングデバイス１００のためのシステムの一例を示す。
コンソール１０５をコンピューティングデバイス１００に、通信ポートおよびそれらの間の通信を提供するように構成される送受信機を通して、動作可能に接続することができる。
送受信機は、たとえば、汎用非同期送受信装置（以下、ＵＡＲＴ）、仮想ＵＡＲＴ、またはコンピューティングデバイス１００とコンソール１０５との間の通信を処理することができる他の通信ロジックであってもよい。
本明細書における例では、「ＵＡＲＴ」という用語を、「送受信機」という用語と同じ意味で使用し、ＵＡＲＴという用語は一般に送受信機を指すということが意図されている。
ＵＡＲＴはまた、ＵＳＡＲＴ（汎用同期非同期送受信装置（Universal Synchronous-Asynchronous Receiver/Tranmitter））を含んでもよい。
他のタイプの入出力コントローラおよびロジックも、これら例の範囲内にある。

一例としてのＵＡＲＴは、コンソール１０５のような取り付けられたシリアルデバイスへのコンピュータのインタフェースを制御するようにプログラムされたマイクロチップを有することができる。
ＵＡＲＴは、コンピューティングデバイス１００にＲＳ−２３２Ｃデータ端末機器（ＤＴＥ）インタフェースを提供することができ、それによって、コンピューティングデバイス１００が、シリアルデバイスに「トーク」するとともにシリアルデバイスとデータを交換することができるようにする。
仮想ＵＡＲＴの一例は、通信データのログを記録し、データを物理ポートに転送し、データをミラーリングし、データをネットワーク接続によって送信し、またはこれらのタスクの任意の組合せを行うようにプログラムされたマイクロプロセッサを有することができる。

システムは、コンソール１０５との通信が機能しているか機能していないかを検出し、かつ、コンピューティングデバイス１００が機能していないコンソール１０５でブートすることを可能にするように構成することができる、ブートロジック１１０を有する。
一例では、ブートロジック１１０を、コンピュータコンポーネントとして、ソフトウェアとして等、コンピューティングデバイス１００内のシステムファームウェアとして具現化することができる。
一シナリオ例で、コンソール１０５との通信がＵＡＲＴの故障により喪失したと想定する。
コンピューティングデバイス１００は、機能を停止する（たとえばクラッシュする）可能性があり、また、ブートプロセスを開始することによってリブートしようと試みる可能性がある。
ブートロジック１１０は、ブートプロセス中に、ＵＡＲＴが機能しているのでエラーなしにうまく初期化され得ると、ブートプロセスに対して信じさせるように動作することができる。
ほかにエラーが発生していないと仮定すると、ブートは、ＵＡＲＴが機能していなくてもうまく完了することができる。
そして、オペレーティングシステムをうまくロードすることができるので、機能しているコンソール１０５なしでもコンピューティングデバイス１００が動作することができるようにすることができる。

図２に、コンピューティングシステム２００のブートプロセスを制御するように構成された別の例のブートロジック２０５を有する別の例のコンピューティングシステム２００を示す。
ブートロジック２０５は、たとえば、システムファームウェアであってもよい。
以下の例では、コンピューティングシステム２００を、複数のハードウェアデバイス１、２等と、コンソール２１５との通信を提供するように構成されたＵＡＲＴ２１０と、を有するものとして説明する。
コンピューティングシステム２００はまた、１つまたは複数のドライバ２２０を有してもよく、ドライバは、ハードウェアデバイスを制御するとともにハードウェアデバイスとハードウェアデバイスを使用するプログラムとの間の変換機構として作用するソフトウェアである。
ドライバ２２０のうちの１つまたは複数を、コンピューティングシステム２００内のさまざまな位置に保持してもよく、かつ／または、リモートデバイスに保持してもよい。

コンピューティングシステム２００のシステムブート中、他にも機能があるが、特に、コンピューティングシステム２００に対していずれのハードウェアデバイスが利用可能であるかを判断するシステム初期化を実行してもよい。
システムブートを、たとえばコンピューティングシステム２００の電源をオンにすること、システムエラー（たとえば、ＵＡＲＴまたは他のデバイスの故障）による自動リブート、手動リブート等によってトリガしてもよい。
ブートプロセス中、ブートロジック２０５は、ＵＡＲＴ２１０が機能しているか機能していないかを検出するように構成される。
ＵＡＲＴ２１０が機能していない場合、ブートロジック２０５は、ＵＡＲＴ２１０が機能しているかのようにブートプロセスが継続するのを可能にするように動作可能なＵＡＲＴドライバをロードするように構成される。

ブートロジック２０５は、ＵＡＲＴ２１０が機能しているか否かを検出するように構成される検出ロジック２２５を有することができる。
これを、たとえば、その存在を検知するとともにＵＡＲＴ２１０を初期化しようと試みることによって実行してもよい。
ＵＡＲＴ２１０が応答しない場合、それは機能していないと確定され、それによりコンソール２１５は機能しなくなる。
マップロジック２３０を、検出されたハードウェアデバイスに関連するドライバ２２０から対応するドライバをマップしまたは他の方法でロードするように構成することができる。
たとえば、ＵＡＲＴ２１０が機能している場合、ＵＡＲＴ２１０に対応するＵＡＲＴドライバ２３５をロードすることができる。
機能していないＵＡＲＴ２１０が検出されると、それに応じて、コンピューティングシステム２００がコンソール２１５と通信せずにブートすることができるようにするダミーＵＡＲＴドライバ２４０をマップすることができる。
別の例では、ＵＡＲＴドライバ２３５およびダミーＵＡＲＴドライバ２４０を、機能しているＵＡＲＴとも機能していないＵＡＲＴとも動作するロジックを含む単一ドライバとして構成することができる。
このように、故障したＵＡＲＴ２１０が検出された場合であってもブートプロセスを継続することができ、それにより初期化を完了することができるとともにオペレーティングシステムをロードすることができる。

別の例では、ブートロジック２０５は、故障したＵＡＲＴ２１０が存在することを示すＵＡＲＴ故障信号２４５等のフラグを設定することができる。
そして、オペレーティングシステムが、その初期化中に故障信号２４５にアクセスすることができる。
ＵＡＲＴ故障信号２４５を、オペレーティングシステムに対しコンソール／ＵＡＲＴドライバをロードさせるように構成することができ、このコンソール／ＵＡＲＴドライバは、オペレーティングシステムが、コンソール２１５にデータを送信することなくコンソール２１５に向けられた通信要求を処理することを可能にするように構成される。
一例では、オペレーティングシステムを、ＵＡＲＴ故障信号２４５を読み出すように、また機能しているＵＡＲＴが使用可能でないことを認識するようにプログラム的に変更することができる。
一般に、ＵＡＲＴ故障信号２４５は、オペレーティングシステムがアクセス可能な場所に配置される信号である。
一例では、ＰＡ−ＲＩＳＣシステムにおいて、故障信号２４５を、ページ０にヌルパスを配置することにより実施することができる。
オペレーティングシステムは、ページ０に書かれた上記パスを読み出し、かつ使用可能なＵＡＲＴがないと判断することができる。
そして、オペレーティングシステムは、それに応じて、故障したＵＡＲＴ２１０との通信を処理するように構成されるコンソールドライバをロードすることによって応答することができる。
使用してもよいコンソールドライバの一例について、図３を参照して説明する。

図３に、故障したＵＡＲＴ、またはその他の故障したコンソールを有することに応じてオペレーティングシステムが使用することができるコンソールドライバ３００の一例を示す。
コンソールドライバ３００は、機能しているＵＡＲＴの状況と機能していないＵＡＲＴの状況とをともに処理するように構成される。
たとえば、機能ロジック３０５を、プログラム３１０から受け取られる場合があるとともにコンソールに向けられる通常の通信要求を処理するように構成することができる。
そして、適当なコマンドを、それら要求に対応するＵＡＲＴに送信（たとえば、ＵＡＲＴへのデータ出力）することができる。

しかしながら、機能していないＵＡＲＴの場合、コンソールドライバ３００に対し、故障したＵＡＲＴとの通信を処理することができる非機能ロジック３１５を実行させることができる。
たとえば、コンソールに書き込まれるように（プログラム３１０から）要求されるデータを、非機能ロジック３１５によって受け取り、そのデータをＵＡＲＴに送信せずに破棄することができる。
要求側プログラム３１０は、データが破棄されたこと、または任意のタイプのエラーが発生したことを気付かずにいることができる。
さらに、この状況ではＵＡＲＴが動作可能でないため、コンソールからいかなるデータも受け取られず、したがって、コンソールドライバ３００によりＵＡＲＴからいかなるデータも受け取られない（たとえば、「ＵＡＲＴからのデータ入力」なし）。
したがって、非機能ロジック３１５からプログラム３１０にいかなるデータも戻されない。
データを破棄することには、たとえば、メモリまたはファイルにデータを書き込むこと、データのログを記録すること、データを削除すること等が含まれてもよい。
プログラム３１０がデータをコンソールに書き込む命令を提供したにも関わらず、プログラム３１０からのデータはコンソールに送信されない。

非機能ロジック３１５を、コンピューティングシステムの他のコンポーネントには機能しているコンソールとして見えるという目的を果たす、ダミーＵＡＲＴドライバまたはダミーコンソールドライバとみなすことができる。
また、２つの別々のコンソールドライバを使用することができ、その場合、一方は機能ロジック３０５に対応する機能しているコンソールを処理し、他方は非機能ロジック３１５に対応するダミードライバである、ということも理解されよう。
オペレーティングシステムを、ＵＡＲＴの機能性に基づいて適当なドライバをロードするように構成することができる。

先の例では２つの異なるダミードライバについて述べ、一方のドライバはオペレーティングシステムがロードされる前にロードされ、他方のドライバはオペレーティングシステムによってロードされると述べたが、他の構成を使用することも可能である。
たとえば、２つのドライバは、２つの異なる時にロードされる同じドライバであってもよい。
別の例では、コンピューティングシステムを、１つのハードウェアデバイスに対し１つのドライバを使用するように構成してもよく、その場合ドライバは、ブート中または初期化プロセス中にロードされる。
そのため、１つのドライバのみが使用される。
したがって、本明細書で説明するシステムおよび方法例を、異なるタイプのシステムに対して変更しかつ適応させることができる。

方法例について、フローチャートを参照してより良く理解することができる。
説明を簡単にするために、図示する方法を一連のブロックとして示し説明するが、ブロックによっては、示し説明するものとは異なる順序で、かつ／または他のブロックと同時に発生することができるため、これら方法はブロックの順序によって限定されない、ということを理解すべきである。
さらに、方法例を実施するために図示するブロックのすべてが必要でない場合もある。
ブロックを結合してもよく、または分割して複数のコンポーネントにしてもよい。
さらに、追加のかつ／または代替的な方法は、追加の図示しないブロックを採用してもよい。
図は、連続的に発生するさまざまな動作を示すが、さまざまな動作は、同時に、実質的に並行して、かつ／または実質的に異なる時点で発生してもよい、ということを理解すべきである。

図４に、故障した送受信機（たとえば、ＵＡＲＴ）を有するシステムをブートすることに関連してもよい一例としての方法４００を示す。
図示する要素は、ロジックで実施してもよい「処理ブロック」を示す。
一例では、処理ブロックは、コンピュータ、プロセッサおよび／またはロジックデバイスに対し、応答させ、動作（複数可）を実行させ、状態を変更させ、かつ／または判断を行わせる等の実行可能命令を表してもよい。
このため、説明する方法を、コンピュータ読取可能媒体によって提供されるプロセッサ実行可能命令および／または動作として実施することができる。
別の例では、処理ブロックは、アナログ回路、デジタル信号プロセッサ回路、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス、または他のロジックデバイス等の機能的に等価な回路によって実行される機能および／または動作を表してもよい。
図４の図は、他の図示する図と同様に、説明する例の実施の態様を限定するようには意図されていない。
むしろ、図は、当業者が回路を設計／製作し、ソフトウェアを生成し、または図示する処理を実行するためにハードウェアおよびソフトウェアの組合せを使用するために使用することができる機能情報を示す。
上述したことは、本明細書で説明するすべての方法および例に適用される。

図４を参照すると、例としての方法４００は、システムブートプロセスの一部として説明されている。
システムブートを、たとえばコンピューティングシステムの電源をオンにすること、システムエラーに起因する自動リブート、手動リブート等によってトリガしてもよい。
この例では、コンソールとの通信を制御する送受信機が故障したと仮定する。
送受信機はＵＡＲＴであってもよい。

システムブートが開始された後、ある時点で、送受信機が機能しているか否かが判断され、プロセスは故障した送受信機を検出することができる（ブロック４０５）。
送受信機が故障した場合、システムブートが継続するのを可能にする送受信機ドライバをロードする（ブロック４１０）。
送受信機ドライバは、機能している送受信機が存在しているかのように見えるようにするダミードライバであってもよい。
そして、システムブートは、送受信機、したがってコンソールが動作可能であるかのように継続することができる（ブロック４１５）。
このように、コンソールなしのブートを達成することができる。
そして、ブートプロセスは、オペレーティングシステムのロードを開始することができ、それによりコンピューティングシステムは動作可能となり得る。

方法４００の別の例では、ブロック４０５において故障した送受信機が検出されると、送受信機が故障したことを示す故障送受信機信号を設定することができる。
そして、その故障送受信機信号をオペレーティングシステムが読み出すことにより、故障した送受信機の存在を確定することができる。
一例では、送受信機がＵＡＲＴであり、かつ、オペレーティングシステムが、初期化中に設定することができるＵＡＲＴパスを読み出すことによりＵＡＲＴを識別するものとする。
ＵＡＲＴパスを、オペレーティングシステムが認識するヌルまたは別の値が故障したＵＡＲＴを識別するようにパスを設定することによる等、故障送受信機信号として使用することができる。
オペレーティングシステムは、故障送受信機信号を読み出すことに応じて、コンソールに向けられる故障した送受信機との通信を処理するように構成されるダミー送受信機ドライバをロードすることができる。
上述したことの方法例について、図５を参照して説明する。

図５に、オペレーティングシステムに関連してもよい一例としての方法５００を示す。
オペレーティングシステムを、初期化段階等の間に方法５００を実行するように構成することができる。
方法５００は、故障したコンソールを検出することを含むことができる（ブロック５０５）。
これを、システムブート中に予め設定された故障信号を読み出すことにより実行してもよい。
そして、故障したコンソールに対する通信要求を処理するように構成されるコンソールドライバをロードすることができる（ブロック５１０）。
これには、上述したようなダミーコンソールドライバをロードすること、または図３に示すコンソールドライバ３００等、機能しているコンソールおよび機能していないコンソールに適応することができるコンソールドライバをロードすることが含まれてもよい。
このように、コンピューティングシステムを、機能していないコンソールでも動作可能にすることができる。

図６は、本明細書で説明するシステムおよび方法例ならびに等価物が動作することができるコンピューティングデバイスの一例を示す。
このコンピューティングデバイス例は、バス６０８に動作可能に接続されたプロセッサ６０２、メモリ６０４および入出力ポート６１０を含むコンピュータ６００であってもよい。
一例では、コンピュータ６００は、故障した送受信機（たとえば、ＵＡＲＴ６３５）が存在する場合であってもシステムブートの成功を容易にするように構成されたブートロジック６３０を有してもよい。
ＵＡＲＴ６３５は、コンソール６４０に対する通信を制御する。
それぞれ図１および図２において説明したブートロジック１１０、２０５、および／または、本明細書で説明する他のシステムおよび方法ならびにそれらの等価物に類似するブートロジック６３０を実施することができる。

たとえば、ブートロジック６３０を、ＵＡＲＴ６３５が機能しているかのようにシステムブートがＵＡＲＴ６３５をうまく初期化することができるようにするダミーＵＡＲＴドライバ６４５をロードするように構成することができる。
ダミードライバ６４５とＵＡＲＴ６３５との間の破線は、仮想動作可能通信リンクを表す。
先の例で説明したように、その後、オペレーティングシステム６５０をロードすることができる。
コンソール６４０が（ＵＡＲＴ６３５が故障したため）機能していないと判断されると、コンソール６４０に対する通信要求を処理するダミーコンソールドライバ６５５をロードすることができる。
ダミーコンソールドライバ６５５を、本明細書で説明した先のドライバ例と同様に構成することができる。

コンピュータ６００の構成例をより一般的に説明すると、プロセッサ６０２を、デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャを含む種々のさまざまなプロセッサとすることができる。
メモリ６０４は、揮発性メモリおよび／または不揮発性メモリを含んでもよい。
不揮発性メモリには、限定されないが、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ等が含まれてもよい。
揮発性メモリには、たとえば、ＲＡＭ、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）およびダイレクトＲＡＭバスＲＡＭ（ＤＲＲＡＭ）が含まれてもよい。

ディスク６０６を、たとえば入出力インタフェース（たとえば、カード、デバイス）６１８および入出力ポート６１０を介してコンピュータ６００に動作可能に接続してもよい。
ＵＡＲＴ６３５を、Ｉ／Ｏポートに接続されたＩ／Ｏインタフェースとみなすことができるということが理解されよう。
ディスク６０６には、限定されないが、磁気ディスクドライブ、半導体ディスクドライブ、フロッピーディスクドライブ、テープドライブ、Ｚｉｐドライブ、フラッシュメモリカードおよび／またはメモリスティックのようなデバイスが含まれてもよい。
さらに、ディスク６０６には、ＣＤ−ＲＯＭ、追記型ＣＤドライブ（ＣＤ−Ｒドライブ）、書換可能ＣＤドライブ（ＣＤ−ＲＷドライブ）および／またはデジタルビデオＲＯＭドライブ（ＤＶＤ ＲＯＭ）のような光ドライブが含まれてもよい。
メモリ６０４は、たとえばプロセス６１４および／またはデータ６１６を格納することができる。
ディスク６０６および／またはメモリ６０４は、コンピュータ６００の資源を制御しかつ割り付けるオペレーティングシステムを格納することができる。

バス６０８は、単一の内部バス相互接続アーキテクチャおよび／もしくは他のバスまたはメッシュアーキテクチャであってもよい。
単一バスを示すが、コンピュータ６００は、図示しない他のバス（たとえば、ＰＣＩＥ、ＳＡＴＡ、インフィニバンド、１３９４、ＵＳＢ、イーサネット（登録商標））を使用してさまざまなデバイス、ロジックおよび周辺機器と通信してもよい、ということを理解しなければならない。
バス６０８は、限定されないがメモリバスまたはメモリコントローラ、周辺バスまたは外部バス、クロスバスイッチおよび／もしくはローカルバスを含む種々のタイプのものであってもよい。
ローカルバスは、限定されないが業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＳＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）バス、ユニバーサルシリアル（ＵＳＢ）バスおよび小型コンピュータシステムインタフェース（ＳＣＳＩ）バスを含む種類のものであってもよい。

コンピュータ６００は、Ｉ／Ｏインタフェース６１８および入出力ポート６１０を介して入出力デバイスと対話してもよい。
入出力デバイスには、限定されないが、キーボード、マイクロフォン、ポインティングおよび選択デバイス、カメラ、ビデオカード、ディスプレイ、ディスク６０６、ネットワークデバイス６２０等が含まれてもよい。
入出力ポート６１０には、限定されないがシリアルポート、パラレルポートおよびＵＳＢポートが含まれてもよい。

コンピュータ６００は、ネットワーク環境で動作することができ、したがってコンピュータ６００を、Ｉ／Ｏデバイス６１８および／またはＩ／Ｏポート６１０を介してネットワークデバイス６２０に接続されてもよい。
ネットワークデバイス６２０を通して、コンピュータ６００は、ネットワークと対話してもよい。
ネットワークを通して、コンピュータ６００をリモートコンピュータに論理的に接続してもよい。
コンピュータ６００が対話してもよいネットワークには、限定されないが、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）および他のネットワークが含まれる。
ネットワークデバイス６２０は、限定されないが光ファイバ分散データインタフェース（ＦＤＤＩ）、より対線ＦＤＤＩ（ＣＤＤＩ）、イーサネット（ＩＥＥＥ８０２．３）、トークンリング（ＩＥＥＥ８０２．５）、無線コンピュータ通信（ＩＥＥＥ８０２．１１）、Ｂｌｕｅｔｏｏｔｈ（ＩＥＥＥ８０２．１５．１）等を含むＬＡＮ技術に接続することができる。
同様に、ネットワークデバイス６２０は、限定されないがポイント・ツー・ポイントリンク、サービス統合デジタル網（ＩＳＤＮ）のような回線交換網、パケット交換網およびデジタル加入者線（ＤＳＬ）を含むＷＡＮ技術に接続することができる。

システム例、方法例等を、例を説明することによって示したが、またそれら例を非常に詳細に説明したが、添付の特許請求の範囲をかかる詳細に制限すること、または何らかの形で限定することは本出願人の意図ではない。
当然ながら、本明細書で説明したシステム、方法等を説明する目的で、すべての考えうる構成要素または方法の組合せを説明することは不可能である。
当業者には、さらなる利点および変更が容易に明らかとなろう。
したがって、本発明は、特定の詳細、代表的な装置および示し説明した例示的な例に限定されない。
このため、本出願は、添付の特許請求の範囲に含まれる改変、変更および変形を包含するように意図されている。
さらに、上述した説明は、本発明の範囲を限定するようには意図されていない。
むしろ、本発明の範囲は、添付の特許請求の範囲およびそれらの等価物によって確定されるべきである。

用語「含む（include、including）」という用語は、詳細な説明または特許請求の範囲において採用される限りにおいて、特許請求の範囲において移行語として採用される場合に解釈される「具備する、備える、含む（comprising）」と同様に包括的であるように意図される。
さらに、用語「または（もしくは）」は、詳細な説明または特許請求の範囲において採用される（たとえば、ＡまたはＢ）限りにおいて、「ＡまたはＢもしくは両方」を意味することが意図されている。
出願人が「ＡまたはＢのみであり両方ではない」を示すよう意図する場合、「ＡまたはＢのみであり両方ではない」という用語を採用する。
このため、本明細書における「または」という用語の使用は、包括的であり排他的な使用ではない。
Bryan A. Garner著、「A Dictionay of Modern Legal Usage 624」（2d. Ed. 1995）」を参照されたい。

機能するコンソールなしにコンピューティングデバイスをブートするシステム例を示す図である。 機能する送受信機／コンソールなしにコンピューティングシステムをブートする別のシステム例を示す図である。 機能しないコンソールを処理するコンソールドライバの一例を示す図である。 システムブートプロセスに関連してもよい方法例を示す図である。 ブートプロセス中にオペレーティングシステムに関連してもよい方法例を示す図である。 本明細書で示すシステム例および方法例が動作することができるコンピューティング環境の一例を示す図である。

符号の説明

１００・・・コンピューティングデバイス，
１０５・・・コンソール，
１１０・・・ブートロジック，
２００・・・コンピューティングシステム，
２０５・・・ブートロジック，
２１５・・・コンソール，
２２５・・・検出ロジック，
２３０・・・マップロジック，
２３５・・・ＵＡＲＴドライバ，
２４０・・・ＵＡＲＴダミードライバ，
２４５・・・ＵＡＲＴ故障信号，
３００・・・コンソールドライバ，
３０５・・・機能ロジック，
３１０・・・プログラム，
３１５・・・非機能ロジック，
６００・・・コンピュータ，
６０２・・・プロセッサ，
６０４・・・メモリ，
６０６・・・ディスク，
６０８・・・バス，
６１０・・・Ｉ／Ｏポート，
６１４・・・プロセス，
６１６・・・データ，
６１８・・・Ｉ／Ｏインタフェース，
６２０・・・ネットワークデバイス，
６３０・・・ブートロジック，
６４５・・・ダミーＵＡＲＴドライバ，
６５０・・・オペレーティングシステム，
６５５・・・ダミーコンソールドライバ，

Claims (10)

1. 少なくとも１つのコンソール（１０５）を含むコンピューティングデバイス（１００）のためのシステムであって、
   前記コンソール（１０５）との通信が機能しているか否かを検出し、前記コンピューティングデバイス（１００）が機能してないコンソールでのブートを可能にするように構成されるブートロジック（１１０）
   を具備するシステム。
2. 前記コンピューティングデバイス（１００）と、前記コンソール（１０５）との間の通信を提供するように送受信機（２１０）が構成され、
   前記ブートロジック（１１０）は、
   機能しない送受信機を検出するように構成される検出ロジック（２２５）であって、前記機能しない送受信機は、前記コンソール（１０５）を機能しないようにする、
   前記機能しない送受信機の検出に応じて、前記コンピューティングデバイス（１００）が、前記コンソール（１０５）と通信することなくブートできるようにするダミー送受信機ドライバ（２４０）をマップするように構成されるマップロジック（２３０）と
   を含む
   請求項１に記載のシステム。
3. 前記送受信機（２１０）は、汎用非同期送受信装置（UART; universal asynchronous receiver/transmitter）および仮想ＵＡＲＴのいずれかである
   請求項２に記載のシステム。
4. 前記ブートロジック（１１０）は、前記ダミー送受信機ドライバ（２４０）および機能送受信機ドライバ（２３５）を含む複数のドライバ（２２０）にアクセスするように構成され、
   前記ブートロジック（１１０）は、前記送受信機（２１０）が機能しているとして検出されることに応じて、前記機能送受信機ドライバ（２３５）をマップするように構成される
   請求項２に記載のシステム。
5. 前記ブートロジック（１１０）は、前記機能していない送受信機が検出されることに応じて、前記コンピューティングデバイス（１００）のオペレーティングシステムがアクセス可能な故障信号（２４５）を設定するように構成され、
   前記故障信号（２４５）は、前記オペレーティングシステムに対し、前記オペレーティングシステムが前記コンソール（１０５）にデータを送信することなく前記コンソール（１０５）に向けられた通信要求を処理するのを可能にするように構成される送受信機ドライバをロードさせるように構成される
   請求項２に記載のシステム。
6. コンピューティングデバイスのシステムブート中の方法であって、
   故障した送受信機を検出すること（４０５）であって、前記送受信機は、前記コンピューティングデバイスとコンソールとの間の通信を提供するように構成されること（４０５）と、
   前記故障した送受信機が検出された場合の前記システムブートの継続を可能にする送受信機ドライバをロードすること（４１０）と、
   前記送受信機が機能しているかのように前記システムブートを継続すること（４１５）と
   を含む方法。
7. 前記送受信機が故障したことを示す故障送受信機信号を設定することと、
   オペレーティングシステムにより前記故障送受信機信号を読み出すことと、
   前記故障送受信機信号を読み出すことに応じて、前記オペレーティングシステムにより、前記コンソールに向けられる前記故障した送受信機との通信を処理するように構成されるダミー送受信機ドライバをロードすることと
   をさらに含む請求項６に記載の方法。
8. 前記ロードすることは、
   前記送受信機ドライバとして作用するダミー送受信機ドライバをロードすること
   を含む
   請求項６に記載の方法。
9. 前記故障した送受信機に応じて、前記コンソールに向けられるデータを破棄すること
   をさらに含む請求項６に記載の方法。
10. コンピューティングシステム（６００）であって、
    前記コンピューティングシステム（６００）に動作可能に接続され、少なくとも情報を表示するように構成されるコンソール（６４０）と、
    前記コンピューティングシステム（６００）に動作可能に接続され、前記コンピューティングシステム（６００）と、前記コンソール（６４０）との間の通信を提供するように構成される送受信機（６３５）と、
    前記コンピューティングシステム（６００）のブートプロセスを制御するように構成され、前記送受信機（６３５）が機能しているか否かを検出するように構成されるシステムファームウェア（６３０）と
    を具備し、
    前記ブートプロセス中に前記送受信機（６３５）が機能していないと検出されることに応じて、前記システムファームウェア（６３０）は、前記送受信機（６３５）が機能しているかのように前記ブートプロセスが継続できるように動作可能な送受信機ドライバ（６４５）をロードするように構成される
    コンピューティングシステム。

Images