JP2008506187A - 複数のカーネルの並列実行のための方法およびシステム - Google Patents

Abstract

共通割込みハンドラおよびオプションの共通スケジューラを使用して複数のカーネルを並列実行するための手法が提供される。また、カーネル間で実行を切り替えるための技法も提供される。カーネル間の実行および割込みの優先権は、割込みマスクレベルを使用して示される。また、異なるカーネル上で実行しているタスク間のリソースの共有のための技法も提供される。

Description

関連出願の相互参照
本ＰＣＴ特許出願は、合衆国法典第３５編１１９条（ｅ）項のもとで、２００４年７月６日出願の米国仮出願第６０／５８６，４８６号の優先権の利益を主張する。

本発明は、一般に、マルチタスク・オペレーティングシステムに関する。より詳細には、本発明は、共通割込みハンドラおよびスケジューラを使用して複数のカーネルの実行を可能にすることによって、単一オペレーティングシステムにおいて複数のカーネルの機能をサポートすることに関する。

オペレーティングシステムは、それらが使用される特定の用途に基づいて、設計され、一般にそれらの動作が最適化される。一方のタイプのオペレーティングシステムの機能が、他方のタイプのオペレーティングシステムにおいて使用可能であることが望ましいことがしばしばある。

例えば、Ｌｉｎｕｘ（登録商標）やＷｉｎｄｏｗｓ（登録商標）のような汎用コンピュータ・オペレーティングシステムは、ファイルシステム、デバイスドライバ、アプリケーション、およびライブラリなどのような機能の広範なセットを有する。このようなオペレーティングシステムは、複数のプログラムの並列実行を可能にし、プログラムの並列実行のサービスに関連する、（待ち時間とも呼ばれる）応答時間、およびＣＰＵ使用率または負荷の最適化を試みる。しかし、遺憾なことに、このようなオペレーティングシステムは、一般に、例えば、ロボット、通信システム、工作機械、および自動車システムの制御などのような組込みリアルタイムアプリケーションに適していない。これらおよび他の多数のような現実世界のイベントおよび制御に基づくアプリケーションは、いわゆるハードリアルタイム性能を必要とする。ハードリアルタイム性能は、最悪応答時間を保証する。汎用オペレーティングシステム（ＧＰＯＳ）は、一般に、アプリケーションプログラムの平均性能に対するプログラム実行時間の予測可能性について妥協している。ｉＴＲＯＮを含むいくつかの知られているリアルタイム・オペレーティングシステム（ＲＴＯＳ）などは、ハードリアルタイム機能を提供する。しかし、遺憾ながら、ほとんどのＲＴＯＳは、ＧＰＯＳ機能を有しておらず、例えば、異なるファイルシステム、デバイスドライバ、およびアプリケーションライブラリなどに対するサポートを提供しない。多くのアプリケーションにおいて、ＲＴＯＳの性能、および汎用オペレーティングシステムの機能を有することが望まれる。

例えば、Ｌｉｎｕｘ（登録商標）は、現代的なオペレーティングシステム機能、多数の開発ツール、およびネットワーキングなどを含む現代的なデバイスのための多くの望ましい機能を有する、周知の汎用オペレーティングシステムである。しかし、Ｌｉｎｕｘ（登録商標）は、組込みオペレーティングシステムとして設計されなかった。セットトップボックス、携帯電話、およびカーナビゲーション・システムなどを限定としてではなく含む現代的デバイスは、Ｌｉｎｕｘ（登録商標）のような汎用オペレーティングシステムの機能だけではなく、リアルタイム性能のような組込みオペレーティングシステムの機能も必要とする。

例えば、ｉＴＲＯＮは、多数の組込みデバイスで一般的に使用される、成熟したリアルタイム組込みオペレーティングシステムである。ｉＴＲＯＮは、組込みデバイスのための多数の望ましい機能を有するが、ネットワーキングや異なるファイルシステムのサポートのようなＬｉｎｕｘ（登録商標）の機能を欠いている。

ＧＰＯＳとＲＴＯＳをともに必要とする例は、自動車で使用されるナビゲーションシステム用の制御装置である。この制御装置は、ＧＰＳセンサからデータを読み取って、自動車の位置および方向を計算する。現在の位置、目的地、および、ナビゲーションデータＤＶＤから抽出されたトポロジカルマップに基づいて、制御装置は、最良経路を計算して液晶表示画面に表示する。液晶表示画面は、ナビゲーションシステムにパラメータを入力するためのタッチパネルに重畳されることがある。センサやタッチパネル入力の読取りのタスクが、ハードリアルタイムを必要とする一方、経路の計算、グラッフィックスの表示、およびＤＶＤからの読取りのタスクは、標準的なプログラミングタスクであり、汎用オペレーティングシステムの機能を使用する。ハードリアルタイム性能は、ｉＴＲＯＮのようなＲＴＯＳカーネルを使用して実現されうるが、汎用タスクは、Ｌｉｎｕｘ（登録商標）カーネル上で実行されうる。

別の必要例は、ビデオデータ圧縮ハードウェアを使用した固体デジタルビデオカメラ用の制御装置である。このようなアプリケーションでは、圧縮ハードウェアから来るデータストリームを読み取り、画像処理機能を実行するとともに、液晶表示画面上に表示を行い、取外し可能記憶媒体にデータを記憶することが望ましい。また、例えば、同じ制御システムを使用して、光学ズームおよびオートフォーカス機構を管理することが必要なことがある。システムがいくつかのレガシ・コンポーネントを使用する場合、特定のＲＴＯＳ（例えば、ｉＴＲＯＮ）に使用可能な広範な制御ソフトウェアが、既に存在することがある。モータならびにデータ収集および格納を制御するタスクが、ハードリアルタイム・オペレーティングシステム（ｈＲＴＯＳ）によって最適に処理されうる一方で、表示、画像処理、および他の機能は、一般にＧＰＯＳのもとで、標準的プログラミングによって、より適切に処理されうる。更に、一般に、ｉＴＲＯＮで使用可能な広範なソフトウェアを別のＲＴＯＳに移植することは、かなり費用がかかり、ｉＴＲＯＮで表示およびファイルシステムのサポートなどを提供することも同様に簡単ではない。したがって、例えば、ＲＴＯＳおよび汎用オペレーティングシステムの強みを組み合わせたシステムが、このアプリケーションに最適となる。

別の必要例は、特定の機能の加速または特定の機能性の追加のために専用ハードウェアの使用を必要とするシステムである。例えば、多くのマルチメディアデバイスでは、オーディオまたはビデオ用にグラフィックス・アクセラレータ・チップあるいはＤＳＰまたはＣＯＤＥＣを使用する必要がある。いくつかの事例では、オペレーティングシステムが、いくつかのタスクについて保証された性能を提供できる場合に、追加のハードウェアの必要性が解消されうる。例えば、ストリーミング・オーディオをサポートするシステムでは、パケットロスを防止し出力の一定の品質を維持するために、圧縮されエンコードされたオーディオの一定のレートでのデコードを保証する、高性能タスクを有することが必要なことがある。ＧＰＯＳおよびＲＴＯＳからなるシステムは、いくつかの事例では、専用のハードウェアの必要性を解消することが可能であり、したがって製品の費用を削減することができる。

