JP2011060225A - オペレーティングシステム起動方法 - Google Patents

Abstract

【課題】コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くする。
【解決手段】スモールＯＳ４２を起動し、起動完了したスモールＯＳ４２上でターゲットアプリケーション４３が起動する。スモールＯＳ４２上でターゲットアプリケーション４３が起動完了した後、リッチＯＳ４１を起動し、起動完了したリッチＯＳ４１上でターゲットアプリケーション４３が起動する。リッチＯＳ４１上でターゲットアプリケーション４３が起動完了した後、スモールＯＳ４２上で動作しているターゲットアプリケーション４３の実行状態をリッチＯＳ４２上で起動されたターゲットアプリケーション４３に引き継ぎ、スモールＯＳ４２を使用停止する。
【選択図】図３

Description

本発明は、オペレーティングシステム起動方法に関する。

従来、モバイル端末などのコンピュータに関し、起動してからアプリケーションが使用可能となるまでの時間をできるだけ短くしたいという要望がある。

例えば特許文献１によれば、ハードウェアを起動させた初期段階では、スモールＯＳ（または汎用ＯＳのいずれか）を起動し、汎用ＯＳが起動した後、自由使用メモリ領域にスモールＯＳを格納することにより、使用するＯＳ（実行ＯＳ）を切り替える。この技術を用い、最初にスモールＯＳを起動させることにより、起動してからユーザがスモールＯＳ上で動作するアプリケーションを使用することができるようになるまでの時間を短縮することができる。しかしながら、この技術によれば、スモールＯＳからフルスペックの汎用ＯＳ（リッチＯＳ）に切り替える際には、ＣＰＵのサスペンド、レジュームの操作が必要となる。サスペンド、レジュームの際、ユーザは使用を中断する必要があるため、起動時間の高速化の引き換えとしてユーザにとっての利便性を犠牲にする結果となる。

特開２００３−１９６０９６号公報 特開２００８−１０７９６６号公報

本発明は、コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くするオペレーティングシステム起動方法を提供することを目的とする。

本願発明の一態様によれば、ＣＰＵを備える目的アプリケーションを実行するためのコンピュータにおいてオペレーティングシステム（ＯＳ）を起動するオペレーティングシステム起動方法であって、前記ＣＰＵが、前記目的アプリケーションを実行する機能を備える第１ＯＳを起動し、前記起動した第１ＯＳ上で前記目的アプリケーションを起動する第１起動ステップと、前記ＣＰＵが、実行ＯＳを切り替えるためのＣＰＵディスパッチャを起動するＣＰＵディスパッチャ起動ステップと、前記ＣＰＵが、前記ＣＰＵディスパッチャを使用することによって、前記第１ＯＳ上に起動した前記目的アプリケーションを動作させつつ、前記第１ＯＳのバックグラウンドで、前記目的アプリケーションを含む前記第１ＯＳよりも多くのアプリケーションを実行する機能を備える第２ＯＳを起動するとともに前記第１ＯＳ上で動作している前記所定のアプリケーションとは別に前記所定のアプリケーションを前記起動した第２ＯＳ上で起動する第２起動ステップと、前記ＣＰＵが、前記第１ＯＳ上で動作している前記所定のアプリケーションの実行状態を前記第２ＯＳ上に起動された前記所定のアプリケーションに受け渡す引き継ぎステップと、前記ＣＰＵが、実行ＯＳを前記第２ＯＳとするとともに前記ＣＰＵディスパッチャを停止するＯＳ移行ステップと、を備えることを特徴とするオペレーティングシステム起動方法が提供される。

本発明によれば、コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くするオペレーティングシステム起動方法を提供することができるという効果を奏する。

図１は、本発明の実施の形態のコンピュータの構成を示す図。 図２は、表示画面を説明する図である。 図３は、本発明の実施の形態のオペレーティングシステム起動方法を説明するフローチャート。 図４は、コンピュータ１の状態を説明する図である。 図５は、例外が発生したときの動作を説明するフローチャートである。 図６は、引き継ぎ処理を説明するタイミングチャートである。

以下に添付図面を参照して、本発明の実施の形態にかかるオペレーティングシステム起動方法を詳細に説明する。なお、この実施の形態により本発明が限定されるものではない。

（実施の形態）
図１は、本発明の実施の形態にかかるオペレーティングシステム起動方法を実行するコンピュータのハードウェア構成の一例を示すブロック図である。

