JP2779587B2 - コンピュータシステムに用いる名前スペースの一部分を別の名前スペースの一部分として利用可能にするための装置及びその方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、概して、コンピュータ
システムに用いられる名前スペースに関し、詳しくはプ
ロセスごとの名前スペースに関する。

【０００２】

【従来の技術】コンピュータシステムでのプログラム実
行に利用可能な主体（エンティティ）の多くは、名前、
すなわち識別子を有する。この識別子は、アドレスでは
ないがそれにも拘らず、識別子が指定するエンティティ
に関してその所在位置を探索するプログラムにこの識別
子が用いられる。このコンピュータシステムのオペレー
ションシステムは、ユ−ザがエンティティに名前を付け
ること、名前とエンティティとの関係をたどること、及
びエンティティの所在位置をその名前によって探索する
こと、を可能にする構成要素を有する。

【０００３】ファイルは、このような名前付きエンティ
ティの例として一般に知られている。オペレーティング
システムのファイルシステム構成要素は、ユ−ザがファ
イルに文字列からなる名前（文字列名）を付けること、
及びこの文字列名を用いてファイルの所在位置を探索す
ること、を可能にするものである。ほかの名前付きエン
ティティとしては、端末又はプリンタのような装置（デ
バイス）がある。

【０００４】エンティティの所在位置を探索するために
プログラムが用いる名前のセットを「名前スペース」と
名付ける（この名前スペースにおいてプログラムが実行
される）。名前スペースの形成方法はオペレーティング
システムによって定められる。或る場合には、名前スペ
ースは平面状で、全ての名前が単一レベル内にある構造
を有する。別の場合には、名前スペースはオペレーティ
ングシステムによって階層構造に形成される。

【０００５】階層的構造の普通の形状はの１つは、単一
樹木形状である。この場合、名前スペースにおける名前
は全て、単一の根部（ルート部）を有する１本の樹木の
形に形成される。樹木の内部ノードにおける名前は、デ
ィレクトリを表し、葉部ノードにおける名前は、通常の
エンティティを表す。

【０００６】このような樹木においてエンティティ若し
くはディレクトリの所在位置を探索するために、このエ
ンティティ若しくはディレクトリの名前、及びこの樹木
のルート部とこのエンティティ若しくはディレクトリと
の間の全てのディレクトリの名前、又はこのエンティテ
ィ若しくはディレクトリの名前、及びプロセスのカレン
ト（現行）ディレクトリとこのエンティティ若しくはデ
ィレクトリとの間の全てのディレクトリの名前、がプロ
グラムによって指定される。エンティティの所在位置を
探索するために必要な名前の組み合せを、このエンティ
ティの「パス名」と名付ける。

【０００７】従来、名前スペースは概してシステムごと
のものであった。システム上で作動中のプログラムは、
そのシステム内の名前付きエンティティについてはどれ
でもその所在位置を特定することができた。このような
システムごとの名前スペースの一例として、周知のＵＮ
ＩＸオペレーティングシステムを実行するコンピュータ
によって与えられる名前スペースがある。

【０００８】ＵＮＩＸオペレーティングシステムによっ
て与えられるファイルは全て、単一樹木の形に形成さ
れ、システム内のどのファイルも、プログラムが樹木内
のそのファイルのパス名を指定することによってそのフ
ァイルの所在位置を特定することができる。この構造形
状の利点は、オペレーティングシステム又は他のユーテ
ィリティに対して実行可能なコ−ドのような、全てのプ
ログラムによって用いられるエンティティが、それらの
エンティティを名前スペース内の予め定められた場所に
置くことによって、全てのプログラムに利用可能になる
ことである。

【０００９】実際には、もしこれらの予め定められた場
所について同じ名前付け規則を２つのＵＮＩＸシステム
が共用する場合、一方のシステム上で実行できたプログ
ラムは、他方のシステムにおいても実行可能である。例
えば、ＵＮＩＸシステムにおいては、共通に用いられる
ユーティリティプログラムは大体に、パス名「／ｂｉ
ｎ」によってアクセス可能なディレクトリ内に置かれ
る。

【００１０】本来、コンピュータシステムは互いに独立
したエンティティであり、通信媒体によって接続するこ
とができたが、接続されたシステムは、単一システムを
形成してはいなかった。通信媒体が改善され、処理装置
及びメモリの価格が下がると、分散形システムが出現し
て来た。これらの分散形システムにおいては、処理装置
とディスプレイ装置とファイル記憶装置とのセットが通
信媒体によって接続されて単一システムを形成する。

【００１１】分散形システムの１つの利点は、システム
の大きさに論理的制約のないことである。現在の分散形
システムは一般に、相互に、そしてファイルサーバ、す
なわちファイルオペレーション専用の処理装置付きファ
イル記憶装置に、ローカルエリアネットワ−ク（ＬＡ
Ｎ）を介して接続される一組のワークステーション（ワ
ークステーションセット）からなるが、大きな会社、団
体におけるワークステーション、プロセッサ、ファイル
記憶装置、ディスプレイ装置、及びプリンタが単一の分
散形システムの一部を構成できないという理由はない。

【００１２】

【発明が解決しようとする課題】分散形システムの設計
における１つの問題は、どのようにして名前スペースを
定義するかである。例えばパイクほか（Pike et al.）
の米国特許出願第０７／７０２６５号（１９９１年５月
１７日出願）に述べられている分散形計算システムにお
いては、名前スペースはプロセスによって定義される。

【００１３】プロセスは、自身の独自の名前スペースを
持つことも、１つの名前スペースを別のプロセスと共用
することもできる。又プロセスは、名前スペース内の名
前の相互関係を再構成することにより、そしてサービス
（作業機能）から与えられるファイル樹木を名前スペー
スに加えることにより、その名前スペースを改変でき
る。

【００１４】上記パイクほかの米国特許出願の計算シス
テムにおける名前スペースの定義の難点は、第１のプロ
セスが第２のプロセスの名前スペースを自身の名前スペ
ースに組み込むことができないことである。その結果、
ワークステーション上で実行中のプロセスの名前スペー
スを、ワークステーションのユ−ザのために中央演算処
理装置（ＣＰＵ）上で実行中のプロセスの名前スペース
に組み込むようなオペレーションが、極めて煩雑であっ
た。

【００１５】

【課題を解決するための手段】上記の問題は、本発明の
技術を用いて１つの名前スペースの一部分を別の名前ス
ペースに組み込むことによって克服できる。すなわち、
本発明の技術による装置は、第１の名前スペースにおい
て作動して、この第１の名前スペースの一部分を第２の
名前スペースに送出して第２の名前スペースの一部分と
して利用可能にするための装置である。

【００１６】この装置は、上記第２の名前スペースにお
いて用いられるように上記第１の名前スペースの上記一
部分において１つの名前を用いて１つのオペレーション
を指定する、第１のオペレーション指定子、を受信する
ための手段と、上記オペレーションと同じオペレーショ
ンを指定し、且つ上記第１の名前スペースにおいて用い
られるように上記１つの名前を用いる、第２のオペレー
ション指定子、を上記第１のオペレーション指定子に応
答して作成するための解釈手段と、上記第２のオペレー
ション指定子に応答して、上記オペレーションを行うた
めの手段と、からなる。

【００１７】本発明に関する上記及びその他の目的並び
に利点は、添付図面を参照して下に述べる「詳細説明」
により、当業者に明瞭となろう。

【００１８】

【実施例】詳細説明 以下、本発明の一実施例について「詳細説明」を行う
が、まず実施例を組み込むオペレーティングシステムと
しての、「プラン９」オペレーティングシステムの概観
と、プラン９システムが或るプロセスに対する名前スペ
ースを形成する手法とについて説明する。

【００１９】その次に、１つのプロセスが別のプロセス
に名前スペースを送出する技術を詳細に述べ、最後に、
この技術を用いる２つのプラン９システムコール（シス
テム呼び出し）について述べる。又上記パイクほかの米
国特許出願から取った題材以外の題材に関連しての説明
を「送出ファイルサービス（ｅｘｐｏｒｔｓｆ）の概
観」及び図１４以降に述べる。（尚、説明及び添付図面
において使用される英字略号は、同一略号を大文字又は
小文字で表す場合があるが、いずれの場合もその意味は
互いに同じである。）

【００２０】プラン９オペレーティングシステムの概観（図７） プラン９オペレーティングシステム（以下、プラン９シ
ステム）は、種々のコンピュータ及びネットワ−ク上で
実現される汎用で多目的の移植可能分散形システムであ
る。

【００２１】プラン９システムは、サービス機能の種類
によって分割される。ＣＰＵ（中央演算処理装置）サー
バは、演算力を大形（過負荷ではない）マルチプロセッ
サに集中し、ファイルサーバは、記憶場所を提供し、端
末は、システムの各ユ−ザにウインドウシステム実行用
のビットマップ及びマウス付き専用コンピュータを提供
する。演算及びファイル記憶サービスの共用によって、
プログラマ・グループのメンバーに共同体意識が生ま
れ、コスト償却が可能となり、管理業務が集中化され、
したがって簡素化される。

【００２２】これらのシステム構成要素は、単一のプロ
トコルによって相互に通信を行う。このプロトコルは、
適切なネットワ−クによって提供される信頼性の高いデ
ータトランスポート層より上に構築され、各サービスを
ルート部付きファイル樹木として定義する。通常にはフ
ァイルとは考えられないようなサービスの場合でも、統
一設計により顕著且つ有益な簡素化が得られる。

【００２３】各プロセスは、ローカルファイル名前スペ
ースを有し、この名前スペースには、そのプロセスが用
いている全てのサービスへ、したがってこれらのサービ
スにおけるファイルへ付随させるための機構が含まれ
る。端末の最も重要な仕事の１つは、名前スペース内で
見られるサービスによって表されるような、システム全
体についてのそのユ−ザの、カスタマイズされた態様
（ビュー）をサポートすることである。

【００２４】システムを効果的に用いるためには、ＣＰ
Ｕサーバ、ファイルサーバ、及び端末が必要である。こ
の場合のシステムの目的は、部門的又はより大きいコン
ピュータセンタのレベルでのサービスの提供である。Ｃ
ＰＵサーバ及びファイルサーバは、大形の装置で、調整
電力を供給された空調付きの機械室に最適状態で収納さ
れる。

【００２５】以下の項目においては、プラン９システム
の基本的構成要素について述べ、名前スペース及びその
用法について説明する。又、通常と異なるサービスを数
例紹介して、プラン９システムの考えがどのようにして
種々の問題に適用できるかについて述べる。

【００２６】ＣＰＵサーバ いくつかのコンピュータが、プラン９システムに対する
ＣＰＵサービスを提供する。量産形ＣＰＵサーバとし
て、シリコングラフィックス社製のパワーシリーズ装置
が用いられ、これには４個の２５ＭＨｚ、ＭＩＰＳプロ
セッサ、１２８メガバイトのメモリ、ディスクなし、及
びファイルサーバへの２０メガバイト／秒の、折り返し
形、直接メモリアクセス（ＤＭＡ）接続線が設けられて
いる。

【００２７】このサーバには又、端末及び非プラン９シ
ステムに接続するためのデータキット及びイーサネット
制御装置を備えている。オペレーティングシステムから
は、「ｆｏｒｋ」システムコールと「ｅｘｅｃ」システ
ムコールとに基づくプロセスと、主として遠隔ファイル
サーバによって定められるファイルとの通常の態様が得
られる。ＣＰＵサーバとの接続が設立されると、ユ−ザ
は、通常の状態にみえる環境においてコマンド・インタ
プリタへコマンドの入力を開始できる。

【００２８】マルチプロセッサＣＰＵサーバは、いくつ
かの利点を有する。最も重要な点は、その負荷吸収能力
である。もし装置が飽和していない場合には（この状態
はマルチプロセッサについては経済的に可能である）、
通常、すぐに新たなプロセスを実行できるフリー状態の
プロセッサが存在する。これは、ファイルシステム上で
新ファイルを記憶する場合のフリーディスクブロックの
概念に似ている。

【００２９】この比較を更に拡大していえば、ファイル
システムがいっぱいになったときに新しいディスクを買
うように、システムが多忙（ビジー）のときは、システ
ム全体を交換したり重複させたりする必要がなく、マル
チプロセッサにプロセッサを追加すればよい。もちろ
ん、新しくＣＰＵサーバを追加して、ファイルサーバを
共用してもよい。

【００３０】ＣＰＵサーバは、コンパイレーション、テ
キスト処理、及びその他のアプリケーション処理を行
い、ローカル記憶装置は持たず、ＣＰＵサーバがアクセ
スする永続ファイルは全て遠隔サーバから与えられる。
実行中のプロセスの集成イメージ又はユ−ザプロセスに
よって与えられたサービスの集成イメージのような、名
前スペース内の非常駐部分は局部的に駐在するが、ＣＰ
Ｕサーバがリブート（ｒｅｂｏｏｔ）されると消滅す
る。プラン９ＣＰＵサーバは、通常の端末がタスクにつ
いて互換性を有するのと同様に、そのタスクである演算
について互換性を有する。

【００３１】ファイルサーバ プラン９ファイルサーバは、全ての永続ファイルを保持
する。ここに用いたサーバは、別のシリコングラフィッ
クス社製コンピュータで、２個のプロセッサ、６４メガ
バイトのメモリ、６００メガバイトの磁気ディスク、及
び３００ギガバイトのジュークボックス形の１回書き込
み光ディスク（ＷＯＲＭ）を備えている。本ファイルサ
ーバは、２０メガバイト／秒のＤＭＡリンクを経てプラ
ン９ＣＰＵサーバに、又通常のネットワ−クを経て端末
及び他の装置に、それぞれ接続される。

【００３２】本ファイルサーバは、顧客に対して例えば
ディスク、ブロック、又はファイルのアレイというより
はむしろ、１つのファイルシステムを提供する。各ファ
イルは、樹木の枝ごとにラベルを付ける、斜線で分けら
れた構成要素によって名付けされ、入出力（Ｉ／Ｏ）に
対してバイトレベルでアドレスされる。サーバ内でのフ
ァイルの所在場所は、顧客には見えない。

【００３３】真のファイルシステムは、ＷＯＲＭ上に駐
在し、磁気ディスク及びＲＡＭの２レベルキャッシュを
経てアクセスされる。最近使用されたファイルの内容
は、ＲＡＭに駐在し、高速リンク上をＤＭＡによって急
速にＣＰＵサーバへ送られる。これは、ローカルメモリ
ほどには速くないが、普通のディスクよりもはるかに速
い。

【００３４】磁気ディスクは、ＷＯＲＭに対してはキャ
ッシュとして作動すると同時に、ＲＡＭに対してはバッ
クアップ媒体として作用する。高速リンクを用いるの
で、顧客がデータをキャッシュメモリに保持する必要が
なく、代わりに、ファイルサーバは、顧客全てに対する
キャッシュメモリ処理を集中化し、分散形キャッシュの
問題を避けるようにしている。

【００３５】ファイルサーバは実際には、いくつかのフ
ァイルシステムを提供する。その１つである主ファイル
システムは、大抵の顧客に対してのファイルシステムと
して使用される。他のファイルシステムは、個々のアプ
リケーションに対する汎用性のより低いデータを扱う。
又、サービスの１つとして通常と異なる種類に属する
「バックアップシステム」がある。１日に１回、ファイ
ルサーバは、主ファイルシステム上の作業を凍結させて
同システム内のデータをＷＯＲＭに落とす。

【００３６】通常のファイルサービスはこれに影響され
ずに継続されるが、ファイルの変更は、要求に基づいて
形成される新たな階層に、「書き込み時コピー」機構を
用いて設定される。したがって、ファイル樹木は、２つ
の部分、すなわちダンプ時点においてシステムを表す読
み取り専用の部分と通常のサービスノード提供を継続す
る普通のシステムとに分割される。

【００３７】これら古いファイル樹木のルート部は、他
の読み取り専用システムの場合と全く同様にアクセスが
可能なファイルシステムにおけるディレクトリとして利
用可能である。例えば、１９９０年４月１日に存在した
状態におけるファイル「ｕｓｒ／ｒｏｂ／ｄｏｃ／ｐｌ
ａｎ９．ｍｓ」は、バックアップファイルシステムを経
て名前「１９９０／０４０１／ｕｓｒ／ｒｏｂ／ｄｏｃ
／ｐｌａｎ９．ｍｓ」によってアクセスできる。

【００３８】この機構があるため、バックアップシステ
ム内の特別ユーティリティによることなく、ファイルコ
ピー及び比較ルーチンのような従来のコマンドによっ
て、損失ファイルの回復及び比較が可能となる。更に、
バックアップシステムは、当初のファイルと同じファイ
ルサーバ及び同じ機構によって提供されるので、バック
アップシステムにおける可能化状態は主システムにおけ
る可能化状態と同一であり、又バックアップデータを用
いて機密保持状態を壊すことはできない。

【００３９】端末 プラン９システムの標準的な端末は、ノット（Ｇｎｏ
ｔ）端末と称される。ノット端末は、地元設計の装置で
数百台が製造されている。端末のハードウエアは、ディ
スクのないワークステーションに似ている。４又は８メ
ガバイトのメモリ、２５ＭＨｚの６８０２０プロセッ
サ、画素当り２ビットで１０２４×１０２４画素のディ
スプレイ、キーボード、及びマウスを有するが、外部記
憶装置及び拡張バスは備えていない。すなわち、これは
端末であってワークステーションではない。

【００４０】これらの端末は、２メガビット／秒のパケ
ット交換装置付き分散形ネットワ−クによってＣＰＵ及
びファイルサーバに接続される。その帯域幅はコンパイ
レーションのようなアプリケーションに対しては低い
が、端末の本来の目的であるウインドウシステム、すな
わちプラン９システムの他の部分に対する多重インタフ
ェ−ス、の提供には充分過ぎるほどである。

【００４１】ワークステーションと異なり、ノット端末
は、コンパイレーションを扱わない。これはＣＰＵサー
バが扱う。端末は、ＣＰＵサーバのオペレーティングシ
ステムであって単一でより小形のプロセッサ用にビット
マップグラフィックのサポートによって構成されたバー
ジョンのオペレーティングシステムを動かし、これを用
いてウインドウシステムやテキストエディタのようなプ
ログラムを実行する。ファイルは、端末のネットワ−ク
接続線を介して標準形のファイルサーバによって提供さ
れる。

【００４２】前の文字端末のように、ノット端末は全て
同等で、ローカルにもファイルサーバにも専用の記憶装
置は持たない。又、廉価であるため研究センタの各員が
１台を職場に又１台を自宅にと計２台を持つことができ
る。職場に設置してあるファイルと演算資源（リソー
ス）（ＣＰＵ等）を効果的に共用し維持することができ
るので、自宅のノット端末で作業する場合、職場におけ
るシステムと全く同じシステムを用いることが可能であ
る。

【００４３】ネットワ−ク プラン９システムにおいてはその構成要素に種々のネッ
トワ−クが接続されている。ＣＰＵサーバ及びファイル
サーバの間の通信伝達は、折り返しＤＭＡ制御装置を介
して行われる。これは、例えばコンピュータセンタの規
模又は部門レベルの演算資源の規模でしか実用にならな
い。より遠くはなれた装置は、イーサネット又はデータ
キットのような従来のネットワ−クによって接続され
る。端末又はＣＰＵサーバは、性能の面の考慮を除いて
はしなければ、遠隔ファイルサーバを完全な透過性（ト
ランスパレンシー）を有する状態で使用できる。

【００４４】データキットネットワ−クが例えば米国で
全国的ネットワ−クとして張り巡らされているのに対
し、プラン９システムは、大規模ネットワ−ク用に構成
される。コスト低減のため、ノット端末は、普通の電話
回線と１個のチップからなるインタフェ−スを用いる廉
価ネットワ−クを採用している（処理能力は約１２０キ
ロバイト／秒と、かなりなものである）。

【００４５】端末は通信を仲介するだけであるので（Ｃ
ＰＵサーバにファイルサーバへの接続を命令するが、接
続の結果として行われる通信には関与しない）、端末に
対する帯域幅が比較的低くてもシステムの全体性能には
影響しない。

【００４６】図７は、プラン９システムの構成要素とシ
ステム構成とを示す。プラン９システム７０１は、ファ
イルサーバ７０５、ＣＰＵ７０３、及びノット端末７１
１から構成される。ＣＰＵ７０３及びファイルサーバ７
０５のセット７１７とノット端末７１１のセット７１９
とは、全国規模長距離通信ネットワ−ク７１５によって
接続される。

【００４７】端末セット７１９内のノット端末７１１
は、ＬＡＮのような分散形ネットワ−ク７１３によって
接続され、又ＣＰＵ・ファイルサーバセット７１７内の
ＣＰＵ７０３とファイルサーバ７０５とは、高速ＤＭＡ
リンク７０９によって接続される。

【００４８】名前スペース プラン９システムには２種類の名前スペース、すなわち
ネットワ−ク上の種々のサーバの名前のグローバルスペ
ース、並びにプロセスに可視であるファイル及びサー
バ、のローカルスペース、がある。データキットに接続
された装置及びサービスの名前は階層的で、例えば、
「ｎｊ／ｍｈ／ａｓｔｒｏ／ｈｅｌｉｘ」と表され、そ
れぞれ地域、建物、部門、及び部門内の装置を概略的に
定義する略号である。

【００４９】ネットワ−クがその装置の名前付け（ネー
ミング）を行うので、グローバルネーミング問題をプラ
ン９システムが直接扱う必要はない。しかし、プラン９
システムの基本的オペレーションの１つは、プロセスご
とという基準でローカル名前スペースにネットワ−クサ
ービスを付随させることである。ローカル名前スペース
の、このきめの細かい制御は、カスタマイズ性、透過
性、及び異質性の問題を取り扱うために用いられる。

【００５０】プラン９システムのサービスと通信する際
のプロトコルは、ファイル志向であり、全てのサービス
は、それぞれ１つのファイルシステムを形成する必要が
ある。すなわち、ローカルか遠隔かを問わず、各サービ
スは、サーバの「名前スペース」と呼ばれる階層の形に
集成されたファイル状の目的体（オブジェクト）のセッ
トとして構成される。これはファイルサーバに対しては
自明の要件である。

【００５１】他のサービスの場合には、もう少し想像力
を働かす必要がある。例えば、印刷サービスにおいて
は、印刷すべきファイルをプロセスが１つのディレクト
リ内で作成することを考えてそのディレクトリの形でフ
ァイルシステムを形成することになる。他の例について
は以下の各項において述べる。当面は、ネットワ−クに
分散された通常のファイルサーバセットについて考える
こととする。

【００５２】ネットワ−ク内で、且つプラン９システム
自身の外部、において固有の機構を用いてプログラムが
プラン９システムのサービスを呼び出すと、プログラム
は、このサービスの名前スペースのルート部に接続され
る。プロトコルを用い、通常にはローカルオペレーティ
ングシステムによってファイル志向のシステム呼び出し
セットへ仲介されて、プログラムは、名前スペース内で
ファイルを開き、形成し、除去し、読み取り、書き込む
ことによってこのサービスにアクセスする。

【００５３】プラン９システムのユ−ザは、ネットワ−
ク上で利用可能なサービスのセットから、望む対象、す
なわち個人ファイルが駐在するファイルサーバ、多分デ
ータが保持されている他のサーバ、又はグループプロジ
ェクト用のソフトウエアが書き込まれている部門ファイ
ルサーバを選択する。これら種々のサービスの名前スペ
ースは集成されて、ユ−ザ自身の専用名前スペースに結
合される。この集成、結合は、サービスの名前スペース
をユ−ザの名前スペースに結合する作業を行う基本プラ
ン９システム扱い者によって行われる。

【００５４】ユ−ザの名前スペースは、用いられるサー
ビスのスペースの合体によって形成される。ローカル名
前スペースは、各ユ−ザに対するローカルオペレーティ
ングシステム、一般には端末、によって組み立てられ
る。名前スペースは、実際にはログイン時に組み立てら
れユ−ザのプロセス全てによって共用されるが、プロセ
スごとのレベルで修正可能である。

【００５５】システムにログインするために、ユ−ザ
は、端末に位置して、どのファイルサーバに接続すべき
かを命令する。端末はサーバを呼び出し、ユ−ザを認証
し（下記参照）、サーバからオペレーティングシステム
をロードする。そして、ユ−ザの個人ディレクトリ内の
「プロフィル」と称するファイルを読み取る。

【００５６】プロフィルは、どのサービスをデフォルト
で使用するか及びローカル名前スペースのどこにそれら
のサービスを付随させるか、を定義するコマンドを有す
る。例えば、主ファイルサーバについてはローカル名前
スペースのルート部「／」に付随させ、プロセスファイ
ルシステムについては、ディレクトリ「／ｐｒｏｃ」に
付随させる。その後、プロフィルは、一般にはウインド
ウシステムについての実行を開始する。

【００５７】ウインドウシステム内の各ウインドウにお
いては、コマンドをローカルに実行するために用いられ
るコマンド解釈ソフトウエアであるコマンド・インター
プリタが、プロフィルによって組み立てられた名前スペ
ース内で解釈されたファイル名前を使用して作動する。
コンパイレーションのような演算集中形アプリケーショ
ンに対しては、ユ−ザは、コマンドを実行するためのＣ
ＰＵサーバを自動的に又は名前によって選択するコマン
ド「ｃｐｕ」を実行する。

【００５８】ｃｐｕをタイプした後には、ユ−ザはコマ
ンド・インタープリタからの指示メッセ−ジ（プロンプ
ト）が可視状態となる。しかし、このコマンド・インタ
ープリタは、「ｃｐｕ」コマンド自身と同じ名前スペー
スというよりも同じカレントディレクトリにおいてＣＰ
Ｕサーバ上で作動している。端末は、名前スペースの記
述をＣＰＵサーバに送出（エクスポート）し、これから
ＣＰＵサーバは同一の名前スペースを組み立てる。

【００５９】したがって、端末によって組み立てられた
このシステムのカスタマイズされた態様は、ＣＰＵサー
バ上で可視の態様と同じである（可能な場合にはＣＰＵ
サーバが端末の介入を要する手法よりもむしろ高速リン
クを使用できるように、名前スペース自身よりも名前ス
ペースの記述が用いられる）。「ｃｐｕ」コマンドは、
その次に来るコマンドだけに作用し、利用可能なサービ
スにもそれらのサービスにどのようにアクセスするかに
も無関係である。

【００６０】プラン９システムにおいて利用可能なサー
ビスの種類は、サービスを見出すためのサービスも含め
て数が多いが、この設計手法の用法及び可能性を示すに
は、そのうちのいくつかについて述べれば足りる。

【００６１】プロセスファイルシステム ローカルサービスの一例はプロセスファイルシステムで
ある。これによって、ファイル志向インタフェ−スを経
ての実行プロセスの点検とデバッグが可能となる。

【００６２】プロセスのルート部は、取り決めに基づき
ディレクトリ「／ｐｒｏｃ」に付随する（プラン９シス
テムにおいては取り決めは重要で、名前スペースは成行
きに従って組み立てられるにしても、多くのプログラム
は、取り決めに合わせて特定の形式（フォーム）を持た
せるようにした名前を用いて構成されている。プログラ
ム「／ｂｉｎ／ｒｃ」（コマンド・インタープリタ）が
どのサーバから来るかは問題ではないが、それを必要と
するコマンドがアクセスできるような名前を持つ必要が
ある）。

【００６３】付随させた後には、ディレクトリ「／ｐｒ
ｏｃ」自身がシステム内の各ローカルプロセスについて
のサブディレクトリを有し、このサブディレクトリはこ
のプロセスの独自の数字識別子に等しい名前を有する
（遠隔ＣＰＵサーバ上で作動するプロセスも表示させる
ことができる。これについては下に述べる）。

【００６４】各サブディレクトリは、このプロセスのこ
の態様を実現するファイルセットを有する。例えば、
「／ｐｒｏｃ／７７／ｍｅｍ」は、プロセス番号７７の
仮想メモリのイメージを有する。プラン９システムの
「／ｐｒｏｃ」は、他のファイルを経て他の機能を実現
する。

【００６５】次に、各プロセスについて与えられるファ
イルのリストを示す。 ｍｅｍ−−−−−プロセスイメージの仮想メモリ。ファ
イルのオフセットは、プロセス内の仮想アドレスに対応
する。 ｃｔｌ−−−−−プロセスの制御挙動。このファイル
に、「書き込み」システムコールにより送られるメッセ
−ジは、プロセスに停止、終結、 実行
再開、等をさせる。

【００６６】ｔｅｘｔ−−−−このファイルからプロセ
スが生成されるそのファイル。これは一般に、目標プロ
セスの記号テーブルの点検を行うためにデバッグ用プロ
グラムによって用いられるが、名前を除く全ての点にお
いて、原（オリジナル）ファイルである。したがって、
コマンドインタープリタに「／ｐｒｏｃ／７７／ｔｅｘ
ｔ」とタイプすることによって、プログラムをあらため
て表示することが可能である。

【００６７】ｎｏｔｅ−−−−適切な許可を得ているプ
ロセスは、別のプロセスの「ｎｏｔｅ」ファイルに書き
込みを行い、プロセス相互間通信用の非同期メッセ−ジ
を別のプロセスに送ることができる。システムは又、例
えばゼロで割る等、プロセスが誤挙動をした場合に、こ
のファイルを用いてメッセ−ジを送る。

【００６８】ｓｔａｔｕｓ−−プロセスの状態について
の、固定フォーマットの、情報交換用米国標準コ−ド
（ＡＳＣＩＩ）による表記。プロセスが実行されたファ
イルの名前、消費したＣＰＵ時間、現在の状態、等を含
む。

