JPH06295237A - 動作システムを動作させるシステム及び方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】新しいモジュールが作り出されても、カーネル
を格納するのに必要な記憶装置の量を増大しないように
する。 【構成】動作システムのモジュールにアクセスするプロ
セスにより要求を阻止し、モジュールがカーネル記憶装
置にロードされてカーネル記憶装置に設置され且つ適切
な表に載置されている他のモジュールと連結されている
か否かを判定するモジュールサブシステムを設ける。モ
ジュールがカーネル記憶装置に入っており且つ設置さえ
ていれば、モジュールサブシステムは要求されているモ
ジュールへの設置プロセスアクセスを承認し、処理が継
続する。モジュールがカーネル記憶装置にロードされて
いなければ、モジュールサブシステムはモジュールのコ
ピーを検索してこれをカーネル記憶装置内に複写する。
次にモジュールをカーネルに設置されている他のモジュ
ールと連結し、設置する。アクセスの承認が要求中のプ
ロセスに対して与えられ、通常の処理が継続する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、動的に構成可能なカー
ネルに関する。更に詳細には、本発明は、必要に応じて
カーネルのモジュールを自動的にロードするシステムに
関する。

【０００２】

【従来の技術】コンピュータシステムの中心構成要素の
一つはその動作システムのカーネルである。カーネル
は、ストリームドライバや装置ドライバを含むドライ
バ、ファイルシステムモジュール、スケジュールクラ
ス、ストリームモジュール、およびシステムコールのよ
うな複数のモジュールから構成されているのが普通であ
る。これらモジュールはコンパイルされ、続いて互いに
連結されてカーネルを形成する。それに続き、システム
が始動するかまたは「ブートアップ」されると、カーネ
ルが記憶装置にロードされる。しかし、技術が進歩し、
一層多くの機能を発揮する更にこみ入った複雑なモジュ
ールが作られ、新しいモジュールが作り出されるにつれ
て、カーネルを格納するのに必要な記憶装置の量が劇的
に増大する。

【０００３】

【発明が解決しようとする課題】コンピュータシステム
の記憶装置の限界を克服する一つの方法はページング可
能なカーネルである。ページング機構はカーネル記憶装
置をカーネル記憶装置のメモリ使用法に従ってページン
グするかまたはディスクに取換えることにより実現され
る。しかし、カーネルの多大な部分がページング不可能
であり、カーネルをページング可能な部分に区分する困
難さは得られる可能性のある利益より大きいことがわか
っている。コンピュータシステムはコンピュータ利用の
各計画形式について静的に構成されるのが普通である。
コンピュータの中には基本モジュールだけが利用される
ものがある。他のコンピュータはこみ入った処理に利用
され、別のモジュールを必要とすることがある。しか
し、カーネルを構成したりまたは再構成したりする仕事
は簡単ではなく、一般に典型的なユーザの技能の程度を
超えている。

【０００４】

【課題を解決する手段】本発明によれば、仮想的カーネ
ル機能が提供される。これは要求時に、必要に応じて、
カーネル記憶装置にモジュールを設けることにより達成
される。したがって、可能な限り少ない組合わせのモジ
ュールを最初カーネルにロードし、残りのモジュールを
必要なときだけ追加する。これは、コンピュータシステ
ムの典型的なほとんどのユーザが利用可能なモジュール
すべてを必要とすることはないから、カーネルに必要な
記憶装置の量を劇的に減らすことがわかっている。更
に、この方法ではカーネルにロードしようとするモジュ
ールのどれかが変わる場合再構成する、すなわち、（カ
ーネルを構築しなおす）必要性が回避される。

【０００５】当業界ではドライバを、ドライバモジュー
ルをロードする命令を明らかに実行することによりユー
ザがロードし得ることが周知であるが、これでは必要に
応じてモジュールを自動的にロードしてカーネルを維持
するのに必要な記憶装置の量を可能な限り少なくするよ
うになっていない。

【０００６】本発明のシステムは仮想的カーネル機能を
提供するシステムを示している。各モジュールは実行可
能なイメージに別々にコンパイルされる。モジュールは
カーネルにより要求されるまで記憶装置に置かれる。カ
ーネル記憶装置に設けられているシステム構成表は、モ
ジュールがカーネルに存在するか、またはモジュールが
カーネルに存在せず、したがってカーネルをカーネル記
憶装置にロードして既にカーネル記憶装置にロードされ
ているモジュールと連結する必要があるかを判定するの
に利用される。仮想的機能は、モジュールを参照すると
きモジュール構成表にアクセスする要求を検出し、モジ
ュールが記憶装置に存在するか否かを判定するためにア
クセスの要求を中断することにより与えられる。モジュ
ールがカーネル記憶装置に存在しなければ、モジュール
をカーネル記憶装置にロードし、そのモジュールをカー
ネル記憶装置に存在しているモジュールと動的に連結
し、その後のアクセスがモジュールがカーネルにロード
され且つ設置されていることを示すようにモジュールを
適切な構成表に設置する。

【０００７】

【実施例の説明】説明の目的のための以下の記述では、
特定の記憶装置、組織、構造、データ速度などを本発明
を充分理解できるようにするため示してある。しかし、
当業者には本発明をこれら特定の細目が無くても実用化
し得ることが明らかであろう。他の場合には、本発明を
不必要に不明瞭にしないために周知の回路またはハード
ウェアをブロック図の形で示してある。本発明の動的に
構成可能な動作システムを下にUNIX動作システムに関し
て説明する（UNIXはAT&Tの登録商標である）。当業者に
は次の説明から本発明がそのように限定されるものでは
なく、他の動作システムにも適用し得ることが明らかで
あろう。

【０００８】カーネルを動的に構成する２ステッププロ
セスについて説明する。カーネルに設置されているシス
テム構成表の組合わせを利用してモジュールの状態を識
別する。モジュールが呼出されるかまたは参照されるか
すると、そのモジュール形式に対する構成表を調べてモ
ジュールが設置されているか否か判定する。モジュール
が設置されていなければ、モジュールをロードし、設置
し、それにより構成表を対応して更新する。

