JPH09179728A - 異パーソナリティ・アプリケーションの起動方法およびコンピュータ・システム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】高速に異パーソナリティ・アプリケーション・
タスクを起動することができ、従来の単一パーソナリテ
ィ・オペレーティング・システム上で動作していたアプ
リケーションのバイナリ・ファイルをそのまま利用する
ことができ、さらに、異パーソナリティ・アプリケーシ
ョン・タスクの強制終了を複雑な処理を経ないで実行す
ることのできる、マルチ・パーソナリティ・シェルを実
現可能なインタフェースを提供する。 【解決手段】カーネルは、タスク制御ブロック４０６内
に割り込みベクタテーブルを保持し、タスクごとに異な
る割り込みベクタ・テーブルを持てるようにする。さら
に、カーネルはマウント表８００、パーソナリティ登録
表９００を保持し、起動したいアプリケーションのバイ
ナリ・ファイルのパス名の指定のみで、いかなるパーソ
ナリティのアプリケーションも起動可能にするインタフ
ェースを提供する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、異種のオペレーテ
ィング・システムに属するアプリケーションを同一イン
ターフェースにより高速に起動することのできる起動方
法およびそのような起動方法を実装したコンピュータ・
システムに関する。

【０００２】

【従来の技術】異種のオペレーティング・システムに属
するアプリケーションを同一インターフェースにより起
動するシェル・プログラムは、既存の各種オペレーティ
ング・システム上で開発されてきたアプリケーションの
すべてを利用可能なものにするため有用である。

【０００３】本明細書では、異種のオペレーティング・
システムに属するアプリケーションを同一インターフェ
ースにより起動可能にするタスク制御方式をマルチ・パ
ーソナリティ、マルチ・パーソナリティを実現している
システム上で動作する各アプリケーションが発するシス
テムコールの処理を行なうソフトウェアをパーソナリテ
ィと定義する。タスクが属するオペレーティング・シス
テムが異なれば、異なるパーソナリティが必要となる。
また、マルチ・パーソナリティを実現しているオペレー
ティング・システムをマルチ・パーソナリティ・オペレ
ーティング・システムと定義する。それに対し、従来の
オペレーティング・システムを単一パーソナリティ・オ
ペレーティング・システムと定義する。

【０００４】マルチ・パーソナリティを実現した典型的
な例として、Ｍａｃｈオペレーティング・システムによ
る実現例や、単一パーソナリティ・オペレーティング・
システム上に異なるオペレーティング・システムのエミ
ュレータを作動させる方式がある。以下では、まず始め
にＭａｃｈオペレーティング・システムによりマルチ・
パーソナリティを実現する方式について本「従来の技
術」の欄および次の「発明が解決しようとする課題」の
欄の前半で説明し、次に、単一パーソナリティ・オペレ
ーティング・システム上に異なるオペレーティング・シ
ステムのエミュレータを作動させる方式について「発明
が解決しようとする課題」の欄の後半で説明する。

【０００５】まず、Ｍａｃｈオペレーティング・システ
ム（特に、Ｍａｃｈマイクロ・カーネル）によりマルチ
・パーソナリティを実現する方式について説明する。こ
の方式では、以下のような、タスクごとにシステムコー
ル実行ルーチンを切り替えるｔａｓｋ＿ｓｅｔ＿ｅｍｕ
ｌａｔｉｏｎ＿ｖｅｃｔｏｒインタフェースを提供して
いる。

【０００６】task_set_emulation_vector(task,vector_
start,emulation_vector,emulation_vector_count)

【０００７】ｔａｓｋは、システムコール・エミュレー
ション・ルーチンのエントリポイントを設定するタスク
を指定する引数である。ｖｅｃｔｏｒ＿ｓｔａｒｔおよ
びｅｍｕｌａｔｉｏｎ＿ｖｅｃｔｏｒ＿ｃｏｕｎｔは、
エントリポイントを設定するシステムコール番号の先頭
およびその数を指定する引数である。ｅｍｕｌａｔｉｏ
ｎ＿ｖｅｃｔｏｒは、エントリ・ポイントの列を指定す
る引数である。なお、システムコール・エミュレーショ
ン・ルーチン（以下、単にエミュレーション・ルーチン
という）とは、実行したいシステムコール処理を、Ｍａ
ｃｈマイクロ・カーネルを用いてエミュレートするソフ
トウェアのことを言う。

【０００８】図１は、Ｍａｃｈマイクロ・カーネルを用
いたマルチ・パーソナリティ・システムのソフトウェア
構成の概要を示す。Ｍａｃｈマイクロ・カーネル（Mach
Micro Kernel）１０１上に、Ｍａｃｈマイクロ・カー
ネル１０１が管理するタスクとしてＯＳサーバ・タスク
（１０２，１０３）とアプリケーション・タスク（シェ
ル１０４、アプリケーション１０５）が配されている。
ＯＳサーバ・タスクは、各アプリケーション・タスクか
ら要求されるシステム・コールの処理を行なうタスクで
ある。図１では、シェル１０４はＯＳサーバ１（１０
２）に属し、アプリケーション１０５はＯＳサーバ２
（１０３）に属している。

【０００９】ＯＳサーバは、自パーソナリティに属する
タスク生成時に、上述の関数ｔａｓｋ＿ｓｅｔ＿ｅｍｕ
ｌａｔｉｏｎ＿ｖｅｃｔｏｒをコールする。例えば、Ｏ
Ｓサーバ１（１０２）はシェル１０４のタスク生成時に
この関数をコールし、ＯＳサーバ２（１０３）アプリケ
ーション１０５のタスク生成時にこの関数をコールす
る。これにより、生成されたタスクからＯＳサーバに対
するシステムコールを実行することが可能となる。

【００１０】実際に、アプリケーション・タスクがシス
テムコール実行を行なうためには、決められたレジスタ
にシステムコール番号を格納して、決められた割り込み
番号を引数として、トラップ命令を発行するのみでよい
（１１１，１１２）。

【００１１】トラップ命令とは、ＣＰＵ（中央処理装
置）に対して割り込み処理要求を割り込み番号とともに
通知するＣＰＵ命令である。ＣＰＵは、割り込み処理要
求信号を受け取ると、割り込みテーブルに定義されてい
る割り込みハンドラのエントリ・アドレスへのジャン
プ、およびプログラム状態語の変更を行なう。旧プログ
ラム・カウンタと旧プログラム状態語はスタックに保持
しておく。割り込みハンドラの実行が終了すると、スタ
ックに保持されていたプログラム・カウンタとプログラ
ム状態語がレジスタに回復され、割り込まれていた次の
命令から実行を継続する。

【００１２】図１の１１１，１１２のようにトラップ命
令が発行されると、Ｍａｃｈマイクロ・カーネルが定義
した割り込みハンドラに制御が移る。この割り込みハン
ドラでは、ｔａｓｋ＿ｓｅｔ＿ｅｍｕｌａｔｉｏｎ＿ｖ
ｅｃｔｏｒインターフェースによって予め登録されてい
た、エミュレーション・ルーチンのエントリ・ポイント
へのリダイレクションを行なう。このリダイレクション
は、スタックに保持してある旧プログラム・カウンタの
値を、エミュレーション・ルーチンのエントリ・ポイン
トに変更することによって実現する。このエミュレーシ
ョン・ルーチンのエントリ・ポイントがタスクごとに変
更可能であるために、タスクごとに異なるシステムコー
ル実行ルーチンを実現することが可能になる。

【００１３】エミュレーション・ルーチンでは、予め定
められたＯＳサーバ・タスクに対してリモート・プロシ
ージャ・コール（１１３や１１４）を行なうことによっ
てシステムコール処理を要求する。リモート・プロシー
ジャ・コールを受け取ったＯＳサーバ・タスクは、実際
のシステムコール処理を行なう。

