JPH0895757A - マイクロカーネル・データ処理システム用のマスタ・サーバ・プログラム・ロード方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 マイクロカーネル・オペレーティング・シス
テムを始動する際の効率を改善する。 【解決の手段】 マスタ・サーバ・プログラム・ローダ
は、マイクロカーネル・システムのメモリ内の多数の様
々なプログラムおよび共用ライブラリのロードを容易に
するように設計される。マスタ・サーバは、ローダ、動
的リンカおよび動的ローダの３つの構成要素を有する。
ローダは、始動前に実行可能プログラムをターゲット・
タスクにロードする。動的リンカは、始動前に共用ライ
ブラリ・オブジェクトをターゲット・タスクとリンクさ
せる。動的ローダは、プログラムの実行時に共用ライブ
ラリ・オブジェクトをロードする。プログラム・ロード
方法は、ローダがターゲット・プログラムをターゲット
・タスクにロードし、動的リンカに制御を移すことから
始まる。次に、動的リンカが共用ライブラリ・オブジェ
クトをターゲット・タスクにリンクし、制御をマスタ・
サーバに移す。次にマスタ・サーバが、制御をターゲッ
ト・プログラムに移して終了する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本明細書に開示する本発明
は、広義にはデータ処理システムに関し、より詳細には
データ処理システム用のオペレーティング・システムの
改善に関する。

【０００２】

【従来の技術】本明細書で開示する本発明はまた、イン
ターナショナル・ビジネス・マシーンズ・コーポレイシ
ョンに譲渡され、参照により本明細書に組み込まれた、
１９９４年９月９日出願のラーム・ケー・グプタ（Ram
K.Gupta）、ラヴィ・スリニバサン（Ravi Srinivasa
n）、デニス・アッカーマン（Dennis Ackerman）および
ヒマンシュ・デサイ（Himanshu Desai）の"EXCEPTION H
ANDLING METHOD AND APPARATUS FOR A MICROKERNEL DAT
A PROCESSING SYSTEM"と題する同時係属の米国特許出願
第３０３７９６号（ＩＢＭ整理番号ＢＣ９−９４−０７
２）にも関連する。

【０００３】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年９月９日出願のハーディープ・シン（Hardeep
Singh）、ガイ・ソトマイヤー（Guy Sotomayor）、ガリ
ー・バートン（Gary Barton）、フリーマン・ローソン
（Freeman Rawson）、チン・ヤン・チャオ（Ching Yun
Chao）およびチャールズ・ジュン（Charles Jung）の"B
ACKING STORE MANAGEMENT METHOD AND APPARATUS FOR A
MICROKERNEL DATA PROCESSING SYSTEM"と題する同時係
属の米国特許出願第３０３８５１号（ＩＢＭ整理番号Ｂ
Ｃ９−９４−０８７）にも関連する。

【０００４】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年６月２１日出願のガイ・ジー・ソトマイヤー・
ジュニア（Guy G.Sotomayor,Jr.）、ジェームズ・エム
・マジー（James M.Magee）、フリーマン・エル・ロー
ソン三世（Freeman L.Rawson,III）の"METHOD AND APPA
RATUS FOR MANAGEMENT OF MAPPED AND UNMAPPED REGION
S OF MEMORY IN A MICROKERNEL DATA PROCESSINGSYSTE
M"と題する同時係属の米国特許出願第２６３７１０号
（ＩＢＭ整理番号ＢＣ９−９４−０５３）にも関連す
る。

【０００５】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年６月２１日出願のジェームズ・エム・マジー他
の"CAPABILITY ENGINE METHOD AND APPARATUS FOR A MI
CROKERNEL DATA PROCESSING SYSTEM"と題する同時係属
の米国特許出願第２６３３１３号（ＩＢＭ整理番号ＢＣ
９−９４−０７１）にも関連する。

【０００６】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年６月２１日出願のジェームズ・エム・マジー他
の"TEMPORARY DATA METHOD AND APPARATUS FOR A MICRO
KERNEL DATA PROCESSING SYSTEM"と題する同時係属の米
国特許出願第２６３６３３号（ＩＢＭ整理番号ＢＣ９−
９４−０７６）にも関連する。

【０００７】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年６月２１日出願のジェームズ・エム・マジー他
の"MESSAGE CONTROL STRUCTURE REGISTRATION METHOD A
ND APPARATUS FOR A MICROKERNEL DATA PROCESSING SYS
TEM"と題する同時係属の米国特許出願第２６３７０３号
（ＩＢＭ整理番号ＢＣ９−９４−０７７）にも関連す
る。

【０００８】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年６月２１日出願のジェームズ・エム・マジー他
の"ANONYMOUS REPLY PORT METHOD AND APPARATUS FOR A
MICROKERNEL DATA PROCESSING SYSTEM"と題する同時係
属の米国特許出願第２６３７０９号（ＩＢＭ整理番号Ｂ
Ｃ９−９４−０８０）にも関連する。

【０００９】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年７月２７日出願のアジーザ・ブシュラ・ファル
ーキー（Aziza Bushra Faruqi）他の"SEPARATION OF TR
ANSMISSION CONTROL METHOD AND APPARATUS FOR A MICR
OKERNEL DATA PROCESSING SYSTEM"と題する同時係属の
米国特許出願第２８１２１７号（ＩＢＭ整理番号ＢＣ９
−９４−０８１ＸＸ）にも関連する。

【００１０】本明細書で開示する本発明はまた、インタ
ーナショナル・ビジネス・マシーンズ・コーポレイショ
ンに譲渡され、参照により本明細書に組み込まれた、１
９９４年９月９日出願のラーム・ケー・グプタ、ラヴィ
・スリニバサン、デニス・アッカーマンおよびヒマンシ
ュ・デサイの"PAGE TABLE ENTRY MANAGEMENT METHODAND
APPARATUS FOR A MAICROKERNEL DATA PROCESSING SYST
EM"と題する同時係属の米国特許出願第３０３８０５号
（ＩＢＭ整理番号ＢＣ９−９４−０７３）にも関連す
る。

【００１１】オペレーティング・システムはコンピュー
タ上で動作する最も重要なソフトウェアである。汎用コ
ンピュータはすべて、他のプログラムを実行するために
オペレーティング・システムを備えていなければならな
い。オペレーティング・システムは通常、キーボードか
らの入力を認識し、出力を表示画面に送り、ディスク上
のファイルとディレクトリを追跡し、ディスク・ドライ
ブやプリンタなどの周辺装置を制御するなどの基本的タ
スクを実行する。より複雑なシステムでは、オペレーテ
ィング・システムはより大きな責任と能力を有する。オ
ペレーティング・システムは、同時に動作する様々なプ
ログラムおよびユーザが互いに干渉しないようにする。
また、オペレーティング・システムは、一般に機密保護
の責任を持ち、無許可ユーザがシステムにアクセスしな
いようにする。

【００１２】オペレーティング・システムは、マルチユ
ーザ・オペレーティング・システム、マルチプロセッサ
・オペレーティング・システム、マルチタスク・オペレ
ーティング・システム、およびリアルタイム・オペレー
ティング・システムに分類することができる。マルチユ
ーザ・オペレーティング・システムは、複数のユーザが
プログラムを同時に実行できる。同時に数百あるいは数
千人のユーザがログオン可能なオペレーティング・シス
テムもある。マルチプロセッシング・プログラムは、１
人のユーザが複数のプログラムを同時に実行できる。実
行される各プログラムはプロセスと呼ばれる。大部分の
マルチプロセッシング・システムは、複数のユーザをサ
ポートする。マルチタスク・システムは、単一のプロセ
スが複数のタスクを実行できる。普通の用語法では、マ
ルチタスキングとマルチプロセッシングの語は、少し異
なる意味をもつ場合でもしばしば交換可能に使用され
る。マルチタスキングは、プログラムであるタスクを複
数同時に実行する機能である。マルチタスキングでは、
１つの中央演算処理装置が関与するだけであるが、１つ
のプログラムから別のプログラムに迅速に切り替わり、
すべてのプログラムを同時に実行しているような外観を
与える。マルチタスキングには、プリエンプティブ（pr
eemptive）と協調型（cooperative）の２つの基本的な
種類がある。プリエンプティブ・マルチタスキングで
は、オペレーティング・システムがＣＰＵのタイム・ス
ライスを各プログラムに分配する。協調型マルチタスク
では、各プログラムが必要な限りＣＰＵを制御すること
ができる。しかしあるプログラムがＣＰＵを使用してい
ない場合は、別のプログラムにＣＰＵを一時的に使用さ
せることができる。たとえば、ＯＳ／２（商標）および
ＵＮＩＸ（商標）オペレーティング・システムはプリエ
ンプティブ・マルチタスキングを使用し、Ｍａｃｉｎｔ
ｏｓｈ（商標）コンピュータ用のＭｕｌｔｉ−Ｆｉｎｄ
ｅｒ（商標）は協調型マルチタスキングを使用する。マ
ルチプロセッシングとは、コンピュータ・システムが複
数のプロセスまたはプログラムを同時にサポートできる
能力を言う。マルチプロセッシング・オペレーティング
・システムは、いくつかのプログラムを並行して動作さ
せることができる。マルチプロセッシング・システム
は、オペレーティング・システムが競合する各プロセス
に資源を適正に割り振らなければならないので、単一プ
ロセス・システムよりもずっと複雑になる。リアルタイ
ム・オペレーティング・システムは、入力に対して即座
に応答する。ＤＯＳやＵＮＩＸなどの汎用オペレーティ
ング・システムはリアルタイムではない。