【００６９】「ｓｔａｔｕｓ」ファイルは、システム機
能に対してファイルサーバモデルによって異質性及び移
植可能性をどのように扱うことができるかを示す。コマ
ンド「ｃａｔ／ｐｒｏｃ／＊／ｓｔａｔｕｓ」は、シス
テム内の全プロセスの状態を表す（読み取れるがやや不
体裁）。実は、プロセス状態コマンド「ｐｓ」は正に、
集められたＡＳＣＩＩテキストを再フォーマットしたも
のである。

【００７０】コマンド「ｐｓ」のソースは、１ページも
の長さで装置間で完全に移植可能である。たとえ「／ｐ
ｒｏｃ」がいくつかの異質装置についてのプロセスに対
するファイルを有する場合でも、同じ実現例が作動可能
である。

【００７１】ここで留意したいのは、「／ｐｒｏｃ」に
よって得られるサービスは種々あるが、ファイルとして
のプロセスの概念を曲げるものではないということであ
る。例えば、プロセスファイルを除去することによって
プロセスを終結しようとしても不可能である。又、プロ
セスファイルを新たに作成しても新しいプロセスを開始
することはできない。ファイルはプロセスの、実行状態
の態様を与えはするが、文字通りプロセスを代表して表
すものではない。サービスをファイルとして設計する際
に、この区別は重要である。

【００７２】ウインドウシステム プラン９システムにおいては、専用の独立形サーバと同
様にユ−ザプログラムによっても、ファイルサービスが
得られる。ウインドウシステムはこのようなプログラム
の一例である。プラン９システムの、通常と最も異なる
性質の１つは、ウインドウシステムがユ−ザレベルのフ
ァイルサーバとして実現されるということである。

【００７３】ウインドウシステムは、そのウインドウに
おいて作動中の顧客プロセスに、他のシステムの「／ｄ
ｅｖ／ｔｔｙ又はＣＯＮ」に類似のファイル「／ｄｅｖ
／ｃｏｎｓ」を提供する。ウインドウシステムがこのフ
ァイル上のＩ／Ｏ動作の全てを制御するので、各ウイン
ドウのプロセスグループが専用の「／ｄｅｖ／ｃｏｎ
ｓ」ファイルを見られるように構成できる。

【００７４】新しいウインドウが形成されると、ウイン
ドウシステムは、新しい「／ｄｅｖ／ｃｏｎｓ」ファイ
ルを割り当てて、この新しいファイルをこの新しい顧客
の新しい名前スペースに入れ、このウインドウにおいて
顧客プロセスを開始する。

【００７５】そして、このプロセスは、普通のファイル
オープン用システムコールを用いて標準的入出力チャン
ネルを「／ｄｅｖ／ｃｏｎｓ」ファイルに接続し、コマ
ンド・インタープリタを実行する。コマンド・インター
プリタがプロンプトをプリントすると、プロンプトは
「／ｄｅｖ／ｃｏｎｓ」ファイルに書き込まれるととも
に適切なウインドウに表示される。

【００７６】この構造を他のオペレーティングシステム
と比較することは有益である。大抵のオペレーティング
システムにおいては、プロセスに接続された端末に対す
る別名（エリアス）である「／ｄｅｖ／ｃｏｎｓ」に似
たファイルが与えられる。この特別ファイルを開くプロ
セスが、プロセスが作動中である端末に、この端末の正
確な名前を知らずにアクセスする。

【００７７】別名は、通常オペレーティングシステムに
おける特別な構成によって与えられるため、顧客プロセ
スがこのファイルを経てウインドウにアクセスできるこ
とをウインドウシステムが保証するのは困難である。こ
の難点は、問題を反転することによってプラン９システ
ムによって容易に取り扱うことができる。

【００７８】１つのウインドウにおける１組のプロセス
は、名前スペース、詳しくは「／ｄｅｖ／ｃｏｎｓ」を
共用する。したがって、「／ｄｅｖ／ｃｏｎｓ」を多重
化し且つテキストの入出力の全てがこのファイルを通る
ように強制することにより、ウインドウシステムが、こ
のファイルの予想される特性をシミュレートすることが
できる。

【００７９】ウインドウシステムは、Ｉ／Ｏ装置のディ
レクトリ「／ｄｅｖ」に通常に付随しているいくつかの
ファイルに対して作動する。これらのファイルは、ＡＳ
ＣＩＩのＩ／Ｏについてのポートである「ｃｏｎｓ」、
マウスの位置を報告するファイルである「ｍｏｕｓ
ｅ」、及びビットマップグラフィックスのプリミティブ
を実行するための書面メッセ−ジである「ｂｉｔｂｌ
ｔ」からなる。

【００８０】異なる「ｃｏｎｓ」ファイルは別個の顧客
の出力を別個のウインドウに保持するけれども、「ｍｏ
ｕｓｅ」ファイル及び「ｂｉｔｂｌｔ」ファイルは、種
々の顧客を互いに独立して保持するような仕方で、ウイ
ンドウシステムによって実現される。

【００８１】例えば、ウインドウ内の顧客プロセスが画
面を消去するメッセ−ジを「ｂｉｔｂｌｔ」ファイル宛
に書き込むと、ウインドウシステムは、そのウインドウ
だけを消去する。部分的に又は全体的に不明瞭なウイン
ドウに送られたグラフィックスは、全てウインドウシス
テムに専用のメモリにビットマップ層として保持され
る。顧客は互いに他の顧客については気付かない。

【００８２】ウインドウシステムは、ファイル及び名前
スペースのオペレーションで全くユ−ザレベルにおいて
実現されるので、このシステムは、繰り返して実行でき
る。すなわち、それ自身の顧客である。ウインドウシス
テムは、オペレーティングシステムによって与えられた
「／ｄｅｖ／ｃｏｎｓ」、「／ｄｅｖ／ｂｉｔｂｌｔ」
等のファイルを開くことにより機能し、顧客間にファイ
ルの機能性を再生し、多重化する。

【００８３】そのため、もしウインドウシステムのあら
ためての表示がウインドウにおいて実行される場合、ウ
インドウは通常に挙動し、その「／ｄｅｖ／ｃｏｎｓ」
及び他のファイルを、その顧客のために多重化する。こ
の繰り返しは、ウインドウにおける新しいウインドウシ
ステムのデバッギングに、又はＣＰＵサーバへの接続の
多重化に用いると有益である。

【００８４】ウインドウシステムはビットマップグラフ
ィックスコ−ドを持たない（そのグラフィックスオペレ
ーションは全てファイルに標準的メッセ−ジを書き込む
ことによって実行される）。したがって、ウインドウシ
ステムは、ＣＰＵサーバを含む、その名前スペースに
「／ｄｅｖ／ｂｉｔｂｌｔ」ファイルを有するどの装置
上でも作動させることができる。

【００８５】「ｃｐｕ」コマンド 「ｃｐｕ」コマンドは、全二重ネットワ−ク接続線を用
いて端末とＣＰＵサーバとを接続し、そこでセットアッ
ププロセスを実行する。端末プロセスとＣＰＵプロセス
とがユ−ザと名前スペースとについての情報を交換す
る。すると、端末駐在プロセスは、ユ−ザレベルのファ
イルサーバとなる。このファイルサーバは、端末の専用
ファイルをＣＰＵサーバから可視状態にする。本発明の
一実施例において、ＣＰＵサーバはユ−ザのプロフィル
を再実行することによって名前スペースを形成する。

【００８６】別の実施例においては、名前スペースは、
特別端末駐在サーバによって送出される。このサーバに
対しては、端末の名前スペースを復元するために、質問
を行うことができる。

【００８７】ＣＰＵプロセスは、名前スペースに対して
僅かな数の調整を施し、ローカル及び遠隔の両方のプロ
セスファイルシステムを「／ｐｒｏｃ」において可視状
態にしてから、コマンド・インタープリタの実行を開始
する。名前スペースに対するこれらの調整は、例えばＣ
ＰＵサーバ上の「／ｄｅｖ／ｃｏｎｓ」ファイルを端末
上のファイルと同じファイルにする調整である。

【００８８】コマンド・インタープリタは、その「／ｄ
ｅｖ／ｃｏｎｓ」ファイルからコマンドを読み取り、結
果を同「／ｄｅｖ／ｃｏｎｓ」ファイル上にプリントす
る。同「／ｄｅｖ／ｃｏｎｓ」ファイルは、端末プロセ
スを経て適切な（例えば端末上の）ウインドウに接続さ
れる。

【００８９】ビットマップエディタのようなグラフィッ
クスプログラムも、ＣＰＵサーバ上で実行される。その
理由は、これらプログラムの定義が全体的に、ＣＰＵサ
ーバにのために端末が取り扱うファイルへのＩ／Ｏに基
づくものだからである。ＣＰＵサーバへの接続及び戻り
の接続は、完全に透過性を有する。

【００９０】この接続は、異質性の問題を提起する。す
なわち、ＣＰＵサーバと端末とは、互いに異なる種類の
プロセッサで有り得るし、現システムにおいてはそうで
ある。ここには、２値データ、及び実行可能コ−ドとい
う２つの異なる問題がある。２値データは２つの仕方、
すなわち２値でないようにする仕方、又はデータのフォ
ーマットをバイトレベルで厳密に定義する仕方によって
扱うことができる。

【００９１】前者の例は、「／ｐｒｏｃ」内の「ｓｔａ
ｔｕｓ」ファイルである。これによって、プログラムが
遠隔プロセスの状態を、透過性状態及び移植可能状態下
で点検することが可能になる。別の例は、端末のオペレ
ーティングシステムによって与えられる「／ｄｅｖ／ｔ
ｉｍｅ」ファイルである。これは、秒数を固定フォーマ
ットのＡＳＣＩＩで表したものである。理由は、プログ
ラムの時間ベースの役をするエポックがタイムスタンプ
を必要とするためである。

【００９２】ＣＰＵサーバ上のプロセスは時間ベースを
端末から得て、これにより分散形クロックの問題を未然
に排除している。

【００９３】「／ｄｅｖ／ｂｉｔｂｌｔ」のようなＩ／
Ｏ集中形のファイルについては、ＡＳＣＩＩのオーバヘ
ッドを禁止できる。故に、プラン９システムにおいては
このようなファイルは、バイト順序が予め定義されてい
る２値フォーマット、及び順序について仮定しないファ
イル使用移植可能ライブラリにアクセスするプログラ
ム、を受け入れる。

【００９４】したがって、「／ｄｅｖ／ｂｉｔｂｌｔ」
ファイルは、単に端末からだけでなく、どの装置からで
も使用できる。この原理は、プラン９システム全体を通
して用いられる。例えば、コンパイラのオブジェクトフ
ァイルとライブラリとのフォーマットは、同様に定義さ
れる。これは、オブジェクトファイルが、オブジェクト
ファイルをコンパイルするＣＰＵの形式に無関係である
ことを意味する。

【００９５】実行可能な２値について異なるフォーマッ
トを有するということは、より困難な問題を提起する。
プラン９システムはこれを次のように解決する。すなわ
ち、実行可能な２値のディレクトリに、「／ｍｉｐｓ／
ｂｉｎ／６８０２０」等、適切に名前を付ける。そして
プログラムが、どのような種類のＣＰＵ上でそのプログ
ラムが作動しているかを、特別なサーバを介して確認す
る。

【００９６】具体的には、プログラム、詳しくは「ｃｐ
ｕ」コマンドが、適切なディレクトリを通常の名前「／
ｂｉｎ」に付随させる。これによって、プログラムが例
えば「／ｂｉｎ／ｒｃ」を作動させると、適切なファイ
ルが見出される。この解法はあまりスマートではない
が、実用的でよい効果が得られる。種々のオブジェクト
ファイル及びコンパイラは、独特のフォーマットとネー
ミングについての取り決めとを用いるので、少なくとも
１回「ｍａｋｅ」又は類似のプログラムによって自動化
すればクロスコンパイレーションが苦でなくなる。

【００９７】機密保護 プラン９システムは、秘密保持の問題を直接には扱わな
いが、プラン９システムの有する態様のいくつかは、こ
の問題と関係がある。ファイルサーバをＣＰＵサーバか
ら分離することで機密保持の可能性が高まる。ファイル
サーバはネットワ−クを介して標準プロトコルによって
のみアクセス可能な別個の装置であるので、ファイルの
みを取り扱い、プログラムを実行することはできない。

【００９８】機密保持問題の多くは、それを介して特典
を得ることが不可能なような、厳密に制御されたインタ
フェ−ス、を用いてＣＰＵサーバとファイルサーバとが
相互に通信することを単に観察することによって解決で
きる。

【００９９】もちろん、ある種の管理機能はファイルサ
ーバ上で行われなければならないが、これらの機能は、
コンソール（操作卓）上でのみアクセス可能であり、し
たがって物理的な機密保持を必要とする特別のコマンド
インタフェ−ス、を経てのみ利用可能である。

【０１００】その上、このインタフェ−スは、管理用に
のみ使用できる。例えば、バックアップ作成並びにファ
イルの形成及び削除はできるが、ファイル読み取りもフ
ァイル動作許可変更もできない。ファイルの所有者に対
してのみの読み取り許可を有するファイルの内容は、フ
ァイルサーバによって他のどのユ−ザにも、又管理者に
さえも漏らされることはない。

【０１０１】もちろん、この場合、ユ−ザが自分が誰か
をどのようにして証明するかの問題が残る。本発明の一
実施例においては、この証明は、データキットネットワ
−クそれ自身の上で簡単な立証マネジャーを用いて行わ
れる。したがって、ユ−ザが端末からログインすると、
ネットワ−クが、この端末からコールを行ったこのユ−
ザの正真性を保証する。ローカルネットワ−クにおける
信頼の必要性は、立証マネジャーをケルベロスに似たシ
ステムに置き換えることにより除去される。

【０１０２】プラン９サービスのアーキテクチャの概観（図１） 既に述べたように、プラン９サービスは、ファイルシス
テムとして実現される。すなわち、本サービスはプラン
９オペレーティングシステムをファイルセットとして有
するコンピュータ上で実行されるプロセスに発生する。
このプロセスは、本サービスによって与えられる「ファ
イル」上でファイル読み取りオペレーションを行うこと
によって本サービスからデータを得ることができ、「フ
ァイル」上でファイル書き込みオペレーションを行うこ
とによって本サービスにデータを与えることができる。

【０１０３】プロセスサービスによって与えられる「フ
ァイルシステム」に関して既に詳しく述べたように、本
サービスは、実際にファイルを維持する必要はなく、フ
ァイルオペレーションに対するプロセスからの要求に本
サービスがファイルを維持しているかのように応答しさ
えすればよい。例えば、プロセスが本サービスによって
維持される「ファイル」を読み取る場合、本サービス
は、「ファイル」を読み取るプロセスにデータを与える
必要がある。

【０１０４】図１は、プラン９サービスとプロセスとの
間の関係の概観を示す。サービスアーキテクチャ１０１
は、１つ以上のサービス１２３にアクセスするためにプ
ロセス１０２がどのようにファイルシステム１０９を用
いるかを示す。プロセス１０２は、ノット端末７１１
（図７）又はＣＰＵ７０３（図７）のいずれかの上で実
行される。本サービスは、プロセス１０２が実行中のプ
ロセッサにローカルに実現されるか、又はファイルサー
バ７０５（図７）のような遠隔の装置内に実現される。

【０１０５】図１に示すように、各サービス１２３は、
本サービスを使用するプロセッサ１０２に１つ以上のフ
ァイル樹木１２５を与える。ファイル樹木１２５は、デ
ータファイル１３１並びにディレクトリファイル１２７
及び１２９からなる。ディレクトリファイルは、ファイ
ルのリストを有するファイルである。ディレクトリファ
イルに記載されるファイルは、ディレクトリファイル又
はデータファイルである。

【０１０６】ファイル樹木１２５（ａ）から判るよう
に、データファイル、１３１のＢ、Ｃ及びＤは、ファイ
ル樹木の葉部であり、一方、ディレクトリファイル１２
９は樹木が枝別れする点を占める。樹木全体の基部には
単一ルートディレクトリファイル１２７がある。サービ
ス１２３内の各ファイルは、ファイル名を有する。本発
明の一実施例においては、ファイル名は、文字列であ
る。

【０１０７】プロセス１０２は、プラン９オペレーティ
ングシステムによって与えられたファイルシステム機能
へのコール（呼び出し）を行うことによってサービス１
２３内のファイルにアクセスする。機能には２つの主な
種類がある。

【０１０８】ファイルの所在場所を探索するファイル探
索機能（ＦＬ）１１３と、ファイル探索機能１１３によ
ってファイルの所在場所が見出された後にファイルにア
クセスするファイルアクセス機能（ＦＡ）１１１とがそ
れである。ファイル探索機能（ＦＬ）１１３へのコール
は、矢印１０７で表され、ファイルアクセス機能（Ｆ
Ａ）１１１へのコールは、矢印１０５で表される。

【０１０９】上記のように、プラン９プロセス１０２は
各々、それに付随する名前スペースを有する。プロセス
１０２の名前スペースは、サービス１２３によって与え
られたどのファイルにプロセス１０２がアクセスすれば
よいかを定める。本発明の一実施例におけるプロセス１
０２の名前スペースは、ファイル樹木１２５とこれらフ
ァイル樹木のサブ樹木との両方又は一方から組み立てら
れる単一のファイル樹木１１７から構成される。

【０１１０】したがって、ファイル探索機能１１３によ
って維持され使用される名前スペース１１５（ｏ）は、
プロセス１０２（ａ）に対する名前スペースである。図
１から判るように、プロセス１０２（ａ）の名前スペー
スは、サービス１２３（ａ）からのファイル樹木１２５
（ａ）とサービス１２３（ｋ）からのファイル樹木１２
５（ｋ）とを含むが、サービス１２３（ｂ）からのファ
イル樹木１２５（ｂ）は含まない。

【０１１１】ファイル樹木１１７（０）は、プロセス１
０２のファイル樹木１１７（ｏ）内のディレクトリファ
イル「Ｘ」をファイル樹木１２５（ａ）のルート部に等
しくし、且つ同じファイル樹木１１７（ｏ）内のディレ
クトリファイル「Ｙ」をファイル樹木１２５（ｋ）のル
ート部に等しくすることによって構築されている。
「Ｘ」及び「Ｙ」自身がどのようにして名前スペース１
１５（ｏ）内にあるようになったかについては、後に詳
しく述べる。

【０１１２】名前スペース１１５（ｏ）内では、ファイ
ルはパス名によって探索できる。パス名は、ファイル名
のリストで、探索すべきファイルの名前と、ファイル探
索がそこから行われているファイル樹木内の点からファ
イルまでの間の全てのディレクトリファイルの名前とを
含む。ファイル探索がそこから行われているファイル樹
木内の点を、「作業ディレクトリ」と称する。そして、
もし作業ディレクトリがディレクトリファイルＸである
場合、パス名は、Ａ／Ｃである。Ａ／Ｃ内の文字（キャ
ラクタ）「／」は、パス名内の名前を分離する作用を有
する。

【０１１３】更に、どのファイルも、その全パス名、す
なわちルートディレクトリを表すキャラクタ「／」と、
ルートディレクトリとファイルとの間の全てのディレク
トリの名前と、ファイルの名前とを指定することによっ
て、探索できる。ファイルの名前は、やはりキャラクタ
「／」によって分離される。したがって、名前スペース
１１５（ｏ）内のファイルＣに対する完全なパス名は、
「／Ｘ／Ａ／Ｃ」である。

【０１１４】プラン９においては、いくつかのプロセス
１０２が１つの名前スペースを共用する。１つの名前ス
ペースを共用するプロセス１０２は、プロセスグループ
１０３を形成する。そして、プロセスグループ１０３
（ｏ）内のプロセスは、ファイル樹木１１７（ｏ）によ
って定義される名前スペース１１５（ｏ）を共用し、又
プロセスグループ１０３（ｚ）内のプロセスは、名前ス
ペース１１５（ｚ）を共用する。

【０１１５】プラン９においては、プロセスは、「フォ
ーク」システムコールによって形成される。新たに形成
されたプロセス１０２は、「フォーク」システムコール
を行ったプロセスと同じ名前スペースに付随した状態に
留まり、したがって、「フォーク」システムコールを行
ったプロセス１０２と同じプロセスグループ１０３に属
する。

【０１１６】プロセス１０２が「フォークプロセスグル
ープ」システムコールを行うと、新しいプロセスグルー
プ１０３が設立される。このコールが伝送する主題項目
は、新しいプロセスグループがプロセス１０２の既存の
名前スペース１１５の複写（コピー）を受け取るべき
か、又は最小限のデフォルト名前スペース１１５を受け
取るべきかを表示するフラッグだけである。このシステ
ムコールの実行によって、このシステムコールを行って
いるプロセス１０２は新しいプロセスグループに置かれ
る。

【０１１７】この「フォークプロセスグループ」システ
ムコールによってプロセス１０２に対する新しい名前ス
ペース１１５が設立されると、新しい名前スペース１１
５における変更は、「フォークプロセスグループ」シス
テムコールを行っているプロセス１０２が前に属してい
たプロセスグループ１０３の既存の名前スペース１１５
には影響を与えない。

【０１１８】プロセスグループ１０３に属するどのプロ
セス１０２も、このプロセスグループについての名前ス
ペースを修正できる。そうするには、プロセスは２つの
名前スペース修正機能のうちの１つを用いる。これら２
つの機能のうちの第１の機能は「ｂｉｎｄ」（バイン
ド）（連結）で、これは既に名前スペースにある名前
を、新しいパス名によって指定されるファイルに等しく
する機能である。

【０１１９】例えば、名前スペース１１５（ｏ）におけ
る「ｂｉｎｄ」（「／Ｙ／Ｈ」、「／Ｘ／Ａ」）機能
は、名前スペース１１５（ｏ）においてそのルート部が
Ａであるサブ樹木を、この名前スペースにおいてそのル
ート部がＨであるサブ樹木に置き換えるために用いられ
る。「ｂｉｎｄ」機能実行後は、パス名「／Ｘ／Ａ／
Ｋ」は、サブ樹木ＨのファイルＫを意味する。

【０１２０】第２の名前スペース修正機能は、「ｍｏｕ
ｎｔ」（マウント）（搭載）で、これは既に名前スペー
スにある名前を、サービス１２３のルート部に等しくす
る機能である。後に更に詳しく述べるように、サービス
のルート部は、小さな整数であるファイル記述子によっ
て表される。すなわち、ファイル樹木１１７（ｏ）のデ
ィレクトリ名「Ｘ」は、「ｍｏｕｎｔ」機能（「Ｆ
Ｄ」、「／Ｘ」）によってサービス１２３（ａ）のファ
イル樹木１２５（ａ）のルート部に等しくされたもので
ある。「ｍｏｕｎｔ」機能実行後は、パス名「／Ｘ／
Ａ」は、ファイル樹木１２５（ａ）内のファイル「Ａ」
を意味する。

【０１２１】プラン９における「ｍｏｕｎｔ」及び「ｂ
ｉｎｄ」機能は、更に次のことができるように緻密に構
成される。すなわち、パス名とパス名との間、又はファ
イル記述子とパス名との間に３種類の関係を指定でき
る。それらのうちの第１の関係は置き換えである。もし
この関係が指定されると、既存の（旧の）名前によって
意味されるものが、新しい名前又はファイル記述子によ
って意味されるものに完全に置き換えられる。

【０１２２】第２及び第３の関係は、「結合ディレクト
リ」と称するものを設立する。結合ディレクトリが設立
されると、「ｂｉｎｄ」機能において用いられた既存の
名前と新しい名前とは両方共、ディレクトリファイルを
参照する必要があり、「ｍｏｕｎｔ」コマンド内の既存
の名前はディレクトリファイルを参照する必要がある
が、一方ファイル記述子は、サービス１２３におけるフ
ァイル樹木のルート部を参照する必要がある。

【０１２３】「ｂｉｎｄ」又は「ｍｏｕｎｔ」機能の効
果は、既存のディレクトリファイル及び新しいディレク
トリファイルにおけるファイルの結合である新しいディ
レクトリを設立することである。一方の関係（「前」）
は、新しいディレクトリが既存のディレクトリの前に探
索されるような結合ディレクトリを設立し、他方の関係
（「後」）は、新しいディレクトリが既存のディレクト
リの後に探索されるような結合ディレクトリを設立す
る。

【０１２４】すなわち、「ｂｉｎｄ」コマンド（「／Ｙ
／Ｈ」、「／Ｘ／Ａ」、「ＢＥＦＯＲＥ」）は、ファイ
ル「Ｉ」、「Ｊ」、「Ｋ」がファイル「Ｂ」、「Ｃ」に
先行するような結合ディレクトリを設立し、ファイル探
索機能１１３がパス名「／Ｘ／Ａ／Ｃ」に応答すると
き、これらの機能は最初にディレクトリＨ内を探索し、
次にディレクトリＡ内を探索する。

【０１２５】このように探索機能がファイルを求めてデ
ィレクトリ内を探索する順序を定めることにより、ＵＮ
ＩＸのようなオペレーティングシステムにおいて探索リ
ストによって得られるのと同じ種類の制御が、結合ディ
レクトリから得られる。

【０１２６】名前スペースを再編成する代わりにファイ
ルを探索するファイル探索機能１１３は、主題項目とし
てパス名をとり、これをファイル記述子を返す。この場
合、ファイル記述子は、ファイルを参照するためにファ
イルアクセス機能１１１において用いられる小さな整数
である。

【０１２７】ファイル探索機能１１３は、パス名によっ
て指定されるディレクトリファイルをプロセス１０２の
作業ディレクトリにする機能（「ｃｈｄｉｒ」機能）
と、パス名によって指定されるファイルを開く開設機能
（「ｏｐｅｎ」機能）とを有する。「ｃｈｄｉｒ」機能
及び「ｏｐｅｎ」機能は、作業ディレクトリファイルに
ついてのファイル記述子及び開かれたファイルについて
のファイル記述子を、それぞれ返す。

【０１２８】これに加えて、「ｃｒｅａｔｅ」（創設）
機能があり、この機能は、パス名において指定されたフ
ァイルがこの機能によって創設されること以外は、「ｏ
ｐｅｎ」機能と同じに作用する。

【０１２９】それからファイルアクセス機能１１１が、
ファイル探索機能によって与えられたファイル記述子を
用いて、ファイルの読み取り及び書き込み、ファイルの
状態のセット及び取得、並びにファイルの閉じの作業を
行う。

【０１３０】サービスアーキテクチャ１０１において、
ファイルシステム１０９は、プロセス１０２によって行
われたファイルアクセス機能コール１０５及びファイル
探索機能コール１０７をサービスファイルオペレーショ
ン要求に変換する。各サービスファイルオペレーション
要求は、そのファイル樹木１２５のうちの１本の樹木内
のファイル上でオペレーションを行うようにサービス１
２３に要求する。

【０１３１】ここでも、これらの要求には２つの種類が
ある。すなわち、矢印１１９によって表示されるサービ
スファイルアクセス要求と、矢印１２１によって表示さ
れるサービスファイル探索要求との２つである。

【０１３２】後に更に詳しく説明するように、或るサー
ビス１２３についての要求１１９及び１２１は、機能コ
ールの形式を取り、別のサービス１２３についての要求
は、ファイルプロトコルの形式を取る。機能コールの場
合には、ファイルはファイル名又はファイル記述子によ
って表され、ファイルプロトコルの場合には、ファイル
はファイル名又は「ファイル識別子」によって表され
る。以下の説明の目的のため、ファイル記述子及びファ
イル識別子を包括して「ファイル指定子」の用語を用い
ることとする。

【０１３３】ファイルシステム１０９において、プロセ
ス１０２によって用いられるファイル記述子には、サー
ビス１２３によって与えられるファイルハンドル「ｑｉ
ｄ」が付随する。この付随関係は、ファイル記述子をフ
ァイル識別しに付随させるか、又はファイル識別子をフ
ァイルハンドル「ｑｉｄ」に付随させるかの方法によ
り、直接又は間接付随となる。

【０１３４】プロセス１０２によって用いられるファイ
ル記述子とファイルハンドル「ｑｉｄ」との間に付随関
係があると、プロセス１０２は、ファイルハンドル「ｑ
ｉｄ」によって表されるファイルと接続関係にある、と
いわれる。同様に、サービス１２３において、ファイル
ハンドル「ｑｉｄ」が、１つ以上のファイル指定子に付
随する。

【０１３５】ファイルシステムコール１０５又は１０７
の結果として生じるサービスファイル要求が、与えられ
たファイルハンドル「ｑｉｄ」の付随するファイル指定
子を有する場合、ファイルオペレーションはファイルハ
ンドル「ｑｉｄ」によって識別されるファイル上で行わ
れる、という結果となる。

【０１３６】ファイルシステム１０９においては名前又
はファイル指定子によってファイルを表すがサービス１
２３においては名前又はファイルハンドル「ｑｉｄ」に
よってファイルを表すことの利点は、サービスが異なる
場合に、ファイル名とファイルハンドル「ｑｉｄ」との
間に異なる関係を設立できることである。例えば、上に
説明したプロセスサービスのような、いくつかのサービ
スにおいては、全てのプロセスによって用いられるファ
イル名は単一のファイルセットを参照するので有利であ
る。

【０１３７】後に詳しく説明する８.５ ウインドウサー
ビスのような、別のサービスにおいては、各プロセスに
よって用いられるファイル名は、このプロセスに独特の
ファイルセットを参照する。その結果、サービスアーキ
テクチャ１０１におけるファイル名は、Ｃ言語のような
プログラミング言語中の変数の特性に類似の特性を有す
る。

【０１３８】いくつかのファイル名は、グローバルな静
的変数名に似ている。すなわち、グローバルな静的変数
名が、その変数名が現れる全てのコ−ド内の同一メモリ
所在場所を参照するように、プロセスサービスによって
与えられるファイル名のようなファイル名は、全てのプ
ロセスにおいて同一ファイルを参照する。