図示するように、本発明の実施の形態のコンピュータ１は、ＣＰＵ（Central Processing Unit）２、メインメモリ３、不揮発性メモリ４、入力部５、および表示部６を備えている。ＣＰＵ２、メインメモリ３、不揮発性メモリ４、入力部５、および表示部６は夫々バスで接続されている。

不揮発性メモリ４は、ＲＯＭ（Read Only Memory）やフラッシュメモリなどで構成され、リッチオペレーティングシステム（ＯＳ）プログラム４１、スモールＯＳプログラム４２、ターゲットアプリケーションプログラム４３、およびＣＰＵディスパッチャプログラム４４を記憶している。

リッチＯＳプログラム４１とは、コンピュータ１に多種多様な機能を実現させるためのアプリケーション群を実行させることができるＯＳのプログラムである。言い換えると、リッチＯＳプログラム４１とは、フルスペックのＯＳである。

ターゲットアプリケーションプログラム４３は、前記したリッチＯＳプログラム４１で動作するアプリケーション群のうちの、コンピュータ１の起動開始から短い時間で使用可能となることが望まれるアプリケーション（以下、ターゲットアプリケーション）のプログラムである。ターゲットアプリケーションはどのようなアプリケーションであってもよい。例えばインターネットを閲覧する機能を重視し、該機能をいち早く使用可能な状態にしたい場合、インターネットの閲覧を行うためのアプリケーションをターゲットアプリケーションとするとよい。他には、テキストファイルを編集するためのアプリケーション、プレゼンテーション資料を編集するためのアプリケーション、電子メールを閲覧・送受信するためのアプリケーションなど、重視する機能に応じて所望のアプリケーションをターゲットアプリケーションとするとよい。なお、ターゲットアプリケーションは複数存在しても構わない。

スモールＯＳプログラム４２は、少なくともターゲットアプリケーションプログラム４３を実行するために必要な機能を備えたＯＳのプログラムであって、リッチＯＳプログラム４１に比べて小さい規模のプログラムである。スモールＯＳプログラム４２はリッチＯＳプログラム４１に比べてプログラムの規模が小さいので、リッチＯＳプログラム４１よりも高速に起動することができる。本実施の形態では、まずスモールＯＳプログラム４２が起動され、起動されたスモールＯＳプログラム４２上でターゲットアプリケーションプログラム４３が起動されることによって、コンピュータ１の起動開始からターゲットアプリケーションプログラム４３が使用可能となるまでの時間を短縮する。なお、コンピュータ１の起動開始からターゲットアプリケーションプログラム４３が使用可能となるまでの時間の短縮幅を大きくするには、スモールＯＳプログラム４２が実行可能なアプリケーションをターゲットアプリケーションのみとし、スモールＯＳプログラム４２の機能を必要最小限にすることが望ましい。

ＣＰＵディスパッチャプログラム４４は、ＣＰＵで実行するＯＳを複数のＯＳ間で切り替えるためのプログラムである。ＯＳの切り替えとは、具体的には、レジスタの退避・復元、切り替え対象の二つのＯＳが使用するアドレス空間の切り替えを含む。本実施の形態では、ＣＰＵディスパッチャプログラム４４は、スモールＯＳプログラム４２の起動の後に起動される。リッチＯＳプログラム４１は、ＣＰＵディスパッチャプログラム４４を使用することによって、スモールＯＳプログラム４２のバックグラウンドで起動される。すなわち、起動されたＣＰＵディスパッチャプログラム４４は、ターゲットアプリケーションプログラム４３を動作させるスモールＯＳプログラム４２と、起動開始してからのリッチＯＳプログラム４１と、の間でＣＰＵ２の割り当てを切り替える。ＣＰＵディスパッチャプログラム４４は、リッチＯＳプログラム４１よりもスモールＯＳプログラム４２に優先してＣＰＵ２が割り当てられる。

なお、後ほど詳述するが、リッチＯＳプログラム４１の起動完了後、リッチＯＳプログラム４１上でターゲットアプリケーションプログラム４３が起動される。リッチＯＳプログラム４１上でのターゲットアプリケーションプログラム４３の起動完了後、スモールＯＳプログラム４２およびＣＰＵディスパッチャプログラム４４は停止され、ユーザはターゲットアプリケーションのみならずリッチＯＳプログラム４１上で動作する全てのアプリケーションを使用することができるようになる。

メインメモリ３は、ＲＡＭ（Random Access Memory）などで構成される、不揮発性メモリ４に比べて高速アクセス可能なメモリであって、ＣＰＵ２が不揮発性メモリ４に格納されているプログラム４１〜４４を実行するためのワークエリアとして使用される。具体的には、ＣＰＵ２により、プログラム４１〜４４のプログラムイメージ（以下、メモリイメージともいう）がロードされる。