【００１４】このように、システムコール処理部分をユ
ーザ空間に配置し、各システムコール処理部分がカーネ
ル空間での実行を必要とする機能のみを提供するＭａｃ
ｈのようなカーネルをマイクロ・カーネルと呼ぶ。一
方、従来のように、システムコール処理部分をカーネル
空間に配置してあるカーネルをインテグレーテッド（ｉ
ｎｔｅｇｒａｔｅｄ）・カーネルと呼ぶ。

【００１５】

【発明が解決しようとする課題】図１のようにＭａｃｈ
マイクロ・カーネルを用いてマルチ・パーソナリティを
実現している場合に、あるＯＳサーバを用いて稼動して
いるシェルから、異パーソナリティ・アプリケーション
を起動する場合の処理の流れを、図２に示す。

【００１６】以下、図２に沿って説明する。なお、図２
中の（１）から（７）は、以下のステップ（１）からス
テップ（７）に対応している。

【００１７】ステップ（１）：シェル・タスクが、異パ
ーソナリティ・タスク起動のシステムコールの実行のた
めに、トラップ命令を発行する。 ステップ（２）：Ｍａｃｈマイクロ・カーネルは、エミ
ュレーション・ライブラリへリダイレクションを行な
う。 ステップ（３）：エミュレーション・ライブラリは、シ
ステムコールごとに処理要求メッセージ送信先のＯＳサ
ーバ・タスクを定義しているテーブルを持つ。そのテー
ブルに沿って、当該システムコールに対応するＯＳサー
バ・タスクに対して、アプリケーション・タスク起動を
要求するメッセージを送信する。 ステップ（４）：ＯＳサーバはメッセージを受信するた
めに、予めトラップを発行した後に休眠している。 ステップ（５）：ＯＳサーバはメッセージが到達すると
起床し、トラップからリターンして、アプリケーション
起動のための処理を開始する。 ステップ（６）：ＯＳサーバは、上記処理内で、Ｍａｃ
ｈマイクロ・カーネルに対して、Ｍａｃｈタスクの生成
および起動関数の実行を要求する。 ステップ（７）：Ｍａｃｈマイクロ・カーネルは、指定
アプリケーション用タスクを生成および起動する。

【００１８】ところが、この方式によると、以下の２点
（Ａ１）および（Ａ２）が問題となる。

【００１９】（Ａ１）図２に示す通り、シェル・タスク
から異アプリケーション・タスクを実行するためには、
２回のタスク間通信（図２でＩＰＣと記載してある位置
で行われる）と、７回のコンテクスト・スイッチ（図２
におけるステップ（１）〜（７）の各ステップにつき１
回づつコンテクスト・スイッチが発生している）を要
し、高速に実行を行なうことができない。

【００２０】（Ａ２）アプリケーション・タスクがＯＳ
サーバ・タスクに対してシステムコール処理を要求する
場合も、上記ステップ（１）から（５）までの処理を経
て、ＯＳサーバ・タスクが起動される。このときの、ス
テップ（１）におけるトラップのトラップ番号は、予め
Ｍａｃｈマイクロ・カーネルによって定義されている番
号を用いる必要がある。そのために、従来のインテグレ
ーテッド・カーネル上で実行していたアプリケーション
のバイナリ・ファイルをそのまま用いることができな
い。

【００２１】このように、Ｍａｃｈマイクロ・カーネル
のｔａｓｋ＿ｓｅｔ＿ｅｍｕｌａｔｉｏｎ＿ｖｅｃｔｏ
ｒインタフェースを用いて異パーソナリティ・アプリケ
ーションを起動しようとすると、タスク間通信やコンテ
クスト・スイッチが多発して高速に実行を行なうことが
できないという問題があった。

【００２２】一方、タスク間通信やコンテクスト・スイ
ッチの多発を防いで、異アプリケーションの高速起動を
可能にする別の方式として、単一パーソナリティ・オペ
レーティング・システム（パーソナリティＡとする）上
に、異なるオペレーティング・システム（パーソナリテ
ィＢとする）のエミュレータを作動させる方式（以下、
エミュレーション方式と呼ぶ）がある。

【００２３】図３は、エミュレーション方式の処理手順
を示す。図３に沿って、パーソナリティＡ上のシェルか
らパーソナリティＢのアプリケーションを起動させる場
合について説明する。なお、図３中の（１）から（４）
は、以下のステップ（１）からステップ（４）に対応し
ている。

【００２４】ステップ（１）：パーソナリティＡのシェ
ル・タスクは、ｌａｕｎｃｈシステムコールを発する。 ステップ（２）：パーソナリティＡに属するカーネル
は、エミュレータに付随しているメッセージキューに、
指定アプリケーション起動要求メッセージをエンキュー
する。 ステップ（３）：トラップからリターンし、エミュレー
タが実行を開始する。 ステップ（４）：エミュレータは、単一パーソナリティ
・カーネルの場合と同様な手順を用いてアプリケーショ
ンを起動する。

【００２５】しかし、このエミュレーション方式におい
ても以下の課題（Ｂ１）〜（Ｂ３）が残っている。

【００２６】（Ｂ１）異パーソナリティに属するアプリ
ケーション（図３のパーソナリティＢのアプリケーショ
ン）の起動のためには、通常の単一パーソナリティ・カ
ーネルにおけるタスク起動手順に加えて、パーソナリテ
ィＡのカーネルに対するシステムコールを１回実行する
必要がある。しかも、通常のタスク起動手順を行なう部
分はエミュレータを通じて実行されるので、通常の単一
パーソナリティ・カーネルにおけるタスク起動に比べて
かなりの実行時間を要することになる。

【００２７】（Ｂ２）エミュレータ上で動作しているパ
ーソナリティＢのアプリケーションはパーソナリティＡ
のタスク起動システムコールを用いて起動されたもので
はないため、パーソナリティＡのカーネルからはタスク
として認識されない。そのため、シェルのコマンド・ラ
インから、パーソナリティＢのアプリケーションを強制
終了させたい場合、その強制終了処理を容易な手順で行
なうことができない。

【００２８】（Ｂ３）上述（Ａ２）と同様な問題が生じ
る。すなわち、エミュレーション方式においては、パー
ソナリティＡのシステムコールで用いるトラップ番号
は、パーソナリティＢで用いるトラップ番号と重なり合
わないように確保してある。そのため、今まで単一パー
ソナリティ・カーネル上で動作していたアプリケーショ
ンのバイナリ・ファイルを、そのままエミュレーション
方式で動作する保証ができないという問題が生じる。

【００２９】本発明は、従来のＭａｃｈやエミュレーシ
ョン方式で生じている上記の問題を解決することのでき
るインタフェースを提供することを目的とする。すなわ
ち、本発明は、高速に異パーソナリティ・アプリケーシ
ョン・タスクを起動することができ、従来の単一パーソ
ナリティ・オペレーティング・システム上で動作してい
たアプリケーションのバイナリ・ファイルをそのまま利
用することができ、さらに、異パーソナリティ・アプリ
ケーション・タスクの強制終了を複雑な処理を経ないで
実行することのできる、マルチ・パーソナリティ・シェ
ルを実現可能なインタフェースを提供することを目的と
する。

【００３０】

【課題を解決するための手段】本発明は上記の課題を解
決するため、各アプリケーション・タスクの割り込みベ
クタ・テーブルをパーソナリティごとに差し替えるよう
にすることにより、高速な異パーソナリティ・アプリケ
ーション起動を可能にするインタフェースを提供する。

【００３１】すなわち、本発明に係る異パーソナリティ
・アプリケーションの起動方法は、異種のオペレーティ
ング・システム上で動作するアプリケーションである異
パーソナリティ・アプリケーションを起動する起動方法
であって、異種のオペレーティング・システム用のファ
イル・システムのマウント情報を、カーネル内に予め登
録するステップと、異種のオペレーティング・システム
上で動作するタスクを起動するにあたって必要となる該
オペレーティング・システムに依存するパーソナリティ
依存情報を、カーネル内に予め登録するステップと、異
種のオペレーティング・システム上で動作するアプリケ
ーションのバイナリ・ファイルのパス名が指定されたと
き、上記マウント情報とパーソナリティ依存情報を用い
て、該アプリケーションのバイナリ・ファイルのディス
ク上の存在位置と、該アプリケーションの属するパーソ
ナリティを特定し、バイナリ・ファイルの内容をファイ
ル・システムから読み込み、主メモリにロードし、かつ
初期環境を与えて該アプリケーションを起動させるステ
ップとを備えたことを特徴とする。