【００１３】オペレーティング・システムは、アプリケ
ーション・プログラムがその上で動作できるソフトウェ
ア・プラットフォームを提供する。アプリケーション・
プログラムは一般に、特定のオペレーティング・システ
ム上で動作するように明確に書かれなければならない。
したがって、オペレーティング・システムの選択によ
り、実行できるアプリケーションがほぼ決定される。Ｉ
ＢＭ互換パーソナル・コンピュータでは、オペレーティ
ング・システムの例は、ＤＯＳ、ＯＳ／２（商標）、Ａ
ＩＸ（商標）、ＸＥＮＩＸ（商標）である。

【００１４】ユーザは一般に１組のコマンドによってオ
ペレーティング・システムと対話する。たとえば、ＤＯ
Ｓオペレーティング・システムには、ファイルをコピー
するＣＯＰＹやファイル名を変更しＲＥＮＡＭＥなどの
コマンドが含まれる。コマンドは、コマンド・プロセッ
サまたはコマンド・インタープリタと呼ばれるオペレー
ティング・システムの一部分によって受け入れられ実行
される。

【００１５】パーソナル・コンピュータ用には、ＣＰ／
Ｍ（商標）、ＤＯＳ、ＯＳ／２（商標）、ＵＮＩＸ（商
標）、ＸＥＮＩＸ（商標）、ＡＩＸ（商標）などの様々
なオペレーティング・システムがある。ＣＰ／Ｍは、小
型コンピュータ用の最初のオペレーティング・システム
の１つであった。ＣＰ／Ｍは最初様々なパーソナル・コ
ンピュータで使用されたが、結局ＤＯＳのために影が薄
くなった。ＤＯＳは、すべてのＩＢＭ互換パーソナル・
コンピュータ上で動作する、単一ユーザ、単一タスクの
オペレーティング・システムである。ＯＳ／２はＤＯＳ
の後継ＯＳであり、インテル８０２８６またはそれ以降
のマイクロプロセッサを使用するＩＢＭ互換パーソナル
・コンピュータ上で動作する比較的強力なオペレーティ
ング・システムである。ＯＳ／２は、一般にＤＯＳと互
換性があるが他に多くの機能を含み、たとえばマルチタ
スキングであり仮想メモリをサポートする。ＵＮＩＸお
よびＵＮＩＸをベースとするＡＩＸは、様々なパーソナ
ル・コンピュータおよびワークステーション上で動作す
る。ＵＮＩＸとＡＩＸは、ワークステーション用の標準
オペレーティング・システムになってきており、強力な
マルチユーザ、マルチプロセッシング・オペレーティン
グ・システムである。

【００１６】１９８１年に、ＩＢＭパーソナル・コンピ
ュータが米国で導入されたとき、ＤＯＳオペレーティン
グ・システムは約１０キロバイトの記憶域を占有してい
た。それ以後、パーソナル・コンピュータはますます複
雑になり、ますます大きなオペレーティング・システム
を必要とする。今日、たとえば、ＩＢＭパーソナル・コ
ンピュータ用のＯＳ／２オペレーティング・システム
は、２２メガバイトもの記憶域を占有する。パーソナル
・コンピュータは時間が経つにつれてますます複雑で強
力になってきており、これらのシステムに関連する記憶
装置上で大きな記憶域を占有するという犠牲を払わず
に、引き続きサイズと複雑さを増大させることができな
いことは明らかである。

【００１７】このようにオペレーティング・システムの
サイズの増大率に耐えられないため、１９８０年代にCa
rnegie Mellon UniversityにおいてＭＡＣＨプロジェク
トが実施された。この研究の目的は、コンピュータ・プ
ログラマが、現れた最新ハードウェア・アーキテクチャ
を利用することができ、しかもカーネル・オペレーティ
ング・システムのサイズと機構数を減少する、新しいオ
ペレーティング・システムを開発することであった。カ
ーネルは、ハードウェア資源の割振りなどの基本機能を
実行するオペレーティング・システムの一部分である。
ＭＡＣＨカーネルの場合、システム用の基本ビルディン
グ・ブロックとして５つのプログラミング概念が確立さ
れた。それらの概念は、カーネルの外部で典型的な複雑
な操作をその上に構築できる、有用なシステムを作成す
るのに最低限必要なものとして選択された。Carnegie M
ellonのＭＡＣＨカネールは、リリース３．０でサイズ
が縮小され、ＭＡＣＨマイクロカーネルと呼ばれる完全
に機能するオペレーティング・システムになった。ＭＡ
ＣＨマイクロカーネルは、タスク、スレッド、ポート、
メッセージ、メモリ・オブジェクトの各プリミティブを
有する。

【００１８】従来のＵＮＩＸプロセスは、ＭＡＣＨマイ
クロカーネルにおいては別々の２つの構成要素に分割さ
れる。第１の構成要素は、１群の協調エンティティ用の
すべての資源を含むタスクである。タスク中の資源の例
には、仮想メモリや通信ポートがある。タスクとは、受
動的な資源の集合であり、したがってプロセッサ上では
動作しない。

【００１９】スレッドは、ＵＮＩＸプロセスの第２の構
成要素であり、能動的な実行環境である。各タスクは、
スレッドと呼ばれる１つまたは複数の並行して実行され
る計算をサポートできる。たとえば、マルチスレッド・
プログラムは、あるスレッドを使って科学計算を計算
し、同時に別のスレッドでユーザ・インターフェースを
監視する。ＭＡＣＨタスクは、すべてが同時に動作する
多数の実行スレッドを有することができる。ＭＡＣＨプ
ログラミング・モデルの能力の大部分は、あるタスク内
のすべてのスレッドがタスクの資源を共有することから
得られる。たとえば、それらのスレッドはすべて同じ仮
想メモリ（ＶＭ）アドレス空間を有する。ただし、ある
タスク内の各スレッドは、それ自体専用の実行状態を有
する。この状態は、汎用レジスタ、スタック・ポイン
タ、プログラム・カウンタ、フレーム・ポインタなどの
１組のレジスタから成る。

【００２０】ポートは、スレッドが互いに通信するため
の通信チャネルである。ポートは資源であり、タスクに
よって所有される。スレッドは、タスクに属することに
よってポートへのアクセス権を得る。協調型プログラム
では、あるタスクのスレッドが別のタスク内のポートに
対するアクセス権を獲得できる。重要な特徴は、スレッ
ドがロケーション透過性であることである。この機能に
よって、プログラムの修正なしにネットワーク上でのサ
ービスの配布が容易になる。

【００２１】メッセージは、異なるタスク内のスレッド
が互いに通信できるようにするために使用される。メッ
セージは、所与のクラスまたはタイプのデータの集合を
含む。このデータは、数または文字列などプログラム特
有のデータから、ポートの諸機能をあるタスクから別の
タスクへ移送するなどのＭＡＣＨ関連データにまで及
ぶ。

【００２２】メモリ・オブジェクトは、ユーザ・レベル
のプログラムにおいて従来のオペレーティング・システ
ムの諸機能を実行する能力をサポートする概念であり、
ＭＡＣＨマイクロカーネルの重要な特徴である。たとえ
ば、ＭＡＣＨマイクロカーネルは、ユーザ・レベルのプ
ログラムにおいて仮想メモリのページング方針をサポー
トする。メモリ・オブジェクトは、この能力をサポート
する概念である。

【００２３】これらの概念はすべて、ＭＡＣＨマイクロ
カーネル・プログラミング・モデルにとって基本的なも
のであり、カーネル自体の中で使用される。Carnegie M
ellon UniversityのＭＡＣＨマイクロカーネルのこれら
の概念およびその他の特徴は、ジョセフ・ボイキン（Jo
seph Boykin）著"Programming Under MACH"、AddisonWe
ssely Publishing Company、１９９３年に記載されてい
る。

【００２４】ＵＮＩＸのパーソナリティをサポートする
ためのマイクロカーネルの使用に関する他の議論は、マ
イク・アセッタ（Mike Accetta）他の"MACH:A New Kern
el Foundation for UNIX Development"、Proceedings o
f the Summer 1986 USENIX Conference、米国ジョージ
ア州アトランタ論文に出ている。この話題に関するもう
１つの技術論文は、デビッド・ゴルブ（David Golub）
他の論文"UNIX as an Application Program"、Proceedi
ngs of the Summer 1990 USENIX Conference、米国カリ
フォルニア州アナハイムである。