【０００９】カーネル内にアクセス可能なモジュールを
設けるために、モジュールをカーネルにロードして設置
する。ロードするプロセスの間、仮想的および物理的な
記憶装置をそのモジュールのためにとっておく。モジュ
ールを物理的記憶装置に書込み、モジュールをその連結
された仮想的アドレスに再配置し、すべての記号参照を
行えるようにする。設置している間、モジュールを適切
な構成表に接続し、モジュールに関する表のエントリが
割当てられ、それに適切な情報が記入されるようにす
る。

【００１０】図１を参照すると、モジュールはしたがっ
て三つの状態の一つにあることができる。最初モジュー
ルはロードされまたは設置されてなく、エントリが構成
表に割当てられていない（構成表があらかじめ割当てら
れたエントリを備えている場合の他） (1)。モジュール
をロードし得るが、モジュールは設置されずエントリが
構成表内に割当てられていない (2)。モジュールに対す
るエントリを構成表に割当てることができ、それに適切
な情報が書込まれ、モジュールがカーネルにロードさ
れ、設置されている (3)。この状態では、モジュールに
アクセスすることができ、モジュールが行う動作をシス
テムに利用することができる。下に説明するとおり、構
成表内のエントリはモジュールを最初に設置したとき割
当てられることができる。代わって、装置ドライバ構成
表のような或る構成表では、エントリを各モジュールの
あらかじめ割当てられた識別番号に対応するようにあら
かじめ割当てることが有利である。

【００１１】カーネルはハードウェアの動作に関する機
能を行う複数のモジュールから構成されている。モジュ
ールには装置ドライバ、システムコールモジュール、フ
ァイルシステムモジュール、ストリームモジュール、ス
ケジューリングクラスモジュール、および他の雑多なモ
ジュールがある。これらモジュールは別々にコンパイル
され、格納される。カーネルは最初基本的な組合わせの
モジュールで構成される。基本的組合わせのモジュール
は少なくとも、モジュールを記憶装置から読出すモジュ
ール、およびモジュールをカーネル記憶装置にロード
し、ロードしようとするモジュールをカーネルに現存し
ているモジュールと連結するモジュールサブシステムを
備えるべきである。基本的組合わせのモジュールを始動
時にロードしまたは結合することを要求するだけで、モ
ジュールの残りの結合をモジュールが必要になるまで遅
らせ、それによりシステムの柔軟性が保たれる。しか
し、ユーザの要求および仕様に従って別のモジュールを
最初にロードすることができる。たとえば、記憶装置管
理モジュールおよび或る装置ドライバモジュールを、そ
れらモジュールの使用頻度に基づきロードするのが望ま
しいことがある。

【００１２】システムを作り上げるときは、複数のモジ
ュール構成表を作り、カーネル記憶装置に格納する。こ
れら構成表をカーネルにロードすべきモジュールの形式
に従って分類する。たとえば、装置ドライバ用構成表、
システムコール用構成表、ストリームモジュール用構成
表、およびファイルシステムモジュール用構成表が存在
する。モジュールを静的にロードし、始動時に結合する
従来技術のシステムでは、これら構成表は、各モジュー
ルの構造を指すポインタまたはハンドルを含む、各モジ
ュールに関する情報と共にロードされる。たとえば、Su
nＯs動作システム（SunＯsはSun Microsystems, Inc.の
商標である）UNIXカーネルでは、装置ドライバ構成表、
devopsp、の各エントリにはdev−ops構成を指すハンド
ルに対するフィールドがある。同様に、ファイルシステ
ム構成表、 vfssw、にはファイルシステムの名称に関す
るフィールド、ファイルシステムについての「init」ル
ーチンを指すハンドル、vfsops構造を指すハンドル、お
よびファイルシステムにアクセスするのに使用されるロ
ックがある。

【００１３】本発明のシステムでは、異なるモジュール
を識別する表のエントリをモジュール名称と静的に結び
つけるのではなく、モジュールをカーネルに設置すると
き必要に応じて作り、または割当てるようにしている。
しかし、ユーザによりアクセスし得る一貫した識別が必
要なこれらモジュール形式はブーツを横断しておよび機
能を横断して一貫した識別または結合を確保するために
構成表にエントリをあらかじめ割当ててある。たとえ
ば、構成表が装置ドライバ用のもの、「 devopsp」、で
あれば、装置ドライバ用のエントリを各装置ドライバの
主要番号が一貫して割当てられるようにあらかじめ割当
てられている。同じ要求事項がシステムコールについて
存在する。すなわち「sysint」表は各システムコールモ
ジュールをそのシステムコール番号により一貫して識別
しなければならない。

【００１４】システムはそのようなものに限定されない
が、モジュールが構成表内にエントリを割当てられれ
ば、エントリはシステムが再ブーツされるまで割当てら
れたままであることが望ましい。各構成表において表内
の各エントリに対する所定のフィールドはモジュールの
状態を識別するのに使用される。構成表に複数のハンド
ルがあれば、モジュールの状態を識別するのに最も活動
的なハンドルを利用するようにする。ハンドルがヌル値
のような所定の値であれば、モジュールは未設置状態に
ある。表の空フィールドを参照するとき生ずることがあ
る不参照エラーを回避するために、モジュールの未設置
状態をモジュールの未設置状態を示す所定の特定値を挿
入することにより識別するようにする。たとえば、ハン
ドルをモジュールがカーネルに設置されていないことを
示すようにあらかじめ決定されているアドレスと共にロ
ードする。モジュールがカーネルにロードされれば、ハ
ンドルフィールドにはモジュールに対する有効ハンドル
が入ることになる。

【００１５】これらヌルまたは特殊エントリはモジュー
ルサブシステムに対してモジュールをカーネルにロード
して設置すべきことを示すフラグとして働く。したがっ
て、コードを実行して特定のモジュールを呼出すと、そ
のモジュールがカーネルにロードされ、カーネル記憶装
置に現存する他のモジュールと連結され、構成表に設置
されているかを判定するチェックが行われる。モジュー
ルがロードされていず、設置されていなければ、モジュ
ールサブシステムは処理を続ける前にモジュールをカー
ネルにロードし設置させる。モジュールが設置されてい
ることが確認されれば、カーネルでの処理が続行され
る。代わりに、特定のモジュールを最初に呼出すかまた
は参照する場合にはフラグをカーネルの異なる場所に組
込むことができる。こうしてから代わりの機構を使用し
てこれらフラグの有無およびモジュールの状態を検出す
る。