【００３２】また、本発明に係るコンピュータ・システ
ムは、異種のオペレーティング・システム上で動作する
アプリケーションである異パーソナリティ・アプリケー
ションを起動するインターフェースを有するコンピュー
タ・システムであって、異種のオペレーティング・シス
テム用のファイル・システムのマウント情報を、カーネ
ル内に予め登録するインターフェースと、上記登録され
たマウント情報を削除するインターフェースと、異種の
オペレーティング・システム上で動作するタスクを起動
するにあたって必要となる該オペレーティング・システ
ムに依存するパーソナリティ依存情報を、カーネル内に
予め登録するインターフェースと、上記登録されたパー
ソナリティ依存情報を削除するインターフェースと、異
種のオペレーティング・システム上で動作するアプリケ
ーションのバイナリ・ファイルのパス名が指定されたと
き、上記マウント情報とパーソナリティ依存情報を用い
て、該アプリケーションのバイナリ・ファイルのディス
ク上の存在位置と、該アプリケーションの属するパーソ
ナリティを特定し、バイナリ・ファイルの内容をファイ
ル・システムから読み込み、主メモリにロードし、かつ
初期環境を与えて該アプリケーションを起動させるイン
ターフェースとを備えたことを特徴とする。

【００３３】具体的にパーソナリティ依存情報は、当該
パーソナリティに特有の、パーソナリティ名、バイナリ
・ファイルのロード・ルーチン、タスクの初期化ルーチ
ン、割り込みベクタ・テーブル、およびサーバ関数エン
トリ・ポイントを特定する情報である。

【００３４】異種のオペレーティング・システム用のフ
ァイル・システムのマウント情報をカーネル内に予め登
録することによって、カーネルから異パーソナリティ・
アプリケーションのファイル・システムをアクセスする
ことが可能になる。そのため、起動すべき異パーソナリ
ティ・アプリケーションを、そのアプリケーションのバ
イナリ・ファイルのパス名によって指定することが可能
になる。

【００３５】また、異種のオペレーティング・システム
上で動作するタスクを起動するにあたって必要となる該
オペレーティング・システムに依存するパーソナリティ
依存情報をカーネル内に予め登録することによって、ユ
ーザはパーソナリティ名を指定するのみで、任意のパー
ソナリティに属するアプリケーションの起動を同一イン
タフェースで行なうことが可能になる。

【００３６】さらに、異種のオペレーティング・システ
ム上で動作するアプリケーションのバイナリ・ファイル
のパス名が指定されたとき、カーネルにより、上記マウ
ント情報とパーソナリティ依存情報を用いて、該アプリ
ケーションのバイナリ・ファイルのディスク上の存在位
置と、該アプリケーションの属するパーソナリティを特
定し、バイナリ・ファイルの内容をファイル・システム
から読み込み、主メモリにロードし、かつ初期環境を与
えて該アプリケーションを起動させるようにしているの
で、１回のシステムコールの実行のみで、異パーソナリ
ティ・アプリケーションのロード、および起動が可能に
なる。従来の方式に比べて実行性能が向上する。

【００３７】

【発明の実施の形態】以下、図４から図１５を用いて、
この発明の実施の形態を説明する。始めに、本発明を適
用して、マルチ・パーソナリティを実現し、異パーソナ
リティ・アプリケーションを同一インターフェースで
（すなわち、異なるパーソナリティのアプリケーション
であっても同一のインターフェースで）起動可能なシェ
ル（マルチ・パーソナリティ・シェル）を実現する本発
明の実施の形態例について説明する。さらに、この形態
例におけるインターフェースを用いて、ｄｆ（ｄｉｓｋ
ｆｒｅｅ）コマンドを拡張する応用例、および＾Ｃ入力
に対する処理を拡張する応用例について説明する。

【００３８】図４に、本発明の形態例のソフトウェア構
成を示す。図１５に、図４のソフトウェア構成が実装さ
れる本形態例のコンピュータ・システムのハードウェア
構成を示す。

【００３９】本形態例が前提とするコンピュータ・シス
テムは、現在実用化されている多くのコンピュータ・シ
ステムと同様のものでよい。すなわち、図１５に示すよ
うに、ＣＰＵ１５０１、主メモリ１５０２、ディスク・
コントローラ１５０３、およびディスク１５０４などを
備えたシステムであればよい。ＣＰＵ１５０１は、割り
込み処理機構（トラップ命令も含む）を備えている。ま
た、ＣＰＵ１５０１は、論理アドレスから物理アドレス
への変換とセグメントごとのメモリ保護とを実現するセ
グメント機構（図５で詳述する）を備えている。

【００４０】図４を参照して、本形態例におけるソフト
ウェア構成を説明する。本形態例におけるソフトウェア
は、アプリケーション（４０１）、複数のサーバ・プロ
グラム（４０２）、およびマイクロ・カーネル（４０
３）の３階層からなる。サーバ・プログラム（４０２）
は、前述のＯＳサーバ・タスクと役割は同等であるが、
別タスクとして実現する訳ではないので、このように呼
ぶこととする。また、サーバ・プログラム（４０２）と
マイクロ・カーネル（４０３）とを併せて、アプリケー
ションから要求されるシステムコールの実行を行なう１
つのパーソナリティを形成する。

【００４１】アプリケーション（４０１）は複数存在し
うる。アプリケーション（４０１）は、サーバ・プログ
ラム（４０２）（またはマイクロ・カーネル（４０
３））に対してシステムコールを発するが、マイクロ・
カーネル（４０３）がタスク制御ブロック（４０６）内
にタスクごとの割り込みベクタ・テーブル（４１１）の
ベース・アドレス（ＩＤＴＲ４０７）を定義することに
より、同じＣＰＵ命令を発しても、アプリケーション
（４０１）ごとにシステムコールの処理内容を変えるこ
とを可能にしている。また、このアプリケーション（４
０１）の一つに、マルチ・パーソナリティ・アプリケー
ションを起動できるシェルがある。このシェルの構成に
ついては、後に詳述する。

【００４２】サーバ・プログラム（４０２）は、当該サ
ーバ・プログラム（４０２）が管理するタスクに関する
タスク制御ブロック（４０４）を保持する。これらのタ
スク制御ブロック（４０４）は、マイクロ・カーネル
（４０３）が保持するタスク制御ブロック（４０６）へ
のポインタと、当該サーバ・プログラム（４０２）が個
別に管理するタスク制御ブロック・フィールド（４０
５）とから構成されている。

【００４３】マイクロ・カーネル（４０３）は、各種の
テーブルを保持する。図４では、本発明と関係の深いパ
ーソナリティ登録表（９００）、マウント表（８０
０）、およびタスク制御ブロック（４０６）のみを描い
ている。タスク制御ブロック（４０６）は、パーソナリ
ティ名（４１４）、割り込みベクタ・テーブル・ベース
・アドレス（４０７）、サーバ・プログラムが存在する
セグメントのセグメント・ディスクリプタ（４０８）、
サーバ関数エントリ・ポイント・テーブル（４１２）の
ベース・アドレス（４０９）、および局所セグメント・
テーブル（４１３）のベース・アドレス（４１０）を保
持する。

【００４４】セグメント・テーブルとは、以下で述べる
セグメント機構を実現するために必要となるテーブルで
ある。本形態例では、ＣＰＵがこのセグメント機構を提
供することを前提としている。セグメント機構は、論理
アドレスから物理アドレスへの変換と、セグメントごと
のメモリ保護を実現する。図５に、セグメント機構にお
ける論理アドレスから物理アドレスへの変換方式を示
す。