【００２５】前記同時係属の米国特許出願第２６３７１
０号には、図１に示した、オペレーティング・システム
用の新しい基礎であるマイクロカーネル・システム１１
５が記載されている。マイクロカーネル・システム１１
５は、純粋なカーネルとして実施される１組の簡潔なカ
ーネル・サービスと、１組のユーザ・レベル・サーバと
して実施される、オペレーティング・システムのパーソ
ナリティを構築するための１組の大規模なサービスとを
提供する。マイクロカーネル・システム１１５は、様々
な従来のオペレーティング・システムの諸機能を提供
し、オペレーティング・システムのパーソナリティとし
て現出する多数のサーバ構成要素からなる。マイクロカ
ーネル・システム１１５は、タスク（クライアント）
が、通信チャネル上を送られるメッセージを介して他の
タスク（サーバ）に要求することによってサービスにア
クセスする、クライアント／サーバ・システム構造を使
用する。マイクロカーネル１２０は、それ自体では極め
て少数のサービスしか提供しないので（たとえば、ファ
イル・サービスは提供しない）、マイクロカーネル１２
０のタスクは、必要なサービスを提供する他の多数のタ
スクと通信しなければならない。

【００２６】マイクロカーネル・システム１１５を構成
する構成要素プログラムが多種多様でかつ多数あるた
め、セッションの開始時に大きなプログラム・ロード負
荷が課される。マイクロカーネル１２０自体を除き、す
べてのパーソナリティ・ニュートラル・サーバ（person
ality neutral server）およびパーソナリティ・プログ
ラム（personality program）は、ユーザ・アドレス空
間内で動作する。多数の共用ライブラリを有する構成要
素プログラムのシステムを始動させて、所望の調整され
た方式で動作を開始させるには何らかの手段が必要であ
る。

【００２７】

【発明が解決しようとする課題】したがって、本発明の
目的は、マイクロカーネル・オペレーティング・システ
ムの始動時の効率を改善することである。

【００２８】本発明のもう１つの目的は、マイクロカー
ネル・アーキテクチャにおける様々な構成要素プログラ
ムの始動時の調整を改善することである。

【００２９】本発明の他の目的は、マイクロカーネル・
システムにおける複数のプログラムおよびその共用ライ
ブラリの始動操作を改善することである。

【００３０】

【課題を解決するための手段】上記その他の目的、特徴
および利点は、本明細書に開示したマスタ・サーバ・プ
ログラム・ロード方法および装置によって達成される。
このマスタ・サーバ・プログラム・ロード方法は、マイ
クロカーネル・システムのメモリ内の多数の様々なプロ
グラムおよび共用ライブラリのロードを容易にするよう
に設計される。マスタ・サーバは、ローダ、動的リンカ
および動的ローダの３つの構成要素を有する。ローダ
は、始動前に実行可能プログラムをターゲット・タスク
内にロードするものである。動的リンカは、始動前に共
用ライブラリ・オブジェクトをターゲット・タスクとリ
ンクさせるものである。動的ローダは、プログラムの実
行時に共用ライブラリ・オブジェクトをロードするもの
である。このプログラム・ロード方法は、ローダがター
ゲット・プログラムをターゲット・タスク内にロード
し、制御を動的リンカに移すことから始まる。次に動的
リンカが、共用ライブラリ・オブジェクトをターゲット
・タスクにリンクし、制御をマスタ・サーバに移す。次
にマスタ・サーバが、制御をターゲット・プログラムに
移して終了する。

【００３１】本発明の１つの特徴は、メモリ内で共用ラ
イブラリ・オブジェクトを再配置するために、再配置情
報データをターゲット・タスク内に記憶することであ
る。動的リンカが再配置情報にアクセスして、共用ライ
ブラリ・オブジェクトにより再配置操作を実行する。動
的ローダはまた、実行時に共用ライブラリ・オブジェク
トにより再配置操作を実行する必要がある場合、そのと
き再配置情報にアクセスする。

【００３２】このように、このマスタ・サーバ・プログ
ラム・ロード方法および装置は、マイクロカーネル・シ
ステムのメモリ内の多数の様々なプログラムおよび共用
ライブラリのロードを容易にする。

【００３３】

【発明の実施の形態】

パートＡ．マイクロカーネル 第１章 マイクロカーネルの原理 図１は、マイクロカーネル・システム１１５の機能ブロ
ック図であり、様々なハードウェア・プラットフォーム
上でマイクロカーネル１２０およびパーソナリティ・ニ
ュートラル・サービス（ＰＮＳ）１４０が複数のオペレ
ーティング・システム・パーソナリティ１５０をどのよ
うに実行するかを示す。

【００３４】図１に示したホスト・マルチプロセッサ１
００は、補助記憶装置１０６にバス１０４によって接続
されたメモリ１０２を含む。補助記憶装置１０６は、た
とえばディスク・ドライブ、読取り専用または読み書き
光記憶装置、あるいはその他の任意の大容量記憶装置で
よい。これは、データをオリジナル・フォーマットで記
憶する補助データ・ソースである。これは、大量記憶装
置、データ通信装置、揮発性データ記憶装置、不揮発性
データ記憶装置、磁気データ記憶装置、光データ記憶装
置、書込み可能なランダム・アクセス・メモリ、プログ
ラマブル読取り専用メモリ、読取り専用メモリ、ローカ
ル・エリア・ネットワーク、分散処理ネットワーク、ま
たは遠隔通信ネットワークでよい。バス１０４には入出
力アダプタ１０８も接続され、この入出力アダプタ１０
８は、キーボード、モニタ・ディスプレイ、遠隔通信ア
ダプタ、ローカル・エリア・ネットワーク・アダプタ、
モデム、マルチメディア・インターフェース装置、また
は他の入出力装置に接続されていてもよい。バス１０４
はまた、第１のプロセッサＡ １１０、と第２のプロセ
ッサＢ １１２にも接続されている。図１に示した例
は、対称マルチプロセッサ構造のものであり、２つの単
一プロセッサ１１０および１１２が共通のメモリ・アド
レス空間１０２を共用する。同様な適切な例として、単
一または複数プロセッサの他の構成を示すこともでき
る。プロセッサは、たとえばインテル３８６（商標）Ｃ
ＰＵ、インテル４８６（商標）ＣＰＵ、ペンティアム
（商標）プロセッサ、またはその他の単一プロセッサ装
置など他の型式のものでもよい。

【００３５】メモリ１０２には、マイクロカーネル・シ
ステム１１５が記憶され、マイクロカーネル・システム
１１５は、マイクロカーネル１２０、マシン依存コード
１２５、パーソナリティ・ニュートラル・サービス１４
０、およびパーソナリティ・サーバ１５０を含む。マイ
クロカーネル・システム１１５は、メモリ１０２内に格
納されたアプリケーション・プログラム１８０用のオペ
レーティング・システムとして働く。

【００３６】本発明の目的は、ＵＮＩＸやＯＳ／２など
の従来のオペレーティング・システムのように振る舞う
オペレーティング・システムを提供することである。つ
まり、そのオペレーティング・システムは、ＯＳ／２ま
たはＵＮＩＸ、あるいは従来の他のオペレーティング・
システムのパーソナリティを有することになる。

【００３７】マイクロカーネル１２０は、計算機の基本
動作を制御する、ホスト・マルチプロセッサ１００の最
優先状態で動作する、システム・ソフトウェアのメッセ
ージを受け渡す小さな核を含む。マイクロカーネル・シ
ステム１１５は、マイクロカーネル１２０と、パーソナ
リティ・ニュートラル・サービス１４０を提供する１組
のサーバおよびデバイス・ドライバとを含む。名前が意
味するように、パーソナリティ・ニュートラル・サーバ
およびデバイス・ドライバは、ＵＮＩＸやＯＳ／２など
のどんなパーソナリティにも依存しない。パーソナリテ
ィ・ニュートラル・サーバおよびデバイス・ドライバ
は、マイクロカーネル１２０に依存しかつ互いに依存し
あう。パーソナリティ・サーバ１５０は、マイクロカー
ネル１２０のメッセージ受渡しサービスを利用してパー
ソナリティ・ニュートラル・サービス１４０と通信す
る。たとえば、ＵＮＩＸ、ＯＳ／２または他のパーソナ
リティ・サーバは、パーソナリティ・ニュートラル・デ
ィスク・ドライバにメッセージを送って、ディスクから
データのブロックを読み取るよう依頼する。ディスク・
ドライバは、そのブロックを読み取ってメッセージ中で
戻す。メッセージ・システムは、ポインタを操作するこ
とより大量のデータが迅速に転送されるように最適化さ
れ、したがってデータ自体はコピーされない。

【００３８】マイクロカーネル１２０は、そのサイズな
らびに標準プログラミング・サービスとアプリケーショ
ン・プログラムとしての機能をサポートできる能力のた
めに、標準のオペレーティング・システムよりも単純で
ある。マイクロカーネル・システム１１５は、様々な形
で構成されるモジュール式断片に分割され、断片を小さ
な断片に加えることにより大きなシステムを構築でき
る。たとえば、各パーソナリティ・ニュートラル・サー
バ１４０は論理的に分離しており、様々な形で構成する
ことができる。各サーバは、アプリケーション・プラグ
ラムとして動作し、アプリケーション・デバッガを使っ
てデバッグすることができる。各サーバは、別々のタス
ク内で動作し、サーバ内のエラーはそのタスクに制限さ
れる。

【００３９】図１は、プロセス間通信モジュール（ＩＰ
Ｃ）１２２、仮想メモリ・モジュール１２４、タスクお
よびスレッド・モジュール１２６、ホストおよびプロセ
ッサ・セット１２８、入出力サポートおよび割込み１３
０、マシン依存コード１２５を含むマイクロカーネル１
２０を示す。