ユーザがターゲットアプリケーションを操作することによってターゲットアプリケーションの実行状態が刻々と変化する。ＯＳが切り替わったことを意識させることなくスモールＯＳプログラム４２上で実行していたターゲットアプリケーションからリッチＯＳプログラム４１上に起動されたターゲットアプリケーションに制御を移すために、スモールＯＳプログラム４２上で動作していたターゲットアプリケーションは自身の実行状態を再現するために必要となる種々のデータ（以下、引き継ぎデータという）を作成する。作成された引き継ぎデータは、メインメモリ３に置かれ、リッチＯＳプログラム４１上で起動されたターゲットアプリケーションに受け渡たされる。

入力部５はマウスやキーボードを備えて構成され、ユーザからのターゲットアプリケーションを含むアプリケーションに関する操作が入力される。入力部５へ入力された操作情報はＣＰＵ２へ送られる。

表示部６は、液晶モニタなどの表示装置であり、ＣＰＵ２からの指示に基づいて、アプリケーションの操作画面などのユーザに対する出力情報を表示する。本実施の形態では、表示部６の表示画面には、スモールＯＳプログラム４２が終了されるまでは図２（ａ）に示すようにターゲットアプリケーションの操作画面が表示され、リッチＯＳプログラム４１およびリッチＯＳプログラム４１上のターゲットアプリケーションの起動が完了し、スモールＯＳプログラム４２が終了されると、図２（ｂ）に示すようにターゲットアプリケーションのみならずその他のアプリケーションの操作画面が表示される。

次に、コンピュータ１において実行される本実施の形態のオペレーティングシステム起動方法を図３〜図６を参照して説明する。図３は、本実施の形態のオペレーティングシステム起動方法を説明するフローチャートである。なお、以降、リッチＯＳプログラム４１を単にリッチＯＳ４１と表現することもある。同様に、スモールＯＳプログラム４２、ターゲットアプリケーションプログラム４３、ＣＰＵディスパッチャプログラム４４を夫々スモールＯＳ４２、ターゲットアプリケーション４３、ＣＰＵディスパッチャ４４と表現することもある。

図３に示すように、コンピュータ１の起動が開始されると、まず、ＣＰＵ２は、不揮発性メモリ４からスモールＯＳ４２を読み出して、前記読み出したスモールＯＳ４２をメインメモリ３にロードし、スモールＯＳ４２を起動する（ステップＳ１）。なお、スモールＯＳ４２の起動には、該起動をさらに高速に実行するために、スナップショットブートを利用するようにしてもよい。スナップショットブートとは、ＯＳ起動直後のメモリイメージを不揮発性メモリ４等に記録しておき、起動時に直接メインメモリ３上へ展開することで高速起動を実現するものである（例えば特許文献２）。なお、メモリイメージのサイズはＯＳプログラムの規模が大きくなるに伴って増加し、該メモリイメージの増加によって起動時間が長くなる傾向がある。スモールＯＳ４２は、前述したように、アプリケーションに関してはターゲットアプリケーション４３を実行するための機能のみを備えていればよい比較的規模の小さいプログラムであるので、スナップショットブートを用いることでスモールＯＳ４２の起動の高速化が期待できる。

続いて、ＣＰＵ２は、スモールＯＳ４２の起動が完了すると、起動されたスモールＯＳ４２上にターゲットアプリケーション４３を起動する（ステップＳ２）。ターゲットアプリケーション４３の起動が完了すると、図２（ａ）に示したように、ＣＰＵ２は、表示部６の表示画面にターゲットアプリケーション４３の操作画面を表示させる。このように、フルスペックのリッチＯＳ４１の代わりにスモールＯＳ４２を起動し、スモールＯＳ４２上でターゲットアプリケーション４３を起動するようにしたので、ユーザは、リッチＯＳ４１を起動してリッチＯＳ４１上でターゲットアプリケーション４３を起動する場合に比べて短い時間でターゲットアプリケーション４３を使用できるようになる。