【００４５】図５において、論理アドレス（５０１）
は、セグメント番号（５０３）とオフセット（５０４）
に分割される。セグメント・テーブル・ベース・レジス
タ（５０５）とセグメント番号（５０３）との和の主メ
モリ番地に、そのセグメントに関する情報（セグメント
・テーブル（４１３）内）が格納されている。この情報
をセグメント・ディスクリプタ（５０６）と呼ぶ。論理
アドレス（５０１）のオフセット（５０４）とセグメン
ト・ディスクリプタ（５０６）内に格納されているベー
ス・アドレス（５０７）の和が求める物理アドレス（５
０２）となる。

【００４６】また、セグメントにおけるメモリ保護に
は、セグメント・ディスクリプタ（５０６）の保護レベ
ル情報Ｌ（５０９）を用いる。現在実行中のプログラム
が属するセグメントの保護レベルより保護レベルが高い
セグメントへのジャンプや読み書きを禁止することによ
ってメモリ保護を実現する。

【００４７】また、論理アドレス（５０１）から物理ア
ドレス（５０２）への変換時に、論理アドレスのオフセ
ット（５０４）がセグメント・ディスクリプタ（５０
６）に格納されているサイズ（５０８）より大きいか否
かを判別し、大きかったらエラーを返すことによって、
セグメント（５１０）外への不法なアクセスを防いでい
る。

【００４８】本形態例では、アプリケーション（４０
１）、サーバ・プログラム（４０２）、マイクロ・カー
ネル（４０３）が、それぞれ別セグメントに配置され、
かつ保護レベルも上記順序で高くなるように設定されて
いるものとする。従って、アプリケーションからサーバ
・プログラムやマイクロ・カーネルにコールする場合に
はトラップを、マイクロ・カーネルからサーバ・プログ
ラムをコールする場合にはサブ・ルーチン・コールを用
いる。

【００４９】図６に、本形態例における空間の配置方法
を示す。セグメント・テーブルには、全タスクで共通に
使用される大域セグメント・テーブル（６０１）と各タ
スクごとに個別に使用される局所セグメント・テーブル
（４１３）があるものとする。

【００５０】マイクロ・カーネル（４０３）空間は、大
域セグメント・テーブル（６０１）を用いて物理空間に
マップされる。すなわち、マイクロ・カーネル（４０
３）空間は、すべてのアプリケーション（４０１）やサ
ーバ・プログラム（４０２）からトラップを用いてアク
セス可能になる。サーバ・プログラム（４０２）空間
は、局所セグメント・テーブル（４１３）の予め定めら
れたエントリを用いて物理空間にマップされる。この定
められたエントリに、マイクロ・カーネル（４０３）が
所持するタスク制御ブロック（４０６）内のサーバ・プ
ログラム・セグメント・ディスクリプタ・フィールド
（４０８）の内容をコピーすることによって、アプリケ
ーション（４０１）ごとにトラップを用いてアクセス可
能なサーバ・プログラム（４０２）を切り替える。ま
た、アプリケーション（４０１）は、局所セグメント・
テーブル（４１３）を用いて物理空間にマップする。従
って、１つのアプリケーション（４０１）から他のアプ
リケーション（４０１）へのアクセスを行なうことはで
きない。

【００５１】次に、本形態例で用いるマルチ・パーソナ
リティ・アプリケーションが起動可能なシェルの構成に
ついて述べる。

【００５２】本シェルは、図７のプログラムによって実
現される。図７のプログラムにおいて、左側の００１〜
００９の数字は行番号を示す。１行目、２行目、３行
目、４行目、および８行目の文は、本発明に係る固有な
関数を含んでいる。

【００５３】＜パーソナリティの初期化＞の部分では、
各パーソナリティの初期化を行なう段階で実行する必要
のあるコードのうち、本発明と関係の深い部分のみを示
している。１行目の文は、パーソナリティのファイル・
システムをマイクロ・カーネルからアクセス可能にする
べくマウント表（８００）（エントリの内容は後述）へ
ファイル・システムの登録を行なう関数ｄｆ＿ｐｅｒｓ
ｏｎａｌｉｔｙ＿ｍｏｕｎｔの呼び出しである。２行目
の文は、パーソナリティ登録表（９００）（エントリの
内容は後述）に必要なパーソナリティ情報を登録する関
数ｐｅｒｓｏｎａｌｉｔｙ＿ｒｅｇｉｓｔｅｒの呼び出
しである。

【００５４】＜パーソナリティの終了＞の部分では、各
パーソナリティの終了処理を行なう段階で実行する必要
のあるコードのうち、本発明と関係の深い部分のみを示
している。３行目目の文は、パーソナリティのファイル
・システムをマイクロ・カーネルからアクセス不可能に
するべくマウント表（８００）からファイル・システム
の削除を行なう関数ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｕ
ｍｏｕｎｔの呼び出しである。４行目の文は、パーソナ
リティ登録表（９００）から、終了するパーソナリティ
に関する情報を削除する関数ｐｅｒｓｏｎａｌｉｔｙ＿
ｆｒｅｅ関数の呼び出しである。

【００５５】＜マルチパーソナリティシェル＞の部分で
は、複数のパーソナリティ上で動作するアプリケーショ
ンを同様なコマンド入力によって起動可能にするシェル
のメインループの部分を示している。５行目の文は、コ
マンド・プロンプトの出力を行なう。６行目の文は、入
力されるコマンドを読み込んでいる。７行目は、入力さ
れたコマンドをコマンド引数に分解し、コマンド引数の
文字列の配列ａｒｇｖ，と引数の数ａｒｇｃを返す関数
ｇｅｔ＿ａｒｇｕｍｅｎｔを呼び出している。８行目の
文は、ａｒｇｖ［０］で示されるアプリケーションを自
らの子タスクとして起動する関数ｄｆ＿ｐｅｒｓｏｎａ
ｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅの呼び出しである。
９行目の文は、子タスクの実行終了を待つ。

【００５６】以下、図７のプログラムに登場する本形態
例に固有の関数群、ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｍ
ｏｕｎｔ関数、ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｕｍｏ
ｕｎｔ関数、ｐｅｒｓｏｎａｌｉｔｙ＿ｒｅｇｉｓｔｅ
ｒ関数、ｐｅｒｓｏｎａｌｉｔｙ＿ｆｒｅｅ関数、ｄｆ
＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関
数の外部仕様（アプリケーション・プログラム・インタ
フェース）とその内部処理フロー、およびこれと関連す
るデータ構造について説明する。

【００５７】まず、ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｍ
ｏｕｎｔ関数について説明する。ｄｆ＿ｐｅｒｓｏｎａ
ｌｉｔｙ＿ｍｏｕｎｔ関数は、下記の外部仕様を提供す
る。 記述形式：df_personality_mount(partition,pty_name,
mount_dir,root_inf) 機能：マウント表（８００）に、ｐａｒｔｉｔｉｏｎで
示されたパーティション名、ｐｔｙ＿ｎａｍｅで示され
たパーソナリティ名、ｍｏｕｎｔ＿ｄｉｒで示されたマ
ウント・ディレクトリの登録を行なう。 引数： ｐａｒｔｉｔｉｏｎ：パーティション名 ｐｔｙ＿ｎａｍｅ：パーソナリティ名 ｍｏｕｎｔ＿ｄｉｒ：マウント・ディレクトリ ｒｏｏｔ＿ｉｎｆ：ルート情報 リターン値：マウントに成功した場合にはＥ＿ＯＫを、
そうでなければエラーコード（負の整数値）をリターン
する。