すべての現実世界のシステムは、ハードリアルタイム（ＨＲＴ）、ソフトリアルタイム（ＳＲＴ）、または非リアルタイム（ＮＲＴ）システムに分類することができる。ハードリアルタイム・システムは、１つまたは複数のアクティビティが必ず期限またはタイミング制約に間に合わなければならず、さもなければタスクが失敗したといわれるシステムである。ソフトリアルタイム・システムは、タイミング要件を有するが、全体としてアプリケーション要件が満たされ続ける限り、時折タイミング要件に間に合わなくてもその影響を無視することができるシステムである。最後に、非リアルタイム・システムは、ハードリアルタイムでもソフトウェアリアルタイムでもないシステムである。非リアルタイム・タスクは、どんな期限またはタイミング制約も有していない。現代的なアプリケーションの多くにおいては、リアルタイム・システム性能の全範囲をサポートする必要がある。例えば、セキュリティアプリケーションのためのネットワーク機器の要件を検討する。ネットワーク機器は、１つのパケットも損なわずに、高速ネットワーク接続を介してすべてのネットワークパケットをサンプリングする必要があることがある（ハードリアルタイム・タスク）。ハードリアルタイム・タスクは、これらのパケットを後で処理するためにバッファに蓄える。これは、ｈＲＴＯＳを使用して実現されうる。バッファ内のこれらのパケットサンプルは、処理され分類される必要があるが、場合によっては、そこで処理および分類の速度が落ちても、バッファがオーバフローしない限り問題とならない（ソフトリアルタイム・タスク）。これは、ｈＲＴＯＳおよびＧＰＯＳにおけるタスクの組合わせを用いて実現されうる。ウェブサーバは、要求に応じて、処理および分類されたデータを送達するために使用されうる。このアクティビティには一般にタイミング制約は存在せず（すなわち、非リアルタイム・タスク）、したがって、このタスクは、ＧＰＯＳにおいて行うことができる。

上記に鑑みて、複数のカーネルの性能および機能を効率的かつ好都合に提供し、リアルタイム性能の全範囲をサポートする、マルチカーネル環境（例えば、ＧＰＯＳおよびＲＴＯＳ）を実装するシステムが、必要とされる。

本発明は、添付の図面の図において限定ではなく例として例示され、図面では、同様の参照番号は同様の要素を参照する。

他に指示がない限り、図中の例示は、必ずしも原寸に比例して描かれていない。

上記および他の目的を達成するために、かつ本発明の目的に従って、複数のカーネルの並列実行、および複数のカーネル間のリソースの共有のための、様々な技法が提供される。

マルチカーネル環境における複数のカーネルの並列実行のための方法、システム、コンピュータコード、および手段が説明される。本発明の方法の一実施形態では、１次および少なくとも１つの２次カーネルが構成され、少なくとも１つの２次カーネルは、１次カーネルの少なくとも部分的制御下にあり、オプションの共通スケジューラは、１次カーネルと２次カーネルの少なくとも１つとに保留しているプロセスの実行を、スケジュールするように構成され、共通割込みハンドラは、１次カーネルと２次カーネルの少なくとも１つとにおける割込みプロセスの割込みおよび実行を処理するように構成される。別の実施形態により、上記の方法を実装するための手段も提供される。更に別の実施形態により、上記の方法を実装するためのコンピュータコードも提供される。

マルチカーネル環境において複数のカーネル間でシステムリソースを共有するための本発明の他の方法実施形態であって、１次および少なくとも１つの２次カーネルが構成され、少なくとも１つの２次カーネルは、１次カーネルの少なくとも部分的制御下にあり、カーネル間のシステムリソースの共有のためのアプリケーション・プログラム・インターフェース（ＡＰＩ）が構成され、呼出しカーネルには、他のカーネルのうち少なくともいくつかに対する適切なダミーＡＰＩコールが提供される、方法実施形態が提供される。更に別の実施形態により、上記の方法を実装するための手段も提供される。更に別の実施形態により、上記の方法を実装するためのコンピュータコードも提供される。

本発明の他の特徴、利点、および目的は、添付の図面と併せて読まれるべき以下の詳細な説明から、より明らかになり、より容易に理解されるであろう。

本発明は、本明細書に示す詳細な図および説明を参照することによって最も理解される。

本発明の実施形態は、図を参照して以下で説明される。しかし、本明細書でこれらの図について与えられる詳細な説明は、説明が目的であり、本発明はこれらの限定された実施形態を超えて拡張されることは、当業者には容易に理解されるであろう。

以下でいくらか詳しく説明される本発明の一態様は、２つ以上のオペレーティングシステム・カーネルが、両方のオペレーティングシステム・カーネルの機能および能力を保持しながら動作することである。

一般に、マルチカーネルシステムを開発する動機は、多数ありうる。４つの理由を挙げる。
１．一方のカーネルの性能特性が、他方において望ましいことがある（リアルタイム機能性が、汎用オペレーティングシステムにおいて望ましいことがある。）、
２．一方のオペレーティングシステム（またはカーネル）の機能が、他方において望ましいことがある（例えば、ファイルシステム、デバイスドライバ、リアルタイムＡＰＩ、ライブラリ）、
３．いくつかの事例では、マルチカーネルシステムの使用によって専用ハードウェアの必要性を解消し、それによって製品の費用を削減する、
４．リアルタイム性能の全範囲をサポートできるｈＲＴＯＳおよびＧＰＯＳからなるシステムの必要性がありうる。

図１は、本発明の実施形態による、１つのハードウェアプラットフォーム上で複数のカーネルの実行を可能にする例示的アーキテクチャを示す線図である。この図に示されるように、カーネル０、カーネル１、カーネル２、およびカーネルｎとラベル付けされた複数のカーネルが、「ＣＰＵ」とラベル付けされた従来の中央処理装置上で実行されている。図および以下の開示では、単一ＣＰＵシステムのコンテキストで実施形態および例を示し説明するが、本発明は、単一ＣＰＵ実装に限定されず、本発明の教示に照らし、知られている技法によって、マルチＣＰＵシステムを用いて本発明の教示を適切に実施するよう適宜に構成されうることは、理解されるべきである。本明細書では、カーネル０は、１次カーネルと呼ばれ、カーネル１、カーネル２、…、カーネルｎは、カーネル０によって実行されている特定の数のカーネルを表し、一般に、カーネルの数は、システムリソースによって制限されうる。カーネルは、汎用オペレーティングシステム（ＧＰＯＳ）またはリアルタイム・オペレーティングシステム（ＲＴＯＳ）に属することができ、それぞれは、提供された機能および能力が大きく異なることがある。

次に、本発明のカーネルの選択の態様が、いくらか詳しく説明される。図２は、本発明の実施形態による、複数のカーネルを並列実行するための方法のフローチャートである。本プロセスにおける各ステップは、後続の図において別個により詳細に例示される。プロセスの開始において、１次カーネル（カーネル０）として、汎用オペレーティングシステムまたはたいていの能力および機能を有するオペレーティングシステムのカーネル（例えば、図１のカーネル）が、ステップ２１０で選択され、ステップ２２０で始動される。本例のコンテキストでは、カーネルの始動は、ハードウェアの電源投入、および、カーネル０を適切にロードまたは実行するブートローダをロードすることを含む。カーネル０は、始動すると、割込みハンドラ、スケジューラ、タスクマネージャなどを始動し、適切なドライバをインストールすることによってシステムハードウェアを初期化する。次に、ステップ２３０で、１次カーネルにおいて、使用可能でない所与のターゲットアプリケーションに望ましい、あるいは他の望ましい特定の機能を有するカーネルが、１次カーネルの動的モジュール（例えば、カーネル１、カーネル２、…、カーネルｎ）として追加される。このプロセスは、ステップ２３０で、すべての所望のカーネルが追加されるまで、ステップ２３０にループして戻る。