図４は、本実施の形態のオペレーティングシステム起動方法により変化するコンピュータ１の状態を説明する概念図である。図４（ａ）は、ステップＳ２によりターゲットアプリケーション４３が起動されたコンピュータ１の状態を説明する図である。図示するように、ハードウェア１１の上にスモールＯＳ４２が動作しており、スモールＯＳ４２の上でターゲットアプリケーション４３が動作している。なお、ハードウェア１１は、ＢＩＯＳを含む（図中ではＢＩＯＳ・ハードウェアと記載）。表示画面はターゲットアプリケーション４３の操作画面を表示している。なお、スモールＯＳ４２では、例外や割り込み（以下、両者をまとめて例外と表記する）の種類毎に対応するプログラムのメモリ空間上のアドレスである例外ベクタアドレス（以下、単に例外ベクタ）が定義されている。スモールＯＳ４２は、メモリ空間のカーネル領域に、例外の種類毎に例外ベクタを示す例外ベクタテーブル４２１を有している。なお、この時点においては、例外ベクタテーブル４２１の例外ベクタは、スモールＯＳ４２に含まれるプログラムの格納場所を指している。例外とは、例えばユーザによるターゲットアプリケーションを操作する入力部５からの入力であったりする。

図３に戻り、スモールＯＳ４２上でのターゲットアプリケーション４３の起動を完了した後、ＣＰＵ２は、ＣＰＵディスパッチャ４４を不揮発性メモリ４から読み出して、読み出したＣＰＵディスパッチャ４４をメインメモリ３にロードし、ＣＰＵディスパッチャ４４を起動する（ステップＳ３）。

図４（ｂ）は、ＣＰＵディスパッチャ４４が起動された直後の状態を示している。図示するように、ＣＰＵディスパッチャ４４（図中では単にディスパッチャ４４と表記している）は、ハードウェア１１とスモールＯＳ４２との間に介在して存在している。なお、この時点で例外が発生すると、ＣＰＵ２は、スモールＯＳ４２が備える例外ベクタテーブル４２１に基づき、スモールＯＳ４２に例外を通知する。

ステップＳ３の後、ＣＰＵ２は、リッチＯＳ４１を不揮発性メモリ４から読み出して、読み出したリッチＯＳ４１をメインメモリ３にロードする（ステップＳ４）。

そして、ＣＰＵ２は、スモールＯＳ４２のバックグラウンドでリッチＯＳ４１を起動するために、例外ベクタテーブル４２１を書き換えて、例外ベクタにＣＰＵディスパッチャ４４のエントリポイントを設定し（ステップＳ５）、ＣＰＵディスパッチャ４４を使用して、スモールＯＳ４２のバックグラウンドでリッチＯＳ４１の起動を開始する（ステップＳ６）。なお、リッチＯＳ４１の起動にもスナップショットブートを適用してもよい。

ここで、スモールＯＳ４２のバックグラウンドでリッチＯＳ４１の起動などリッチＯＳ４１に関する処理を実行するとは、具体的には、スモールＯＳ４２がidleの間にリッチＯＳ４１に関する処理を実行することを言う。すなわち、スモールＯＳ４２上のターゲットアプリケーション４３に関するユーザからの操作や該ターゲットアプリケーション４３が処理を非実行中であるとき、ＣＰＵディスパッチャ４４はスモールＯＳ４２から自身を起動中またはターゲットアプリケーション４３を起動中のリッチＯＳ４１に制御を移し、ユーザからのターゲットアプリケーション４３に関する入力などスモールＯＳ４２に関する例外が発生したとき、リッチＯＳ４１からスモールＯＳ４２に制御を移す。

図５は、例外発生時のＣＰＵディスパッチャ４４の動作を説明するフローチャートである。図示するように、例外が発生すると、ＣＰＵ２は例外ベクタテーブル４２１を参照してＣＰＵディスパッチャ４４に制御を移し、発生した例外がスモールＯＳ４２に対するものであるか否かを判定する（ステップＳ１１）。発生した例外がスモールＯＳ４２に対するものであった場合（ステップＳ１１、Ｙｅｓ）、ＣＰＵ２は、スモールＯＳ４２が動作中であるか否かをさらに判定する（ステップＳ１２）。リッチＯＳ４１が動作中であった場合（ステップＳ１２、Ｎｏ）、ＣＰＵディスパッチャ４４は、リッチＯＳ４１からスモールＯＳ４２にＣＰＵ２の割り当てを変更、すなわちＯＳを切り替え（ステップＳ１３）、スモールＯＳ４２に前記発生した例外を通知する（ステップＳ１４）。例外の通知が終了すると、ＣＰＵ２はＣＰＵディスパッチャ４４からスモールＯＳ４２に制御を移し、ＣＰＵディスパッチャ４４の動作はリターンとなる。ステップＳ１２の判定処理において、スモールＯＳ４２が動作中であると判定された場合（ステップＳ１２、Ｙｅｓ）、ステップＳ１４に移行する。