【００４０】本発明によれば、図１に示したパーソナリ
ティ・ニュートラル・サービス１４０は、マスタ・サー
バ１４２を含み、マスタ・サーバ１４２はローダ１９
０、動的リンカ１９２および動的ローダ１９４を含む。
マスタ・サーバ１４２は、マイクロカーネル・システム
１１５内の様々なプログラム構成要素および共用ライブ
ラリを調整された形でロードする責任を負う。本発明の
マスタ・サーバ・プログラムのロード動作の詳細な考察
を以下に示す。

【００４１】また、図１のパーソナリティ・ニュートラ
ル・サービス１４０は、メモリ・オブジェクト管理モジ
ュール１４３および補助記憶管理モジュール１４５を備
えるデフォルト・ページャ１４４を含む。パーソナリテ
ィ・ニュートラル・サービス１４０はまた、複数パーソ
ナリティ・サポート／パーソナリティ・ニュートラル・
デバイス・ドライバ１４７を含むデバイス・サポート１
４６も含む。パーソナリティ・ニュートラル・サービス
１４０はさらに、ファイル・サーバ、ネットワーク・サ
ービス、データベース・エンジンおよびセキュリティを
含む他のパーソナリティ・ニュートラル・プロダクト１
４８も含む。

【００４２】パーソナリティ・サーバ１５０は、たとえ
ばＵＮＩＸパーソナリティなどの主要パーソナリティ１
５２である。パーソナリティ・サーバ１５０は、ＵＮＩ
Ｘサーバとなる補助空間用管理エンティティ１５４など
の主要パーソナリティ・サーバ、およびＵＮＩＸ主要パ
ーソナリティをサポートする入出力システム・デバイス
・ドライバ１５５などの他の主要パーソナリティ・サー
ビスを含む。代替主要パーソナリティ１５６は、たとえ
ばＯＳ／２でよい。代替パーソナリティ１５６には、補
助空間用管理エンティティ１５８などＯＳ／２パーソナ
リティを特徴づける代替パーソナリティ・サーバと、入
出力システム・デバイス・ドライバ１５９などＯＳ／２
用の他の代替パーソナリティ・サービスとが含まれる。

【００４３】図１に示した、ＵＮＩＸ主要パーソナリテ
ィの例に関連する主要パーソナリティ・アプリケーショ
ン１８２は、ＵＮＩＸオペレーティング・システム・パ
ーソナリティ１５２上で動作するＵＮＩＸ型アプリケー
ションである。図１に示した代替パーソナリティ・アプ
リケーション１８６は、ＯＳ／２代替パーソナリティ・
オペレーティング・システム１５６上で動作するＯＳ／
２アプリケーションである。図１には、本発明による再
配置情報２１４を含むタスク２１０も示されている。タ
スク２１０内に再配置情報を配置することによって、そ
のタスクに関してプログラム・ロード操作を実行するた
めに、動的リンカ１９２と動的ローダ１９４がこの情報
を迅速に取り出せるようになる。

【００４４】図１では、マイクロカーネル・システム１
１５がその実施を、あるタイプのプロセッサから別のタ
イプのプロセッサに完全に移植可能なコードと、実行し
ている特定装置内のプロセッサ・タイプに依存するコー
ドとに入念に分割する。マイクロカーネル・システム１
１５はまた、デバイスに依存するコードをデバイス・ド
ライバに分離し、したがって、デバイス・ドライバ・コ
ードはデバイス依存であるが、必ずしもプロセッサ・ア
ーキテクチャに依存しない。マイクロカーネル・システ
ム１１５は、タスクごとに複数のスレッドを使用するこ
とによって、どれか特定の装置がマルチプロセッサであ
ることを必要とせずにマルチプロセッサを使用できるア
プリケーション環境を提供する。単一プロセッサ上で
は、様々なスレッドが異なる時間に動作する。複数のプ
ロセッサに必要なサポートはすべて、小さく単純なマイ
クロカーネル１２０に集中される。

【００４５】上記の特許出願に、アーキテクチャ・モデ
ル、タスク、スレッド、ポート、およびプロセス間通信
を含むマイクロカーネル・システム１１５と、マイクロ
カーネル１２０の諸機能のより詳細な説明が出ている。
マイクロカーネル１２０によって提供される仮想環境
は、カーネルによって提供されるエミュレートされた命
令（システム・トラップ）によって増補された、ユーザ
空間からアクセス可能なすべてのハードウェア命令を実
行する仮想プロセッサからなり、この仮想プロセッサ
は、１組の仮想レジスタと、他の点ではマシンの物理メ
モリと同様に応答する何らかの仮想メモリにアクセスす
る。他のすべてのハードウェア資源は、メモリ・アクセ
スとエミュレートされた命令の特別な組合せによっての
みアクセス可能である。当然ながら、スレッドによって
提示された命令を実際に実行するのは物理プロセッサで
ある。

【００４６】スレッドを実行できる物理プロセッサはそ
れぞれ、プロセッサ制御ポートと呼ばれる。それらのプ
ロセッサは、実際の作業を行う点では重要であるが、マ
イクロカーネルにおいてはプロセッサ・セットのメンバ
として以外はあまり重要でない。プロセッサ・セット
は、１組のスレッドのスケジュールを立てるために使用
されるプロセッサのプールの基礎を構成し、それと関連
したスケジューリング属性を有する。プロセッサのため
にサポートされる操作には、プロセッサ・セットに対す
る指定、および始動や停止などの装置制御が含まれる。

【００４７】メモリ管理 カーネルは、何らかのメモリ管理を提供する。メモリ
は、タスクと関連付けされる。メモリ・オブジェクト
は、タスクがメモリ管理を制御するための手段である。
マイクロカーネル・システム１１５は、大型で潜在的に
疎らな仮想アドレス空間をサポートするための機構を提
供する。各タスクは、カーネルによって維持されタスク
のアドレス空間における仮想アドレスの物理アドレスへ
の変換を制御する、関連アドレス・マップを有する。仮
想メモリ・システム内と同様に、所与のタスクのアドレ
ス空間全体の内容が完全に物理メモリ内に同時に常駐す
るわけではなく、タスクの仮想アドレス空間用のキャッ
シュとして物理メモリを使用する機構がなければならな
い。従来の仮想メモリの設計とは違って、マイクロカー
ネル・システム１１５は、それ自体ですべてのキャッシ
ングを実施するわけでなない。マイクロカーネル・シス
テム１１５は、ユーザ・モードのタスクにこれらの機構
に関与する能力を与える。パーソナリティ・ニュートラ
ル・サービスは、メモリにページング・サービスを提供
するユーザ・タスクである、デフォルト・ページャ１４
４を含む。

【００４８】マイクロカーネル・システム１１５内の他
の資源と違って、仮想メモリはポートを使って参照され
ない。メモリは、特定のタスク・アドレス空間への索引
として仮想アドレスを使用することによってのみ参照す
ることができる。メモリと、タスクのアドレス空間を定
義する関連アドレス・マップとは、他のタスクと部分的
に共用することができる。タスクは、そのアドレス空間
内に新しいメモリ範囲を割り振り、それを割り振り解除
し、それに対する保護を変更することができる。タスク
はまた、その範囲の継承特性を指定できる。新しいタス
クは、新しいタスク用のアドレス空間を構築する基礎と
して既存のタスクを指定することによって作成される。
既存タスクの各メモリ範囲の継承属性によって、新しい
タスクがその定義された範囲を有するかどうかが決ま
り、またその範囲が仮想コピーされるかそれとも既存タ
スクと共用されるかどうかが決まる。メモリに関するほ
とんどの仮想コピー操作は、書込み時コピー最適化によ
って実施される。書込み時コピー最適化は、共用を保護
することによって実施される。２つのタスクは、コピー
するメモリを共用するが、読取り専用アクセスである。
いずれかのタスクが範囲の一部を修正しようとすると
き、その部分がその時点でコピーされる。このメモリ・
コピーの遅延評価は、マイクロカーネル・システム１１
５によって実行される重要なパフォーマンス最適化であ
り、このシステムの通信／メモリの原理にとって重要で
ある。

【００４９】マイクロカーネル・システム１１５では、
機能的に独立した多数のサーバ・プログラムによってサ
ービスが提供される。マイクロカーネル１２０自体を除
くすべてのサーバは、ユーザ・アドレス空間内で動作す
る。マスタ・サーバ１４２（ＭＳ）は、マイクロカーネ
ル・システム１１５内にプログラムおよび共用オブジェ
クト・ローダとして設計される。ＭＳローダ１９０はシ
ステム起動中に早期に始動され、他のすべてのシステム
・サービスを始動させて、１つまたは複数のオペレーテ
ィング・システム環境を提供する。

