JP2011060225A - オペレーティングシステム起動方法 - Google Patents
オペレーティングシステム起動方法 Download PDFInfo
- Publication number
- JP2011060225A JP2011060225A JP2009212288A JP2009212288A JP2011060225A JP 2011060225 A JP2011060225 A JP 2011060225A JP 2009212288 A JP2009212288 A JP 2009212288A JP 2009212288 A JP2009212288 A JP 2009212288A JP 2011060225 A JP2011060225 A JP 2011060225A
- Authority
- JP
- Japan
- Prior art keywords
- cpu
- target application
- small
- rich
- dispatcher
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
【課題】コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くする。
【解決手段】スモールOS42を起動し、起動完了したスモールOS42上でターゲットアプリケーション43が起動する。スモールOS42上でターゲットアプリケーション43が起動完了した後、リッチOS41を起動し、起動完了したリッチOS41上でターゲットアプリケーション43が起動する。リッチOS41上でターゲットアプリケーション43が起動完了した後、スモールOS42上で動作しているターゲットアプリケーション43の実行状態をリッチOS42上で起動されたターゲットアプリケーション43に引き継ぎ、スモールOS42を使用停止する。
【選択図】図3
【解決手段】スモールOS42を起動し、起動完了したスモールOS42上でターゲットアプリケーション43が起動する。スモールOS42上でターゲットアプリケーション43が起動完了した後、リッチOS41を起動し、起動完了したリッチOS41上でターゲットアプリケーション43が起動する。リッチOS41上でターゲットアプリケーション43が起動完了した後、スモールOS42上で動作しているターゲットアプリケーション43の実行状態をリッチOS42上で起動されたターゲットアプリケーション43に引き継ぎ、スモールOS42を使用停止する。
【選択図】図3
Description
本発明は、オペレーティングシステム起動方法に関する。
従来、モバイル端末などのコンピュータに関し、起動してからアプリケーションが使用可能となるまでの時間をできるだけ短くしたいという要望がある。
例えば特許文献1によれば、ハードウェアを起動させた初期段階では、スモールOS(または汎用OSのいずれか)を起動し、汎用OSが起動した後、自由使用メモリ領域にスモールOSを格納することにより、使用するOS(実行OS)を切り替える。この技術を用い、最初にスモールOSを起動させることにより、起動してからユーザがスモールOS上で動作するアプリケーションを使用することができるようになるまでの時間を短縮することができる。しかしながら、この技術によれば、スモールOSからフルスペックの汎用OS(リッチOS)に切り替える際には、CPUのサスペンド、レジュームの操作が必要となる。サスペンド、レジュームの際、ユーザは使用を中断する必要があるため、起動時間の高速化の引き換えとしてユーザにとっての利便性を犠牲にする結果となる。
本発明は、コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くするオペレーティングシステム起動方法を提供することを目的とする。
本願発明の一態様によれば、CPUを備える目的アプリケーションを実行するためのコンピュータにおいてオペレーティングシステム(OS)を起動するオペレーティングシステム起動方法であって、前記CPUが、前記目的アプリケーションを実行する機能を備える第1OSを起動し、前記起動した第1OS上で前記目的アプリケーションを起動する第1起動ステップと、前記CPUが、実行OSを切り替えるためのCPUディスパッチャを起動するCPUディスパッチャ起動ステップと、前記CPUが、前記CPUディスパッチャを使用することによって、前記第1OS上に起動した前記目的アプリケーションを動作させつつ、前記第1OSのバックグラウンドで、前記目的アプリケーションを含む前記第1OSよりも多くのアプリケーションを実行する機能を備える第2OSを起動するとともに前記第1OS上で動作している前記所定のアプリケーションとは別に前記所定のアプリケーションを前記起動した第2OS上で起動する第2起動ステップと、前記CPUが、前記第1OS上で動作している前記所定のアプリケーションの実行状態を前記第2OS上に起動された前記所定のアプリケーションに受け渡す引き継ぎステップと、前記CPUが、実行OSを前記第2OSとするとともに前記CPUディスパッチャを停止するOS移行ステップと、を備えることを特徴とするオペレーティングシステム起動方法が提供される。
本発明によれば、コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くするオペレーティングシステム起動方法を提供することができるという効果を奏する。
以下に添付図面を参照して、本発明の実施の形態にかかるオペレーティングシステム起動方法を詳細に説明する。なお、この実施の形態により本発明が限定されるものではない。
(実施の形態)
図1は、本発明の実施の形態にかかるオペレーティングシステム起動方法を実行するコンピュータのハードウェア構成の一例を示すブロック図である。
図1は、本発明の実施の形態にかかるオペレーティングシステム起動方法を実行するコンピュータのハードウェア構成の一例を示すブロック図である。
図示するように、本発明の実施の形態のコンピュータ1は、CPU(Central Processing Unit)2、メインメモリ3、不揮発性メモリ4、入力部5、および表示部6を備えている。CPU2、メインメモリ3、不揮発性メモリ4、入力部5、および表示部6は夫々バスで接続されている。
不揮発性メモリ4は、ROM(Read Only Memory)やフラッシュメモリなどで構成され、リッチオペレーティングシステム(OS)プログラム41、スモールOSプログラム42、ターゲットアプリケーションプログラム43、およびCPUディスパッチャプログラム44を記憶している。
リッチOSプログラム41とは、コンピュータ1に多種多様な機能を実現させるためのアプリケーション群を実行させることができるOSのプログラムである。言い換えると、リッチOSプログラム41とは、フルスペックのOSである。
ターゲットアプリケーションプログラム43は、前記したリッチOSプログラム41で動作するアプリケーション群のうちの、コンピュータ1の起動開始から短い時間で使用可能となることが望まれるアプリケーション(以下、ターゲットアプリケーション)のプログラムである。ターゲットアプリケーションはどのようなアプリケーションであってもよい。例えばインターネットを閲覧する機能を重視し、該機能をいち早く使用可能な状態にしたい場合、インターネットの閲覧を行うためのアプリケーションをターゲットアプリケーションとするとよい。他には、テキストファイルを編集するためのアプリケーション、プレゼンテーション資料を編集するためのアプリケーション、電子メールを閲覧・送受信するためのアプリケーションなど、重視する機能に応じて所望のアプリケーションをターゲットアプリケーションとするとよい。なお、ターゲットアプリケーションは複数存在しても構わない。
スモールOSプログラム42は、少なくともターゲットアプリケーションプログラム43を実行するために必要な機能を備えたOSのプログラムであって、リッチOSプログラム41に比べて小さい規模のプログラムである。スモールOSプログラム42はリッチOSプログラム41に比べてプログラムの規模が小さいので、リッチOSプログラム41よりも高速に起動することができる。本実施の形態では、まずスモールOSプログラム42が起動され、起動されたスモールOSプログラム42上でターゲットアプリケーションプログラム43が起動されることによって、コンピュータ1の起動開始からターゲットアプリケーションプログラム43が使用可能となるまでの時間を短縮する。なお、コンピュータ1の起動開始からターゲットアプリケーションプログラム43が使用可能となるまでの時間の短縮幅を大きくするには、スモールOSプログラム42が実行可能なアプリケーションをターゲットアプリケーションのみとし、スモールOSプログラム42の機能を必要最小限にすることが望ましい。
CPUディスパッチャプログラム44は、CPUで実行するOSを複数のOS間で切り替えるためのプログラムである。OSの切り替えとは、具体的には、レジスタの退避・復元、切り替え対象の二つのOSが使用するアドレス空間の切り替えを含む。本実施の形態では、CPUディスパッチャプログラム44は、スモールOSプログラム42の起動の後に起動される。リッチOSプログラム41は、CPUディスパッチャプログラム44を使用することによって、スモールOSプログラム42のバックグラウンドで起動される。すなわち、起動されたCPUディスパッチャプログラム44は、ターゲットアプリケーションプログラム43を動作させるスモールOSプログラム42と、起動開始してからのリッチOSプログラム41と、の間でCPU2の割り当てを切り替える。CPUディスパッチャプログラム44は、リッチOSプログラム41よりもスモールOSプログラム42に優先してCPU2が割り当てられる。
なお、後ほど詳述するが、リッチOSプログラム41の起動完了後、リッチOSプログラム41上でターゲットアプリケーションプログラム43が起動される。リッチOSプログラム41上でのターゲットアプリケーションプログラム43の起動完了後、スモールOSプログラム42およびCPUディスパッチャプログラム44は停止され、ユーザはターゲットアプリケーションのみならずリッチOSプログラム41上で動作する全てのアプリケーションを使用することができるようになる。
メインメモリ3は、RAM(Random Access Memory)などで構成される、不揮発性メモリ4に比べて高速アクセス可能なメモリであって、CPU2が不揮発性メモリ4に格納されているプログラム41〜44を実行するためのワークエリアとして使用される。具体的には、CPU2により、プログラム41〜44のプログラムイメージ(以下、メモリイメージともいう)がロードされる。
ユーザがターゲットアプリケーションを操作することによってターゲットアプリケーションの実行状態が刻々と変化する。OSが切り替わったことを意識させることなくスモールOSプログラム42上で実行していたターゲットアプリケーションからリッチOSプログラム41上に起動されたターゲットアプリケーションに制御を移すために、スモールOSプログラム42上で動作していたターゲットアプリケーションは自身の実行状態を再現するために必要となる種々のデータ(以下、引き継ぎデータという)を作成する。作成された引き継ぎデータは、メインメモリ3に置かれ、リッチOSプログラム41上で起動されたターゲットアプリケーションに受け渡たされる。
入力部5はマウスやキーボードを備えて構成され、ユーザからのターゲットアプリケーションを含むアプリケーションに関する操作が入力される。入力部5へ入力された操作情報はCPU2へ送られる。
表示部6は、液晶モニタなどの表示装置であり、CPU2からの指示に基づいて、アプリケーションの操作画面などのユーザに対する出力情報を表示する。本実施の形態では、表示部6の表示画面には、スモールOSプログラム42が終了されるまでは図2(a)に示すようにターゲットアプリケーションの操作画面が表示され、リッチOSプログラム41およびリッチOSプログラム41上のターゲットアプリケーションの起動が完了し、スモールOSプログラム42が終了されると、図2(b)に示すようにターゲットアプリケーションのみならずその他のアプリケーションの操作画面が表示される。
次に、コンピュータ1において実行される本実施の形態のオペレーティングシステム起動方法を図3〜図6を参照して説明する。図3は、本実施の形態のオペレーティングシステム起動方法を説明するフローチャートである。なお、以降、リッチOSプログラム41を単にリッチOS41と表現することもある。同様に、スモールOSプログラム42、ターゲットアプリケーションプログラム43、CPUディスパッチャプログラム44を夫々スモールOS42、ターゲットアプリケーション43、CPUディスパッチャ44と表現することもある。
図3に示すように、コンピュータ1の起動が開始されると、まず、CPU2は、不揮発性メモリ4からスモールOS42を読み出して、前記読み出したスモールOS42をメインメモリ3にロードし、スモールOS42を起動する(ステップS1)。なお、スモールOS42の起動には、該起動をさらに高速に実行するために、スナップショットブートを利用するようにしてもよい。スナップショットブートとは、OS起動直後のメモリイメージを不揮発性メモリ4等に記録しておき、起動時に直接メインメモリ3上へ展開することで高速起動を実現するものである(例えば特許文献2)。なお、メモリイメージのサイズはOSプログラムの規模が大きくなるに伴って増加し、該メモリイメージの増加によって起動時間が長くなる傾向がある。スモールOS42は、前述したように、アプリケーションに関してはターゲットアプリケーション43を実行するための機能のみを備えていればよい比較的規模の小さいプログラムであるので、スナップショットブートを用いることでスモールOS42の起動の高速化が期待できる。
続いて、CPU2は、スモールOS42の起動が完了すると、起動されたスモールOS42上にターゲットアプリケーション43を起動する(ステップS2)。ターゲットアプリケーション43の起動が完了すると、図2(a)に示したように、CPU2は、表示部6の表示画面にターゲットアプリケーション43の操作画面を表示させる。このように、フルスペックのリッチOS41の代わりにスモールOS42を起動し、スモールOS42上でターゲットアプリケーション43を起動するようにしたので、ユーザは、リッチOS41を起動してリッチOS41上でターゲットアプリケーション43を起動する場合に比べて短い時間でターゲットアプリケーション43を使用できるようになる。
図4は、本実施の形態のオペレーティングシステム起動方法により変化するコンピュータ1の状態を説明する概念図である。図4(a)は、ステップS2によりターゲットアプリケーション43が起動されたコンピュータ1の状態を説明する図である。図示するように、ハードウェア11の上にスモールOS42が動作しており、スモールOS42の上でターゲットアプリケーション43が動作している。なお、ハードウェア11は、BIOSを含む(図中ではBIOS・ハードウェアと記載)。表示画面はターゲットアプリケーション43の操作画面を表示している。なお、スモールOS42では、例外や割り込み(以下、両者をまとめて例外と表記する)の種類毎に対応するプログラムのメモリ空間上のアドレスである例外ベクタアドレス(以下、単に例外ベクタ)が定義されている。スモールOS42は、メモリ空間のカーネル領域に、例外の種類毎に例外ベクタを示す例外ベクタテーブル421を有している。なお、この時点においては、例外ベクタテーブル421の例外ベクタは、スモールOS42に含まれるプログラムの格納場所を指している。例外とは、例えばユーザによるターゲットアプリケーションを操作する入力部5からの入力であったりする。
図3に戻り、スモールOS42上でのターゲットアプリケーション43の起動を完了した後、CPU2は、CPUディスパッチャ44を不揮発性メモリ4から読み出して、読み出したCPUディスパッチャ44をメインメモリ3にロードし、CPUディスパッチャ44を起動する(ステップS3)。
図4(b)は、CPUディスパッチャ44が起動された直後の状態を示している。図示するように、CPUディスパッチャ44(図中では単にディスパッチャ44と表記している)は、ハードウェア11とスモールOS42との間に介在して存在している。なお、この時点で例外が発生すると、CPU2は、スモールOS42が備える例外ベクタテーブル421に基づき、スモールOS42に例外を通知する。
ステップS3の後、CPU2は、リッチOS41を不揮発性メモリ4から読み出して、読み出したリッチOS41をメインメモリ3にロードする(ステップS4)。
そして、CPU2は、スモールOS42のバックグラウンドでリッチOS41を起動するために、例外ベクタテーブル421を書き換えて、例外ベクタにCPUディスパッチャ44のエントリポイントを設定し(ステップS5)、CPUディスパッチャ44を使用して、スモールOS42のバックグラウンドでリッチOS41の起動を開始する(ステップS6)。なお、リッチOS41の起動にもスナップショットブートを適用してもよい。
ここで、スモールOS42のバックグラウンドでリッチOS41の起動などリッチOS41に関する処理を実行するとは、具体的には、スモールOS42がidleの間にリッチOS41に関する処理を実行することを言う。すなわち、スモールOS42上のターゲットアプリケーション43に関するユーザからの操作や該ターゲットアプリケーション43が処理を非実行中であるとき、CPUディスパッチャ44はスモールOS42から自身を起動中またはターゲットアプリケーション43を起動中のリッチOS41に制御を移し、ユーザからのターゲットアプリケーション43に関する入力などスモールOS42に関する例外が発生したとき、リッチOS41からスモールOS42に制御を移す。
図5は、例外発生時のCPUディスパッチャ44の動作を説明するフローチャートである。図示するように、例外が発生すると、CPU2は例外ベクタテーブル421を参照してCPUディスパッチャ44に制御を移し、発生した例外がスモールOS42に対するものであるか否かを判定する(ステップS11)。発生した例外がスモールOS42に対するものであった場合(ステップS11、Yes)、CPU2は、スモールOS42が動作中であるか否かをさらに判定する(ステップS12)。リッチOS41が動作中であった場合(ステップS12、No)、CPUディスパッチャ44は、リッチOS41からスモールOS42にCPU2の割り当てを変更、すなわちOSを切り替え(ステップS13)、スモールOS42に前記発生した例外を通知する(ステップS14)。例外の通知が終了すると、CPU2はCPUディスパッチャ44からスモールOS42に制御を移し、CPUディスパッチャ44の動作はリターンとなる。ステップS12の判定処理において、スモールOS42が動作中であると判定された場合(ステップS12、Yes)、ステップS14に移行する。
一方、ステップS11の判定処理において、発生した例外がリッチOS41に対するものであると判定された場合(ステップS11、No)、CPU2は、スモールOS42が動作中であるか否かをさらに判定する(ステップS15)。スモールOS42が動作中であった場合(ステップS15、Yes)、CPUディスパッチャ44は、スモールOS42がidleになるまでリッチOS41への例外通知を遅延させるために、CPUディスパッチャ44内でリッチOS41の例外状態を記録する(ステップS16)。そして、CPU2は、CPUディスパッチャ44からスモールOS42へ制御を移し(スモールOS42へ復帰し)(ステップS17)、CPUディスパッチャ44の動作がリターンとなる。ステップS16にて記録されたリッチOS41の例外状態は、その後スモールOS42がidleとなり、リッチOS41へ制御が移る際に参照され、例外状態が記録されていればCPUディスパッチャ44からリッチOS41へ例外が通知される。
ステップS15の判定処理においてリッチOS41が動作中であると判定された場合(ステップS15、No)、CPUディスパッチャ44はリッチOS41へ例外を通知し(ステップS18)、CPUディスパッチャ44の動作がリターンとなる。
このように、スモールOS42がidle状態のとき、CPUディスパッチャ44はリッチOS41へCPU2を割り当て、CPU2がリッチOS41に関する処理(リッチOS41の起動、後述するリッチOS41上でのターゲットアプリケーション43の起動)を実行中に例外が発生したとき、例外ベクタテーブル421の記述に基づいてCPUディスパッチャ44に制御を移し、CPUディスパッチャ44は、CPUディスパッチャ44に基づいて、スモールOS42へCPU2を割り当てる。すなわち、CPUディスパッチャ44はリッチOS41よりもスモールOS42に優先してCPU2を割り当てる。
なお、本実施の形態では、スモールOS42およびリッチOS41はともにデバイスを直接制御することができるようにしておくとよい。この場合、OS41、42間で共有するデバイス(例:入力部5、表示部6など)は、各OS41、42のデバイスドライバが協調して操作する必要がある。例えば、新たに起動されたリッチOS41のデバイスドライバがデバイス検出を行う際に、すでに初期化済みであるなら初期化を行わず、スモールOS42のデバイスドライバへ要求を発行することで間接的にデバイスを操作する。また、後述するステップS9においてスモールOS42を使用しないように変更する場合も、共有デバイスを持つドライバには通知を行うことでそれ以後はリッチOS41のみがデバイスを直接操作するように処理を変更できることとするとよい。
図3に戻り、CPU2は、リッチOS41の起動終了後、リッチOS41上でターゲットアプリケーション43を起動する(ステップS7)。この処理もスモールOS42のバックグラウンドで実行されるので、ユーザにはスモールOS42上のターゲットアプリケーション43しか見えない。なお、ステップS7では、ターゲットアプリケーション43だけでなくリッチOS41上で動作するターゲットアプリケーション43以外のアプリケーションをも起動するようにしてもよい。
図4(c)は、ステップS7の処理を実行中のコンピュータ1の状態を説明する図である。図示するように、CPUディスパッチャ44の上にスモールOS42とともにリッチOS41が存在し、リッチOS41の上にターゲットアプリケーション43のみならずその他のアプリケーションも動作している。表示画面には、ターゲットアプリケーション43の操作画面のみが表示される。
ターゲットアプリケーション43の起動終了後、CPU2は、メインメモリ3上で、スモールOS42上のターゲットアプリケーション43の引き継ぎデータをリッチOS41上のターゲットアプリケーション43に受け渡す(ステップS8)。言い換えると、スモールOS42上のターゲットアプリケーション43の実行状態をリッチOS41上のターゲットアプリケーション43に受け渡す。この引き継ぎは、ターゲットアプリケーション43が動作するOSが変化したことをユーザに認識させないように、安全にセッションを引き継げる状態となった時点で行われる。
ターゲットアプリケーションの実行状態の引き継ぎが完了した後、CPU2は、リッチOS41を実行OSとし、リッチOS41に例外が通知されるように例外ベクタテーブル421を書き換える(ステップS9)。これにより、スモールOS42およびCPUディスパッチャ44の動作が停止し、コンピュータ1ではOSとしてリッチOS41のみが動作し、ユーザはリッチOS41上で動作しているターゲットアプリケーション43を操作できる状態となる。また、ユーザは、ターゲットアプリケーション43以外のアプリケーションを操作することができるようになる。すなわち、コンピュータ1のOSの起動が完了する。
なお、例外ベクタテーブル421の書き換えは、システムコール等の例外によって、スモールOS42またはリッチOS41がCPUディスパッチャ44に書き換えを要求し、CPUディスパッチャ44が例外ベクタテーブル421を書き換えるようにするとよい。スモールOS42が使用していたメインメモリ3の領域については、CPU2は、リッチOS41が使用可能なメモリ領域に追加するようにしてもよい。
図4(d)は、本実施の形態のオペレーティングシステム起動方法が完了した後のコンピュータ1の状態を説明する図である。図示するように、ハードウェア11の上にリッチOS41が動作し、リッチOS41の上でターゲットアプリケーション43およびその他のアプリケーションが動作している。表示画面には、ターゲットアプリケーション43および他のアプリケーションの操作画面が表示される。
図6は、ターゲットアプリケーション43の実行状態の引き継ぎを詳しく説明するタイミングチャートである。図示するように、最初に、ステップS2によりスモールOS42上のターゲットアプリケーション43が起動を完了し(ステップS21)、ユーザに対するサービスが開始される(ステップS22)。その後しばらくしてからステップS7によるリッチOS41上のターゲットアプリケーション43が起動を完了する(ステップS23)。リッチOS41上のターゲットアプリケーション43は、メインメモリ3を用いたOS間通信などによって、スモールOS42上のターゲットアプリケーション43へ引き継ぎ要求メッセージを送信し(ステップS24)、スモールOS42上のターゲットアプリケーション43からの引き継ぎ準備完了メッセージを待つ。
スモールOS42上のターゲットアプリケーション43はこのメッセージを受信すると(ステップS25)、引き継ぎ可能な状態になるまでユーザへのサービスを継続する。引き継ぎ可能な状態としては、ユーザからのサービス要求に応答するまでにある程度の待ち時間が発生するような状態(I/O処理待ちなど)がある。スモールOS42上のターゲットアプリケーション43は、この状態を検出すると(ステップS26)、本来のサービス要求に対する処理に加えて、リッチOS41上のターゲットアプリケーション43が引き継ぎデータの準備を行う(ステップS27)。スモールOS42上のターゲットアプリケーション43は、引き継ぎデータをメインメモリ3に置き、リッチOS41上のターゲットアプリケーション43から参照できるようにする。引き継ぎデータの準備が完了すると、スモールOS42上のターゲットアプリケーション43は、リッチOS41上のターゲットアプリケーション43へ引き継ぎ準備完了メッセージを送信し(ステップS28)、自分自身はターゲットアプリケーション43としての動作を終了する(ステップS29)。
リッチOS41上のターゲットアプリケーション43は引き継ぎ準備完了メッセージを受信すると(ステップS30)、メインメモリ3上の引き継ぎデータを使って、自分自身の状態をスモールOS42上のターゲットアプリケーション43と同じ実行状態にし(ステップS31)、ステップS9により例外ベクタテーブル421が書き換えられた後、ユーザに対してサービスを開始する(ステップS32)。この結果、ユーザには当初のサービス要求に対する応答が返るが、ターゲットアプリケーション43の引き継ぎ処理をユーザが認識することはない。
なお、CPU2は、どのプログラムあるいはハードウェアの制御に基づいて前述した順序およびタイミングでスモールOS42、スモールOS42上のターゲットアプリケーション43、CPUディスパッチャ44、リッチOS41、リッチOS41上のターゲットアプリケーション43を起動させるようにしてもよい。例えば、ステップS1はブートローダプログラム(図示せず)の制御によりCPU2が実行し、ステップS2〜ステップS7はスモールOS42の制御によりCPU2が実行し、ステップS8はスモールOS42上のターゲットアプリケーション43およびリッチOS41上のターゲットアプリケーション43の制御によりCPU2が実行し、ステップS9はCPUディスパッチャ44の制御によりCPU2が実行するようにしてもよい。
なお、CPUディスパッチャ44の起動、例外ベクタテーブル421の書き換え、CPUディスパッチャ44を利用したリッチOS41の起動は、CPU特権モードで実行する必要がある。例えば、スモールOS42がLinux(登録商標)である場合、CPUディスパッチャ44のイメージ、例外ベクタテーブル421の書き換えプログラム、リッチOS41のイメージをローダブルモジュール化しておき、夫々のモジュールのインストール時に、CPUディスパッチャ44の起動、例外ベクタテーブル421の書き換え、リッチOS41のロードに必要なアドレス空間の用意および該アドレス空間へのリッチOS41のロードを実行するようにするとよい。
また、スモールOSを立ち上げて、追加モジュールを逐次起動することによって多数のアプリケーション群を実行できるようにする技術が知られている。しかしながら、この技術によれば、追加モジュールのインストール時にはCPU特権モードとなる必要があるため、ターゲットアプリケーションの動作に影響が出る。これに対して本実施の形態では、CPUディスパッチャ44の起動、リッチOS41の起動、および例外ベクタの書き換えのときのみCPU特権モードとなるだけでよいので、前記した追加モジュールを逐次起動する方法に比べて安定した動作が可能となる。
また、あるOSを実行し、このOSのバックグラウンドでその他のOSを起動する技術は、CPU仮想化技術として一般的に知られている。しかしながら、このままでは常に仮想化が有効となっているので、仮想化オーバヘッドによってシステムの性能が低下する。これに対して、本実施の形態は、スモールOS42を起動後、動的にCPU仮想化を有効にしてリッチOS41を起動し、リッチOS41上の全ての機能が使用可能となったとき、動的にCPU仮想化を無効化しているといえる。従って、本実施の形態では、ユーザが全ての機能を使用できるようになった後、実行OSとしてリッチOS41のみが動いている状態となるので、仮想化オーバヘッドによる性能低下を防ぐことができるようになる。
また、本実施の形態では、各プログラム41〜44をバスに接続された不揮発性メモリ4内に格納しておくようにしたが、プログラム41〜44のうちのいくつかまたは全てを外部記憶装置(図示せず)やコンピュータ1からネットワーク(図示せず)を介してアクセス可能な記憶装置に格納しておくようにしてもよい。
また、スモールOS42を1個だけ起動し、該スモールOS42からリッチOS41を起動するとして説明したが、スモールOS42の数は複数であっても構わない。
また、スモールOS42からリッチOS41を起動するとして説明したが、スモールOS42からリッチOS41とは異なる別のOSを起動し、該起動したOSからリッチOS41を起動するようにしてもよい。
以上説明したように、本発明の実施の形態によれば、スモールOS42を起動し、起動したスモールOS42上でターゲットアプリケーション43を起動し、ターゲットアプリケーション43を起動完了した後、CPUディスパッチャ44を起動し、CPUディスパッチャ44を起動した後、該CPUディスパッチャ44を使用することによって、スモールOS42上に起動したターゲットアプリケーション43を動作させつつ、スモールOS42のバックグラウンドで、リッチOS41を起動するとともにリッチOS41上で動作しているターゲットアプリケーション43とは別にターゲットアプリケーション43を前記起動したリッチOS41上で起動し、リッチOS41上のターゲットアプリケーション43の起動を完了した後、スモールOS41上で動作しているターゲットアプリケーション43の実行状態をリッチOS41上に起動されたターゲットアプリケーション43に受け渡し、実行OSをリッチOS41としてCPUディスパッチャ44を停止させる、ように構成したので、コンピュータが起動開始してから目的のアプリケーションが使用可能となるまでの時間を可及的に短くすることができる。
1 コンピュータ、2 CPU、3 メインメモリ、4 不揮発性メモリ、5 入力部、6 表示部、11 ハードウェア、41 リッチOSプログラム、42 スモールOSプログラム、43 ターゲットアプリケーションプログラム、44 CPUディスパッチャプログラム、421 例外ベクタテーブル。
Claims (4)
- CPUを備える目的アプリケーションを実行するためのコンピュータにおいてオペレーティングシステム(OS)を起動するオペレーティングシステム起動方法であって、
前記CPUが、前記目的アプリケーションを実行する機能を備える第1OSを起動し、前記起動した第1OS上で前記目的アプリケーションを起動する第1起動ステップと、
前記CPUが、実行OSを切り替えるためのCPUディスパッチャを起動するCPUディスパッチャ起動ステップと、
前記CPUが、前記CPUディスパッチャを使用することによって、前記第1OS上に起動した前記目的アプリケーションを動作させつつ、前記第1OSのバックグラウンドで、前記目的アプリケーションを含む前記第1OSよりも多くのアプリケーションを実行する機能を備える第2OSを起動するとともに前記第1OS上で動作している前記所定のアプリケーションとは別に前記所定のアプリケーションを前記起動した第2OS上で起動する第2起動ステップと、
前記CPUが、前記第1OS上で動作している前記所定のアプリケーションの実行状態を前記第2OS上に起動された前記所定のアプリケーションに受け渡す引き継ぎステップと、
前記CPUが、実行OSを前記第2OSとするとともに前記CPUディスパッチャを停止するOS移行ステップと、
を備えることを特徴とするオペレーティングシステム起動方法。 - 前記第2起動ステップは、
実行OSが前記第1OSである場合において前記第1OSがアイドル状態となったとき、前記CPUディスパッチャに基づいて前記CPUが実行OSを前記第1OSから前記起動中または起動後の前記第2OSに切り替える第1切り替えステップと、
実行OSが前記起動中または起動後の前記第2OSである場合において前記目的アプリケーションに対する例外が発生したとき、前記CPUディスパッチャに基づいて前記CPUが実行OSを前記第2OSから前記第1OSに切り替える第2切り替えステップと、
をさらに備えることを特徴とする請求項1に記載のオペレーティングシステム起動方法。 - 前記第2起動ステップは、前記CPUが、例外ベクタテーブルを編集して例外ベクタに前記CPUディスパッチャのエントリポイントに設定する第1例外ベクタ編集ステップをさらに備え、
前記OS移行ステップは、前記CPUが、前記例外ベクタテーブルを編集して例外ベクタに前記第2OSのエントリポイントを設定する第2例外ベクタ編集ステップをさらに備え、
前記第2切り替えステップにおいて、前記CPUは、前記第1例外ベクタ編集ステップにより編集された前記例外ベクタテーブルに基づいて前記第2OSから前記CPUディスパッチャに制御を移す、
ことを特徴とする請求項2に記載のオペレーティングシステム起動方法。 - 前記コンピュータは前記第1OSおよび前記第2OSのプログラムイメージを格納するメインメモリを備え、
前記OS移行ステップの後、CPUが、前記第1OSのプログラムイメージを格納していた前記メインメモリのメモリ領域を前記第2OSの使用領域に割り当てるメモリ領域変更ステップ、
をさらに備えることを特徴とする請求項1に記載のオペレーティングシステム起動方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009212288A JP2011060225A (ja) | 2009-09-14 | 2009-09-14 | オペレーティングシステム起動方法 |
US12/876,452 US20110066836A1 (en) | 2009-09-14 | 2010-09-07 | Operating system booting method, computer, and computer program product |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009212288A JP2011060225A (ja) | 2009-09-14 | 2009-09-14 | オペレーティングシステム起動方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2011060225A true JP2011060225A (ja) | 2011-03-24 |
Family
ID=43731614
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009212288A Pending JP2011060225A (ja) | 2009-09-14 | 2009-09-14 | オペレーティングシステム起動方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US20110066836A1 (ja) |
JP (1) | JP2011060225A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012256091A (ja) * | 2011-06-07 | 2012-12-27 | Mitsubishi Electric Corp | 情報処理装置及びその起動方法 |
JP2013105391A (ja) * | 2011-11-15 | 2013-05-30 | Fujitsu Ltd | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
KR20140059222A (ko) * | 2011-09-09 | 2014-05-15 | 마이크로소프트 코포레이션 | 중지된 애플리케이션 재개 및/또는 애플리케이션의 중지 면제 기법 |
JP2014112369A (ja) * | 2012-11-27 | 2014-06-19 | Oberthur Technologies | 無効化モジュールを備えた電子アセンブリ |
JP2014192656A (ja) * | 2013-03-27 | 2014-10-06 | Mitsubishi Electric Corp | 情報処理装置及び起動方法 |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2998694B1 (fr) * | 2012-11-27 | 2016-01-01 | Oberthur Technologies | Module electronique pour rendre un message accessible par un systeme d'exploitation vise |
FR2998747B1 (fr) * | 2012-11-27 | 2015-01-23 | Oberthur Technologies | Procede d'aiguillage d'un message |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7103767B2 (en) * | 2003-09-30 | 2006-09-05 | Intel Corporation | Method and apparatus to support legacy master boot record (MBR) partitions |
US7689620B2 (en) * | 2006-05-24 | 2010-03-30 | Sizhe Tan | Efficiently and systematically searching stock, image, and other non-word-based documents |
JP5028904B2 (ja) * | 2006-08-10 | 2012-09-19 | ソニー株式会社 | 電子機器、および起動方法 |
US9003173B2 (en) * | 2007-09-28 | 2015-04-07 | Microsoft Technology Licensing, Llc | Multi-OS (operating system) boot via mobile device |
-
2009
- 2009-09-14 JP JP2009212288A patent/JP2011060225A/ja active Pending
-
2010
- 2010-09-07 US US12/876,452 patent/US20110066836A1/en not_active Abandoned
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012256091A (ja) * | 2011-06-07 | 2012-12-27 | Mitsubishi Electric Corp | 情報処理装置及びその起動方法 |
KR20140059222A (ko) * | 2011-09-09 | 2014-05-15 | 마이크로소프트 코포레이션 | 중지된 애플리케이션 재개 및/또는 애플리케이션의 중지 면제 기법 |
KR101933246B1 (ko) | 2011-09-09 | 2018-12-27 | 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 | 중지된 애플리케이션 재개 및/또는 애플리케이션의 중지 면제 기법 |
JP2013105391A (ja) * | 2011-11-15 | 2013-05-30 | Fujitsu Ltd | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
JP2014112369A (ja) * | 2012-11-27 | 2014-06-19 | Oberthur Technologies | 無効化モジュールを備えた電子アセンブリ |
JP2014192656A (ja) * | 2013-03-27 | 2014-10-06 | Mitsubishi Electric Corp | 情報処理装置及び起動方法 |
Also Published As
Publication number | Publication date |
---|---|
US20110066836A1 (en) | 2011-03-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5032191B2 (ja) | サーバ仮想化環境におけるクラスタシステム構成方法及びクラスタシステム | |
KR101134816B1 (ko) | 운영 체제 초기화 중에 플랫폼 그래픽을 디스플레이하기 위한 방법 및 시스템 | |
JP4842210B2 (ja) | フェイルオーバ方法、計算機システム、管理サーバ及び予備サーバの設定方法 | |
JP5385347B2 (ja) | メイン・メモリのフリー・メモリ量を拡大する方法およびコンピュータ | |
US20110113426A1 (en) | Apparatuses for switching the running of a virtual machine between multiple computer devices belonging to the same computer platform and the associated switching methods | |
JP5212360B2 (ja) | 制御プログラム、制御システムおよび制御方法 | |
JP2011060225A (ja) | オペレーティングシステム起動方法 | |
US20110173429A1 (en) | Method and apparatus to minimize computer apparatus initial program load and exit/shut down processing | |
US9959134B2 (en) | Request processing using VM functions | |
JP2000330806A (ja) | 計算機システム | |
JP2012220990A (ja) | ハイパーバイザ置き換え方法および情報処理装置 | |
KR20070100367A (ko) | 하나의 가상 머신에서 다른 가상 머신으로 메모리를동적으로 재할당하기 위한 방법, 장치 및 시스템 | |
JP2009003749A (ja) | 仮想化プログラム及び仮想計算機システム | |
US20110219373A1 (en) | Virtual machine management apparatus and virtualization method for virtualization-supporting terminal platform | |
JP6111181B2 (ja) | 計算機の制御方法及び計算機 | |
JP2012252576A (ja) | 情報処理装置、起動方法およびプログラム | |
JP5200085B2 (ja) | コンピュータを短時間で起動する方法およびコンピュータ | |
JP2011103093A (ja) | 高速で起動するコンピュータ | |
CN113094111B (zh) | 设备以及设备的启动方法 | |
US11671379B1 (en) | System and method for subscription management using dynamically composed management entities | |
US20190310874A1 (en) | Driver management method and host | |
JP2006351013A (ja) | 電子装置において保存/リストア手順を行なうための方法及びシステム | |
JP2002132741A (ja) | プロセッサ追加方法、計算機及び記録媒体 | |
KR100994723B1 (ko) | 시스템에서 초기 구동시간을 단축시키는 선택적 서스펜드 리쥼 방법 및 그 기록매체 | |
US8949587B2 (en) | Method for dynamic loading of operating systems on bootable devices |