各２次カーネルには、アクティブ化されるとき、一意のカーネル識別手段（ＩＤ）が割り当てられることが好ましく、この識別の有用性は、以下にいくらか詳しく例示される。これらのカーネルＩＤは、好ましくは、予め割り当てられる。ステップ２４０で、予め割り当てられた割込みマスクおよびカーネルＩＤに従って、１次カーネルによって、追加カーネルが選択され、その後、ステップ２５０で、追加カーネル、すなわち２次カーネルであるカーネル１、カーネル２、…、カーネルｎが、動的モジュールとしてアクティブ化される。

図３は、本発明の実施形態による、図２に示される１次カーネルの選択のための例示的方法のフローチャートを示す。プロセスは、ステップ３１０で、最も望ましい能力および機能を有する共通割込みハンドラを選択することから開始する。次いで、ステップ３２０で、共通割込みハンドラが属するカーネルが、１次カーネルに指定される。ステップ３３０で、共通スケジューラとして、スケジューラが選択される。このスケジューラは、１次カーネルのスケジューラであっても、他の任意のカーネルのスケジューラであってもよい。特定のアプリケーションの必要に応じて、本発明の代替実施形態は、実装されることができ、さもなければ、１次カーネルおよび／または本システムが任意の適切な割込みハンドラまたはスケジューラを使用することを可能にすることができる。本発明の更に他の実施形態では、１次制御カーネルがなくてもよく、代わりに、マルチカーネルシステムにおけるすべてのカーネルは、共通タスクスケジューラおよび共通割込みハンドラによって制御され、直接互いを制御しない。本発明の更に他の実施形態では、１次カーネルの割込みハンドラが使用されなくてよく、代わりに、別の割込みハンドラが１次カーネルの外部に実装され、この状況において、割込みハンドラ・エミュレータが既知の技法によって実装でき、さもなければ、本発明の他の新規の態様が実装されうる。本実施形態では、そのデフォルトの割込みハンドラが共通割込みハンドラとして使用されるカーネルが、自動的にマルチカーネルシステムの１次カーネルになることを理解されたい。更に、いくつかのアプリケーションでは、システム設計者が、１次カーネルのデフォルト割込みハンドラを除去して別の割込みハンドラに置き換えることを選択してもよく、いずれの場合も、１次カーネルに使用可能である有効な割込みハンドラは、本実施形態の用途のために、そのカーネルの一部分と見なされることを理解されたい。本発明の教示による共通割込みハンドラの他の適切な実装変形形態の多様性は、当業者には容易に明らかとなろう。

図に戻ると、一意のＩＤ、および割込みマスクレベルがそれぞれ、ステップ３４０およびステップ３５０で１次カーネルに割り当てられる。割込みマスクレベルは、後でいくらか詳しく説明される。

図４は、本発明の実施形態による、図２に示される１次カーネルを始動するための例示的方法のフローチャートを示す。プロセスは、ステップ４１０で、１次カーネルの共通割込みハンドラをインストールすることから開始する。次いで、ステップ４２０で、共通スケジューラがインストールされる。ステップ４３０で、共通アプリケーション・プログラム・インターフェース（ＡＰＩ）が、リソース共有のためにインストールされる。１つまたは複数の２次カーネルがあるかどうか、あるいは、選択された２次カーネルのどの特定のリソースがリソース共有のために使用可能であるかは、予め知られていない。リソース共有のための共通ＡＰＩは、リソースＡＰＩの詳細についての事前知識なしに、リソースの無制限の共有を可能にする。ステップ４４０で、特定のアプリケーションに依存する所望の切替え方式に従って２次カーネルに実行を切り替える、周期タスクまたはプロセスが、インストールされる。好ましい実施形態では、カーネル間の切替えは、ハードウェアタイマ割込みによってトリガされる。特定のアプリケーションの必要に応じて、当業者が、本発明の教示に照らして、場合によっては、非周期またはイベント駆動方式の他の適切な切替えを考案することができる。限定ではなく例として、周期、非周期、イベントベース、および優先順位ベースの方式を含む、適切なカーネル切替え方式が、カーネル間の切替えのために使用されうる。

図５は、本発明の実施形態による、図２に示される２次カーネルの選択および追加のための例示的方法のフローチャートを示す。プロセスは、ステップ５１０で、マルチカーネル・ソフトウェアがインストールされるシステムの要件から導かれる望ましい能力および機能の集合を有する２次カーネルを選択することから開始する。一意のＩＤ、および割込みマスクレベルがそれぞれ、ステップ５２０およびステップ５３０で２次カーネルに割り当てられる。

図６は、本発明の実施形態による、図２に示される２次カーネルを始動するための例示的方法のフローチャートを示す。プロセスは、ステップ６１０で、２次カーネル用の「フック」として知られるものを、１次カーネルの共通割込みハンドラ内にインストールすることから開始する。次いで、ステップ６２０で、２次カーネルに対するフックは、共通スケジューラ内にインストールされる。ステップ６３０で、２次カーネルに対するフックは、共通アプリケーション・プログラミング・インターフェース（ＡＰＩ）内にインストールされる。フックは、１次カーネル内の制御アプリケーション（例えば、割込みハンドラ、スケジューラ、または共通ＡＰＩ）から、フックが関連付けられる特定の２次カーネルへの制御経路を有効にする。

次に、本発明の割込みマスキングおよびカーネル優先順位の態様がいくらか詳しく説明される。すべての現代的なコンピューティングシステムは、選択的に有効または無効にされうる割込みを有する。割込みマスクレベルは、プロセッサに割り込むために、どの割込みが許可され、どの割込みが許可されないかを決定する。図７は、本発明の実施形態による、複数のカーネルについての共通割込みハンドラおよび共通スケジューラの例示的アーキテクチャを示すブロック図である。図において、カーネル０に対するマスクレベルは、すべての割込みが許可されるようになされている。本発明の好ましい実施形態では、各２次カーネルは、カーネルが実行されているときのみ有効にされる割込みの範囲が割り当てられる。これは、本実施形態では、マスクレベルの使用によって実現される。

たいていの現代的なプロセッサは、割込みマスクレベルをサポートする。上記のように、カーネルマスクレベルは、どの割込みがカーネルによって許可され、どの割込みが許可されないかを決定する。ただし、割込みがカーネルによって許可されても、カーネルによって処理されないことがあることに留意すべきである。したがって、本実施形態は、カーネルおよび割込みについて３つの割込み条件、すなわち、（１）割込みが、ブロックされうる、（２）割込みが、許可されうるが処理されない、および、（３）割込みが、許可されカーネルによって処理されうる（取り扱われうる）、を有する。ある特定のカーネルによって許可され処理された割込みは、そのカーネルに割り当てられたといわれる。更に、すべての割込みは、カーネル０によって許可され処理される。各割込みはまた、任意の他のカーネルに一意的に割り当てられうる。したがって、本発明の手法では、割込みは、カーネル０によって許可され処理されなければならず、かつ、他の唯一のカーネルによって許可され処理されうる。本発明のいくつかの実施形態は更に、ＣＰＵの設計によってまたは当業者に知られる他の手段によって指示されうる優先順位を有する割込みを提供する。

本実施形態の一般的なアプリケーションでは、マルチカーネルシステムの設計の際、割込みの優先順位は、好ましくは、最も高い優先順位の割込みが、最も高い実行の優先順位を有するカーネルに割り当てられるように指定される。図に示されるように、カーネル１はカーネル０より高い優先順位を有し、カーネル２はカーネル１より高い優先順位を有し、以下同様である。カーネルｎは、最も高い優先順位を有する。したがって、カーネル０は、カーネル１、カーネル２、…、カーネルｎによって優先割り込みされうる。カーネル１は、カーネル２からカーネルｎまでによって優先割り込みされうる。カーネルｎは、いずれのカーネルによっても優先割り込みされることがない。他の代替の適切な割込み優先順位方式は、本発明の教示に照らして、当業者には容易に明らかとなろう。