【００５０】図１は、ホスト・マルチプロセッサ１００
のメモリ１０２内のマイクロカーネル・システム１１５
の機能ブロック図であり、マイクロカーネル１２０とパ
ーソナリティ・ニュートラル・サービス１４０が複数の
オペレーティング・システムパーソナリティをどのよう
に実行するかを示す。マスタ・サーバ１４２は、図１に
示したように、ローダ１９０、動的リンカ１９２、動的
ローダ１９４の３つのモジュールに区分される。すべて
のプログラムを、１つまたは複数の共用ライブラリと動
的にリンクすることができる。これらの共用ライブラリ
は、プログラム・ロード時にロードされる。外部データ
参照は、プログラム・ロード時に完全に解決される。外
部機能参照は、プログラム・ロード時に完全に解決する
ことも実行時間まで延期することもできる。共用ライブ
ラリはまた、プログラム実行中にロードしプログラムと
動的にリンクすることもでき、これがいわゆる動的ロー
ディングである。マスタ・サーバ１４２は、プログラム
自体をロードする基本ローダ１９０モジュールを含む。
動的リンカ１９２は、プログラム・ロードの一環として
すべての共用ライブラリをロードする、スタートアップ
・コードの一部分である。動的ローダ１９４は、必要な
らば、動的リンカ１９２によって提供されるサービスを
使用できる、プログラムの一部分である。動的リンカ１
９２と動的ローダ１９４は共に、共用オブジェクトとし
て実現することができる。外部参照をターゲット・プロ
グラム２２０のアドレスで解決すると、（１）アドレス
変換が必要なく、（２）複数プロセッサには理想的なの
で、効率が高くなる。

【００５１】本発明では、タスク２１０内に再配置情報
２１４を維持し、この再配置情報２１４は、動的リンカ
１９２および動的ローダ１９４のみならずデバッガおよ
び追跡ユーティリティにも役立つ。図２は、タスク２１
０のメモリ・マップであり、再配置情報２１４の記憶場
所を示す。再配置情報２１４はまた、再配置情報に関す
るデータを含むメモリ・オブジェクトへのポインタとす
ることもできる。

【００５２】再配置情報２１４は、ターゲット・プログ
ラム２２０空間内の、タスク２１０によって指示されマ
スタ・サーバ１４２に既知の場所に常駐するデータ構造
内にある。動的リンカ１９２が、そのデータ構造を作成
してマスタ・サーバ１４２ならびに動的ローダ１９４を
使用可能にする。情報は、動的リンカ１９２および動的
ローダ１９４の両方に必要なので、ターゲット・プログ
ラム２２０のアドレス空間内で情報を維持するとより効
率的である。マスタ・サーバ１４２はこの情報の場所を
知っているので、この情報にどうアクセスすべきかを知
っており、それをデバッガおよび追跡ユーティリティに
使用可能にすることができる。マスタ・サーバ１４２
が、動的リンカ１９２または動的ローダ１９４の遠隔手
順呼出しを介してではなく再配置情報２１４に直接アク
セスすることの利点は、デバッガでは通例のことである
が、ターゲット・プログラム２２０が一時中断されて
も、情報検索サービスが中断されないことである。

【００５３】本発明では、プログラムの実行をプログラ
ムのロードとプログラムの始動に分割する。これを図３
の流れ図に示す。図３は、マスタ・サーバ１４２のプロ
グラム・ロード方法３００の流れ図である。

【００５４】プログラムを実行するために、マスタ・サ
ーバ１４２は、図３の段階３１０でターゲット・プログ
ラム２２０をロードして動的リンカ１９２に制御を渡
す。段階３２０で、動的リンカ１９２は必要なすべての
共用ライブラリをロードし、マスタ・サーバ１４２に制
御を戻す。次に段階３３０で、マスタ・サーバ１４２は
ターゲット・プログラム２２０に制御を戻す。プログラ
ムの実行を２段階に分けることの利点は、（１）異なる
１組の引数および環境文字列を動的リンカ１９２および
ターゲット・プログラム２２０に渡すことができ、フレ
キシビリティが高くなること、および（２）ターゲット
・プログラム２２０を既知の状態から始動したいデバッ
ガにとって理想的であるが、ロード後に別のエンティテ
ィによってターゲット・プログラム２２０を始動するこ
とができることである。

【００５５】本発明では、ファイル管理機能を、マスタ
・サーバ１４２、外部メモリ・マネージャ、およびファ
イル・サーバの間で分割して、冗長性を回避する。

【００５６】ローディングのパフォーマンスを改善する
ためには、プログラム・ファイルおよび共用ライブラリ
・ファイルを、実際にメモリ内にコピーするのではなく
メモリ空間にマップしなければならない。マスタ・サー
バ１４２のローダ１９０、動的リンカ１９２および動的
ローダ１９４は、ファイル・サーバからのマップ・イン
ターフェースを必要とする。システム起動の早期段階で
ファイル・サーバがないときは、プログラム・ファイル
はブートストラップ・タスクを介してアクセス可能にな
る。ブートストラップ・タスクはまた、ファイル・サー
バと同じマップ・インターフェースも提供する。ブート
ストラップ・タスクからマップされたファイルは、外部
メモリ・マネージャによって管理される。したがって、
この方法により、マイクロカーネル・システム１１５に
冗長機能が導入されるのを回避することができる。

【００５７】マスタ・サーバ用のローダ１９０および動
的リンカ１９２ マスタ・サーバ１４２および関連ライブラリは、パーソ
ナリティ・ニュートラル・サービス・プログラムをロー
ドする能力をユーザに提供する。また、共用ライブラリ
を使用できる能力をパーソナリティ・ニュートラル・サ
ービス・プログラムに提供する。マスタ・サーバ１４２
のローダ１９０機能および動的リンカ１９２機能は、マ
スタ・サーバ・タスクとマスタ・サーバ１４２によって
始動されるパーソナリティ・ニュートラル・サービス・
タスクの間で分割される。これをさらに明らかにするた
めに、ローダ１９０と動的リンカ１９２の用語を以下の
ように使用する。

【００５８】ローダ１９０−ローダ１９０はマスタ・サ
ーバ１４２内にあり、実行可能なプログラムをターゲッ
ト・タスク２１０内にロードする。動的リンカ１９２−
これは、本質的にライブラリであり、マスタ・サーバ１
４２によって始動されたプログラムがこのライブラリと
リンクされる。動的ローダ１９４は、始動中に共用ライ
ブラリをロードし、再配置を実行する。動的リンカ１９
２はまた、実行時に記号解決を提供するコードを有する
（ＬＤ＿ＢＩＮＤ＿ＮＯＷフラグ）。

【００５９】動的ローダ１９４−これは、実行時に共用
ライブラリをロード／アンロードするための、ライブラ
リ呼出しdl_open()、dl_close()、dl_sym()、およびdl_
error()をサポートする。したがって、動的リンカ１９
２によって提供されるサービスを使用する。

【００６０】ローダ１９０ マスタ・サーバ１４２内で動作するローダ１９０は、呼
出し側からの２つの異なる要求、MS_LoadResource およ
びMS_StartResourceとしてタスクをロードし始動するサ
ポートを提供する。その代わりに、単一の呼出しMS_Sta
rtResourceでタスクのロードと始動を行うこともでき
る。

【００６１】このことは、マスタ・サーバ１４２が内部
でタスクのロードと開始を別々に実施していることを暗
示する。

【００６２】プログラムのロードを最初のロードと次の
始動との別々の２つの段階に分離することが本発明の特
徴である。そのようにすることの利点は、タスクをロー
ドした後そのタスクを実行する前に第三者がタスクを操
作できることである。この特徴によりデバッガがタスク
に容易に接続できるようになるので、デバッガのような
システム保守ユーティリティがこの特徴から恩恵を受け
ることができる。

【００６３】図４は、ローダ１９０によって実行される
方法４００の流れ図である。

【００６４】タスクのロード − ファイルを開いて認識する − ターゲット・タスク２１０上にセグメントをマップ
する − ターゲット・タスク２１０用のポートおよび他の初
期設定 − ターゲット・タスク２１０上で動的ローダを始動す
る

【００６５】段階４１０：（ａ） ファイルを開いて認
識する マスタ・サーバ１４２のローダ１９０がファイルを開
き、ファイル・フォーマットを認識し、ファイル用のMo
dule_Handleを作成する（ＥＬＦの場合はそのElf Module
_Handle)。

【００６６】段階４２０：（ｂ） ターゲット・タスク
２１０上にセグメントをマップする ターゲット・タスク２１０上にセグメントをマップす
る。マップされるセグメントは実行可能ファイル用のも
のだけである。共用ライブラリはローダ１９０によって
マップされない。

【００６７】マスタ・サーバ１４２のローダ１９０はま
た、ターゲット・タスク上にElf Module_Handleをｖｍ
書込みする。Elf Module_Handleはまたプログラム・ヘ
ッダも含む。プログラム・ヘッダ情報は、実行可能プロ
グラムがテキスト・セグメント内に再配置要件（ＤＴ＿
ＴＥＸＴＲＥＬ）を有する場合に、動的リンカを必要と
する。この場合、動的リンカ１９２は、テキスト・セグ
メントを識別し、このセグメント内での書込みが可能な
ように許可を変更することができなければならない。

【００６８】段階４３０：（ｃ） ターゲット・タスク
２１０用のポートおよび他の初期設定 ターゲット・タスク２１０用の他の初期設定を実行す
る。たとえば、ターゲット・タスク２１０用の例外ハン
ドラおよびポート名空間を占有する。