【０１３９】他のファイル名は、ローカルな変数名に似
ている。すなわち、ローカルな変数名が、手順の呼び出
しごとに異なるメモリ所在場所を参照するように、８.
５ サーバによって与えられるファイル名のようなファ
イル名は、各プロセスにおいて異なるファイルを参照す
る。ファイル名がどの特性を有するかは、もちろん、フ
ァイルを与えるサービス１２３によって定められる。

【０１４０】変数に用いられる用語に類似して、サービ
ス１２３は、そのファイルの実例を与える、といわれ
る。すなわち、プロセスサービスはそのファイルの各々
の単一事例を与え、サービスによって与えられたファイ
ルのうちの１つのファイルと接続関係にあるプロセス１
０２は、そのファイルと接続関係にある他のプロセス１
０２の全てと同じファイルにアクセスを有する。

【０１４１】他方、ウインドウサービスは、ファイル樹
木のルート部との接続を設立する各プロセス１０２に、
そのファイル樹木内のファイルの別個の事例を与える。
ウインドウサービスによって与えられるファイルと接続
関係にあるプロセス１０２は、そのファイルの多数の事
例のうちの１つと接続関係にある。

【０１４２】各サービス１２３は、次のような種類のサ
ービスファイル探索要求１２１を扱うことができる。 ・「ａｔｔａｃｈ」：指定されたサービス１２３におけ
るファイル樹木のルート部についてのファイル指定子を
与えられて、ルート部についてのファイルハンドル「ｑ
ｉｄ」をファイルシステム１０９に返す。

【０１４３】・「ｗａｌｋ」（ウオーク）：与えられた
名前を有するファイルについてファイル指定子によって
指定されたディレクトリファイルを探し、もしそのファ
イルが見出された場合、ファイル指定子をそのファイル
についてのファイルハンドル「ｑｉｄ」に付随させ、フ
ァイルハンドル「ｑｉｄ」を返す。

【０１４４】・「ｃｒｅａｔｅ」：ファイル指定子によ
って指定されたディレクトリファイル内に新しいファイ
ルを「創設」し、ファイルに特定の名前を付け、ファイ
ル指定子を、新しいファイルについてのファイルハンド
ル「ｑｉｄ」に付随させ、ファイルハンドル「ｑｉｄ」
を返す。 ・「ｒｅｍｏｖｅ」：ファイル指定子によって指定され
たファイルをサーバから「除去」し、ファイル指定子を
ファイルハンドル「ｑｉｄ」との付随から外し、除去さ
れたファイルの名前を返す。

【０１４５】各サービス１２３は更に、次のような種類
のサービスファイルアクセス要求を扱うことができる。 ・「ｏｐｅｎ」：ファイル指定子によって指定されたフ
ァイルを、ファイルアクセスオペレーションのために
「用意」し、ファイル指定子の付随するファイルハンド
ル「ｑｉｄ」を返す。

【０１４６】・「ｃｌｏｎｅ」：ファイルを表す第１の
ファイル指定子と、まだファイルを表していない第２の
ファイル指定子とを与えられて、第１のファイル指定子
が付随するファイルに第２のファイル指定子を付随させ
る。 ・「ｒｅａｄ」：ファイル指定子と、このファイルにお
けるオフセットと、カウントとを与えられて、このオフ
セットで始まるこのカウントにおいて指定されるバイト
数を「読み取る」。

【０１４７】・「ｗｒｉｔｅ」：ファイル指定子と、こ
のファイルにおけるオフセットと、カウントと、データ
とを与えられて、このオフセットで始まるこのカウント
において指定されるバイト数にこのデータを「書き込
む」。 ・「ｃｌｕｎｋ」：ファイル指定子を与えられて、この
ファイル指定子とこのファイルとの間の付随関係を終了
させる。

【０１４８】・「ｓｔａｔ」：ファイル指定子と、ファ
イル状態情報を得るためにサービスによって必要とされ
る情報とを与えられて、ファイルの「状態」を返す。 ・「ｗｓａｔ」：ファイル指定子と、ファイル状態を変
更するためにサービスによって必要とされる情報とを与
えられて、ファイルの状態を変更する。

【０１４９】全てのサービス１２３が上記のオペレーシ
ョンを実現する必要があるが、いくつかの場合には、オ
ペレーションが無効であるか、又は誤り（エラー）が発
生する。例えば、もしサービス１２３がプリンタであ
り、したがって書き込み専用のファイルしか実現できな
い場合には、「ｒｅａｄ」オペレーション（読み取り）
を行うとエラーが発生する。

【０１５０】核サービス及びプロトコルサービス（図２） プラン９についての本発明の一実施例には、２種類のサ
ービス１２３が存在する。第１の種類は核サービスで、
これはファイルオペレーション要求２０５及び２０７が
プラン９の核機能へのコールによって実現されるような
サービスである。第２の種類はプロトコルサービスで、
これはファイルオペレーション要求２０５及び２０７が
プラン９のファイルプロトコルによって実現されるよう
なサービスである。

【０１５１】プロトコルサービスにおいては、各サービ
スファイルオペレーション要求は、プロセス１０２から
プロトコルサービスへ伝送される「ｔメッセ−ジ」によ
って起こされる。プロトコルサービスは、プロトコルサ
ービスからプロセスに返される情報を含む「ｒメッセ−
ジ」でｔメッセ−ジに応答する。プロトコルサービスに
対するサービスファイルオペレーション要求を構成する
ｔメッセ−ジ及びｒメッセ−ジを、「トランズアクショ
ン」と名付ける。

【０１５２】例えば、プロトコルサービスに対するサー
ビスファイル「ｒｅａｄ」（読み取り）オペレーション
要求は、次に示す「ｒｅａｄ」ｔメッセ−ジ（「ｔｒｅ
ａｄ」）及び「ｒｅａｄ」ｒメッセ−ジ（「ｒｒｅａ
ｄ」）からなる「ｒｅａｄ」トランズアクションであ
る。

【０１５３】「ｔｒｅａｄ」：タイプ指定子、ファイル
識別子、タグ、オフセット、及びカウント 「ｒｒｅａｄ」：タイプ指定子、ファイル識別子、タ
グ、カウント、及びデータ

【０１５４】ファイル識別子は、ファイルシステム１０
９内のファイル記述子と、ファイルシステム１０９内及
びプロトコルサービス内のファイルハンドル「ｑｉｄ」
と、に付随する。

【０１５５】「ｔｒｅａｄ」メッセ−ジは、メッセ−ジ
が「ｔｒｅａｄ」メッセ−ジであること、すなわちメッ
セ−ジのタイプ（種類）、を表示するタイプ指定子、フ
ァイル識別子、メッセ−ジを識別するタグ、ファイルに
おけるオフセット（そこから「ｒｅａｄ」が始まる）、
及びカウント（バイト数）からなる。「ｒｒｅａｄ」メ
ッセ−ジは、メッセ−ジが「ｒｒｅａｄ」メッセ−ジで
あることを表示するタイプ指定子、ファイル識別子、別
のタグ、実際に読み取られたバイト数のカウント、及び
データ自身からなる。

【０１５６】もし「ｒｅａｄ」（読み取り）オペレーシ
ョンの結果としてエラーが発生した場合、プロトコルサ
ービス２０９は、「ｒｒｅａｄ」メッセ−ジの代わりに
エラーメッセ−ジを返す。エラーメッセ−ジ（「ｒｅｒ
ｒｏｒ」）は、次に示す形式（フォーム）を有する。 「ｒｅｒｒｏｒ」：タイプ指定子、タグ、エラーメッセ
−ジ列

【０１５７】各プロトコルサービス２０９は、上記のサ
ービスファイルオペレーション要求の各々に対応するト
ランズアクションを行うことができる必要がある。これ
が、プロトコルサービス２０９に求められる要件の全て
であるので、プロトコルサービス２０９は、マウントサ
ービス２０３が実行されるプロセッサのアーキテクチャ
とは全く異なるアーキテクチャを有するプロセッサ上で
実現してもよい。プロトコルサービス２０９を使用する
ために求められる全要件は、プロトコルの送受信に使用
されるプロトコルサービス２０９への接続である。

【０１５８】更に、本発明の一実施例においては、プロ
トコルに含めて送られ返されるデータは、与えられたフ
ァイル樹木を提供する全てのプロトコルサービス２０９
によって用いられる予め定められたフォーマットを有す
る。したがって、プロセス１０２は、プロセス１０２を
実行中の装置のタイプ及びプロセスサービス２０９を実
行中の装置のタイプに関係なく、条件として与えられた
ファイル樹木を提供するプロセスサービスであれば、ど
のプロセスサービスを用いることもできる。

【０１５９】図２は、プロトコルサービスと、アーキテ
クチャ１０１のうちのその他の部分との間の関係を示
す。図示のように、プロトコルサービス（ＰＳ）２０９
は、上記のサービスファイル探索要求及びサービスファ
イルアクセス要求に対応するファイルプロトコルを用い
てファイル探索トランズアクション２０５とファイルア
クセストランズアクション２０７とを行う。

【０１６０】特別な核サービスであるマウントサービス
２０３が、サービスファイル探索要求を指定する機能コ
ール２１７、及びサービスファイルアクセス要求を指定
する機能コール２１９をファイルシステム１０９から受
信する。それからマウントサービス２０３は、機能コー
ルに応答して、プロトコルサービス２０９によって対応
するトランズアクションを行う。

【０１６１】トランズアクションを行うために、マウン
トサービス２０３は、いくつもの通信サービス２１５を
用いる。このような通信サービスには２つの種類、すな
わちネットワ−ク通信サービス（ＮＳ）２１４とプロセ
ス間通信サービス（ＩＰＳ）２１６とがある。

【０１６２】ネットワ−ク通信サービス２１４は、プロ
セス１０２を実行するＣＰＵにネットワ−クを介して接
続される遠隔プロトコルサーバ２１３と通信するために
ネットワ−クを用いる。プロセス間通信サービス２１６
は、ローカルプロトコルサーバ２１１と通信するために
プロセス間通信システムを用いる。

【０１６３】本発明の一実施例において、プロセス間通
信サービス２１６によって用いられるプロセス間通信シ
ステムは、ＵＮＩＸオペレーティングシステムにあるよ
うなパイプシステムである。通信サービス２１５がプロ
トコルサーバ２０９に接続されるときには、ファイル記
述子によって表される。「ｍｏｕｎｔ」システムコール
において用いられるのは、これらのファイル記述子であ
る。

【０１６４】図２においてネットワ−ク通信サービス２
１４に併記した括弧内符号に示すように、ネットワ−ク
通信サービス２１４は、図７の分散形ネットワ−ク７１
３、全国規模長距離通信ネットワ−ク７１５、及び高速
ＤＭＡリンク７０９を用いてもよい。又、遠隔プロトコ
ルサーバ２１３には、１つ以上のファイルサーバ７０５
を設けるようにしてもよい。

【０１６５】ローカルプロトコルサーバ２１１は、ノッ
ト端末７１１に対する８.５ サービスのような装置でよ
く、又与えられたプロセス１０２との間でプロセス間通
信施設によって通信する他のプロセス１０２でもよい。

【０１６６】上に述べたように、プロトコルサービス２
０９と、マウントサービス２０３のような核サービスと
の間の区別は、所在場所ではなく、単に、プロトコルサ
ービス２０９がマウントサービス２０３とトランズアク
ションを行うということだけである。

【０１６７】後に８.５ サービスについての説明で詳し
く述べるように、プロトコルサービス２０９のこの特性
の利点は、同じプロトコルサービス２０９を、ローカル
プロセッサ上で作動するプロセス１０２と、図７のＣＰ
Ｕ７０３のような遠隔プロセッサ上で作動するプロセス
１０２との両方で使用できることにある。

【０１６８】プラン９におけるファイルオペレーションの実現 以下、プラン９におけるファイルオペレーションの実現
について説明する。まず、ファイルを表すためとファイ
ルをプロセス１０２及びサービス１２３に関連付けるた
めとに用いられるデータ構造について述べ、続いて、プ
ロセスの名前スペース１１５を表すために用いられるデ
ータ構造について述べ、最後に、或る一般的なファイル
オペレーションの例について述べる。

【０１６９】プロセス１０２とファイルとの間の接続の
表示（図３〜図５） プロセス１０２との間に接続を有するファイルは、チャ
ンネルデータ構造で表される。ファイルについてのチャ
ンネルデータ構造は、最低限でも、ファイルを与えるサ
ービス１２３を指定し、ファイルを参照するためにプロ
セス１０２が用いるファイル記述子に、サービス１２３
によって与えられるファイルハンドル「ｑｉｄ」を付随
させる。

【０１７０】もしサービス１２３がプロトコルサービス
２０９である場合、チャンネルは更に、ファイルプロト
コル内及びファイルプロトコルに対するプロトコルチャ
ンネル内でファイルについて用いられるファイル識別子
をファイル記述子に付随させる。

【０１７１】図３は、チャンネルデータ構造の説明図で
ある。チャンネルデータ構造３０１は、次の構成要素を
有する。 ・「ＬＯＣＫ」３０３（ロック）：同時に複数のプロセ
スがチャンネル３０１にアクセスすることを禁じる。 ・「ＲＥＦ」３０７（参照カウント）：チャンネルが他
の核データ構造によって指し示されているかどうかを表
示する。

【０１７２】・「ＮＥＸＴ／ＯＦＦ」（ＮＥＸＴ／ＯＦ
ＦＳＥＴ）３０９（次／オフセット）：チャンネル３０
１が使用されていないときは、不使用チャンネル３０１
のリストに記憶され、その場合、「ＮＥＸＴ／ＯＦＦＳ
ＥＴ」フィールドは、次の不使用チャンネル３０１を指
し示す。チャンネル３０１によって表されるファイルが
アクセスされているときは、「ＮＥＸＴ／ＯＦＦ」フィ
ールドは、ファイル内への現オフセットを指定する。

【０１７３】・「ＫＳＩＮＦＯ」３１１（核サービス情
報）：チャンネル３０１によって表されるファイルを与
える核サービスを指定する情報を含む次の２個のフィー
ルドから構成される。 −「ＴＹＰＥ」３１３（タイプ）：このフィールドは、
チャンネル３０１によって表されるファイルにアクセス
するための核サービスを指定する。プロトコルサービス
２０９については、「ＴＹＰＥ」フィールド３１３は、
マウントサービス２０３を指定する。

【０１７４】−「ＤＥＶ」（ＤＥＶＩＣＥ）３１５（デ
バイス）：このフィールドは、核サービスによって表さ
れる特別なデバイスを指定する。マウントサービス２０
３の場合には、「ＤＥＶ」フィールド３１５は、チャン
ネル３０１によって表されるファイルを与えるプロトコ
ルサービス２０９を指定する。

【０１７５】・「ＡＩＮＦＯ」３１７（アクセス情
報）：ファイルアクセスを行うのに必要な情報を含む次
の３個のフィールドから構成される。 −「ＭＯＤＥ」３１９（モード）：チャンネルによって
表されるファイルにどのようにアクセスするかを表示す
る。 −「ＦＬＡＧ」３２１（フラッグ）：ファイルに関する
状態情報を含む。 −「ＱＩＤ」３２３：ファイルを与えるサービスがファ
イルに割り当てるファイルハンドル「ｑｉｄ」を表す。

【０１７６】・「ＭＩＮＦＯ」３２５（マウント情
報）：チャンネル３０１によって表されるファイルのパ
ス名に影響を与える「ｂｉｎｄ」及び「ｍｏｕｎｔ」に
関する情報をどこで見出せるかを表示する次の２個のフ
ィールドから構成される。 −「ＭＯＵＮＴ ＰＴＲ」３２７（マウントポイン
タ）：「ｂｉｎｄ」及び「ｍｏｕｎｔ」に関する情報が
見出されるデータ構造にを指し示すポインタである。 −「ＭＯＵＮＴ ＩＤ」３２９（マウント識別子）：
「ＭＯＵＮＴ ＰＴＲ」３２７によって指し示されるデ
ータ構造についての識別子である。

【０１７７】・「ＦＩＤ」３３１（ファイル識別子）：
このファイル識別子は、チャンネル３０１によって表さ
れるファイルを与えるプロトコルサービス２０９に対し
てマウントサービス２０３が与えるファイル識別子であ
り、且つファイルが接続されている間ファイルについて
のファイルハンドル「ｑｉｄ」に対してプロトコルサー
ビス２０９が付随させる、ファイル識別子である。本発
明の一実施例においては、「ＦＩＤ」３３１は、チャン
ネル３０１が形成されるときにチャンネルごとに独自の
値にセットされる。

【０１７８】・「ＡＵＸ」３３３（補助情報）：デバイ
スタイプ３１３によって意味の定まる情報である。 ・「ＰＳＩＮＦＯ」３３５（プロトコルサービス情
報）：チャンネルによって表されるファイルを与えるプ
ロトコルサービスにファイルプロトコルをどのようにし
て送るべきかを表示する次の２個のフィールドから構成
される。

【０１７９】−「ＰＣＨＡＮ」３３７（プロトコルチャ
ンネル）：現チャンネル構造によって表されるファイル
でのトランズアクションに用いられる通信サービス２１
５を表すチャンネル構造３０１を指し示すポインタであ
る。 −「ＭＱＩＤ」３３９：チャンネル３０１によって表さ
れるファイルを含むプロトコルサービスにおけるファイ
ル樹木のルートディレクトリのファイルハンドル「ｑｉ
ｄ」である。

【０１８０】各プロセス１０２は、そのプロセス１０２
が接続関係にあるファイルセットに付随する。ファイル
セットには、プロセス１０２の先代プロセスによって接
続関係が設立されたファイルであり且つ「ｆｏｒｋ」シ
ステムコールによってプロセス１０２が形成されたとき
に受け継がれたファイルを含み、又、プロセス１０２自
身によって接続関係が設立されたファイルを含む。

【０１８１】付随関係は、図４に示すデータ構造４０１
によって達成される。データ構造４０１は更に、ファイ
ルセット内の各ファイルを、プロセス１０２がそのファ
イルを参照するために用いるファイル記述子に付随させ
る。

【０１８２】データ構造４０１へのアクセスの始点は、
プロセス１０２についてのユ−ザデータ構造４０３であ
る。ユ−ザデータ構造４０３内のポインタ４１１が、フ
ァイル記述子アレイ（ＦＤＡ）４１３を指し示す。ファ
イル記述子アレイ４１３は、チャンネル４０１を指し示
すポインタ４２３のアレイで、ファイル記述子（ＦＤ）
４１７による索引が付けられている。

【０１８３】もしファイルがプロセス１０２に接続され
たファイルセットに属する場合、そのファイルについて
のファイル記述子に対応するアレイ４１３内のエントリ
（ＦＤＡＥ）４１５には、そのファイルについてのチャ
ンネル構造３０１を指し示すポインタ４２３が含まれ
る。このようなチャンネル構造を図４にファイルチャン
ネルデータ構造４１９として示す。更に、このようなフ
ァイルチャンネルデータ構造４１９からなるセット４２
１が、プロセス１０２が接続されるファイルセットに対
応する。

【０１８４】本発明の一実施例においては、ファイル記
述子アレイ４１３は、１００個の要素を有し、したがっ
て、各プロセス１０２は、最大１００個までのファイル
に接続されることになる。

【０１８５】前に述べたように、「ｂｉｎｄ」、「ｍｏ
ｕｎｔ」、「ｃｈｄｉｒ」、又は「ｏｐｅｎ」機能のよ
うなファイル探索機能は、パス名を主題項目として取
り、そのファイルについてのファイル記述子４１７を返
す。

【０１８６】下に更に詳しく述べるように、パス名解釈
の目的でのファイルチャンネルデータ構造４１９へのア
クセスは、プロセス１０２のファイル樹木のルート部に
ついてはファイルチャンネルデータ構造４１９へのユ−
ザデータ構造４０３内のポインタ４０７によって与えら
れ、プロセス１０２の作業ディレクトリについてはファ
イルチャンネルデータ構造４１９を指し示す別のポイン
タ４０９によって与えられる。

【０１８７】パス名解釈に用いられるユ−ザデータ構造
４０３には別のコンポネントとして要素（ＥＬＥＭ）４
０５があり、この要素には現に解釈作業下にあるパス名
を構成する名前リスト内の名前が含まれる。

【０１８８】ファイルチャンネルデータ構造４１９によ
って表されるファイルがプロトコルサービス２０９によ
って与えられると、ファイルチャンネルデータ構造４１
９は、通信サービスをかいしてのプロトコルサービス２
０９との接続を表すプロトコルチャンネルに 付随され
る。プロトコルチャンネルも又、チャンネル構造３０１
を用いて実現される。

【０１８９】プロトコルチャンネルとして作用するチャ
ンネル構造３０１において、「ＴＹＰＥ」フィールド３
１３は、プロセス間通信サービス２１６又はネットワ−
クサービス２１４（本発明の一実施例においては、パイ
プサービス又はデータキットネットワ−ク通信サービ
ス）のいずれかを指定する。フィールド３２７、３２
９、及び３３７は、プロトコルチャンネルにおいては意
味を持たない。

【０１９０】プロトコルチャンネルによって表される接
続がプロセス１０２によって開かれると、そのプロトコ
ルチャンネルを指し示すポインタが、プロセス１０２に
ついてのファイル記述子４１３内に置かれ、プロトコル
チャンネルが、対応するファイル記述子を受信する。パ
イプを形成するパイプシステムコールがプロセス１０２
によって実行されると、パイプによるローカルプロトコ
ルサービスへの接続が開かれる。

【０１９１】そして、ｓｒｖサービスにおける遠隔プロ
トコルサービス２０９を表すファイルが開かれると、デ
ータキット接続による遠隔のプロトコルサービス２０９
への接続が開かれる。

【０１９２】図５は、ファイルチャンネルデータ構造４
１９をプロトコルチャンネルと、「ｔメッセ−ジ」及び
「ｒメッセ−ジ」を表すデータ構造とに付随させるため
に本発明の一実施例において用いられるデータ構造５０
１を示す。前に述べたように、ファイルチャンネルデー
タ構造４１９内の「ＰＣＨＡＮ」フィールド３３７はプ
ロトコルチャンネル５１７を指し示し、これはチャンネ
ル構造３０１を用いて実現される。

【０１９３】「ｔメッセ−ジ」及び「ｒメッセ−ジ」を
表すデータ構造は、マウントサービスアレイ（ＭＮＴ
Ａ）５０２を用いて探索される。マウントサービスアレ
イ５０２内には、プロトコルサービス２０９によって与
えられるファイルを表す各ファイルチャンネルデータ構
造４１９についてのエントリ（ＭＮＴＥ）５０３が含ま
れる。

【０１９４】各エントリ５０３は、１個の識別子及び２
個のポインタを有し、これら２個のポインタは、エント
リ５０３に対応するファイルチャンネルデータ構造４１
９を指し示すポインタ及びマウントサービス待ち行列構
造（ＭＮＴＱ）５０９を指し示すポインタである。又、
ファイルチャンネルデータ構造４１９は、「ＤＥＶ」フ
ィールド３１５内の情報の一部分として、エントリ５０
３についての識別子を有する。

【０１９５】マウントサービス待ち行列構造５０９は、
３個のポインタを有する。第１は、ファイルチャンネル
データ構造４１９の属する手順を表すデータ構造を指し
示すポインタ５１１であり、第２は、プロトコルサービ
ス２０９と、ファイルチャンネルデータ構造４１９によ
って表されるファイルを含むファイル樹木１２５との接
続を表すプロトコルチャンネル５１７を指し示すポイン
タ５１５であり、そして第３は、メッセ−ジ待ち行列５
２０を指し示すポインタ５１９である。

【０１９６】待ち行列内のメッセ−ジは、もちろんプロ
トコルサービス２０９へのそのファイルに関する「ｔメ
ッセ−ジ」と、プロトコルサービス２０９からの「ｒメ
ッセ−ジ」である。マウントサービス待ち行列構造５０
９は、メッセ−ジ待ち行列をプロトコルチャンネル５１
７とプロセス１０２とに付随させる。

【０１９７】各メッセ−ジ５２０は、少なくとも１個の
マウントサービスヘッダ構造（ＭＮＴＨＤＲ）５２１か
らなる。ファイルチャンネルデータ構造４１９によって
表されるファイルとチャンネルとの組み合せについては
１個を超える数の未決着のメッセ−ジがあるので、マウ
ントサービスヘッダ構造５２１は、ファイルチャンネル
データ構造４１９によって表されるプロセスとファイル
との組み合せについての他のメッセ−ジに対するヘッダ
とヘッダ５２１とをつなぐポインタ５２７及び５２９を
有する。

【０１９８】マウントサービスヘッダ構造５２１は、更
に又、ファイルチャンネル４１９が属するプロセスにつ
いてのプロセスデータ構造を指し示すポインタ５２６を
有する。

【０１９９】もしメッセ−ジ５２０が「ｒメッセ−ジで
ある場合、メッセ−ジの、データ以外の部分は「ＲＨＤ
Ｒ」フィールド５２５に置かれる。メッセ−ジが「ｔメ
ッセ−ジ」の場合、メッセ−ジの、データ以外の部分は
「ＴＨＤＲ」フィールド５２３に置かれる。したがっ
て、これらのフィールドは、メッセ−ジのタイプ、マウ
ントサービス２０３がファイルに付随させたファイル識
別子、及びその他必要情報からなる。

【０２００】例えば、もしメッセ−ジが「ｔｗｒｉｔ
ｅ」メッセ−ジであると、「ＴＨＤＲ」フィールド５２
３は、メッセ−ジのタイプ、ファイルについてのファイ
ル識別子、書き込まれるべきバイト数、及び「ｗｒｉｔ
ｅ」機能が始まるオフセット位置からなる。更に、「Ｔ
ＨＤＲ」及び「ＲＨＤＲ」フィールドは、メッセ−ジに
入れて送信又は受信されたデータを有するマウントバッ
ファ５３３を指し示すポインタ５３１を有する。

【０２０１】メッセ−ジ５２０は、ファイルチャンネル
４１９に対応するエントリ５０３とマウントサービスヘ
ッダ構造５２１とを主題項目として取る機能により送信
される。この機能は、エントリ５０３を用いてプロトコ
ルチャンネル５１７を探索する。そして、マウントサー
ビスヘッダ構造５２１によって指定されるメッセ−ジ５
２０が、プロトコルチャンネル５１７によって指定され
る接続線に出力される。送信後、メッセ−ジを送ったプ
ロセス１０２は、応答を待つ。

【０２０２】応答が到着すると、メッセ−ジ５２０内に
おかれ、プロセスが注意喚起され、メッセ−ジ５２０が
プロセス１０２によって読み取られる。本発明の一実施
例においては、適切なマウントサービスヘッダデータ構
造５２１を探索するのに、メッセ−ジ内のタグが用いら
れる。

【０２０３】与えられたファイルチャンネルデータ構造
４１９に対するデータ構造５０１を探索する必要のある
プラン９内の機能は、与えられたファイルチャンネルデ
ータ構造４１９を指し示すポインタ５０５を有するエン
トリ５０３を見出すまでマウントサービスアレイ５０２
を通して作業することによって、この探索を行う。ファ
イルチャンネルデータ構造は、その「ＤＥＶ」フィール
ド３１５が、対応するエントリ５０３についての識別子
を有する、という事実によって識別が可能である。

【０２０４】上記の説明から明白なように、図３〜図５
に示すデータ構造によって、ファイルについてのファイ
ル記述子４１７を有するプロセス１０２が、ファイル上
での読み書きのようなファイルアクセス機能を行うこと
が可能となる。しかし、これらの機能には、ファイル記
述子のほかにパス名が関連するので、これらのデータ構
造は、ファイル探索機能を行うには十分ではない。

【０２０５】名前スペース１１５の表示（図６、図８、及び図９） 前に述べたように、新しいプロセス１０２の名前スペー
ス１１５は、プロセス１０２の親（先代）プロセスから
受け継がれたもの、又は先代の名前スペースを受け継が
ないプロセス１０２に対してプラン９によって利用可能
にされる名前スペース用の跡地（スタブ）スペース（ス
タブ名前スペース）から新しく形成されたもの、のいず
れかである。図６は、スタブ名前スペースからどのよう
にしてプロセス１０２の名前スペースが形成されるかを
概念的に示す。

【０２０６】図６のスタブファイル樹木６０１は、ルー
トディレクトリ６０３に単一レベルのファイルを与える
核サービスであるルートサービスによって与えられる。
ルートディレクトリ６０３及びファイル６０５〜６１５
は、他のサービス１２３に属する樹木１２５のルート部
がバインド（連結）される点としての役をするだけであ
る。本発明の一実施例においては、符号６０５〜６１５
のファイルセットは、サービスの種類を機能によって分
割する役をする。ファイル名は、機能に対して次のよう
に対応する。

【０２０７】・ファイル「ｄｅｖ」６０５は、サービス
がバインド（連結）される主な場所である。Ｉ／Ｏ（入
出力）機能を与えるサービス及び雑機能を有する他のサ
ービスは全て、ファイル「ｄｅｖ」６０５に連結され
る。 ・ファイル「ｂｏｏｔ」６０７は、プラン９が実行され
るＣＰＵをブートするサービスが連結される場所であ
る。

【０２０８】・ファイル「ｆｄ」６０９は、プロセス
の、接続されたファイルについての複製ファイル記述子
を与えるサービスが連結される場所である。 ・ファイル「ｐｒｏｃ」６１０は、プラン９プロセスに
ついての情報を与えるサービスが連結される場所であ
る。 ・ファイル「ｅｎｖ」６１１は、プロセス１０２につい
ての環境ファイルを与えるサービスが連結される場所で
ある。これらの環境ファイルは、ＵＮＩＸ環境変数と同
じ機能を行う。