次に、本発明の割込み処理の態様が、いくらか詳しく説明される。本発明の新規の態様は、共通割込みハンドラが最初に選択されることである。共通割込みハンドラが関連付けられるカーネルは、１次カーネルと呼ばれる。好ましい実施形態では、すべての割込みは、カーネル０割込みハンドラによって処理される。割込みを受け取ると（７１０）、カーネル０は、非カーネル特定割込みサービスルーチンを実行し、次いで、その特定の割込みが割り当てられるカーネルの割込みハンドラに、制御を渡す。再び図を参照すると、カーネルｎに割り当てられる割込みＮが発生すると、まずカーネル０ハンドラによって割込みが処理され、次いで、カーネルｎの割込みサービスルーチンが呼び出され、この場合、カーネルｎは、本明細書では、ターゲットカーネルとして参照される（７２０）。割込みハンドラが呼び出されたとき、割込みハンドラは、カーネル非依存割込み処理機能を実行し、ターゲットカーネルの割込みサービスルーチンに制御を渡すことに留意すべきである。ターゲットカーネルは、好ましくは割込みマスクレベルを用いて識別される。このようにして、カーネル０の割込みハンドラは、マルチカーネルシステムのための共通割込みハンドラの役割をする。

図８は、図７のコンテキストにおける本発明の実施形態による、複数のカーネルについての割込みマスクレベルの例示的線図を示す。この図は、本実施形態における割込みマスクレベルが、各割込みごとのターゲットカーネルを決定するためにどのように使用されるかを示す。割込み番号は、チャートの左側または軸上の昇順番号として示され、Ｎは割込みの総数である。

垂直バーの網点（またはほぼ白抜き）の領域（８１０）は、それぞれのカーネルによって処理され許可される割込みを示す。斜線領域（８２０）は、それぞれのカーネルによって許可される割込みを示す。れんが模様領域（８３０）は、それぞれのカーネルが実行されているとき、すなわちＣＰＵ時間の制御において、ブロックされる割込みを示す。

図９は、本発明の実施形態による、図２のブロック図および図８のバーチャートに示される複数のカーネルについての割込みマスクレベルの更なる態様を示す。どの割込みがカーネルによって処理されることになりうるか、どの割込みがカーネルによって無効にされうるか、および、どの割込みが所与のカーネルによって有効にされうるかを、マスクレベルが、どのように決定するかについての例が、図に示される。割込み番号は、チャートの左側または軸上の昇順番号（９１０）として示され、Ｎは割込みの総数である。

詳細には、ｉ番目のカーネルが、最も右のバーの垂直バーにおけるＫｉとして示され、「ａｉ」（９２０）は、カーネルＫｉによって有効にされうる割込みを、「ｂｉ」（９３０）は、カーネルＫｉによって無効にされうる割込みを、「ｃｉ」（９４０）は、カーネルＫによって処理される割込みを示す。

次に、本発明のスケジューリングの態様が、いくらか詳しく説明される。ほとんどの従来のオペレーティングシステムでは、スケジューラは、ハードウェアタイマを使用して周期的に呼び出される。ハードウェアタイマは、通常、スケジューリングイベントを開始するために周期割込みをトリガするように設定される。マルチカーネルシステムにおける各カーネルは、オペレーティングシステムの用途に応じて、スケジューラを呼び出すための異なる周期を有することができる。限定としてではなく、例えば、汎用オペレーティングシステムの場合、１０ミリ秒周期が所望の性能に対して充分でありうる。しかし、リアルタイムカーネルの場合、各１００マイクロ秒後毎にスケジューリングイベントを有することが必要なことがある。

本実施形態では、共通スケジューラが、マルチカーネルシステムに対し選択される。すべてのスケジューリングイベントは、最初に共通スケジューラによって受け取られることが好ましい。カーネル非依存スケジューリング機能の実行後、スケジューラは、現在実行中のカーネルのスケジューラに制御を渡すことが好ましい（７３０）。この例では、現在実行中のカーネルは、スケジューリングイベントが発生したときに実行中のカーネルとして定義される。

次に、本発明のマルチカーネル実行の態様が、いくらか詳しく説明される。本発明の別の新規の態様は、より高い優先順位のカーネルが実行されているときでも、システムは、機会が生じた場合（すなわち、高い優先順位のカーネル内のタスクが実行状態ではない、例えば、待機、スリープ、休止など）、より低い優先順位のカーネル内のタスクの実行を可能にすることである。

図１０は、本発明の実施形態による、周期信号によってカーネルを切り替えるための例示的方法のフローチャートを示す。図に示される実施形態では、汎用カーネル（カーネル０、図示せず）が、カーネル切替えプロセスをトリガするステップ１００５の周期信号の生成により、あるカーネルから別のカーネルに切替えを行う周期プロセスを実行し、それによって、プロセスが進行して、まず、別のカーネルに保留タスクがあることを決定する。これは、多くの適切な手法によって実現されうるが、１つの適切な手法として、チェイン内のカーネルが実行すべき保留タスクを有するかどうかをを決定するために、シリアルポーリング方法を利用する手法が、図示されている。図示の例では、ステップ１００５で周期信号が生成されると、カーネル１は、実行すべき保留タスクをポーリングする。カーネル１が１つまたは複数の実行すべき保留タスクを有する場合（「Ｙｅｓ」経路）、カーネル１における保留タスクの実行は、例えば、現在実行中のＩＤをカーネル１のＩＤに変更してそれにより保留タスクの実行のためにＣＰＵ時間を転送することによって行われる。カーネル１が実行すべき保留タスクを有していない場合（「Ｎｏ」経路）、プロセスは、次のカーネルを、例えばステップ１０２０でカーネル２をポーリングし、最後のカーネル、すなわちステップ１０３０でカーネルｎに到達するまで、チェイン内の後続の各カーネルについて同様にプロセスは継続する。カーネルにおけるすべての保留プロセスが実行されたとき、または保留タスクが発見されないとき（すなわち、ステップ１０１０〜１０３０を通じて「Ｎｏ」経路）、プロセスは終了し、カーネル０のタスクの実行が再開される。しかし、本発明のいくつかの代替実施形態では、１次カーネルに制御を返す前にすべての保留タスクを完了することを必要とする代わりに、１次カーネルに制御を返す前に、保留プロセスの少なくとも一部分をサービスする既知の技術（限定としてではなく、例えば、まず最も高い優先順位のカーネルのみをサービスし、次いで、後続のパスでより低い優先順位をサービスすることなど）によって、他のポーリングまたは切替え方式が実装されうる。ステップ１００５で周期信号の次の生成があると、プロセスは再び開始する。本発明の教示に照らして、特定のアプリケーションの必要に応じ、代替の適切な切替え方式が多数あることは、当業者には理解されよう。

次に、本発明のマルチカーネルのリソース共有の態様が、いくらか詳しく説明される。本発明の更に別の新規の態様は、リソースが、１次カーネルと任意の２次カーネルとの間ならびに２次カーネル間で共有されうることである。多くのアプリケーションでは、オペレーティングシステム・カーネルの機能およびリソースに、他のオペレーティングシステム・カーネルからアクセスするのが望ましいことがしばしばある。いくつかの事例では、これが、マルチカーネルシステムを実装する主な理由である。