【００６９】段階４４０：（ｄ） ターゲット・タスク
２１０上で動的リンカ１９２を始動する この時点で、マスタ・サーバ１４２のローダ１９０が、
動的リンカ１９２に渡される引数を作成する。以下の引
数が動的リンカ１９２に供給される。 argv[1] int FILE TYPE(ELF,AOUT,XCOFF,…） argv[2] vm_address_t Elf_Module_Handleのアドレス

【００７０】ターゲット・タスク２１０上でスレッドが
作成される。次に、ａｒｇｃ、ａｒｇｖおよびスタック
が作成され、動的リンカ１９２が始動される。この時点
で、マスタ・サーバ１４２はローディングのその部分を
完了した。

【００７１】段階４５０：この時点で、マスタ・サーバ
１４２は、ターゲット・タスク２１０から動的リンキン
グ完了の通知を待つだけでよい。

【００７２】動的リンカ１９２は、インターフェースを
介してリンキング・プロセスの完了を知らせる。 MS_LinkNotify( ms_special_port, /*ターゲット・タスクのブートストラップ・ポートと同じ*/ target_task, /*ターゲット・タスク２１０のカーネル・ポート*/ linking_status /*動的リンカ１９２によって戻される状況*/ /* *linking status values: */ #define MS_LINK_STATUS_SUCCESS MS SUCCESS /*リンキング成功*/ #define MS_LINK_STATUS_NOFILE MS FILE NOTFOUND /*そのようなリップは見つからなかった*/ #define MS_LINK_STATUS_BADFILE MS FILE BADFORMAT /*ＥＬＦファイルではない*/

【００７３】ターゲット・タスク２１０上の呼出しスレ
ッドは、この呼出しを行った後で終了する。

【００７４】マスタ・サーバ１４２は、通知を受け取る
と通知の結果を呼出し側タスクに戻す。

【００７５】MS_LoadResourceとMS_StartResource呼出
しは、次のように実施される。呼出し側のｍｉｇ定義
は、マスタ・サーバ１４２のｍｉｇ定義とは異なる。呼
出し側（クライアント）のｍｉｇ定義は、同期呼出しの
ように見える。一方、マスタ・サーバ１４２（サーバ）
はそれを２つの同期呼出しに分割する。マスタ・サーバ
１４２（サーバ）のｍｉｇ定義は、マスタ・サーバ１４
２がLoad/StartResourceに対する要求を受け取るように
分割される。ターゲット・タスク２１０をロードした後
で、マスタ・サーバ１４２のサーバ・スレッドは、さら
に他の要求の処理準備完了を戻す。一方、呼出し側は待
ち続ける。ターゲット・タスク２１０がマスタ・サーバ
１４２に（MS_LinkNotifyにより）通知を出すときは、
動的リンキングの状況であり、マスタ・サーバ１４２は
別のＩＰＣメッセージを送る。このメッセージは、実際
には、呼出し側によって行われるMS_LoadResource/MS_S
tartResource呼出しから戻された値として現れる。

【００７６】タスクの始動 ローディングが成功した場合、タスクはただちに、ある
いは後で呼出し側から要求されたときに始動できる。

【００７７】タスクを始動するために、ローダ１９０は
ターゲット・タスク内に新しいスレッドを作成する。次
に、ａｒｇｃ、ａｒｇｖおよびスタックをセットする。
そしてスレッドが始動される。

【００７８】動的リンカ１９２ 動的リンカ１９２用のスタートアップ・コード 図５は、動的リンカ１９２によって実行される方法５０
０の流れ図である。動的リンカ１９２は、始動時に以下
の機能を実行する。 段階５１０：（ａ） flag_relocatedを以下のようにセットする if (I(flag_relocated)){ ms InitDyneElfLinker(); /*下記段階（ｂ）ないし（ｅ）を呼び出す*/ flag_relocated++; return; } continue processing,main ()etc…

【００７９】スタートアップ・コードが一番最初に呼び
出されるときは、再配置を実行して戻る。２回目の要求
では、再配置をスキップしユーザ・コードを呼び出す。

【００８０】段階５２０：（ｂ） ファイルがＥＬＦで
はない場合は、残りの初期設定をスキップする。

【００８１】段階５３０：（ｃ） 共用ライブラリの依
存関係リストを作成する。これには、２つの連係リス
ト、つまりElf_Module_handleの共用ライブラリ・リス
トおよびｄｅｐ＿ｅｎｔｒｙの連係リストを更新する必
要がある。共用ライブラリのすべてのエントリは１のｒ
ｅｆ＿ｃｏｕｎｔを有する。（本明細書の最後にあるデ
ータ構造の説明を参照のこと）

【００８２】段階５４０：（ｄ） すべての共用ライブ
ラリをマップする

【００８３】段階５５０：（ｅ） 実行可能ファイルお
よび共用ライブラリの再配置を実行する

【００８４】動的ローダ１９４ dl *()機能の実行時サポート：サポートされる４つの機
能、dl_open()、dl_close()、dl_sym()、およびdl_writ
e()である。

【００８５】dl_open() この機能は、動的リンカ１９２用のスタートアップ・コ
ードと類似している。図６は、動的ローダ１９４によっ
て実行される方法６００の流れ図である。これは以下の
段階を含む。

【００８６】段階６１０：（ａ） まず、図７に示した
既存の共用ライブラリ・リスト７００中で共用ライブラ
リ７１０を探す。見つかった場合は、新しい依存関係リ
ストを作成し、この共用ライブラリおよびそのいずれか
の依存物のｒｅｆ＿ｃｏｕｎｔを更新する。戻る。

【００８７】段階６２０：（ｂ） 共用ライブラリ７１
０を開いて読み取り、フォーマットがＥＬＦかどうか確
認し、ＥＬＦではない場合はＥＲＲＯＲを戻す。

【００８８】段階６３０：（ｃ） 図８の依存関係リス
ト８００を作成する。依存関係リストを作成するとき
は、マップされていないがマップする必要のある共用ラ
イブラリをマップする。新しい共用ライブラリがマップ
されると、その共用ライブラリはｒｅｆ＿ｃｏｕｎｔが
１の共用ライブラリ・リストに付加される。共用ライブ
ラリがすでにマップされている場合は、その参照カウン
トだけを更新する。

【００８９】段階６４０：（ｄ） これらの共用ライブ
ラリに必要な再配置を実行する

【００９０】段階６５０：（ｅ） 現依存関係リスト８
２０を、依存関係リスト８００の末尾８１０に付加する
（図８のデータ構造を参照のこと）。

【００９１】段階６６０：（ｆ） このテーブル８００
用の現依存関係リスト８２０の先頭８０５であるハンド
ルを戻す。

【００９２】dl_close()： （ａ）依存関係リストを削除し、依存関係リスト内のす
べての共用ライブラリの参照カウントを減少させる。

【００９３】dl sym()：実行可能ファイル（ハンド＝Ｎ
ＵＬＬ）の場合は、記号テーブルは動的リンキングに必
要な記号だけを有する。共用ライブラリの場合は、すべ
ての記号が使用可能である（共用ライブラリ用のｅｌｆ
ｄｕｍｐに見られるように）。

【００９４】dl error()：このルーチンは、上記のdl_*
()呼出しの間に起こった最終エラーを抽出する。エラー
の値は静的バッファ内に戻される。

【００９５】このバッファは、次の呼出しで上書きされ
る。スレッドは、新しい文字列をバッファ内に常にコピ
ーすることによって安全になる。

【００９６】データ構造：図７は、共用ライブラリの連
係リスト７００を示す。

【００９７】図８は、依存関係リスト８００を示す。

【００９８】（ａ）マップされた共用ライブラリのリス
トは、Elf_Module_Handle構造に記憶される。

【００９９】（ｂ）初期オープン用およびすべてのdl_o
pen()用の依存関係リスト

【０１００】図７に、共用ライブラリ連係リスト７００
を示す。

【０１０１】図８に、依存関係リスト８００を示す。

【０１０２】動的リンカ１９２および動的ローダ１９４
はタスク・アドレス空間内で動作し、ローダ１９０のア
ドレス空間内では動作しない。ロードするすべての共用
ライブラリおよびその場所のリストなど再配置情報２１
４を記憶する理想的な場所はタスク内である。再配置情
報２１４は動的リンカ１９２によって構成され、動的ロ
ーダ１９４によって更新される。再配置情報２１４は、
デバッガなど他のタスクが利用できなければならない。

【０１０３】再配置情報２１４は、データ構造内の、マ
スタ・サーバ１４２内のローダ１９０、動的リンカ１９
２および動的ローダ１９４に既知のアドレスに記憶され
る。デバッガなどのユーティリティ・プログラムは、マ
スタ・サーバ１４２からのみ情報を取り出す。 /*再配置情報２１４は次のように記憶される * *MS_RELOC_INFO *１番目のモジュールのMS_MODULE_INFO * １番目のセグメントのプログラム・ヘッダ（Elf32_Phdr構造） * ２番目のセグメントのプログラム・ヘッダ（Elf32-Phdr構造） * .... * 最後のセグメントのプログラム・ヘッダ（Elf32-Phdr構造） *２番目のモジュールのMS_MODULE_INFO * １番目のセグメントのプログラム・ヘッダ（Elf32_Phdr構造） * ２番目のセグメントのプログラム・ヘッダ（Elf32-Phdr構造） * .... * 最後のセグメントのプログラム・ヘッダ（Elf32-Phdr構造） *.... *.... *最後のモジュールのMS_MODULE_INFO * １番目のセグメントのプログラム・ヘッダ（Elf32_Phdr構造） * ２番目のセグメントのプログラム・ヘッダ（Elf32-Phdr構造） * .... * 最後のセグメントのプログラム・ヘッダ（Elf32-Phdr構造） */

【０１０４】再配置情報２１４のデータ構造とそれをす
べてのシステム構成要素が使用できるようにする方法が
本発明の特徴である。

【０１０５】利点は以下の通りである。 （１）最も便利な場所に記憶される。その場所は、タス
ク・アドレス空間内であり、動的リンカ１９２および動
的ローダ１９４もそこに配置される。 （２）マスタ・サーバ１４２を経由し１組のインターフ
ェースを介して他のユーティリティが使用できるように
なる。情報はマスタ・サーバ１４２に既知の場所にある
ので、マスタ・サーバ１４２はその情報をそのアドレス
空間にマップすることによって情報を取り出すことがで
きる。その情報は、タスクがデバッガによって中断され
ているときでも使用可能である。

【０１０６】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１０７】（１）データ処理システムにおいて、デー
タ処理システム内にあり、データ構造およびプログラム
命令を記憶するメモリ手段と、前記メモリ手段に結合さ
れたバス手段と、メモリ手段に結合され、前記メモリ手
段に記憶された前記プログラム命令を実行するプロセッ
サ手段と、前記メモリ手段内のターゲット・タスクと、
前記メモリ手段内にあり、前記メモリ手段内にプログラ
ムをロードするマスタ・サーバ・プログラム・ロード手
段と、前記マスタ・サーバ・プログラム・ロード手段内
にあり、実行可能プログラムを前記ターゲット・タスク
内にロードするローダ手段と、前記マスタ・サーバ・プ
ログラム・ロード手段内にあり、共用ライブラリ・オブ
ジェクトを前記ターゲット・タスクにリンクさせる動的
リンカ手段とを含み、前記ローダ手段が、ターゲット・
プログラムを前記ターゲット・タスクにロードして制御
を前記動的リンカ手段に移し、前記動的リンカ手段が、
共用ライブラリ・オブジェクトをロードし、前記共用ラ
イブラリ・オブジェクトを前記ターゲット・タスクにリ
ンクさせ、制御をマスタ・サーバ・プログラム・ロード
手段に移し、前記マスタ・サーバ・プログラム・ロード
手段が、制御を前記ターゲット・プログラムに移すこと
を特徴とするプログラム・ロード装置 （２）前記ターゲット・タスク内にあり、前記メモリ内
で前記共用ライブラリ・オブジェクトを再配置するため
の再配置情報データをさらに含み、前記動的リンカが、
前記再配置情報にアクセスし、前記共用ライブラリ・オ
ブジェクトにより再配置動作を実行することを特徴とす
る、上記（１）に記載のプログラム・ロード装置。 （３）前記ローダ手段がさらに、前記ローダ手段内にあ
り、ターゲット・プログラム・ファイルを開いて認識す
る手段と、前記ローダ手段内にあり、前記ターゲット・
タスク上にターゲット・プログラム・ファイルのセグメ
ントをマップする手段と、前記ローダ手段内にあり、前
記ターゲット・タスク用のポートを初期設定する手段、
および前記ローダ手段内にあり、前記ターゲット・タス
ク上で動的リンカを始動する手段とを含むことを特徴と
する、上記（１）に記載のプログラム・ロード装置。 （４）前記動的リンカ手段が、さらに、前記動的リンカ
手段内にあり、再配置フラグをセットする手段と、前記
動的リンカ手段内にあり、前記プログラム・ファイルが
ロード・ファイルかどうか判定する手段と、前記動的リ
ンカ手段内にあり、前記共用ライブラリ・オブジェクト
の依存関係リストを作成する手段と、前記動的リンカ手
段内にあり、前記共用ライブラリ・オブジェクトをマッ
プする手段と、前記動的リンカ手段内にあり、前記共用
ライブラリ・オブジェクトの再配置を実行する手段とを
含むことを特徴とする、上記（３）に記載のプログラム
・ロード装置。 （５）前記マスタ・サーバ・プログラム・ロード手段内
にあり、前記ターゲット・プログラムの実行時に前記共
用ライブラリ・オブジェクトを前記ターゲット・タスク
にロードする動的ローダ手段をさらに含む、上記（１）
に記載のプログラム・ロード装置。 （６）前記動的ローダ手段が、さらに、前記ターゲット
・タスク内にあり、前記メモリ内で前記共用ライブラリ
・オブジェクトを再配置するための再配置情報データを
含み、前記動的ローダが、前記再配置情報データにアク
セスして前記共用ライブラリ・オブジェクトにより再配
置操作を実行することを特徴とする、上記（５）に記載
のプログラム・ロード装置。 （７）前記動的ローダ手段が、さらに、前記共用ライブ
ラリ・オブジェクトを見つける手段と、前記共用ライブ
ラリ・オブジェクトを開いて読み取り、前記共用ライブ
ラリ・オブジェクトがロード・ファイルかどうか判定す
る手段と、前記共用ライブラリ・オブジェクトの依存関
係リストを作成する手段と、前記共用ライブラリ・オブ
ジェクトの再配置を実行する手段と、現依存関係リスト
を既存の依存関係リストの末尾に増補する手段と、現依
存関係リストのハンドルを戻す手段とを含むことを特徴
とする、上記（５）に記載のプログラム・ロード装置。 （８）メモリ手段とプロセッサ手段を含むデータ処理シ
ステムにおいて、ローダ手段によりターゲット・プログ
ラムをターゲット・タスク内にロードし、制御を動的リ
ンカ手段に移す段階と、動的リンカ手段により共用ライ
ブラリ・オブジェクトをロードし、前記共用ライブラリ
・オブジェクトを前記ターゲット・タスクにリンクし、
制御をマスタ・サーバ・プログラム・ロード手段に移す
段階とを含み、前記マスタ・サーバ・プログラム・ロー
ド手段が、制御を前記ターゲット・プログラムに移すこ
とを特徴とするプログラム・ロード方法。 （９）前記メモリ内に前記共用ライブラリ・オブジェク
トを再配置するための再配置情報データを前記ターゲッ
ト・タスク内に記憶する段階をさらに含み、前記動的リ
ンカが、前記再配置情報にアクセスして前記共用ライブ
ラリ・オブジェクトにより再配置操作を実行することを
特徴とする、上記（８）に記載のプログラム・ロード方
法。 （１０）前記ローダ手段が、ターゲット・プログラム・
ファイルを開いて認識する段階と、前記ターゲット・タ
スク上にターゲット・プログラム・ファイルのセグメン
トをマップする段階と、前記ターゲット・タスク用のポ
ートを初期設定する段階と、前記ターゲット・タスク上
で前記動的リンカを始動する段階とを含む方法を実行す
ることを特徴とする、上記（８）に記載のプログラム・
ロード方法。 （１１）前記動的リンカ手段が、再配置フラグをセット
する段階と、前記プログラム・ファイルがロード・ファ
イルかどうか判定する段階と、前記共用ライブラリ・オ
ブジェクトの依存関係リストを作成する段階と、前記共
用ライブラリ・オブジェクトをマップする段階と、前記
共用ライブラリ・オブジェクトの再配置を実行する段階
とを含む方法を実行することを特徴とする、上記（１
０）に記載のプログラム・ロード方法。 （１２）前記ターゲット・プログラムの実行時に、動的
ローダ手段により共用ライブラリ・オブジェクトを前記
ターゲット・タスク内にロードする段階をさらに含むこ
とを特徴とする、上記（８）に記載のプログラム・ロー
ド方法。 （１３）前記動的ローダ手段が、前記メモリ内で前記共
用ライブラリ・オブジェクトを再配置する段階と、前記
再配置情報にアクセスして、前記共用ライブラリ・オブ
ジェクトにより再配置操作を実行する段階とを含む方法
を実行することを特徴とする、上記（１２）に記載のプ
ログラム・ロード方法。 （１４）前記動的ローダ手段が、前記共用ライブラリ・
オブジェクトを見つける段階と、前記共用ライブラリを
開いて読み取り、それがロード・ファイルであると判定
する段階と、前記共用ライブラリ・オブジェクトの依存
関係リストを作成する段階と、前記共用ライブラリ・オ
ブジェクトの再配置を実行する段階と、現依存関係リス
トを既存の依存関係リストの末尾に増補する段階と、現
依存関係リストのハンドルを戻す段階とを含む方法を実
行することを特徴とする、上記（１２）に記載のプログ
ラム・ロード方法。

【０１０８】

【発明の効果】以上のマスタ・サーバ・プログラム・ロ
ード方法および装置の発明は、マイクロカーネル・シス
テム１１５のさまざまなプログラム構成要素のローディ
ングにおける効率、フレキシビリティ、調整を改善す
る。

【図面の簡単な説明】

【図１】マイクロカーネル１２０およびパーソナリティ
・ニュートラル・サービス１４０が複数のオペレーティ
ング・システム・パーソナリティをどのように実行する
かを示す、ホスト・マルチプロセッサ１００のメモリ１
０２内のマイクロカーネル・システム１１５の機能ブロ
ック図である。

【図２】タスク２１０のメモリ・マップを示す図であ
る。

【図３】マスタ・サーバのプログラム・ロード方法３０
０の流れ図である。

【図４】ローダ１９０によって実行される方法４００の
流れ図である。

【図５】動的リンカ１９２によって実行される方法５０
０の流れ図である。

【図６】動的ローダ１９４によって実行される方法６０
０の流れ図である。

【図７】共用ライブラリ連係リスト７００を示す図であ
る。

【図８】依存関係リスト８００を示す図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 チン・ユン・チャオ アメリカ合衆国33434 フロリダ州ボカ・ ラトン ネプチューンズ・ベーシン・コー ト 9281 (72)発明者 ジェームズ・マイケル・マジー アメリカ合衆国33463 フロリダ州レー ク・ワース キャナル・ドライブ 5310 (72)発明者 リチャード・マンコフスキ アメリカ合衆国33496 フロリダ州ボカ・ ラトン ミリタリー・トレール ノース 6503 ナンバー4402 (72)発明者 ヴィンケッシュ・オー・メフタ アメリカ合衆国78717 テキサス州オース チン スプレットアロウ・ドライブ 8906

Claims (14)

【特許請求の範囲】
1. 【請求項１】データ処理システムにおいて、 データ処理システム内にあり、データ構造およびプログ
   ラム命令を記憶するメモリ手段と、 前記メモリ手段に結合されたバス手段と、 メモリ手段に結合され、前記メモリ手段に記憶された前
   記プログラム命令を実行するプロセッサ手段と、 前記メモリ手段内のターゲット・タスクと、 前記メモリ手段内にあり、前記メモリ手段内にプログラ
   ムをロードするマスタ・サーバ・プログラム・ロード手
   段と、 前記マスタ・サーバ・プログラム・ロード手段内にあ
   り、実行可能プログラムを前記ターゲット・タスク内に
   ロードするローダ手段と、 前記マスタ・サーバ・プログラム・ロード手段内にあ
   り、共用ライブラリ・オブジェクトを前記ターゲット・
   タスクにリンクさせる動的リンカ手段とを含み、 前記ローダ手段が、ターゲット・プログラムを前記ター
   ゲット・タスクにロードして制御を前記動的リンカ手段
   に移し、 前記動的リンカ手段が、共用ライブラリ・オブジェクト
   をロードし、前記共用ライブラリ・オブジェクトを前記
   ターゲット・タスクにリンクさせ、制御をマスタ・サー
   バ・プログラム・ロード手段に移し、 前記マスタ・サーバ・プログラム・ロード手段が、制御
   を前記ターゲット・プログラムに移すことを特徴とする
   プログラム・ロード装置
2. 【請求項２】前記ターゲット・タスク内にあり、前記メ
   モリ内で前記共用ライブラリ・オブジェクトを再配置す
   るための再配置情報データをさらに含み、 前記動的リンカが、前記再配置情報にアクセスし、前記
   共用ライブラリ・オブジェクトにより再配置動作を実行
   することを特徴とする、請求項１に記載のプログラム・
   ロード装置。
3. 【請求項３】前記ローダ手段がさらに、 前記ローダ手段内にあり、ターゲット・プログラム・フ
   ァイルを開いて認識する手段と、 前記ローダ手段内にあり、前記ターゲット・タスク上に
   ターゲット・プログラム・ファイルのセグメントをマッ
   プする手段と、 前記ローダ手段内にあり、前記ターゲット・タスク用の
   ポートを初期設定する手段、および前記ローダ手段内に
   あり、前記ターゲット・タスク上で動的リンカを始動す
   る手段とを含むことを特徴とする、請求項１に記載のプ
   ログラム・ロード装置。
4. 【請求項４】前記動的リンカ手段が、さらに、 前記動的リンカ手段内にあり、再配置フラグをセットす
   る手段と、 前記動的リンカ手段内にあり、前記プログラム・ファイ
   ルがロード・ファイルかどうか判定する手段と、 前記動的リンカ手段内にあり、前記共用ライブラリ・オ
   ブジェクトの依存関係リストを作成する手段と、 前記動的リンカ手段内にあり、前記共用ライブラリ・オ
   ブジェクトをマップする手段と、 前記動的リンカ手段内にあり、前記共用ライブラリ・オ
   ブジェクトの再配置を実行する手段とを含むことを特徴
   とする、請求項３に記載のプログラム・ロード装置。
5. 【請求項５】前記マスタ・サーバ・プログラム・ロード
   手段内にあり、前記ターゲット・プログラムの実行時に
   前記共用ライブラリ・オブジェクトを前記ターゲット・
   タスクにロードする動的ローダ手段をさらに含む、請求
   項１に記載のプログラム・ロード装置。
6. 【請求項６】前記動的ローダ手段が、さらに、 前記ターゲット・タスク内にあり、前記メモリ内で前記
   共用ライブラリ・オブジェクトを再配置するための再配
   置情報データを含み、 前記動的ローダが、前記再配置情報データにアクセスし
   て前記共用ライブラリ・オブジェクトにより再配置操作
   を実行することを特徴とする、請求項５に記載のプログ
   ラム・ロード装置。
7. 【請求項７】前記動的ローダ手段が、さらに、 前記共用ライブラリ・オブジェクトを見つける手段と、 前記共用ライブラリ・オブジェクトを開いて読み取り、
   前記共用ライブラリ・オブジェクトがロード・ファイル
   かどうか判定する手段と、 前記共用ライブラリ・オブジェクトの依存関係リストを
   作成する手段と、 前記共用ライブラリ・オブジェクトの再配置を実行する
   手段と、 現依存関係リストを既存の依存関係リストの末尾に増補
   する手段と、 現依存関係リストのハンドルを戻す手段とを含むことを
   特徴とする、請求項５に記載のプログラム・ロード装
   置。
8. 【請求項８】メモリ手段とプロセッサ手段を含むデータ
   処理システムにおいて、 ローダ手段によりターゲット・プログラムをターゲット
   ・タスク内にロードし、制御を動的リンカ手段に移す段
   階と、 動的リンカ手段により共用ライブラリ・オブジェクトを
   ロードし、前記共用ライブラリ・オブジェクトを前記タ
   ーゲット・タスクにリンクし、制御をマスタ・サーバ・
   プログラム・ロード手段に移す段階とを含み、 前記マスタ・サーバ・プログラム・ロード手段が、制御
   を前記ターゲット・プログラムに移すことを特徴とする
   プログラム・ロード方法。
9. 【請求項９】前記メモリ内に前記共用ライブラリ・オブ
   ジェクトを再配置するための再配置情報データを前記タ
   ーゲット・タスク内に記憶する段階をさらに含み、 前記動的リンカが、前記再配置情報にアクセスして前記
   共用ライブラリ・オブジェクトにより再配置操作を実行
   することを特徴とする、請求項８に記載のプログラム・
   ロード方法。
10. 【請求項１０】前記ローダ手段が、 ターゲット・プログラム・ファイルを開いて認識する段
    階と、 前記ターゲット・タスク上にターゲット・プログラム・
    ファイルのセグメントをマップする段階と、 前記ターゲット・タスク用のポートを初期設定する段階
    と、 前記ターゲット・タスク上で前記動的リンカを始動する
    段階とを含む方法を実行することを特徴とする、請求項
    ８に記載のプログラム・ロード方法。
11. 【請求項１１】前記動的リンカ手段が、 再配置フラグをセットする段階と、 前記プログラム・ファイルがロード・ファイルかどうか
    判定する段階と、 前記共用ライブラリ・オブジェクトの依存関係リストを
    作成する段階と、 前記共用ライブラリ・オブジェクトをマップする段階
    と、 前記共用ライブラリ・オブジェクトの再配置を実行する
    段階とを含む方法を実行することを特徴とする、請求項
    １０に記載のプログラム・ロード方法。
12. 【請求項１２】前記ターゲット・プログラムの実行時
    に、動的ローダ手段により共用ライブラリ・オブジェク
    トを前記ターゲット・タスク内にロードする段階をさら
    に含むことを特徴とする、請求項８に記載のプログラム
    ・ロード方法。
13. 【請求項１３】前記動的ローダ手段が、 前記メモリ内で前記共用ライブラリ・オブジェクトを再
    配置する段階と、 前記再配置情報にアクセスして、前記共用ライブラリ・
    オブジェクトにより再配置操作を実行する段階とを含む
    方法を実行することを特徴とする、請求項１２に記載の
    プログラム・ロード方法。
14. 【請求項１４】前記動的ローダ手段が、 前記共用ライブラリ・オブジェクトを見つける段階と、 前記共用ライブラリを開いて読み取り、それがロード・
    ファイルであると判定する段階と、 前記共用ライブラリ・オブジェクトの依存関係リストを
    作成する段階と、 前記共用ライブラリ・オブジェクトの再配置を実行する
    段階と、 現依存関係リストを既存の依存関係リストの末尾に増補
    する段階と、 現依存関係リストのハンドルを戻す段階とを含む方法を
    実行することを特徴とする、請求項１２に記載のプログ
    ラム・ロード方法。