【００５８】ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｍｏｕｎ
ｔ関数は、図８に示されるマウント表（８００）の各フ
ィールドの登録を行なう。マウント表（８００）は以下
の各フィールドで構成される。 パーティション名（８０１）：ファイル・システムを含
むパーティション名を示す。 マウント・ディレクトリ（８０２）：シェル・タスクが
動作しているパーソナリティのファイル・システムにお
ける、各ファイル・システムのマウント・ディレクトリ
を示す。シェル・タスクが動作しているパーソナリティ
名のパス名の指定方法に基づいた表記法を用いて指定す
る。 パーソナリティ名（８０３）：当該パーティションに格
納されているファイル・システムのパーソナリティ名を
示す。 ルート情報（８０４）：ファイル・システムのルートに
関する情報を格納する。このフィールドに格納される情
報はファイル・システムに依存する。例えば、ＵＮＩＸ
ファイル・システムの場合には、ルート・ディレクトリ
のｉノード番号が入る。ＭＳ−ＤＯＳファイル・システ
ムの場合は、パーティションの先頭ブロック内の固定さ
れたオフセットにルートのＦＡＴ情報が格納されている
ため、このフィールドは使用されない。

【００５９】次に、ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｕ
ｍｏｕｎｔ関数について説明する。ｄｆ＿ｐｅｒｓｏｎ
ａｌｉｔｙ＿ｕｍｏｕｎｔ関数は、下記の外部仕様を提
供する。 記述形式：df_personality_umount(pty_name) 機能：マウント表（８００）から、ｐｔｙ＿ｎａｍｅで
指定されるパーソナリティに関するマウント情報を削除
する。 引数：ｐｔｙ＿ｎａｍｅ：マウント表（８００）からマ
ウント情報を削除したいパーソナリティ名。 リターン値：マウント情報の削除成功の場合にはＥ＿Ｏ
Ｋを、そうでなければエラーコード（負の整数値）をリ
ターンする。

【００６０】次に、ｐｅｒｓｏｎａｌｉｔｙ＿ｒｅｇｉ
ｓｔｅｒ関数について説明する。ｐｅｒｓｏｎａｌｉｔ
ｙ＿ｒｅｇｉｓｔｅｒ関数は、下記の外部仕様を提供す
る。 記述形式：personality_register(pty_name,load_routi
ne,setup_routine,trap_vector,server_segment,server
_function_routine) 機能：パーソナリティ登録表（９００）に、ｐｔｙ＿ｎ
ａｍｅで指定されたパーソナリティ名、ｌｏａｄ＿ｒｏ
ｕｔｉｎｅで指定されたバイナリ・ファイルの主メモリ
へのロード・ルーチン、ｓｅｔｕｐ＿ｒｏｕｔｉｎｅで
指定されたタスク制御ブロックの個別フィールド部の初
期化ルーチン、ｔｒａｐ＿ｖｅｃｔｏｒで指定された割
り込みベクタ・テーブル・ベース・アドレス、ｓｅｒｖ
ｅｒ＿ｓｅｇｍｅｎｔで指定されたサーバ・プログラム
の配置されているセグメント番号に対応するセグメント
・ディスクリプタ、ｓｅｒｖｅｒ＿ｆｕｎｃｔｉｏｎ＿
ｒｏｕｔｉｎｅで指定されたサーバ関数ルーチン・エン
トリ・ポイント・テーブル・ベース・アドレスを登録す
る。 引数： ｐｔｙ＿ｎａｍｅ：パーソナリティ名 ｌｏａｄ＿ｒｏｕｔｉｎｅ：バイナリ・ファイルのロー
ド・ルーチン ｓｅｔｕｐ＿ｒｏｕｔｉｎｅ：タスク制御ブロックの個
別フィールドの初期化ルーチン ｔｒａｐ＿ｖｅｃｔｏｒ：割り込みベクタ・テーブル リターン値：登録成功の場合にはＥ＿ＯＫ（０）を、そ
うでなければエラーコード（負の整数値）をリターンす
る。

【００６１】ｐｅｒｓｏｎａｌｉｔｙ＿ｒｅｇｉｓｔｅ
ｒ関数は、図９に示されるパーソナリティ登録表（９０
０）の各フィールドの登録を行なう。パーソナリティ登
録表（９００）は、以下の各フィールドで構成する。 パーソナリティ名（９０１）：パーソナリティ名を登録
する。マウント表（８００）に登録されるパーソナリテ
ィ名（８０３）と同じ名前になるようにする。 ロード・ルーチン（９０２）：パーソナリティごとに異
なるロード・ルーチンのエントリポイントを登録する。
ロード・ルーチンとは、パス名、コマンド・ライン引
数、およびマウント表のエントリへのポインタを関数の
引数としてとり、パス名で指定されたバイナリ・ファイ
ルの主メモリへのロードおよびコマンド・ライン引数に
応じたスタック状態の設定を行なうルーチンである。ま
た、戻り値として、指定アプリケーションの属するパー
ソナリティ名を返す。 セット・アップ・ルーチン（９０３）：パーソナリティ
ごとに異なるセット・アップ・ルーチンのエントリポイ
ントを登録する。セット・アップ・ルーチンとは、サー
バ・プログラムの管理するタスク制御ブロック（４０
４）の初期化を行なうルーチンである。

【００６２】割り込みベクタ・テーブル（９０４）：パ
ーソナリティごとに異なる割り込みベクタ・テーブル・
ベース・アドレス（割り込みベクタ・テーブルへのポイ
ンタ）を登録する。このフィールドをパーソナリティご
とに設けてあるので、アプリケーションは、当該アプリ
ケーションが属するパーソナリティごとに異なるシステ
ムコールを、同じＣＰＵ命令を用いて、実行することが
できる。なお、本形態例で提供している関数を実行する
ための割り込みベクタなどは、各パーソナリティで共通
にとっておく必要がある。全体としての割り込み番号の
割り振りは、図１０で示すようにする。すなわち、各パ
ーソナリティで共通の割り込み番号として、マイクロ・
カーネル用システムコール実行用割り込みベクタおよび
外部割り込みベクタに割り振りをしておき、さらにパー
ソナリティごとに異なるシステムコールを実行すること
ができるように、サーバ・プログラムごとにサーバ・プ
ログラム用システムコール実行用割り込みベクタ・テー
ブルを用意しておく。

【００６３】サーバ・プログラムのセグメント情報（９
０５）：サーバ・プログラムの属するセグメントのセグ
メント・ディスクリプタが格納されている。引数で与え
られたサーバ・プログラムが属するセグメント番号を対
応するセグメント・ディスクリプタに変換して格納す
る。 サーバ関数エントリポイント：マイクロ・カーネルから
サーバ・プログラムに対して通知したいイベントが発生
した場合にコールする関数のエントリ・ポイントの配列
のベースを格納する。マイクロ・カーネルがＵＮＩＸサ
ーバ・プログラムがシグナル処理を行なうために、割り
込みの発生をマイクロ・カーネルからＵＮＩＸサーバ・
プログラムに通知したい場合などに用いられる。

【００６４】次に、ｐｅｒｓｏｎａｌｉｔｙ＿ｆｒｅｅ
関数について説明する。ｐｅｒｓｏｎａｌｉｔｙ＿ｆｒ
ｅｅ関数は、下記の外部仕様を提供する。 記述形式：personality_free(pty_name) 機能：パーソナリティ登録表（９００）から、ｐｔｙ＿
ｎａｍｅで指定されたパーソナリティ名に関するエント
リを削除する。 引数：ｐｔｙ＿ｎａｍｅ：パーソナリティ登録表（９０
０）から削除したいエントリのパーソナリティ名 リターン値：削除に成功した場合にはＥ＿ＯＫ（０）
を、そうでない場合にはエラーコード（負の整数値）を
リターンする。