【００１６】モジュールサブシステムをカーネルに設け
て、カーネル内の一定のモジュールに対して行われる呼
出しを中断し、モジュールが現在カーネルにロードされ
て設置されているかまたはモジュールをカーネル記憶装
置にロードし、連結し、設置することを必要としている
か判定する。模範的なモジュールサブシステムおよびカ
ーネルとの相互作用のブロック図を図２に示す。モジュ
ールサブシステム20は、モジュールがカーネル記憶装置
にロードされ且つ設置されているか否かを判定するため
にモジュールに対する各呼びを阻止する。モジュールサ
ブシステムはまた、呼ばれたモジュールがロードされて
設置されているか判定するため、モジュールを呼出す他
のモジュールからの呼びを阻止する。図２を参照する
と、ユーザプログラムおよびライブラリはシステムコー
ルを発し、これはカーネルにおいてシステムコールモジ
ュール10により受取られる。モジュールサブシステム20
は、特定の呼びがカーネルに設置されているモジュール
により支持されているか否かを、システムコール構成表
システム30を調べることにより判定する。モジュールが
ロードされ且つ設置されていれば、それに対応する動作
が行われる。同様に、ファイルサブシステム33またはプ
ロセス制御サブシステム35が必要ならば、モジュールの
設置が、 vfssw表37を参照することにより、またはプロ
セス制御サブシステムの場合には、クラス39またはexec
sw表40を参照することによりチェックされる。これらは
モジュールサブシステム20により検査されてモジュール
がロードされ設置されているか判定する。装置ドライバ
モジュールが必要なときは表devopsp 42がモジュールサ
ブシステム20によりチェックされ、ストリームモジュー
ルが必要なときは、表fmodsw44が同様にモジュールサブ
システムによりチェックされる。

【００１７】図４を参照すると、モジュールサブシステ
ムは制御モジュール70、設置モジュール74、および実行
時リンカー72から構成されている。制御モジュール70は
モジュールに対するアクセス要求を阻止し、適切なモジ
ュール構成表を調べてモジュールがカーネルに設置され
ているか判定する。設置モジュール74は、制御モジュー
ル70がカーネルに存在しないことを確認するときモジュ
ールをカーネルにロードさせ、設置させ、実行時リンカ
ー72は、ロードされ設置されるモジュールに呼出される
が、カーネルに既に存在しているモジュールとロードし
ようとするモジュールとの間の参照を解決する。

【００１８】好適実施例では、モジュールサブシステム
は対応するモジュール構成表を参照することによりモジ
ュールの状態を判断する。モジュールは必要なとき自動
的にロードされ、設置される。モジュールは、それらが
行う機能が名称（ストリームモジュールのプッシュまた
はファイルシステムのマウントのような）により参照さ
れるときまたはカーネルに存在しない機能に対するカー
ネル参照を満足するのにモジュールが必要であるとき、
必要である。模範的な構成表を図３に示す。好適実施例
では、これらの表を、モジュールの形式（たとえば、fm
odsw）を識別する特定の記号名または変数名により識別
されるロケーションで参照されるカーネル記憶装置のロ
ケーションに設置される。たとえば、ファイルシステム
モジュールに対する構成表は「 vfssw」として識別され
る。使用する名称および表が設置されるロケーションは
現存するUNIXカーネルに見られるものと同じであること
が望ましい。

【００１９】カーネルにモジュールを動的にロードする
プロセスを図５の流れ図により図解してある。モジュー
ルへのアクセスが要求されるときおよび／またはプロセ
ス表にアクセスしようとするとき、モジュールサブシス
テムはアクセス要求を阻止する、ステップ 100。モジュ
ールに対する表のエントリをチェックしてそこにモジュ
ールがカーネルに設置されていないことを示す特別のま
たは空のエントリが入っていないか判定する、ステップ
105。特別のまたは空のエントリが存在しないためモジ
ュールが設置されていることが確認されれば、ステップ
110、モジュールサブシステムは戻って要求中のプロセ
スアクセスを承認し、通常の処理を継続させる、ステッ
プ 115。空のまたは特別のエントリが存在すれば、制御
モジュールは記憶装置からコンパイル済みモジュールが
入っているファイルを検索し、ステップ120、そのファ
イルを調べてファイルの大きさを決定する、ステップ12
5。次に記憶装置をそのファイルのカーネル記憶装置に
割当てる、ステップ 130。好ましくは、これは現存のUN
IXカーネルに存在するカーネル記憶装置割付けルーチン
を用いて行われる。次にコンパイル済みモジュールが入
っているファイルを割当てられた記憶装置に複写し、ス
テップ 135、次に設けられている実行時リンカーを始動
させてモジュールをカーネル記憶装置に設置されている
他のモジュールと連結し、それとの参照を解決する、ス
テップ 140。

【００２０】リンカーはモジュールでのコードによる参
照を固定し、正しいアドレスを参照しまたは呼出す。こ
のようにして、リンカーは、呼出すべきモジュールの名
称を使用して、機能が存在しているモジュール内のアド
レスを決定する。このアドレスを次に機能参照時にモジ
ュールに書込み、コードを実行するとき正しいアドレス
が識別されるようにする。リンカーの技術は当業者に周
知であり、ここでは詳細には説明しないことにする。好
適実施例ではカーネルは、或る一つの時期にモジュール
が一つだけ連結されることを除いてはUNIXファイルシス
テムで行われているdlopen、dlclose、およびdlsymと同
様の機能を行うリンカーを備えている。dlopen、dlclos
e、およびdlsymに関する事項については、Sun Microsys
tems, Inc.のSunＯs動作システムマニアルページ、「Mi
scellaneous Library Functions(雑多なライブラリの機
能)」 (1990)を参照のこと。更にリンカーがモジュール
ファイルを指定アドレスに割当てしなおし、次いで共通
変数を割当て、モジュールからのカーネルへの参照を解
決するのが望ましい。