【０２０９】・ファイル「ｂｉｎ」６１３は、プロセス
１０２によって実行されるプログラムのファイルを含む
サービスが連結される場所である。 ・ファイル「ｓｒｖ」６１５は、プログラム１０２に利
用可能なプロトコルサービス２０９についてプロトコル
チャンネル５１７を表すファイルを与えるサービスが連
結される場所である。

【０２１０】プラン９によって、スタブファイル樹木６
０１内のファイル名に連結可能なビルトイン・サービス
のセットが得られる。これらサービスのうちのいくつか
は、プロセス１０２によって実行されるプラン９核機能
にだけ連結される。他のサービスは、プロセス１０２に
よって実行されるどの機能に連結してもよい。プラン９
のパス名においては、ビルトイン・サービスの名前に
は、前に「＃」記号が付く。

【０２１１】核機能にだけ連結されるビルトイン・サー
ビスは、次の通りである。 ・「＃／」：スタブファイル樹木６０１を与える核ルー
トサービス。 ・「＃」：プロセス間通信についてのＵＮＩＸ形のパイ
プを与える核パイプサービス。 ・「＃Ｍ」：プロトコルサービス２０９とのトランズア
クションを扱うマウントサービス６０３。 核は、ルートサービスを、プロセス１０２の名前スペー
スのルート部に連結する。

【０２１２】プロセス１０２によって実行されるどの機
能に連結してもよいビルトイン・サービスは、以下の通
りである。 ・「＃ｂ」：ブートサービス。このサービスは、ファイ
ルに書き込みが行われたときに、核をして、与えられた
アドレスに分岐させるようにするファイル、を有する。
これによって、核が仮想メモリ内の与えられた場所に書
き込みを行うことが可能になる。ブートサービスは、概
してファイル「ｂｏｏｔ」６０７に連結される。

【０２１３】・「＃ｂ」：ビットサービス。このサービ
スは、ビットマップスクリーン及びマウスを表すファイ
ルを有する。ビットサービスは、概してファイル「ｄｅ
ｖ」６０５に連結される。 ・「＃ｃ」：コンソール・サービス。このサービスは、
システムコンソール（操作卓）を表すファイルを有す
る。コンソール・サービスは、概してファイル「ｄｅ
ｖ」６０５に連結される。

【０２１４】・「＃ｄ」：複製サービス。このサービス
によって与えられるファイルは、プロセス１０２に属す
る接続されたファイルについてのファイル記述子である
名前を有する。複製サービスは、概してファイル「ｆ
ｄ」６０９に連結される。 ・「＃ｅ」：環境サービス。このサービスによって与え
られるファイルは、概してファイル「ｅｎｖ」６１１に
連結される。

【０２１５】・「＃ｋｎａｍｅ」：データキットサービ
ス。このサービスによって与えられるファイルは、「ｎ
ａｍｅ」によって表されるデータキットハードウエア上
の会話を表す。このサービスは、概してファイル「ｄｅ
ｖ」に連結される。 ・「＃ｐ」：全体概観において述べたプロセスサービ
ス。概してファイル「ｐｒｏｃ」６１０に連結される。

【０２１６】・「＃ｓ」：サービス登録サービス。この
サービスによって与えられたファイルは、プロトコルサ
ービス２０９に接続された既に開かれているプロトコル
チャンネル５１７を表す。

【０２１７】本発明の、プラン９についての一実施例に
おいては、その名前スペース１１５を受け継いでいない
プロセス１０２がノット端末７１１上で実行開始すると
きに、ノット端末７１１上で実行されるプラン９核機能
が、バインド（連結）オペレーションを行い、これによ
って、樹木６１７として図示されるフォームが、名前ス
ペース１１５に与えられる。

【０２１８】もし樹木内の名前にサービスが連結されて
いた場合、その事実は、「＝」の後にそのサービスの名
前を付けて表示される。もし連結オペレーションが結合
ディレクトリを形成した場合、その事実は、結合ディレ
クトリの構成要素を括弧内にリストとして列記したもの
を「＝」の後に付けて表示される。この列記リストは、
構成要素が探索される順に作成される。ファイル樹木６
１７は、次に示す一連の「ｂｉｎｄ」（連結）及び「ｍ
ｏｕｎｔ」（マウント）オペレーションによって形成さ
れる。

【０２１９】・「ｂｉｎｄ（「＃／」、「／」、ＭＲＥ
ＰＬ）」。これは、ルートサービスによって与えられる
樹木を、プロセス１０２によって解釈されたパス名内の
ルート部を表す「／」に連結する。「／」への参照は、
「／」６０３への参照として解釈される。

【０２２０】・「ｍｏｕｎｔ（ＦＤ、「／」、ＭＡＦＴ
ＥＲ）」。これは、マウントサービス２０３に属するプ
ロトコルチャンネル５１７を「／」上にマウントし、こ
れによって、ルートサービスのルート部及びプロトコル
チャンネル５１７によって表されるプロトコルサービス
２０９のルート部からアクセス可能なファイルからなる
結合ディレクトリを形成する。プラン９においては、プ
ロトコルサービス２０９が、デフォルトファイルサーバ
７０５においてデフォルトファイル樹木１２５を与え
る。

【０２２１】・「ｂｉｎｄ（「／６８０２０／ｂｉ
ｎ」、「／ｂｉｎ」、ＭＲＥＰＬ）」。これは、そのル
ート部がデフォルト樹木１２５内のディレクトリ「／６
８０２０／ｂｉｎ」であるような樹木を、スタブ名前ス
ペース（スタブファイル樹木）内の名前「ｂｉｎ」６１
３に連結する。ディレクトリ「／６８０２０／ｂｉｎ」
はノット端末７１１について実行可能なコ−ドを有す
る。本発明の一実施例においてはノット端末７１１はモ
トローラ６８０２０マイクロプロセッサを有する。

【０２２２】・「ｂｉｎｄ（「／ｌｉｂ／ｒｃ」、「／
ｂｉｎ」、ＭＡＦＴＥＲ）」。これは、そのルート部が
デフォルト樹木１２５内のディレクトリ「／ｌｉｂ／ｒ
ｃ」である樹木を、名前「ｂｉｎ」６１３に連結する。
「／６８０２０／ｂｉｎ」が既に「ｂｉｎ」６１３に連
結されており、ＭＡＦＴＥＲも指定されているので、結
果は、ディレクトリ「／６８０２０／ｂｉｎ」がディレ
クトリ「／ｌｉｂ／ｒｃ」より前に探索されるような結
合ディレクトリである。

【０２２３】・「ｂｉｎｄ（「＃ｃ」、「／ｄｅｖ」、
ＭＲＥＰＬ）」。これは、コンソールサービス「＃ｃ」
によって与えられる樹木を、名前「ｄｅｖ」６０５に連
結する。 ・「ｂｉｎｄ（「＃ｄ」、「／ｆｄ」、ＭＲＥＰ
Ｌ）」。これは、複製サービス「＃ｄ」によって与えら
れる樹木を、スタブファイル樹木６０１内の名前「ｆ
ｄ」に連結する。

【０２２４】これらの連結の結果として、プロセス１０
２は、パス名「／ｂｉｎ／ｃｃ」によって、「＃Ｍ１」
が接続されている接続先のプロトコルサービス２０９の
ディレクトリ「／６８０２０／ｂｉｎ」内の「ｃｃ」と
呼ばれるファイルを参照できるし、又パス名「／ｂｉｎ
／ｐｗｄ」によって、同じプロトコルサービス２０９の
「／ｌｉｂ／ｒｃ」内の「ｐｗｄ」と呼ばれるファイル
を参照できる。但し、もちろんこれは、もしディレクト
リ「／６８０２０／ｂｉｎ」内にファイル「ｐｗｄ」が
存在しなければ、ということを前提とする。

【０２２５】同様に、サービス「＃ｃ」によって与えら
れるファイル「ｐｉｄ」は、パス名「／ｄｅｖ／ｐｉ
ｄ」によって参照でき、サービス「＃ｄ」によって与え
られるファイル「０」は、パス名「／ｆｄ／０」によっ
て参照できる。

【０２２６】上記から明らかなように、プラン９プロセ
ス１０２についての名前スペース１１５は、名前スペー
ス１１５内の名前に対して行われた全ての「ｂｉｎｄ」
及び「ｍｏｕｎｔ」オペレーションの記録を含んでいな
ければならない。この記録を「マウントテーブル」と名
付ける。本発明の一実施例のマウントテーブルは、ファ
イルについてのファイルチャンネルデータ構造４１９が
そのファイルについてのパス名を暗に表す、という事実
を利用している。

【０２２７】このことから、「ｂｉｎｄ」および「ｍｏ
ｕｎｔ」オペレーションの記録は、次に示すファイルチ
ャンネルデータ構造間の関係を設立することによって作
成できる。

【０２２８】すなわち、「ｂｉｎｄ」オペレーション又
は「ｍｏｕｎｔ」オペレーションにおいて用いられた旧
パス名によって表されるファイルを表すファイルチャン
ネルデータ構造４１９と、「ｂｉｎｄ」オペレーション
において用いられた新しいパス名によって指定されるフ
ァイルを表すファイルチャンネルデータ構造４１９、又
は「ｍｏｕｎｔ」オペレーションにおいて用いられたフ
ァイル記述子に対応するファイルチャンネルデータ構造
４１９との間の関係である。

【０２２９】もちろん、これらのファイルチャンネルデ
ータ構造４１９は全て、現プロセスグループ１０３がそ
の名前をそこから受け継いでいる元のプロセスグループ
１０３内のどれかのプロセス１０２に接続されているフ
ァイル、又は、現プロセスグループ１０３内のどれかの
プロセス１０２によって接続されているファイルを表
す。

【０２３０】図８は、本発明の一実施例において実現さ
れたマウントテーブル（ＭＴ）８０１の一部分を示す。
マウントテーブル８０１の構成要素は、マウントテーブ
ルアレイ８０６から探索され、マウントテーブルアレイ
８０６は、ユ−ザデータ構造４０３から探索される。図
８に示すように、ユ−ザデータ構造４０３は、プロセス
データ構造（ＰＲＯＣ）８２５を指し示すポインタ８２
４を有する。

【０２３１】各プロセス１０２は、ユ−ザデータ構造４
０３とプロセスデータ構造８２５とを有する。ユ−ザデ
ータ構造４０３のポインタ８２４は、プロセス１０２の
プロセスデータ構造を指し示す。プロセスデータ構造８
２５は、更に又、マウントサービス待ち行列構造５０９
内のポインタ５１１によっても指し示され、又自分自身
プロセスグループデータ構造（ＰＲＧＲＰ）８２７を指
し示すポインタを有する。

【０２３２】プロセスグループデータ構造８２７は、プ
ロセス１０２が属するプロセスグループ１０３を表す。
そして、プロセスグループデータ構造８２７は、マウン
トテーブルアレイ８０６を指し示すポインタ８２９を有
し、以上により、ユ−ザデータ構造４０３が属するプロ
セス１０２についてのマウントテーブル８０１の探索が
可能となる。

【０２３３】マウントテーブルアレイ８０６は、新しい
パス名又はファイル記述子が連結される連結先の旧パス
名についてのエントリ（ＭＴＥ）８０３を有する。与え
られたマウントテーブルエントリ８０３は、２個のポイ
ンタを有する。そのうちのポインタ８０５は、旧パス名
によって指定されるファイルを表すファイルチャンネル
データ構造４１９を指し示すポインタである。マウント
テーブル８０１内の位置関係において左側にある、これ
らファイルチャンネルデータ構造４１９を左チャンネル
（ＬＣＨＡＮ）８０２と名付ける。

【０２３４】マウントテーブルエントリ８０３の他方の
ポインタ８０７は、マウント構造８０９を指し示すポイ
ンタである。各マウント構造８０９は、１つの「ｂｉｎ
ｄ」又は「ｍｏｕｎｔ」オペレーションの結果を表す。
マウント構造８０９の内容は、下記からなる。 ・「参照」フィールド８１１。これは、マウントテーブ
ルエントリ８０３によって指し示されているチャンネル
以外の左チャンネルがマウント構造を使用中かどうかを
表示する。

【０２３５】・「終結」フィールド８１３。これは、マ
ウント構造８０９が結合ディレクトリを定義するマウン
ト構造８０９のリスト内で最後のマウント構造かどうか
を表示する。 ・「ＭＯＵＮＴ ＩＤ」（マウント識別子）フィールド
８１５。これは、このマウント構造８０９についての、
したがってマウント構造８０９によって表される「ｂｉ
ｎｄ」又は「ｍｏｕｎｔ」オペレーションの結果につい
ての、独自の識別子である。

【０２３６】・「ポインタ」８１７。もしマウント構造
８０９が結合ディレクトリを定義するマウント構造８０
９のリストの一部分であり且つこのリスト上の最後のマ
ウント構造データはない場合、ポインタ８１７は、リス
ト上の次のマウント構造を指し示す。

【０２３７】・「ポインタ」８１９。このポインタは、
新しいパス名によって（又は、「ｍｏｕｎｔ」の場合に
は、ファイル記述子によって）識別されるファイルを表
すファイルチャンネルデータ構造４１９を指し示す。マ
ウントテーブル８０１内の位置関係において右側にあ
る、これらファイルチャンネルデータ構造４１９を右チ
ャンネル（ＲＣＨＡＮ）８０４と名付ける。

【０２３８】上記から判るように、各マウントテーブル
エントリ８０３は、１つの左チャンネル８０２と１つ以
上の右チャンネル８０４との間の関係を設立する。

【０２３９】これに加えて、「ｍｏｕｎｔ」又は「ｂｉ
ｎｄ」オペレーションが理由でパス名の意味が変更され
たファイルを表すファイルチャンネルデータ構造４１９
においては、「ＭＯＵＮＴ ＰＴＲ」（マウントポイン
タ）フィールド３２７は、「ｍｏｕｎｔ」又は「ｂｉｎ
ｄ」オペレーションを表すマウント構造８０９を指し示
し、「ＭＯＵＮＴ ＩＤ」（マウント識別子）フィール
ド３２９は、そのマウント構造８０９についてのマウン
トＩＤ（マウント識別子）８１５を有する。

【０２４０】更に、プロトコルサービス２０９によって
与えられるファイルを表すファイルチャンネルデータ構
造４１９は、そのファイルを与えるプロトコルサービス
２０９への接続のため、プロトコルチャンネル５１７を
指し示すポインタ８２３をプロトコルチャンネルフィー
ルド３３７に有する。

【０２４１】図８は又、どのようにして「ｍｏｕｎｔ」
及び「ｂｉｎｄ」機能の「置換」、「前」及び「後」オ
プションの実現が、マウントテーブル８０１によって許
されるかを示す。

【０２４２】「置換」オプションの場合、新しいパス名
を表す右チャンネル８０４を指し示すマウント構造８０
９が、マウント構造８０９のリストを置換する。「前」
オプションの場合は、マウント構造８０９のリストの先
頭にそのマウント構造８０９が追加される。もしマウン
ト構造８０９のリストがない場合は、エラーとなる。
「後」オプションでは、マウント構造８０９がマウント
構造のリストの末尾に追加される。ここでも、リストが
ない場合にはエラーとなる。

【０２４３】結合ディレクトリが探索される場合には、
探索は、リスト中の第１のマウント構造８０９によって
指し示される右チャンネル８０４によって表されるディ
レクトリから始まる。次に探索されるディレクトリは、
リスト中の第２のマウント構造８０９によって指し示さ
れる右チャンネル８０４によって表されるディレクトリ
であり、以下も同様である。

【０２４４】したがって、もし左チャンネル８０２
（ａ）がパス名「／Ｍ」を表し、右チャンネル８０４
（ａ）が「／Ｍ」に連結された第１のサービス１２３か
らの第１ルートディレクトリを表し、右チャンネル８０
４（ｂ）が「／Ｍ」に連結された第２のサービス１２３
からの第２ルートディレクトリを表す場合、「ｃｈｄｉ
ｒ（「／Ｍ／」）」のようなファイル探索機能において
は、「Ｏ」の探索を最初に第１のルートディレクトリに
おいて行い、もしそこで見出されない場合には第２のル
ートディレクトリにおいて探索することになる。

【０２４５】前に述べたように、プロセス１０２が「フ
ォークグループ」システムコールを実行するときにはい
つも、プロセス１０２についての新しい名スペース１５
が形成される。「フォークグループ」システムコール
は、単一の主題項目を取る。

【０２４６】もし主題項目が「０」以外の値を取る場
合、「フォークグループ」システムコールを実行中のプ
ロセス１０２についての現存の名前スペースは、新しい
名前スペース１１５へはコピーすべきではない。もし主
題項目が「０」の値を取る場合、「フォークグループ」
システムコールを実行中のプロセス１０２についての現
存の名前スペースは、新しい名前スペース１１５へはコ
ピーすべきである。

【０２４７】「フォークグループ」システムコールが非
「０」主題項目で実行される場合、「フォークグルー
プ」システムコールは、単に新しいプロセスグループ構
造８２７とプロセス１０２についての新しいマウントテ
ーブルアレイ８０６とを形成する。それから、マウント
テーブルエントリ８０３が、新しい名前スペース１１５
を定義する「ｂｉｎｄ」及び「ｍｏｕｎｔ」オペレーシ
ョンについての必要に合わせて形成される。

【０２４８】もし「フォークグループ」システムコール
が「０」主題項目で実行される場合、「フォークグルー
プ」システムコールを実行するプロセス１０２について
のマウントテーブルアレイ８０６内のマウントテーブル
アレイエントリ８０３は、新しいマウントテーブルアレ
イ８０６内へコピーされる。

【０２４９】これがすむと、与えられたマウントテーブ
ルアレイエントリ８０３によって指し示される各左チャ
ンネル８０２内の「ＲＥＦ」（参照カウント）フィール
ド３０７と、そのエントリによって指し示される各マウ
ント構造８０９内の「ＲＥＦ」（参照）フィールド８１
１とが、増値される。

【０２５０】上記から判るように、本発明の一実施例に
おけるマウントテーブル８０１の実現により、プロセス
についての新しい名前スペース１１５形成が、比較的効
率のよい廉価なオペレーションとなる。

【０２５１】図９は、ファイル樹木６１７（図６）につ
いてのマウントテーブル９０１の全体を示す。図中、チ
ャンネルデータ構造３０１は、長手の矩形で表される。
チャンネルデータ構造３０１上のラベルは、チャンネル
データ構造３０１によって表されるファイルのパス名を
表示する。第１のマウントテーブルアレイエントリ８０
３（ｂ）は、ルート部「／」における「ｂｉｎｄ」及び
「ｍｏｕｎｔ」オペレーションの結果を記録する。

【０２５２】ルート部「／」を表す左チャンネル８０２
（ｂ）は、マウントテーブルアレイエントリ８０３
（ｂ）及び２つのマウント構造８０９（ｃ）、８０９
（ｄ）を介して２つの右チャンネルに接続される。これ
ら２つの右チャンネルのうちの１つは８０４（ｃ）で、
核ルートサービスによって与えられるファイル樹木のル
ート部についてのものであり、他の１つは「＃Ｍ１」が
接続されるプロトコルサービス２０９によって与えられ
るファイル樹木のルート部についてのものである。

【０２５３】右チャンネル８０４（ｄ）内のプロトコル
チャンネル・ポインタ３３７は、ルート部への接続を表
すプロトコルチャンネル５１７を指し示す。

【０２５４】第２のマウントテーブルアレイエントリ８
０３（ｃ）は、左チャンネル８０２（ｃ）によって表さ
れる「＃／ｂｉｎ」における「ｂｉｎｄ」オペレーショ
ンの結果を記録する。左チャンネル８０２（ｃ）は、
「＃Ｍ１／６８０２０／ｂｉｎ」を表す８０４（ｅ）
と、「＃Ｍ１／ｌｉｂ／ｒｃ」を表す８０４（ｆ）との
２つの右チャンネルに接続される。

【０２５５】右チャンネル８０４（ｅ）及び８０４
（ｆ）によって表されるファイルは、「＃Ｍ１」が接続
されるプロトコルサービス２０９によって与えられるの
で、これらの右チャンネルはいずれも、プロトコルサー
ビス２０９への接続を与えるプロトコルチャンネル５１
７を指し示すプロトコルチャンネル・ポインタ３３７を
有する。

【０２５６】更に、左チャンネル８０２（ｃ）によって
表されるファイルのパス名「＃／ｂｉｎ」は、パス名
「＃／」を含む。そのディレクトリファイルは、左チャ
ンネル８０４（ｃ）によって表される。したがって、左
チャンネル８０２（ｃ）の「ＭＯＵＮＴ ＰＴＲ」（マ
ウントポインタ）フィールド３２７は、マウント構造８
０９（ｃ）を指し示すポインタを有し、マウント構造８
０９（ｃ）は、右チャンネル８０４（ｃ）を指し示すポ
インタを有する。

【０２５７】マウントテーブル９０１の残りの部分から
判るように、右チャンネル８０４によって表される構成
要素を含むパス名を表すマウントテーブル９０１内の各
ファイルチャンネルは、その構成要素を表すその右チャ
ンネル８０４を指し示すマウント構造８０９に対して
「ＭＯＵＮＴ ＰＴＲ」（マウントポインタ）フィール
ド３２７内のポインタを有する。

【０２５８】すなわち、左チャンネル８０２（ｃ）、８
０２（ｄ）、及び８０２（ｅ）は、全てが、「＃／」を
含むパス名でファイルを表し、全てがマウント構造８０
９（ｃ）を指し示す。一方、右チャンネル８０４（ｅ）
及び８０４（ｆ）は、両方共、「＃Ｍ１」を含むパス名
でファイルを表し、マウント構造８０９（ｄ）を指し示
す。

【０２５９】もちろん、「ＭＯＵＮＴ ＰＴＲ」（マウ
ントポインタ）フィールド３２７がマウント構造８０９
を指し示す場合、チャンネルデータ構造３０１内の「Ｍ
ＯＵＮＴ ＩＤ」（マウント識別子）フィールド３２９
は、マウント構造８０９についてのマウント識別子にセ
ットされる。

【０２６０】残りのマウントテーブルアレイエントリ８
０３（ｄ）及び８０３（ｅ）は、ビルトイン核サービス
の「ｂｉｎｄ」オペレーションの結果を、核ルートサー
ビス「＃／」によって与えられるスタブファイル樹木の
ディレクトリ（スタブディレクトリ）の「ｄｅｖ」及び
「ｆｄ」に記録する。

【０２６１】これらの場合、各マウントテーブルアレイ
エントリ８０３は、スタブディレクトリを表す左チャン
ネル８０２をビルトイン核サービスを表す右チャンネル
８０４に関連付ける。ビルトイン核サービスは、プロト
コルサービスではないので、右チャンネルは、プロトコ
ルチャンネル５１７に対するポインタを持たない。

【０２６２】名前スペース１１５におけるパス名の解
（図１０及び図１１） 既に指摘したように、マウントテーブル８０１は、プラ
ン９のファイルチャンネルデータ構造４１９が各々、フ
ァイルチャンネルデータ構造４１９によって表されるフ
ァイルのパス名を暗に表す、という事実を利用してい
る。

【０２６３】プラン９オペレーティングシステムが、
「ｂｉｎｄ」、「ｍｏｕｎｔ」、「ｃｈｄｉｒ」、又は
「ｏｐｅｎ」のようなファイル探索機能においてパス名
を呈示される場合、パス名は、パス名によって指定され
るファイルを表すファイルチャンネルデータ構造４１９
を得ることと、ファイルチャンネルデータ構造４１９を
指し示すポインタを返すこととによって解が得られる。

【０２６４】プロセス１０２のファイル樹木１１７はサ
ービス１２３によって表されるファイル樹木から構成さ
れるので、パス名の解にはマウントテーブル８０１と、
各サービス１２３が応答するサービス要求とが関連す
る。具体的なサービス要求は、「ｗａｌｋ」サービスフ
ァイル探索要求であり、或る場合には、「ａｔｔａｃ
ｈ」サービスファイル探索要求である。

【０２６５】パス名を解くプラン９核機能を「ｎａｍｅ
ｃ」（ネーメック）と名付ける。この機能の流れ図を図
１０に示す。ステップ１００３に示すように、「ｎａｍ
ｅｃ」機能は、主題項目として、パス名、「ｎａｍｅ
ｃ」機能を用いるシステムコールによって要求されるフ
ァイルアクセスの種類（アクセスモード）についてのコ
−ド、及び「ｎａｍｅｃ」機能によって開かれるファイ
ルがどのように開かれるべきか（オープンモード）を表
示するコ−ドを取る。

【０２６６】「ｎａｍｅｃ」機能は、チャンネルへポイ
ンタを返す。又、「ｎａｍｅｃ」機能は、パス名中の第
１文字を特別に取り扱うが、それ以外は、パス名を
「／」記号で分けられた名前のリストとして扱う。名前
を各々、「要素」と名付ける。

【０２６７】「ｎａｍｅｃ」機能の最初の部分１０６７
においては、パス名が始まる点を表すチャンネル３０１
が求められる。チャンネルを求める仕方は、どのように
パス名が始まるかによる。これには３つの可能性があ
る。

【０２６８】・もしパス名が完全なパス名である場合、
「／」で始まる。 ・もしパス名が、ビルトイン核サービスによって与えら
れるファイルを指定し、そのサービスが、別のファイル
名にまだ連結されていない場合、パス名は「＃」で始ま
る。 ・もしパス名が作業ディレクトリにおいて始まる場合、
パス名はファイル名で始まる。

【０２６９】もしパス名が「／」で始まる場合、意思決
定ステップ１００５の「ＹＥＳ」分岐が取られ、ルート
部についてのファイルチャンネル４１９の内容がチャン
ネル３０１「ｎｃｈａｎ」にコピーされる（ステップ１
００９）。前に述べたように、ルートファイルチャンネ
ル４１９は、そのプロセスについてのユ−ザデータ構造
４０３から探索できる。

【０２７０】もしパス名がほかのもの（「／」以外）で
始まる場合、ステップ１００５の「ＮＯ」分岐が取ら
れ、ステップ１００７において、第１の要素が点検さ
れ、「＃」であるかどうかが定められる。もし「＃」で
ある場合、「＃」に続く記号によって指定される核ビル
トインサービスによって、「ａｔｔａｃｈ」サービスフ
ァイル探索要求が実行される。「ａｔｔａｃｈ」サービ
スファイル探索要求の結果は、ビルトインサービスによ
って与えられるファイル樹木１２５のルート部を表すチ
ャンネルデータ構造３０１である。

【０２７１】与えられたサービスが「ａｔｔａｃｈ」要
求を取り扱う仕方は、もちろんそのサービスによる。例
えば、ルートサービスについての「ａｔｔａｃｈ」機能
は、一般的な「ａｔｔａｃｈ」機能である「ｄｅｖａｔ
ｔａｃｈ」を呼び出す。この機能は、主題項目として、
ビルトインサービスの名前、この場合は「／」、を取
る。

【０２７２】「ｄｅｖａｔｔａｃｈ」機能は、新しいチ
ャンネルデータ構造３０１を得て、「ＱＩＤ」フィール
ド３２３（ファイルハンドル）を、ルート部を指定する
値にセットし、「ＴＹＰＥ」フィールド３１３を、主題
項目「／」から導かれた値にセットする。

【０２７３】もし第１の要素が「／」でも「＃」でもな
い場合には、パス名は作業ディレクトリにおいて始ま
る。そして、ステップ１０１３に示すように、作業ディ
レクトリを表すファイルチャンネル４１９が「ｎｃｈａ
ｎ」にコピーされる。そのファイルチャンネルは、もち
ろんそのプロセスについてのユ−ザデータ構造３０１か
ら探索可能である。

【０２７４】「ｎａｍｅｃ」機能のうちの次のステージ
１０６９は、「ｎｃｈａｎ」によって表されるファイル
についてのパス名が、「ｂｉｎｄ」又は「ｍｏｕｎｔ」
機能コールにおいて旧パス名として用いられていたかど
うかを見出すステージである。最初に、パス名の次の要
素が求められる。これを行う機能は、ユ−ザデータ構造
４０３内の「ＥＬＥＭ」（要素）フィールド４０５を、
次の要素であるファイル名にセットする。

【０２７５】それから、プロセスグループ１０３につい
てのマウントテーブルアレイ８０２が、プロセス１０２
についてのユ−ザデータ構造４０３から探索される。各
マウントテーブルアレイエントリ８０３についての左チ
ャンネル８０２が「ｎｃｈａｎ」と比較され、「ｎｃｈ
ａｎ」に等しいものが見出されるまで比較が繰り返され
る。

【０２７６】この場合に、「等しい」の意味は、２つの
チャンネル３０１が同じサービス１２３内の同じファイ
ルを表す、すなわちこれら２つのチャンネル３０１が
「ＴＹＰＥ」フィールド３１３、「ＤＥＶ」フィールド
３１５、及び「ＱＩＤ」フィールド３２３において等し
い値を有する、ということである。

【０２７７】もしこのような左チャンネル８０２が見出
されない場合、意思決定ステップ１０１９の「ＮＯ」分
岐が取られ、見出された場合には、「ＹＥＳ」分岐が取
られる。そして、その左チャンネル８０２が「ｎｃｈａ
ｎ」に等しいようなエントリ８０３によって指し示され
る右チャンネル８０４の内容が、「ｎｃｈａｎ」へコピ
ーされる（ステップ１０２１）。