【００６５】次に、ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔ
ｓｋ＿ｅｘｅｃｕｔｅ関数について説明する。ｄｆ＿ｐ
ｅｒｓｏｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関数
は、下記の外部仕様を提供する。 記述形式：df_personality_tsk_execute(file,argv,arg
c,init_envp) 機能：ｆｉｌｅ名で示されたバイナリ・ファイルを、ａ
ｒｇｖ，ａｒｇｃで与えられた引数を持ち、ｉｎｉｔ＿
ｅｎｖｐで与えられた初期環境の下で、子タスクとして
実行を開始する。 引数： ｆｉｌｅ：バイナリ・ファイルのパス名 ａｒｇｖ：コマンド引数の文字列の配列 ａｒｇｃ：コマンド引数の数 ｉｎｉｔ＿ｅｎｖｐ：初期環境へのポインタ リターン値：子タスクのタスクＩＤを関数値（正の整数
値）としてリターンする。ただし、子タスクの生成に失
敗した場合には、エラーコード（負の整数値）をリター
ンする。

【００６６】ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔｓｋ＿
ｅｘｅｃｕｔｅ関数は、指定されたバイナリ・ファイル
を主メモリ（１５０２）上にロードし、それを呼び出し
たタスクの子タスクとして実行を開始させる。

【００６７】図１１に、ｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ
＿ｔｓｋ＿ｅｘｅｃｕｔｅ関数の処理フローを示す。ｄ
ｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ
関数が呼び出されると、まずマイクロ・カーネルは、処
理ステップ１１０２において、新しく生成される子タス
ク用の空きタスク制御ブロック（４０６）を確保する。
次に、処理ステップ１１０３において、新しく生成され
るタスクのセグメント・テーブル（４１３）領域などを
主メモリ上に確保する。処理ステップ１１０４では、指
定されたバイナリ・ファイルの内容を主メモリにロード
する。このロード処理に関しては、後に詳述する。この
ロード処理は、リターン値として、主メモリに展開した
バイナリ・ファイルのパーソナリティ名を返す。

【００６８】処理ステップ１１０５では、マイクロ・カ
ーネルが管理するタスク制御ブロック（４０６）（ステ
ップ１１０２で確保）を初期化する。具体的には、タス
ク制御ブロック（４０６）のパーソナリティ名（４１
４）に、ステップ１１０４のロード処理から返されたパ
ーソナリティ名を設定する。また、そのパーソナリティ
名に対応するパーソナリティ登録表（９００）内のエン
トリを探し、そのエントリに従って、タスク制御ブロッ
ク（４０６）のサーバ・プログラムのセグメント・ディ
スクリプタ・フィールド（４０８）、サーバ関数エント
リ・ポイント・テーブル・ベース・アドレス・フィール
ド（４０９）、および割り込みベクタ・テーブル・ベー
ス・アドレス・フィールド（４０７）を設定する。局所
セグメント・テーブル（４１３）のベース・アドレス
（４１０）としては、処理ステップ１１０３において主
メモリ上に確保された領域の先頭アドレスを設定する。

【００６９】処理ステップ１１０６では、ロード・ルー
チン（９０２）によってリターンされたパーソナリティ
名に従って分岐し、処理ステップ１１０７では、そのパ
ーソナリティ名に従ったセット・アップ・ルーチン（９
０３）を起動する。このルーチンでは、サーバ・プログ
ラム（４０２）が管理するタスク制御ブロック（４０
４）の初期化が行なわれる。処理ステップ１１０８で、
初期環境に従った環境設定を行なう。最後に処理ステッ
プ１１０９で、レディーキュー操作とディスパッチャを
起動して終了する。

【００７０】図１２に、先程詳細を省略したロード処理
（図１１のステップ１１０４）の処理フローの代表例と
して、ＵＮＩＸパーソナリティのロード・ルーチン（９
０２）の処理フローを示す。ロード処理は、ａｒｇｖ
［０］（ａｒｇｖはｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔ
ｓｋ＿ｅｘｅｃｕｔｅ関数の引数として与えられる）で
指定されたパス名に該当するバイナリ・ファイルの主メ
モリ（１５０２）へのロード、およびａｒｇｖに従った
スタックの設定を行なう。ロード・ルーチン（９０２）
は、ａｒｇｖ，ａｒｇｃおよびマウント表（８００）へ
のエントリへのポインタを引数にとり、リターン値とし
て、主メモリ（１５０２）に展開したバイナリ・ファイ
ルのパーソナリティ名を返す。引数として与えられるマ
ウント表（８００）へのエントリへのポインタというの
は、現在、シェルが動作しているパーソナリティ（本例
では、ＵＮＩＸパーソナリティ）のパーティションに対
応するエントリへのポインタのことである。

【００７１】処理ステップ１２０１において、引数とし
て与えられたマウント表（８００）のエントリのルート
情報（８０４）から、ルートｉノードを獲得し、これを
作業ｉノードとする。処理ステップ１２０２では、パス
名（ａｒｇｖ［０］で指定されたパス名）の次の区切り
文字（ＵＮＩＸであれば”／”がこれにあたる）までの
ディレクトリ名（またはファイル名）の読み込みを行な
う。一番始めは、パス名の先頭から第１番目に出現する
ディレクトリ名（またはファイル名）が読み込まれるこ
とになる。次に、処理ステップ１２０３では、現在の作
業ｉノードの内容から、ステップ１２０２で読み込んだ
ディレクトリ名（またはファイル名）に該当するｉノー
ド番号を得て、これを新たな作業ｉノードとする。

【００７２】次に、処理ステップ１２０４において、作
業ｉノードがマウント・ポイントであるか否かを調べ
る。マウント・ポイントであるか否かの判別は、作業ｉ
ノードのディレクトリをマウント表（８００）のマウン
ト・ディレクトリ・エントリ（８０２）と比較し、一致
するものを検索することにより行なう。

【００７３】マウント・ポイントであれば、処理ステッ
プ１２０５で、マウント・ディレクトリ・エントリ（８
０２）が作業ｉノードのディレクトリと合致するマウン
ト表（８００）の当該エントリから、マウント先のファ
イル・システムのパーソナリティ名（８０２）を得る。
そして、処理ステップ１２０６において、未解析のパス
名（すなわち、ａｒｇｖ［０］で指定されたパス名から
マウント・ディレクトリ（８０２）部分を除いた分）、
コマンド・ライン引数、および当該マウント表（８０
０）エントリへのポインタを引数として与えて、マウン
ト先パーソナリティのロード・ルーチン（９０２）を呼
び出す。マウント先のパーソナリティ名（８０２）は既
にステップ１２０５で分かっているから、パーソナリテ
ィ登録表（９００）を参照して当該パーソナリティ名に
対応するロード・ルーチン（９０２）が分かる。ロード
後は、当該パーソナリティ名と呼び出したロード・ルー
チン（９０２）のリターン値を、リターン値として返し
て、ロード処理の実行を終了する。

【００７４】また、処理ステップ１２０４において、マ
ウント・ポイントでなければ、処理ステップ１２０７に
おいて、未解析のパス名が残っているかを判定し、残っ
ている場合には、処理ステップ１２０２に戻って実行を
継続する。残っていない場合には、ＵＮＩＸパーソナリ
ティのバイナリが指定されたということであるから、処
理ステップ１２０８でそのロードを行なう。すなわち、
処理ステップ１２０８で、マイクロ・カーネルは、まず
ｉノード情報からバイナリ・イメージが存在する論理ブ
ロック番号を得る。また、マイクロ・カーネルは、主メ
モリ（１５０２）上の空き領域を確保して、局所セグメ
ント・テーブル（４１３）を更新し、上記論理ブロック
番号のディスク・ブロック・データ（指定されたバイナ
リ・ファイルの内容）を主メモリに転送する。最後に、
ａｒｇｖに応じてスタック状態を変更して実行を終了す
る。この場合、リターン値のパーソナリティ名は、ＵＮ
ＩＸパーソナリティとなる。