【００２１】モジュールは目的ファイルであるから、そ
れには未解決の参照が存在していることがある。これら
参照はモジュールがカーネル記号表をのぞくことにより
ロードされると満足される。それ故、モジュールが他の
モジュールを必要とするということを特に述べている場
合の他はこれら参照を解決するのに他のモジュールに関
する記号を使用しないことが望ましい。これは幾つかの
異なるモジュールに共通のコードが必要であるとき生ず
ることがある。たとえば、他のモジュールが必要である
ことを特に述べる一つの方法は文字列変数「＿depends
＿on 」を宣言し、これをこのモジュールが従属してい
る他のモジュールの<subdir／filename>対を用いて初期
設定することによることである。これは共通ライブラリ
にアクセスする実行可能イメージにある所要ライブラリ
リストと同様に働く。したがって、モジュールをロード
すると、従属変数で表されているモジュールのリストを
最初にロードする。

【００２２】カーネルの静的に連結された部分には未規
定の参照が存在する可能性があり、それ故、カーネルは
モジュール記号を直接参照することができない。モジュ
ールは、モジュールをロードするとカーネル実行時リン
カーが参照をモジュールからカーネルへ変ずるから、カ
ーネル記号への参照を備えていることがある。

【００２３】しかし、カーネルがカーネルの存在部分か
ら移動してしまっている機能を参照することを必要とす
るときがある。たとえば、カーネルでのexit()ルーチン
は常に退出プロセスがUNIXシステムＶ共有記憶装置を使
用して場合に浄化するshmexit()を呼出す。しかし、shm
exit()は今はロード可能モジュールにあってカーネルの
存在部分と連結していない。それ故、 shmexit()が規定
されていなければ、カーネルは未規定記号を受取ること
になる。解決法はカーネルの存在部分と連結している s
hmexit()に対するダミールーチンを設けることである。
このルーチンは適切なモジュールをロードしたり制御を
モジュールの目標ルーチンに移したりする仕方を知って
いる。このような存在ダミー機能をスタブという。スタ
ブは間接アドレス機能としてまはたＰＬＴ（手順連結
表）のエントリと類似しているが一層柔軟性が大きいも
のとして見ることができる。代わりに、ＰＬＴを修正し
てスタブ機能を発揮させることができる。たとえば、Su
nＯs動作システムでは、制御をモジュールの目標ルーチ
ンに移すと、スタックフレームはスタブの呼出されたル
ーチンが間接に目標モジュールルーチンへの呼びを行う
ように見えるように配列される。したがって呼出し部の
引数が目標ルーチンに伝えられる。図６はスタブの処理
を図解する流れ図である。

【００２４】スタブはすべてファイルで規定されてい
る。スタブは現存する機能をカーネルからおよびモジュ
ール内に移動させるのに必要な機構を提供する。スタブ
には強および弱の二つの形式がある。強いスタブは必要
な場合モジュールをロードしようとし、弱いスタブはそ
うしない。上の例では、 shmexit()カーネル内で弱いス
タブとして規定されている。典型的には、弱いスタブは
得られる状態を単にカーネルにロードしないということ
により指示するモジュールについて利用される。たとえ
ば、共有記憶装置モジュールが既に存在していなけれ
ば、共有記憶装置区画は存在せず、したがってモジュー
ルをロードし、チェックを行って共有区画が存在しない
ことを見出す必要は全く無い。

【００２５】図７を参照すると、二つのスタブデータ構
造が設けられている。一つはモジュールを記述するもの
であり他はそのスタブ機能を記述するものである。図
８、９は図７のデータ構造を作るのに使用されるスタブ
マイクロの図解を示している。

【００２６】図５に戻って、モジュールがカーネル記憶
装置にロードされ、他のモジュールと連結されると、ス
テップ 145、設置プロセスが行われ、ロードされたモジ
ュールの構成表エントリがモジュールが今はカーネル記
憶装置に設置されていることを反映するように更新され
る。モジュールの対応する構成表に割当てられているエ
ントリが無い場合には、エントリが割当てられ、情報が
そのエントリに対するフィールドに入れられる。エント
リがモジュールに対してあらかじめ割当てられていれ
ば、モジュールがカーネルにロードされていないことを
示す特別のまたは空のエントリが現在入っているハンド
ルフィールドが、そのモジュールに対する正しいハンド
ルを備えるように更新される。こうしてから制御は阻止
されたプロセスに戻り、通常の処理が継続する。

【００２７】カーネルは、モジュールサブシステムを介
して、三つの機能、モジュールをロードして設置する機
能、モジュールをアンロードして取外す機能、およびモ
ジュールの状態に関する情報を要求する機能、を利用す
るのが望ましい。本発明のシステムにロードすることが
できるモジュールの形式に関する柔軟性を維持するに
は、カーネルが対応してモジュール特有機能を呼出して
所要機能を行うことが望ましい。それ故、好適実施例で
は、各モジュールはカーネルとモジュールとの間のイン
ターフェースとして働くラッパーを備えている。モジュ
ールラッパーはカーネルにより呼出すことができる三つ
の機能を規定する。「＿init」ルーチンはモジュールが
ロードされ設置されると引数なしでカーネルから呼出さ
れる。このルーチンはモジュールをシステムに引掛ける
責務を有する。下に更に詳細に説明するように、「＿fi
ni」ルーチンはモジュールをアンロードし取外す要求が
行われたときカーネルから呼出される。「＿fini」ルー
チンはモジュールがアンロードおよび取外しに利用でき
るか否かを判定し、取外しおよびアンロードに利用でき
れば、モジュールをシステムから外す。「＿info」ルー
チンはモジュール情報の要求が行われたときカーネルか
ら呼出される。

【００２８】連結構造、modlinkage、はモジュールで規
定されている連結構造を好適に識別する。連結構造には
モジュールに関するモジュール特有情報が入っている。
説明の目的で、モジュールあたり一つだけ連結構造を規
定してある。しかし、当業者にはモジュールあたり複数
の連結構造を規定し得ることが明らかであろう。構造の
図解を図１０に示す。変数「 ml−rev」はシステムの改
訂を表す。ラッパーの規定が変われば、改訂が変わる。
これにより現存するモジュールの支持が簡単になる。変
数「ml−linkage［4］」は連結構造を指すポインタのヌ
ル終端列である。連結構造にはモジュールを設置したり
取外したりするのに使用される情報が入っている。異な
る形式の連結構造の好適実施例を図１１に示す。連結構
造の最初の二つの要素にはすべてのモジュールに関する
同じ形式の情報が入っている。構造の残りはモジュール
特有である。図１１はモジュールをUNIXシステムのカー
ネルに見られるもののような例として引用したものであ
る。