【０２７８】その後、「ｎｃｈａｎ」内の「ＭＯＵＮＴ
ＰＴＲ」（マウントポインタ）フィールド３２７が、
右チャンネル８０４を指し示すマウント構造８０９を指
し示すようにセットされ、「ＭＯＵＮＴ ＩＤ」（マウ
ント識別子）フィールド３２９が、マウント構造８０９
の「ＭＯＵＮＴ ＩＤ」の値にセットされる。

【０２７９】したがって、もしパス名が「ｂｉｎｄ」又
は「ｍｏｕｎｔ」コールにおいて旧パス名として用いら
れた場合、「ｎｃｈａｎ」は今や右チャンネル８０４に
よって表されるファイルを表すことになる。もしそうで
なければ、「ｎｃｈａｎ」は変わらない。

【０２８０】図１０の「ｎａｍｅｃ」機能のうちの、そ
の次の１０７１の部分は、パス名における残る各要素を
点検するループ１０２５からなる。ループを通るごとに
核機能である「ｗａｌｋ」（ウオーク）機能へのコール
（呼び出し）が行われる。このコールに用いられる主題
項目は、「ｎｃｈａｎ」、現要素（ステップ１０２
９）、及び現在の名前がそのファイルを表す左チャンネ
ル８０２を有する（これが不可能なのは、核ビルトイン
サービス名の場合のみである）かどうかを表示するフラ
ッグである。

【０２８１】下に更に詳しく説明するように、「ｗａｌ
ｋ」機能は、その要素によって指定されるファイルを表
すチャンネル３０１を返す。そのチャンネル（図１０に
おいてｔｃｈａｎと名付ける）が、ステップ１０３１に
示すように、「ｎｃｈａｎ」に割り当てられる。それか
ら、次の要素が、パス名から求められる（ステップ１０
３３）。前と同様に、ユ−ザデータ構造４０３内の「要
素」フィールド４０５が、次の要素にセットされる。ル
ープが終ると、パス名の最後の要素が残って処理される
段階となる。

【０２８２】最後の要素が処理される仕方は、どのシス
テムコールが「ｎａｍｅｃ」機能を呼び出したかによ
る。もしそれが「ｃｒｅａｔｅ」（創設）システムコー
ルだった場合、最後の要素は新しいファイルの名前を表
す。そうでなかった場合は、それはアクセスすべきファ
イルを表す。どのシステムコールが「ｎａｍｅｃ」機能
を呼び出したかは、アクセスモード主題項目によって表
示される。

【０２８３】そして、意思決定ステップ１０５５に示す
ように、その後の処理もこの主題項目によるが、ここで
の説明の目的のためには、ステップ１０５７に示すよう
に、アクセスモード主題項目が、ファイルを創設すべき
ことを表示する場合、最後の要素と「ｔｃｈａｎ」とを
用いて「ｃｒｅａｔｅ」サービスファイル要求が作成さ
れること、を知っていれば十分である。「ｔｃｈａｎ」
は、この時点では新しいファイルが創設されるべきディ
レクトリについてのファイルチャンネルデータ構造４１
９のコピーである。

【０２８４】したがって、「ｔｃｈａｎ」は、その「Ｔ
ＹＰＥ」フィールド３１３及び「ＤＥＶ」フィールド３
１５に、ディレクトリと「ＱＩＤ」フィールド３２３内
のディレクトリについての「ｑｉｄ」とを含むサービス
１２３を指定する値、を有する。「ｃｒｅａｔｅ」サー
ビスファイル要求の結果として、新しいファイルが創設
され、最後の要素にその名前として割り当てられる。そ
して、「ｔｃｈａｎ」の「ＱＩＤ」フィールドが、新し
いファイルの「ｑｉｄ」にセットされる（ステップ１０
５７）。

【０２８５】そうでなければ、最後の要素は、既に存在
するファイルの名前を表す。この場合は、「ｔｃｈａ
ｎ」を得るために最後の要素を用いて「ｗａｌｋ」機能
が呼び出される。この「ｔｃｈａｎ」は、最後の要素に
よって参照されるファイルを表す（ステップ１０５
９）。

【０２８６】それから、「ｔｃｈａｎ」内のフィールド
が、「ｎａｍｅｃ」機能の「アクセス」モード及び「オ
ープン」モード主題項目からの要求に合わせてセットさ
れ（ステップ１０６１）、「ｔｃｈａｎ」は「ｎｃｈａ
ｎ」にコピーされる（ステップ１０６３）。次に、ステ
ップ１０６５に示すように、「ｎｃｈａｎ」は、パス名
主題項目に指定されるファイルを表すチャンネル３０１
として返される。

【０２８７】図１１は、「ｗａｌｋ」（ウオーク）機能
の流れ図である。図１１の開始ステップ１１０３から明
らかなように、「ｗａｌｋ」機能は、主題項目として、
チャンネルデータ構造３０１、パス名からの要素、及び
要素への「ｍｏｕｎｔ」が正当かどうかを表示するフラ
ッグを取る。

【０２８８】チャンネルデータ構造３０１は、要素名を
有するファイルについて探索すべきディレクトリを表
す。もし要素名が、そのディレクトリ内、又はチャンネ
ルデータ構造によって表されるそのディレクトリに結合
されたディレクトリ内に見出される場合、「ｗａｌｋ」
機能は、パス名の要素によって指定されるファイルを表
すチャンネルデータ構造３０１を返す。

【０２８９】概観すれば、アルゴリズムは次の通りであ
る。まず、主題項目として用いられるチャンネル３０１
の「ＴＹＰＥ」フィールド３１３及び「ＤＥＶ」フィー
ルド３１５によって指定されるサービスに対して、「ｗ
ａｌｋ」ファイルサービス要求が行われる。「ｗａｌ
ｋ」ファイルサービス要求には、主題項目として用いら
れる要素が含まれる。

【０２９０】もしファイルサービス要求が成功すると、
その要素によって指定されるファイルについてのチャン
ネル３０１を返す。それから、マウントテーブルが点検
されて、「ｗａｌｋ」要求によって返されたチャンネル
３０１が左チャンネル８０２かどうかが定められる。も
し左チャンネル８０２でない場合、「ｗａｌｋ」要求に
よって返されたチャンネルは、「ｗａｌｋ」機能によっ
て返される。

【０２９１】もし左チャンネル８０２である場合、その
左チャンネル８０２に対応する右チャンネル８０４が、
チャンネル３０１へコピーされて、「ｗａｌｋ」機能に
よって返される。そして、チャンネル３０１の「ＭＯＵ
ＮＴ ＰＴＲ」及び「ＭＯＵＮＴ ＩＤ」のフィールド
が、左チャンネル８０２を指し示すマウントテーブルア
レイエントリ８０３によって指し示されるマウントデー
タ構造８０９からの要求に合わせてセットされる。

【０２９２】もしファイルサービスがチャンネルによっ
て指定されたディレクトリ内の要素によって指定される
名前を有するファイルを見出すことができない場合に
は、「ｗａｌｋ」ファイルサービス要求は成功しない。
このような場合が生じるには次の２つの理由がある。 ・ディレクトリが、別の名前と連結されていた。 ・要素に対応するファイルが、ディレクトリ内に存在し
ない。

【０２９３】第１の場合、「ＭＯＵＮＴ ＰＴＲ」フィ
ールド３２７及び「ＭＯＵＮＴ ＩＤ」フィールド３２
９が、その別の名前が連結されたときに創設されたマウ
ント構造８０９を指定する。そして、「ｗａｌｋ」サー
ビスファイル探索要求が、マウント構造８０９によって
指し示された右チャンネル８０４内に指定されるサービ
スについて、再度企図される。

【０２９４】もし「ｗａｌｋ」サービスファイル探索要
求が成功すると、処理は上記のように継続される。もし
不成功の場合、上記の理由のいずれかが存在する可能性
が残る。今度は、要素に対応するファイルがディレクト
リ内に存在しないことが問題であると仮定して、まだ２
つの可能性がある。すなわち、ファイルが実際に存在し
ないか、又は探索されたディレクトリが結合ディレクト
リの一部であり、結合ディレクトリの一部である他のデ
ィレクトリがまだ探索されていない、という可能性であ
る。

【０２９５】もしファイルが実際に存在しない場合に
は、今探索されたディレクトリについてのマウント構造
８０９内の「終結」フィールド８１３は、そのマウント
構造８０９が、結合ディレクトリを構成するマウント構
造８０９のリスト中の最後のマウント構造であることを
表示する。

【０２９６】もしそうでない場合、マウント構造８０９
の次のフィールド８１７が、結合ディレクトリ内の次の
ディレクトリについてのマウント構造８０９を指し示
す。そして、その、次のマウント構造から、探索すべき
右チャンネル８０４を定めることが可能である。この場
合、「ｗａｌｋ」サービスファイル探索要求が、次のマ
ウント構造によって指し示される右チャンネル８０４を
用いて繰り返される。

【０２９７】更に詳しく説明すれば、ステップ１１０５
において、それが、「ｗａｌｋ」サービスファイル探索
要求が処理される最初の回であることを表示するように
フラッグ「第１」が「１」にセットされ、主題項目とし
て与えられたチャンネルが「ｃｃｈａｎ」へコピーされ
る。ステップ１１０７において、「ｗａｌｋ」サービス
ファイル探索要求が、「ｃｃｈａｎ」とその要素とを用
いて処理される。

【０２９８】その要求に応答してサービスが行う作業
は、そのサービスによる。ここでは２つの例を説明すれ
ば足りる。ルートサービスが、「ｗａｌｋ」要求に応答
して、ルートサービスのルート部に対して予約されてい
る「ＱＩＤ」フィールド３２３に「ｃｃｈａｎ」が特別
値を有するかどうかを定め、もし有する場合は、その要
素が、ルートサービスが「スタブ」として与える名前の
うちの１つかどうかを定める。

【０２９９】もし後者の場合には、「ｃｃｈａｎ」の
「ＱＩＤ」フィールド３２３がそのスタブ名のために予
約されている特別値にセットされる。そうでない場合、
「ｗａｌｋ」サービスファイル探索要求は不成功であ
る。

【０３００】マウントサービス２０３は、「ｗａｌｋ」
要求に対して次のように応答する。前に述べたように、
プロトコルサービス２０９によって与えられるファイル
を表すチャンネル３０１の「ＤＥＶ」フィールド３１５
の一部は、マウントサービスアレイエントリ５０３を指
定する識別子を有する。

【０３０１】その識別子を用いて、マウントサービス２
０３は、プロトコルサービス２０９についてのプロトコ
ルチャンネル５１７についてのマウントサービス待ち行
列５０９を探索し、「ｗａｌｋ」要求のために必要とさ
れる「ｔメッセ−ジ」についてマウントサービスヘッダ
５２１を割り当て、チャンネルからのファイル識別子
と、要素とを、「ｔメッセ−ジ」に置く。

【０３０２】もしプロトコルサービス２０９が、チャン
ネルからファイル識別子によって指定されるディレクト
リ内に要素によって指定される名前付きのファイルを有
する場合、プロトコルサービス２０９は、そのファイル
についての「ｑｉｄ」を含む「ｒメッセ−ジ」を返す。
そして、その「ｑｉｄ」は、「ｃｃｈａｎ」の「ＱＩ
Ｄ」フィールド３２３に置かれる。

【０３０３】もし「ｗａｌｋ」要求が成功すると、「ｃ
ｃｈａｎ」内のフラッグ３２１が、チャンネル３０１が
「ｍｏｕｎｔ」又は「ｂｉｎｄ」オペレーションの結果
ではないことを表示するようにセットされる（ステップ
１１１９）。次のステップでは、「ｗａｌｋ」要求が１
回を超えて（２回以上）処理されたかどうかが定められ
る（１１２１）。

【０３０４】もしそうである場合、主題項目として受け
られたチャンネルは、返されたチャンネルではない。そ
して、主題項目として受けられたチャンネルは、閉じら
れる（ステップ１１２３）。「閉じ」オペレーション
は、そのチャンネルの「ＲＥＦ」（参照）フィールド内
のカウントを減値し、もし「ＲＥＦ」フィールドのカウ
ント値が「０」になる場合は、「ｃｌｕｎｋ」サービス
要求を、そのチャンネルの「ＤＥＶ」フィールド３１５
によって表示されるサービスに送り、チャンネル構造３
０１を自由リストに返す。

【０３０５】もしそれがまだ、「ｗａｌｋ」要求が処理
される最初の回である場合、このステップ１１２３は省
略される。次の意思決定ステップ１１３３においては、
パス名の構成要素が別の構成要素をその上にマウントさ
れてもよいことを「ｃｃｈａｎ」が表しているかどうか
が定められる。これは、「＃」以外の構成要素について
は真であり、「ｗａｌｋ」機能の「マウントＯＫ」の主
題項目によって表示される。

【０３０６】もしマウントされた構成要素がない場合、
マウントテーブル８０１を調査する必要がなく、「ｃｃ
ｈａｎ」はそのまま返される（ステップ１１３５）。そ
うでない場合、マウントテーブル８０１が、「ｃｃｈａ
ｎ」に等しい左チャンネル８０２について点検される。

【０３０７】もしこのような左チャンネル８０２が見出
される場合、左チャンネル８０２に対応する右チャンネ
ル８０４の値が、右チャンネル８０４を指し示すマウン
ト構造８０９についての「ＭＯＵＮＴ ＰＴＲ」及び
「ＭＯＵＮＴ ＩＤ」フィールドの値と共に、「ｃｃｈ
ａｎ」へコピーされる。「ｃｃｈａｎ」は、このように
修正されたうえで返される（ステップ１１３７〜１１４
３）。

【０３０８】「ｗａｌｋ」サービス要求可否点検ステッ
プ１１０７に戻って、もし要求が不成功の場合、次の最
初のステップでは、「ｃｃｈａｎ」が「ｍｏｕｎｔ」又
は「ｂｉｎｄ」要求の結果であるかどうかが定められる
（ステップ１１０９）。もし「ＹＥＳ」の場合、この探
索は不成功で、「ｗａｌｋ」機能は、「０」を返す（ス
テップ１１４９）。ステップ１１４５及び１１４７に示
すように、もし「ｗａｌｋ」要求が１回よりも多い回数
処理された場合には、「ｃｃｈａｎ」は閉じられる。

【０３０９】次に、「ｃｃｈａｎ」の「ＭＯＵＮＴ Ｐ
ＴＲ」フィールド３２７の値を用いてマウント構造８０
９が探索される（ステップ１１１１）。もしマウント構
造が結合ディレクトリを定義するマウント構造のリスト
の末尾にあることを、マウント構造８０９の「終結」フ
ィールド８１３が表示する場合（ステップ１１１３）、
探索は不成功で、「ｗａｌｋ」機能は終了する。

【０３１０】そうでない場合、現マウント構造８０９内
の次のポインタ８１７に沿って進み、次のマウント構造
８０９によって指し示される右チャンネル８０４が、仮
チャンネル（「ｔｃｈａｎ」と名付ける）へコピーされ
る（ステップ１１１５、１１１７）。

【０３１１】それから、「ｔｃｈａｎ」内の「ＭＯＵＮ
Ｔ ＰＴＲ」フィールド３２７が、次のマウント構造を
指し示すようにセットされ（ステップ１１２５）、「ｔ
ｃｈａｎ」が「ｃｃｈａｎ」へコピーされ（ステップ１
１２７）、フラッグ「第１」の値が、処理が第１回でな
いことを示す「０」にセットされ（ステップ１１２
９）、機能はステップ１１０７に戻って「ｗａｌｋ」サ
ービス要求が繰り返される。上記のように、ステップ１
１０７において「ｗａｌｋ」要求が成功するか、又は要
素に対応するファイルが見出されなかったことが明白に
なるまで一連のループ手順が繰り返される。

【０３１２】ファイル探索オペレーションの実現 プラン９における名前解法が理解されると、「ｏｐｅ
ｎ」、「ｂｉｎｄ」、及び「ｍｏｕｎｔ」のようなファ
イル探索システムコールの実現は簡単である。「ｏｐｅ
ｎ」（開設）についてのシステムコールからまず説明す
ると、システムコールは、パス名と、「ｏｐｅｎ」の方
法を示す「ｏｐｅｎ」モードを指定する整数とを主題項
目として取り、開かれたファイルについてのファイル記
述子４１７を返す。

【０３１３】システムコールは最初に、現時点において
チャンネル３０１を指し示していないファイル記述子ア
レイ４１３内のエントリ４１５を探索する。その要素の
番号が、新しく開かれたファイルについてのファイル記
述子である。それからシステムコールは、「ｎａｍｅ
ｃ」機能を呼び出す。主題項目は、パス名、「ｏｐｅ
ｎ」を指定するアクセスモード指定子、及び「ｏｐｅ
ｎ」のモードである。

【０３１４】上記のように、「ｎａｍｅｃ」機能は、パ
ス名を解き、パス名によって表示されるサービスが、パ
ス名によって指定されるファイル上でオペレーションを
行うこと、を指定する。又、「ｎａｍｅｃ」機能は、フ
ァイルを表すファイルチャンネル４１９にチャンネル３
０１がなるようにフィールドをセットしてチャンネル３
０１を返す。「ｏｐｅｎ」システムコールは、ファイル
記述子によって指定されるファイル記述子アレイエント
リ４１５内に、ファイルチャンネル４１９を指し示すポ
インタを置き、ファイル記述子を返す。

【０３１５】本発明の一実施例における「ｂｉｎｄ」シ
ステムコールは、主題項目として、新しいパス名を指し
示すポインタ、旧パス名を指し示すポインタ、及び「ｂ
ｉｎｄ」機能が「置換」、「前」、又は「後」オプショ
ン付きで行われているかどうかを表示するフラッグを取
る。「ｂｉｎｄ」システムコールは又、もし「ｂｉｎ
ｄ」が成功したときに「１」を取り不成功のときに
「０」を取る整数指標を返す。

【０３１６】「ｂｉｎｄ」システムコールは、「ｂｉｎ
ｄ」と「ｍｏｕｎｔ」との両方の機能を行う「ｂｉｎｄ
ｍｏｕｎｔ」と名付ける核機能を呼び出す。「ｂｉｎ
ｄ」又は「ｍｏｕｎｔ」システムコールによって与えら
れるフラッグは、どちらを行うべきかを表示する。

【０３１７】「ｂｉｎｄ」システムコールが表示される
と、「ｂｉｎｄｍｏｕｎｔ」が、第１のパス名によって
指定されるファイルを表す第１のチャンネル３０１を得
るために、第１のパス名で「ｎａｍｅｃ」機能を呼び出
し、次に、第２のパス名によって指定されるファイルを
表す第２のチャンネル３０１を得るために、第２のパス
名で「ｎａｍｅｃ」機能を呼び出す。

【０３１８】次のステップは、核「ｍｏｕｎｔ」機能の
呼び出しである。核「ｍｏｕｎｔ」機能は、「ｂｉｎ
ｄ」オペレーションの必要に合わせてマウントテーブル
８０１を再構成する。

【０３１９】図１２は、核「ｍｏｕｎｔ」機能の流れ図
である。ステップ１２０３に示すように、「ｍｏｕｎ
ｔ」機能は、主題項目として、旧チャンネル、新チャン
ネル、及びフラッグを取り、「ｂｉｎｄ」又は「ｍｏｕ
ｎｔ」機能から結果として得られるマウント構造８０９
の「マウントＩＤ」を返す。フラッグは、「ｂｉｎｄ」
又は「ｍｏｕｎｔ」システムコールのオプションフラッ
グからセットされる。現在の例の場合、旧チャンネル及
び新チャンネルについての実際の主題項目は、それぞ
れ、第１チャンネル３０１、及び第２チャンネルであ
る。

【０３２０】アルゴリズムの第１ステップは、「ｂｉｎ
ｄ」又は「ｍｏｕｎｔ」オペレーションが、主題項目と
して受けられたチャンネル３０１上で実行可能かどうか
を定めることである（ステップ１２０５）。もし両チャ
ンネルが同じファイルを指定する（すなわち同じ「ＱＩ
Ｄ」フィールド３２３を有する）場合、又はもし旧チャ
ンネルがディレクトリではないファイルを表し、フラッ
グが「置換」以外のオプションを指定する場合には、オ
ペレーションは許されない。

【０３２１】次のステップは、既に述べたように、マウ
ントテーブル８０１内を探索して、旧チャンネル３０１
が、既にマウントテーブル８０１内にある左チャンネル
８０２に等しいかどうかを定めることである。もし等し
い場合は、新しいマウントテーブルエントリ８０３は必
要なく、ステップ１２１１は省略される。もし等しくな
い場合、ステップ１２１１において、空きマウントテー
ブルアレイエントリ８０３が得られ、そのエントリ８０
３においてポインタ８０５が旧チャンネルを指し示すよ
うにセットされる。

【０３２２】次に、新チャンネル３０１内の「ＦＬＡ
Ｇ」フィールド３２１が、右チャンネル８０４であるこ
とを意味する「ＣＭＯＵＮＴ」を表示するようにセット
される（ステップ１２１３）。「ＦＬＡＧ」フィールド
３２１は又、「ＣＲＥＡＴＥ」オプションを表示する。
「ＣＲＥＡＴＥ」オプションは、ファイルが右チャンネ
ル８０４によって表されるディレクトリ内に創設される
ことを指定する。

【０３２３】そのオプションが指定されると、新チャン
ネル３０１内の「ＦＬＡＧ」フィールド３２１が、「Ｃ
ＭＯＵＮＴ」と同様に、「ＣＲＥＡＴＥ」オプションを
表示するようにセットされる（ステップ１２１５、１２
１７）。それから、「ｍｏｕｎｔ」機能が、旧チャンネ
ルに対応する左チャンネル８０２についてのマウントテ
ーブルエントリを、新チャンネル３０１から形成される
右チャンネル８０４とリンクするために新マウント構造
を得る。新マウント構造内のポインタ８１９が、新チャ
ンネル３０４を指し示すようにセットされる（ステップ
１２１９）。

【０３２４】次は、切り換えステップ１２２１で、ここ
では、フラッグ主題項目が「置換」、「前」、又は
「後」オプションのどれを表示するかによって、３種類
のパスのうちの１つが指定される。「前」オプションの
パス１２２３では、ステップ１２２９において、点検が
行われ、別のディレクトリが既に左チャンネル８０２に
連結されているかどうかが定められる。

【０３２５】もし連結されていなければ、結合ディレク
トリの可能性はなく、「前」オプションはエラーとなる
（ステップ１２３１）。もしこのようなディレクトリが
既に存在する場合、「置換」オプション１２２５に関し
ての処理が続く。

【０３２６】この「置換」オプションにおいては、新マ
ウント構造８０９が、旧チャンネル３０１に等しい左チ
ャンネル８０２に対応するマウント構造８０９のリスト
の先頭に置かれる（ステップ１２３３）。もし「置換」
オプション１２２５が行使されると、新マウント構造内
の「終結」フィールド８１３が、リストの末尾を表示す
るようにセットされる（ステップ１２３４）。

【０３２７】３種類のうちの最後の、「後」オプション
１２２７においては、ステップ１２３５において、点検
が行われ、結合ディレクトリが可能かどうかが定められ
る。もし可能性がないなら、エラーが生じる（ステップ
１２３７）。そうでなく、可能性があれば、ステップ１
２３９に示すように、新マウント構造８０９が、マウン
ト構造８０９のリストの末尾に置かれる。そして、新マ
ウント構造８０９に属する「マウントＩＤ」（マウント
識別子）８１５が返される（ステップ１２４１）。

【０３２８】「ｂｉｎｄｍｏｕｎｔ」機能について説明
すると、この機能は、旧チャンネル及び新チャンネル３
０１を閉じることによって終了し、これらのチャンネル
のいずれもマウントテーブルに追加されなかったこと及
びフリーチャンネルのリストに用いられていないことを
返す。

【０３２９】「ｍｏｕｎｔ」機能システムコールは、新
パス名主題項目がないという点で「ｂｉｎｄ」機能シス
テムコールと異なる。この場合、新パス名主題項目の代
わりに、オープンプロトコルチャンネル５１７を表すフ
ァイル記述子４１７を主題項目として採用している。こ
のようなファイル記述子４１７を得る方法については下
に詳しく述べる。

【０３３０】更に、「ｍｏｕｎｔ」機能システムコール
は、マウントされつつあるプロトコルサービス２０９に
送られるデータからなる主題項目を有する。フラッグに
応答して、「ｂｉｎｄｍｏｕｎｔ」機能は最初にファイ
ル記述子４１７とファイル記述子アレイ４１３とを用い
てファイル記述子主題項目によって指定されるプロトコ
ルチャンネル５１７を探索する。

【０３３１】次に、マウントサービス「ａｔｔａｃｈ」
（アタッチ）オペレーションが、プロトコルチャンネル
５１７を用いて行われる。「アタッチ」オペレーション
において最初に行われることは、不使用のマウントサー
ビスアレイエントリ５０３を探索することである。これ
が行われた後、前に述べた一般的な「ｄｅｖａｔｔａｃ
ｈ」オペレーションが行われるが、ここで異なるのは、
システム呼び出しに用いられる主題項目が、マウントサ
ービス２０３を指定する「Ｍ」であるということであ
る。

【０３３２】「ｄｅｖａｔｔａｃｈ」は、「ＴＹＰＥ」
フィールド３１３をマウントサービス２０３を指定する
ようにセットしたチャンネル構造３０１を返す。そし
て、マウントサービスについての「アタッチ」機能が、
チャンネル内の「ＤＥＶ」フィールド３１５を不使用マ
ウントサービスアレイエントリ５０３についての記述子
の値にセットし、不使用エントリ内のポインタ５０５
を、チャンネル構造を指し示すようにセットする。

【０３３３】次に、プロトコルチャンネル主題項目が、
用いられて、この主題項目によって指定されるプロトコ
ルチャンネル５１７について、マウントサービス待ち行
列構造５０９によって表されるメッセ−ジ待ち行列が既
に存在するかどうかが定められる。もし存在しなけれ
ば、１つのメッセ−ジ待ち行列が割り当てられる。それ
から、「ｄｅｖａｔｔａｃｈ」によって返されたチャン
ネル３０１についてのファイル識別子と、プロトコルサ
ービス２０９に送られることになっていた主題項目と、
を含む「アタッチ」「ｔメッセ−ジ」が送られる。

【０３３４】「ｒメッセ−ジ」が返されると、そのメッ
セ−ジには、プロトコルサービス２０９内のファイル樹
木１２５のルート部についてのファイルハンドル「ｑｉ
ｄ」を含む。「ｑｉｄ」は、「ｄｅｖａｔｔａｃｈ」に
よって返されたチャンネル３０１の「ＱＩＤ」フィール
ド３２３と「ＭＱＩＤ」フィールド３３９とへコピーさ
れる。そして、メッセ−ジ待ち行列が属するプロトコル
チャンネル５１７を指し示すポインタが、「ＰＣＨＡ
Ｎ」フィールド３３７へコピーされる。

【０３３５】マウントサービス「アタッチ」オペレーシ
ョンから結果として得られるチャンネルは、新チャンネ
ル３０１主題項目として、「ｍｏｕｎｔ」機能に与えら
れる。「ｍｏｕｎｔ」が「ｂｉｎｄｍｏｕｎｔ」につい
て指定されると、「ｂｉｎｄｍｏｕｎｔ」は、ファイル
記述子アレイ４１３からプロトコルチャンネル５１７を
閉じることと、ファイル記述子アレイ４１３からプロト
コルチャンネル５１７を削除することとによって、終了
する。

【０３３６】オープンプロトコルチャンネル５１７の取得（図１３） 「ｍｏｕｎｔ」システムコールについての主題項目は、
オープンプロトコルチャンネル５１７についてのファイ
ル記述子４１７を有する。プロトコルチャンネル５１７
は、プロトコルサービス２０９と接続関係にあるファイ
ルを表すチャンネル３０１である。本発明の一実施例に
おいて、この接続は、ローカルプロトコルサービス２１
１がメッセ−ジを送受するパイプ内のファイル、又は通
信システムを介しての遠隔プロトコルサービス２１３と
の会話を表すファイル、のいずれかである。

【０３３７】本発明の一実施例において、パイプ内のフ
ァイルについてのファイル記述子は、パイプを創設する
「パイプ」システムコールによって与えられる。通信シ
ステムを介しての会話を表すファイルについてのファイ
ル記述子は、次のようにして得られる。まず、「ダイヤ
ル」機能が呼び出される。この機能は、会話を表すファ
イルを含むディレクトリのパス名を返す。それから、会
話を表すファイルのパス名が、「ｏｐｅｎ」機能内で使
用され、「ｏｐｅｎ」機能は、会話を表すファイルにつ
いてのファイル記述子を返す。

【０３３８】プロトコルチャンネル５１７が「ｓｒｖ」
６１５においてプロトコルサービス２０９との接続を表
すそのプロトコルサービス２０９を「登録」することに
より、プロセス１０２による一般使用に対してプロトコ
ルチャンネル５１７が利用可能となる。

【０３３９】これは全てのサーバについて成り立つの
で、「ｓｒｖ」６１５によって、ファイルとして管理で
きるリソースが提供されることとなる。したがって、プ
ロトコルサービス２０９を「ｓｒｖ」６１５に登録する
ためには、「ｓｒｖ」によって表されるディレクトリ内
でプロトコルサービス２０９を表すファイルを創設し、
ファイルを創設するための接続を表すファイルについて
のファイル記述子を書き込む。

【０３４０】もちろん、「ｃｒｅａｔｅ」機能の呼び出
しを行うとその結果、「ｓｒｖ」への「ｃｒｅａｔｅ」
ファイル要求を行うことになり、「ｓｒｖ」がこの要求
に応答して、ファイルについてのディレクトリエントリ
を行い、ディレクトリエントリについての「ｑｉｄ」
を、創設されたファイルについてのチャンネル３０１の
フィールド３２３に置き、ディレクトリエントリを指し
示すポインタを、「ＡＵＸ」フィールド３３３に置く。

