JP2007507779A - オペレーティングシステム - Google Patents

オペレーティングシステム Download PDF

Info

Publication number
JP2007507779A
JP2007507779A JP2006530758A JP2006530758A JP2007507779A JP 2007507779 A JP2007507779 A JP 2007507779A JP 2006530758 A JP2006530758 A JP 2006530758A JP 2006530758 A JP2006530758 A JP 2006530758A JP 2007507779 A JP2007507779 A JP 2007507779A
Authority
JP
Japan
Prior art keywords
operating system
kernel
nanokernel
exception
interrupt
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
Application number
JP2006530758A
Other languages
English (en)
Inventor
レスクエット,エリック
グロウズデヴ,ブラディミール
Original Assignee
ジャルナ エスアー
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 ジャルナ エスアー filed Critical ジャルナ エスアー
Priority claimed from PCT/IB2004/003344 external-priority patent/WO2005033928A2/en
Publication of JP2007507779A publication Critical patent/JP2007507779A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B82NANOTECHNOLOGY
    • B82YSPECIFIC USES OR APPLICATIONS OF NANOSTRUCTURES; MEASUREMENT OR ANALYSIS OF NANOSTRUCTURES; MANUFACTURE OR TREATMENT OF NANOSTRUCTURES
    • B82Y10/00Nanotechnology for information processing, storage or transmission, e.g. quantum computing or single electron logic

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

複数の異なるオペレーティングシステムを同一RISCコンピュータ上で同時に動作させる方法であって、相対的に高い優先順位を有する第1オペレーティングシステム(C5などのリアルタイムオペレーティングシステム)を選択することと、相対的に低い優先順位を有する少なくとも1つの副オペレーティングシステム(Linuxなどの汎用オペレーティングシステム)を選択することと、所定の条件の下で各オペレーティングシステムの間で切り替えるように構成された共通プログラム(ナノカーネルに似たハードウェアリソースディスパッチャ)を提供することと、第1および第2のオペレーティングシステムを共通プログラムによって制御できるようにするために第1および第2のオペレーティングシステムに対して修正を加えることとを含む方法。
【選択図】 図1

Description