【００２９】モジュールは連結する前に、ＥＬＦフォー
マット（拡張可能リンカーフォーマット）のような目的
コードフォーマットにコンパイルされる。コンパイルさ
れたモジュールは記憶部または他の記憶装置の所定の部
分に設置される。各モジュールは、ファイルシステムの
名称またはシステムコールのような、特定のモジュール
と一義的に関連している。名称またはハンドルにより識
別される。コール番号で識別されるモジュールもある。
たとえば、システムコールまたは装置ドライバは番号で
識別することができる。これらの番号はモジュールの異
なる形式を横断しては一義的でないのでこれら数値識別
子に対して独特の識別子を設けることが必要である。そ
れ故、特定の形式のモジュールに対する数値識別子をモ
ジュールを表すコンパイル済みファイルを識別する独特
のモジュール名称に翻訳する表を設けることが望まし
い。しかし、ファイルシステムのような独特の名称によ
って既に識別されているモジュールは翻訳する必要はな
く、システムで採用されている名称がモジュールのファ
イルにアクセスするのに使用される。

【００３０】「ラッパー」と言われる見出し情報が各フ
ァイルに設けられていてファイルおよびモジュールに関
する一定の情報を提供する。ファイルシステムに対する
模範的ラッパーを図１２に示す。ラッパーはファイルが
ロード可能なモジュールであること、モジュールの形
式、およびモジュールの形式に対する適切な設置コード
を指すポインタを識別する。カーネル内の設置コードは
適切な構成表内のモジュールの設置に関する特定の指令
を示す。ラッパーはコードをモジュールのソースコード
に挿入してラッパー情報を発生することにより形成され
る。

【００３１】たとえば、図１２は「device filesyste
m」と名付けられているファイルシステムのラッパーを
示す。この形式のファイルシステムの内部名称は「 dev
fs」であり、vfssw構造はinitルーチン、devfsinit、を
規定するが、これはモジュールが最初にロードされたと
き行われる機能を備えている。＿init、＿fini、および
＿infoの各ルーチンは各モジュールに特有である。好適
に、図１２に示すように、＿init、＿fini、または＿in
foの各ルーチンは、パラメータとして伝えられたモジュ
ールのmodlinkage構造を用いて、モジュールサブシステ
ムルーチン、それぞれmod＿install、mod＿remove、お
よびmod＿info、を呼出す。

【００３２】構造modlfsはこのモジュールに対して規定
された連結構造である。構造modlfsはファイルシステム
に対するmod−ops、「modfsops」、を規定するが、これは
モジュールに対する＿init、＿fini、および＿infoの各
ルーチンを指すポインタを備えている。modlfsの次の要
素は、モジュールに関する情報に応答して表示されるフ
ァイルシステムの名称を指すポインタである。第３の要
素「 vfw」はモジュールがカーネルに伝えるハンドルを
介してvfssw 構造を識別する。

【００３３】ラッパーの次の二行はモジュールの連結構
造を規定するもので、システムの改訂、「mod−rev＿
１」および単一連結構造「modlfs」を識別する。ラッパ
ーの残りの要素にはモジュール特有のinit、fini、およ
びinfoの各ルーチンを指すポインタがある。

【００３４】図１３−１５は、Sun MicrosystemのUNIX
動作システムのもとで動作するSun Microsystems, Inc.
のSPARCstationワークステーションで動作するように
構成されている模範的文字ドライバである（SPARCstati
on はSPARC Internationalの登録商標である）。それ
故、本発明のシステムにより、モジュールが必要に応じ
てロードされ且つ設置される。これによりシステムに、
特に、小さい一般的組合わせのモジュールを利用するユ
ーザに必要なカーネル記憶装置の量が少なくなる。別モ
ジュールを使用するユーザに対しては、必要なものだけ
がロードされる。カーネル記憶装置の消費が減るのに加
えて、カーネルを再ブーツすることなく構成することが
でき、カーネルの再構成が非常に簡単になる。

【００３５】モジュールを設置すると、モジュールはそ
れが行うサービスにハンドルを伝える。モジュールが設
置されないと、モジュールはハンドルを伝えない。ドラ
イバモジュール要素がそれ自身を設置するとき伝えるハ
ンドルはそのdev＿ops構造を指すポインタである。好適
にも一般的ドライバルーチン、mod＿installdrv() およ
びmod＿removedrv()、が設けられていてドライバ特有の
設置および取外し（「uninstall」で）動作を実行しや
すくしている。

【００３６】mod＿installdrv() の機能はドライバモジ
ュールの要素をシステムに設置することである。これは
ドライバの主要番号に対応するdevopsp エントリをセッ
トしてドライバのdev＿ops構造を指すことにより行われ
る。ドライバの主要番号はドライバを備えているモジュ
ールが記憶媒体（すなわち、ハードディスク）に設置さ
れると割当てられる。mod＿removedrv()の機能はドライ
バモジュールの要素をシステムから取外すことである。
これはドライバの主要番号に対するdevopspエントリを
セットしてmov＿nodev＿ops構造（モジュールが設置さ
れていないことを示すのに使用される特殊アドレス）を
指し、dev＿info 構造のようなカーネルデータ構造から
ドライバへの参照を取除くことにより行われる。ドライ
バが取外し可能でなければ、mod＿removedry()はEBUSY
に戻る。

【００３７】ドライバの取外しルーチンがドライバに所
有されている dev＿infoノードに対して呼出されるとき
またはそのdev＿opsがシステムにより使用されるため保
持されているとき失敗すれば、ドライバは取外し不能で
ある。ドライバの取外しルーチンはDDI＿SUCCESSが戻す
責任がある値以外の値を戻す責任があり、ドライバは、
たとえば、それが開いている、またはドライバに対する
顕著な呼戻しが存在するという或る他の理由で多忙であ
る。