一方、ステップＳ１１の判定処理において、発生した例外がリッチＯＳ４１に対するものであると判定された場合（ステップＳ１１、Ｎｏ）、ＣＰＵ２は、スモールＯＳ４２が動作中であるか否かをさらに判定する（ステップＳ１５）。スモールＯＳ４２が動作中であった場合（ステップＳ１５、Ｙｅｓ）、ＣＰＵディスパッチャ４４は、スモールＯＳ４２がidleになるまでリッチＯＳ４１への例外通知を遅延させるために、ＣＰＵディスパッチャ４４内でリッチＯＳ４１の例外状態を記録する（ステップＳ１６）。そして、ＣＰＵ２は、ＣＰＵディスパッチャ４４からスモールＯＳ４２へ制御を移し（スモールＯＳ４２へ復帰し）（ステップＳ１７）、ＣＰＵディスパッチャ４４の動作がリターンとなる。ステップＳ１６にて記録されたリッチＯＳ４１の例外状態は、その後スモールＯＳ４２がidleとなり、リッチＯＳ４１へ制御が移る際に参照され、例外状態が記録されていればＣＰＵディスパッチャ４４からリッチＯＳ４１へ例外が通知される。

ステップＳ１５の判定処理においてリッチＯＳ４１が動作中であると判定された場合（ステップＳ１５、Ｎｏ）、ＣＰＵディスパッチャ４４はリッチＯＳ４１へ例外を通知し（ステップＳ１８）、ＣＰＵディスパッチャ４４の動作がリターンとなる。

このように、スモールＯＳ４２がidle状態のとき、ＣＰＵディスパッチャ４４はリッチＯＳ４１へＣＰＵ２を割り当て、ＣＰＵ２がリッチＯＳ４１に関する処理（リッチＯＳ４１の起動、後述するリッチＯＳ４１上でのターゲットアプリケーション４３の起動）を実行中に例外が発生したとき、例外ベクタテーブル４２１の記述に基づいてＣＰＵディスパッチャ４４に制御を移し、ＣＰＵディスパッチャ４４は、ＣＰＵディスパッチャ４４に基づいて、スモールＯＳ４２へＣＰＵ２を割り当てる。すなわち、ＣＰＵディスパッチャ４４はリッチＯＳ４１よりもスモールＯＳ４２に優先してＣＰＵ２を割り当てる。

なお、本実施の形態では、スモールＯＳ４２およびリッチＯＳ４１はともにデバイスを直接制御することができるようにしておくとよい。この場合、ＯＳ４１、４２間で共有するデバイス（例：入力部５、表示部６など）は、各ＯＳ４１、４２のデバイスドライバが協調して操作する必要がある。例えば、新たに起動されたリッチＯＳ４１のデバイスドライバがデバイス検出を行う際に、すでに初期化済みであるなら初期化を行わず、スモールＯＳ４２のデバイスドライバへ要求を発行することで間接的にデバイスを操作する。また、後述するステップＳ９においてスモールＯＳ４２を使用しないように変更する場合も、共有デバイスを持つドライバには通知を行うことでそれ以後はリッチＯＳ４１のみがデバイスを直接操作するように処理を変更できることとするとよい。

図３に戻り、ＣＰＵ２は、リッチＯＳ４１の起動終了後、リッチＯＳ４１上でターゲットアプリケーション４３を起動する（ステップＳ７）。この処理もスモールＯＳ４２のバックグラウンドで実行されるので、ユーザにはスモールＯＳ４２上のターゲットアプリケーション４３しか見えない。なお、ステップＳ７では、ターゲットアプリケーション４３だけでなくリッチＯＳ４１上で動作するターゲットアプリケーション４３以外のアプリケーションをも起動するようにしてもよい。

図４（ｃ）は、ステップＳ７の処理を実行中のコンピュータ１の状態を説明する図である。図示するように、ＣＰＵディスパッチャ４４の上にスモールＯＳ４２とともにリッチＯＳ４１が存在し、リッチＯＳ４１の上にターゲットアプリケーション４３のみならずその他のアプリケーションも動作している。表示画面には、ターゲットアプリケーション４３の操作画面のみが表示される。

ターゲットアプリケーション４３の起動終了後、ＣＰＵ２は、メインメモリ３上で、スモールＯＳ４２上のターゲットアプリケーション４３の引き継ぎデータをリッチＯＳ４１上のターゲットアプリケーション４３に受け渡す（ステップＳ８）。言い換えると、スモールＯＳ４２上のターゲットアプリケーション４３の実行状態をリッチＯＳ４１上のターゲットアプリケーション４３に受け渡す。この引き継ぎは、ターゲットアプリケーション４３が動作するＯＳが変化したことをユーザに認識させないように、安全にセッションを引き継げる状態となった時点で行われる。