【０３４１】「ｗｒｉｔｅ」機能の呼出も同様に、結果
として「ｓｒｖ」への「ｗｒｉｔｅ」ファイル要求とな
り、「ｓｒｖ」が「ｗｒｉｔｅ」ファイル要求に応答し
て、ファイル記述子によって指定されるプロトコルチャ
ンネル５１７を指し示すポインタを、プロトコルサービ
ス２０９についてのディレクトリエントリに置く。

【０３４２】プロトコルサービス２０９を表すファイル
の名前を用いて「ｏｐｅｎ」システムコールが行われる
と、結果としての、「ｓｒｖ」６１５への「ｏｐｅｎ」
ファイル要求により、プロトコルサービス２０９につい
てのプロトコルチャンネル５１７が「ｓｒｖ」６１５か
ら返される。それから、既に述べたように、「ｏｐｅ
ｎ」機能は、プロトコルチャンネル５１７にファイル記
述子４１７を与える。そして、ファイル記述子４１７は
「ｍｏｕｎｔ」システムコールに用いられる。

【０３４３】図１３は、プロトコルサービス２０９を登
録するために「ｓｒｖ」サービス６１５によって用いら
れるデータ構造１３０１である。「ｓｒｖ」サービス６
１５によって維持されるディレクトリは、ディレクトリ
・エントリ１３０３の樹木から構成される。各ディレク
トリ・エントリ１３０３は、ディレクトリ情報１３０５
及びいくつかのポインタを有する。

【０３４４】ポインタは、ディレクトリ・エントリ１３
０３を樹木の形に編成する。樹木の各レベルには１つ以
上のディレクトリ・エントリ１３０３があり、或る与え
られたレベルにおけるディレクトリ・エントリ１３０３
は、内部ノード、すなわち樹木の次のより低いレベルに
つながる点、又はプロトコルサービス２０９を表す葉部
ノード、のいずれかである。内部ノードを以後、「親」
と名付ける。

【０３４５】与えられた「親」を有するエントリ１３０
３は、次方向ポインタ１３１１及び逆方向ポインタ１３
１３によって子リスト１３１０に接続される。そのう
え、与えられた子リスト１３１０内の各エントリ１３０
３は、その親エントリ１３０３を指し示すポインタ１３
０９を有する。親エントリ１３０３は更に、子リスト１
３１０内の第１のエントリ１３０３を指し示すポインタ
１３０７を有する。

【０３４６】葉部ノードは、その葉部ノードによって表
されるプロトコルサービス２０９への接続を表すプロト
コルチャンネル５１７を指し示すポインタ１３１４を有
する。更に、エントリ１３０３がチャンネル３０１によ
って表されるときは、そのチャンネル３０１内の「ＡＵ
Ｘ」フィールド３３３は、そのチャンネルによって表さ
れるエントリ１３０３を指し示すポインタ１３０２を有
する。

【０３４７】ディレクトリ情報は、次のフィールドを有
する。 ・「ＮＡＭＥ」（名前）１３１５：プロトコルサービス
２０９が登録されるときにそのプロトコルサービス２０
９を識別するために用いられる名前である。 ・「ＱＩＤ」１３１７：ディレクトリを表すチャンネル
３０１におけるディレクトリ・エントリ１３０３を表す
ファイルハンドル「ｑｉｄ」である。 ・「ＴＹＰＥ」フィールド１３１９及び「ＤＥＶ」フィ
ールド１３２１：「ｓｒｖ」６１５を指定する。

【０３４８】・「ＭＯＤＥ」１３２３：エントリ１３０
３によって表されるディレクトリが開かれたときに、オ
ープンモードを表示するようにセットされる。 ・「ＡＴＩＭＥ」１３２５：エントリ１３０３が何時割
り当てられたかを表示する。 ・「ＭＴＩＭＥ」１３２７：エントリ１３０３の親が何
時割り当てられたかを表示する。もしエントリ１３０３
が親の場合、子が創設された最新の時点を表示する。

【０３４９】・「ＬＥＮＧＴＨ」１３２９：もしエント
リ１３０３が親の場合、子エントリ１３０３の数を表示
する。 ・「ＵＩＤ」１３３１：エントリ１３０３を所有するユ
−ザに名前を付ける、記号列からなる値。 ・「ＧＩＤ」１３３３：「ＵＩＤ」１３３１において識
別されたユ−ザの属するグループを識別する、記号列か
らなる値。

【０３５０】以上、プラン９オペレーティングシステム
において如何にしてプロセスごとの名前スペースを実現
するか、如何にして名前スペースが「ｂｉｎｄ」及び
「ｍｏｕｎｔ」オペレーションによって修正されるか、
如何にして名前スペースがローカルファイルに用いられ
るか、そしてこのようにして探索され見出されたファイ
ル上で如何にしてファイルオペレーションが行われる
か、について説明した。次に、プロセスごとの名前スペ
ースについての有利な用法について説明する。

【０３５１】送出ファイルサービス（ｅｘｐｏｒｔｆ
ｓ）の概観（図１４） 上記プラン９システムにおいて、サービス１２３は、プ
ロセス１０２の名前スペース１１５における「ｍｏｕｎ
ｔ」（マウント）用にファイル樹木の全体しか与えるこ
とができない（上記「プラン９サービスのアーキテクチ
ャの概観」の項参照）。以下に説明する改善によって、
或る１つのプロセス１０２の名前スペースの一部分で、
別のプロセス１０２の名前スペースにマウントすべき部
分、を与えるサービス１２３が得られる。この新サービ
ス１２３をここでは送出ファイルサービス（ｅｘｐｏｒ
ｔｆｓ）と名付ける。

【０３５２】図１４は、１つのプロセス１０２（ｂ）が
その名前スペース１１５（ｂ）の一部分（ＮＳＰ）１４
０１を別のプロセス１０２（ａ）に送出する場合の２つ
のプロセス１０２の間の関係を示す。プロセス１０２
（ａ）は、この送出された部分を自身の名前スペース１
１５（ａ）にマウントする。

【０３５３】上記の「プラン９サービスのアーキテクチ
ャの概観」及び「核サービス及びプロトコルサービス」
の項で図１及び図２を参照して述べたように、プラン９
のファイルシステム１０９は、プロセス１０２からのフ
ァイルアクセス機能コール（呼び出し）１０５に応答し
てファイルアクセスオペレーションを行うファイルアク
セス機能成分１１１と、プロセス１０２からのファイル
探索機能コール１０７に応答してファイル探索オペレー
ションを行うファイル探索機能成分１１３とを有する。

【０３５４】ファイルアクセス機能コール１０５は、ア
クセス中のファイルを表すチャンネルデータ構造３０１
を指定する小さい整数であるファイル記述子４１７によ
ってアクセスすべきファイルを指定する。ファイル探索
機能コールは、パス名によって探索すべきファイルを指
定する。

【０３５５】プラン９システムにおいては、ファイル
は、いくつものサービス１２３によって与えられる。フ
ァイルシステム１０９がプロセス１０２からファイルオ
ペレーション機能コールを受けると、ファイルシステム
１０９は機能コールをそのファイルを与えるサービス１
２３についてのサービスファイルオペレーション要求に
変換する。

【０３５６】機能と同じく、サービスファイルオペレー
ション要求にも２つの種類がある。すなわち、サービス
ファイルアクセス要求１１９及びサービスファイル探索
要求１２１である。全てのサービス１２３は、「プラン
９サービスのアーキテクチャの概観」の項に述べたサー
ビスファイルオペレーションのセットを取り扱うことが
できなければならない。

【０３５７】多くのサービス１２３は、上記「核サービ
ス及びプロトコルサービス」の項で述べたプラン９プロ
トコルに応答してサービスファイルオペレーションを行
う。これらのサービスを、プロトコルサービス２０９と
名付ける。プロトコルは、プロセス間通信によって、又
はネットワ−ク経由のメッセ−ジによって、プロセスと
プロトコルサービスとの間で転送される。

【０３５８】サービスファイルオペレーション要求とプ
ラン９プロトコルとの間の変換は、マウントサービス２
０３によって管理される。マウントサービス２０３とプ
ロトコルサービス２０９との間でのプラン９プロトコル
搬送用のチャンネルを、プロトコルチャンネル５１７と
名付ける。

【０３５９】ファイルシステム１０９のファイル探索機
能成分１１３は、現にプロセス１０２に利用可能な樹木
を、名前スペース１１５へ編成する。名前スペース１１
５においては、樹木はファイル名によって単一のファイ
ル樹木に編成される。名前スペース１１５は、プラン９
「ｂｉｎｄ」及び「ｍｏｕｎｔ」機能コールによって修
正できる。

【０３６０】「ｂｉｎｄ」機能コールは、名前スペース
１１５内に既にある名前相互間の関係を変更する。「ｍ
ｏｕｎｔ」機能コールは、名前スペースに既にある名前
を、サービス１２３によって与えられるファイル樹木の
ルート部と同等にする。すなわち、「ｍｏｕｎｔ」機能
は、サービスによって与えられたファイル樹木をプロセ
スの名前スペース１１５に追加する。

【０３６１】図１４に示すように、符号（参照番号）１
４０５は、取込側プロセス１０２（ａ）、その、名前ス
ペース１１５（ａ）を含むファイルシステム１０９
（ａ）、及びマウントサービス２０３（ａ）を含むサー
ビス１２３（ａ）である。又、符号１４０７は、送出側
プロセス１０２（ｂ）、その、名前スペース１１５
（ｂ）を含むファイルシステム１０９（ｂ）、及びマウ
ントサービス２０３（ｂ）を含むサービス１２３（ｂ）
である。

【０３６２】マウントサービス２０３（ａ）は、プロト
コルチャンネル５１７によってプロセス１０２（ｂ）に
接続される。プロトコルチャンネル５１７は、プラン９
プロトコルを、マウントサービス２０３（ａ）とプロセ
ス１０２（ｂ）との間で直接変換する。

【０３６３】取込側プロセス１０２（ａ）は、何かのプ
ログラムを実行中であり、送出側プロセス１０２（ｂ）
は、送出ファイルサービスコ−ド１４０９を実行中であ
るとする。送出ファイルサービスコ−ド１４０９を実行
すると、プロセス１０２（ｂ）は、送出ファイルサービ
スになる。

【０３６４】この送出ファイルサービスは、すなわちプ
ロトコルチャンネル５１７を介して受けた名前スペース
１１５（ａ）の一部分１４０１内のファイルを指定する
プラン９プロトコルを、その名前スペース１１５（ｂ）
の一部分（ＮＳＰ）１４０１内のファイルを指定するフ
ァイル機能コール１０５、１０７に変換できるプロトコ
ルサービス２０９である。

【０３６５】その結果、プロセス１０２（ａ）がプロト
コルチャンネル５１７に対応するチャンネルを、名前ス
ペース１１５（ａ）のディレクトリ「Ｐ」上にマウント
すると、名前スペースの一部分１４０１は、名前スペー
ス１１５（ａ）の一部分となる。

【０３６６】したがって、「ｍｏｕｎｔ」機能の実行後
は、プロセス１０２（ａ）は、プロセス１０２（ｂ）の
名前スペース内のパス名「／Ｏ／Ｉ／Ｊ／Ｌ」によって
指定されるファイルを探索するのにパス名「／Ｐ／Ｑ／
Ｊ／Ｌ」を使用することができる。そして、プロセス１
０２（ａ）によってファイル「／Ｐ／Ｑ／Ｊ／Ｌ」上で
行われるファイルアクセスオペレーションは結果とし
て、プロセス１０２（ｂ）においてパス名「／Ｏ／Ｉ／
Ｊ／Ｌ」によって指定されるファイル上で行われるファ
イルアクセスオペレーションとなる。

【０３６７】プロセス１０２（ｂ）が送出ファイルサー
ビスコ−ド１４０９を実行中の場合、プロセス１０２
（ｂ）は、名前スペース１１５（ｂ）のどのサブ樹木で
も（名前スペース１１５（ｂ）の全てを含む）プロトコ
ルチャンネル５１７を介してプロセス１０２（ａ）に与
えることができる。そして、プロセス１０２（ａ）は、
「ｍｏｕｎｔ」機能を用いて名前スペース１１５（ａ）
内のどのディレクトリにでもこのサブ樹木をマウントで
きる。

【０３６８】本発明の一実施例において、プロセス１０
２（ａ）及びプロセス１０２（ｂ）が通信ネットワ−ク
によって接続される別個のコンピュータシステム１４１
１及び１４１３上でプログラムを実行中であるとする。
図１４に示すプロセス１０２（ｂ）とプロセス１０２
（ａ）との名前スペースの間の関係は、次のようにセッ
トアップされる。

【０３６９】まず、プロセス１０２（ａ）がプラン９
「ダイヤル」機能を用いて、プロセス１０２（ｂ）が作
動しようとするコンピュータシステム１４１３にダイヤ
ルする。「ダイヤル」機能の主題項目は、システム１４
１３のネットワ−ク名、及び接続を設立すべき先のプロ
トコルサービスの名前、この場合送出ファイルサービ
ス、である。

【０３７０】「ダイヤル」機能が成功すると、機能は、
システム１４１３によって与えられるサービス１２３に
ついてファイルオペレーションを行うことのできるチャ
ンネルについてのファイル記述子を返す。そして、この
オペレーションについてのプラン９プロトコルが、プロ
トコルチャンネル５１７上を移動する。

【０３７１】コンピュータシステム１４１３上で「リス
ナー（聴取者）」と名付けられるプロセスがネットワ−
クから受信されたメッセ−ジに応答して、メッセ−ジに
指定されるサービスを実行するためのプロセスを生成す
る。今の場合に生成されるプロセスはプロセス１０２
（ｂ）で、プロセス１０２（ｂ）は、送出ファイルサー
ビスコ−ド１４０９を実行する。プロセス１０２（ｂ）
の名前スペース１１５（ｂ）は、プロセス１０２（ａ）
がシステム１４１１において作動している対象のユ−ザ
についてのシステム１４１３上の名前スペースである。

【０３７２】本発明の一実施例において、システムの各
ユ−ザは、ユ−ザがシステムにログインすると実行され
る、「プロフィル」ファイルを有する。「リスナー」が
プロセス１０２（ｂ）を生成すると、「リスナー」は、
プロセス１０２（ｂ）をして、「ダイヤル」機能が実行
された対象の、システム１４１１内のユ−ザについて、
システム１４１３内で「プロフィル」ファイルを実行さ
せる。

【０３７３】そのユ−ザについての「プロフィル」ファ
イル内の「ｂｉｎｄ」及び「ｍｏｕｎｔ」機能コール
が、プロセス１０２（ｂ）についての名前スペース１１
５（ｂ）を構築する。

【０３７４】「プロフィル」ファイルは更に、プロセス
１０２（ｂ）によって用いられる標準入力及び標準出力
ファイルをセットするコールを有する。このセットアッ
プは、標準入力ファイルからの読み取りがプロトコルチ
ャンネル５１７からの読み取りであり、標準出力ファイ
ルへの書き込みがプロトコルチャンネル５１７への書き
込みであるように行われる。

【０３７５】プロセス１０２（ｂ）の名前スペース１１
５（ｂ）及び標準入力出力チャンネルをこのようにセッ
トアップしてから、プロセス１０２（ｂ）は、送出ファ
イルサービスコ−ド１４０９の実行を開始する。

【０３７６】一方、プロセス１０２（ａ）は、「ダイヤ
ル」機能によって与えられるチャンネルを用いて、「ｗ
ｒｉｔｅ」（書き込み）オペレーションを行う。書き込
まれるのは、名前スペース１１５（ａ）に取り込まれる
べきファイル樹木のルート部の名前スペース１１５
（ｂ）内のパス名である。すなわち、図１４の例では、
「書き込み」オペレーションにおけるパス名は、「／Ｏ
／Ｉ」である。

【０３７７】プロセス１０２（ｂ）は、プロセス１０２
（ａ）がパス名を書き込んだチャンネルにおいて読み取
り中である。プロセス１０２（ｂ）がパス名を受信する
と、プロセス１０２（ｂ）は、送出ファイルシステムコ
−ド１４０９内の初期設定コ−ドを実行する。これによ
って、ディレクトリ「Ｉ」１４０３を、プロセス１０２
（ｂ）によってプロセス１０２（ａ）に与えられつつあ
るファイル樹木のルート部にする作業が有効に行われ
る。このコ−ドについては、後に更に詳しく述べる。

【０３７８】もし初期設定が成功すると、プロセス１０
２（ｂ）は、プロセス１０２（ａ）によって指定される
ファイル樹木上でのファイルオペレーションの実行準備
ができたことを表示する確認メッセ−ジをプロセス１０
２（ａ）に送る。それから、プロセス１０２（ａ）は、
「ダイヤル」機能から受けたチャンネルを、名前スペー
ス１１５（ａ）内の望むディレクトリ、この場合はディ
レクトリ「Ｑ」１４０４、上にマウントする。

【０３７９】確認メッセ−ジを送った後、プロセス１０
２（ｂ）は、プロセス１０２（ａ）と接続されているチ
ャンネル上で読み取りオペレーションを行うループに入
る。プロセス１０２（ａ）は、名前スペースの一部分１
４０１内のファイル上でオペレーションを行おうと望む
都度、プロセス１０２（ａ）は機能コール１０５又は１
０７を行う。

【０３８０】この機能コールは、ファイルシステム１０
９（ａ）によってマウントサービス２０３（ａ）へのサ
ービスファイル要求に変えられる。そして、マウントサ
ービス２０３（ａ）は、このサービスファイル要求を、
同等のプラン９ファイルプロトコルについての「ｔメッ
セ−ジ」（送信メッセ−ジ）に変換する。

【０３８１】「ｔメッセ−ジ」は、プロトコルチャンネ
ル５１７を介してシステム１４１３に送られ、そこでプ
ロセス１０２（ｂ）によって直接に受信される。プロセ
ス１０２（ｂ）は、この「ｔメッセ−ジ」を、「ｔメッ
セ−ジ」内で指定されたオペレーションを実行するため
に名前スペース１１５（ａ）において要求されるファイ
ル機能コール１０５又は１０７に変換する。

【０３８２】ファイル機能コール１０５又は１０７がオ
ペレーションを完了すると、プロセス１０２（ｂ）は、
「ｒメッセ−ジ」を、プロトコルチャンネル５１７を介
してプロトコル０２（ａ）に返す。マウントサービス２
０３（ａ）がこの「ｒメッセ−ジ」を受信すると、マウ
ントサービス２０３（ａ）は、「ｔメッセ−ジ」を生成
した元のサービスファイル要求に応答して、「ｒメッセ
−ジ」の内容をファイルシステム１０９（ａ）に与え
る。

【０３８３】そして、ファイルシステム１０９（ａ）
は、サービスファイル要求を生成した機能コールに応答
して、この「ｒメッセ−ジ」の内容をプロセス１０２
（ａ）に与える。

【０３８４】したがって、プロセス１０２（ａ）から見
ると、プロセス１０２（ｂ）の名前スペースの一部分１
４０１内のファイル上でのオペレーションは、名前スペ
ース１１５（ａ）内の他のファイル上でのオペレーショ
ンと異ならない。そして、プロセス１０２（ｂ）は、送
出ファイルサービスコ−ド１４０９を実行しながら、実
は、名前スペースの一部分１４０１内のファイル樹木に
ついてのプロトコルサービスとしてオペレーションを行
っていることになる。

【０３８５】送出ファイルサービスの詳細（図１５） 図１５に、プロトコルサービスの一種である、「送出フ
ァイルサービス」１５０１の実施例の詳細を示す。送出
ファイルサービス１５０１の構造は、次の２つの要件の
結果として得られたものである。

【０３８６】・送出ファイルサービスは、名前スペース
１１５（ａ）に出現するパス名に基づくプラン９プロト
コルを、名前スペース１１５（ｂ）に出現するパス名に
基づくファイル機能コール１０５及び１０７に変換でき
なければならない。・送出ファイルサービスは、非閉塞
性（ノンブロッキング）でなければならない。すなわ
ち、ファイル機能コール１０５又は１０７が値を返す前
に新しい「ｔメッセ−ジ」を取り扱うことができなけれ
ばならない。

【０３８７】後に更に詳しく述べるように、上の第１の
要件は、プロトコルインタプリタデータベース構造（Ｐ
ＩＤＳ）１５１７によって取り扱われる。プロトコルイ
ンタプリタデータベース構造１５１７によって、名前ス
ペース１１５（ａ）内の名前スペースの一部分１４０１
についてのパス名と、名前スペース１１５（ｂ）内の名
前スペースの一部分１４０１についてのパス名との間
の、マッピングが得られる。

【０３８８】上の第２の要件は、ファイルアクセス機能
「ｒｅａｄ」、「ｗｒｉｔｅ」及び「ｏｐｅｎ」が、閉
塞性（ブロッキング）であるという事実から来ている。
すなわち、これらの機能のうちの１つを実行するプロセ
スは、ファイルシステム１０９及びサービス１２３が
「ｏｐｅｎ」、「ｒｅａｄ」、又は「ｗｒｉｔｅ」オペ
レーションが実際に完了するまで実行を一時停止する。

【０３８９】例えば、もし読み取られているファイル
が、キーボード又はマウスのような入力装置である場
合、「ｒｅａｄ」オペレーションは、入力装置のユ−ザ
が実際にデータを入力しないうちは完了しない。明らか
に、プロセス１０２（ｂ）は同じ名前スペース部分１４
０１内の他のファイル上でのオペレーションを指定する
プラン９プロトコルへの応答を終止できない。理由は、
ユ−ザがデータを入力装置に入力してしまうまで一時停
止状態に置かれているからである。

【０３９０】本発明の一実施例においては、この問題
は、従プロセスを用いることによって解決される。図１
５のプロセス１０２（ｂ）には、このような１組（セッ
ト）の従プロセスが利用可能である。

【０３９１】プロセス１０２（ｂ）が、閉塞性のファイ
ルアクセス機能コール１０５に変換しなければならない
「ｔメッセ−ジ」を受信する都度、プロセス１０２
（ｂ）は、プロトコルに応答するために行うべき仕事を
従プロセス１５１５に回し、この従プロセス１５１５
は、プロトコルを適切なファイルアクセス機能コールに
変換する。そして、ファイルアクセス機能が実行を完了
すると、従プロセスによって実行されたコ−ドが、結果
を適切な「ｒメッセ−ジ」に変換して、プロトコルチャ
ンネル５１７に与える。

【０３９２】図１５について更に詳しく説明すると、プ
ロセス１０２（ｂ）及び従プロセス１５１５は、図１５
においては長円形に表されている。矢印は、これらプロ
セスに出入りするデータ及び命令の流れを表す。破線は
子プロセスを示す。送出ファイルサービスコ−ド（以
下、コ−ドと略称）１４０９から命令が出されるが、こ
のコ−ド１４０９は、ここでの説明の目的のためには、
次に示す成分に分割できる。

【０３９３】・「ＩＮＩＴ」（初期設定）１５０３。こ
れは、プロトコルチャンネル５１７とプロトコルインタ
プリタデータベース構造１５１７とをセットアップす
る。 ・「ＲＤＬＯＯＰ」（読み取りループ）１５０５。これ
は、プロトコルチャンネル５１７から「ｔメッセ−ジ」
１５２１を読み取る。

【０３９４】・「ＰＩ」（プロトコルインタプリタ）１
５０７。これは、「ｔメッセ−ジ」１５２１をファイル
オペレーション機能コール１０５及び１０７に変換す
る。プロトコルインタプリタは、次に示す２つのサブ成
分を有する。 ａ．「ＮＢＰＩ」（非閉塞性プロトコルインタプリタ）
１５０９。非閉塞性ファイルオペレーションを指定する
全ての「ｔメッセ−ジ」を適切なファイルオペレーショ
ン１０５及び１０７に変換する。

【０３９５】ｂ．「ＢＰＩ」（閉塞性プロトコルインタ
プリタ）１５１１。これは、「ｒｅａｄ」、「ｗｒｉｔ
ｅ」、及び「ｏｐｅｎ」の「ｔメッセ−ジ」１５２１
を、「ｒｅａｄ」、「ｗｒｉｔｅ」及び「ｏｐｅｎ」の
ファイル機能コール１０５に変換する。 ・「ＲＥＰＬＹ」（回答）１５１３。この成分は、ファ
イルオペレーション機能コール１０５又は１０７の結果
を「ｒメッセ−ジ」に変換し、プロトコルチャンネル５
１７に与える。

【０３９６】送出ファイルサービス１５０１は、次のよ
うに行われる。プロセス１０２（ｂ）がコ−ド１４０９
の実行を開始するとき、プロセス１０２（ｂ）は既に名
前スペース１１５（ｂ）を有し、その標準入出力はプロ
トコルチャンネル５１７に向けられている。実行すべき
コ−ド１４０９の最初の部分は、「ＩＮＩＴ」（初期設
定）１５０３である。

【０３９７】この「初期設定」１５０３は、まずプロセ
ス１０２（ｂ）をそれ自身の新しいプロセスグループ１
０３に置く。その結果、名前スペース１１５（ｂ）は今
やプロセス１０２（ｂ）だけに属することとなり、「リ
スナー」プロセスによってプロセス１０２（ｂ）に与え
られるような、名前スペースにおいてなされる変化は、
名前スペース１１５（ｂ）には反映されない。更に、プ
ロトコルインタプリタデータベース構造１５１７の成分
のうちのいくつかについて、記憶域が割り当てられる。

【０３９８】次に、「初期設定」１５０３は、プロトコ
ルチャンネル５１７を読む。この時点では、プロトコル
チャンネル５１７は送出すべき名前スペースのルート部
の仕様を与える。それから「初期設定」１５０３は、デ
ィレクトリをルート部の仕様において指定されるファイ
ルに変更し、マッピングを行う「ＰＩ」（プロトコルイ
ンタプリタデータベース構造）１５１７内の、マッピン
グを行う部分を初期設定する。

【０３９９】「ＲＤＬＯＯＰ」（読み取りループ）１５
０５が次に、プロトコルチャンネル５１７から「ｔメッ
セ−ジ」１５２１を読み取る。各「ｔメッセ−ジ」はバ
ッファ内に置かれ、そのバッファは「プロトコルインタ
プリタデータベース構造」１５１７に与えられる。

【０４００】もし「ｔメッセ−ジ」が「ｒｅａｄ」、
「ｗｒｉｔｅ」、又は「ｏｐｅｎ」オペレーション以外
を指定する場合、プロセス１０２（ｂ）は、「ＮＢＰ
Ｉ」（非閉塞性プロトコルインタプリタ）１５０９にお
いてコ−ドを実行し、「読み取りループ」１５０５から
受信したバッファ内の情報と、「プロトコルインタプリ
タデータベース構造」１５１７内の情報とを用いて、バ
ッファ内の情報をファイルオペレーション機能コール１
０５又は１０７に変換する。ファイルオペレーション機
能コール１０５又は１０７は、前に述べたように、ファ
イルシステム１０９（ｂ）へ行く。

【０４０１】もし「ｔメッセ−ジ」が「ｒｅａｄ」、
「ｗｒｉｔｅ」、又は「ｏｐｅｎ」オペレーションを指
定する場合、プロセス１０２（ｂ）は、従プロセス１５
１５を１つ取り、バッファをこの従プロセスに回す。す
ると、従プロセス１５１５は、「ＢＰＩ」（閉塞性プロ
トコルインタプリタ）１５１１においてコ−ドを実行
し、バッファの内容と、「プロトコルインタプリタデー
タベース構造」１５１７の内容とを用いて、バッファ内
の情報を「ｒｅａｄ」、「ｗｒｉｔｅ」、又は「ｏｐｅ
ｎ」ファイルアクセス機能コール１０５に変換する。

【０４０２】本発明の一実施例において、従プロセス１
５１５は、軽量級のプロセスで、自分のスタックは有す
るが、メモリ及びファイル記述子テーブルの両方をプロ
セス１０２（ｂ）と共用する。

【０４０３】最終的に、ファイル機能コール１０５又は
１０７が返されると、「ＲＥＰＬＹ」（回答）１５１３
成分においてコ−ドが、ファイル機能コール１０５又は
１０７を行ったプロセスによって実行される。

【０４０４】プロトコルインタプリタデータベース構造
１５１７の詳細（図１６、図１７） 以下、プロトコルインタプリタデータベース構造１５１
７の詳細について述べるが、最初にデータ構造の主要要
素について説明し、次にこれらの要素がどのように組み
合わされるかを示し、最後に、「ｔメッセ−ジ」１５２
１のファイル機能コール１０５又は１０７への変換と
「ｒメッセ−ジ」１５１９の生成とに、データ構造１５
１７がどのように用いられるか、について述べる。プロ
トコルインタプリタデータベース構造１５１７は、次に
示す異なる４種類の要素から構成される。

【０４０５】・「ＦＲＳＰＣ」１６０１。これは、「ｔ
メッセ−ジ」１５２１から受信されたデータを含む。 ・「ＦＩＤ」１６０９。これは、名前スペース１１５
（ａ）の一部分１４０１内のファイルを識別するために
マウントサービス２０３（ａ）が用いる「ＦＩＤ」（フ
ァイル識別子）３３１に対応し、ファイルにアクセスす
るために必要な情報を有する。

【０４０６】・「ＦＳ」（ファイル構造）１６２３。こ
れは、名前スペース１１５（ａ）の一部分１４０１から
名前スペース１１５（ｂ）の一部分１４０１へ名前をマ
ッピングするために用いられる。 ・「ＳＰＲＯＣ」（従プロセス構造）１６３５。従プロ
セス１５１５のうちの１つを表す。