【００３８】実行システムモジュールがそれ自身を伝え
るハンドルはそのマジックナンバー、その実行機能を指
すポインタ、およびその中心機能（すなわち、execsw構
造の最初の三つのフィールド）を指すポインタである。
好適にも一般的実行ルーチン、 mod＿installexec()お
よびmod＿removeexec()、が設けられていて実行特有の
設置および取外しの動作を行いやすくしている。mod＿i
nstallexec()の機能は実行モジュール要素をシステムに
設置することである。これはexecsw表に利用可能なエン
トリを割り当て、そのエントリのexec＿magic、exec＿f
unc、およびexec＿coreの各フィールドをモジュール要
素のmodlexec 構造内で指示されるexecsw構造に入って
いるものにセットすることにより行われる。mod＿remov
eexec()の機能は実行モジュール要素をシステムから取
外すことである。これは割当てられたエントリのexec＿
magic、exec＿func、およびexec＿coreの各フィールド
をヌルにセットすることにより行われる。

【００３９】execの伝えられたハンドルへのアクセス
は、モジュール要素がそれが設置されるとき割当てるex
ecswエントリに読み書きをロックすることにより保護さ
れている。書込みロックはハンドルが伝えられていると
きまたは伝えられていないとき得られ、読取りロックは
モジュール要素のexec＿func()エントリおよびexec＿co
re()エントリに対する呼出し期間中保持される。それ故
execは対応するexecswエントリに入っているread＿writ
e ロックを書込みのため入れることができなければ取外
し不能である。

【００４０】ファイルシステムのシステムモジュールが
伝えるハンドルはその名称、vsw＿init()機能、vsw＿fl
ag、およびvfsops （すなわち、vfssw構造のフィール
ド）である。好適にも一般的ファイルシステムルーチ
ン、mod＿installfs()およびmod＿removefs()、が設け
られていてファイルシステム特有の設置および取外しの
動作を行いやすくしている。mod＿installfs()の機能は
ファイルシステムモジュール要素をシステムに設置する
ことである。これは骨組により割当てられているvfssw
表のエントリを探し、そのエントリの vsw＿init、vsw
＿vfsops、およびvsw＿flagの各フィールドをモジュー
ル要素の modlfs構造内で指示されているvfssw構造に入
っているものにセットすることによって行われる。 mod
＿removefs()の機能はファイルシステムモジュール要素
をシステムから取外すことである。これは割当てられた
vfsswエントリのvsw＿initおよびvsw＿vfsopsの各フィ
ールドをヌルにセットし、vsw＿flagフィールドを０に
セットすることにより行われる。

【００４１】すべてのファイルシステムの伝えられたハ
ンドルへのアクセスは一つの読み書きロックにより保護
されている。書込みロックはvfsswエントリを割当てる
間、vfsswエントリに書込む間、および mod＿removef
s()で取付けられたファイルシステムのリストをチェッ
クしてファイルシステムがアンロード可能か否かを判定
する間保持されている。読取りロックはvfsswおよびフ
ァイルシステムのvsw＿init()機能、vfs＿mount()機
能、vfs＿sysnc()機能、およびvfs＿unmount()機能の相
互呼出を探している間保持されている。それ故骨組は、
vsw＿init()機能、vfs＿mount()機能、vfs＿sync()機
能、およびvfs＿unmount()機能に活性の実行スレッドが
存在するときファイルシステムが取外されないように
し、ファイルシステムは、その他の場合使用中であると
きそれ自身が取外されないようにする。

【００４２】スケジューラモジュール要素が伝えるハン
ドルはそのクラス名、クラス初期設定機能、およびその
クラス機能（すなわち、クラス構造の最初の三つのフィ
ールド）である。好適にも一般的ルーチン、mod＿insta
llsched()およびmod＿removesched()が設けられてスケ
ジューラ特有の設置および取外しの動作を行いやすくし
ている。mod＿installsched() の機能はスケジューラモ
ジュール要素をシステムに設置することである。これは
エントリをスケジューラに対応するクラス表に設置し
（必要なら一つを割当てる）、cl＿init フィールドお
よびcl＿funcsフィールドをモジュール要素のmoldsched
構造により指されているクラス構造に入っているもの
にセットし、次いでdispinit()を呼出してクラスを初期
設定することにより行われる。cl＿nameおよびcl＿lock
の各フィールドはクラスエントリが割当てられると初期
設定される。mod＿removesched()の機能はスケジューラ
モジュール要素をシステムから取外すことである。これ
は割当てられたエントリのcl＿initフィールドおよびcl
＿funcs フィールドをヌルにセットすることにより行わ
れる。

【００４３】スケジューラの伝えられたハンドルへのア
クセスはスケジューラクラスについて割当てられた読み
書きロックにより保護されている。ロックはクラスエン
トリが割当てられるとき割当てられ、初期設定される。
ロックはmod＿installsched()およびmod＿removesche
d() によりクラスエントリを書込む間保持される。ロッ
クは読取り中も保持される。ストリームモジュール要素
が伝えるハンドルはそのストリームタブを指すポインタ
である。好適にも一般的ルーチンmod＿installstrmod()
およびmod＿removestrmod()が設けられていてストリー
ム特有の設置および取外しの動作を行いやすくしてい
る。

【００４４】mod＿installstrmod()の機能はストリーム
モジュール要素をシステムに設置することである。これ
はエントリをfmodsw表に割当てるかまたは既に割当てら
れているエントリをストリームモジュールに設置し、f
＿strフィールドおよびf＿flag フィールドをモジュー
ルのmodlstrmod構造により指されているfmodsw構造に入
っている値を用いて初期設定することにより行われる。
f＿nameおよびf＿lockの各フィールドはfmodswエントリ
が割当てられると初期設定される。mod＿removestrmo
d() の機能はストリームモジュール要素をシステムから
取外すことである。これは割当てられたfmodswエントリ
のf＿strフィールドをヌルにセットし、f＿flagフィー
ルドを０にセットすることにより行われる。

【００４５】ストリームの伝えられたハンドルへのアク
セスはfmodsw表エントリを読み書きロックすることによ
り保護されている。書込みロックはmod＿installstrmod
()およびmod＿removestrmod() によるエントリへの書込
み中保護される。読取りロックはストリームのqi＿open
() およびqi＿close()に対する呼出し期間中保持され
る。システムコールモジュール要素が伝えるハンドルは
機能を指すポインタである。好適にも一般的ルーチンmo
d＿installsys() およびmod＿removesys()がシステムコ
ールモジュール特有の設置および取外しの動作を行いや
すくするのに利用できる。