図１１は、共通システムＡＰＩが複数カーネルのリソース共有のために使用される本発明の実施形態の例示的ブロック図を示す。本実施形態では、複数カーネルのリソース共有は、１次カーネルと２次カーネルの間のリソース共有（例えば、ファイルシステム、デバイスドライバ、ライブラリなど）をサポートする各カーネルごとに定義されるダミーＡＰＩシステムコール（例えば、Ｓｙｓ＿ｃａｌｌ１、Ｓｙｓ＿ｃａｌｌ２、…、Ｓｙｓ＿ｃａｌｌｎ）を介して実現される。好ましい実施形態では、１次カーネルが、各カーネルごとにダミーＡＰＩコールを有し、１次カーネルと２次カーネルの間のリソース共有を各カーネルごとにサポートする。２次カーネルが１次カーネルの動的モジュールとしてアクティブ化される場合、ダミーＡＰＩコールは、実ＡＰＩコールに置き換えられる。

実ＡＰＩコールが１次カーネルから実行されるとき、２次カーネルは、そのＡＰＩに対応する特定の機能コールを呼び出し、２次カーネルのもとでその機能を実行する。このようにして、２次カーネルのＡＰＩが、１次カーネルに使用可能になされる。したがって、アプリケーション（ユーザおよびシステム）は、２次カーネルの機能にアクセスすることができる。ユーザアプリケーション（１１１０）が１次カーネル（１１２０）にカーネルｎのＡＰＩを実行するよう要求するとき。１次カーネル（１１２０）は、リソース共有のための共通ＡＰＩのＳｙｓ＿ｃａｌｌ０（１１３０）を使用して、カーネルｎ（１１４０）におけるリソース共有のための共通ＡＰＩのＳｙｓ＿ｃａｌｌｎを呼び出す。カーネルｎにおけるリソース共有のための共通ＡＰＩのＳｙｓ＿ｃａｌｌｎ（１１５０）は、ユーザアプリケーションによって要求される特定のＡＰＩを呼び出す。

Ｌｉｎｕｘ（登録商標）（ＧＰＯＳ）およびｉＴＲＯＮ（ＲＴＯＳ）オペレーティングシステムに適用されるこのプロセスを例示する、本発明の特定の実施形態が、以下で説明される。本発明の教示によって動作する任意の適切なＧＰＯＳおよびＲＴＯＳをどのように適切に構成するかが、当業者には容易に認識されるであろうことは理解される。本発明によって認識されるように、Ｌｉｎｕｘ（登録商標）カーネルのようなＧＰＯＳとｉＴＲＯＮカーネルのようなＲＴＯＳとを含むハイブリッドシステムは、多くの現代的な組込み装置に最も望ましい機能を有することになる。

上記の教示のコンテキストで、本実施形態において、Ｌｉｎｕｘ（登録商標）カーネルは、汎用オペレーティングカーネル（ｋ０）として選択され、ｉＴＲＯＮは、２次カーネル（ｋ１）として選択される。Ｌｉｎｕｘ（登録商標）のスケジューラは、共通スケジューラとして、Ｌｉｎｕｘ（登録商標）の割込みハンドラは、システムの共通割込みハンドラとしてそれぞれ選択される。コンピュータをブートすると、まずＬｉｎｕｘ（登録商標）カーネルが始動される。ｉＴＲＯＮカーネルは、Ｌｉｎｕｘ（登録商標）カーネルのランタイム動的モジュールとして挿入される。一意のカーネルＩＤ０および１が、例えば、Ｌｉｎｕｘ（登録商標）およびｉＴＲＯＮにそれぞれ割り当てられる。ｉＴＲＯＮカーネル１には、（例えば、適切には日立ＳＨ−４の実装において）割込みマスクレベル１１〜１５が割り当てられうる。したがって、例えば、ｉＴＲＯＮカーネルが、マスクレベル１〜１０で割込みを実行する場合、割込みは許可されない。

Ｌｉｎｕｘ（登録商標）スケジューラは、システムのための共通スケジューラとして使用されるため、ハードウェアタイマを使用して周期的にシステムによって呼び出される。スケジューリングイベントがトリガされたとき、Ｌｉｎｕｘ（登録商標）スケジューラは呼び出される。Ｌｉｎｕｘ（登録商標）スケジューラは、Ｌｉｎｕｘ（登録商標）スケジューラが呼び出されたとき実行していたカーネルのカーネルＩＤを決定する。次いで、実行中のカーネルがＬｉｎｕｘ（登録商標）であった場合、例えば、以下の擬似コードによって例示されるようなｌｉｎｕｘ＿ｓｃｈｅｄｕｌｅ（）関数が呼び出される。

式１

どのカーネルが実行されているかに応じて、特定の割込みがマスクされうる。例えば、ｉＴＲＯＮカーネルが実行されているとき、（例えば、ＳＨ−４の実装で）マスクレベル１〜１０を有するすべての割込みがマスクされる。マスクレベル１１〜１５を有する割込みが発生する場合、Ｌｉｎｕｘ（登録商標）割込みハンドラが呼び出される。Ｌｉｎｕｘ（登録商標）割込みハンドラが、非ｉＴＲＯＮ特有のコードを実行し、次いで、以下の擬似コードによって例示されるようにｄｏ＿ＩＲＱを使用してｉＴＲＯＮ割込みハンドラを実行する。

式２

本実施形態では、（ｉＴＲＯＮなどの）２次カーネルがインストールされる必要がある場合、まず、１次カーネルが、カーネル間の実行を切り替えることを目的とする周期信号をインストールする。この周期信号は、ハードウェアタイマによってトリガされうる。この周期信号が発生すると、割込みハンドラは、２次カーネル（ｉＴＲＯＮ）において実行を保留しているタスクが存在するかどうかを決定し、存在しない場合、Ｌｉｎｕｘ（登録商標）カーネルに実行を渡す。これは、２次カーネルがアイドル状態の間、１次カーネルにおけるタスクの実行を可能にする。

本実施形態では、１次カーネル（例えばＬｉｎｕｘ（登録商標）カーネル）が２次カーネル（例えばｉＴＲＯＮカーネル）に実行を渡すとき、１次カーネルは、まず、その割込みマスクレベルを２次カーネル（ｉＴＲＯＮ）の割込みマスクレベルに変更することが好ましい。限定としてではなく、例えば、ｉＴＲＯＮに実行が転送されたとき、割込みマスクレベルは、以下に示されるように、ｌｉｎｕｘ＿２＿ｉｔｒｏｎ（）を呼び出すことによって設定される。これは、０ｘ００００００Ａ０に割込みマスクを設定する。これで１１〜１５の間の割り込みのみが許可されることになる。マスクレベル０〜１０を有する割込みが発生した場合、以下の擬似コードによって例示されるように、割込みは無視される。

式３

実行がｉＴＲＯＮから返されＬｉｎｕｘ（登録商標）に転送されると、割込みマスクは、０ｘ００００００００に設定され、すべての割込みが許可される。実行が転送される前に、カーネルＩＤも、実行が渡されるカーネルのＩＤに変更されることに留意すべきである。例えば、Ｌｉｎｕｘ（登録商標）からｉＴＲＯＮに実行が渡されるとき、カーネルＩＤは、０から１に変更される。実行がＬｉｎｕｘ（登録商標）に返されるとき、以下の擬似コードによって例示されるように、カーネルＩＤは、１から０に変更される。

式４

上記のシステムは、日立ＳＨｘ系列プロセッサ上で実装された。日立ＳＨｘプロセッサおよび他の多くのプロセッサは、明示的な割込み優先順位をサポートする。割込み優先順位がハードウェアでサポートされないシステムでは、割込み優先順位は、エミュレーションまたは他の何らかの技法でソフトウェアによって実装されうる。