【００７５】次に、上記形態例で説明したインターフェ
ースを用いて機能拡張されたｄｆコマンドを実行する応
用例について説明する。ｄｆコマンドとはディスクの使
用状況を標準出力に出力するコマンドであるが、本例に
よる拡張ｄｆコマンドでは、他パーソナリティのファイ
ル・システムが格納されているディスクパーティション
のディスク使用状況も知ることができる。例えば、ＵＮ
ＩＸのファイル・システムとＭＳ−ＤＯＳのファイル・
システムとが混在していた場合であっても、本例の拡張
ｄｆコマンドによれば、ＵＮＩＸで動作するｄｆコマン
ドを起動してＵＮＩＸのファイル・システムのディスク
使用状況を取得し、引続きＭＳ−ＤＯＳで動作するｄｆ
コマンドを起動してＭＳ−ＤＯＳのファイル・システム
のディスク使用状況を取得することができる。

【００７６】図１３に、拡張ｄｆコマンドの具体的なプ
ログラム例を示す。１行目で、ファイル・システムのマ
ウント状況を示すファイル／ｅｔｃ／ｆｓｔａｂをオー
プンしている。３行目で、その／ｅｔｃ／ｆｓｔａｂの
次のエントリのデバイス名（パーティション名）を、ｇ
ｅｔ＿ｎｅｘｔ＿ｄｅｖｉｃｅ関数で取得している。ｇ
ｅｔ＿ｎｅｘｔ＿ｄｅｖｉｃｅ関数は、次のエントリを
読み込む際にＥＯＦ（ファイルの終り）文字を読み込ん
だ場合には負の整数値を返すものとする。３行目から６
行目ではすべてのデバイスについて処理を終了したとき
にｆｉｎｉｓｈを１としてｂｒｅａｋするようにし、こ
れによりｗｈｉｌｅのループ（２行目から１８行目）を
抜けて処理を終了するようにしている。

【００７７】７行目では、ｇｅｔ＿ｎｅｘｔ＿ｐｅｒｓ
ｏｎａｌｉｔｙ関数により、ファイル・システムのパー
ソナリティ名を取得している。そして、８行目以降で、
ファイル・システムのパーソナリティ名に従って、それ
ぞれのパーソナリティのディスク使用状況を標準出力に
出力するコマンドを実行している。なお、この例では、
ファイル・システムのパーソナリティ名として、ＵＮＩ
ＸとＭＳ−ＤＯＳしか存在しないとした。従って、ファ
イル・システムのパーソナリティ名として「ＵＮＩＸ」
が返ってきたときは１１行目でｄｆ＿ｐｅｒｓｏｎａｌ
ｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関数を用いてＵＮＩＸ
のｄｆコマンド（／ｂｉｎ／ｄｆ）を実行し、「ＭＳ−
ＤＯＳ」が返ってきたときは１５行目でｄｆ＿ｐｅｒｓ
ｏｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関数を用いて
ＭＳ−ＤＯＳのｄｆコマンド（／ｄｏｓ／ＭＳＤＯＳ￥
ＤＦ．ＥＸＥ）を実行している。

【００７８】このように、ｄｆ＿ｐｅｒｓｏｎａｌｉｔ
ｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関数を用いると、通常のシ
ステムコール実行と同じ回数のコンテクスト・スイッチ
を用いて異パーソナリティ・アプリケーション・タスク
を起動することが可能であるので、上述の拡張ｄｆコマ
ンドのような複数のパーソナリティに対してそれぞれコ
マンド実行を要求しなければならないようなコマンド
も、高速な実行が可能になる。

【００７９】次に、上記形態例で説明したインターフェ
ースを用いて、拡張された＾Ｃ入力の実行をする応用例
について説明する。＾Ｃ入力とは、キーボード上のｃｔ
ｒｌキーとＣキーとを同時に押下することをいう。＾Ｃ
入力により、現在シェルの前面で動作しているアプリケ
ーション・タスクを強制終了させることができる。

【００８０】ここでは、例として、マルチ・パーソナリ
ティ・シェルがＭＳ−ＤＯＳパーソナリティ上で動作し
ており、かつ、そのシェルからＵＮＩＸアプリケーショ
ンが起動されているものとする。本例の拡張された＾Ｃ
入力の実行では、たとえシェルの前面で異パーソナリテ
ィ・アプリケーション・タスクが実行されていた場合に
も、その異パーソナリティ・アプリケーション・タスク
の実行を強制終了させることができる。図１４に、その
実行の手順を示す。

【００８１】いま、マルチ・パーソナリティ・シェルが
ＭＳ−ＤＯＳパーソナリティ上で動作しており、かつ、
そのシェルからＵＮＩＸアプリケーション（１４０６）
が起動されているとする。＾Ｃが入力されると、マイク
ロ・カーネルは、割り込みにより＾Ｃが入力されたこと
を知る（１４０１）。マイクロ・カーネルは、タスク制
御ブロック（４０６）により現在シェルの前面で実行中
のタスクを知ることができるから、＾Ｃ入力がかけられ
た被割り込みタスクがＵＮＩＸパーソナリティに属して
いることを知ることができる。動作中のシェルはＭＳ−
ＤＯＳパーソナリティに属するので、ＵＮＩＸパーソナ
リティに属するタスクを強制終了させるためには、この
割り込み発生をＵＮＩＸサーバ・プログラム（１４０
４）に通知する必要がある。

【００８２】そこで、マイクロ・カーネルは、割り込み
ハンドラの最後において、現在実行中のタスクＩＤ（ア
プリケーション（１４０６）のタスクＩＤ）を引数にし
てＵＮＩＸパーソナリティのサーバ関数をコール（１４
０２）するように、割り込みハンドラを形成しておく。
ＵＮＩＸパーソナリティのサーバ関数のエントリ・ポイ
ント（１４０３）が格納されているサーバ関数エントリ
・ポイント・テーブル（４１２）のベース・アドレス
は、予めｐｅｒｓｏｎａｌｉｔｙ＿ｒｅｇｉｓｔｅｒ関
数でパーソナリティ登録表（９００）のサーバ関数エン
トリ・ポイント・フィールド（９０６）に登録されてお
り、さらにｄｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔｓｋ＿ｅ
ｘｅｃｕｔｅ関数によりアプリケーション（１４０６）
のタスクを生成するときにタスク制御ブロック（４０
６）のサーバ関数エントリ・ポイント・テーブル・ベー
ス・アドレス・フィールド（４０９）にコピーされるの
で、当該エントリ・ポイント（１４０３）を知ることが
できる。

【００８３】ＵＮＩＸサーバ・プログラム（１４０４）
は、サーバ関数の中で、引数で与えられたタスクＩＤに
該当するアプリケーション・タスク（１４０６）にＳＩ
ＧＴＥＲＭシグナルを送信する（１４０５）。ＳＩＧＴ
ＥＲＭシグナルを受信したタスク（１４０６）は、シグ
ナル・ハンドラを実行し、自らを強制終了させる。

【００８４】エミュレーション方式のように、エミュレ
ータ上で異パーソナリティ・アプリケーション・タスク
を実行している場合には、カーネルから見えているエミ
ュレション・タスクに対し、まず、指定アプリケーショ
ンの終了を要求するシグナルを送信する必要がある。そ
して、そのシグナルハンドラ内で、エミュレータから実
行しているアプリケーションに対して強制終了を要求す
るメッセージを送信してやる必要がある。このようにエ
ミュレーション方式では、コマンド・ラインから＾Ｃが
入力されたとしても、容易に異アプリケーション・タス
クの強制終了を行なうことができない。それに対し、ｄ
ｆ＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ
関数を用いて起動された異アプリケーション・タスクに
対しては、上述したように強制終了を容易に実現でき
る。

【００８５】上記形態例および応用例によれば、パーソ
ナリティごとに割り込みベクタ・テーブルを定義可能に
した。その結果、例えば異なるパーソナリティの２つの
タスクがシステムコール実行のために同じトラップ命令
を発しても、異なるシステムコール処理ルーチンが実行
される。また、パーソナリティごとに割り込みベクタ・
テーブルを差し替えることに加えて、タスクを起動する
際にパーソナリティごとに異なるルーチンをパーソナリ
ティ登録表に登録するインターフェースを提供した。さ
らに、異パーソナリティ・ファイル・システムのマウン
ト情報をマウント表に登録するインターフェースも提供
した。その結果、起動したいアプリケーションのバイナ
リ・ファイルのパス名を指定すれば、マウント表を用い
たパス名解析を行ない、属するファイル・システムのパ
ーソナリティ名が判別可能になった。そして、パーソナ
リティ登録表内のパーソナリティ名に対応するエントリ
から、タスク起動の際のパーソナリティ依存ルーチンを
得ることができる。その結果、パス名の指定のみで、異
アプリケーション・タスクを同一インタフェースで起動
することを可能にしている。以下、本形態例がもたらす
結果を要約する。