ターゲットアプリケーションの実行状態の引き継ぎが完了した後、ＣＰＵ２は、リッチＯＳ４１を実行ＯＳとし、リッチＯＳ４１に例外が通知されるように例外ベクタテーブル４２１を書き換える（ステップＳ９）。これにより、スモールＯＳ４２およびＣＰＵディスパッチャ４４の動作が停止し、コンピュータ１ではＯＳとしてリッチＯＳ４１のみが動作し、ユーザはリッチＯＳ４１上で動作しているターゲットアプリケーション４３を操作できる状態となる。また、ユーザは、ターゲットアプリケーション４３以外のアプリケーションを操作することができるようになる。すなわち、コンピュータ１のＯＳの起動が完了する。

なお、例外ベクタテーブル４２１の書き換えは、システムコール等の例外によって、スモールＯＳ４２またはリッチＯＳ４１がＣＰＵディスパッチャ４４に書き換えを要求し、ＣＰＵディスパッチャ４４が例外ベクタテーブル４２１を書き換えるようにするとよい。スモールＯＳ４２が使用していたメインメモリ３の領域については、ＣＰＵ２は、リッチＯＳ４１が使用可能なメモリ領域に追加するようにしてもよい。

図４（ｄ）は、本実施の形態のオペレーティングシステム起動方法が完了した後のコンピュータ１の状態を説明する図である。図示するように、ハードウェア１１の上にリッチＯＳ４１が動作し、リッチＯＳ４１の上でターゲットアプリケーション４３およびその他のアプリケーションが動作している。表示画面には、ターゲットアプリケーション４３および他のアプリケーションの操作画面が表示される。

図６は、ターゲットアプリケーション４３の実行状態の引き継ぎを詳しく説明するタイミングチャートである。図示するように、最初に、ステップＳ２によりスモールＯＳ４２上のターゲットアプリケーション４３が起動を完了し（ステップＳ２１）、ユーザに対するサービスが開始される（ステップＳ２２）。その後しばらくしてからステップＳ７によるリッチＯＳ４１上のターゲットアプリケーション４３が起動を完了する（ステップＳ２３）。リッチＯＳ４１上のターゲットアプリケーション４３は、メインメモリ３を用いたＯＳ間通信などによって、スモールＯＳ４２上のターゲットアプリケーション４３へ引き継ぎ要求メッセージを送信し（ステップＳ２４）、スモールＯＳ４２上のターゲットアプリケーション４３からの引き継ぎ準備完了メッセージを待つ。

スモールＯＳ４２上のターゲットアプリケーション４３はこのメッセージを受信すると（ステップＳ２５）、引き継ぎ可能な状態になるまでユーザへのサービスを継続する。引き継ぎ可能な状態としては、ユーザからのサービス要求に応答するまでにある程度の待ち時間が発生するような状態（I／Ｏ処理待ちなど）がある。スモールＯＳ４２上のターゲットアプリケーション４３は、この状態を検出すると（ステップＳ２６）、本来のサービス要求に対する処理に加えて、リッチＯＳ４１上のターゲットアプリケーション４３が引き継ぎデータの準備を行う（ステップＳ２７）。スモールＯＳ４２上のターゲットアプリケーション４３は、引き継ぎデータをメインメモリ３に置き、リッチＯＳ４１上のターゲットアプリケーション４３から参照できるようにする。引き継ぎデータの準備が完了すると、スモールＯＳ４２上のターゲットアプリケーション４３は、リッチＯＳ４１上のターゲットアプリケーション４３へ引き継ぎ準備完了メッセージを送信し（ステップＳ２８）、自分自身はターゲットアプリケーション４３としての動作を終了する（ステップＳ２９）。

リッチＯＳ４１上のターゲットアプリケーション４３は引き継ぎ準備完了メッセージを受信すると（ステップＳ３０）、メインメモリ３上の引き継ぎデータを使って、自分自身の状態をスモールＯＳ４２上のターゲットアプリケーション４３と同じ実行状態にし（ステップＳ３１）、ステップＳ９により例外ベクタテーブル４２１が書き換えられた後、ユーザに対してサービスを開始する（ステップＳ３２）。この結果、ユーザには当初のサービス要求に対する応答が返るが、ターゲットアプリケーション４３の引き継ぎ処理をユーザが認識することはない。