ほとんどの従来のリアルタイム組込みシステムは、イベントベースのプログラミングを使用する、つまり、特定のイベントが発生したときにタスクを実行する。充分にプログラムされた組込みコンピュータシステムでは、システムＣＰＵが、大部分の時間はアイドル状態である。すべてではないがほとんどの組込みアプリケーションは、ハードリアルタイム（ＨＲＴ）、ソフトリアルタイム（ＳＲＴ）、および非リアルタイムまたは通常（ＮＲＴ）の３つのタイプのタスクからなると見なすことができ、それらのタスクモデルおよび対応する割込みモデルは、次にいくらか詳しく説明される本発明の実施形態で活用される。このコンテキストにおいて、本発明の別の態様は、組込みシステムにおけるこの一般的なアイドル時間を利用して、汎用オペレーティングシステムの性能およびデューティサイクルを増大する。上述のタスクモデルおよびシステムアイドル時間を活用する本発明の一実施形態では、ＨＲＴタスクは、ＲＴＯＳカーネル、限定ではなく例えば、ｉＴＲＯＮ ＡＰＩを使用したｉＴＲＯＮカーネルでのタスクとして実装され、ＳＲＴタスクは、ＲＴＯＳカーネル、限定ではなく例えば、ｉＴＲＯＮ ＡＰＩ、および／または、ＧＰＯＳカーネル、限定ではなく例えば、Ｌｉｎｕｘ（登録商標）ライブラリ（システムコールおよびカーネルＡＰＩ）を、使用して実装され、ＮＲＴタスクは、ＧＰＯＳカーネル、限定ではなく例えば、標準Ｌｉｎｕｘ（登録商標）ＡＰＩを使用して実装される。

本実施形態は、既知または未開発のＲＴＯＳシステムとＧＰＯＳシステムの任意の組合わせでの使用に適するが、分かりやすいように、以下の説明では、ＲＴＯＳがｉＴＲＯＮでありＧＰＯＳがＬｉｎｕｘ（登録商標）であると想定する。本実施形態の手法によれば、ｉＴＲＯＮカーネルで実行を保留しているタスクがある限り、Ｌｉｎｕｘ（登録商標）プロセスは、実行される機会を得ることがない。実行可能な２つ以上のタスクがある場合、最も高い優先順位を有するタスクが最初に実行され、次に最も高い優先順位を有するタスクが次に実行され、実行可能または保留状態のタスクがなくなるまで、以下同様に実行される。

ｉＴＲＯＮシステムに実行を保留しているタスクがない場合、実行制御がＬｉｎｕｘ（登録商標）に渡されて、再度、最も高い実行優先順位を有するタスクが、最初に実行される。待ち時間を適切に短く維持するために、すべてのＳＲＴタスクは、標準Ｌｉｎｕｘ（登録商標）プロセス（すなわちＮＲＴタスク）より高い実行優先順位を有する。好ましい実施形態では、ＳＲＴとＮＲＴの間のＬｉｎｕｘ（登録商標）の優先順位システムは、Ｌｉｎｕｘ（登録商標）「ＲＴ優先順位」を用いて実装される。したがって、ＮＲＴプロセスは、実行を保留しているＳＲＴタスクがなくなるまで実行されない。代替実施形態では、任意の適切なパプリックドメインまたは独自の優先順位管理システムが、ＨＲＴ、ＳＲＴ、およびＮＲＴプロセスの優先順位およびスケジューリングを管理するために実装されうる。

先に示唆されたように、本発明の別の新規の態様は、複数のカーネルが、ファイルシステム、デバイスドライバ、およびライブラリなどのリソースを共有することを可能にするプロセスである。本発明の一実施形態では、このリソース共有プロセスは、リソース共有がサポートされる各カーネルごとにダミーＡＰＩコールを定義することによって実現される。限定としてではなく、例えば、ＲＴＯＳカーネル例えばｉＴＲＯＮで使用可能な機能を、ＧＰＯＳカーネル例えばＬｉｎｕｘ（登録商標）から使用することが、非常に望ましい。ｉＴＲＯＮカーネルについてのダミーＡＰＩコールは、限定ではなく例として、以下の擬似コードに示される。

式５

２次カーネルが、動的ランタイムモジュールとして初めてアクティブ化（ロード）されたとき、ダミーＡＰＩコールが、実ＡＰＩにリンクされる。ｉＴＲＯＮが動的モジュールとしてＬｉｎｕｘ（登録商標）のもとでアクティブ化されたとき、ダミーＡＰＩコールは、実ＡＰＩコールに置き換えられる。このようにして、２次カーネル全体（例えば、この例ではｉＴＲＯＮ）のＡＰＩが、以下の擬似コードに限定としてではなく例示されるように、１次カーネル（例えば、この例ではＬｉｎｕｘ（登録商標））に使用可能にされる。

式６

Ｌｉｎｕｘ（登録商標）のランタイム動的モジュールの本実施形態をアクティブ化するために、限定ではなく例として以下の擬似コードが使用されうる。

式７

ＲＴＯＳモジュール、例えばｉＴＲＯＮが、除去されるとき、以下の擬似コードに限定としてではなく例示されるように、ダミーＡＰＩが除去される。

式８

上記または同様のやり方で、ダミーＡＰＩコールを使用することにより、１次カーネルは、ダミーＡＰＩを介して１次カーネルに特定的に使用可能にされる２次カーネル機能を実行することができる。この機構は、データ共有、タスク同期、および通信機能（セマフォ、イベントフラグ、データキュー、メールボックス）を限定としてではなく含む、２つのカーネル間の複雑な対話の使用を可能にすることが企図される。ダミーＡＰＩ、およびＧＰＯＳ（例えば、Ｌｉｎｕｘ（登録商標））システムコールを使用することによって、当業者は、本発明の教示に照らして、リアルタイム組込みプログラムにおいてＬｉｎｕｘ（登録商標）の豊富な機能（例えば、ファイルシステム、ドライバ、ネットワークなど）を利用できるプログラムを、開発することができる。本発明のいくつかの実施形態は、上記の共通スケジューラおよび／または共通ダミーＡＰＩを、任意選択として含まないことがある。つまり、本発明の共通割込みハンドラを用いて、複数のカーネルが、共通スケジューラおよび／または共通ダミーＡＰＩなしに実行されうる。しかし、多くのアプリケーションでは、共通スケジューラが、より向上した性能、およびより優れたエラー処理をもたらす。複数のカーネル間のリソース共有を必要としないアプリケーションは、本発明の上記の共通ダミーＡＰＩの態様を実装しなくてもよい。

図１２は、適切に構成され設計された場合、本発明が実施されうるコンピュータシステムの役割をすることができる、典型的コンピュータシステムを示す。コンピュータシステム１２００は、任意の数の（中央処理装置またはＣＰＵとも呼ばれる）プロセッサ１２０２を含み、プロセッサ１２０２は、１次ストレージ１２０６（典型的にはランダムアクセスメモリ即ちＲＡＭ）および１次ストレージ１２０４（典型的には読取り専用メモリ即ちＲＯＭ）を含むストレージデバイスに結合される。ＣＰＵ１２０２は、プログラマブルデバイス（例えば、ＣＰＬＤおよびＦＰＧＡ）、ならびにゲートアレイＡＳＩＣや汎用マイクロプロセッサのような非プログラマブルデバイスなどの、マイクロコントローラおよびマイクロプロセッサを含め、様々なタイプでありうる。当技術分野で周知のように、１次ストレージ１２０４は、データおよび命令をＣＰＵに対して一方向に転送するよう動作し、１次ストレージ１２０６は、通常、データおよび命令を双方向に転送するために使用される。これら両方の１次ストレージデバイスは、任意の適切な上述のようなコンピュータ可読媒体を含むことができる。大容量ストレージデバイス１２０８もまた、ＣＰＵ１２０２に双方向に結合することができ、追加のデータ記憶容量を提供し、任意の上述のコンピュータ可読媒体を含むことができる。大容量ストレージデバイス１２０８が、プログラムおよびデータなどを記憶するために使用されてもよく、通常は、ハードディスクのような２次記憶媒体である。大容量ストレージデバイス１２０８内に保持される情報は、該当する場合、仮想メモリとして標準的様式で１次ストレージ１２０６の部分として取り込まれることは、理解されよう。ＣＤ−ＲＯＭ１２１４など特定の大容量ストレージデバイスもまた、データをＣＰＵに一方向に渡すことができる。