本発明は、オペレーティングシステムに関する。具体的には、本発明は、複数のオペレーティングシステムを同時に動作させるシステム、方法、およびコンピュータプログラムに関する。
いくつかのコンピュータプログラムでは、プログラムのステップが、規定された時間内にまたは規定された時刻に実行されることが重要である。そのようなプログラムの例としては、携帯電話機を動作させる制御プログラム、または構内交換機(PBX)もしくはセルラ基地局を動作させる制御プログラムが挙げられる。通常、プログラムは、外部イベントまたは状態の変化に対して、一貫した形で、そのイベントの後の特定の時刻にまたはある時間以内に応答しなければならない。これを「リアルタイム」での動作と称する。
しかし、多数の他のプログラムについては、そのプログラムを実行するのに要する時間は、重要ではない。これは、スプレッドシートプログラム、ワードプロセッシングプログラム、給与パッケージ、および一般的なレポート作成プログラムまたは分析プログラムを含めて、大抵の一般的なコンピュータプログラムにあてはまる。その一方で、そのようなプログラムが要する正確な時間はクリティカルでないが、大抵の場合、ユーザは、可能であるならば、よりすばやい実行を好む。
アプリケーションプログラムは、それが動作するコンピュータと、オペレーティングシステムを介して相互作用する。オペレーティングシステムのアプリケーションプログラミングインターフェース(API)を使用することによって、アプリケーションプログラムをポータブルな形で記述することができ、その結果、そのアプリケーションプログラムを、異なるハードウェアリソースを有する異なるコンピュータで実行できるようになる。さらに、LinuxまたはWindowsなどの一般的なオペレーティングシステムは、マルチタスキングを提供する。言い換えると、これらのオペレーティングシステムは、複数のプログラムを同時に実行することを可能にする。それを行うために、これらのオペレーティングシステムは、スケジューリングを提供する。言い換えると、これらのオペレーティングシステムは、異なるプログラムの間でコンピュータのリソースの使用を共用し、スケジューリングアルゴリズムに従って各プログラムに時間を割り振る。この種のオペレーティングシステムは、非常に広い範囲で使用されているが、一般に、リアルタイムアプリケーションを動作させる準備がなく、したがって、多数の制御タスクまたは通信タスクに不適切である。
したがって、そのようなタスクに関して、リアルタイムオペレーティングシステムが開発され、その一例が、ChorusOS(Chorusとも称する)およびその派生物である。Chorusは、オープンソースソフトウェアとしてhttp://www.experimentalstuff.com/Technologies/ChorusOS/index.htmlから、およびhttp://www.jaluna.com/のJalunaから入手可能である。
ChorusOSは、http://www.jaluna.com/developer/papers/COSDESPERF.pdfから入手できる「ChorusOS Features and Architecture overview」、Francois Armand、Sun Technical Report、2001年8月、222頁で説明されている。
これらのオペレーティングシステムを使用して、他のタイプのプログラムを動作させることもできる。しかし、ユーザは、当然、WindowsまたはLinuxなどの汎用オペレーティングシステム用に記述された膨大な数の「レガシ(legacy)」プログラムを、リアルタイムオペレーティングシステムで動作させるためにこれらを書き直す必要なしに実行できることを望む。
「デュアルブート」システムを提供し、ユーザが一方のオペレーティングシステムまたは他方のオペレーティングシステムのいずれかを動作させることを可能にすることができるが、リアルタイムプログラムを動作させるのと同時に「レガシ」プログラムを動作できることが望ましい場合が多数ある。例えば、遠隔通信ネットワークインフラストラクチャ機器、第3世代携帯電話機および他の高度な電話機、ならび高度な電子ゲーム機器が、リアルタイムアプリケーション(例えば、グラフィックスを再生するゲーム)および非リアルタイムアプリケーション(ゲームのダウンロード)の両方を必要とする可能性がある。
米国特許第5903752号および米国特許第5721922号では、非リアルタイムオペレーティングシステム(Windowsなど)の割込み処理環境にリアルタイムマルチタスキングカーネルを設けることによって、非リアルタイムオペレーティングシステムにリアルタイム環境を組み込む試みが行われている。
広く使用されている1つの手法が、「エミュレーション」である。通常、汎用オペレーティングシステム用に記述されたプログラムの各命令を解釈し、リアルタイムオペレーティングシステムの下で対応する一連の命令を実行するエミュレータプログラムが、リアルタイムオペレーティングシステムの下で動作するように記述される。しかし、1つの命令が、必ず多数の命令によって置換されるので、エミュレーションは、より重い負荷をコンピュータにかけ、性能がより低下する。類似する問題が、仮想計算機(例えば、Java(商標)仮想計算機)を提供することに基づく手法から生じる。仮想計算機実装の例が、欧州特許第1059582号、米国特許第5499379号、および米国特許第4764864号である。
さらに同様な技法が、米国特許第5995745号(Yodaiken)に記載されている。Yodaikenは、マルチタスキングリアルタイムオペレーティングシステムが、そのタスクの1つとして汎用オペレーティングシステムを動作させ、リアルタイムタスクの実行に必要なときにそれに取って代わる(プリエンプトする)システムを説明している。
もう1つの手法が、例えば欧州特許第0360135号および記事「Merging real−time processing and UNIX V」、(Gosch)、ELECTRONICS、1990年9月、62頁に記載されている、汎用オペレーティングシステムのモジュールとしてリアルタイムオペレーティングシステムを動作させることである。この例では、ハードウェア割込みは、汎用オペレーティングシステムに関係するハードウェア割込みがリアルタイムオペレーティングシステムをプリエンプトしてはならないという意図で、選択的にマスクされる。
もう1つの手法が、http://opersys.com/ftp/pub/Adeos/adeos.pdfのホワイトペーパーに記載されたADEOS(Adaptive Domain Environment for Operating Systems)の手法である。
ADEOSは、とりわけ複数のオペレーティングシステムを動作させることを意図されたナノカーネルを提供するが、Linuxと共に実装されただけであるように思われる。ADEOSの提案された用途の1つが、ADEOSにRTAI(Realtime Application Interface for Linux)に割込みを分配させることであったが、RTAIについては、http://www.aero.polimi.it/〜rtai/applications/を参照されたい。
欧州特許第1054332号に、「スイッチングユニット」(完全な理解に十分に詳細には説明されていない)が、リアルタイムオペレーティングシステムおよび汎用オペレーティングシステムを動作させるシステムが記載されている。ハードウェア割込みが、共通の割込みハンドラによって処理され、いくつかの実施形態では、ハードウェア割込みはリアルタイムオペレーティングシステムによって処理され、このリアルタイムオペレーティングシステムは、副オペレーティングシステム内のルーチンで処理されるソフトウェア割込みをより低い優先順位レベルで生成する。
本発明の目的は、複数のオペレーティングシステムを、これらが異なる目的のために設計されている場合であっても、同時に動作させる改善されたシステム、方法、およびコンピュータプログラムを提供することである。特に、本発明は、オペレーティングシステムのうちの1つ(例えば、リアルタイムオペレーティングシステム)が、邪魔されずに動作することを可能にし、他のオペレーティングシステム(例えば、汎用オペレーティングシステム)が、コンピュータの残りのリソースを使用して、できる限り良好に動作することを可能にすることを目指す。
したがって、一態様で、本発明は、複数のオペレーティングシステムが、わずかに修正され、それらの間でスケジューリングする共通のプログラムを設けられ、オペレーティングシステムのうちの1つ(「主」オペレーティングシステムまたは「クリティカル」オペレーティングシステム)が、別のオペレーティングシステム(「副」オペレーティングシステムまたは非クリティカルオペレーティングシステム)より優先されるシステムを提供する。本発明は、クリティカルオペレーティングシステムに優先的にハードウェアを割り振り、クリティカルオペレーティングシステムのアクセスに干渉する1つまたは複数の副オペレーティングシステムアクセスを拒否することが好ましい。本発明は、アクセスが副オペレーティングシステムによって要求される場合であっても、クリティカルオペレーティングシステムドライバを使用して共用リソースにアクセスすることが好ましい。しかし、決して、米国特許第5995745号のように、クリティカルオペレーティングシステムが副オペレーティングシステムを「動作させる」のではない。各システムは、一緒に動作している他のシステムを無視し、共通プログラム(従来技術のナノカーネルに対応する)だけと通信し、この共通プログラムが、クリティカルオペレーティングシステムのドライバへのアクセスを仲介する。
副オペレーティングシステムが割り込みをマスクできないように変更され、その割込みサービスルーチンが、割込みが発生したことを示すメッセージに応答するように変更されることが好ましい。共通プログラムは、すべてのハードウェア例外を主オペレーティングシステムの割込みサービスルーチンに渡すことによって、すべてのハードウェア例外を処理し、ハードウェア割込みが副オペレーティングシステムのうちの1つにあてられたものである場合に、割込みメッセージまたは割込み通知が生成される。副オペレーティングシステムが次に共通プログラムによってスケジューリングされるときに、そのメッセージまたは通知が、この副オペレーティングシステムに渡され、共通プログラムが、その割込みサービスルーチンを呼び出して、その割込みをサービスする。
したがって、副オペレーティングシステムは、割込み発生時に、いかなる形でも主オペレーティングシステム(または、一般的に、より重要性の高い副オペレーティングシステム)に取って代わる(プリエンプトする)ことができない。というのは、すべてが、まず主オペレーティングシステムによって処理され、主オペレーティングシステムが実行を終了し、それらの宛先である副オペレーティングシステムがスケジューリングされた後に、その副オペレーティングシステムに通知されるだけであるからである。
したがって、そのような割込みの処理は、主オペレーティングシステムでクリティカルタスクが発生しなくなるまで延期される。しかし、そのような割込みが最終的に実施されるときに、副オペレーティングシステムのルーチンが、実質的に変更されない形で動作することができ、その結果、挙動が、(遅延を除いて)副オペレーティングシステムの期待する通りになる。
他の態様、実施形態、および好ましい特徴は、対応する利益と共に、次の説明、請求項、および図面から明白になる。
添付図面を参照して、本発明の実施形態を例示的に説明する。
概説
[システムハードウェア]
本システムを適用可能なコンピュータシステム100は、Intel Corporation社から入手可能なPentium 4(商標)CPUまたはMotorola社から入手可能なPowerPC CPU(本実施形態は、この両方で実現されている)などの中央処理装置(CPU)102を含む。CPU102は、システムバス104(制御バス、データバス、およびアドレスバスを含む)を介して、読取専用メモリ(ROM)チップ106と、ランダムアクセスメモリ(RAM)チップ(108)の1つまたは複数のバンクと、ディスクコントローラデバイス110(例えば、フロッピーディスクドライブ、ハードディスクドライブ、およびDVDドライブなどの追加リムーバブルメディアドライブに接続されたIDEコントローラまたはSCSIコントローラ)と、1つまたは複数の入出力ポート(112)(例えば、1つもしくは複数のUSBポートコントローラおよび/またはプリンタなどに接続するためのパラレルポートコントローラ)と、外付けまたは内蔵の周辺デバイスへのバス接続のための拡張バス114(例えば、PCIバス)と、他のシステムチップ116(例えば、グラフィックスデバイスおよびサウンドデバイス)とに結合されている。このタイプのコンピュータの例が、パーソナルコンピュータ(PC)およびワークステーションである。しかし、メインフレーム、制御システム内の組込みマイクロコンピュータ、およびPDA(この場合に、ディスクドライブコントローラなど、示されたデバイスの一部が存在しない場合がある)などの他のコンピューティングデバイスへの本発明の適用も、本明細書で開示する。
[ソフトウェアの管理]
図2aを参照すると、図1のコンピュータ100は、使用中に、オペレーティングシステムカーネル202(図1に示された他のデバイスへのCPUによるアクセスを可能にする出力ルーチンを提供する)と、オペレーティングシステムユーザインターフェースレイヤまたはオペレーティングシステムプレゼンテーションレイヤ204(X Windowsなど)と、ミドルウェアレイヤ206(例えば、TCP/IPスタックなどのネットワーキングソフトウェアおよびプロトコルを提供する)とを含む常駐プログラム、及び、アプリケーション208a,208bを動作させる。アプリケーション208aおよび208bは、オペレーティングシステムカーネル202を形成するAPIルーチンへの呼出しを行うことによって動作する。
オペレーティングシステムカーネルは、複数のタスク、特に次のものを有する。
・ スケジューリング(すなわち、動作中の異なるアプリケーションの間でのCPUおよび関連リソースの共用)と、
・ メモリ管理(すなわち、各タスクへのメモリの割振り、および必要な場合の、メモリアドオンからディスクドライブへのデータおよびプログラムのスワップ)と、
・ ファイルシステムの提供と、
・ デバイスへのアクセスの提供(通常、ドライバを介する)と、
・ 割込み処理と、
・ アプリケーションがシステムリソースおよびユーザと相互作用することを可能にするアプリケーションプログラミングインターフェースの提供。
カーネルは、Unixに関するいわゆる「モノリシックカーネル」とすることができ、この場合に、デバイスドライバが、カーネル自体の一部を形成する。代替案では、カーネルを、Chorusに関する「マイクロカーネル」とすることができ、この場合、デバイスドライバは、カーネルと別々である。
使用に際して、コンピュータ100が始動するとき、ROM 106にストアされたブートストラッププログラムが、ディスクコントローラ110にアクセスして、オペレーティングシステムのファイル処理部分をディスク上の永久ストレージからRAM 108に読み取り、次に、オペレーティングシステムの残りをRAM 108のある領域にロードする。次に、オペレーティングシステムは、ディスクコントローラ110を介してディスクドライブからすべてのアプリケーションを読み取り、それぞれのためにRAM 108内に空間を割り振り、その割り振られたメモリ空間に各アプリケーションをストアする。
アプリケーションの動作中に、オペレーティングシステムのスケジューラ部分が、CPUの使用を異なるアプリケーションの間で分割し、各アプリケーションがスケジューリングポリシに従ってプロセッサの時間を共用することを可能にする。スケジューラは、頻繁には使用されていないアプリケーションまたはデータを「スワップアウトする」(すなわち、これらをRAM 108から除去して空間を解放し、これらをディスクにストアする)ことによって、メモリリソースの使用も管理する。
最後に、アプリケーションプログラミングインターフェース(API)を構成するルーチンが、アプリケーションから呼び出されて、入力および出力などの機能を実行し、オペレーティングシステムの割込み処理ルーチンが、割込みおよびイベントに応答する。
好ましい実施形態の原理の概要
好ましい実施形態では、コンピュータ100で使用される各オペレーティングシステム201および202がわずかに書き直され、新しい低水準プログラム400(本明細書では「ハードウェアリソースディスパッチャ」と称し、オペレーティングシステムのカーネルではないが、時々「ナノカーネル」と称する)が作成される。ハードウェアリソースディスパッチャ400は、プロセッサと相互作用するので、特定のタイプのCPU 102に固有である。修正変更されたオペレーティングシステム201および202の版も、下で明らかになる理由から、ハードウェアに固有の版である。
ハードウェアリソースディスパッチャ400自体は、オペレーティングシステムではない。ハードウェアリソースディスパッチャ400は、アプリケーションプログラムと一切相互作用せず、非常に限られた機能性を有する。ハードウェアリソースディスパッチャ400は、仮想計算機またはエミュレータではなく、処理のほとんどをオペレーティングシステム自体に委ね、プロセッサ上でネイティブコードを動作させるが、協力するようにオペレーティングシステムを修正することを必要とする。ハードウェアリソースディスパッチャ400は、次の基本機能を実行する。
・ 複数のオペレーティングシステムのそれぞれをロードし、始動することと、
・ メモリおよび他のシステムリソースをオペレーティングシステムのそれぞれに割り振ることと、
・ 異なるオペレーティングシステムの動作をスケジューリングする(すなわち、CPU時間をそれらの間で分割し、それらの間での切替を管理する)ことと、
・ オペレーティングシステムによって共用される必要があるシステムデバイスへの間接アクセスの「仮想化されたデバイス」メソッドを提供する(デバイスを「仮想化する」)ことと、
・ 異なるオペレーティングシステムで動作するアプリケーションが互いに通信できるようにするために、オペレーティングシステムの間の通信リンクを提供すること。
各オペレーティングシステムは、この実施形態によって、同等には扱われない。そうではなく、複数のオペレーティングシステムのうちの1つが、「クリティカル」オペレーティングシステムとして選択され(これは、リアルタイムオペレーティングシステムになる)、1つまたは複数の他のオペレーティングシステムのそれぞれが、「非クリティカル」または「副」オペレーティングシステムとして扱われる(これは、Linuxなどの各汎用オペレーティングシステムになる)。
ハードウェアリソースディスパッチャは、設計されるときに、できる限り多くのシステムデバイスを複数のオペレーティングシステムのうちの一方または他方に排他的に静的に割り振ることを可能とするために、使用可能なシステムリソース(すなわち、デバイスおよびメモリ)をリストしたデータ構造体(例えば、テーブル)を与えられる。
例えば、パラレルプリンタポートを、プリンタ出力を作ることを必要とするアプリケーションをしばしば動作させる汎用オペレーティングシステム202に静的に割り振ることができる。その一方で、ISDNデジタル回線アダプタポートを、通信のためにリアルタイムオペレーティングシステム201に永久的に割り振ることができる。この可能な所に必ずデバイスを静的に割り振ることは、各オペレーティングシステムが、ハードウェアリソースディスパッチャを呼び出す必要なしに、静的に割り振られたデバイスにアクセスするのにその既存のドライバを使用できることを意味する。したがって、そのようなデバイスにアクセスする際の実行速度の損失(仮想計算機またはエミュレータとして操作される場合のような)はない。
共用されなければならないシステムデバイスの場合に、ハードウェアリソースディスパッチャが、非クリティカルオペレーティングシステムによるデバイスの使用を仮想化し、クリティカルオペレーティングシステムと共に提供されるドライバを利用してアクセスを実行する。同様に、割込み処理に関して、割込みは、クリティカルオペレーティングシステム割込み処理ルーチンに渡され、この割込み処理ルーチンは、その割込みを処理する(クリティカルオペレーティングシステム宛である場合)か、非クリティカルオペレーティングシステムへの転送のためにハードウェアリソースディスパッチャを介して渡す(非クリティカルオペレーティングシステム宛である場合)かのいずれかを行う。
ブート時に、ハードウェアリソースディスパッチャが、まずロードされ、次に、所定のシーケンス(クリティカルオペレーティングシステムから始め、1つまたは複数の各副オペレーティングシステムが続く)でオペレーティングシステムのそれぞれをロードする。クリティカルオペレーティングシステムは、それが必要とするリソースをテーブルから順番に割り振られ、そのシステムがその中で動作する固定されたメモリ空間を有する。次に、各副オペレーティングシステムが、使用可能な残りのリソースから、それが必要とするリソースおよびメモリ空間を順番に割り振られる。
したがって、この実施形態によれば、オペレーティングシステムによって使用されるリソースが、各オペレーティングシステムにそれ自体のメモリ空間を割り振ることと、各オペレーティングシステムへの排他的なデバイスの静的割振りを提供することによって、物理的にできる限り分離され、共用が必須のデバイスだけが共用される。
動作中に、ハードウェアリソースディスパッチャスケジューラは、クリティカルオペレーティングシステムが、そのタスクを終了するまで動作することを許容し、その後、次の割込みまたはイベントが発生するまで、各非クリティカルオペレーティングシステムに順番に制御を渡す。
したがって、この実施形態は、クリティカルオペレーティングシステムの動作が事実上変更されない(クリティカルオペレーティングシステムがそのオリジナルドライバを使用し、すべての割込み処理およびイベント処理への最初のアクセスを有するので)マルチオペレーティングシステム環境を可能にする。副オペレーティングシステムは、残りのプロセッサ時間内で効率的に動作することができる。というのは、大抵の場合、副オペレーティングシステムが、それ自体のネイティブドライバを使用し、システムデバイスの多くへの排他的アクセスを有するからである。最後に、ハードウェアリソースディスパッチャ自体は、限られた機能だけを処理するので、小さいプログラムにすることができ、その結果、システムリソースが節約される。
この好ましい実施形態は、特定のコンピュータ100に既に適合されている標準的な市販オペレーティングシステムに対する限られた変更だけを用いるので、作成および保守が経済的でもある。さらに、オペレーティングシステムに対する変更は、割込み処理などのアーキテクチャ固有ファイル処理の問題と、特定のタイプのコンピュータ100とインターフェースし、オペレーティングシステムの残りほど頻繁に変更される可能性が低い初期化時の構成とに制限されるので、複数オペレーティングシステムの形で働くように同一のオペレーティングシステムの新版を適合させる作業は、ほとんどまたはまったくない可能性がある。
好ましい実施形態の詳細な説明
この実施形態では、コンピュータ100が、Intel 386ファミリプロセッサ(例えば、Pentiumプロセッサ)およびMotorola PowerPC750(Reduced Instruction Set Computer、すなわち“RISC”)コンピュータであった(ステップ302)。クリティカルオペレーティングシステム201は、C5オペレーティングシステム(オープンソースで入手可能であり、http://www.jaluna.comから無料でダウンロードされる、ChorusOSシステムの第5世代のオープンソース版であるJaluna−1のリアルタイムマイクロカーネル)であった。
ステップ306で、ChorusOSオペレーティングシステムカーネル201を、複数オペレーティングシステムモードで動作するように修正するが、これは、新しいプラットフォームへのs移植と同一の形で扱われる(すなわち、同一CPUを有するが異なるシステムデバイスを有する新しいコンピュータでの実行を可能にするために新しいBoard Support Packageを記述する)。ブートおよび初期化のシーケンスを変更して、リアルタイムオペレーティングシステムを、それ自体を始動するのではなく、それに割り振られたメモリ空間内でハードウェアリソースディスパッチャによって始動できるようにする。初期化シーケンスのハードウェアプローブステージを変更して、クリティカルオペレーティングシステムが、他の副システムに割り当てられるハードウェアリソースにアクセスしないようにする。クリティカルオペレーティングシステムは、ハードウェアリソースディスパッチャから静的ハードウェア割振りテーブルを読み取って、それが使用可能なデバイスを検出する。
トラップ呼出し2012をクリティカルオペレーティングシステムに追加して、状態を検出し、それに応答して、あるアクションを要求する。本明細書でのトラップ呼出しは、プロセッサに現在のコンテキスト(例えば、レジスタの状態)を保存させ、新しいコンテキストをロードさせる呼出しを意味する。したがって、仮想メモリアドレッシングが使用される場合に、アドレスポインタが変更される。例えば、リアルタイムオペレーティングシステム201が、エンドポイントに達し(プロセッサリソースを要求するのをやめる)ときに、制御をハードウェアリソースディスパッチャに戻し、「idle(アイドル)」トラップ呼出しを発行して、副オペレーティングシステムを始動することができる。多くのプロセッサが、「halt(ホールト)」命令を有する。いくつかの場合に、スーパーバイザレベルコード(例えば、アプリケーションではなくオペレーティングシステム)だけに、そのような「halt」命令を含めることができる。この実施形態では、すべてのオペレーティングシステムが、「halt」命令を除去し、これらを「idle」ルーチン(例えば、実行スレッド)に置換するように書き直され、この「idle」ルーチンは、呼び出されたときに、「idle」トラップ呼出しを発行する。
Board Support Packageのいくつかのドライバは、特に、ハードウェアリソースディスパッチャが副オペレーティングシステムのために共用されるデバイスを仮想化するのを支援する。
追加の「仮想」ドライバ2014が追加され、この仮想ドライバ2014は、オペレーティングシステムにとっては、入出力バスへのアクセスを提供し、データをバスに書き込むことを可能にするように見える。実際には、仮想バスドライバ2014は、通信媒体としてメモリを使用し、あるプライベートメモリをエクスポートし(入力データ用)、他のシステムによってエクスポートされたメモリをインポートする(出力データ用)。このようにして、オペレーティングシステム201(またはそのオペレーティングシステムで動作するアプリケーション)が、実際の入出力バスによって接続された別々の機械で動作している2つのオペレーティングシステムであるかのように、別のオペレーティングシステム(またはそのオペレーティングシステムで動作するアプリケーション)にデータを渡すことができる。
副オペレーティングシステム202は、カーネルバージョン2.4.18を有する(ステップ308)Linuxとして選択された(ステップ308)。
ステップ310で、副オペレーティングシステムカーネル202を変更して、新しいハードウェアアーキテクチャとして扱われる複数オペレーティングシステム環境で機能することを可能にする。ステップ306と同様に、ブートおよび初期化のシーケンスを変更して、副オペレーティングシステムをハードウェアリソースディスパッチャによって始動することを可能にし、ハードウェアリソースディスパッチャテーブルで指定される他のシステムに割り当てられるハードウェアリソースにアクセスしないようにする。ステップ306と同様に、ハードウェアリソースディスパッチャに制御を渡すために、トラップ呼出し2022を追加する。
共用されるシステムデバイスのネイティブドライバは、ハードウェアリソースディスパッチャによって仮想化されたデバイス(割込みコントローラ、入出力バスブリッジ、システムタイマ、およびリアルタイムクロック)を扱う新しいドライバ2028によって置換される。これらのドライバは、コンピュータ100のそれぞれのデバイスに対するある動作を実行するために、ハードウェアリソースディスパッチャの仮想デバイスハンドラ416への呼出しを実行する。ハードウェアリソースディスパッチャの各そのような仮想デバイスハンドラ416は、クリティカルオペレーティングシステム内の「ピア」ドライバルーチンと対にされ、このピアドライバルーチンは、システムデバイスと直接に相互作用するように構成される。したがって、仮想デバイスハンドラへの呼出しは、実際のデバイスアクセスを行うために、その仮想化されたデバイス用のクリティカルシステム内のピアドライバまで中継される。ステップ306と同様に、仮想入出力バスの読み書きドライバ2024が、オペレーティングシステム間通信を可能にするために設けられる。
副オペレーティングシステムの割込みサービスルーチンを変更して、それぞれが実際の割込みまたはイベントではなく、それぞれの仮想割込み(ハードウェアリソースディスパッチャの割込みハンドラルーチン412によって発行される呼出しの形の)に応答する仮想割込みサービスルーチン2026を設ける。副オペレーティングシステムのルーチン(割込みサービスルーチンを含む)も、ハードウェア割込みのマスク(少なくとも、すべての例外クリティカル動作の)を除去するように変更される。したがって、この形で、副オペレーティングシステム202、・・・が、クリティカルオペレーティングシステム201によってプリエンプトされる。言い換えると、仮想割込みに対する副オペレーティングシステム応答自体に、クリティカルオペレーティングシステム201に関する実際の割込みによって割り込むことができる。これには、通常、次のものが含まれる。
・ イベントのマスク/マスク解除(プロセッサレベルでの割込み)と、
・ イベントマスク状況の保存/復元と、
・ 割込みソース(割込みコントローラデバイス)の識別と、
・ ソース(割込みコントローラデバイス)レベルでの割込みのマスキング/マスク解除。
新しい仮想デバイスドライバ2028が、共用されるハードウェアデバイス(入出力バスブリッジ、システムコンソール、システムタイマ、およびリアルタイムクロック)へのアクセスのために追加される。これらのドライバは、コンピュータ100のそれぞれのデバイスにデータを書き込む、またはそこからデータを読み取るために、ハードウェアリソースディスパッチャの仮想デバイスハンドラ416への呼出しを実行する。
これをもたらすために、Linuxカーネル207が、この実施形態で、少数の変更されたファイルを用いて新しい仮想ハードウェアリソースディスパッチャアーキテクチャサブツリー(I−386変形およびPowerPC変形のnk−i386およびnk−ppc)を追加することによって変更される。未変更のファイルは、その既存の形で再利用される。オリジナルサブツリーは、保存されるが、使用されない。
ステップ312で、ハードウェアリソースディスパッチャ400を記述する。ハードウェアリソースディスパッチャに、次の機能(図4に示された)のルーチンを提供するコードが含まれる。
・ それ自体をブートし初期化する機能(402)と、
・ 各リソースが一意に割り当てられるオペレーティングシステムを示す割振りエントリとハードウェアリソース(ポートなどのデバイス)のリストをストアするテーブルをストアする機能(403)と、
・ ハードウェアリソースディスパッチャ割振りテーブルを完了する、クリティカルオペレーティングシステムをブートし、初期化する機能(404)と、
・ 副オペレーティングシステムをブートし、初期化する機能(406)と、
・ オペレーティングシステムの間で切り替える機能(408)と、
・ オペレーティングシステムの間でスケジューリングする機能(410)と、
・ 割込みを処理する(リアルタイムオペレーティングシステム割込みサービスルーチンを使用し、必要な場合に副オペレーティングシステムの仮想割込みサービスルーチンにデータを供給する)機能(412)と、
・ オペレーティングシステムのそれぞれからのトラップ呼出しを処理する機能(414)と、
・ 副オペレーティングシステムから共用されるデバイスへのアクセスを処理する機能(416)と、
・ 仮想入出力バスでのオペレーティングシステム間通信を処理する機能(418)。
もう1つの実施形態(下で説明する)で、ハードウェアリソースディスパッチャは、システムデバッギングフレームワークも提供することができる。
[オペレーティングシステムスイッチャ408]
あるオペレーティングシステムから別のオペレーティングシステムに切り替えるために、オペレーティングシステムスイッチャ408は、現在実行中のオペレーティングシステムの「コンテキスト」(レジスタ値など、状態変数の組の現在の値)を保存し、別のオペレーティングシステムのストアされたコンテキストを復元し、それが止まった所から実行を再開するためにその別のオペレーティングシステムを呼び出すように構成されている。したがって、プロセッサがメモリのセグメントと、仮想アドレッシング技法または間接アドレッシング技法とを使用する場合に、現在のメモリ空間へのポインタをストアしたレジスタまたはデータ構造体が、スワップされる。例えば、オペレーティングシステムは、それぞれ、そのようなメモリ空間へのポインタ値を含むコンテキストによって定義される、異なるそのようなメモリ空間内で動作する。
詳細に言うと、スイッチャは、次を提供する。
・ 現在のオペレーティングシステムがアイドルになるときの、現在動作しているオペレーティングシステムから次にスケジューリングされたオペレーティングシステムへの明示的な切替(例えば、トラップ呼出し)と、
・ ハードウェア割込みが発生したときの、副オペレーティングシステムからクリティカルオペレーティングシステムへの暗黙の切替。
切替は、下で説明するように、トラップ呼出し、実際の割込み、または仮想割込みの際に発生する可能性がある。
[スケジューラ410]
スケジューラ410は、あるオペレーティングシステムから出た後に、次にどの副オペレーティングシステム(複数が存在する場合に)に切り替えるかを選択することによって、使用可能な処理時間の一部を各オペレーティングシステムに割り振る。この実施形態では、各副オペレーティングシステムが、固定優先順位スケジューリングに基づいて選択される。時分割またはプロセッサ時間の保証された最小限のパーセンテージに基づく指定を可能にする他の実施形態も、本明細書で企図されている。しかし、どの場合でも、クリティカルオペレーティングシステムは、アイドル状態であるときに限ってプリエンプトされる。
他の実施形態では、クリティカルシステムでまだ動作中のタスクより優先順位の高いタスクを実行するためにすべての副オペレーティングシステムがCPUへのあるアクセスをできることを許可するために、クリティカルオペレーティングシステムが、いつそれをプリエンプトできるかを、スケジューラ410に明示的に知らせることができる。したがって、1つの例では、クリティカルオペレーティングシステムの割込みサービスルーチンをプリエンプトすることができず、その結果、クリティカルオペレーティングシステムは、外部イベントまたはリアルタイムクロックからのタイミング信号に必ず応答できるようになり、リアルタイム動作が維持される。
[仮想化されたプロセッサ例外の処理]
ハードウェアリソースディスパッチャは、次のように、プロセッサ例外(例えば、CPU割込みまたはコプロセッサ割込み)を処理する機構を提供するように構成される。
・ 第1に、クリティカルオペレーティングシステムを介してプロセッサ例外をインターセプトし、
・ 第2に、対応する仮想例外を1つまたは複数の副オペレーティングシステムにポストし、そのデータをストアし、スケジューラがその副オペレーティングシステムを次に呼び出すときに、その副オペレーティングシステム内の対応する仮想割込みサービスルーチン2026を呼び出し、
・ 第3に、副オペレーティングシステム内からのすべての保留中の仮想例外をマスクするかマスクを解除する。
仮想化された例外は、通常、次の2つの異なる目的に使用される。
・ 第1に、ハードウェアデバイス割込み(非同期プロセッサ例外として配送される)を副オペレーティングシステムに転送するため、
・ 第2に、オペレーティングシステム間クロス割込みすなわち、あるシステムによって別の割込みのために生成された割込み(非同期例外として配送される)を実装するため。
[トラップ呼出しハンドラ414]
トラップ呼出しハンドラの動作は、次の説明から明らかになる。その主目的は、スケジューラおよびスイッチャが、第1のオペレーティングシステムが停止した(したがって、CPUリソースを必要としない)ときに別のオペレーティングシステムに変更することを可能にすることである。追加の役割は、後の実施形態に関して説明するデバッギングで使用するためにシステムコンソールなどのハードウェアリソースディスパッチャサービスを呼び出すことである。
[仮想化されたデバイス416]
上で示したように、共用されるデバイス(例えば、割込みコントローラ、バスブリッジ、システムタイマ、リアルタイムクロック)ごとに、各オペレーティングシステムがデバイスドライバを提供し、そのデバイスに関するピアレベルドライバの組を形成する。リアルタイムオペレーティングシステムは、デバイスに実際にアクセスするのに使用されるドライバを提供し、他のオペレーティングシステムは、仮想デバイスドライバを提供する。
ハードウェアリソースディスパッチャの共用されるデバイスハンドラ416は、各デバイスのすべてのピアデバイスドライバによるアクセスのための、デバイスごとのストアされたデータ構造体を提供する。デバイスがアクセスされるべきときまたはアクセスされたときに、デバイスドライバは、アクセスの詳細を用いて、対応するデータ構造体にストアされたデータを更新する。ピアドライバは、クロス割込み(上で述べた)を使用して、データ構造体が更新されたばかりであることを他のピアドライバに通知するためにイベントをシグナリングする。
割込みコントローラデバイスにアクセスするためのドライバは、次のように、ハードウェア割込みを処理するために上で述べた仮想化された例外機構を使用する。
・ クリティカルオペレーティングシステムデバイスドライバが、ハードウェア割込みを処理し、これらを、仮想化された例外として副ピアドライバに転送し、
・ 副オペレーティングシステムが、上で述べた仮想化された例外のマスクルーチンおよびマスク解除ルーチンを使用することによって、割込みをイネーブルおよびディスエーブルする。
入出力バスおよびそのブリッジは、それらに接続されたデバイスのすべてが同一のオペレーティングシステムに割り振られていない場合に限って、共用されなければならない。したがって、デバイスを割り振る際に、可能な範囲まで、同一の入出力バスに接続されたデバイスが、同一のオペレーティングシステムに割り振られる。共用が必要な場合に、リソース割振りテーブル404に、どのオペレーティングシステムがどのリソースを有するかを示すために、バス上のリソース(アドレス空間、割込み線、および入出力ポート)の割振りを示す記述子データがストアされる。
[実施形態の実装]
最後に、ステップ314で、ハードウェアリソースディスパッチャおよびオペレーティングシステムのコードが、コンピュータ100と共に供給される配布可能バイナリコンピュータプログラム製品としてコンパイルされる。
本発明の一態様に従って供給できる製品は、ユーザが、使用される異なるオペレーティングシステムを選択し、各オペレーティングシステムの異なるアプリケーションをビルドし、選択し、配布可能な製品にアプリケーションおよびオペレーティングシステムを組み込み、オペレーティングシステムのブートおよびアプリケーションの実行可能バイナリの起動を提供することを可能にするコンピュータプログラムを含む、開発環境製品である。これは、www.jaluna.comから入手可能なC5開発環境に基づき、これに似ている。
[ブートおよび初期化の間の実施形態の動作]
図5を参照すると、本発明によるブートプロセスおよび初期化プロセスは、次のように実行される。
ROM 106にストアされたブートストラッピングプログラム(「trampoline」)4022が、電力が始めて供給されるときに実行され、プログラム4024を始動し、このプログラム4024が、ハードウェアリソースディスパッチャプログラム400の残りをメモリにインストールし、始動し、引数として、システムイメージ構成を記述したデータ構造体(下で説明する)を渡す。
ハードウェアリソースディスパッチャは、システムコンソールに使用することができるシリアル回線を初期化する。次に、ハードウェアリソースディスパッチャは、クリティカルオペレーティングシステムから始めて、各オペレーティングシステムのメモリ空間(オペレーティングシステム環境)を順番に割り振る。したがって、ハードウェアリソースディスパッチャは、第2レベルシステムカーネルブートローダとして働く。
次に、各オペレーティングシステムカーネルが、それ自体の初期化フェーズをすべて行い、リソース割振りテーブル404に残っているリソースの中でそのオペレーティングシステムに排他的なリソースを選択し、その最初のサービスおよびアプリケーションを始動する。
図6に、システムイメージを形成するメモリアドレス割振りの例を示す。ハードウェアリソースディスパッチャおよびオペレーティングシステムがコンパイルされるときに、メモリ内の位置が割り振られる。メモリ内のこれらの位置の組が、図6に示されたシステムイメージを定義する。システムイメージに、ハードウェアリソースディスパッチャが構成されるメモリの第1バンク602と、リアルタイムオペレーティングシステムが構成されるメモリの第2バンク604と、副オペレーティングシステムが構成されるメモリの第3バンク606と、この実施形態では、副オペレーティングシステム(Linux)のルートファイルシステムを含むRAMディスクが構成されるメモリの第4バンク608とが含まれる。
このシステムイメージは、永続ストレージ(例えば、携帯電話機またはPBXなどの通常のリアルタイムデバイスでは読取専用メモリ)にストアされる。メモリの残りのバンクは、各オペレーティングシステムにその環境として割り振るのに使用可能であり、この環境内で、各オペレーティングシステムがアプリケーションをロードし、動作させることができる。
[オペレーティングシステムコンテキスト用のメモリの割振り]
ブートされている間に、各オペレーティングシステムは、それ自体の構成が必要とする総サイズを満足するために、相補的なメモリを割り振る。オペレーティングシステムに割り振られたならば、メモリのバンクは、そのオペレーティングシステム自体の物理メモリ管理方式を使用して管理される。他のすべてのメモリは、オペレーティングシステムによって無視される。
[仮想メモリ割振り]
各オペレーティングシステムは、オペレーティングシステムが互いにまたはハードウェアリソースディスパッチャと干渉できないことを保証するために、別々の仮想メモリ空間を割り振られる。オペレーティングシステムのそれぞれのユーザアドレス空間(すなわち範囲)およびスーパーバイザアドレス空間(すなわち範囲)は、それぞれ、異なるメモリ管理ユニット(MMU)コンテキスト識別子(ID)を割り振られ、このMMUコンテキストIDが、オーバーラップするアドレスを有する異なる仮想メモリアドレス空間の区別を可能にする。MMUコンテキストIDは、各オペレーティングシステムがコンパイルされるとき(図3のステップ314)に、各オペレーティングシステムに割り当てられる。
この解決策は、ハードウェアリソースディスパッチャが異なるオペレーティングシステムの間で切り替えるときに、追加の時間を要する変換キャッシュ(TLB)のフラッシュの必要をなくす。その代わりに、異なるオペレーティングシステムの間の切替は、現在機能するオペレーティングシステムのMMUコンテキストIDをストアし、切り替えられる2つのオペレーティングシステムの以前にストアされたMMUコンテキストIDをリコールすることによって達成される。
[入出力デバイスの割振り]
上で示したように、割振りテーブル404は、どのデバイスが各オペレーティングシステムに一意に割り振られているかを示す。さらに、テーブル404は、どの入出力リソース(直接メモリアクセス(DMA)デバイス、入出力ポート、割込みなど)がそのようなデバイスに排他的に割り振られており、したがって、衝突なしのこれらのリソースの直接使用が可能であるかを示す。通常、多数のデバイスが複製され、したがって、この形で、潜在的な衝突を実質的に減らすことが可能である。
分配は、オペレーティングシステム構成方式(例えば、C5の場合に、デバイスツリーで指定されたデバイス)に基づく。デバイスは、ブート時に、ブートの順序でオペレーティングシステムに割り振られ、その結果、クリティカルオペレーティングシステムが、まず、テーブル404内の使用可能なデバイスを最初に選択し、次に、副オペレーティングシステムが、残っているものの中で割振りを受け取る。各オペレーティングシステムは、初期化時に、これらのデバイスの存在を検出し、ハードウェアリソースディスパッチャからの相互作用なしで、それらのためのネイティブドライバを使用する。
[副オペレーティングシステムの「ホット」リブート]
現在の実施形態によれば、他のオペレーティングシステムが動作を継続している間に、副オペレーティングシステムをリブートする(例えば、クラッシュのゆえに)ことが可能である。システムリソースの分離のゆえに、副オペレーティングシステムのクラッシュは、クリティカルオペレーティングシステム(または他の副オペレーティングシステム)の進行中の動作に干渉せず、副オペレーティングシステムのリブートも、これらに干渉しない。
この実施形態では、ハードウェアリソースディスパッチャへのシステムの「停止」トラップ呼出しおよび「始動」トラップ呼出しが、クリティカルオペレーティングシステム内からの副オペレーティングシステムのシャットダウンおよび再始動を支援する。さらに、ハードウェアリソースディスパッチャは、オリジナルシステムイメージのコピーを、ブート時に、ハードウェアリソースディスパッチャに割り振られたメモリ内の永続メモリに保存する。一例として、この実施形態のホット再始動は、次のように管理される。
最初のブートアップ時に、ハードウェアリソースディスパッチャが、副オペレーティングシステムメモリイメージのコピーを保存する。
クリティカルオペレーティングシステムに、副オペレーティングシステムの機能を周期的に監視する(例えば、副オペレーティングシステムの継続動作を検査するために、タイムアウトを設定し、副オペレーティングシステム内で動作するピアドライバによってトリガされるイベントを待つことによって)ソフトウェアウォッチドックドライバルーチンが含まれる。
副オペレーティングシステムが障害を発生したか停止したことをクリティカルオペレーティングシステムが検出した場合に、クリティカルオペレーティングシステムは、ハードウェアリソースディスパッチャへの「停止」トラップ呼出しおよびその後の「始動」トラップ呼出し(副オペレーティングシステムの)をトリガする。
次に、ハードウェアリソースディスパッチャが、副オペレーティングシステムイメージの保存されたコピーを復元し、メモリからリブートして、再始動する。実施形態のテストで、Linux副オペレーティングシステムを、ロックアップから数秒以内にリブートできることがわかった。他の点で、ホット再始動は、例えば次の文献に記載のように、Chorusオペレーティングシステムで使用可能なホット再始動に基づく。
「Fast Error Recovery in CHORUS/OS. The Hot−Restart Technology」、Abrossimov,F.Hermann、J.C.Hugly他、Chorus Systems Inc.Technical Report、1996年8月、14頁、http://www.jaluna.com/developer/papers/CSI−TR−96−34.pdfから入手可能。
[ランタイム動作]
インストールおよびブートの後のこの実施形態の動作を、これから詳細に説明する。
ブートされ、初期化された後に、リアルタイムオペレーティングシステムは、1つまたは複数のアプリケーション207(例えば、UDP/IPスタック。UDP/IPは、ユニバーサルデータグラムプロトコル/インターネットプロトコルを表す)を動作させており、副オペレーティングシステムは、複数のアプリケーション208aおよび208b(例えば、ワードプロセッサおよびスプレッドシート)を動作させている。リアルタイムオペレーティングシステムマイクロカーネル201および副オペレーティングシステムカーネル202は、次を含むハードウェアリソースディスパッチャインターフェースを介してハードウェアリソースディスパッチャと通信する。
・ オペレーティングシステムコンテキスト(すなわち、そのオペレーティングシステムに切り替えるために保存され、復元される必要がある状態変数の組)およびハードウェアリポジトリを表すデータ構造体と、
・ オペレーティングシステム環境で実行される機能の組と、
・ ハードウェアリソースディスパッチャ環境で実行されるトラップ呼出しルーチンの組。
両方のオペレーティングシステムがプロセッサ時間を必要としない(例えば、両方が「待ち」状態に達した)場合に、ハードウェアリソースディスパッチャ400は、クリティカルオペレーティングシステムのアイドルスレッドに切り替え、このスレッドで割込みまたはイベントを待つ。したがって、割込みを、まずクリティカルオペレーティングシステムに切り替える必要なしに、クリティカルオペレーティングシステムのサービスルーチンによって即座に処理することができる。
ある時点で、割込みまたはイベントが発生する。例えば、パケットが、データポートで受信され、UDP/IPスタックを実行するリアルタイムオペレーティングシステムによってこれを処理できるようにするための割込みが引き起こされる。その代わりに、ユーザが、キーボードまたはマウスを操作する場合があり、これによって、ワードプロセッシングアプリケーション208との相互作用のために副オペレーティングシステム202のGUIを操作する割込みが引き起こされる。その代わりに、システムクロックが、所定の時間が経過し、アプリケーションが再実行を開始しなければならないか、オペレーティングシステム機能を実行しなければならないことを示す場合がある。
その後、クリティカルオペレーティングシステムのサービスルーチンが、下で説明するように、その割込みにサービスする。
[割込みおよびイベントの処理]
まだクリティカルオペレーティングシステム内でない場合に、ハードウェアリソースディスパッチャの割込みハンドラ412が、オペレーティングシステムスイッチャ408を呼び出して、クリティカルオペレーティングシステムに切り替え、その後、割込みハンドラルーチン412を呼び出して、クリティカルオペレーティングシステム201の割込みサービスルーチン(ISR)を呼び出す。その割込みが、クリティカルオペレーティングシステムに一意に割り当てられたデバイスからのものであるため、または共用されるデバイスからのものであり、ある所定の値を有するため、クリティカルオペレーティングシステムを示すことが意図されている場合、クリティカルオペレーティングシステムISRが、その割込みを処理するのに必要な処置を講ずる。そうでない場合には、制御が、ハードウェアリソースディスパッチャに渡される。
[クリティカルオペレーティングシステムから副オペレーティングシステムへの切り替え]
図7を参照すると、この例では、システムが、クリティカルオペレーティングシステム201で動作するアプリケーション207aのスレッド702を実行している。
割込みが発生した場合に、クリティカルオペレーティングシステムの割込みサービスルーチン704が、割込みサービスを実行する。終了時に、制御が、スレッド702およびクリティカルオペレーティングシステム201のスケジューラによって実行される他のすべてのスレッドに渡される。すべてのスレッドの処理が完了したときに、クリティカルオペレーティングシステムは、実行を終了しており、その「idle」スレッドをスケジューリングする。したがって、クリティカルオペレーティングシステムの「idle」トラップルーチンが、「idle」トラップ呼出しをハードウェアリソースディスパッチャ400に発行する。次に、ハードウェアリソースディスパッチャが、次を行うルーチンを実行する。
・ 割込みハンドラ412が、現在、あるストアされた仮想割込みを有する場合に、これらの仮想割込みが、割込みハンドラ412によって副オペレーティングシステムに転送される。
・ ハードウェアリソースディスパッチャオペレーティングシステムスケジューラ410が、実行すべき副オペレーティングシステム202を選択する。次に、OSスイッチャ408が、クリティカルOSコンテキストストレージ領域706に現在のコンテキスト(通常は、プロセッサMMUレジスタ、プロセッサ状況レジスタ、命令ポインタ、およびスタックポインタ)を保存する。次に、OSスイッチャ408が、副オペレーティングシステム202のストアされた実行コンテキスト708を取り出し、これを、関係するレジスタに書き込む。
・ 関係する副OSに関する仮想割込みがある場合に、割込みハンドラ412は、副オペレーティングシステム内の関連する割込みサービスルーチン710を呼び出し、この割込みサービスルーチン710が、その割込みにサービスし、その後、完了時に、副オペレーティングシステムのスレッド712の実行の、それが止まった場所に戻る。
割込みハンドラ412が、現在、保留中の割込みを有しない場合には、ハードウェアリソースディスパッチャオペレーティングスイッチャ408が、復元されたオペレーティングシステムコンテキスト内のストアされたプログラムカウンタ値を使用して、止まった場所、この例ではスレッド712から副オペレーティングシステムに実行を再開させる。
したがって、クリティカルオペレーティングシステム201が、ある機能を実行した(それ自体のアプリケーションまたはサービスにサービスしたか、別のオペレーティングシステム宛の割込みにサービスしたのいずれか)後に、ハードウェアリソースディスパッチャは、スケジューラ410による決定に従って、次の副オペレーティングシステム202に制御を渡す。
[割込み時の副オペレーティングシステムからクリティカルオペレーティングシステムへの切替]
図8を参照して、副オペレーティングシステムからクリティカルオペレーティングシステムへの遷移のプロセスを、これから開示する。この場合に、システムは、クリティカルオペレーティングシステム202で動作するアプリケーション208aのスレッド712を実行している。
ハードウェア割込みが発生するときに、ハードウェアリソースディスパッチャは、OSスイッチャを起動して、副オペレーティングシステムコンテキストをコンテキストストレージ領域708に保存する。ハードウェアリソースディスパッチャは、次に、コンテキストストレージ領域706から状態変数の値を復元することによって主オペレーティングシステム201に切り替え、主オペレーティングシステム201の割込みサービスルーチン704を呼び出す。割込みにサービスした後に、主オペレーティングシステム201のスケジューラが、ISR 704から前に実行されていた任意のスレッド704(または実行すべきスレッド)に制御を渡すことができる。
ISRおよびすべてのスレッドが処理されたときに、上で図7を参照して述べた形で、主オペレーティングシステム201が、ハードウェアリソースディスパッチャに制御を渡し、ハードウェアリソースディスパッチャが、主オペレーティングシステム201から切り替え(コンテキストストレージ領域706に状態変数を保存することによって)、選択された副オペレーティングシステム201に切り替える(コンテキストストレージ708から状態変数を取り出すことによって)。
[オペレーティングシステム間通信−仮想バス418]
仮想バスルーチンは、各オペレーティングシステム内の仮想バスドライバと協力する。仮想バスルーチンは、コンパクトPCI(cPCI)バックプレーンに挿入されたcPCIボードに似た、オペレーティングシステムを接続する物理バスをエミュレートする。各オペレーティングシステムは、この仮想バス上の仮想バスブリッジデバイス用のドライバルーチンを設けられ、これによって、オペレーティングシステムおよびそのアプリケーションが、生のデータ転送から完全なIPプロトコルスタックまでのすべての所望のプロトコルによって通信できるようになる。
ハードウェアリソースディスパッチャ仮想バスは、上で既に述べた、共用メモリおよびシステムクロス割込みの原理に基づく。詳細に言うと、仮想バスルーチン418は、C5 buscom DDIをエミュレートし、このC5 buscom DDIは、仮想バスブリッジ共用デバイスを定義し、仮想バスにまたがるメモリのエクスポート(共用)および他のオペレーティングシステム内へのクロス割込みのトリガを可能にするsyscomである。
各副オペレーティングシステム内の各仮想バスドライバは、スタートアップ時に、ハードウェアリソースディスパッチャハードウェアリポジトリ内にそのような仮想バスブリッジを作成する。それを行うことによって、各仮想バスドライバは、そのプライベートメモリの領域をエクスポート(共用)し、そのホスティングシステム内で割込みを送出する形を提供する。
したがって、第1オペレーティングシステムの仮想バスドライバは、次によって第2オペレーティングシステムにデータを送る。
・ 第2オペレーティングシステムのピア仮想バスドライバによってエクスポートされたメモリに書き込み、次に、
・ データが第2オペレーティングシステム内のピアバスドライバから使用可能であることを通知するためにクロス割込みをトリガする。
逆の(着信)方向では、仮想バスドライバは、それ自体がエクスポートしたメモリ領域にそのようなデータがストアされたことを示すクロス割込みを受け取ったときに、着信データをアップストリームに伝搬させる(それがあてられたアプリケーションまたはルーチンによる使用のために)。
図9の(a)を参照すると、同一のオペレーティングシステム202で動作する別のアプリケーション208bと通信しなければならないアプリケーション208aは、そのオペレーティングシステムを介してそれを行うことができる。異なるオペレーティングシステム202で動作する別のアプリケーション208bと通信しなければならない、あるオペレーティングシステム201で動作するアプリケーション207bは、そのオペレーティングシステムのAPIを使用することによって仮想バスにデータを書き込むことによってそれを行い、このオペレーティングシステム201は、仮想バスドライバルーチンを使用してそのデータを他方のオペレーティングシステム202に渡し、オペレーティングシステム202は、その仮想バスドライバを使用してそのデータをアプリケーション208bに伝搬させる。
図9の(b)を参照すると、第1および第2のオペレーティングシステムが異なるコンピュータ100および101で動作する構成にこの構成を移植するのに必要な変更は、少ない。オペレーティングシステムによって使用されるドライバを変更し、その結果、これらが、仮想バスドライバではなく実際のバス103を使用するようにすることだけが必要である。したがって、このシステムは、それが動作するハードウェアからより独立したものになる。
ハードウェアリソースディスパッチャ仮想バスを介する通信は、アプリケーションから使用可能であるが、オペレーティングシステムカーネルによって内部的に使用することもでき、その結果、オペレーティングシステムカーネルが、複数のオペレーティングシステムの間で分散されたサービスの実装で協力できるようになる。この種の「スマート」分散サービスに、システムホット再始動(上で述べた)に使用されるソフトウェアウォッチドッグまたは分散ネットワークプロトコルスタックが含まれる。
[デバッギング]
好ましい実施形態で、ハードウェアリソースディスパッチャは、第2の動作モードを有し、このモードでは、デバッギングエージェントとして働く。
この実施形態によれば、第2のモードで、ハードウェアリソースディスパッチャが、シリアル通信回線を介して、別の計算機(「ホスト」計算機)で動作するデバッギングソフトウェアツールと通信することができる。
そのようなデバッギングツールは、ハードウェアリソースディスパッチャをリモートコントロールするために、高水準のグラフィカルユーザインターフェース(GUI)を提供する。ハードウェアリソースディスパッチャの仮想化された例外機構が、規定された例外をインターセプトするのに使用される。ユーザは、コードまたは他のシステムのエラーまたは問題の診断をイネーブルするために、プロセッサ例外の場合にハードウェアリソースディスパッチャがどのように振る舞うかを構成し、制御し、計算機状態およびシステム状態を表示することもできる。
ユーザは、オペレーティングシステムからハードウェアリソースディスパッチャへのトラップ呼出しの基礎として、1つまたは複数のそのようなプロセッサ例外を選択することができる。選択された例外を基礎として、各例外が実行中に発生するときに、オペレーティングシステムが、停止され、ハードウェアリソースディスパッチャへのトラップ呼出しを実行し、ハードウェアリソースディスパッチャは、現在のコンテキストを保存し、ホスト側のデバッギングツールとの相互作用をイネーブルする。次に、ユーザは、状態変数(スタックポインタ、プログラムカウンタ、およびアドレスカウンタなど)の現在の状態および/またはメモリの選択されたブロックの内容を表示させることができる。ユーザは、デバッグされる特定のオペレーティングシステム内で所与のタイプの例外をトラップしなければならないこと、またはどのオペレーティングシステム内でも、発生したときに必ず所与のタイプの例外をトラップすることのいずれかを指定することができる。それに応答して、トラップ呼出しが、1つまたはすべてのオペレーティングシステム内で実装される。ユーザは、所与のタイプの例外が、実行を再始動するときにシステムに普通に転送されるか、単純に無視されるかを指定することもできる。
ハードウェアリソースディスパッチャは、それ自体の環境で実行するので、オペレーティングシステム内から行えるもの以上にそのオペレーティングシステムをデバッグすることができる。重要なことに、デバッグエージェントとして働くハードウェアリソースディスパッチャとデバッグされるシステムの間に、共用されるコードがない。これによって、例えば、例外ベクトルまたは割込みサービスルーチンなどのカーネル低水準コードさえデバッグすることが可能になる。
この実施形態による全体的な(ホスト/ターゲット)デバッギングアーキテクチャの他のいくつかの他の態様は、Jalunaが発行し、http://www.jaluna.com/doc/c5/html/DebugGuide/bookl.htmlで入手できる文書「C5 1.0 Debugging Guide」に記載されたChorusおよびC5のデバッギングシステムの態様に似ている。
[セキュアアーキテクチャ]
上で説明した実施形態が、セキュアアーキテクチャの堅固な基礎を与えることは明瞭である。これは、ユーザが通常非セキュアアプリケーションを動作させる副オペレーティングシステムが、指定されたシステムリソースから隔離され、ハードウェアリソースデスパッチャ(および主オペレーティングシステムのドライバ)を介してのみこれらにアクセスするからである。したがって、例えば、暗号化/復号を実行するもの、暗号化されたファイルへのアクセスを可能にするもの、パスワードおよび他のアクセス情報を管理し、ストアし、供給するもの、著作権材料のアクセスおよび複製を管理し、ログ記録するものなどのセキュリティアプリケーションを、主オペレーティングシステム上で動作させることができる。副オペレーティングシステムで動作するアプリケーションは、そのオペレーティングシステムに割り振られていないシステムリソースにアクセスすることができず、オペレーティングシステムが異なるメモリコンテキストで動作する(すなわち、異なる空間への異なるアドレッシングポインタを使用する)場合に、副オペレーティングシステムで動作するアプリケーションを使用して、主システムで動作するアプリケーションに干渉して、その動作のセキュリティを弱めることはできない。
この節では、縮小命令セットコンピュータ(RISC)の例として、PowerPC(「PPC」)アーキテクチャに関する本発明を説明する。この周知のアーキテクチャの背景理解のために、以下を説明する。
http://www.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778525699600719DF2からダウンロードできる、「PowerPC Microprocessor Family:The Programming Environments for 32−Bit Microprocessors − Software Reference Manual」(IBM Inc.刊)、Publication Number:G522−0290−01 Revision Date:02/21/00
次では、ハードウェアリソースデスパッチャを、(非制限的な意味で)ナノカーネルとして説明する。このセクションでは、ナノカーネル実装のPPC固有態様、特にナノカーネル環境のコーナーストーンであるナノカーネルエグゼクティブ(nanokernel executive)に焦点を合わせる。
このセクションでは、複数のオペレーティングシステムにまたがって中央処理装置およびコプロセッシングユニット(CPUおよびFPU)ならびにメモリ管理ユニット(MMU)を共有する複数の独立なオペレーティングシステムを同時に動作させることができるナノカーネルエグゼクティブを実装するために、PowerPCプロセッサアーキテクチャがどのように使用されるかを説明する。
このセクションでは、ナノカーネルエグゼクティブがハードウェア割込みをどのように処理するかも説明する。具体的には、ハードウェア割込みをインターセプトし、主オペレーティングシステムに転送するのに使用される機構と、副オペレーティングシステムに提供されるソフトウェア割込み機構とを説明する。
ここでは、ナノカーネルがユニプロセッサコンピュータで動作していると仮定し、したがって、対称型マルチプロセッサ(SMP)アーキテクチャに関する諸態様に本明細書で言及しない。
概要
仮想アドレス空間
PowerPCアーキテクチャでは、ナノカーネルが、必ず有効(物理)アドレス空間内で動作する。言い換えると、MMUは常にディスエーブルされており、プロセッサは、ナノカーネルコードが実行されるときにはリアルモードで動作している。
この説明では、用語メモリコンテキストは、PowerPC仮想アドレス変換コンテキストを指定する。
・セグメントレジスタで指定される16個の仮想セグメント識別子(VSID)の組
・ページテーブルエントリ(PTE)の組
・BATレジスタで指定されるブロックアドレス変換の組
通常、ユーザモードをサポートするオペレーティングシステムは、プライベートユーザ仮想アドレス空間を処理できるようにするために、複数のメモリコンテキスト(ユーザプロセスあたり1つ)を作成する。カーネルは、あるユーザプロセスから別のユーザプロセスに切り替えるたびにメモリコンテキストを変更する。さらに、オペレーティングシステムカーネルは、一意のスーパーバイザアドレス空間も処理する。ユーザ仮想アドレスおよびスーパーバイザ仮想アドレスは、PowerPCアーキテクチャではオーバーラップすることができる。
スーパーバイザアドレス空間マッピングは、静的または動的のいずれでもよい。静的マッピングは、システム初期化時に作成され、通常は、(全体をまたは部分的に)使用可能な物理メモリをマッピングする。そのようなマッピングは、1対1マッピングまたはカーネル仮想(KV)マッピングとも呼ばれ、通常は、PowerPCのブロックアドレス変換機構(BAT)を使用する。具体的に言うと、KVマッピングは、通常、カーネルのコードセクション、データセクション、およびbssセクションをカバーする。動的マッピングは、動的にロードされるカーネルモジュールまたは動的に割り振られる(不連続な)メモリチャンクにアクセスするために、ランタイムに作成される。
3種類すなわち、主、副、およびナノカーネルのメモリコンテキストが、ナノカーネル環境で区別される。
主メモリコンテキストは、主カーネルによって現在使用されているメモリコンテキストである。主オペレーティングシステムがユーザアドレス空間をサポートする場合に、主カーネルによって使用される複数のメモリコンテキストがある場合があるが、既に上で述べたように、スーパーバイザ空間が一意であることに留意されたい。ナノカーネルは、ユーザマッピングを考慮しないので、主メモリコンテキストは、ナノカーネルから見て一意であり、主カーネルによって確立された静的スーパーバイザマッピングおよび動的スーパーバイザマッピングにある。
副メモリコンテキストは、副カーネルによって現在使用されているメモリコンテキストである。やはり、副オペレーティングシステムがユーザアドレス空間をサポートする場合、副カーネルによって複数のメモリコンテキストが使用されることがあるが、スーパーバイザアドレス空間は1つだけである。したがって、副メモリコンテキストは、ナノカーネルから見て(所与の副カーネルについて)一意であり、そのスーパーバイザメモリコンテキストにある。
ナノカーネル自体は、上で規定されたメモリコンテキストを使用するのではなく、PowerPCプロセッサ有効(物理)アドレス空間を使用する。しかし、ナノカーネルアドレス空間は、他のすべてのメモリコンテキストと異なっており、したがって、特定のもとであると考えることができる。
ナノカーネルメモリコンテキストは、主に、例えばナノカーネルコンソールへの入出力動作を実行するために、副カーネルが、ナノカーネルによって処理される割込み、トラップ、または例外イベントによってプリエンプトされるときに、ナノカーネルコードを実行するのに使用される。ナノカーネルメモリコンテキストは、副実行環境から主実行環境へおよびその逆の切替を可能にする中間アドレス空間としても使用される。PowerPCプロセッサが、例外処理のためにリアル実行モードに切り替えるので、ナノカーネルメモリコンテキストとしてプロセッサ物理アドレス空間を使用することが自然で効率的な手法であることに留意されたい。
図10に、主仮想アドレス空間および副仮想アドレス空間、ならびにナノカーネル物理アドレス空間の例を示す。
この例では、物理メモリサイズが128メガバイトである。主カーネルは、0から始まる自明な1対1(KV)マッピング(C5マイクロカーネルに似た)を使用し、副カーネルは、0×c0000000から始まるシフトされた1対1(KV)マッピング(Linuxカーネルに似た)を使用する。
図11に、メモリコンテキストが経時的にどのように切り替わるかの例を示す。最初に、副オペレーティングシステムが、副メモリコンテキストで動作している。時刻t0に、現在の副カーネルが、ナノカーネルコンソールに文字を出力するためにナノカーネルにトラップする。このトラップが、現在のメモリコンテキストをナノカーネルメモリコンテキストに切り替える。[t0,t1]期間中に、ナノカーネル(ナノカーネルメモリコンテキストで動作している)が、ナノカーネルコンソールに文字をプリントアウトする。時刻t1に、ナノカーネルが、副カーネルにリターンし、副メモリコンテキストに切り替える。時刻t2に、副オペレーティングシステムの動作中に割込みが発生する。この割込みは、現在のメモリコンテキストをナノカーネルメモリコンテキストに切り替え、ナノカーネル割込みハンドラを呼び出す。この割込みを主カーネルに転送するために、ナノカーネルは、ナノカーネルメモリコンテキストから主メモリコンテキストに切り替え、時刻t3に主割込みハンドラを呼び出す。この割込み要求処理中の時刻t4に、主カーネルが、ナノカーネルコンソールに文字を出力するためにナノカーネルにトラップする。
時刻t5に、ナノカーネルが、putcharトラップ呼出しから主カーネルにリターンし、主カーネルは、時刻t6まで割込み要求処理を継続する。この時刻t6に、主カーネルが、割込みハンドラからリターンし、ナノカーネルが、割り込まれた副オペレーティングシステムの実行を継続するために、その副オペレーティングシステムに切り替える。そのような切替は、主メモリコンテキストで開始され、中間ナノカーネルコンテキストを経て、最終的に時刻t7に副メモリコンテキストで終わる。
ナノカーネルの呼出しおよびプリエンプション
ナノカーネルは、トラップを介して明示的に、または割込み/例外ハンドラを介して黙示的に、呼び出される。前者の場合に、オペレーティングシステムカーネルがナノカーネルを呼び出すと言う。後者の場合に、ナノカーネルがオペレーティングシステムをプリエンプトすると言う。ナノカーネルが、必ず、スーパーバイザアドレス空間で動作する特権コードから呼び出されることを強調することが重要である。その一方で、ナノカーネルが、カーネル自体およびカーネルの制御下で動作するユーザプロセスをプリエンプトすることができる。実際には、ナノカーネルが主カーネルをプリエンプトするのを許可することは、望ましくなく、直観に反しており、ナノカーネルは、浮動小数点ユニット共用(下で説明する)を除いてそれを行わない。レイジイ浮動小数点共用によって実現される切替時間の節約は、時折のプリエンプションの短所よりまさるからである。
システムがブートされたならば、まずナノカーネルがアクティブ化され、次に、ナノカーネルが、主カーネルおよび副カーネルの実行を開始する。初期化フェーズが終わったならば、ナノカーネルは、受動的な役割をする。これは、ナノカーネル内で実行されるコードが、主カーネルおよび副カーネルがナノカーネルを明示的に呼び出す(トラップによって)ことによって、または外部で生成された同期イベント(すなわち例外)または非同期イベント(すなわち割込み)によって駆動されることを意味する。
PowerPCアーキテクチャでは、ナノカーネルの呼出しおよびプリエンプションに使用される機構が、主オペレーティングシステムおよび副オペレーティングシステムについて同一である。実行環境に関して、ナノカーネルは、PowerPCリアルモードで動作するので、主カーネルおよび副カーネルから完全に分離されている。ナノカーネルは、「ヌル」メモリコンテキスト(物理アドレス空間)および異なるスーパーバイザスタックを使用する。オペレーティングシステム(MMUがイネーブルされる)とナノカーネル(MMUがディスエーブルされる)の間に、カーネル誤動作に対する保護を提供する障壁がある。しかし、各カーネルがスーパーバイザアドレス空間内で特権コードを動作させ、したがって、副カーネルが、それでも主カーネルならびにナノカーネルをクラッシュさせることができるので、そのような保護が絶対的ではないことに留意されたい。
ナノカーネル呼出し
主カーネルおよび副カーネルは、トラップ呼出し機構を使用してナノカーネルを呼び出す。PowerPCのsc命令およびtrap命令は、ナノカーネルによるprogram例外およびsystem call例外のインターセプトを避けるために使用されない。これは、オペレーティングシステムカーネルによって頻繁に使用されるこれらの例外の処理での性能オーバーヘッドを導入するはずである。
その代わりに、現在PowerPCプロセッサ実装によって使用されていない幾つかの例外ベクトルが、ナノカーネルトラップ呼出し専用である(オペレーティングシステムトラップ呼出しの使用を避ける)。これらの例外ベクトルは、主カーネルおよび副カーネルの実行環境で動作する小さいソフトウェアルーチンを介して呼び出され、PowerPCプロセッサを実際の例外が発生したときと同一の状態にし、rfi命令を使用して適当なベクトルにジャンプする。カーネルは適切に変更される。言い換えると、ナノカーネル呼出し機構は、主カーネルまたは副カーネルの制御の下でトリガされたソフトウェア例外をシミュレートすることによって、既存のPowerPC例外セットを拡張する。
次の例外ベクトルが、ナノカーネルトラップ呼出しに使用される。
0×2000idle、ナノカーネルスケジューラを呼び出す
0×2100 ナノカーネルデバッグエージェントを呼び出して実行を停止する
0×2200 ナノカーネルコンソールIOサービスを呼び出す
0×2300 システムクロス呼出しをトリガする
0×2400 システムを再始動する
0×2500 保留中の仮想例外が存在する場合に、それを処理する(副のみ)
0×2600 システムを停止する(副のみ)
ナノカーネル呼出しは、次の規約およびプロセッサ状態を用いて行われる。
変換がディスエーブルされる(リアルモードに切り替える)
割込みがプロセッサレベルでディスエーブルされる
呼出し側r20がsprg0に保存される
呼出し側r21がsprg1に保存される
呼出し側msrがr20に保存される
呼出し側リターンアドレス(次に実行される命令)がr21に保存される
サブトラップ番号がr9にストアされる(マルチファンクショントラップ用)
ナノカーネルプリエンプション
ナノカーネルは、PowerPC例外/割込みベクトルをインターセプトすることによってオペレーティングシステムをプリエンプトする。PowerPCアーキテクチャは、例外ベクトルが位置するアドレスを構成する機構(ベースレジスタに似た)を提供するのではなく、例外ベクトルを、物理アドレス空間の始め(RAM内の0×00000000)に置くか、物理アドレス空間の最後のメガバイトの最初のページ(通常はRAM内の0×fff00000)に置くことを強制する。したがって、ナノカーネルは、PowerPC実例外ベクトルを所有し、間接関数ポインタの配列(割込みハンドルテーブル)を使用して、ネイティブシステムハンドラを呼び出すか、その代わりに割込みをインターセプトし、ナノカーネルハンドラを実行する。オペレーティングシステムがナノカーネルによってプリエンプトされる際、プロセッサ状態は、使われる例外によって自動的に変更される(リアルモード)。さらに、ナノカーネルハンドラは、別のメモリコンテキストおよびスーパーバイザスタックに切り替えるか、それ自体の環境でタスクを実行するか、別のオペレーティングシステムに直接に切り替えることができる。
ナノカーネルは、ネイティブカーネルハンドラに例外を転送するだけのとき、プロセッサ状態を失わずに間接呼出しを実行するために、レジスタ内容を変更しなければならない。したがって、ナノカーネルは、カーネル例外ハンドラを呼び出すときに、レジスタ使用に関する次の規約を適用する(例外エントリ時の状態と異なるものだけに言及する)。
r20がsprg0スクラッチレジスタに保存される
r21がsprg1スクラッチレジスタに保存される
lrがr20レジスタに保存される
r21に例外テーブルインデックス(例外番号*4)がロードされる
lrにカーネル例外ハンドラのアドレスがロードされる
主プリエンプション
ナノカーネルは、稀に、主オペレーティングシステムをプリエンプトする。通常、使用不能なコプロセッシングユニットの管理に使用される例外(FPU使用不能例外およびAltiVec使用不能例外)だけが、インターセプトされる。これらの例外は、後述するように、レイジイな形でカーネル間のユニット共用を処理するために、ナノカーネルによって使用される。
副プリエンプション
コプロセッシング例外の他に、副オペレーティングシステムは、割込み(非同期例外)が発生したときにもプリエンプトされる。その場合に、割込みベクトルが、対応するナノカーネルハンドラ(副例外テーブルにインストールされる)によってインターセプトされる。次に、ナノカーネルが、主メモリコンテキストに切り替え、この割込みに関連する主カーネルハンドラ(主例外ハンドラテーブルにインストールされる)を呼び出す。
カーネルコンテキスト
ナノカーネルデータを、2つのカテゴリすなわち、グローバルデータおよびカーネルごとのデータに分けることができる。グローバルデータは、グローバルナノカーネル状態(例えば、ナノカーネルメモリコンテキスト)を保ち、カーネルごとのデータは、所与の主カーネルまたは副カーネルに関連付けられた状態を保つ。カーネルごとのデータを、カーネルコンテキストとも呼ぶ。
カーネルコンテキストは、2つの部分すなわち、可視部分および隠し部分にある。可視部分は、パブリックであり、ナノカーネルインターフェースに加わる。カーネルコンテキストのこの部分は、ナノカーネルインターフェースに関する下のセクションで詳細に説明する。隠し部分は、カーネルに可視ではなく、ナノカーネルエグゼクティブによって内部的に使用される。
ナノカーネルエグゼクティブインターフェース
この章では、主カーネルおよび副カーネルにエクスポートされるナノカーネルエグゼクティブインターフェースを説明する。そのようなインターフェースは、カーネルとナノカーネルの間で共用されるデータ構造体(すなわち、可視カーネルコンテキスト)ならびにナノカーネルメソッドにある。
可視カーネルコンテキスト
図12に、カーネルコンテキストの可視部分を示す。
カーネルコンテキストの可視部分内で、すべての参照が、物理アドレスを介して行われることに留意されたい。カーネルは、参照されたオブジェクトにアクセスするために、そのような物理アドレスを仮想アドレス(KVマッピングからの)に変換しなければならない。この図には、2つのカーネルすなわち主カーネルおよび副カーネルだけを有する構成が示されている。
hdls[]フィールドは、カーネル例外ハンドラへのポインタの配列である。この配列は、例外番号によってインデクシングされる。この配列の各エントリに、カーネルネイティブ例外ハンドラを直接にセットするか、関連する例外をインターセプトするためにナノカーネルハンドラをセットすることができる。後者の場合に、カーネルネイティブ例外ハンドラポインタが、VEX hdls[]フィールドに置かれる。
pending VEXフィールドおよびenabled VEXフィールドは、仮想例外の現在の状態を反映する。主カーネル例外はナノカーネルによって仮想化されないので、これらのフィールドが主コンテキストについて無意味であることに留意されたい。仮想化された例外の機構については、副カーネル実行モデルと一緒に詳細に説明する。
boot infoフィールドは、グローバルブート情報構造体である。このフィールドは、読取専用である。
そのようなデータ構造体に、さまざまなプロセッサ情報(周波数)ならびにファーウェアによって渡された引数へのポインタが含まれる。
cmd_line startパラメータおよびcmd_line sizeパラメータは、ブート時パラメータを指定するブートコマンドラインをポイントする。そのようなパラメータは、ブートローダに与えられるか、ナノカーネル環境を介して渡される。コマンドラインは、カーネル固有であり、カーネルコンテキストに置かれる。ナノカーネルは、対応するカーネルに関するパラメータだけを含むカーネル固有コマンドラインを作成するために、最初の(マルチシステム)コマンドラインを解析する。
RAM infoフィールドは、RAM記述テーブルをポイントする。このフィールドは、読取専用である。RAM記述テーブルは、すべてのカーネルによって共用されるグローバルデータ構造体である。RAM記述テーブルは、RAMリソースがカーネルにまたがってどのように分配されるかを記述する。
dev infoフィールドは、ナノカーネルによって抽象化された仮想デバイスのリストをポイントする。このフィールドは、副カーネルについては読取専用であり、主カーネルについては読み書きである。デバイスリストは、グローバルであり、すべてのカーネルによって共用される。このリスト内の各仮想デバイスは、ナノカーネルによって指定されるデータ構造体によって表される。このデータ構造体は、通常、ナノカーネルによって定義されるルールを使用して、主ピアドライバと副ピアドライバの両方によってアクセスされる。主ピアドライバは、仮想デバイスをサポートするサーバの役割を演じ、副ピアドライバは、実際のデバイスではなく仮想デバイスを使用してクライアントの役割を演じる。このリストは、主カーネルだけによって作成(および変更)される。副カーネルは、このリストをブラウズすることだけを許可される。
pending XIRQフィールドは、保留中のクロス割込みを指定する。このフィールドは、ナノカーネル自体によっては使用されない。このフィールドは、クロス割込み交換の際に主カーネルおよび副カーネルを助けるためにコンテキスト構造体によってホスティングされる。クロス割込み配送専用の1つのプロセッサ例外だけがある。pending XIRQフィールドは、クロス割込みの個数を32個まで(クロス割込みソースごとに1ビット)拡張することを可能にする。クロス割込みビットは、ソースカーネル(すなわち、クロス割込みを送るカーネル)によってセットされ、宛先カーネル(すなわち、クロス割込みを受け取るカーネル)によってリセットされる。
IDフィールドに、独自のカーネル識別子が含まれる。このフィールドは、読取専用である。識別子0は、ナノカーネル自体に割り当てられ、識別子1は、主カーネルに割り当てられる。カーネル識別子は、ナノカーネルインターフェース内でカーネルを指定する。例えば、カーネル識別子は、所与のカーネルに割り当てられたリソース(例えば、RAM記述テーブル内のメモリチャンク)にタグを付けるのに使用される。
runningフィールドは、対応するカーネルの状態すなわち、動作中(1)または停止(0)を指定するシステム識別子ビットフィールドをポイントする。このビットフィールドは、読取専用である。ナノカーネルは、関連するカーネルを起動する前にこのビットをセットし、このカーネルが停止した後にこのビットをクリアする。カーネルが再始動されるときに、そのrunningビットが、まずクリアされ、その後セットされる。すべてのカーネルが、すべての動作中のピアカーネルを見つけるためにrunningビットフィールドを分析することができる。主カーネルのrunningビットが、常にセットされていることに留意されたい。
ctx rootフィールドおよびctx lastフィールドは、それぞれ、最初の(ナノカーネル自体)有効なカーネルコンテキストおよび最後の有効なカーネルコンテキストをポイントする。ctx sizeフィールドは、隠し部分を含むカーネルコンテキスト構造体全体のサイズを指定する。これらのフィールドが、一緒に、カーネルコンテキストを管理するのに必要な情報を供給する。
shared memoryフィールドは、共用メモリのプールをポイントする。これは、主に、すべてのカーネルの間で共用されるデータをストアするメモリを割り振るために、主カーネルによって使用される。
ナノカーネルメソッド
ナノカーネルは、2つのグループのメソッドすなわち、コンソール入出力動作およびエグゼクティブ動作を提供する。コンソール入出力グループは、カーネルがナノカーネルコンソールシリアル回線に/から文字を送る/受け取ることを可能にする。この文書は、多かれ少なかれ包括的であるコンソール入出力メソッドに特に対処するのではなく、PowerPCアーキテクチャ固有であるエグゼクティブメソッドに焦点を合わせる。
Install CPU exception handler
例外ベクトルコードをPowerPC例外ベクトルに直接にインストールするのではなく、カーネルは、このナノカーネルメソッドを呼び出して、所与のプロセッサ例外にハンドラをアタッチしなければならない。例外番号およびカーネルハンドラコードの物理アドレスが、引数として渡される。例外番号は、カーネルコンテキスト内のhdls[]例外ハンドラテーブルをインデクシングするのに使用され、このテーブルに、カーネルハンドラポインタがストアされる。
ナノカーネルは、後に、このテーブルエントリ値を使用して、追加の間接呼出しの最小限のオーバーヘッドで、対応する例外をカーネルに直接に送出することができる。このメソッドは、カーネルが直接に処理する(ナノカーネルによってインターセプトされない)例外に使用されなければならない。
Install virtualized exception handler(VEX)
このメソッドは、カーネル例外ハンドラを、ナノカーネルによって仮想化された例外にアタッチするのに使用される。そのような例外は、ナノカーネルによってインターセプトされ、延期される実PowerPC例外に対応する仮想例外、またはナノカーネルによって送出される論理イベントのいずれかである。
VEX番号およびカーネルハンドラコードの物理アドレスが、引数として渡される。VEX番号は、カーネルコンテキスト内のvexHdls[]仮想化例外ハンドラテーブルをインデクシングするのに使用され、このテーブルに、カーネルハンドラポインタがストアされる。
Idle
ナノカーネルは、アイドルループ内でカーネルによって呼び出されなければならないidleメソッドを提供する。idleメソッドは、呼出し側カーネルが次の割込みまで行うべきことがないことをナノカーネルに知らせる。
idleメソッド呼出しは、動作の準備ができている次の副カーネル(ある場合に)へのシステム切替またはすべての副カーネルがアイドルであるときの主idleメソッドからのリターンをもたらす。idleメソッドは、パラメータを有しない。
Restart
ナノカーネルは、副カーネルを再始動するために、主カーネルならびに副カーネルによって呼び出すことができるrestartメソッドを提供する。
メソッドパラメータは、再始動されるカーネルの識別子を指定する。ナノカーネルは、カーネル実行を停止し、コピーからカーネルイメージを復元し、最後に、初期エントリポイントでカーネル実行を開始する。
副カーネルが、それ自体の識別子を用いてrestartトラップを呼び出すことによって、それ自体をリブートできることに留意されたい。
副Halt
haltトラップが、ナノカーネルによって副カーネルに提供される。そのようなトラップは、停止するときに副カーネルによって呼び出される。ナノカーネルは、ナノカーネルスケジューラが呼出し側カーネルに切り替えないようにするために、呼出し側カーネルを非動作状態にする。
停止されたカーネルは、上で説明したrestartナノカーネルメソッドによってもう一度始動することができる。
主実行環境
基本的に、主カーネルは、ネイティブ実行環境で実行している。PowerPCプロセッサでのナノカーネル実装は、主オペレーティングシステム特性(性能、割込み待ち時間、プリエンプション待ち時間)に対するナノカーネル環境の影響を最小限にすることを試みる。主オペレーティングシステムは、通常はリアルタイムオペレーティングシステムなので、他の(副)オペレーティングシステムが同一のプロセッサ上で同時に動作している場合であっても、主カーネル挙動を変化しないままに保つことが重要である。
初期化
ナノカーネルは、まず、ディスエーブルされたMMUを用いてすなわち物理空間で、ブートローダによって始動される。基本的に、ナノカーネル初期化コードは、物理メモリ内の主メモリバンク(主カーネルのコード/データ/bssセクションを含む)および他のバンクをインストールし、主エントリポイントにジャンプする。
主カーネルにジャンプする前に、ナノカーネルは、システム固有関数を呼び出すことによって、主カーネルコンテキストを初期化する。この関数は、カーネルコンテキストの隠し部分内で、少なくとも、srr0レジスタイメージにカーネルエントリポイントを、srr1レジスタイメージにシステムカーネルが期待する初期値をセットしなければならない。
例外ハンドラテーブル(カーネルコンテキストのhdls[]フィールド)のすべてのエントリが、コプロセッシング(FPU)ユニット例外を除くナノカーネルデバッグエージェントエントリポイントをポイントする。これによって、予期されない早期例外が実行を停止することが保証される。
ナノカーネル初期化コードは、データセクションに置かれた別々の静的ナノカーネルスタックを使用して実行される。主カーネルにジャンプするときに、このスタックがまだ有効である。それにもかかわらず、主カーネルは、できる限り早くそれ自体のスタックに切り替えなければならず、絶対に将来にこのナノカーネルスタックを使用してはならない。ナノカーネルスタックは、次の章で説明する副呼出しおよび副プリエンプションを処理するために、初期化フェーズだけではなく、ランタイムにも使用される。
主カーネルにジャンプするときに、r3ジスタが、カーネルコンテキストをポイントし、msrレジスタに、カーネルコンテキスト内のsrr1イメージセットがロードされる。通常、プロセッサ割込みは、主初期化フェーズの始めにはディスエーブルされている。主カーネルは、通常、クリティカルな初期化フェーズが終わった後に割込みをイネーブルする。
初期化フェーズ中に、主カーネルは、通常、ハンドラをプロセッサ例外および仮想化された例外にアタッチするために、ナノカーネルメソッドを呼び出す。最後に、主カーネルが、アイドルループに入り、ナノカーネルidleメソッドを呼び出す。
idleメソッドが始めて呼び出されるときに、ナノカーネルは、主カーネルがその実行環境を完全に初期化し終えたと考え、ポスト初期化フェーズに進む。
そのようなポスト初期化フェーズで、ナノカーネルは、次の章で説明するように、副カーネルコンテキストを初期化する。ポスト初期化が終わったならば、ナノカーネルは、動作の準備ができた副カーネルに切り替えるか、すべての副カーネルがアイドルである場合に主idleメソッドからリターンするために、スケジューラを呼び出す。
ナノカーネルは、主カーネルがグローバルに共用されるデータ構造体すなわち、RAM記述子および仮想デバイスリストを初期化することを必要とする。そのような初期化は、idleメソッドが呼び出される前に行われなければならない。この要件は、自然である。というのは、この瞬間の後に、副カーネルが、グローバルに共用されるデータ構造体にアクセスできるからである。
具体的に言うと、主カーネルは、基板上で使用可能な物理メモリを検出し、空き物理メモリチャンクをRAM記述子に登録する責任を負う。
主Board Support Package(BSP)に従って、主カーネルは、ナノカーネル対応ドライバを始動しなければならず、これらのドライバは、仮想デバイスリストに投入しなければならない。そのような仮想デバイスは、副カーネルに提供され、したがって、最初の副カーネルが始動される前に作成されなければならない。
インターセプトされる例外
基本的に、ナノカーネルは、主オペレーティングシステムがプロセッサ上で動作しているときに発生する割込みをインターセプトしない。すべてのプログラミング例外、トラップ、および割込みが、ネイティブ主ハンドラによって処理される。主低水準ハンドラは、PowerPCアーキテクチャのナノカーネル例外ハンドラ呼出し規約に従うために変更されることだけを必要とする。
上のルールからの例外は、コプロセッシングユニットエミュレーションに関連する次のプログラミング例外である。
浮動小数点使用不能例外(FPU)
ベクトルユニット使用不能例外(AltiVec VU)
これらの例外は、この文書でさらに説明するコプロセッシングユニット共用のレイジイ機構を実装するために、ナノカーネルによって使用される。
もう1つの特別な事例が、主オペレーティングシステムのホストベースのリモートシステムデバッギングを提供するためにナノカーネルに組み込むことができるデバッグエージェントである。この場合に、デバッグエージェントは、通常、デバッグ機能(例えば、単一命令トレース)またはプログラムエラー(例えば、ページフォールト)のいずれかに関連するいくつかの同期例外をインターセプトする。しかし、そのようなデバッグエージェントの設計は、この文書の範囲外である。
転送される例外
割込みが、副オペレーティングシステムがプロセッサ上で動作している間に発生したときに、その割込みは、主オペレーティングシステムに転送される。そのような割込み転送プロセスは、次の主要なステップを行う。
割込みが、ナノカーネル(副カーネルコンテキスト内のhdls[]テーブルの対応するエントリが、ナノカーネルハンドラをポイントする)によってインターセプトされ、
プリエンプトされた副カーネルの実行が、サスペンドされ、ナノカーネルが、主実行環境に切り替え、
ナノカーネルが、主カーネルへの対応する割込みをトリガする(主カーネルコンテキスト内のhdls[]テーブルの対応するエントリに分岐する)。
その形で、対応する主低水準割込みハンドラが、割込みを処理するために呼び出される(主実行環境内で)。割込みが処理されたならば、主カーネルは、rfi命令を実行することによってナノカーネルにリターンする。
主割込みハンドラからリターンした後に、ナノカーネルは、次に動作させる副オペレーティングシステムを決定するために、スケジューラを呼び出す。プリエンプトされた副システムが、必ずしも割込みの後に継続されないことに留意されたい。もう1つの(より高い優先順位の)副システムが、割込みのゆえに動作の準備ができる場合がある。
副実行環境
基本的に、副カーネル実行環境は、割込み管理を除いて、ネイティブ実行環境に対してまったく閉ざされている。ナノカーネル環境は、副オペレーティングシステムを完全にプリエンプト可能にするために、割込み管理のネイティブ機構を変更する。ナノカーネル環境に移植された副カーネルは、もはやプロセッサレベルで割込みをディスエーブルするのではなく、ナノカーネルによって提供されるソフトウェア割込みマスク機構(すなわち、仮想例外)を使用する。割込みは、もはやそのような副カーネルによって直接に処理されるのではなく、ナノカーネルによってインターセプトされ、主カーネルに転送され、その後に限って、任意選択として、延期された形で副カーネルによって処理される。
初期化
ナノカーネルは、初期化時に、主バンクと一緒に副メモリバンクをインストールする。その一方で、副カーネルの最後の初期化、具体的にはカーネルコンテキストセットアップは、ポスト初期化フェーズまで延期される。
このフェーズで、ナノカーネルは、副メモリバンクのコピーを保つためにメモリを割り振る。そのようなコピーは、その後、再始動時に副システムの初期イメージを復元するのに使用される。しかし、副システム再始動は、任意選択であり、物理メモリ消費を減らすためにディスエーブルすることができる。
副カーネルコンテキストは、システムエントリポイントによって期待されるものに従ってコンテキストを初期化するシステム固有ルーチンを呼び出すことによってセットアップされる。例外ハンドラテーブル(カーネルコンテキストのhdls[]フィールド)のすべてのエントリが、コプロセッシング(FPU)ユニットエントリおよび割込みエントリを除くナノカーネルデバッグエージェントエントリポイントをポイントする。これらは、次の節で説明するように、対応する副例外をインターセプトするのに使用されるナノカーネル固有ハンドラをポイントする。
ナノカーネルは、カーネルコンテキスト隠し部分内のシステム固有ルーチンによって前にセットアップされた初期実行コンテキストに切り替えることによって、副カーネルを起動する。
主カーネルに似て、カーネルコンテキスト物理アドレスが、引数として渡される(渡し方の規約は、システム固有である)。その一方で、主カーネルと異なって、割込は、副カーネル初期化フェーズ中であってもプロセッサレベルでイネーブルされる(MSR[EE]がセットされている)。副カーネル初期化コードさえもが、主システムによって完全にプリエンプト可能であることに留意されたい。これは、副オペレーティングシステムが再始動されるときに主オペレーティングシステムを邪魔しないようにするために特に重要である。
イネーブルされたハードウェア割込みにもかかわらず、仮想化された例外(ハードウェア割込みに対応する)は、副カーネルが始動されるときにディスエーブルされる。したがって、割込みは、クリティカル初期化フェーズの終りに副カーネルによって明示的にイネーブルされるまで、ナノカーネルによって配送されない。ソフトウェア割込みマスク機構(仮想例外に基づく)は、この文書でさらに詳細に説明する。
スタックポインタは、副カーネルが始動されるときには無効である。通常、副カーネルは、その初期化コードを実行するために、データセクションに置かれた静的初期スタックを使用する。
主カーネルに似て、初期化フェーズ中に、副カーネルは、通常、PowerPC例外および仮想化された例外にハンドラをアタッチするために、ナノカーネルトラップを呼び出す。最後に、副カーネルが、アイドルループに入り、ナノカーネルidleトラップを呼び出す。
インターセプトされる例外
副例外をインターセプトするために、ナノカーネルは、副カーネルコンテキスト内のhdls[]例外ハンドラテーブルの対応するエントリにそれ自体のハンドラへのポインタをインストールする。したがって、そのような例外が発生したときに、例外ベクトルは、ナノカーネルハンドラに分岐し、このナノカーネルハンドラが、副メモリコンテキストを保存し、例外を処理する。
すべてのインターセプトされる例外を、その性質に従って、割込み、トラップ、およびプログラミング例外(フォールト)として分類することができる。
ナノカーネルは、次のすべてのPowerPC割込み(非同期例外)を、主カーネルに転送するためにインターセプトする。
リセット
マシンチェック
システム管理
外部割込み
性能モニタ
デクリメンタ
さらに、2つのナノカーネルトラップが、性能クリティカルであり、副カーネルについて特に処理される。
第1のナノカーネルトラップは、主カーネルにクロス割込みを送る。ナノカーネル処理は、例外がハードウェア割込みではなくソフトウェア割込みに対応する主カーネルに転送されることを除いて、割込み処理と同等である。したがって、割込みに似て、このトラップは、現在の副カーネルをプリエンプトする。
第2のナノカーネルトラップは、保留中の仮想例外がもう一度イネーブルされたときに、この仮想例外を処理するために副カーネルによって呼び出される。これらのトラップは、ソフトウェア割込みマスク機構に加わり、仮想例外専用の次の節で詳細に説明される。
主カーネルに似て、ナノカーネルは、通常、下で説明するいくつかの特別な場合を除いて、プログラミング例外をインターセプトしない。
浮動小数点使用不能例外(FPU)
ベクトルユニット使用不能例外(AltiVec VU)
これらの例外は、この文書でさらに説明するコプロセッシングユニット共用のレイジイ機構を実装するために、ナノカーネルによって使用される。
もう1つの特別な事例が、副オペレーティングシステムのホストベースのリモートシステムデバッギングを提供するためにナノカーネルに組み込むことができるデバッグエージェントである。この場合に、デバッグエージェントは、通常、デバッグ機能(例えば、単一命令トレース)またはプログラムエラー(例えば、ページフォールト)のいずれかに関連するいくつかの同期例外をインターセプトする。しかし、そのようなデバッグエージェントの設計は、この文書の範囲外である。
仮想例外
仮想例外(VEX)は、カーネルが延期された形で副カーネルに例外をポストし、配送することを可能にする、ナノカーネルによって提供される機構である。具体的に言うと、VEX機構は、ハードウェア割込みを副カーネル用のソフトウェア割込みに置換するためにPowerPCナノカーネルアーキテクチャで使用される。
VEXインターフェースは、カーネルコンテキストに置かれる2つのフィールドすなわち、pendingおよびenabledにある。これらのフィールドは、副カーネルコンテキストに関してのみ意味があるが、主カーネルと副カーネルの両方によってアクセスされる。すべての仮想例外が、pending(またはenabled)フィールド内のビット位置によって自然に列挙される。したがって、PowerPCアーキテクチャ上のナノカーネルによってサポートされる合計32個の仮想例外がある(pendingフィールドおよびenabledフィールドは、32ビット整数値である)。
下の表に、仮想例外が実例外にどのようにマッピングされるかを示す。
Figure 2007507779
0から6までの仮想例外は、PowerPC割込みにマッピングされる。仮想例外7は、副カーネルにクロス割込みを配送するのに使用される例外ベクトル0×23にマッピングされる。9から30までの仮想例外は、現在は使用されておらず、将来の拡張用に予約済みである。仮想例外31は、実例外には対応せず、実際には、ナノカーネルによって内部的に使用される、カーネルがアイドルであるかどうかを検出する順序である擬似仮想例外である。そのような擬似仮想例外がどのように働くかを、この文書でさらに詳細に説明する。
複数の仮想例外を同時に保留中にすることができるが、一時にそのうちの1つしか処理することができないので、すべての仮想例外が、その番号に従って優先順位を付けられる。最高の優先順位が、マシンチェックに割り当てられ、最低の優先順位が、動作中擬似例外に割り当てられる。
副コンテキストのpending VEXフィールドは、通常は、仮想PICデバイスのドライバを提供する主カーネルによって更新される。そのようなドライバは、通常、pending VEXフィールド内の適当なビットをセットすることによって、副カーネルに仮想例外(割込み)をポストする。
enabled VEXフィールドは、仮想例外をイネーブルし、またはディスエーブルするために、副カーネルによって更新される。所与の仮想例外は、対応するビットがenabled VEXフィールドでセットされている場合にイネーブルされる。enabled VEXフィールドを使用して、副カーネルは、割込みに対して保護されたクリティカルセクションを実装する。言い換えると、副カーネルは、もはやプロセッサ割込みをディスエーブル/イネーブルするのにMSR[EE]ビットおよびMSR[ME]ビットを使用するのではなく、そのカーネルコンテキストのenabled VEXフィールドを変更する。
所与の仮想例外は、それが保留中であると同時にイネーブルされている場合に、ナノカーネルによって配送される。ナノカーネルは、副例外ハンドラにジャンプする直前に、対応する保留中ビットをリセットする。
副カーネルをPowerPCナノカーネルアーキテクチャに移植するときに、ハードウェア割込みマスク機構と置換されるソフトウェア割込みマスク機構を考慮に入れるために、低水準例外ハンドラを変更しなければならないことに留意されたい。ハードウェア割込みは、低水準例外ハンドラコード内を除いて、副カーネルを動作させるときにプロセッサレベルで必ずイネーブルされ、低水準例外ハンドラコード内では、プロセッサ状態が、共用リソース(スクラッチレジスタ)を使用して保存され、クリティカルセクションが必要である。その形で、ナノカーネル環境では、副オペレーティングシステムが、主オペレーティングシステムによって非常にプリエンプト可能になり、そのような低水準例外コードが状態を保存している短い期間を除いてプリエンプト可能である。
仮想例外を、その例外がディスエーブル状態である間に主カーネルによってポストすることができる。この場合に、例外は、副カーネルに配送されるのではなく、その例外が再イネーブルされるまで保留中にされる。したがって、仮想例外が副カーネルによって再イネーブルされるときに、仮想例外が保留中であるかどうかの検査を行わなければならない。検査が肯定の場合に、副カーネルは、そのような保留中の仮想例外を処理するために、ナノカーネルを呼び出さなければならない。そのような検査は、「保留中仮想例外処理」トラップ(ナノカーネル固有ベクトル0×2500)によって行われる。
一般に、副カーネルは、次の2つの場合に仮想例外を再イネーブルする。
コードのクリティカルセクションを保護するために、仮想例外が前に副カーネルによってディスエーブルされているときと、
プロセッサ例外低水準ハンドラを処理している間に仮想例外がディスエーブルされたとき。
ナノカーネル再入
ナノカーネルコードは、主として、ナノカーネルへの再入を防ぐためにプロセッサレベルで割込みをディスエーブルされた状態で実行される。その一方で、一部のナノカーネル呼出しが、長い時間を要する場合があり、したがって、ナノカーネルは、主割込み待ち時間を短く保つために、そのような長い動作を実行するときに割込みをイネーブルしなければならない。
長いナノカーネル動作には、次の2種類がある。
同期コンソール出力
動作持続時間は、シリアル回線速度に依存する。例えば、9600ボーレート回線では、単一文字出力が1ミリ秒を要する場合がある。
副カーネル再始動
動作持続時間は、コピーから復元されるカーネルイメージサイズに依存する。
上にリストしたすべての動作について、ナノカーネルは、割込みをイネーブルし、したがって、主カーネルからの再入をイネーブルする。その一方で、割込みがイネーブルされるときに、ナノカーネルスケジューラは、主割込みハンドラからリターンするときに別の副カーネルがスケジューリングされないようにするために、絶対に呼び出されない。言い換えると、ナノカーネルは、主カーネルだけがプリエンプトすることができる(割込みの結果として)が、副カーネルからの再入は、禁止される。そのような制限は、ナノカーネルが副実行環境についてグローバルリソースを使用することを可能にする。したがって、副オペレーティングシステムからナノカーネルに入るときには、ナノカーネルに副オペレーティングシステムから割り込むことができないので、すべての状態を保存する必要はない。
上の議論は、ナノカーネルが、主カーネルまたは副カーネルによって呼び出されたトラップから生じるナノカーネルメモリコンテキストでコードを実行している間に、プロセッサ割込みをイネーブルできなければならないことを示す。言い換えると、ナノカーネルは、それ自体のトラップ呼出しハンドラを動作させている間の主割込みハンドラへの切替をサポートしなければならない。
そのようなコンテキスト切替ネスティングをサポートするために、ナノカーネルは、それ自体のカーネルコンテキストを管理する。ナノカーネルカーネルコンテキストは、0の識別子値(IDフィールド)を有する。このコンテキストは、割込み時に主カーネルに切り替えるときに、ナノカーネル実行コンテキストを保存する(隠し部分に)のに使用される。このコンテキストは、ナノカーネル固有割込みハンドラポインタをストアする(hdls[]テーブルに)のにも使用される。この形で、ナノカーネルコードが動作中のときであっても、割込みを、「現在」実行中のカーネルコンテキストを介してベクトル化することができる。さらに、ナノカーネルスーパーバイザスタックが、クリティカルな共用プロセッサリソースならびに、そうでなければ主カーネル再入時に上書きされるナノカーネルコンテキストおよび主カーネルコンテキストをプッシュするのに使用される。
ナノカーネルは、ルーチンの割込みプロローグ/エピローグ対を使用して、ナノカーネル内での割込みを処理し、主カーネルによって処理された割込みの終りに、ナノカーネルの割り込まれたコードにリターンする。ルーチンのプロローグ/エピローグ対が、ナノカーネルトラップを呼び出した最後のカーネルに応じて異なることに留意されたい。実際に、スタックにプッシュされる情報の種類および量は、主トラップ呼出し側および副トラップ呼出し側について同一ではない。
割込みプロローグルーチンは、ナノカーネル割込みハンドラである。これは、ナノカーネルカーネルコンテキスト内のhdls[]例外ハンドラテーブルのすべての割込みエントリにアタッチされる。このハンドラは、次のアクションを実行する。
カーネルコンテキストの一部をスタック上の割込みフレームに保存し、
主カーネル再入を処理するためにカーネルコンテキストを現在の値を用いて更新し、
適当なエピローグルーチンにリターンするためにsrr0レジスタ値を変更し、
対応する主カーネル割込みハンドラに切り替える。
割込みエピローグルーチンは、主カーネル割込み処理からリターンするとき(rfi)に呼び出される。これは、ナノカーネルスケジューラを呼び出さずに、ナノカーネルの割り込まれた実行コンテキストを直接に復元するのに使用され、次のステップを行う。
カーネルコンテキストから現在の状態を復元し、
割込みスタックフレームからカーネルコンテキスト(プロローグルーチンによって保存された)を復元し、
割り込まれたコードにリターンする。
ナノカーネル割込みスタックフレームは、次の情報を保存するのに使用される。
ナノカーネルカーネルコンテキストのクリティカル部分すなわち、lrレジスタ、r1レジスタ、r2レジスタ、srr0レジスタ、およびsrr1レジスタのコピーと、
最後のトラップ呼出し側(主カーネルコンテキストまたは副カーネルコンテキストへのポインタ)と、
最後のトラップ呼出し側が主カーネルである場合に限って、主カーネルコンテキストのクリティカル部分すなわち、r1レジスタ、r2レジスタ、srr0レジスタ、およびsrr1レジスタのコピー。
ナノカーネルは、割込みをイネーブル/ディスエーブルするのに使用される関数の対を定義する。これらの関数は、それぞれ、ナノカーネル実行コンテキストのうちでトラップに入るときにシステムによって保存されない追加部分をスタックに保存し、復元する。
割込みをイネーブルするときに、ナノカーネルは、次のステップを行う。
スクラッチレジスタ(sprg0〜3)をスタックに保存し、
割込みプロローグ/エピローグルーチンの現在の対をスタックに保存し、
トラップ呼出し側(主または副)に従って割込みプロローグ/エピローグルーチンの現在の対を更新し、
プロセッサレベルで割込みをイネーブルする(MSR[EE]ビットをセットする)。
割込みをディスエーブルするときに、ナノカーネルは、次のステップを行う。
プロセッサレベルで割込みをディスエーブルし(MSR[EE]ビットをクリアし)、
割込みプロローグ/エピローグルーチンの現在の対をスタックから復元し、
スクラッチレジスタ(sprg0〜3)をスタックから復元する。
図13に、実行の流れと、ナノカーネルスタックが割込み処理および主カーネル再入を可能にするのにどのように使用されるかを示す。
スケジューラ
オペレーティングシステムスケジューラの主な役割は、次に動作するタスクを選択することである。ナノカーネルは、オペレーティングシステムの実行を制御するので、ナノカーネルスケジューラは、次に動作する副オペレーティングシステムを選択する。言い換えると、ナノカーネルは、システム全体に余分なスケジューリングレベルを追加する。
ナノカーネルアーキテクチャでは、主オペレーティングシステムが、副オペレーティングシステムに関して最高の優先順位を有し、CPUが、主システムがアイドルループに入っているときに限って副システムに与えられることに留意されたい。主カーネルが、プリエンプト可能ではなく、アイドルループ内で呼び出されるidleメソッドを介してナノカーネルスケジューラを明示的に呼び出すと言うことができる。副システムを動作させているときに割込みが発生したならば、主カーネル割込みハンドラが呼び出される。主カーネルの展望から、そのような割込みは、アイドルループを実行するバックグラウンドスレッドをプリエンプトする。割込みが処理され、すべての関連するタスクが終わったならば、主カーネルは、ナノカーネルにリターンし、このナノカーネルは、次に動作する副システムを決定するためにナノカーネルスケジューラを呼び出す。主カーネルの展望から、カーネルは、単に、割込みによってプリエンプトされたバックグラウンドスレッドにリターンする。副アクティビティは、主カーネルに透過的であり、主システム挙動を変更しない。
ナノカーネルは、異なるスケジューリングポリシを実装することができる。しかし、デフォルトで、優先順位ベースのアルゴリズムが使用される。同一の優先順位レベルでは、ナノカーネルがラウンドロビンスケジューリングポリシを使用することに留意されたい。所与の副カーネルの優先順位は、システムイメージ作成時に静的に構成される。
実装されるスケジューリングポリシがどれであっても、スケジューラは、所与の副システムが動作の準備ができているかどうかを検出しなければならない。この条件は、カーネルコンテキストのpending VEXフィールドとenabled VEXフィールドの間のビット単位論理積演算として計算される。非0の結果が、システムが動作の準備ができていることを示す。
上で説明したように、pending VEXおよびenabled VEX対の各ビットが、仮想例外を表す。動作の準備ができていることの判断基準を言い直すと、少なくとも1つのマスクされていない保留中の仮想例外がある場合に、副システムは動作の準備ができた状態であると言うことができる。
通常はハードウェア割込みおよびソフトウェア(クロス)割込みにマッピングされるすべての仮想例外の中に、カーネルが現在アイドルであるかどうかを反映する特別な仮想割込み(running)がある。
runningビットは、副カーネルがidleメソッドを呼び出すたびにpending VEXフィールド内でクリアされ、runningビットは、仮想例外が副カーネルに配送されるたびにpending VEXフィールド内でセットされる。
runningビットは、通常、動作中の副カーネルのenabled VEXフィールド内で必ずセットされている。ナノカーネルは、副カーネルが始動されるときにこのビットをセットし、副カーネルが停止されるときにこのビットをリセットする。副カーネルは、仮想例外にマッピングされた割込みをマスク/マスク解除するときに、絶対にrunningビットをクリアしてはならない。
外部エージェントが、カーネルコンテキスト内のenabled VEXフィールドをクリア/復元することによって副カーネルの実行をサスペンド/再開できることに留意されたい。この機能は、スケジューリングポリシエージェントをナノカーネルの外部で主カーネルタスクとして実装する可能性を開く。さらに、これは、副カーネル用のデバッグエージェントを主カーネル上のタスクとして動作させることを可能にする。そのような副デバッグエージェントの利益は、主オペレーティングシステムによって提供されるすべてのサービスが、デバッグに使用可能になり(例えば、ネットワーキングスタック)、副カーネルデバッギングを、主オペレーティングシステムで動作するクリティカルタスクと同時に行えることである。
クロス割込み
このセクションでは、主として、ナノカーネルクロス割込み機構に関する情報(前の節で既に与えた)を整理統合する。
次の2種類のクロス割込みを、ここで検討する。
副カーネルに送られるクロス割込み
主カーネルに送られるクロス割込み
クロス割込みを宛先副カーネルに送るためには、ソースカーネルが、まず、宛先カーネルコンテキストのpending XIRQフィールド内のクロス割込みソースに対応するビットをセットする。次に、ソースカーネルは、宛先カーネルコンテキストのpending VEXフィールド内の対応するビットをセットすることによって、宛先カーネルにクロス割込みVEXをポストする。クロス割込みハンドラは、ナノカーネルによって呼び出されたならば、pending XIRQフィールドを検査し、保留中のクロス割込みソースに対応するビットをクリアし、最後に、このソースにアタッチされたハンドラを呼び出す。ソースカーネルと宛先カーネルの両方が、アトミック命令を使用してpending XIRQフィールドを更新する。同一のアルゴリズムが、主と副の両方のタイプのソースカーネルによって使用されることに留意されたい。
クロス割込みを主カーネルに送るためには、副カーネルが、まず、主カーネルコンテキストのpending XIRQフィールド内のクロス割込みソースに対応するビットをセットする。次に、副カーネルは、XIRQトラップを実行することによってナノカーネルを呼び出す。ナノカーネルは、即座に副カーネルをプリエンプトし、主低水準クロス割込みハンドラを呼び出し、このハンドラが、pending XIRQフィールドを検査し、保留中のクロス割込みソースに対応するビットをクリアし、最後に、このソースにアタッチされたハンドラを呼び出す。
クロス割込み0は、カーネルによって使用されてはならない。この割込みは、停止したカーネルが始動されたことまたは動作中のカーネルが停止されたことをナノカーネルがカーネルに通知するために予約されている。言い換えると、クロス割込み0は、グローバルシステム構成が変化したことを動作中のカーネルに通知する。これは、カーネルコンテキストによってポイントされるrunningビットフィールドの状態が変更されるたびに、すべての動作中のカーネルにブロードキャストされる。
コプロセッシングユニット管理
コプロセッシングユニット(FPU、SIMDユニット)は、通常、ナノカーネル環境で動作するすべてのオペレーティングシステムによって共用されるコンピューティングリソースである。次では、浮動小数点ユニット(FPU)を、例としてとりあげる。しかし、AltiVecベクトル計算ユニット(SIMD)などの他のコプロセッシングユニットが、同一の形で管理される。
PowerPCアーキテクチャでは、ナノカーネルが、レイジイな形でコプロセッシングユニット共用を管理する。これは、例えば、あるオペレーティングシステムから別のオペレーティングシステムへの切替が発生するときに、FPUが、新たにスケジューリングされるオペレーティングシステムに即座に与えられるのではなく、新たにスケジューリングされたシステムが実際に浮動小数点命令を実行し、浮動小数点レジスタにアクセスするまで、FPUコンテキスト切替が延期されることを意味する。
そのようなレイジイFPUディスパッチアルゴリズムは、ナノカーネルがシステム切替時間を減らすことを可能にする。これは、主割込み待ち時間を減らすために特に重要である。というのは、FPUが、通常、割込みレベルでは使用されず、したがって、通常、副オペレーティングシステムをプリエンプトし、主割込みハンドラを呼び出すためにFPUレジスタを保存し、復元する必要がないからである。
ナノカーネルは、現在FPUを使用しているカーネルのコンテキストをポイントするFPUオーナーグローバル変数を処理する。FPUオーナーがない場合には、FPUオーナーコンテキストに0がセットされる。FPUコンテキストは、カーネルコンテキストの隠し部分に置かれる。そのようなコンテキストは、カーネルがFPUオーナーでないときにFPUエンジンの状態(すなわち、浮動小数点レジスタおよび状況)を保つ。明らかに、FPUオーナーの状態は、FPUエンジンハードウェアによって保たれる。ナノカーネルがFPUオーナーを変更するときに、FPU状態が、古いFPUコンテキストに保存され、新しいFPUコンテキストから復元される。
ナノカーネルは、FPUが非FPUオーナーによって使用されるときに例外を誘発するために、MSRレジスタの浮動小数点使用不能(FP)ビットを使用する。MSRレジスタイメージは、カーネルコンテキストの隠し部分に加わる。MSR[FP]ビットは、FPU切替時に、前のオーナーコンテキストでクリアされ、新しいオーナーコンテキストでセットされる。FPビットは、FPUオーナー以外のすべてのカーネルコンテキストでクリアされ、FPUオーナーではセットされる。これによって、ナノカーネルが、すべての非FPUオーナーについて浮動小数点使用不能例外(0×8)をインターセプトできるようになると同時に、FPUオーナーは、この例外をネイティブな形で処理する。
FPU切替は、ナノカーネルが「FP使用不能」例外をインターセプトするときに発生する(これは、オペレーティングシステムカーネルの変更を必要とする)。2つのカーネルの間でFPUエンジンを切り替えるために、ナノカーネルは、現在のFPUオーナーを解放し、新しいFPUオーナーを割り当てる。
現在のFPUオーナーを解放するために、ナノカーネルは、現在のFPU状態を、MSR[FP]ビットの現在の状態と一緒にナノカーネルのカーネルコンテキストに保存し、MSRレジスタイメージのFPビットをクリアする。さらに、ナノカーネルは、FP使用不能例外(0×8)をインターセプトするために、ナノカーネル自体の例外ハンドラを、カーネルコンテキスト内のhdls[]例外ハンドラテーブルの適当なエントリにインストールする。ネイティブ例外ハンドラポインタが、カーネルコンテキストの隠し部分のsavedHdls[]に保存される。
新しいFPUオーナーを割り当てるために、ナノカーネルは、カーネルコンテキストからFPU状態を復元し、FPビットの以前に保存された状態をMSRイメージに復元する。さらに、FPUを所有している間にFP使用不能例外をネイティブな形で処理するために、ネイティブ例外ハンドラが、savedHdls[]テーブルからカーネルコンテキストのhdls[]テーブルに復元される。
ナノカーネルは、レイジイFPU切替を実装するためにMSRレジスタのFPビットを使用するので、カーネルは、FPUのオーナーでない(ネイティブFP使用不能例外ハンドラの外部である)間にこのビットの状態を変更することを許可されない。具体的には、これは、FPUエミュレーションが、ナノカーネルアーキテクチャに移植されたカーネルによってサポートされないことを意味する。
通常、オペレーティングシステムカーネルが、プロセス間のレイジイFPU切替を実装するためにMSRレジスタのFPビットも使用することに留意されたい。MSRレジスタイメージは、カーネルコンテキストに加わり、したがって、システム切替時に保存され、復元されるので、ネイティブFPU管理を、ナノカーネル環境でほとんど無変更のままに保つことができる。
同一の機構が、一部のPowerPCプロセッサ実装に統合されたベクトル計算ユニット(AltiVec)に使用される。その場合に、MSRレジスタのVUビットが、FPビットがFPUに対して行うのと同一の役割を演じる。また、ベクトル使用不能例外(ベクトル0×0f20)が、レイジイな形でSIMDユニットのコンテキスト切替を実装するためにインターセプトされる。
他の態様および実施形態
前述から、上で説明した実施形態が例にすぎず、多数の他の実施形態が可能であることは明らかである。言及したオペレーティングシステム、プラットフォーム、およびプログラミング技法は、すべて、自由に変更することができる。当業者に明白な他のすべての変更、置換、および変形は、添付請求項に含まれるものであってもそうでなくても、本発明の範囲内と考えられなければならない。不確かさをなくすために、本明細書で開示されたすべての新規の主題およびその組合せについて、保護が求められる。
本発明を実行できるコンピュータシステムの要素を示すブロック図である。 従来技術のソフトウェアの構成を示す図である。 本発明によるソフトウェアの構成を示す対応する図である。 図1のコンピュータのために図2bのソフトウェアを作成するステージを示す流れ図である。 図2bの一部を形成するハードウェアリソースディスパッチャのコンポーネントを示す図である。 ブートおよび初期化シーケンスで使用されるプログラムを示す図である。 ブートプロセスまたは初期化プロセスで使用されるシステムメモリイメージを示す図である。 主オペレーティングシステムから副オペレーティングシステムへの遷移を示す図である。 副オペレーティングシステムから主オペレーティングシステムへの遷移を示す図である。 (a)は、本発明による、異なるオペレーティングシステムで動作するアプリケーションの間の通信を示す図であり、(b)は、本発明による、異なるコンピュータの異なるオペレーティングシステムで動作するアプリケーションの間の通信を示す図である。 主、副、およびナノカーネルの仮想アドレス空間の例を示す図である。 メモリコンテキストが経時的にどのように切り替わるかを示す図である。 ナノカーネルコンテキストの可視部分を示す図である。 実行の流れと、ナノカーネルスタックが割込み処理および主カーネル再入を可能にするのにどのように使用されるかを示す図である。

Claims (32)

  1. 複数の異なるオペレーティングシステムを同一コンピュータ上で同時に動作させる方法であって、
    相対的に高い優先順位を有する第1のオペレーティングシステムを選択するステップと、
    相対的に低い優先順位を有する少なくとも1つの第2のオペレーティングシステムを選択するステップと、
    所定の条件に従って前記各オペレーティングシステムをこれらの間で切り替えるように組まれた共通プログラムを提供するステップと、
    前記第1および第2のオペレーティングシステムが前記共通プログラムによって制御されるようにするために、前記第1および第2のオペレーティングシステムに対して修正を加えるステップと、
    を含む方法。
  2. 前記各オペレーティングシステムの間の切替が、例外ベクトルを使用して前記共通プログラムを呼び出すことを含む、請求項1に記載の方法。
  3. 割込みベクトルをトラップ呼出しに割り振ることにより、トラップ呼出し機構を使用する前記共通プログラムの呼出しを可能とするステップを含む、請求項2に記載の方法。
  4. 前記第1または第2のオペレーティングシステムが、例外ベクトルを呼び出すことによって前記共通プログラムを呼び出す、請求項2または3に記載の方法。
  5. 前記共通プログラムを呼び出すために例外ベクトルを呼び出すことが、外部イベントによって引き起こされる例外をシミュレートする、請求項4に記載の方法。
  6. 前記共通プログラムが、例外または割込みベクトルをインターセプトすることによって前記第1または第2のオペレーティングシステムをプリエンプトする、請求項1〜請求項5のいずれか一項に記載の方法。
  7. 例外をインターセプトするためにポインタの配列を含む例外ハンドラテーブルを使用するステップと、前記第1または第2のオペレーティングシステムをプリエンプトするために例外ハンドラプログラムをアクティブ化するステップとをさらに含む、請求項6に記載の方法。
  8. 前記共通プログラムが、リアルモードで動作する、請求項1〜請求項7のいずれか一項に記載の方法。
  9. 前記共通プログラムによって前記第1または第2のオペレーティングシステムをプリエンプトするステップと、前記第1または第2のオペレーティングシステムをプリエンプトするときにリアルモードに切り替えるステップとを含む、請求項8に記載の方法。
  10. 前記第1または第2のオペレーティングシステムによって前記共通プログラムを呼び出すステップと、前記共通プログラムを呼び出すときにリアルモードに切り替えるステップとを含む、請求項8に記載の方法。
  11. マシン状態を保存するサブルーチンの動作中を除いて、前記第2のオペレーティングシステムの動作中全体に渡り、ハードウェア割込みをイネーブルするステップを含む、請求項1〜請求項10のいずれか一項に記載の方法。
  12. 前記第1のオペレーティングシステムが、リアルタイムオペレーティングシステムである、請求項1〜請求項11のいずれか一項に記載の方法。
  13. 前記第2のオペレーティングシステムが、非リアルタイムの汎用オペレーティングシステムである、請求項1〜請求項12のいずれかに記載の方法。
  14. 前記第2のオペレーティングシステムが、Linuxまたはその版もしくはその変形である、請求項1〜請求項13のいずれか一項に記載の方法。
  15. 前記共通プログラムが、前記各オペレーティングシステムの間で切り替えるのに必要なプロセッサ状態を保存し、保存された版から復元するように構成される、請求項1〜請求項14のいずれか一項に記載の方法。
  16. 前記第2のオペレーティングシステムに関するプロセッサ例外が、前記共通プログラムによって仮想的な形で処理される、請求項1〜請求項15のいずれか一項に記載の方法。
  17. 前記共通プログラムが、いくつかのプロセッサ例外をインターセプトし、それらにサービスするために前記第1のオペレーティングシステムの例外処理ルーチンを呼び出すように構成される、請求項1〜請求項16のいずれか一項に記載の方法。
  18. 前記第2のオペレーティングシステムに関する前記プロセッサ例外が、仮想例外として通知される、請求項17に記載の方法。
  19. 前記共通プログラムが、保留中である前記仮想例外に対応する前記第2のオペレーティングシステムの例外処理ルーチンを呼び出すように構成される、請求項18に記載の方法。
  20. 前記オペレーティングシステムのそれぞれに、前記オペレーティングシステムのそれぞれがその中で排他的に動作できる別々のメモリ空間を提供するステップをさらに含む、請求項1〜請求項19のいずれか一項に記載の方法。
  21. 前記オペレーティングシステムのそれぞれに、前記オペレーティングシステムのそれぞれが排他的にアクセスできる前記コンピュータの第1の入力デバイスおよび/または出力デバイスを提供するステップをさらに含む、請求項1〜請求項20のいずれか一項に記載の方法。
  22. 各オペレーティングシステムが、実質的に変更されないネイティブルーチンを使用して前記第1の入力デバイスおよび/または出力デバイスにアクセスする、請求項21に記載の方法。
  23. 前記オペレーティングシステムのそれぞれに、前記オペレーティングシステムのそれぞれが共用アクセスを有する前記コンピュータの第2の入力デバイスおよび/または出力デバイスへのアクセスを提供するステップをさらに含む、請求項1〜請求項22のいずれか一項に記載の方法。
  24. すべてのオペレーティングシステムが、前記第1のオペレーティングシステムのルーチンを使用して前記第2の入力デバイスおよび/または出力デバイスにアクセスする、請求項23に記載の方法。
  25. 前記共通プログラムが、前記第2のオペレーティングシステムの動作を制御するトラップ呼出し機構、および/または、前記第2のオペレーティングシステムの状況変化について前記第1のオペレーティングシステムに通知するイベント機構を提供する、請求項24に記載の方法。
  26. 前記オペレーティングシステムおよび共通プログラムを単一コード製品に組み合わせるステップをさらに含む、請求項1〜請求項25のいずれか一項に記載の方法。
  27. 前記各オペレーティングシステムおよび共通プログラムをコンピュータ製品上の永続メモリに組み込むステップをさらに含む、請求項1〜請求項26のいずれか一項に記載の方法。
  28. 請求項1〜請求項27のいずれかの前記ステップを実行するコードを含むデベロッパキットコンピュータプログラム製品。
  29. 請求項36に従って組み合わされたコードを含むコンピュータプログラム製品。
  30. CPU、メモリデバイス、および入出力デバイスを備えるコンピュータシステムであって、
    相対的に高い優先順位を有する第1のオペレーティングシステムと、
    相対的に低い優先順位を有する第2のオペレーティングシステムと、
    所定の条件の下で前記各オペレーティングシステムの間でこれらを切り替えることによって、前記オペレーティングシステムを同時に動作させるように構成された共通プログラムと、
    を含む、コンピュータコードをその上で実行する、コンピュータシステム。
  31. 請求項1〜27のいずれか一項に記載の方法を使用して前記第1および第2のオペレーティングシステムを同時に動作させるように構成された、請求項30に記載のコンピュータシステム。
  32. 前記コンピュータが、縮小命令セットアーキテクチャを有する、請求項1〜請求項31のいずれか一項に記載のシステム、製品、または方法。
JP2006530758A 2003-10-01 2004-10-01 オペレーティングシステム Pending JP2007507779A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP03292428 2003-10-01
PCT/IB2004/003344 WO2005033928A2 (en) 2003-09-22 2004-10-01 Operating systems

Publications (1)

Publication Number Publication Date
JP2007507779A true JP2007507779A (ja) 2007-03-29

Family

ID=37870414

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006530758A Pending JP2007507779A (ja) 2003-10-01 2004-10-01 オペレーティングシステム

Country Status (3)

Country Link
JP (1) JP2007507779A (ja)
KR (1) KR20070003765A (ja)
CN (1) CN1942859A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008305070A (ja) * 2007-06-06 2008-12-18 Hitachi Communication Technologies Ltd 情報処理装置および情報処理装置システム
JP2009211505A (ja) * 2008-03-05 2009-09-17 Nec Corp エミュレータ、エミュレーション方法、プログラム、及び、記録媒体
JP2015041199A (ja) * 2013-08-21 2015-03-02 キヤノン株式会社 情報処理装置

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9098437B2 (en) 2010-10-01 2015-08-04 Z124 Cross-environment communication framework
US8726294B2 (en) * 2010-10-01 2014-05-13 Z124 Cross-environment communication using application space API
CN105183555A (zh) * 2010-01-13 2015-12-23 马维尔以色列(M.I.S.L.)有限公司 用于媒体处理的硬件虚拟化
DE102011116144B4 (de) * 2011-10-15 2013-06-27 Festo Ag & Co. Kg Kopplungseinrichtung und Verfahren zurAnsteuerung von austauschbarenelektrischen Systemen
CN105512000B (zh) * 2014-09-24 2020-04-24 中兴通讯股份有限公司 一种操作***异常信息收集方法、装置及计算机
US20160110235A1 (en) * 2014-10-17 2016-04-21 D2 Technologies Inc. Electronic device for Internet Protocol Communications
KR102513961B1 (ko) * 2015-11-11 2023-03-27 삼성전자주식회사 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법
US10282812B2 (en) * 2017-04-09 2019-05-07 Intel Corporation Page faulting and selective preemption
JP6786010B2 (ja) * 2018-05-07 2020-11-18 三菱電機株式会社 情報処理装置、チューニング方法およびチューニングプログラム
CN112470125B (zh) * 2018-07-24 2024-02-20 三菱电机株式会社 中断处理方法、计算机***以及存储介质
CN109520079B (zh) * 2018-11-08 2021-07-23 广东美的制冷设备有限公司 空调器及其控制方法、装置及计算机可读存储介质
CN111124664B (zh) * 2019-11-22 2023-12-08 华为技术有限公司 第一操作***访问第二操作***资源的方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0193830A (ja) * 1987-10-05 1989-04-12 Nec Corp 仮想計算機システムにおける割り込み制御方式
JP2000181748A (ja) * 1998-12-11 2000-06-30 Hitachi Ltd マルチメモリ空間プログラムのデバッグシステムおよびそのデバッグ方法
JP2000347883A (ja) * 1999-06-03 2000-12-15 Matsushita Electric Ind Co Ltd 仮想計算機装置
JP2001022598A (ja) * 1999-07-07 2001-01-26 Hitachi Ltd 計算機システム
JP2001243080A (ja) * 2000-03-02 2001-09-07 Hitachi Ltd 情報処理装置
JP2001282558A (ja) * 2000-03-30 2001-10-12 Hitachi Ltd マルチオペレーティング計算機システム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0193830A (ja) * 1987-10-05 1989-04-12 Nec Corp 仮想計算機システムにおける割り込み制御方式
JP2000181748A (ja) * 1998-12-11 2000-06-30 Hitachi Ltd マルチメモリ空間プログラムのデバッグシステムおよびそのデバッグ方法
JP2000347883A (ja) * 1999-06-03 2000-12-15 Matsushita Electric Ind Co Ltd 仮想計算機装置
JP2001022598A (ja) * 1999-07-07 2001-01-26 Hitachi Ltd 計算機システム
JP2001243080A (ja) * 2000-03-02 2001-09-07 Hitachi Ltd 情報処理装置
JP2001282558A (ja) * 2000-03-30 2001-10-12 Hitachi Ltd マルチオペレーティング計算機システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008305070A (ja) * 2007-06-06 2008-12-18 Hitachi Communication Technologies Ltd 情報処理装置および情報処理装置システム
JP2009211505A (ja) * 2008-03-05 2009-09-17 Nec Corp エミュレータ、エミュレーション方法、プログラム、及び、記録媒体
JP2015041199A (ja) * 2013-08-21 2015-03-02 キヤノン株式会社 情報処理装置

Also Published As

Publication number Publication date
KR20070003765A (ko) 2007-01-05
CN1942859A (zh) 2007-04-04

Similar Documents

Publication Publication Date Title
US9619279B2 (en) Operating systems sharing supervisor address space with same virtual to physical mapping for supervisor address space using same translation formula with different translation tree
US8024742B2 (en) Common program for switching between operation systems is executed in context of the high priority operating system when invoked by the high priority OS
US8612992B2 (en) Operating systems
US7434224B2 (en) Plural operating systems having interrupts for all operating systems processed by the highest priority operating system
Dike A user-mode port of the Linux kernel
US9009701B2 (en) Method for controlling a virtual machine and a virtual machine system
EP1669864B1 (en) A process for managing virtual machines in a physical processing machine, corresponding processor system and computer program product therefor
US9164784B2 (en) Signalizing an external event using a dedicated virtual central processing unit
JP2009537897A (ja) 実行中のオペレーティングシステムの下でのハイパーバイザの起動
JP2007507779A (ja) オペレーティングシステム
US20050251803A1 (en) Method of performing kernel task upon initial execution of process at user level
Kanda et al. SIGMA system: A multi-OS environment for embedded systems
EP1673697B1 (en) Operating systems
EP1616257B1 (en) Operating systems
Tan et al. How Low Can You Go? Practical cold-start performance limits in FaaS
EP1673693B1 (en) Operating systems
Poess Feasibility Study of Building a User-mode Native Windows NT VMM

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070911

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091117

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100511