【００８６】１）本形態例が提供するｐｅｒｓｏｎａｌ
ｉｔｙ＿ｒｅｇｉｓｔｅｒ関数などを用いると、パーソ
ナリティごとに、任意の割り込みベクタ・テーブルを実
現できる。その結果、従来の単一パーソナリティ・サポ
ートのオペレーティング・システム上で動作していたア
プリケーションのバイナリ・ファイルがそのままマルチ
・パーソナリティ・シェルにおいても利用できる。

【００８７】２）本形態例が提供するｄｆ＿ｐｅｒｓｏ
ｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関数を用いる
と、単一パーソナリティ・サポートのオペレーティング
・システムと同じコンテクスト・スイッチ回数で異パー
ソナリティ・アプリケーション・タスクを起動可能にな
る。従来のＭａｃｈやエミュレーション方式による異パ
ーソナリティ・アプリケーション起動より、起動時間が
短縮できる。

【００８８】３）本形態例が提供するｄｆ＿ｐｅｒｓｏ
ｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関数を用いる
と、マイクロ・カーネルがすべてのパーソナリティのタ
スクを管理することになる。また、サーバ・プログラム
へのイベント通知は、タスク間通信機構ではなくサブ・
ルーチン・コールで実現可能になる。そのため、任意の
パーソナリティに属するタスクの強制終了処理が容易な
手順でしかも高速に実現可能になる。

【００８９】

【発明の効果】以上説明したように、本発明によれば、
高速に異パーソナリティ・アプリケーション・タスクを
起動することができ、従来の単一パーソナリティ・オペ
レーティング・システム上で動作していたアプリケーシ
ョンのバイナリ・ファイルをそのまま利用することがで
き、さらに、異パーソナリティ・アプリケーション・タ
スクの強制終了を複雑な処理を経ないで実行することの
できる、マルチ・パーソナリティ・シェルを実現可能な
異パーソナリティ・アプリケーションの起動方法および
コンピュータ・システムが提供される。

【図面の簡単な説明】

【図１】Ｍａｃｈマイクロ・カーネルを用いてマルチ・
パーソナリティを実現する従来のソフトウェア構成の概
要図

【図２】Ｍａｃｈマイクロ・カーネルの異パーソナリテ
ィ・タスク起動手順を示す図

【図３】エミュレーション方式の異パーソナリティ・タ
スク起動手順を示す図

【図４】本発明の実施の形態例のソフトウェア構成図

【図５】セグメント機構を示す図

【図６】形態例の空間配置を示す図

【図７】形態例のマルチ・パーソナリティ・シェル・プ
ログラムの一例を示す図

【図８】マウント表の構造を示す図

【図９】パーソナリティ登録表の構造を示す図

【図１０】形態例の割り込みベクタ・テーブルの割り付
け法を示す図

【図１１】異アプリケーション・タスク起動処理（ｄｆ
＿ｐｅｒｓｏｎａｌｉｔｙ＿ｔｓｋ＿ｅｘｅｃｕｔｅ関
数）の処理フローを示す図

【図１２】ＵＮＩＸパーソナリティのロード・ルーチン
の処理フローを示す図

【図１３】拡張ｄｆプログラムの一例を示す図

【図１４】異パーソナリティ・アプリケーションの強制
終了の手順を示す図

【図１５】形態例のコンピュータ・システムのハードウ
ェア構成を示す図

【符号の説明】

４０１…アプリケーション、４０２…サーバ・プログラ
ム、４０３…マイクロ・カーネル、４０４…タスク制御
ブロック、４０６…タスク制御ブロック、４１４…パー
ソナリティ名、４０７…割り込みベクタ・テーブル・ベ
ース・アドレス、４０８…サーバ・プログラムが存在す
るセグメントのセグメント・ディスクリプタ、４１２…
サーバ関数エントリ・ポイント・テーブル、４０９…サ
ーバ関数エントリ・ポイント・テーブル・ベース・アド
レス、４１３…局所セグメント・テーブル、４１０…局
所セグメント・テーブルのベース・アドレス、８００…
マウント表、９００…パーソナリティ登録表、１５０１
…ＣＰＵ、１５０２…主メモリ、１５０３…ディスク・
コントローラ、１５０４…ディスク。

Claims (4)

【特許請求の範囲】
1. 【請求項１】異種のオペレーティング・システム上で動
   作するアプリケーションである異パーソナリティ・アプ
   リケーションを起動する起動方法であって、 異種のオペレーティング・システム用のファイル・シス
   テムのマウント情報を、カーネル内に予め登録するステ
   ップと、 異種のオペレーティング・システム上で動作するタスク
   を起動するにあたって必要となる該オペレーティング・
   システムに依存するパーソナリティ依存情報を、カーネ
   ル内に予め登録するステップと、 異種のオペレーティング・システム上で動作するアプリ
   ケーションのバイナリ・ファイルのパス名が指定された
   とき、上記マウント情報とパーソナリティ依存情報を用
   いて、該アプリケーションのバイナリ・ファイルのディ
   スク上の存在位置と、該アプリケーションの属するパー
   ソナリティを特定し、バイナリ・ファイルの内容をファ
   イル・システムから読み込み、主メモリにロードし、か
   つ初期環境を与えて該アプリケーションを起動させるス
   テップとを備えたことを特徴とする異パーソナリティ・
   アプリケーションの起動方法。
2. 【請求項２】前記パーソナリティ依存情報が、当該パー
   ソナリティに特有の、パーソナリティ名、バイナリ・フ
   ァイルのロード・ルーチン、タスクの初期化ルーチン、
   割り込みベクタ・テーブル、およびサーバ関数エントリ
   ・ポイントを特定する情報である請求項１に記載の異パ
   ーソナリティ・アプリケーションの起動方法。
3. 【請求項３】異種のオペレーティング・システム上で動
   作するアプリケーションである異パーソナリティ・アプ
   リケーションを起動するインターフェースを有するコン
   ピュータ・システムであって、 異種のオペレーティング・システム用のファイル・シス
   テムのマウント情報を、カーネル内に予め登録するイン
   ターフェースと、 上記登録されたマウント情報を削除するインターフェー
   スと、 異種のオペレーティング・システム上で動作するタスク
   を起動するにあたって必要となる該オペレーティング・
   システムに依存するパーソナリティ依存情報を、カーネ
   ル内に予め登録するインターフェースと、 上記登録されたパーソナリティ依存情報を削除するイン
   ターフェースと、 異種のオペレーティング・システム上で動作するアプリ
   ケーションのバイナリ・ファイルのパス名が指定された
   とき、上記マウント情報とパーソナリティ依存情報を用
   いて、該アプリケーションのバイナリ・ファイルのディ
   スク上の存在位置と、該アプリケーションの属するパー
   ソナリティを特定し、バイナリ・ファイルの内容をファ
   イル・システムから読み込み、主メモリにロードし、か
   つ初期環境を与えて該アプリケーションを起動させるイ
   ンターフェースとを備えたことを特徴とするコンピュー
   タ・システム。
4. 【請求項４】前記パーソナリティ依存情報が、当該パー
   ソナリティに特有の、パーソナリティ名、バイナリ・フ
   ァイルのロード・ルーチン、タスクの初期化ルーチン、
   割り込みベクタ・テーブル、およびサーバ関数エントリ
   ・ポイントを特定する情報である請求項３に記載のコン
   ピュータ・システム。