ＣＰＵ１２０２はまた、インターフェース１２１０に結合することができ、インターフェース１２１０は、１つまたは複数の入出力装置に接続し、このような入出力装置は、例えば、ビデオモニタ、トラックボール、マウス、キーボード、マイクロフォン、タッチ検知ディスプレイ、変換カードリーダ、磁気または紙テープリーダ、タブレット、スタイラス、音声または手書き文字認識装置、あるいは、もちろん他のコンピュータなど他の周知の入力装置である。最後に、ＣＰＵ１２０２は、任意選択で、１２１２で概略的に示されるような外部接続を使用して、データベースまたはコンピュータのような外部装置、あるいは遠隔通信またはインターネット・ネットワークに結合されうる。このような接続を用いて、本発明の教示に記載の方法ステップを実行する過程で、ＣＰＵは、ネットワークから情報を受け取ることができ、またはネットワークに情報を出力することができることが企図される。

上述のいずれのステップおよび／またはシステムモジュールが、適切に置き換えられ、再配列され、除去されうること、追加のステップおよび／またはシステムモジュールが、特定のアプリケーションの必要に応じて挿入されうること、ならびに、本実施形態の方法およびシステムは、任意の様々な適切なプロセスおよびシステムモジュールを用いて実装されることが可能であって、いずれの特定のコンピュータハードウェア、ソフトウェア、ＲＴＯＳ、ＧＰＯＳ、ファームウェア、およびマイクロコードなどにも限定されないことは、本発明の教示によって当業者には容易に認識されよう。

本発明の少なくとも１つの実施形態を完全に説明したが、本発明による複数のカーネルの並列実行および複数のカーネル間のリソース共有の他の等価または代替の方法は、当業者には明らかであろう。本発明は、例示によって上記に説明されており、開示の特定の実施形態が、本発明を開示の特定の形態に限定するものではない。したがって、本発明は、添付の特許請求の範囲の趣旨および範囲に含まれるすべての修正形態、均等物、および代替形態を含むことになる。

本発明の実施形態による、１つのハードウェアプラットフォーム上で複数のカーネルの実行を可能にする例示的アーキテクチャを示す図である。 本発明の実施形態による、複数のカーネルを並列実行するための方法を示すフローチャートである。 本発明の実施形態による、図２に示される１次カーネルの選択のための例示的方法を示すフローチャートである。 本発明の実施形態による、図２に示される１次カーネルを始動するための例示的方法を示すフローチャートである。 本発明の実施形態による、図２に示される２次カーネルの選択および追加のための例示的方法を示すフローチャートである。 本発明の実施形態による、図２に示される２次カーネルを始動するための例示的方法を示すフローチャートである。 本発明の実施形態による、複数のカーネルについての共通割込みハンドラおよび共通スケジューラの例示的アーキテクチャを示すブロック図である。 図７のコンテキストにおける本発明の実施形態による、複数のカーネルについての割込みマスクレベルを示す例示的線図である。 本発明の実施形態による、周期信号によってカーネルを切り替えるための例示的方法を示すフローチャートである。 共通システムコールが複数カーネルのリソース共有のために使用される本発明の実施形態を示す例示的ブロック図である。 適切に構成され設計された場合、本発明が実施されうるコンピュータシステムの役割をすることができる、典型的コンピュータシステムを示す図である。

Claims (33)

1. マルチカーネル環境における複数のカーネルの並列実行のための方法であって、
   前記マルチカーネル環境から１次カーネルを選択するステップと、
   前記１次カーネルを始動するステップと、
   少なくとも１つの２次カーネルを追加するステップであって、前記少なくとも１つの２次カーネルは、前記１次カーネルの少なくとも部分的制御下にあるステップと、
   割込みハンドラを、前記１次カーネルおよび少なくとも１つの前記２次カーネルにおける割込みプロセスの割込みおよび実行を処理する共通割込みハンドラにするステップと、を含む方法。
2. 前記１次カーネルは、汎用オペレーティングシステムの能力がある、請求項１に記載のマルチカーネル実行方法。
3. 前記少なくとも１つの２次カーネルのうち少なくとも１つは、リアルタイム・オペレーティングシステムの能力がある、請求項１に記載のマルチカーネル実行方法。
4. 前記１次カーネルとして選択されたカーネルは、最も望ましい能力を有する前記マルチカーネル環境におけるカーネルである、請求項１に記載のマルチカーネル実行方法。
5. スケジューラを、前記１次カーネルおよび少なくとも１つの前記２次カーネルに保留しているプロセスの実行をスケジュールする共通スケジューラにするステップを更に含む、請求項１に記載のマルチカーネル実行方法。
6. 前記共通スケジューラは、最も望ましい能力を有する前記マルチカーネル環境におけるオペレーティングシステムから選択される、請求項５に記載のマルチカーネル実行方法。
7. 前記共通割込みハンドラは、最も望ましい能力を有する前記マルチカーネル環境におけるオペレーティングシステムから選択される、請求項１に記載のマルチカーネル実行方法。
8. 前記共通割込みハンドラまたは前記共通スケジューラは、前記１次カーネル内にある、請求項５に記載のマルチカーネル実行方法。
9. 前記マルチカーネル環境を実行するコンピュータをブートすると、前記１次カーネルは、前記少なくとも１つの２次カーネルに先立って始動される、請求項１に記載のマルチカーネル実行方法。
10. 前記少なくとも２次カーネルのうち少なくとも１つが、前記１次カーネルのランタイム動的モジュールとしてアクティブ化される、請求項１に記載のマルチカーネル実行方法。
11. 一意のカーネル識別子を前記１次カーネルに割り当てるステップと、
    少なくとも１つの割込みマスクレベルを前記１次カーネルに割り当てるステップであって、前記少なくとも１つの割込みマスクレベルは、前記１次カーネルについて許可される前記割込みを決定するステップとを更に含む、請求項１に記載のマルチカーネル実行方法。
12. 一意のカーネル識別子を前記少なくとも１つの２次カーネルに割り当てるステップと、
    少なくとも１つの割込みマスクレベルを少なくとも１つの２次カーネルに割り当てるステップであって、前記少なくとも１つの割込みマスクレベルは、前記特定の２次カーネルについて許可される前記割込みを決定するステップとを更に含む、請求項１に記載のマルチカーネル実行方法。
13. 前記少なくとも１つの２次カーネルに対するフックを、前記１次カーネルの前記共通スケジューラまたは前記共通割込みハンドラにインストールするステップを更に含む、請求項５に記載のマルチカーネル実行方法。
14. プロセス実行制御を、現在アクティブのカーネルから次のアクティブカーネルに切り替えるタスクを実行するステップであって、前記次のアクティブカーネルは、前記少なくとも１つの２次カーネルのうちの１つであるステップを更に含む、請求項１に記載のマルチカーネル実行方法。
15. 前記プロセス実行制御タスクは、周期タスクであり、前記次のアクティブカーネルは、２次カーネル・ポーリング優先順位方式に従ってポーリングによって決定され、最も高い優先順位の２次カーネルの前記２次カーネルは、少なくとも１つの実行すべき保留プロセスを有し、プロセス実行制御は、前記少なくとも１つの２次カーネルにおける前記保留プロセスの少なくとも一部分の完了の後に、前記１次カーネルに転送される、請求項１４に記載のマルチカーネル実行方法。
16. 前記共通割込みハンドラを呼び出すステップであって、前記共通割込みハンドラは、その後、少なくとも１つのカーネル非依存割込み処理機能を実行し、プロセス実行制御を、前記割込みに関連付けられたターゲットカーネルの割込みサービスルーチンに渡すステップを更に含む、請求項１に記載のマルチカーネル実行方法。
17. 前記ターゲットカーネルは、前記少なくとも１つの２次カーネルの前記マスクレベルによって決定される、請求項１６に記載のマルチカーネル実行方法。
18. 前記共通スケジューラを呼び出すステップと、
    前記マルチカーネル環境においてどのカーネルが現在実行中のカーネルであるかを決定するステップと、
    プロセス実行制御を、前記現在実行中のカーネルに転送するステップと、
    少なくとも１つのカーネル特定スケジューリング機能を前記現在のカーネルによって実行するステップとを更に含む、請求項５に記載のマルチカーネル実行方法。