【００４６】mod＿installsys() の機能はシステムコー
ルモジュール要素をシステムに設置することである。こ
れはこのシステムコールに割当てられたsysentエントリ
を設置し、エントリのsy＿narg フィールドおよびsy＿c
allフィールドをそのmodlsys構造により指されたsysent
構造に入っているものに等しくセットすることにより行
われる。sysentエントリはブーツ時にシステムコールに
割当てられる。mod＿removesysの機能はシステムコール
モジュール要素をシステムから取外すことである。これ
は割当てられたシステムエントリのsy＿callフィールド
をnosys機能のアドレスに、sy＿nargフィールドの値を
０にセットすることにより行われる。

【００４７】システムコールの伝えられたハンドルへの
アクセスはシステムエントリの読み書きロックにより保
護されている。書込みロックはmod＿installsys()およ
びmod＿removesys() によるsysent構造への書込み期間
中保持され、読取りロックはsy＿call機能の呼出しの間
保持される。システムにこみ入った機能を設ける間カー
ネル記憶装置の使用を更に最適にするには、システムに
モジュールをアンロードするプロセスを設けるのが望ま
しい。モジュールを手操作でアンロードするような他の
方法を使用することができるが、下に説明するモジュー
ルを自動的にアンロードするという革新的システムを利
用するのが望ましい。

【００４８】更に多数のカーネル記憶装置を得たいとき
は、モジュールサブシステムを呼出してモジュールをア
ンロードする。多数の異なるルールを適用してカーネル
記憶装置を解放するのが所要に応じて必要になるときを
判定することができるが、別のモジュールをロードする
のに存在する記憶装置が不充分であるときはモジュール
をアンロードするのが望ましい。好適に、これは従来技
術に見られるカーネルページング機構（「スワッパ」と
言われる）を一部修正してモジュールサブシステムに現
在利用されていないモジュールを取外し、アンロードす
ることを知らせることにより行われる。モジュールサブ
システムの自動アンロードモジュールはロードされてい
る各モジュールにモジュールを取外してアンロードする
ことができるか否かを示すよう要求する。モジュールは
各モジュールのラッパーに設置されている機能、fini、
を呼出す。fini機能はその形式のモジュールに対する判
定基準を使用してモジュールの状態をチェックする。

【００４９】モジュールおよびシステム、すなわち、カ
ーネル、は共にモジュールをアンロードして取外すこと
ができるか否かを判定する。一般に、モジュールは使用
中でなければ取外し可能且つアンロード可能と言われ
る。特に、モジュールを設置すると、モジュールはそれ
が行うサービスにハンドルを伝える。モジュールを取外
すと、モジュールはハンドルを取戻す。したがって、シ
ステムはモジュールの動作にアクセスするため各モジュ
ールのハンドルにアクセスする。ハンドルがシステムに
よりアクセスされていれば、そのモジュールは使用中で
あって取外すことができない。他の判定基準がモジュー
ルの形式に応じて存在し得る。他に、腕木式信号機のよ
うなロック機構を採用してモジュールの使用の状態を特
に識別することができる。したがって、システムはロッ
クを発生するルーチン、ロックを解除するルーチン、お
よびロックの状態をチェックしてロックを解除すること
ができるか判定するルーチンを備えることになる。

【００５０】たとえば、モジュールがドライバであれ
ば、システムはどのドライバが開いているかのトラック
を確保している。ドライバが開いていれば、ドライバを
取外すことはできない。ドライバが開いていなければ、
ドライバをそれが取付けられている装置から取外すこと
ができるか判定するチェックが行われる。取外しルーチ
ンはUNIX動作システムで現在利用できる取付けルーチン
と反対の機能を行う。取外しルーチンを次にドライバが
現在取付けられているすべての装置に関して実行する。
装置がドライバを現在利用している場合に生ずることで
あるが、取外しルーチンのどれかが失敗すれば、そのド
ライバに対するすべての装置が取付けられたままにな
り、ドライバは取外し可能ではないとして区別される。

【００５１】モジュール表がカーネルに設けられるのが
好ましい。モジュール表は各モジュール、各モジュール
に関するロックの状態（すなわち、ロックされている、
ロックされていない）、およびモジュールの状態（たと
えば、ロードされている／アンロードされている／ロー
ディング中である、など）を区別する。このときモジュ
ール表に情報を保持したり、その情報にアクセスしたり
するサービスルーチンが設けられることになる。モジュ
ールが自動アンロードモジュールにモジュールを取外す
ことができることを示せば、自動アンロードモジュール
は適切な構造表エントリを無効にする。好適に、これは
モジュールの状態を決定するモジュールサブシステムに
より参照されるハンドルにヌル値または特別の値を入れ
ることにより行われる。次にアンロード機能が行われ、
これによりモジュールにより占有されている記憶装置が
再割当てされ、カーネル内の記憶空間が解放される。

【００５２】好ましくは構成表の対応するエントリはモ
ジュールがその取外し状態にある間割当てられたままに
なすることである。構成表に必要な記憶装置の量は比較
的極少であり、エントリの維持は表のエントリを割当て
から外したり割当てし直したりするステップを除くこと
によって可能な限り少なくなる。代わりの実施例では、
モジュールをロードしたりアンロードしたりする頻度を
可能な限り少なくするために２ステップ取外しプロセス
を採用している。取外してアンロードするのに利用でき
ると判定されているモジュールを最初に取外す。カーネ
ル記憶装置がそれに続いて必要なときは、なおロードさ
れてはいるが設置されていないモジュールをアンロード
してカーネルの空間を解放する。同様に、続いて、他の
モジュールを取外すが、カーネル記憶装置が必要な次回
のため、ロードしたままにしておく。モジュールを取外
すがロードしてあり、且つモジュールへのアクセスが必
要である場合には、設置プロセスを単に行うだけでモジ
ュールへのアクセスを行わせる。

【００５３】