なお、ＣＰＵ２は、どのプログラムあるいはハードウェアの制御に基づいて前述した順序およびタイミングでスモールＯＳ４２、スモールＯＳ４２上のターゲットアプリケーション４３、ＣＰＵディスパッチャ４４、リッチＯＳ４１、リッチＯＳ４１上のターゲットアプリケーション４３を起動させるようにしてもよい。例えば、ステップＳ１はブートローダプログラム（図示せず）の制御によりＣＰＵ２が実行し、ステップＳ２〜ステップＳ７はスモールＯＳ４２の制御によりＣＰＵ２が実行し、ステップＳ８はスモールＯＳ４２上のターゲットアプリケーション４３およびリッチＯＳ４１上のターゲットアプリケーション４３の制御によりＣＰＵ２が実行し、ステップＳ９はＣＰＵディスパッチャ４４の制御によりＣＰＵ２が実行するようにしてもよい。

なお、ＣＰＵディスパッチャ４４の起動、例外ベクタテーブル４２１の書き換え、ＣＰＵディスパッチャ４４を利用したリッチＯＳ４１の起動は、ＣＰＵ特権モードで実行する必要がある。例えば、スモールＯＳ４２がLinux（登録商標）である場合、ＣＰＵディスパッチャ４４のイメージ、例外ベクタテーブル４２１の書き換えプログラム、リッチＯＳ４１のイメージをローダブルモジュール化しておき、夫々のモジュールのインストール時に、ＣＰＵディスパッチャ４４の起動、例外ベクタテーブル４２１の書き換え、リッチＯＳ４１のロードに必要なアドレス空間の用意および該アドレス空間へのリッチＯＳ４１のロードを実行するようにするとよい。

また、スモールＯＳを立ち上げて、追加モジュールを逐次起動することによって多数のアプリケーション群を実行できるようにする技術が知られている。しかしながら、この技術によれば、追加モジュールのインストール時にはＣＰＵ特権モードとなる必要があるため、ターゲットアプリケーションの動作に影響が出る。これに対して本実施の形態では、ＣＰＵディスパッチャ４４の起動、リッチＯＳ４１の起動、および例外ベクタの書き換えのときのみＣＰＵ特権モードとなるだけでよいので、前記した追加モジュールを逐次起動する方法に比べて安定した動作が可能となる。

また、あるＯＳを実行し、このＯＳのバックグラウンドでその他のＯＳを起動する技術は、ＣＰＵ仮想化技術として一般的に知られている。しかしながら、このままでは常に仮想化が有効となっているので、仮想化オーバヘッドによってシステムの性能が低下する。これに対して、本実施の形態は、スモールＯＳ４２を起動後、動的にＣＰＵ仮想化を有効にしてリッチＯＳ４１を起動し、リッチＯＳ４１上の全ての機能が使用可能となったとき、動的にＣＰＵ仮想化を無効化しているといえる。従って、本実施の形態では、ユーザが全ての機能を使用できるようになった後、実行ＯＳとしてリッチＯＳ４１のみが動いている状態となるので、仮想化オーバヘッドによる性能低下を防ぐことができるようになる。

また、本実施の形態では、各プログラム４１〜４４をバスに接続された不揮発性メモリ４内に格納しておくようにしたが、プログラム４１〜４４のうちのいくつかまたは全てを外部記憶装置（図示せず）やコンピュータ１からネットワーク（図示せず）を介してアクセス可能な記憶装置に格納しておくようにしてもよい。

また、スモールＯＳ４２を１個だけ起動し、該スモールＯＳ４２からリッチＯＳ４１を起動するとして説明したが、スモールＯＳ４２の数は複数であっても構わない。

また、スモールＯＳ４２からリッチＯＳ４１を起動するとして説明したが、スモールＯＳ４２からリッチＯＳ４１とは異なる別のＯＳを起動し、該起動したＯＳからリッチＯＳ４１を起動するようにしてもよい。

以上説明したように、本発明の実施の形態によれば、スモールＯＳ４２を起動し、起動したスモールＯＳ４２上でターゲットアプリケーション４３を起動し、ターゲットアプリケーション４３を起動完了した後、ＣＰＵディスパッチャ４４を起動し、ＣＰＵディスパッチャ４４を起動した後、該ＣＰＵディスパッチャ４４を使用することによって、スモールＯＳ４２上に起動したターゲットアプリケーション４３を動作させつつ、スモールＯＳ４２のバックグラウンドで、リッチＯＳ４１を起動するとともにリッチＯＳ４１上で動作しているターゲットアプリケーション４３とは別にターゲットアプリケーション４３を前記起動したリッチＯＳ４１上で起動し、リッチＯＳ４１上のターゲットアプリケーション４３の起動を完了した後、スモールＯＳ４１上で動作しているターゲットアプリケーション４３の実行状態をリッチＯＳ４１上に起動されたターゲットアプリケーション４３に受け渡し、実行ＯＳをリッチＯＳ４１としてＣＰＵディスパッチャ４４を停止させる、ように構成したので、コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くすることができる。