19. 前記１次カーネルが、プロセス実行制御を、前記少なくとも１つの２次カーネルのうちの１つに渡し、それによって、前記少なくとも１つの２次カーネルのうちの１つが、アクティブカーネルになるステップと、
    前記１次カーネルが、その割込みマスクレベルを、前記アクティブカーネルに対応するように変更するステップと、
    前記１次カーネルが、現在実行中のカーネル識別コードを、前記アクティブカーネルに関連付けられた識別コードに変更するステップとを更に含む、請求項１に記載のマルチカーネル実行方法。
20. 前記１次カーネルと前記少なくとも１つの２次カーネルの間のリソース共有のためのアプリケーション・プログラム・インターフェース（ＡＰＩ）をインストールするステップを更に含む、請求項１に記載のマルチカーネル実行方法。
21. マルチカーネル環境における複数のカーネル間のシステムリソースを共有するための方法であって、
    前記マルチカーネル環境から１次カーネルを選択するステップと、
    前記１次カーネルを始動するステップと、
    少なくとも１つの２次カーネルを追加するステップであって、前記少なくとも１つの２次カーネルは、前記１次カーネルの少なくとも部分的制御下にあるステップと、
    第１の前記１次カーネルまたは前記少なくとも１つの２次カーネルと、第２の前記１次カーネルまたは前記少なくとも１つの２次カーネルとの間のシステムリソース共有のためのアプリケーション・プログラム・インターフェース（ＡＰＩ）をインストールするステップであって、前記第１のカーネルには、少なくとも前記第２のカーネルに対する適切なダミーＡＰＩコールが提供されるステップと、を含む方法。
22. 前記第２のカーネルが前記第１のカーネルからの前記ダミーＡＰＩコールによってアクティブ化されると、前記第２のカーネルは、前記ダミーＡＰＩが定義されたカーネルにおける前記ダミーＡＰＩコールを、前記第２のカーネルに対する実ＡＰＩコールに置き換えるステップを更に含む、請求項２１に記載のシステムリソース共有方法。
23. 前記第１のカーネルからの前記実ＡＰＩコールがあると、前記第２のカーネルの特定のシステム機能を実行し、それによって、前記第１のカーネルにおいて前記第２のカーネルのリソースを使用可能にするステップを更に含む、請求項２２に記載のシステムリソース共有方法。
24. マルチカーネル環境における複数のカーネルの並列実行のためのシステムであって、
    前記マルチカーネル環境から１次カーネルを選択する手段と、
    少なくとも１つの２次カーネルを、追加し、少なくとも部分的に制御する手段と、
    前記１次カーネルおよび前記少なくとも１つの２次カーネルを実行する手段と、
    前記１次カーネルおよび少なくとも１つの前記２次カーネルにおける割込みプロセスの割込みおよび実行を処理する手段と、を含むシステム。
25. 前記１次カーネルおよび少なくとも１つの前記２次カーネルに保留しているプロセスの実行をスケジュールする手段を更に含む、請求項２４に記載の複数カーネルシステム。
26. マルチカーネル環境における複数のカーネル間でシステムリソースを共有するためのシステムであって、
    前記マルチカーネル環境から１次カーネルを選択する手段と、
    少なくとも１つの２次カーネルを、追加し、少なくとも部分的に制御する手段と、
    前記１次カーネルおよび前記少なくとも１つの２次カーネルを実行する手段と、
    第１の前記１次カーネルまたは前記少なくとも１つの２次カーネルと、第２の前記１次カーネルまたは前記少なくとも１つの２次カーネルとの間のシステムリソース共有のための手段と、を含むシステム。
27. マルチカーネル環境における複数のカーネルの同時実行のためのコンピュータプログラム製品であって、
    前記マルチカーネル環境から１次カーネルを選択するコンピュータコードと、
    少なくとも１つの２次カーネルを、追加し、少なくとも部分的に制御するコンピュータコードと、
    前記１次カーネルおよび前記少なくとも１つの２次カーネルを実行するコンピュータコードと、
    前記１次カーネルおよび少なくとも１つの前記２次カーネルにおける割込みプロセスの割込みおよび実行を処理する共通割込みハンドラを実装するコンピュータコードと、
    前記コンピュータコードを記憶するコンピュータ可読媒体と、を含むコンピュータプログラム製品。
28. 前記１次カーネルおよび少なくとも１つの前記２次カーネルに保留しているプロセスの実行をスケジュールする共通スケジューラを実装する、コンピュータコードを更に含む、請求項２７に記載のコンピュータプログラム製品。
29. 前記コンピュータ可読媒体は、搬送波に具現化されたデータ信号、ＣＤ−ＲＯＭ、ハードディスク、フロッピー（登録商標）ディスク、テープドライブ、および半導体メモリからなる群から選択される媒体である、請求項２７に記載のコンピュータプログラム製品。
30. マルチカーネル環境における複数のカーネル間でシステムリソースを共有するためのコンピュータプログラム製品であって、
    前記マルチカーネル環境から１次カーネルを選択するコンピュータコードと、
    少なくとも１つの２次カーネルを、追加し、少なくとも部分的に制御するコンピュータコードと、
    前記１次カーネルおよび前記少なくとも１つの２次カーネルを実行するコンピュータコードと、
    第１の前記１次カーネルまたは前記少なくとも１つの２次カーネルと、第２の前記１次カーネルまたは前記少なくとも１つの２次カーネルとの間でシステムリソースを共有するコンピュータコードと、
    前記第１のカーネルに、少なくとも前記第２のカーネルに対する適切なダミー・アプリケーション・プログラム・インターフェース（ＡＰＩ）コールを提供するコンピュータコードと、
    前記コンピュータコードを記憶するコンピュータ可読媒体と、を含むコンピュータプログラム製品。
31. 前記第２のカーネルが前記第１のカーネルからの前記ダミーＡＰＩコールによってアクティブ化されると、前記ダミーＡＰＩが定義されたカーネルにおける前記ダミーＡＰＩコールを、前記第２のカーネルに対する実ＡＰＩコールに置き換えるコンピュータコードを更に含む、請求項３０に記載のシステムリソース共有方法。
32. 前記第１のカーネルからの前記実ＡＰＩコールがあると、前記第２のカーネルの特定のシステム機能を実行し、それによって、前記第１のカーネルにおいて前記第２のカーネルのリソースを使用可能にするコンピュータコードを更に含む、請求項３０に記載のシステムリソース共有方法。
33. 前記コンピュータ可読媒体は、搬送波に具現化されたデータ信号、ＣＤ−ＲＯＭ、ハードディスク、フロッピー（登録商標）ディスク、テープドライブ、および半導体メモリからなる群から選択される媒体である、請求項３０に記載のコンピュータプログラム製品。

Images