【発明の効果】このプロセスで多数の長所が実現され
る。スラッシングは極少である。モジュールにアクセス
するのに必要な時間は、アンロード動作を必要なときだ
け行うので、極少になり、これにより時間を消費するロ
ード動作を行う頻度が極少になる。更に、２ステッププ
ロセスを、最少最近使用（ＬＲＵ）アルゴリズムのよう
な記憶装置取換えアルゴリズムを用いて採用し、ロード
／設置プロセスおよび取外し／アンロードプロセスの利
用を更に最適にすることができる。本発明を好適実施例
に関して説明してきたが、これまでの説明に照らして多
数の代案、修正案、変形、および使用法が当業者には明
らかであることが明白である。特に、モジュールを自動
ロードするシステムをここに説明したモジュールを自動
アンロードするシステムと共に、またはそれと無関係に
使用して、なおカーネル記憶装置使用法の利益を実現し
得ることが明らかである。

【図面の簡単な説明】

【図１】本発明の好適実施例におけるモジュールの状態
を示す図である。

【図２】カーネルを用いる本発明のモジュールサブシス
テムの相互作用を示すブロック図である。

【図３】モジュールサブシステムの構成要素を示すブロ
ック図である。

【図４】模範的なモジュール構成表の図である。

【図５】モジュールを動的にロードする本発明のプロセ
スを示す流れ図である。

【図６】スタブに対するプロセスの流れを示す。

【図７】スタブのデータ構造を示す。

【図８】データ構造を作るのに使用されるマクロを示
す。

【図９】データ構造を作るのに使用されるマクロを示
す。

【図１０】模範的連結構造を示す。

【図１１】異なる形式の連結構造を示す。

【図１２】ファイルシステムモジュールの模範的ラッパ
ーを示す。

【図１３】本発明のシステムに従って動作するよう構成
した模範的文字ドライバを示す。

【図１４】本発明のシステムに従って動作するよう構成
した模範的文字ドライバを示す。

【図１５】本発明のシステムに従って動作するよう構成
した模範的文字ドライバを示す。

【符号の説明】

１０ システムコールモジュール、 ２０ モジュール
サブシステム、３０ システムコール構成表システム、
３３ フィルムサブシステム、３５ プロセス制御シ
ステム、 ７０ 制御モジュール、７２ 実行時リンカ
ー、 ７４ 設置モジュール。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジョセフ・イー・プロヴィノ アメリカ合衆国 02138 マサチューセッ ツ州・ケンブリッジ・ウェンデル ストリ ート・29 (72)発明者 ウィリアム・エフ・ピットア アメリカ合衆国 02173 マサチューセッ ツ州・レキシントン・ブロジェット ロー ド・６

Claims (3)

【特許請求の範囲】
1. 【請求項１】 中央処理装置 (CPU)、記憶装置、および
   入出力装置のような資源から成るコンピュータシステム
   で、動的に構成された動作システムを動作させるシステ
   ムにおいて、 モジュールを動作システムの記憶装置にロードして設置
   するモジュールサブシステムを備えており、このモジュ
   ールサブシステムは、 モジュールにアクセスする要求を阻止し、モジュールが
   ロードされて設置されているか確認する制御モジュー
   ル、 モジュールがロードされ且つ設置されていなければ、 コンパイル済みモジュールコードのファイルを動作シス
   テムの記憶装置に複写する手段、 ロードされたモジュールと動作システムの記憶装置にロ
   ードされた他の手段との間の参照を行えるようにする連
   結手段、およびモジュールがロードされ且つ設置されて
   いることを示す設置手段、 を備えており、モジュールがアクセス用動作システムに
   ロードされ且つ設置され、制御が要求プロセスに戻され
   て正常処理を継続することを特徴とするシステム。
2. 【請求項２】 中央処理装置 (CPU)、記憶装置、および
   入出力装置等の資源から成るコンピュータシステムの、
   複数のモジュールからなり、処理を実行し且つ資源を利
   用する動作システムであって、モジュールを必要に応じ
   て動作システムの記憶装置にロードすることによりその
   動作システムを動的に構成する方法において、 モジュールにアクセスしようとするとき、 モジュールへのアクセスを阻止するステップと、 モジュールが動作システムに設置されているか判定する
   ステップとを有し、 モジュールが動作システムの記憶装置に設置されていな
   いとき、モジュールをロードするプロセスが、 モジュールコードを動作システムの記憶装置に複写する
   ステップと、 モジュールと動作システムの記憶装置にロードされてい
   るモジュールとの間のすべての参照を行えるようにする
   ステップと、 モジュールがロードされ設置されていることを示すモジ
   ュールを設置するステップとを有し、 ロードされたモジュールにアクセスすることができ、処
   理が継続することを特徴とする方法。
3. 【請求項３】 中央処理装置 (CPU)、記憶装置、および
   入出力装置のような資源から成るコンピュータシステム
   の、処理を実行し且つ資源を利用する複数のモジュール
   から成るカーネル記憶装置を備えている動作システム
   で、モジュールを必要に応じてカーネル記憶装置にロー
   ドする方法において、 各モジュールを目的コードフォーマットにコンパイルす
   るステップ、 モジュールを表すコンパイル済みファイルを格納するス
   テップ、 動作システムのモジュールを識別する少なくとも一つの
   モジュール構成表を設けるステップ、 アクセス要求がモジュールに対して行われ、モジュール
   構成表のエントリがアクセスされたとき、 モジュール構成表へのアクセスを阻止するステップ、 モジュール構成表のエントリを審査してモジュールがカ
   ーネルにロードされているか確認するステップ、 モジュール構成表がモジュールがカーネルにロードされ
   ていず設置されていないことを示せば、 モジュールを示すコンパイル済みファイルを読取るステ
   ップ、 ファイルの大きさを判定するステップ、 カーネル記憶装置のスペースをファイルに割当てるステ
   ップ、 ファイルをカーネル記憶装置に複写するステップ、 モジュールと先にカーネル記憶装置に設置されているモ
   ジュールとの間のすべての参照を行えるようにするステ
   ップ、 モジュールがカーネルに設置されていることを示すモジ
   ュール構成表を更新することによりモジュールを設置す
   るステップ、 とから構成され、処理を継続し、モジュールへのアクセ
   スを可能とすることを特徴とする方法。