１ コンピュータ、２ ＣＰＵ、３ メインメモリ、４ 不揮発性メモリ、５ 入力部、６ 表示部、１１ ハードウェア、４１ リッチＯＳプログラム、４２ スモールＯＳプログラム、４３ ターゲットアプリケーションプログラム、４４ ＣＰＵディスパッチャプログラム、４２１ 例外ベクタテーブル。

Claims (4)

1. ＣＰＵを備える目的アプリケーションを実行するためのコンピュータにおいてオペレーティングシステム（ＯＳ）を起動するオペレーティングシステム起動方法であって、
   前記ＣＰＵが、前記目的アプリケーションを実行する機能を備える第１ＯＳを起動し、前記起動した第１ＯＳ上で前記目的アプリケーションを起動する第１起動ステップと、
   前記ＣＰＵが、実行ＯＳを切り替えるためのＣＰＵディスパッチャを起動するＣＰＵディスパッチャ起動ステップと、
   前記ＣＰＵが、前記ＣＰＵディスパッチャを使用することによって、前記第１ＯＳ上に起動した前記目的アプリケーションを動作させつつ、前記第１ＯＳのバックグラウンドで、前記目的アプリケーションを含む前記第１ＯＳよりも多くのアプリケーションを実行する機能を備える第２ＯＳを起動するとともに前記第１ＯＳ上で動作している前記所定のアプリケーションとは別に前記所定のアプリケーションを前記起動した第２ＯＳ上で起動する第２起動ステップと、
   前記ＣＰＵが、前記第１ＯＳ上で動作している前記所定のアプリケーションの実行状態を前記第２ＯＳ上に起動された前記所定のアプリケーションに受け渡す引き継ぎステップと、
   前記ＣＰＵが、実行ＯＳを前記第２ＯＳとするとともに前記ＣＰＵディスパッチャを停止するＯＳ移行ステップと、
   を備えることを特徴とするオペレーティングシステム起動方法。
2. 前記第２起動ステップは、
   実行ＯＳが前記第１ＯＳである場合において前記第１ＯＳがアイドル状態となったとき、前記ＣＰＵディスパッチャに基づいて前記ＣＰＵが実行ＯＳを前記第１ＯＳから前記起動中または起動後の前記第２ＯＳに切り替える第１切り替えステップと、
   実行ＯＳが前記起動中または起動後の前記第２ＯＳである場合において前記目的アプリケーションに対する例外が発生したとき、前記ＣＰＵディスパッチャに基づいて前記ＣＰＵが実行ＯＳを前記第２ＯＳから前記第１ＯＳに切り替える第２切り替えステップと、
   をさらに備えることを特徴とする請求項１に記載のオペレーティングシステム起動方法。
3. 前記第２起動ステップは、前記ＣＰＵが、例外ベクタテーブルを編集して例外ベクタに前記ＣＰＵディスパッチャのエントリポイントに設定する第１例外ベクタ編集ステップをさらに備え、
   前記ＯＳ移行ステップは、前記ＣＰＵが、前記例外ベクタテーブルを編集して例外ベクタに前記第２ＯＳのエントリポイントを設定する第２例外ベクタ編集ステップをさらに備え、
   前記第２切り替えステップにおいて、前記ＣＰＵは、前記第１例外ベクタ編集ステップにより編集された前記例外ベクタテーブルに基づいて前記第２ＯＳから前記ＣＰＵディスパッチャに制御を移す、
   ことを特徴とする請求項２に記載のオペレーティングシステム起動方法。
4. 前記コンピュータは前記第１ＯＳおよび前記第２ＯＳのプログラムイメージを格納するメインメモリを備え、
   前記ＯＳ移行ステップの後、ＣＰＵが、前記第１ＯＳのプログラムイメージを格納していた前記メインメモリのメモリ領域を前記第２ＯＳの使用領域に割り当てるメモリ領域変更ステップ、
   をさらに備えることを特徴とする請求項１に記載のオペレーティングシステム起動方法。

Images