【０４０７】「ＦＲＳＰＣ」要素１６０１から始まり、
このような構造の配列（アレイ）が、送出ファイルサー
ビスコ−ド１４０９の「ＮＮＩＴ」（初期設定）成分１
５０３によって割り当てられる。

【０４０８】コ−ド１４０９の「ＲＤＬＯＯＰ」（読み
取りループ）成分１５０５が実行される都度、アレイ内
の使用中でない（ノンビジー）要素が探索され、プロト
コルチャンネル５１７から読み取られた「ｔメッセ−
ジ」１５２１内のデータが、アレイ内のノンビジー要素
に置かれる。その後この要素は、「ｔメッセ−ジ」１５
２１に対応する「ｒメッセ−ジ」１５１９が送られるま
で使用中（ビジー）の状態を継続する。

【０４０９】ここでの説明に関連する「ＦＲＳＰＣ」要
素１６０１のフィールドは３種類である。第１は「ＢＵ
ＳＹ」フィールド１６０３で、「ＦＲＳＰＣ」１６０１
が現在使用中であることを表示する。第２は「ＷＯＲ
Ｋ」フィールド１６０５で、どのような種類の「ｔメッ
セ−ジ」１５２１が受信されたかを表示する。最後は
「ＤＡＴＡ」フィールド１６０７で、「ｔメッセ−ジ」
１５２１で受信されたデータが含まれる。

【０４１０】次に「ＦＩＤ」要素１６０９のフィールド
について説明する。「ＦＤ」（ファイル記述子）フィー
ルド１６１１は、名前スペースの一部分１４０１内のフ
ァイルにアクセスするためにファイルシステム１０９
（ｂ）が用いるファイル記述子４１７である。「ＯＦ
Ｆ」（オフセット）フィールド１６１３は、「ファイル
記述子」フィールド１６１１によって指定されるファイ
ル内の位置を表示する。

【０４１１】「ＦＳＰＴＲ」（ファイル構造ポインタ）
フィールド１６１５は、「ファイル記述子」フィールド
１６１１によって指定されるファイルを表す「ファイル
構造」要素１６２３を指し示すポインタである。「ＭＯ
ＤＥ」（モード）フィールド１６１７は、「ファイル記
述子」フィールド１６１１によって指定されるファイル
のモードを表示する。

【０４１２】「ＦＩＤ」（ファイル識別子）ファイル６
１９は、「ファイル記述子」フィールド１６１１によっ
てファイルシステム１０９（ｂ）内に指定されるファイ
ルを表すためにマウントサービス２０３（ａ）が用いる
「ＦＩＤ」フィールド３３１である。最後に、「ＮＥＸ
Ｔ」（次）フィールド１６２１は、一連の「ＦＩＤ」１
６１９内の次の要素を指し示すポインタである。

【０４１３】プロトコルインタプリタデータベース構造
１５１７の「ＦＳ」（ファイル構造）１６２３のフィー
ルドを次に示す。すなわち、「ＮＡＭＥ」（名前）フィ
ールド１６２５は、名前スペースの一部分１４０１内の
ファイルの名前である。

【０４１４】「ＰＱＩＤ」（プロトコルＱＩＤ）フィー
ルド１６２７は、ファイルシステム１０９（ａ）のデー
タ構造において用いるために送出ファイルサービスがフ
ァイルシステム１０９（ａ）に与える「ＱＩＤ」フィー
ルド３２３である。これは、ファイルシステム１０９
（ｂ）がそのファイルを知るための「ＱＩＤ」フィール
ド３２３と同じではない。

【０４１５】残る３種類のフィールド、「ＰＡＲＥＮ
Ｔ」１６２９、「ＣＨＩＬＤ」（子）１６３１、及び
「ＣＨＬＩＳＴ」（子リスト）１６３３は、他のファイ
ル構造１６２３を指し示すポインタである。これら３種
類のポインタについては下に詳しく述べる。

【０４１６】「ＳＰＲＯＣ」（従プロセス構造）１６３
５は、連結リスト内の要素の１つで、各々１つの従プロ
セス１５１５を表す。この要素は３種類のフィールドを
有する。第１は、「ＰＩＤ」（プロセス識別子）フィー
ルド１６３７で、その要素によって表される従プロセス
１５１５のプロセス識別子である。「ＢＵＳＹ」（ビジ
ー）フィールド１６３９は、その要素によって表される
従プロセス１５１５が現在使用中であることを表示す
る。最後に「ＮＥＸＴ」（次）フィールド１６４１は、
連結リスト内の次の要素を指し示すポインタである。

【０４１７】図１７は、送出ファイルサービスのオペレ
ーションに際して、図１６に示すデータ構造がどのよう
に用いられるかを示す。「ＦＩＤ」（ファイル識別子）
３３１が「ｔメッセ−ジ」１５２１から受信されると、
ハッシング機能１７０１に与えられ、ハッシング機能１
７０１は、ファイル識別子３３１に応答して、チェイン
ポインタ１７０３を「ＦＩＤ」（ファイル識別子）デー
タ構造１６０９のチェイン１７０５に与える。

【０４１８】チェイン１７０５内の「ＦＩＤ」データ構
造１６０９の１つは、「ＦＩＤ」３３１によって表され
るファイルについてのデータ構造１６０９であり、「Ｆ
ＩＤ」フィールド１６１９内にその「ＦＩＤ」３３１を
有する。「ＦＩＤ」データ構造１６０９からの「ＦＳＰ
ＴＲ」（ファイル構造ポインタ）フィールド１６１５
は、「ＦＩＤ」３３１によって表されるファイルについ
ての「ＦＳ」（ファイル構造）１６２３を指し示す。

【０４１９】「ＦＳ」（ファイル構造）１６２３は、フ
ァイル樹木１７０７に編成される。このファイル樹木１
７０７は、名前スペース１１５（ｂ）の一部分１４０１
内のファイル樹木を表すものである。ファイル樹木１７
０７が完成すると、名前スペースの一部分１４０１内の
各ファイルは、ファイル構造１６２３によって表され、
ファイル構造１６２３は、対応するファイル樹木が名前
スペースの一部分１４０１のファイル樹木内で占めるの
と同じスペースをファイル樹木１７０７内で占める。

【０４２０】このことは、図１７においてブロック１６
２３内の英字によって表され、これらの英字は、「ＮＡ
ＭＥ」フィールド１６２５内の名前を表す。ルートブロ
ック１６２３は、名前スペースの一部分１４０１のファ
イル樹木のルートディレクトリの名前スペース１１５
（ｂ）内の全パス名を含む。すなわち、この場合には、
パス名「／Ｏ／Ｉ」を含む。

【０４２１】本発明の一実施例において、ルート部は、
コ−ド１４０９の「ＩＮＩＴ」（初期設定）コ−ド成分
１５０３によって創設される。初期設定コ−ド成分１５
０３は、ディレクトリを名前スペースの一部分１４０１
のルート部に変更した後、現ディレクトリのパス名を
「ＮＡＭＥ」フィールド１６２５に置き、「ＰＱＩＤ」
１６２７フィールドについて「ＰＱＩＤ」を作成する。
「ＰＱＩＤ」は、ファイル樹木１７０７に独特な方法で
生成される。

【０４２２】樹木は、「ＦＳ」（ファイル構造）１６２
３内の３種類のポインタフィールド１６２９、１６３
１、及び１６３３によって編成される。図１７に示すよ
うに、「ＰＡＲＥＮＴ」ポインタフィールド１６２９
は、樹木１７０７内のファイル構造１６２３に親があれ
ばその親を指し示し、「ＣＨＩＬＤ」ポインタフィール
ド１６３１は、樹木１７０７内のファイル構造１６２３
に子があればその第１の子を指し示し、「ＣＨＬＩＳ
Ｔ」ポインタフィールド１６３３は樹木１７０７内のフ
ァイル構造１６２３に次の子があればその子を指し示
す。

【０４２３】最後に、「ＳＰＲＯＣ」（従プロセス構
造）１６３５が、これら従プロセス構造チェイン１７０
９に編成される。

【０４２４】送出ファイルサービス１５０１によって行
われるファイルオペレーション プロセス１０２（ｂ）がコ−ド１４０９の「ＲＤＬＯＯ
Ｐ」（読み取りループ）成分１５０５の実行を開始する
時点においては、単一のファイル構造１６２３、すなわ
ちルート部についてのファイル構造、から構成されるよ
うな「ＦＩＤ」（ファイル識別子）チェイン１７０５も
ファイル樹木１７０７も、存在しない。名前スペースの
一部分１４０１が使用できるようになる前に、「ａｔｔ
ａｃｈ」サービスファイル探索要求が処理されなければ
ならない。

【０４２５】送出ファイルサービス１５０１はプロセス
サービス２０９であるので、送出ファイルサービス１５
０１において最初に受信される「ｔメッセ−ジ」１５２
１は、「ａｔｔａｃｈ」オペレーションを指定する「ａ
ｔｔａｃｈ」メッセ−ジである。「ａｔｔａｃｈ」メッ
セ−ジのうち、ここでの説明で重要な部分は、マウント
サービス２０３（ａ）が名前スペースの一部分１４０１
のルート部を識別するために使用中の、「ＦＩＤ」（フ
ァイル識別子）３３１である。

【０４２６】「ａｔｔａｃｈ」の「ｔメッセ−ジ」を受
信すると、コ−ド１４０９の「ＲＤＬＯＯＰ」成分１５
０５は、「ＦＩＤ」３３１を、「ＦＳＲＰＣ」構造１６
０１の「ＷＯＲＫ」フィールド１６０５に置く。それか
らコ−ド１４０９の「ＮＢＰＩ」（非閉塞性プロトコル
インタプリタ）成分が、名前スペースの一部分１４０１
のルート部であるフィールドに対応する「ＦＩＤ」構造
１６１９を得る。

【０４２７】「ＦＩＤ」構造１６１９を得るということ
は、「ＦＩＤ」３３１についての「ＦＩＤ」構造１６０
９が存在する筈の「ＦＩＤ」チェインを探索するため
に、「ＦＩＤ」３３１を「ＷＯＲＫ」フィールド１６０
５からハッシング機能１７０１に与えることに関連す
る。もし「ＦＩＤ」構造１６０９が「ＦＩＤ」チェイン
１７０５内に既にある場合には、ポインタ１６１５がフ
ァイル樹木１７０７のルート部であるファイル構造１６
２３を指し示すことになる。

【０４２８】そうでなければ、「ＦＩＤ」構造を「ＦＩ
Ｄ」チェインに追加しなければならない。これは、「Ｆ
ＩＤ」構造１６０９を構造のフリーリストから得ること
と、「ＦＩＤ」構造１６０９を適切な「ＦＩＤ」チェイ
ン１７０５内に置くこととによって行われる。これが済
むと、「ＦＩＤ」３３１は、「ＦＩＤ」フィールド１６
１９に置かれ、「ＦＳＰＴＲ」（ファイル構造ポイン
タ）１６１５がファイル樹木１７０７のルート部を指し
示すようにセットされる。

【０４２９】次に、「ＦＩＤ」３３１と、ルートファイ
ル構造内の「ＰＱＩＤ」（プロトコルＱＩＤ）フィール
ド１６２７の内容とが、コ−ド１４０９の「ＲＥＰＬ
Ｙ」（回答）成分１５１３に与えられる。これには、
「ＦＩＤ」としての「ＦＩＤ」３３１と、マウントサー
ビス２０３（ａ）に返される「ａｔｔａｃｈ」メッセ−
ジ内の「ＱＩＤ」３２３としての「ＰＱＩＤ」フィール
ド１６２７とが含まれる。前に「プラン９サービスのア
ーキテクチャの概観」の項で述べたように、「ｑｉｄ」
はサービス１２３によって与えられるファイルハンドル
である。

【０４３０】送出ファイルサービス１５０１の重要な面
は、送出ファイルサービスが、それによってファイルシ
ステム１０９（ｂ）がファイルを知ることができる「Ｑ
ＩＤ」３２３をでなくて、合成「ＱＩＤ」３２３である
「ＰＱＩＤ」１６２７を、マウントサービス２０３
（ａ）に返す、ということである。後に更に詳しく述べ
るように、必要な場合には、ファイルについての実際の
「ＱＩＤ」３２３がプロトコル０２（ａ）に与えられる
ように構成される。

【０４３１】ルートディレクトリがアタッチ（付加）さ
れると、オペレーションは「ｗａｌｋ」機能コールによ
ることとなり、これは、この場合には「ｔｗａｌｋ」ｔ
メッセ−ジとなる。「ｔｗａｌｋ」ｔメッセ−ジは、
「ＦＩＤ」３３１を有し、これはこの時点では、現ディ
レクトリと、現ディレクトリの親又は現ディレクトリの
子の１つのいずれかを表示する名前とを表す。

【０４３２】「ｒｗａｌｋ」ｒメッセ−ジは、「ＦＩ
Ｄ」３３１を有し、これは今や、ウオークされたファイ
ルと、そのファイルの「ＱＩＤ」３２３とを表す。もし
ディレクトリがアタッチされたばかりであれば、現ディ
レクトリはもちろんルートディレクトリである。

【０４３３】「ｔｗａｌｋ」ｔメッセ−ジがファイルの
名前として「Ｊ」を指定すると仮定すると、コ−ド１４
０９の「ＮＢＰＩ」（非閉塞性プロトコルインタプリ
タ）成分１５０９は、次のようにオペレーションを行
う。

【０４３４】すなわち、「ＮＢＰＩ」１５０９は、「ｔ
ｗａｌｋ」ｔメッセ−ジから「ＦＩＤ」３３１を用い
て、「ＦＩＤ」データ構造１６０９（この場合、ルート
部についての「ＦＩＤ」データ構造１６０９）を探索
し、それから「ＦＳＰＴＲ」（ファイル構造ポインタ）
１６１５に従って、対応するファイル構造１６２３、こ
こではファイル樹木１７０７のルート部についてのファ
イル構造、を探索する。

【０４３５】現在、ファイル樹木１７０７は、ルート部
だけから構成され、したがって、「ＣＨＩＬＤ」ポイン
タ１６３１は「０」にセットされる。この場合には、フ
ァイル「Ｊ」についての新しい「ＦＳ」（ファイル構
造）１６２３が割り当てられ且つファイル樹木１７０７
内の適切な場所に置かれる必要がある。

【０４３６】最初のステップは、ファイル「Ｊ」がルー
トディレクトリの子として存在するかどうかの点検であ
る。これは、ファイル「Ｊ」についてのパス名を作るこ
とによって行われる。パス名は、名前「Ｊ」を、ファイ
ル樹木１７０７のルート部を通してファイル「Ｊ」の全
ての親の名前と組み合わせることによって作られる。フ
ァイル樹木１７０７のルート部は名前スペースの一部分
１４０１についてのルートディレクトリの完全なパス名
を有するので、結果として、ファイル「Ｊ」の完全なパ
ス名、この場合「／Ｏ／Ｉ／Ｊ」、が得られる。

【０４３７】そして、この完全なパス名が、ファイルシ
ステム１０９（ｂ）への「ｄｉｒｓｔａｔ」ファイルシ
ステム機能コール１０５において用いられて、ファイル
が存在することが確認される。ファイル「Ｊ」が存在す
るので、次のステップは、新しい「ＦＳ」（ファイル構
造）１６２３を割り当てることである。

【０４３８】新しいファイル構造１６２３において、
「ＮＡＭＥ」（名前）フィールド１６２５が、「Ｊ」に
セットされ、「ＰＱＩＤ」フィールド１６２７について
の値が生成され、「ＰＡＲＥＮＴ」ポインタ１６２９
が、ルートファイル構造１６２３を指し示すようにセッ
トされる。ルートファイル構造１６２３において、「Ｃ
ＨＩＬＤ」ポインタ１６３１が、新しいファイル構造１
６２３を指し示すようにセットされる。

【０４３９】新しいファイル構造１６２３がファイル樹
木１７０７に付加されると、新しいファイル構造を指し
示すポインタが、「ＦＩＤ」３３１についての「ＦＩ
Ｄ」構造１６０９内の「ＦＳＰＴＲ」フィールド１６１
５内に置かれる。そして、コ−ド１４０９の「回答」成
分１５１３が、「ＦＩＤ」３３１を「ｔｗａｌｋ」メッ
セ−ジから返し、「ＰＱＩＤ」１６２７を、ファイル
「Ｊ」についての新しいファイル構造１６２３から、
「ｒｗａｌｋ」メッセ−ジ内の「ＦＩＤ」３３１及び
「ＱＩＤ」３２３として返す。

【０４４０】もちろん、もしファイル樹木１７０７内に
そのファイルについてのファイル構造１６２３が既にあ
る場合には、必要なことは、「ＰＱＩＤ」１６２７をそ
のファイル構造１６２３から、「ｒｗａｌｋ」メッセ−
ジ内で返される「ＱＩＤ」３２３として与えることだけ
である。

【０４４１】同様に、もしファイル名が、現在のファイ
ルの親であることを表示する「．．」の場合には、必要
なことは、ファイル樹木１７０７内の「ＦＩＤ」３３１
によって表されるファイルについてのファイル構造１６
２３を探索すること、親ファイル構造１６２３を指し示
す「ＰＡＲＥＮＴ」ポインタ１６２９に従うこと、及び
親から「ＰＱＩＤ」１６２７を、「ｒｗａｌｋ」メッセ
−ジ内で返される「ＱＩＤ」３２３として与えることだ
けである。

【０４４２】名前スペース１１５（ｂ）内にファイル
「Ｊ」が存在するかどうかを定めるために用いられる上
記の方法は、名前スペース１１５（ａ）内の、名前スペ
ースの一部分１４０１からの名前を名前スペース１１５
（ｂ）内の名前スペースの一部分１４０１からの名前上
にマッピングするために送出ファイルサービス１５０１
において用いられる一般的技術の一例である。

【０４４３】この一般的技術は、ファイルについてのフ
ァイル樹木１７０７内のエントリを探索するためにその
ファイルについての「ＦＩＤ」構造１６０９を用い、名
前スペース１１５（ｂ）内のファイルについて望む完全
パス名を生成するためにファイル樹木１７０７を用い、
それから、ファイルシステム１０９（ｂ）へのファイル
探索機能コールにおいてその完全パス名を用いることで
ある。

【０４４４】名前スペースの一部分１４０１内にファイ
ルを創設するために、プロセス１０２（ａ）は、「ｃｒ
ｅａｔｅ」機能コールを用いる。その結果、マウントサ
ービス２０３が「ｔｃｒｅａｔｅ」ｔメッセ−ジ１５２
１を送出ファイルサービス１５０１に送ることになる。

【０４４５】「ｔｃｒｅａｔｅ」ｔメッセ−ジ１５２１
には、「ＦＩＤ」３３１が含まれ、この「ＦＩＤ」３３
１は現時点において新ファイルを包含する予定のディレ
クトリと、新ファイルについての名前と、新ファイルに
ついての許可事項とモード、すなわちどのような種類の
オペレーションが新ファイル上で許可されるか、とを表
す。「ｒｃｒｅａｔｅ」ｒメッセ−ジは、今や新ファイ
ルを表す「ＦＩＤ」３３１と、新ファイルについての
「ＱＩＤ」３２３とを含む。

【０４４６】コ−ド１４０９の「ＲＤＬＯＯＰ」成分１
５０５が「ｔメッセ−ジ」を読み取った後、メッセ−ジ
内の情報は、使用中でない「ＦＳＲＰＣ」構造の「ＷＯ
ＲＫ」フィールド１６０５に置かれて、「ＮＢＰＩ」
（非閉塞性プロトコルインタプリタ）１５０９に与えら
れる。ここで行われる最初のステップは、「ＦＩＤ」３
３１に対応する「ＦＩＤ」構造１６０９を取り、新ファ
イルが創設されるディレクトリについてのファイル構造
１６２３を指し示す構造ポインタ１６１５に従うことで
ある。

【０４４７】次に、「ｔメッセ−ジ」で受信された名前
と、ファイル樹木内のファイル構造１６２３及びその祖
先ファイル内の名前とを用いて、新ファイルについての
完全パス名が作られる。それから、この完全パス名と、
「ｔｃｒｅａｔｅ」メッセ−ジからのモード及び許可事
項についての情報は、ファイルシステム１０９（ｂ）へ
のファイルシステム「ｃｒｅａｔｅ」機能コールにおい
て用いられる。

【０４４８】この「ｃｒｅａｔｅ」コールは、新ファイ
ルについてのファイル記述子を返し、このファイル記述
子は、「ＦＩＤ」３３１に対する「ＦＩＤ」構造１６０
９のファイル記述子フィールド１６１１へコピーされ
る。

【０４４９】新ファイルが創設されたので、このファイ
ルについて新しいファイル構造１６２３を作る必要があ
る。新しいファイル構造１６２３においては、「ｔｃｒ
ｅａｔｅ」メッセ−ジで受信された名前が、「ＮＡＭ
Ｅ」フィールド１６２５に置かれ、このファイルについ
ての新しい「ＰＱＩＤ」が合成されて「ＰＱＩＤ」フィ
ールド１６２７に置かれる。

【０４５０】そして最終的に、このファイルが創設され
たディレクトリについてのファイル構造１６２３に対す
る子ファイル構造１６２３のリストの先頭に、新しいフ
ァイル構造１６２３が行くように、このファイルについ
ての新しいファイル構造１６２３内のポインタがセット
される。

【０４５１】最後のステップは、「ＦＩＤ」３３１に対
する「ＦＩＤ」フィールド１６０９内の新ファイルにつ
いてのファイル構造１６２３を指し示すポインタを置
き、「ＦＩＤ」構造１６０９内の「ＭＯＤＥ」フィール
ド１６１９を、「ｔｃｒｅａｔｅ」メッセ−ジデータ受
信された値にセットし、「ＯＦＦＳＥＴ」フィールド１
６１３を「０」にセットし、そして「ｒｃｒｅａｔｅ」
メッセ−ジで返すべき、コ−ドの「ＲＥＰＬＹ」（回
答）成分１５１３に、「ＦＩＤ」３３１と「ＰＱＩＤ」
１６１７を与えることである。

【０４５２】プロセス１０２（ａ）によるファイルシス
テム１０９（ａ）への「ｏｐｅｎ」ファイルコールの結
果、開かれるべきファイルについての「ＦＩＤ」３３１
と、このファイルを開く際のモードを指定する値とを含
む「ｔｏｐｅｎ」メッセ−ジが得られる。この「ｔｏｐ
ｅｎ」メッセ−ジは、この開かれたファイルについての
「ＦＩＤ」３３１と「ＱＩＤ」３２３とを含む。

【０４５３】「ｏｐｅｎ」ファイルコールは、コールを
行うプロセス１０２をブロックすることになる。その結
果、プロセス１０２（ｂ）は、従プロセスチェイン１７
０９から従プロセス１５１５を１つ取り、「ｔｏｐｅ
ｎ」ｔメッセ−ジから作られた「ＦＳＲＰＣ」１６０１
をこの従プロセス１５１５に回す。それから、この従プ
ロセスは、この「ｔｏｐｅｎ」ｔメッセ−ジについてコ
−ドを「ＢＰＩ」（閉塞性プロトコルインタプリタ）成
分１５１１において実行する。

【０４５４】「ｏｐｅｎ」オペレーションの場合、開く
べきファイルは、「ｗａｌｋ」ファイルコール又は「ｃ
ｒｅａｔｅ」ファイルコールによって既に探索され見出
されている。したがって、開くべきファイルについての
ファイル構造１６２３を指し示すファイル構造ポインタ
１６１５を有する「ＦＩＤ」３３１に対する「ＦＩＤ」
構造１６０９が存在する筈である。

【０４５５】このファイルについての「ＦＩＤ」構造１
６０９及びファイル構造１６２３が探索され見出される
と、このファイルについての完全パス名が、ファイル樹
木内のこのファイル及びその祖先ファイルについてのフ
ァイル構造１６２３内の「ＮＡＭＥ」フィールド１６２
５から作られて、「ｔｏｐｅｎ」ｔメッセ−ジからのモ
ードで「ｏｐｅｎ」ファイルコールにおいて用いられ
る。

【０４５６】「ｏｐｅｎ」ファイルコールは、開かれた
ファイルについてのファイル記述子４１７を返し、この
ファイル記述子４１７は、「ＦＩＤ」３３１に対する
「ＦＩＤ」構造１６０９の「ＦＤ」フィールド１６１１
内に置かれる。その「ＦＩＤ」構造１６０９の「ＭＯＤ
Ｅ」フィールド１６１７が、「ｔメッセ−ジ」によって
与えられる値にセットされ、「ＯＦＦＳＥＴ」フィール
ド１６１３が「０」にセットされる。

【０４５７】「ＲＥＰＬＹ」（回答）１５１３が、「ｒ
ｏｐｅｎ」メッセ−ジ内の開かれたファイルについての
ファイル構造１６２３から「ＦＩＤ」３３１及び「ＰＱ
ＩＤ」フィールド１６２７を返す。「ＲＥＰＬＹ」（回
答）１５１３が実行された後、従プロセス１５１５に対
する従プロセス構造１６３５内の「ＢＵＳＹ」フィール
ドが、「０」にセットされる。

【０４５８】「ｒｅａｄ」及び「ｗｒｉｔｅ」ファイル
オペレーションの場合、これらのオペレーションは、既
に探索され見出されて開かれているファイル上で行われ
る。両オペレーションについての一例として、「ｒｅａ
ｄ」（読み取り）オペレーションについて説明する。

【０４５９】「ｒｅａｄ」オペレーションについての
「ｔメッセ−ジ」には、「ＦＩＤ」３３１と、「読み取
り」が始まる位置のオフセットと、読み取るべきバイト
数とが含まれる。又、「ｒｅａｄ」オペレーションにつ
いての「ｒメッセ−ジ」には、「ＦＩＤ」３３１と、読
み取るべきバイト数と、読み取られたデータとが含まれ
る。

【０４６０】コ−ド１４０９の「ＲＤＬＯＯＰ」成分１
５０５が「ｔｒｅａｄ」メッセ−ジを受信すると、「Ｒ
ＤＬＯＯＰ」成分１５０５は、従プロセス１５１５を取
り、この従プロセス１５１５に「ｔｒｅａｄ」メッセ−
ジからのデータを含む「ＦＳＲＰＣ」構造１６０１を回
す。そして、従プロセス１５１５が、「ＢＰＩ」（閉塞
性プロトコルインタプリタ）１５１１において、「ｒｅ
ａｄ」コ−ドを実行する。

【０４６１】この読み取り中のファイルは既に探索され
見出されて開かれているので、「ｔメッセ−ジ」で受信
された「ＦＩＤ」３３１に対応する「ＦＩＤ」１６０９
は、フィールド１６１１において読み取られるべきこの
ファイルについてのファイル記述子４１７を既に有して
いる。もし「ＯＦＦＳＥＴ」フィールド１６１３が、
「ｔメッセ−ジ」で受信された「ＯＦＦＳＥＴ」と同じ
でない場合には、この「ＯＦＦＳＥＴ」は、「ｔメッセ
−ジ」に指定された「ＯＦＦＳＥＴ」へ動かされる。

【０４６２】それから、「ｔｒｅａｄ」メッセ−ジで
「ＯＦＦＳＥＴ」によって指定される場所において始ま
る「ＦＩＤ」３３１によって指定されるファイルの読み
取りが、ファイルシステム１０９（ｂ）への「ｒｅａ
ｄ」ファイルシステムコールを用いて行われる。

【０４６３】読み取りが完了すると、「ＦＩＤ」３３１
の「ＦＩＤ」構造１６０９内の「ＯＦＦＳＥＴ」フィー
ルド１６１３が、旧「ＯＦＦＳＥＴ」に読み取られたバ
イト数を加えたものにセットされ、「ＲＥＰＬＹ」（回
答）１５１３が、「ＦＩＤ」３３１と、「ｔｒｅａｄ」
メッセ−ジで受信されたカウントと、「ｒｒｅａｄ」メ
ッセ−ジで読まれたデータとを返す。ここで再び、「Ｓ
ＰＲＯＣ」（従プロセス構造）１６３５内の「ＢＵＳ
Ｙ」フィールド１６３９が。「０」にセットされる。

【０４６４】上記の説明から、又前の「プラン９サービ
スのアーキテクチャの概観」の項におけるサービスファ
イルオペレーションの記述から、「ｒｅｍｏｖｅ」、
「ｃｌｏｎｅ」、及び「ｃｌｕｎｋ」オペレーションが
どのようにして送出ファイルサービス１５０１において
実現されるかは、当業者には明かである。

【０４６５】しかし、ファイルの状態を読み取る「ｓｔ
ａｔ」オペレーションは、オペレーションにおける「Ｑ
ＩＤ」３２３の役割の点で、少し重要度が高い。「ｔｓ
ｔａｔ」メッセ−ジは、状態を読み取られるべきファイ
ルについての「ＦＩＤ」３３１だけを含む。

【０４６６】「ＦＩＤ」３３１を用いて、「ＦＩＤ」３
３１についての「ＦＩＤ」構造１６０９が探索され、フ
ァイル構造ポインタ１６１５を用いてファイルについて
の樹木１７０７内の「ＦＳ」（ファイル構造）１６２３
が探索される。それから、「ＦＩＤ」３３１によって指
定されるファイルについての全パス名が、ファイル樹木
１７０７から得られ、「ｓｔａｔ」ファイルアクセス機
能コールにおいて用いられる。

【０４６７】「ｓｔａｔ」コールは、ファイルシステム
１０９（ｂ）内でこのファイルを判るための「ＱＩＤ」
を含む情報を返す。「ｒｓｔａｔ」メッセ−ジで「ｓｔ
ａｔ」ファイルアクセス機能コールから受信される他の
情報と共に返されるのは、この「ＱＩＤ」３２３であっ
て、このファイルについてのファイル構造１６２３から
の「ＰＱＩＤ」１６２７ではない。

【０４６８】「ＰＱＩＤ」１６２７の代わりに実際の
「ＱＩＤ」３２３が必要とされる理由は、１つよりも多
い数の、名前スペースの一部分１４０１が、名前スペー
ス１１５（ｂ）から名前スペース１１５（ａ）へ送出さ
れているかも知れないからである。

【０４６９】そして更に、もし同じファイルが両方の名
前スペースの一部分１４０１にある場合には、これら両
方のファイルが名前スペース１１５（ｂ）において同じ
ファイルであるにも拘らず、このファイルは、各一部分
１４０１について別個のファイル構造１６２３を有する
ことになり、これらのファイル構造１６２３は各々、
「ＰＱＩＤ」１６２７において異なる値を取ることにな
るからである。

【０４７０】プロセス１０２（ａ）は、「ｓｔａｔ」機
能によってこのファイルについて返される「ＱＩＤ」３
２３を比較することにより、名前スペース１１５（ａ）
において異なるパス名を有することになるこれらのファ
イルが同一であるかどうかを定めようとする。したがっ
て、「ｒｓｔａｔ」ｒメッセ−ジは、このファイルの、
「ＰＱＩＤ」でなく実際の「ＱＩＤ」３２３を含む必要
がある。

【０４７１】「プロトコルインタプリタデータ構造」１
５１７におけるデータ構造の重要な利点は、これらのデ
ータ構造が動的なことである。「ＦＩＤ」構造１６０９
は、マウントサーバ２０３（ａ）が「ｔメッセ−ジ」で
「ＦＩＤ」３３１を用いるときにだけ「ＦＩＤ」１６１
９のチェイン１７０５に付加され、「ｔメッセ−ジ」が
「ＦＩＤ」３３１と名前スペースの一部分１４０１内の
ファイルとの付随関係がもはや存在しないことを表示す
る場合には「ＦＩＤ」チェイン１７０５から除去され
る。

【０４７２】同様に、ファイル構造１６２３は、このフ
ァイル構造によって表されるファイルの名前を指定する
「ｔｗａｌｋ」メッセ−ジ又は「ｔｃｒｅａｔｅ」メッ
セ−ジがあった場合にだけファイル樹木１７０７に付加
される。

【０４７３】送出ファイルサービスを用いるプラン９システムコール 送出ファイルサービスを用いるプラン９サービス１２３
には、「ｉｍｐｏｒｔ」（取り込み）と「ｃｐｕ」との
２つのサービスがある。「ｉｍｐｏｒｔ」サービスは、
遠隔システムから名前スペースの一部分１４０１を取り
込むために送出ファイルサービスを用いる。

【０４７４】「取り込み」サービスは、主題項目とし
て、遠隔システムの名前と、遠隔システム内の名前スペ
ースの一部分１４０１についてのルートディレクトリの
パス名とを取る。又主題項目として、このファイルがマ
ウントされるべきローカルシステム内のディレクトリの
パス名もとってもよい。

【０４７５】上の「プラン９サービスのアーキテクチャ
の概観」の項で述べたように、オプションによって、ル
ートディレクトリがマウントされる先のディレクトリ
の、前、後、又はそのものの場所上（この場合には置換
となる）、へのマウントが許される。

【０４７６】「取り込み」サービスは次のように行われ
る。すなわち最初に、「ダイヤル」システムコールを用
いて、遠隔システム上の送出ファイルサービスへのプロ
トコルチャンネル５１７が設立される。それから、ルー
トディレクトリについてのパス名を送出ファイルサービ
スに与え、送出ファイルサービスは、今先に述べたよう
に、ファイル樹木１７０７を初期設定するためにこのパ
ス名を用いる。

【０４７７】それから、「取り込み」サービスが送出フ
ァイルサービスから確認メッセ−ジを受信すると、「取
り込み」サービスは、プロトコルチャンネル５１７につ
いてのファイル記述子４１７を、主題項目に指定される
名前スペース１１５（ａ）内のディレクトリ上に、オプ
ションに指定される仕方でマウントしてから、動作を終
了する。もし名前スペース１１５（ａ）内のディレクト
リが指定されない場合は、名前スペース１１５（ｂ）内
のディレクトリについて指定されたのと同じパス名を有
する名前スペース内のディレクトリがマウント点として
用いられる。

【０４７８】「ｃｐｕ」サービス１２３の説明には最初
に、プラン９プロセスが一般に作動する環境の点検が必
要である。図７を参照して「プラン９オペレーティング
システムの概観」の項で述べたように、プラン９オペレ
ーティングシステムがそこで作動する分散形システムは
一般に、いくつもの、ＣＰＵ又はＣＰＵサーバ７０３、
ファイルサーバ７０５、及び端末７１１を有する。

【０４７９】ＣＰＵサーバとファイルサーバとの間は、
高速のＤＭＡ７０９によって接続され、端末７１１は、
高速のＤＭＡ７０９に全国規模長距離通信ネットワ−ク
７１５によって接続される。プラン９プロセス１０２
は、少なくともＣＰＵサーバ７０３及び端末７１１上で
作動する。

【０４８０】このシステムの一般的な用法の１つは、端
末７１１上での編集のようなグラフィックユ−ザインタ
フェ−ス集中形タスクやＣＰＵサーバ７０３上でのコン
パイレーションのようなコンピュータ集中形タスクの実
行である。

【０４８１】「ｃｐｕ」サービス１２３では、ユ−ザ
の、端末７１１上でのプログラム実行からＣＰＵサーバ
７０３上でのプログラム実行へシフトが許される。ＣＰ
Ｕサーバ７０３上で実行中のプログラムは、端末７１１
のユ−ザには端末７１１上のウインドウ内で実行されて
いるように見える。そしてユ−ザは、ＣＰＵサーバ７０
３上での実行中のプログラムへの入力の付与及びプログ
ラムからの出力の受領をウインドウ内で行うことができ
る。

【０４８２】「ｃｐｕ」サービスと、遠隔ＣＰＵ上でプ
ログラムを実行するために普通に用いられる端末エミュ
レーションプログラムとの基本的な差異は、「ｃｐｕ」
サービスを行う端末７１１上のプロセス１０２の名前ス
ペースがＣＰＵサーバ７０３上でプログラムを実行する
プロセス１０２へ送出されることである。

【０４８３】図１４に関連して説明すれば、「システム
２」１４１３は端末７１１であり、プロセス１０２
（ｂ）は「ｃｐｕ」サービスを実行するプロセスであ
る。又、「システム１」１４１１はＣＰＵサーバ７０３
であり、プロセス１０２（ａ）はＣＰＵサーバ７０３上
でユ−ザのために実行中のプロセスである。

【０４８４】「ｃｐｕ」サービスを開始するコマンドに
は２つのオプションがあり、１つは、プログラムがそこ
で実行されるＣＰＵサーバ７０３を指定するオプショ
ン、他の１つは、プラン９シェルである「ｒｃ」に対す
るコマンドラインによってプログラムを指定するオプシ
ョンである。もしどちらのオプションも指定されない場
合、デフォルトＣＰＵサーバ７０３が与えられ、実行さ
れるプログラムは、「ｒｃ」となる。

【０４８５】「ｃｐｕ」サービスは２つの部分を有す
る。１つの部分は、ＣＰＵサーバ上で作動し、他の１つ
の部分は、端末７１１上で作動する。実行は、端末７１
１上で作動する方の部分で開始される。以下の説明にお
いて、この、端末７１１上で作動する方の部分がプロセ
ス１０２（ｉ）によって実行されるものと仮定する。

【０４８６】この部分は、コマンドで又はデフォルトに
よって与えられるＣＰＵサーバ７０３の名前を用いてＣ
ＰＵサーバ７０３のネットワ−クアドレスを定め、次に
「ダイヤル」システムコールを用いて、ＣＰＵサーバ７
０３へのプロトコルチャンネル５１７を設立させる結果
となるメッセ−ジをＣＰＵサーバ７０３に送る。

【０４８７】「ｃｐｕ」サービスの端末部分はそれか
ら、まずプロトコルチャンネル５１７にＣＰＵサーバ７
０３によって実行されるべきコマンドを書き込んでか
ら、プロトコルチャンネル５１７に文字列「ＮＯ」又は
プロセス１０２（ｉ）の作業ディレクトリを書き込む。

【０４８８】ＣＰＵサーバ７０３において、前に述べた
「リスナー」プロセスが、「ダイヤル」システムコール
に応答して、ＣＰＵサーバ７０３上でこのユ−ザについ
てのデフォルト名前スペース１１５（ｊ）でプロセス１
０２（ｊ）を開始し、プロセスについての標準入力、標
準出力、及びエラーをプロトコルチャンネル５１７に接
続する。デフォルト名前スペース１１５（ｊ）は、プロ
セス１０２（ｉ）からの名前スペースの一部分１４０１
をその上にマウントできるようなディレクトリ「ｔｅｒ
ｍ」を有する。

【０４８９】それからプロセスは、ＣＰＵサーバ７０３
上で作動する「ｃｐｕ」サービスのこの部分の実行を開
始する。それからこのプロセスは、コマンドを得るプロ
トコルチャンネル５１７上で第１の「ｒｅａｄ」（読み
取り）を行い、（もしディレクトリがあれば）そのディ
レクトリを得る第２の読み取りを行う。もしディレクト
リがある場合、プロセス１０２（ｊ）は、そのディレク
トリに変わる。そうでなければ、プロセス１０２（ｊ）
は、プロセス１０２（ｊ）についてのホームディレクト
リに変わる。

【０４９０】次のステップは、プロセス１０２（ｊ）の
「ＰＩＤ」をこのチャンネルを介してプロセス１０２
（ｉ）に送り、プロセス１０２（ｉ）にプロセス１０２
（ｊ）の存在を確認する。その後、プロセス１０２
（ｊ）は、最初にプロセス１０２（ｉ）に文字列「Ｆ
Ｓ」を送って、プロセス１０２（ｉ）が送出ファイルサ
ービスコ−ド１４０９を実行することになっていること
を表示し、それから「／」を送って、このプロセス１０
２（ｉ）がその名前スペース１１５（ｉ）全体を送出す
ることになっていることを表示する。

【０４９１】端末７１１において、プロセス１０２
（ｉ）は、文字列「ＦＳ」を受信して送出ファイルサー
ビスコ−ド１４０９の実行を開始し、こうして送出ファ
イルサービス１５０１となる。送出ファイルサービス１
５０１は、プロセス１０２（ｊ）によって送られた
「／」を読み取り、既に述べたように、これを用いてプ
ロトコルインタプリタデータベース構造１５１７を初期
設定し、それから文字列「ＦＳ」をプロセス１０２
（ｊ）に返す。

【０４９２】プロセス１０２（ｊ）は、これに応答し
て、プロトコルチャンネル５１７についてのファイル記
述子４１７を、名前スペース１１５（ｊ）内のディレク
トリ「ｔｅｒｍ」上にマウントし、これにょって名前ス
ペース１０２（ｉ）の名前スペース全体をプロセス１０
２（ｊ）の名前スペースに組み込む。

【０４９３】以後、プロセス１０２（ｊ）の名前スペー
ス１１５（ｊ）内のディレクトリ「ｔｅｒｍ」内のファ
イル上でのファイルオペレーションは、結果的に、端末
７１１上での、プロセス１０２（ｉ）の名前スペース１
１５（ｉ）内のファイル上でのオペレーションとなる。

【０４９４】まとめ 上記の「詳細説明」により、１つの名前スペースの一部
分を別の名前スペース内に組み込むための本発明者らの
技術を実現するために本発明者らが現在知る限りで最良
の方式を開示した。本発明者らがその技術をそこで実現
するために用いたプラン９オペレーティングシステムに
おいて、名前スペースは、プロセスごとのものである。

【０４９５】したがって、その一部分がそこから送出さ
れる元の名前スペースは、１つのプロセスに属する。こ
れは、名前スペースの一部分が取り込まれる先の名前ス
ペースが別のプロセスに属するのと同様である。

【０４９６】しかし、本発明の技術は、名前スペースが
プロセスに属することを必要とせず、１つのエンティテ
ィによって定義される名前スペースの一部分が、別の１
つのエンティティによって定義される名前スペース内に
組み込まれることになる場合には、本発明の技術を用い
ることができる。そのうえ、プラン９の名前スペース内
の名前はファイルを意味するのに対し、本発明の技術
は、どの様な種類のエンティティを意味する名前とでも
使用可能である。

【０４９７】更に、本発明の実施例において送出される
名前スペースが遠隔のプロセッサ上で作動するプロセス
に属するのに対し、本発明の技術は、名前スペースが送
出されつつある先のプロセスが作動するプロセッサと同
じプロセッサ上で作動するプロセスに属する名前スペー
スを送出する際にも用いることができる。

【０４９８】これに加えて、ここに説明した実現例にお
いてはプラン９ファイルプロトコルからプラン９ファイ
ルシステムコールへの変換が行われるのに対し、同じ技
術を、名前の一部分をそれが取込側名前スペース内に現
れるのと同じ状態に指定するオペレーションを、それが
如何なるオペレーションであっても、その名前をそれが
送出側名前スペース内に現れるのと同じ状態に指定する
オペレーションに変換する作業にも使用できる。

【０４９９】又更に、取込側名前スペース内に現れるよ
うな名前を送出側名前スペースに現れるような名前にマ
ッピングするために本発明者らが用いた技術は、プラン
９名前スペースが樹木に編成できるという事実を利用し
ている。名前スペースが別の仕方で編成される場合に
は、これらの編成にとって適切なマッピング技術は、こ
こで開示されたのと同じ仕方で用いることができる。

【０５００】最後に、上記「詳細説明」に示された手法
以外にも、ここに開示された技術を実現する多くの手法
があることは、当業者には明かである。

【０５０１】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例を考え得るが、それらはいずれも本発明の技術
的範囲に包含される。

【０５０２】尚、特許請求の範囲に記載した参照番号は
発明の容易な理解のためで、その技術的範囲を制限する
よう解釈されるべきではない。

【０５０３】

【発明の効果】以上述べたごとく、本発明によれば、第
１のプロセスが第２のプロセスの名前スペースの一部分
又は全部を自身の名前スペースに組み込むことができる
ようにしたので、ワークステーション上で実行中のプロ
セスの名前スペースを、ワークステーションの端末のユ
−ザのためにＣＰＵ上で実行中のプロセスの名前スペー
スに組み込むようなオペレーションが、従来技術では極
めて煩雑であったのに比べ、大変容易となり、コンピュ
ータシステムにおける作業効率を大幅に改善することが
できる。

【図面の簡単な説明】

【図１】本明細書に述べるオペレーティングシステムに
よって与えられる、プロセスごとの名前スペースの概観
の説明図である。

【図２】上記オペレーティングシステムにおけるマウン
トサービス及びプロトコルサービスの概観の説明図であ
る。

【図３】チャンネルデータ構造の説明図である。

【図４】ファイルを探索、開設するために用いられるデ
ータ構造の説明図である。

【図５】プロトコルサービスとの間でプロトコルの送受
信を行うために用いられるデータ構造の説明図である。

【図６】ルートサービスによって与えられるファイル樹
木並びに或る「ｂｉｎｄ」オペレーション及び「ｍｏｕ
ｎｔ」オペレーションが行われた後のファイル樹木の説
明図である。

【図７】本発明によるオペレーティングシステムを実現
した分散形システムの説明図である。

【図８】本発明のマウントテーブルの説明図である。

【図９】図６の第２のファイル樹木についてのマウント
テーブルの説明図である。

【図１０】本発明の一実施例における「ｎａｍｅｃ」
（ネーメック）機能の、流れ図である。

【図１１】本発明の一実施例における「ｗａｌｋ」（ウ
オーク）機能の流れ図である。

【図１２】本発明の一実施例における「ｍｏｕｎｔ」
（マウント）機能の流れ図である。

【図１３】本発明の一実施例におけるプロトコルサービ
スを登録するために用いられるデータ構造の説明図であ
る。

【図１４】その名前スペースの一部分を第２のプロセス
に与えた第１のプロセスの説明図である。

【図１５】送出ファイルサービスの一実施例についての
説明図である。

【図１６】プロトコルインタプリタデータベース構造１
５１７において用いられるデータ構造の説明図である。

【図１７】プロトコルインタプリタデータベース構造１
５１７においてデータ構造がどのように組み合わされる
かを示す説明図である。

【符号の説明】

１０１ サービスアーキテクチャ １０２ プロセス １０３ プロセスグループ １０５ ファイルアクセス機能（ＦＡ）１１１へのコー
ル（呼び出し） １０７ ファイル探索機能（ＦＬ）１１３へのコール １０９ ファイルシステム １１１ ファイルアクセス機能（ＦＡ） １１３ ファイル探索機能（ＦＬ） １１５ 名前スペース １１７ 単一のファイル樹木 １１９ サービスファイルアクセス要求 １２１ サービスファイル探索要求 １２３ サービス １２５ ファイル樹木 １２７、１２９ ディレクトリファイル １３１ データファイル ２０３ マウントサービス ２０５ ファイル探索トランズアクション ２０７ ファイルアクセストランズアクション ２０９ プロトコルサービス（ＰＳ） ２１１ ローカルプロトコルサーバ ２１３ 遠隔プロトコルサーバ ２１４ ネットワ−ク通信サービス（ＮＳ） ２１５ 通信サービス ２１６ プロセス間通信サービス（ＩＰＳ） ２１７ サービスファイル探索要求を指定する機能コー
ル ２１９ サービスファイルアクセス要求を指定する機能
コール ３０１ チャンネルデータ構造 ３０３ 「ＬＯＣＫ」（ロック）フィールド ３０７ 「ＲＥＦ」（参照カウント）フィールド ３０９ 「ＮＥＸＴ／ＯＦＦ」（ＮＥＸＴ／ＯＦＦＳＥ
Ｔ）フィールド ３１１ 「ＫＳＩＮＦＯ」（核サービス情報） ３１３ 「ＴＹＰＥ」（タイプ）フィールド ３１５ 「ＤＥＶ」（ＤＥＶＩＣＥ）（デバイス）フィ
ールド ３１７ 「ＡＩＮＦＯ」（アクセス情報）フィールド ３１９ 「ＭＯＤＥ」（モード）フィールド ３２１ 「ＦＬＡＧ」３２１（フラッグ）フィールド ３２３ 「ＱＩＤ」（ファイルハンドル「ｑｉｄ」）フ
ィールド ３２５ 「ＭＩＮＦＯ」３２５（マウント情報） ３２７ 「ＭＯＵＮＴ ＰＴＲ」３２７（マウントポイ
ンタ）フィールド ３２９ 「ＭＯＵＮＴ ＩＤ」（マウント識別子）フィ
ールド ３３１ 「ＦＩＤ」（ファイル識別子）フィールド ３３３ 「ＡＵＸ」（補助情報）フィールド ３３５ 「ＰＳＩＮＦＯ」（プロトコルサービス情報） ３３７ 「ＰＣＨＡＮ」（プロトコルチャンネル）フィ
ールド ３３９ 「ＭＱＩＤ」３３９フィールド ４０１ データ構造 ４０３ ユ−ザデータ構造 ４１３ ファイル記述子アレイ（ＦＤＡ） ４１５ （ファイル記述子アレイ）エントリ（ＦＤＡ
Ｅ） ４１７ ファイル記述子（ＦＤ） ４１９ ファイルチャンネル構造（ＦＣＨＡＮ） ５０１ データ構造 ５０２ マウントサービスアレイ（ＭＮＴＡ） ５０３ （マウントサービスアレイ）エントリ（ＭＮＴ
Ｅ） ５０９ マウントサービス待ち行列構造（ＭＮＴＱ） ５１７ プロトコルチャンネル（ＰＣＨＡＮ） ５２０ メッセ−ジ待ち行列 ５２１ マウントサービスヘッダ構造（ＭＮＴＨＤＲ） ５３３ マウントバッファ ６０１ スタブファイル樹木 ６１７ ファイル樹木 ７０１ プラン９システム ７０３ 中央演算処理装置（ＣＰＵ） ７０５ ファイルサーバ ７０９ 高速ＤＭＡ（直接メモリアクセス）リンク ７１１ ノット（Ｇｎｏｔ）端末（ローカル処理ユニッ
ト） ７１３ 分散形ネットワ−ク ７１５ 全国規模長距離通信ネットワ−ク ７１７ ＣＰＵ・ファイルサーバセット ７１９ 端末セット ８０１、９０１ マウントテーブル ８０２ 左チャンネル（ＬＣＨＡＮ） ８０３ マウントテーブルアレイ（ＭＴＡ） ８０４ 右チャンネル（ＲＣＨＡＮ） ８０６ （マウントテーブルアレイ）エントリ（ＭＴ
Ｅ） ８０９ マウント構造 １３０１ データ構造 １３０３ ディレクトリ・エントリ １３０５ ディレクトリ情報 １３１０ 子リスト １３１５ 「ＮＡＭＥ」（名前）フィールド １３１７ 「ＱＩＤ」フィールド（ファイルハンドル
「ｑｉｄ」） １４０１ 名前スペースの一部分 １４０５ 取込側 １４０７ 送出側 １４０９ 送出ファイルサービスコ−ド １５０１ 送出ファイルサービス １５０３ （送出ファイルサービスコ−ド１４０９の）
「ＩＮＩＴ」（初期設定）成分 １５０５ 「ＲＤＬＯＯＰ」（読み取りループ） １５０７ 「ＰＩ」（プロトコルインタプリタ） １５０９ 「ＮＢＰＩ」（非閉塞性プロトコルインタプ
リタ） １５１１ 「ＢＰＩ」（閉塞性プロトコルインタプリ
タ） １５１３ 「ＲＥＰＬＹ」（回答） １５１５ 従プロセス １５１７ プロトコルインタプリタデータベース構造
（ＰＩＤＳ） １５１９ ｒメッセ−ジ １５２１ ｔメッセ−ジ １６０１ 「ＦＳＲＰＣ」 １６０９ 「ＦＩＤ」（ファイル識別子） １６２３ 「ＦＳ」（ファイル構造） １６３５ 「ＳＰＲＯＣ」（従プロセス構造）

───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06F 12/00 G06F 15/16

Claims (15)

(57)【特許請求の範囲】
1. 【請求項１】 エンティティを表す名前の第１の名前ス
   ペース（１１５（ｂ））において作動して、この第１の
   名前スペースの一部分（１４０１）を第２の名前スペー
   ス（１１５（ａ））の一部分（１４０１）として利用可
   能にする装置において、 １つのオペレーションを指定し、且つ前記第２の名前ス
   ペースの前記一部分において１つのオペレーション指定
   子によって要求されるフォームを有する第１の名前を含
   む、その第１のオペレーション指定子を受信する手段
   （１５０５）と、 前記オペレーションと同じオペレーションを指定し、且
   つ前記第１の名前スペースにおいて要求されるフォーム
   を有する第２の名前を含む、第２のオペレーション指定
   子、を前記第１のオペレーション指定子に応答して作成
   する解釈手段（１５０７）と、 前記第２のオペレーション指定子に応答して、前記第２
   の名前によって表されるエンティティ上で前記オペレー
   ションを行う手段（１０９（ｂ））と、からなることを
   特徴とする、コンピュータシステムに用いる第１の名前
   スペースの一部分を第２の名前スペースの一部分として
   利用可能にする装置。
2. 【請求項２】 第１のオペレーション指定子を受信する
   ための前記手段が、前記第２の名前スペースを用いる原
   始エンティティ（１０２（ａ））から前記第１のオペレ
   ーション指定子を受信し、 前記第２のオペレーション指定子手段から前記オペレー
   ションの結果を受信するための、及びこの結果を含む結
   果指定子を前記原始エンティティに送信する回答手段
   （１５１３）をさらに有することを特徴とする請求項１
   の装置。
3. 【請求項３】 前記第２の名前スペースにおいて作動
   し、前記受信する手段、前記解釈手段、及び前記回答手
   段を実現するためのプロセス（１０２（ｂ））と、 前記プロセスと前記原始エンティティとの間で前記第１
   のオペレーション指定子と前記結果指定子とを転送する
   ためのチャンネル（５１７）とをさらに有することを特
   徴とする請求項２の装置。
4. 【請求項４】 前記原始エンティティが、別のプロセス
   であり、 前記第１の名前スペース及び前記第２の名前スペース
   が、プロセスごとの名前スペースである、ことを特徴と
   する請求項３の装置。
5. 【請求項５】 中央演算処理装置（７０３）と、 ローカル処理ユニット（７１１）と、をさらに有し、 前記ローカル処理ユニットが、前記第１の名前スペー
   ス、第１のオペレーション指定子を受信する手段、前記
   解釈手段、及び前記オペレーション手段を実現するため
   に用いられ、 前記中央演算処理装置が、前記第２の名前スペースを実
   現するために用いられ、 第１のオペレーション指定子を受信する前記手段が、前
   記第１のオペレーション指定子を前記中央演算処理装置
   から受信する、ことを特徴とする請求項１の装置。
6. 【請求項６】 前記ローカル処理ユニットが、ディスプ
   レイと入力装置とを有し、 前記第２の名前スペースの前記一部分である前記第１の
   名前スペースの前記一部分が、前記第１の名前スペース
   のうち前記入力装置についての名前と前記ディスプレイ
   についての名前とを有する部分、を有する、ことを特徴
   とする請求項５の装置。
7. 【請求項７】 前記第１の名前スペース及び前記第２の
   名前スペースが、前記ローカル処理ユニットと前記中央
   演算処理装置との同一ユ−ザに属する、ことを特徴とす
   る請求項５の装置。
8. 【請求項８】 前記第１のオペレーション指定子が、ブ
   ロッキングオペレーションを含む複数のオペレーション
   のうちの１つのオペレーションを指定し、 前記解釈手段が、前記第１のオペレーション指定子がブ
   ロッキングオペレーションを指定する場合に、前記第２
   のオペレーション指定子に対する従プロセス（１５１
   ５）を得ることによって、前記第１のオペレーション指
   定子に応答し、 前記第２のオペレーション指定子に応答する前記手段
   が、前記従プロセスについてのオペレーションを行う、
   ことを特徴とする請求項１の装置。
9. 【請求項９】 前記解釈手段が、前記第２の名前に前記
   第１の名前をマッピングするためのマッピング手段を有
   することを特徴とする請求項１の装置。
10. 【請求項１０】 第１のオペレーション指定子を受信す
    るための前記手段が、複数の第１のオペレーション指定
    子を受信し、 前記マッピング手段が、前記受信された第１のオペレー
    ション指定子のための要求に応じて動的に構築され、少
    なくとも、前記第１の名前スペースにおいて前記第１の
    名前に要求されるフォームを定める手段（１７０７）を
    有する、ことを特徴とする請求項９の装置。
11. 【請求項１１】 前記第１の名前スペースにおいて要求
    される前記フォームを定めるための前記手段が、前記第
    １の名前スペースにおける名前についてのノード（１６
    ２３）を有する、動的に構築された樹木（１７０７）で
    あり、 前記ノードは、前記樹木において前記第１の名前につい
    てのノードを探し且つこのノードから前記樹木のルート
    部へ樹木に沿って移動することによって、第２の名前の
    ために要求されるフォームが得られるように、構成され
    る、ことを特徴とする請求項１０の装置。
12. 【請求項１２】 前記マッピング手段が更に、 前記第１の名前を、前記第２の名前スペースの前記一部
    分において前記第１の名前によって表されるエンティテ
    ィだけを識別するエンティティハンドル（１６２７）で
    あるが前記オペレーションを行うための前記手段におい
    て前記エンティティのために用いられるエンティティハ
    ンドル（１６１９）とは異なるようなエンティティハン
    ドル（１６２７）上にマッピングすることを特徴とする
    請求項１０の装置。
13. 【請求項１３】 前記第１のオペレーション指定子を受
    信するための前記手段が、前記第２の名前スペースを用
    いる原始エンティティから前記第１のオペレーション指
    定子を受信し、 前記第２のオペレーション指定子手段から前記オペレー
    ションの結果を受信するための、及びこの結果を含む結
    果指定子を前記原始エンティティへ送信する手段（１５
    １３）を有し、 前記第１のオペレーション指定子が、前記第１の名前に
    よって表されるエンティティの状態を定めるための状態
    オペレーションを指定し、 前記状態オペレーションについての前記結果指定子が、
    前記オペレーションを行うための前記手段において前記
    エンティティのために用いられる前記エンティティハン
    ドルを返す、ことを特徴とする請求項１２の装置。
14. 【請求項１４】 エンティティを表す名前の第１の名前
    スペースの一部分を第２の名前スペースの一部分として
    利用可能にする方法において、 オペレーションを指定する第１のオペレーション指定子
    であって前記第２の名前スペースの前記一部分において
    要求されるフォームを有する第１の名前を含むような第
    １のオペレーション指定子、を原始エンティティから受
    信するステップと、 前記第１のオペレーション指定子に応答して、前記オペ
    レーションと同じオペレーションを指定する第２のオペ
    レーション指示子であって前記第１の名前スペースにお
    いて第２のオペレーション指定子のために要求されるフ
    ォームを有する第２の名前を含むような第２のオペレー
    ション指定子、を作成するステップと、 前記第２のオ
    ペレーション指定子によって指定される前記オペレーシ
    ョンを行うステップと、からなることを特徴とする、コ
    ンピュータシステムに用いる第１の名前スペースの一部
    分を第２の名前スペースの一部分として利用可能にする
    方法。
15. 【請求項１５】 前記オペレーションの結果を受信し
    て、この結果を含む結果指定子を前記原始エンティティ
    に送信するステップをさらに有することを特徴とする請
    求項１４の方法。