JP2724256B2 - コンピュータシステム - Google Patents

コンピュータシステム

Info

Publication number
JP2724256B2
JP2724256B2 JP3196061A JP19606191A JP2724256B2 JP 2724256 B2 JP2724256 B2 JP 2724256B2 JP 3196061 A JP3196061 A JP 3196061A JP 19606191 A JP19606191 A JP 19606191A JP 2724256 B2 JP2724256 B2 JP 2724256B2
Authority
JP
Japan
Prior art keywords
file
service
namespace
name
names
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP3196061A
Other languages
English (en)
Other versions
JPH04233654A (ja
Inventor
チャールズ パイク ロバート
エル．トンプソン ケニス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
AT&T Corp
Original Assignee
AT&T Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by AT&T Corp filed Critical AT&T Corp
Publication of JPH04233654A publication Critical patent/JPH04233654A/ja
Application granted granted Critical
Publication of JP2724256B2 publication Critical patent/JP2724256B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0613—Improving I/O performance in relation to throughput
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F2003/0697—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers device management, e.g. handlers, drivers, I/O schedulers

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は、概して電算システム
（コンピュータシステム）に関し、さらに詳細には分散
型電算システム、すなわちシステムの構成要素が通信媒
体によって接続されているような電算システムに関す
る。
【０００２】
【従来の技術】コンピュータシステムにおいてプログラ
ムの実行に利用可能なエンティティの多くは、名前、す
なわち、アドレスではないがそれによって指定されるエ
ンティティを検索するためにプログラムによって使用さ
れる識別子を有する。コンピュータシステムのオペレー
ティングシステムは、ユーザがエンティティに名前を付
けることを可能にし、名前とエンティティの間の関係を
追跡し、ユーザが名前によってエンティティを検索する
ことを可能にするような構成要素を有する。
【０００３】ファイルは、そのような名前の付けられた
エンティティの一例である。オペレーティングシステム
のファイルシステム要素によって、ユーザは、ファイル
に文字列からなる名前を与え、その文字列からなる名前
を用いてファイルを検索することができる。その他の名
前の付けられたエンティティには、端末やプリンタなど
の装置（デバイス）がある。エンティティを検索するた
めにプログラムが使用する名前の集合を、そのプログラ
ムが実行される「名前空間」という。オペレーティング
システムによって、名前空間の編成の仕方が決定され
る。ある場合には、名前空間は平坦である。すなわち、
すべての名前が単一のレベル上にある。別の場合には、
オペレーティングシステムは名前を階層へと編成する。
階層的な編成の一般的な形は、単一の木構造である。名
前空間におけるすべての名前は、単一のルートを有する
木構造へと編成される。この木構造の内部ノードの名前
はディレクトリを表し、葉ノードの名前は普通のエンテ
ィティを表す。このような木構造においてエンティティ
またはディレクトリを検索するために、プログラムは、
そのエンティティもしくはディレクトリの名前および木
構造のルートとそのエンティティもしくはディレクトリ
との間のすべてのディレクトリの名前とを指定するか、
または、そのエンティティもしくはディレクトリの名前
およびプロセスの現在のディレクトリ（カレントディレ
クトリ）とそのエンティティもしくはディレクトリとの
間のすべてのディレクトリの名前とを指定する。エンテ
ィティを検索するのに必要な名前の組合せをそのエンテ
ィティの「パス名」という。
【０００４】分散システムの設計における１つの問題
は、名前空間をいかに定義するかである。１つの方法
は、アメーバ(Amoeba)分散システムの例に示されるよう
に、単にこの問題を無視することである。アメーバシス
テムは、マレンダ(Mullender)他「Amoeba−１９９０年
代の分散オペレーティングシステム(Amoeba-A Distribu
ted Operating System for the 1990's)」、IEEE Compu
ter（１９９０年５月）、に記載されているが、このオ
ペレーティングシステムは名前空間を定義しない。その
代わり、このシステムには、名前サーバという構成要素
を含めることができる。名前サーバが名前空間を定義す
る。
【０００５】オペレーティングシステムが名前空間を定
義している場合、いくつかの方法がとられている。この
方法については、カマー(Comer)、ドロムズ(Droms)およ
びマーター(Murtagh)「ティルデ命名方式の実験的実装
(An Experimental Implementation of the Tilde Namin
g System)」、Computing Systems、第３巻第４号、米国
カリフォルニア州バークレイのカリフォルニア大学出版
（１９９１年）第４８７〜５１５ページに、さらに詳細
な説明がある。１つの方法は、分散システムにおけるす
べての名前を単一の全システム的な名前の階層に含める
ことである。場合によっては、名前の階層に、その名前
によって表されるエンティティがあるシステム構成要素
の名前を含めることもある。この方法に関する１つの難
しさは、名前空間の大きさである。普通のプログラムは
２、３の名前しか使わないのに、プログラムやユーザは
巨大な階層に対処しなければならない。さらに、システ
ム構成要素の名前が名前の階層に含まれる場合には、ユ
ーザまたはプログラムは、求めているエンティティがい
ずれの構成要素に含まれるものかを知らなければならな
い。明らかに、これらの難しさの程度は、分散システム
の規模が拡大するほど、増大する。
【０００６】大きさの問題は、名前空間を分割すること
によって対処されてきた。名前空間を分割する１つの方
法は、プロセッサまたはワークステーションごとに行う
ものである。名前空間を分割するもう１つの方法は、ユ
ーザごとに行うものである。
【０００７】ユーザによる分割も、プロセッサによる分
割も、コンピュータシステムにおいてプログラムを実行
するエンティティはプロセスであり、ユーザやマシンで
はないという事実には対処していない。名前空間を除く
すべての点において、プログラムが実行される環境は、
それを実行するプロセスの環境である。例えば、プログ
ラムが一時変数を生成すると、その変数は、そのプログ
ラムを実行しているプロセスの環境の一部であり、それ
にアクセスできるのは、そのプロセスだけである。しか
し、プログラムが一時ファイル（テンポラリファイル）
を作成すると、そのファイルは、プロセスが実行されて
いる名前空間の一部となるが、これは、その名前空間
が、全システム的な名前空間か、あるプログラムに対す
る名前空間か、またはあるユーザに対する名前空間かを
問わない。
【０００８】一般に、同じ名前空間で実行中の２つのプ
ロセスによって使用される同じ名前は同じエンティティ
を指すという事実のために、名前付け上の重大な問題が
起こる。例えば、一時ファイルのようなエンティティ
が、真に単一のプロセスのみに関係しているならば、プ
ロセスは、そのエンティティに対して、名前空間内で一
意的な名前を生成しなければならない。２つのプロセス
が異なる名前空間を持っていれば、そのような一意的な
名前を生成する必要性およびそれらの使用から生じる複
雑さが避けられる。プロセスごとの名前空間が無いこと
によって生じる困難は、分散システムに限らないが、プ
ロセスが走っている名前空間の大きさが拡大するほど明
らかに厳しくなるので、分散システムによって与えられ
る名前空間が大きくなるほど、その困難も増大する。
【０００９】
【発明が解決しようとする課題】従って、各プロセスが
名前の独立した階層（名前空間）を持ち、かつプロセス
どうしが、異なるプロセッサ上で実行中でも、互いに他
のプロセスの名前空間を利用することを許すことによ
り、大規模なシステムにおいても、効率的に名前を管理
することができる分散オペレーティングシステムを実現
することが所望される。
【００１０】
【課題を解決するための手段】ここに開示する本発明の
１つの特徴は、次の構成要素によって特徴付けられるマ
ルチプロセスオペレーティングシステムである。すなわ
ち、その構成要素は、１つ以上の名前空間と、各名前空
間に関係付けられたプロセスの集合と、プロセスに関係
付けられた名前空間において名前の意味を変更する名前
空間変更手段と、プロセスの現在の名前空間との関係を
終了させそのプロセスを新たに作成した名前空間に関係
付ける新名前空間作成手段である。名前空間変更手段お
よび新名前空間作成手段は、いずれのプロセスにも利用
可能である。
【００１１】その他の本発明の特徴には次のものが含ま
れる。すなわち、名前の単一の木構造からなるプロセス
ごとの名前空間、単一の木構造内での名前の意味を変更
する名前空間変更手段、名前の意味の変更記録を保持す
るコンパクト手段、エンティティがファイルによって表
されファイルに対する操作がエンティティを管理するよ
うなサービス、プロセスの名前空間のルートに結合よう
な所定のファイル木構造を与えるオペレーティングシス
テムのルートサービス、ファイル操作をファイルプロト
コルに変換するオペレーティングシステムのマウントサ
ービス、マウントサービスによって与えられるファイル
プロトコルの集合にすべて応答するプロトコルサービ
ス、および、プロセスごとにエンティティを管理するフ
ァイルを与えるサービスなどである。さらに、本発明の
特徴には、キーボードからコマンドを入力するための改
良された方法、および、あるローカルプロセッサに存在
するサービスによって与えられるファイルへのアクセス
をリモートプロセッサ上で実行中のプロセスに与える方
法も含まれる。
【００１２】
【実施例】実施例において用いる参照番号は、２つの部
分を有する。すなわち、下位２桁の数字は、１つの図面
内での番号であり、残りの桁は、図面番号である。従っ
て、例えば、参照番号１１５によって特定される項目は
図１に最初に現れる。
【００１３】以下の好ましい実施例の詳細な説明は、本
発明が具体化されるプラン９(Plan9)オペレーティング
システムの概要から開始する。概要に続いて、プラン９
の次のような内容、すなわち、プラン９がプロセスに対
する名前空間を作成する方法、プラン９のウィンドウシ
ステム、および、ＣＰＵコマンド、についてさらに詳細
に説明する。
【００１４】［プラン９オペレーティングシステムの概
要：図７］ プラン９は、種々のコンピュータおよびネットワーク上
に実装される汎用のマルチユーザ可搬分散システムであ
る。
【００１５】プラン９は、サービスファンクションに従
って分割される。ＣＰＵサーバは、計算能力を大規模な
マルチプロセッサに（過負荷がかからないように）集中
する。ファイルサーバは、記憶のための格納場所を提供
する。端末は、ウィンドウシステムを動作させるための
ビットマップスクリーンおよびマウスを備えた専用のコ
ンピュータをシステムの各ユーザに与える。計算および
ファイル格納のサービスを共有することにより、プログ
ラマのグループに共同意識を与え、費用を償却し、かつ
管理・運営を集中化し、従って、その単純化を行う。
【００１６】各部分は、単一のプロトコルによって通信
を行う。このプロトコルは、適切なネットワークによっ
て提供される信頼性のあるデータトランスポート層上に
構築され、各サービスを、ルートを有するファイル木構
造として定義する。ファイルとは通常考えられないサー
ビスに対しても、統一された設計によって、顕著かつ有
益な単純化が可能となる。各プロセスは、ローカルなフ
ァイルの名前空間を有する。この名前空間は、プロセス
が使用しているすべてのサービスへの連結を含み、それ
によってそれらのサービスに関するファイルへの連結も
含む。端末の最も重要な仕事の１つは、名前空間に見え
るサービスによってシステム全体を表現するようなビュ
ー（概観、view）をユーザがカスタマイズするのをサポ
ートすることである。
【００１７】有効に利用するために、本システムは、Ｃ
ＰＵサーバ、ファイルサーバ、および、端末を必要とす
る。このシステムは、部門別かまたはそれより大きな単
位のコンピュータセンタのレベルでサービスを与えるこ
とを意図したものである。ＣＰＵサーバおよびファイル
サーバは、大規模なマシンであり、調節された電源を有
する空調付きの機械室に収容することが望ましい。
【００１８】以降、プラン９の基本的な構成要素を述べ
る。名前空間およびその使用方法を説明し、さらにプラ
ン９の概念が種々の問題にいかにして適用できるかを例
示する普通でないサービスの例をいくつか提示する。
【００１９】［ＣＰＵサーバ］ いくつかのコンピュータがプラン９のＣＰＵサービスを
与える。製品のＣＰＵサーバは、４個の２５ＭＨｚのＭ
ＩＰＳプロセッサおよび１２８メガバイトのメモリを有
し、ディスクは無く、ファイルサーバへの毎秒２０メガ
バイトのＤＭＡ接続を行うシリコン・グラフィクス(Sil
icon Graphics)社のパワー・シリーズ(Power Series)マ
シンである。また、これは、端末およびプラン９以外の
システムに接続するためにデータキット(Datakit)およ
びイーサネット(Ethernet)のコントローラも備えてい
る。オペレーティングシステムは、forkおよびexecシス
テムコールに基づくプロセスならびに大部分はリモート
のファイルサーバによって決定されるファイルの通常の
ビュー(view)を与える。ＣＰＵサーバへの接続がひとた
び確立すると、ユーザは、通常どおりに見える環境の下
で、コマンドインタプリタにコマンドをタイプ入力する
ことができる。
【００２０】ＣＰＵサーバは、コンパイル、テキスト処
理などのアプリケーションを実行する。ＣＰＵサーバ
は、それ自体の外部記憶装置を持たず、それがアクセス
する永久ファイルはすべてリモートのサーバによって与
えられる。ユーザのプロセスによって与えられるサービ
スまたはアクティブなプロセスを集めたイメージなどの
名前空間の一時的な部分はローカルに存在し得るが、Ｃ
ＰＵサーバがリブートされるとそれらは消滅する。普通
の端末どうしがそれらのタスクに対して交換可能である
ように、プラン９のＣＰＵサーバどうしは、それらのタ
スク、すなわち処理に対して交換可能である。
【００２１】［ファイルサーバ］ プラン９のファイルサーバは、すべての永久ファイルを
保持する。現在のファイルサーバは、２つのプロセッ
サ、６４メガバイトのメモリ、６００メガバイトの磁気
ディスク、および３００ギガバイト相当の追記型（ＷＯ
ＲＭ）光ディスクユニットを備えたもう１つのシリコン
・グラフィックスのコンピュータである。このファイル
サーバは、毎秒２０メガバイトのＤＭＡリンクを通して
プラン９のＣＰＵサーバに接続され、また通常のネット
ワークを通して端末などのマシンに接続される。
【００２２】ファイルサーバは、クライアントに対し、
ディスク、ブロックまたはファイルのアレイなどではな
くファイルシステムを提示する。ファイルは、木構造の
分岐の標識となる斜線（スラッシュ）で区切られた構成
要素によって命名され、入出力のためにバイトレベルで
アドレス指定可能である。サーバにおけるファイルの位
置は、クライアントには見えない。真のファイルシステ
ムは、ＷＯＲＭに存在し、磁気ディスクの２レベルのキ
ャッシュおよびＲＡＭを通してアクセスされる。最近利
用されたファイルの内容は、ＲＡＭに存在して、高速リ
ンクを介するＤＭＡによりＣＰＵサーバに迅速に送られ
る。この転送は、ローカルメモリほどは速くないが通常
のディスクよりはるかに高速である。磁気ディスクは、
ＷＯＲＭに対するキャッシュとして作用すると同時に、
ＲＡＭに対するバックアップ媒体として作用する。高速
リンクについては、クライアントがデータをキャッシュ
する必要がない。その代わり、ファイルサーバがそのす
べてのクライアントに対しキャッシュ処理を集中化し
て、分散されたキャッシュの問題を回避している。
【００２３】［端末］ ここではプラン９に対する標準の端末をGnot（ノット）
と称する。Gnotは、限定地域で設計されたマシンであ
り、数百台が製造された。この端末のハードウェアは、
ディスクの無いワークステーションのようであり、４〜
８メガバイトのメモリ、２５ＭＨｚの６８０２０プロセ
ッサ、１画素あたり２ビットで１０２４×１０２４画素
の画面、キーボード、およびマウスを備えている。この
端末は、外部記憶装置も拡張バスも無い。これは、端末
であって、ワークステーションではないからである。毎
秒２メガビットのパケット交換分散ネットワークによっ
て、端末がＣＰＵサーバおよびファイルサーバに接続さ
れる。コンパイルのような用途には帯域幅が狭いが、端
末を意図した目的（ウィンドウシステム、つまりプラン
９の他の部分への多重化インタフェースを与えること）
には十分すぎるほどである。
【００２４】ワークステーションとは異なり、Gnotは、
コンパイルを扱わない。これは、ＣＰＵサーバによって
行われる。端末では、ＣＰＵサーバのオペレーティング
システムを単一のさらに小型のプロセッサ用にビットマ
ップ・グラフィックスのサポートを付けて変更したもの
を実行させ、これを用いてウィンドウシステムおよびテ
キストエディタなどのプログラムを実行させる。ファイ
ルは、標準のファイルサーバによって端末ネットワーク
接続を介して与えられる。
【００２５】旧式のキャラクタ端末のように、すべての
Gnotは、ローカルにもファイルサーバ上にも独自の記憶
装置を持っていないので、同等である。この端末は高価
ではないので、研究センタの各人が２台（１台は職場
に、もう１台は自宅に）持つことができる。自宅に居て
Gnotで仕事をしている人は、職場と全く同じシステムを
見ることになる。これは、ファイルおよび処理資源がす
べて効率的に共有・保守できるように職場に残っている
からである。
【００２６】［ネットワーク］ プラン９は、構成要素を接続する種々のネットワークを
有する。ＣＰＵサーバとファイルサーバはＤＭＡコント
ローラを介して通信を行う。これは、例えばコンピュー
タセンタまたは部門ごとの処理資源の規模に対して実際
的であるにすぎない。さらに離れたマシンどうしは、イ
ーサネットまたはデータキットなどの通常のネットワー
クで接続される。端末またはＣＰＵサーバは、性能面を
考慮しなければ、遠隔のファイルサーバを全く透過的に
利用することができる。データキットネットワークは全
国的な範囲にわたるので、プラン９のシステムは、大規
模に構築することができる。費用を低く抑えるために、
Gnotは、標準の電話線および単一チップインタフェース
を用いる安価なネットワークを使用する。（処理効率
は、毎秒約１２０キロバイトとかなり高い。）端末は単
に通信を仲介する（ファイルサーバに接続するようにＣ
ＰＵサーバに指示はするが、結果としての通信には関与
しない）だけなので、端末に対する比較的低い帯域幅
も、システムの全体的な性能には影響がない。
【００２７】図７は、プラン９の構成要素およびトポロ
ジー（位相幾何学的配置表現）を示す図である。プラン
９のシステム７０１は、ファイルサーバ７０５、ＣＰＵ
７０３、およびGnot７１１からなる。ＣＰＵ７０３およ
びファイルサーバ７０５のクラスタ７１７、およびGnot
７１１のクラスタ７１９は、全国的な長距離通信ネット
ワーク７１５によって接続されている。クラスタ７１９
内のGnot７１１は、ＬＡＮなどの分散ネットワーク７１
３によって接続され、クラスタ７１７内のファイルサー
バ７０５およびＣＰＵ７０３は、高速ＤＭＡリンク７０
９によって接続されている。
【００２８】［名前空間］ プラン９には２種類の名前空間がある。すなわち、ネッ
トワーク上の種々のサーバの名前のグローバル（広域）
空間およびプロセッサから見えるファイルおよびサーバ
のローカル（局所）空間である。データキットに接続さ
れているマシンおよびサーバの名前は、階層的であり、
例えば、nj/mh/astro/helixというように、（大まか
に）地域を、そして建物、部門、部門におけるマシンを
定義する。ネットワークによって、そのマシンに対する
命名がなされるので、グローバル名の命名の問題は、プ
ラン９において直接扱う必要はない。しかし、プラン９
の基本的な作用として、ネットワークサービスをプロセ
スごとにローカル名前空間に結び付けることがあげられ
る。このローカル名前空間のきめ細かい管理は、カスタ
マイズ可能性、透過性、および異種混交性の問題に取り
組むのに使用される。
【００２９】プラン９のサービスと通信するためのプロ
トコルは、ファイル指向であり、すべてのサービスはフ
ァイルシステムを実現しなければならない。つまり、ロ
ーカルであれリモートであれ、各サービスは、サーバの
名前空間という階層へと集められるファイル状のオブジ
ェクトの集合へと配列される。ファイルサーバにとって
は、これは自明な要求である。他のサービスについて
は、仮想的にならなければならない場合がある。例え
ば、印字（プリント）サービスであれば、プロセスが印
字されるべきファイルを生成する場所のディレクトリと
して実現される。その他の例は以下の節で説明するの
で、僅かな間、ネットワーク中に分散する普通のファイ
ルサーバの集合のみを考えることにする。
【００３０】プログラムがあるプラン９のサービスを
（ネットワーク固有の、プラン９自体の外部にある機構
を用いて）呼び出すと、プログラムは、そのサービスの
名前空間のルートに接続される。通常、ローカルオペレ
ーティングシステムによってファイル指向のシステムコ
ールの集合へと仲介されるようなプロトコルを用いて、
プログラムは、前記の名前空間におけるファイルに対
し、オープン、作成、削除、読出し、および書込みを行
うことによって、サービスにアクセスする。
【００３１】ネットワーク上で利用可能なサービスの集
合から、プラン９のユーザは、所望のものを、例えば、
個人のファイルが存在するファイルサーバ、おそらく
は、データが蓄えられている他のファイルサーバ、また
はグループの計画のためのソフトウェアが書かれている
部門のファイルサーバ、を選択する。それらの種々のサ
ービスの名前空間は、attachというプラン９の基本的な
オペレータによって、収集されてユーザ自身の個人の名
前空間に連結される。ユーザの名前空間は、使用中のサ
ービスのすべての空間の合併によって形成される。ロー
カル名前空間は、各ユーザに対し、一般には端末ごと
に、ローカルオペレーティングシステムによって作られ
る。名前空間は、プロセスごとのレベルで変更可能であ
るが、実際には、ログイン時に作られ、そのユーザのす
べてのプロセスによって共有される。
【００３２】システムにログインするには、端末におい
て、いずれのファイルサーバに接続するべきかを端末に
命令する。端末は、サーバを呼び出し、ユーザを認証し
（以下参照）、さらにそのサーバからオペレーティング
システムをロードする。次に、端末は、ユーザの個人の
ディレクトリにあるprofileというファイルを読む。pro
fileには、いずれのサービスがデフォルトで使用される
べきか、またそれらをローカル名前空間のいずれの場所
に結び付けるべきかを定義するコマンドが、入ってい
る。例えば、使用されるべき主なファイルサーバは、ロ
ーカル名前空間のルート（/）に結び付けられ、プロセ
スファイルシステムは、ディレクトリ/procに結び付け
られる。その後、プロファイルは、ウィンドウシステム
を開始させるのが一般的である。
【００３３】ウィンドウシステムにおける各ウィンドウ
内で、ローカルにコマンドを実行する場合に使用される
コマンドインタプリタが、profileによって作られた名
前空間において解釈されるファイル名を用いて、実行さ
れる。コンパイルなどの演算集約的なアプリケーション
については、ユーザは、コマンドを実行させるためにＣ
ＰＵサーバを（自動的に、または名前によって）選択す
るコマンドcpuを走らせる。cpuとタイプした後、ユーザ
には、コマンドインタプリタからの正規のプロンプトが
見える。しかし、そのコマンドインタプリタは、cpuコ
マンド自体と同じ名前空間（ディレクトリも同じ現在の
ディレクトリ）にあるＣＰＵサーバ上で実行されてい
る。端末は、その名前空間の記述をＣＰＵサーバに送
り、そのＣＰＵサーバにおいて、同一の名前空間を作っ
て、端末によって作られたシステムのカスタマイズされ
たビューを、ＣＰＵサーバ上にあるものと同じにする。
（名前空間の記述は、名前空間それ自体以外で使用され
ることが多いので、ＣＰＵサーバは、可能であれば、端
末による仲介を要求せずに高速リンクを使用する。）cp
uコマンドは、後続のコマンドの効率に影響を与えるだ
けであり、利用可能なサービスやそれらアクセス方法に
は無関係である。
【００３４】サービスを見つけるサービスも含めて、プ
ラン９において利用可能なサービスの大きなカタログが
あるが、使用法およびこの設計の可能性を説明するに
は、２、３のサービスで十分である。
【００３５】［プロセスファイルシステム］ ローカルサービスの一例は、「プロセスファイルシステ
ム」であり、これによって、ファイル指向インタフェー
スによるプロセスの実行の検査およびデバッグが可能と
なる。
【００３６】プロセスファイルシステムのルートは、慣
例どおりディレクトリ/procに結び付ける。（プラン９
において慣例は重要である。名前空間は、いやおうなし
に作られるが、多くのプログラムは、名前空間がある形
式を持つことを必要とするような慣例的な名前を有す
る。プログラム/bin/rc（コマンドインタプリタ）がい
ずれのサーバから来るかは重要ではないが、そのプログ
ラムは、それを要求するコマンドによってアクセス可能
となるようにこの名前を持たなければならない。）結び
付けた後は、ディレクトリ/procそれ自体に、システム
におけるローカルプロセスごとに、そのプロセス固有の
数的識別子と同じ名前の１つのサブディレクトリが含ま
れる。（リモートのＣＰＵサーバで走っているプロセス
も見えるようにすることができる。これは、後述す
る。）各サブディレクトリには、そのプロセスのビュー
を実現するファイルの集合が含まれる。例えば、/proc/
77/memには、プロセス番号７７の仮想メモリのイメージ
が入っている。プラン９の/procにより、他のファイル
を通して他の関数が実現される。ここで、各プロセスに
対して与えられるファイルのリストを掲げる。プロセス
イメージの仮想メモリ。ファイルにおけるオフセット
は、そのプロセスにおける仮想アドレスに対応する。プ
ロセスの制御動作。このファイルに（writeシステムコ
ールによって）送られたメッセージによって、プロセス
は、実行の停止、終了、再開などを行う。プログラムの
発生源であるファイル。これは、一般に、対象のプロセ
スのシンボルテーブルを調べるためにデバッガによって
使用されるが、名前は別としてすべての点においてオリ
ジナル・ファイルである。従って、そのプログラムを新
たに起動するように、コマンド・インタプリタに対し
「/proc/77/text」とタイプ入力することもできる。適
切な許可を有するプロセスであれば、他のプロセスのノ
ート（note）ファイルを書いて、プロセス間通信のため
に非同期メッセージをそれに送ることができる。システ
ムは、このファイルを、例えばプロセスがゼロで割ると
いうような誤動作をする場合に、（毒入りの）メッセー
ジを送るためにも使用する。プロセス状態の固定フォー
マットのＡＳＣＩＩ表現。これには、そのプロセスが実
行される元のファイルの名前、それが消費したＣＰＵ時
間、現在の状態などが含まれる。
【００３７】状態(status)ファイルは、異種混交性およ
び可搬性がシステムの機能のためにファイルサーバ・モ
デルによっていかに処理され得るかを説明するものであ
る。cat /proc/*/statusというコマンドによって、シス
テムにおけるすべてのプロセスの状態が（読むことは可
能であるが幾分見にくく）表示される。実際に、プロセ
ス状態コマンドpsは、そのように集められたＡＳＣＩＩ
テキストを書式化したものである。psに対するデータ源
は、１ページの長さであり、マシンを問わず完全な可搬
性がある。いくつか種類の異なるマシンのプロセスに対
するファイルが/procに入っている場合でも、同様の実
装が有効である。
【００３８】/procが与えるサービスが、多様ではあっ
ても、プロセスの概念を全くファイルのようにしている
わけではないことは重要である。例えば、プロセスを終
了させるために、そのプロセス・ファイルを削除しよう
としても無駄であり、プロセス・ファイルを生成するこ
とによって、新たなプロセスを開始することもできな
い。ファイルは、プロセスの有効なビュー(active vie
w)を与えるが、ファイルを文字どおり表すわけではな
い。サービスをファイルシステムとして設計する場合、
この区別が重要である。
【００３９】［プラン９のサービスのアーキテクチャの
概要：図１］ 既に述べたように、サービスは、ファイルシステムとし
て実施される、つまり、プラン９のオペレーティングシ
ステムによってコンピュータ上で実行中のプロセスにと
っては、サービスはファイルの集合として映る。プロセ
スは、サービスによって与えられる「ファイル」にファ
イル読出し操作を行うことによって、サービスからデー
タを得ることができ、それらの「ファイル」にファイル
書込み操作を行うことによって、サービスにデータを与
えることができる。プロセス・サービスによって与えら
れる「ファイルシステム」について既に詳細に説明した
ように、サービスは、実際にファイルを保持する必要は
なく、プロセスによるファイル操作への要求に対し、単
に、それらを保持しているかのように反応するだけでよ
い。例えば、プロセスがサービスによって保持されてい
るある「ファイル」を読む場合、サービスは、その「フ
ァイル」を読むプロセスにデータを与えなければならな
い。
【００４０】サービスとプロセスとの間の関係の概要を
図１に示す。サービスのアーキテクチャ１０１は、プロ
セスが１つ以上のサービス１２３にアクセスするために
ファイルシステムをいかに使用するかを示している。プ
ロセス１０２は、Gnot７１１またはＣＰＵ７０３のいず
れかにおいて実行中であり、サービスは、プロセス１０
２が実行中のプロセッサに対して局所的に実施されるこ
ともあれば、ファイルサーバ７０５のような遠隔の装置
において実施されることもある。
【００４１】図１に示したように、各サービスは、その
サービスを使用するプロセッサ１０２に１つ以上のファ
イルの木構造を与える。ファイルの木構造は、データ・
ファイル１３１とディレクトリ・ファイル１２７および
１２９とから成り立つ。ディレクトリ・ファイルは、フ
ァイルのリストが入っているファイルである。ディレク
トリ・ファイルに掲げられたファイルは、ディレクトリ
・ファイルかデータ・ファイルのいずれかである。ファ
イル木構造１２５（ａ）から分かるように、データ・フ
ァイル１３１Ｂ、ＣおよびＤが、ファイル木構造の
「葉」であるのに対し、ディレクトリ・ファイル１２９
は、その木構造が分岐する点を占める。木構造全体の根
元には、単一のルート・ディレクトリ・ファイル１２７
がある。サービス１２３中の各ファイルは、ファイル名
を有する。好ましい実施例では、ファイル名は、文字列
である。
【００４２】プロセス１０２は、プラン９のオペレーテ
ィングシステムによって与えられるファイルシステム関
数へのコールによって、サービス１２３中のファイルに
アクセスする。関数には主な種類が２つある。ファイル
・ロケータ関数（ＦＬ）１１３はファイルを検索する。
ファイル・アクセス関数（ＦＡ）１１１は、ファイル・
ロケータ関数１１３によってファイルが検索された後
に、そのファイルをアクセスする。ファイル・ロケータ
関数１１３へのコールは、矢印１０７で表し、ファイル
・アクセス関数１１１へのコールは、矢印１０５によっ
て表す。
【００４３】前述のように、プラン９の各プロセス１０
２は、名前空間に関係付けられている。プロセス１０２
の名前空間により、サービス１２３によって与えられる
いずれのファイルにプロセス１２がアクセスできるかが
決定される。好ましい実施例におけるプロセス１０２の
名前空間は、ファイル木構造１２５および（または）そ
れらの木構造の下位木構造から構成される単一のファイ
ル木構造１１７からなる。このように、ファイル・ロケ
ータ関数１１３によって維持・使用される名前空間１１
５（ｏ）は、プロセス１０２（ａ）に対する名前空間で
ある。図１から分かるように、プロセス１０２（ａ）の
名前空間には、サービス１２３（ａ）からの１２５
（ａ）およびサービス１２３（ｋ）からのファイル木構
造１２５（ｋ）を含むファイル木構造１１７（ｏ）が入
っているが、サービス１２３（ｂ）からのファイル木構
造１２５（ｂ）は含んでいない。ファイル木構造１１７
（ｏ）は、プロセス１０２のファイル木構造１１７
（ｏ）のディレクトリ・ファイル「Ｘ」を木構造１２５
（ａ）のルートと同じにし、かつファイル木構造１１７
（ｏ）のディレクトリ・ファイル「Ｙ」をファイル木構
造１２５（ｋ）のルートと同じにすることによって、構
成されている。「Ｘ」および「Ｙ」それ自体がいかにし
て名前空間１１５（ｏ）に存在するようになったかの詳
細は後述する。
【００４４】名前空間１１５（ｏ）において、ファイル
は、パス名によって検索される。パス名は、検索すべき
ファイルの名前、およびそのファイルの元のファイル木
構造における検索開始点からそのファイルまでのすべて
のディレクトリ・ファイルの名前を含むファイル名リス
トである。そのファイルの元のファイル木構造における
検索開始点をワーキング・ディレクトリという。従っ
て、ワーキング・ディレクトリが、ディレクトリ・ファ
イルＸならば、前記のパス名は、Ａ／Ｃである。Ａ／Ｃ
における文字「／」は、パス名における名前を区切る役
目をする。さらに、任意のファイルは、その完全なパス
名（すなわち、ルート・ディレクトリを表す文字
「／」、ルート・ディレクトリとそのファイルとの間の
すべてのディレクトリ名、およびそのファイル名）を指
定することによって検索することができる。それらのフ
ァイル名も「／」によって区切られる。従って、名前空
間１１５（ｏ）におけるファイルＣの完全なパス名は、
／Ｘ／Ａ／Ｃである。
【００４５】プラン９においては、多数のプロセス１０
２が、１つの名前空間を共有する。ある名前空間を共有
するプロセス１０２によって、１つのプロセス・グルー
プ１０３が構成される。従って、プロセス・グループ１
０３（ｏ）に所属するプロセスは、ファイル木構造１１
７（ｏ）によって定義される名前空間１１５（ｏ）を共
有し、一方、プロセス・グループ１０３（ｚ）内のプロ
セスは、名前空間１１５（ｚ）を共有する。プロセス
は、プラン９において、システム・コール「fork」によ
って生成される。新たに生成されたプロセス１０２は、
その「fork」システム・コールを行ったプロセス１０２
と同じ名前空間１１５に関係付けられた状態を維持する
ので、そのforkシステム・コールを行ったプロセス１０
２と同じプロセス・グループに属する。プロセス１０２
がシステム・コール「forkpgrp」を行うと、新たなプロ
セス・グループが確立される。このコールは、引数を１
つだけ持つ。すなわち、新たなプロセス・グループがプ
ロセス１０２の古い名前空間１０５のコピーを受け取る
か、または最小限のデフォルトの名前空間１０５を受け
取るかを示すフラグである。システム・コールを実行す
ることによって、そのシステム・コールを行っているプ
ロセス１０２は新たなプロセス・グループに置かれる。
forkpgrpシステム・コールによって、プロセス１０２に
対し新たな名前空間１１５が確立されると、新たな名前
空間１１５における変化は、そのforkpgrpシステム・コ
ールを行っているプロセス１０２が以前に所属していた
プロセス・グループ１０３の古い名前空間には、影響を
与えない。
【００４６】プロセス・グループ１０３に属するプロセ
スは、そのプロセス・グループに対する名前空間１１５
を変更することができる。これを行うには、プロセス
は、２つの名前空間修正関数のうちの１つを使用する。
第１の関数は、「bind（結合）」であり、その名前空間
に既に存在する名前を新たなパス名によって指定される
ファイルと同じにする。bindの実行後は、古いパス名に
よって指定されたファイルへの参照は、新たなパス名に
よって指定されるファイルへの参照へと変換される。例
えば、名前空間１１５（ｏ）においてＡというルートを
有する下位木構造をその名前空間においてＨというルー
トを有する下位木構造で置き換える場合には、名前空間
１１５（ｏ）における「bind（"/Y/H","/X/A"）」とい
うシステム・コールが使用される。このbindの後、パス
名／Ｘ／Ａ／Ｋは、下位木構造ＨのファイルＫを参照す
ることになる。
【００４７】第２の関数は、「mount」であり、名前空
間に既にある名前をサービス１２３のルートと同じにす
るものである。詳細は後述するが、サービスのルート
は、小さい整数のファイル記述子（ファイル・ディスク
リプタ）によって表される。従って、マウント関数「mo
unt（FD,"/X"）」によって、ファイル木構造１１７
（ｏ）のディレクトリ名「Ｘ」は、サービス１２３
（ａ）のファイル木構造１２５（ａ）のルートと同じに
なる。マウントした後は、パス名／Ｘ／Ａによってファ
イル木構造１２５（ａ）のファイルＡが参照される。
【００４８】プラン９における「mount」および「bin
d」の更なる改良点は、パス名どうしの間またはファイ
ル記述子とパス名との間に３種類の異なる関係を指定で
きることである。第１の関係は、置換である。この関係
が指定された場合、新たな名前またはファイル記述子に
よって参照されるものが、すべて古い名前によって参照
されるものに置き代わる。第２および第３の関係によ
り、結合ディレクトリと称するものが確立される。結合
ディレクトリが確立されると、bind関数において使用さ
れる古い名前と新たな名前は、共にディレクトリ・ファ
イルを示さなければならず、またmountコマンドにおけ
る古い名前は、ディレクトリ・ファイルを示さなければ
ならないが、他方、ファイル記述子は、サービス１２３
中のファイル木構造のルートを示さなければならない。
bindまたはmountの作用は、新旧のディレクトリ・ファ
イルの結合体である新たなディレクトリを確立すること
である。関係beforeによって、古いディレクトリの前に
新たなディレクトリが探査されるような結合ディレクト
リが確立され、もう１つの関係afterによって、古いデ
ィレクトリの後に新たなディレクトリが探査されるよう
な結合ディレクトリが確立される。従って、結合コマン
ド「bind（"/Y/H","/X/A",BEFORE）」により、ファイル
Ｉ、Ｊ、ＫがファイルＢおよびＣより先行するようなデ
ィレクトリが確立され、ファイル・ロケータ関数１１３
がパス名／Ｘ／Ａ／Ｃに応答する場合、その関数は、ま
ずディレクトリＨを通って探査し、次にディレクトリＡ
を通って探査することになる。ロケータ関数がファイル
を求めてディレクトリを探査する順序をこのように決定
することにより、結合ディレクトリは、ＵＮＩＸのよう
なオペレーティングシステムにおけるリスト探査によっ
て与えられる制御と同じ種類の制御を与える。
【００４９】名前空間の配置を変えずにファイルの位置
を特定するファイル・ロケータ関数１１３は、引数とし
てパス名を取り、ファイル記述子を返す。ここにおい
て、ファイル記述子は、ファイルを参照するためにファ
イル・アクセス関数において使用される小さい整数であ
る。ファイル・ロケータ関数１１３には、パス名によっ
て指定されたディレクトリ・ファイルをプロセス１０２
のワーキング・ディレクトリに変更する「chdir」、お
よびパス名によって指定されたファイルを開く「open」
が含まれる。「chdir」および「open」は、ワーキング
・ディレクトリのファイルおよび開かれたファイルに対
するファイル記述子をそれぞれ返す。さらに、「creat
e」関数は、パス名において指定されたファイルが生成
されると言う点を除けば、「open」と同様に作用する。
そして、ファイル・アクセス関数１０５は、ファイルの
読出し・書込み、ファイルの状態の設定・獲得、および
ファイルのクローズを行う場合に、ファイル・ロケータ
関数によって与えられるファイル記述子を使用する。
【００５０】アーキテクチャ１０１において、ファイル
システム１０９は、プロセス１０２によって行われるフ
ァイル・アクセス・コール１０５およびファイル・ロケ
ータ・コール１０７をサービス・ファイル操作要求に変
換する。各サービス・ファイル操作要求によって、サー
ビス１２３に、そのファイル木構造１２５のうちの１つ
にあるファイルに対してある操作を実行することを要求
する。このような要求には２種類ある：矢印１１９で示
したサービス・ファイル・アクセス要求、および矢印１
２１で示したシステム・ファイル・ロケータ要求であ
る。あるサービス１２３に対する要求１１９および１２
１は、関数呼び出し（ファンクション・コール）の形式
を取り、他のサービス１２３に対しては、要求はファイ
ル・プロトコルの形式を取る。関数読出しの場合、ファ
イルは、ファイル名またはファイル記述子（descripto
r）によって表され；ファイル・プロトコルの場合、フ
ァイルは、ファイル名またはファイル識別子（identifi
er）によって表される。以降の説明のために、ファイル
記述子およびファイル識別子をファイル指定子（specif
ier）という用語に包括する。
【００５１】ファイルシステム１０９において、プロセ
ス１０２によって使用されるファイル記述子は、サービ
ス１２３によって与えられるファイル・ハンドルqidに
関係付けられる。この関係付けは、ファイル記述子のフ
ァイル識別子への関係付け、およびファイル識別子のqi
dへの関係付けによって、直接的または間接的に行われ
る。プロセス１０２によって使用されるファイル記述子
とqidとの間に関係付けがある場合、プロセス１０２
は、qidによって表されるファイルへの接続（connectio
n）があると称する。同様に、サービス１２３におい
て、qidは、１つ以上のファイル指定子に関係付けられ
ている。所与のqidに関係付けられたファイル指定子を
有するシステム・ファイル要求を発生させるファイルシ
ステム・コール１０５によって、qidによって指定され
るファイルに対してファイル操作が行われることにな
る。
【００５２】ファイルを名前、すなわちサービス１２３
におけるqidではなく、名前、すなわちファイル指定子
によって表すことの利点は、異なるサービスによって、
名前およびqidの間に異なる関係を確立することができ
ることである。例えば、前記のプロセス・サービスなど
のサービスにおいては、すべてのプロセスによって使用
されるファイル名がファイルの単一の集合を示すことが
有益であり；詳細に後述する予定の８．５ウィンドウ・
サービスのような他のサービスでは、各プロセスによっ
て使用されるファイル名は、そのプロセス固有のファイ
ル集合を示す。結果として、アーキテクチャ１０１にお
けるファイル名は、Ｃなどのプログラミング言語におけ
る変数の性質と類似の性質を有する。ファイル名のある
ものは、グローバルな静的変数名に似ている；グローバ
ルな静的変数名が、その変数名が現れるすべてのコード
において同一のメモリ位置を示すように、プロセス・サ
ービスによって与えられるようなファイル名は、すべて
のプロセスにおいて同じファイルを示す。ファイル名の
中には、局所的変数名に似たものがある；局所的変数名
が、プロシージャの呼び出しの度に異なるメモリ位置を
示すように、８．５サーバによって与えられるようなフ
ァイル名は、各プロセスにおいて異なるファイルを示
す。ファイル名がいずれの性質を有するかは、勿論、そ
のファイルを与えるサービス１２３によって決定され
る。変数について用いられる用語との類似性により、サ
ービス１２３が、そのファイルのインスタンスを与える
と言える。従って、プロセス・サービスにより、そのフ
ァイルの各々の単一のインスタンスが与えられ、そのサ
ービスによって与えられるファイルの１つへの接続を有
するプロセス１０２は、そのファイルへの接続を有する
他のすべてプロセス１０２と同じファイルにアクセスす
ることができる。一方、ウィンドウ・サービスは、その
ファイル木構造のルートとの接続を確立する各プロセス
１０２に対し、そのファイル木構造におけるファイルの
別個のインスタンスを与え；ウィンドウ・サービスによ
って与えられるファイルとの接続を有するプロセス１０
２は、そのファイルの多数のインスタンスの１つへの接
続を有する。
【００５３】各サービス１２３は、次の種類のサービス
・ファイル・ロケータ要求１２１を処理することができ
る。attach：指定されたサービス１２３におけるファイ
ル木構造のルートに対するファイル指定子が与えられる
と、そのルートに対するqidをファイルシステム１０９
に返す。walk：所与の名前を有するファイルを求めてフ
ァイル指定子によって指定されたディレクトリ・ファイ
ルを探査し、かつ求めるファイルが見つかった場合、そ
のファイルのqidにファイル指定子を関係付けて、そのq
idを返す。create：ファイル指定子によって指定された
ディレクトリ・ファイルに新たなファイルを生成し、そ
のファイルに指定された名前を与え、そのファイル指定
子を新たなファイルに対するqidに関係付け、さらにそ
のqidを返す。remove：ファイル指定子によって指定さ
れたファイルをサーバから削除し、ファイル指定子をqi
dから切り放し、さらに削除中のファイルの名前を返
す。
【００５４】さらに、各サービスは、次の種類のサービ
ス・ファイル・アクセス要求を処理することができる。
open：ファイル・アクセス操作のために、ファイル指定
子によって指定されたファイルを準備し、そのファイル
指定子に関係付けられたqidを返す。clone：ファイルを
表す第１のファイル指定子およびファイルをまだ表して
いない第２のファイル指定子が与えられた場合、第２の
ファイル指定子を第１のファイル指定子に関係付けられ
たファイルに関係付ける。read：ファイル指定子、その
ファイルにおけるオフセット、および総数が与えられた
場合、オフセットで始まる総数で指定された数のバイト
を読み出す。write：ファイル指定子、そのファイルに
おけるオフセット、総数、およびデータが与えられた場
合、オフセットで始まる総数で指定された数のバイトに
データを書き込む。clunk：ファイル指定子が与えられ
た場合、ファイル指定子とそのファイルとの間の関係付
けを終了させる。stat：ファイル指定子およびファイル
状態情報を得るためにサービスによって必要とされる情
報が与えられた場合、そのファイルの状態を返す。wsta
t：ファイル指定子およびファイルの状態を変更するた
めにサービスによって必要とされる情報が与えられた場
合、そのファイルの状態を変更する。
【００５５】すべてのサービス１２３は、前記の操作を
実施できなければならないが、操作が、実際には、全く
作用しなかったり、エラーを生じたりする場合もある。
例えば、サービス１２３が、プリンタで、書込み専用
「ファイル」しか実施できない場合には、読出し操作に
よってエラーを生じることになる。
【００５６】カーネル・サービスおよびプロトコル・サ
ービス：図２プラン９の好ましい実施例には、２種類の
サービスがある。カーネル・サービスは、サービス・フ
ァイル操作要求２０５および２０７が、プラン９のカー
ネル関数の呼び出しによって実施されるサービスであ
る。プロトコル・サービスは、サービス・ファイル操作
要求２０５および２０７が、プラン９のファイル・プロ
トコルによって実施されるサービスである。プロトコル
・サービスにおいて、各サービス・ファイル操作要求
は、プロセス１０２のためにプロトコル・サービスに対
して送られる往信メッセージ（tmessage）によって開始
される。プロトコル・サービスは、その往信メッセージ
に対し、プロトコル・サービスからそのプロセスに返さ
れる情報を入れた返信メッセージ（rmessage）によって
応答する。プロトコル・サービスに対するサービス・フ
ァイル操作要求を構成する往信メッセージおよび返信メ
ッセージは、トランザクション（処理）と称する。例え
ば、プロトコル・サービスに対するサービス・ファイル
・リード操作要求は、次のようなリード往信メッセージ
（tread）およびリード返信メッセージ（rread）からな
るリード・トランザクションである。 tread: 型指定子、ファイル識別子、タグ、オフセッ
ト、総数 rread: 型指定子、ファイル識別子、タグ、総数、デー
タ ファイル識別子は、ファイルシステム１０９におけるフ
ァイル記述子、およびファイルシステム１０９およびプ
ロトコル・サービスにおけるqidに関係付けられてい
る。treadメッセージには、このメッセージがリード往
信メッセージであることを示す型指定子、ファイル識別
子、このメッセージを識別するタグ、読出しを開始する
べきファイル内のオフセット、およびバイト数が、含ま
れる。rreadメッセージには、このメッセージがリード
返信メッセージであることを示す型指定子、ファイル識
別子、このメッセージを識別するタグ、実際に読み出さ
れるバイト数、およびデータそのものが、含まれる。読
出しの結果、エラーとなった場合、プロトコル・サービ
ス２０９は、rreadメッセージの代わりに、エラー・メ
ッセージを返す。それは次のような形式である。rerro
r: 型指定子、タグ、エラー・メッセージ文字列
【００５７】各プロトコル・サービス２０９は、先に掲
げたサービス・ファイル操作要求のそれぞれに対応する
トランザクションを実行できなければならない。プロト
コル・サービス２０９に求められることは、これだけで
あるから、プロトコル・サービス２０９は、マウント・
サービス２０３が実行しているプロセッサのアーキテク
チャと完全に異なるアーキテクチャを有するプロセッサ
上に実現しても良い。プロトコル・サービス２０９を使
用するために必要なことは、それによってプロトコルが
送受信され得るようなプロトコル・サービス２０９への
接続だけである。さらに、好ましい実施例では、プロト
コルによって送りかつ戻されるデータは、所与のファイ
ル木構造を与えるすべてのプロトコル・サービス２０９
によって使用される所定の書式を有する。従って、プロ
セス１０２は、このプロセス１０２がその上で実行中の
マシンの種類またはプロトコル・サービス２０９がその
上で実行中のマシンの種類にかかわらず、所与のファイ
ル木構造を与える任意のプロトコル・サービスを使用す
ることができる。
【００５８】図２において、プロトコル・サービス（Ｐ
Ｓ）２０９は、前記のサービス・ファイル・ロケータ要
求およびサービス・ファイル・アクセス要求に対応する
ファイル・プロトコルを伴うファイル・ロケータ・トラ
ンザクション２０５およびファイル・アクセス・トラン
ザクション２０７を実行する。特殊なカーネル・サービ
スであるマウント・サービス２０３が、サービス・ファ
イル・ロケータ要求を指定する関数コール２１７および
サービス・ファイル・アクセス要求を指定する関数コー
ル２１９をファイルシステム１０９から受信する。次
に、マウント・サービス２０３は、これらの関数コール
に応じて、プロトコル・サービス２０９により対応する
トランザクションを行う。このトランザクションを行う
ために、マウント・サービス２０３は、多数の通信サー
ビス２１５を利用する。このような通信サービスには、
２種類ある：ネットワーク通信サービス（ＮＳ）２１４
およびプロセス間通信サービス（ＩＰＳ）２１６であ
る。ネットワーク通信サービスは、プロセス１０２が実
行中のＣＰＵにネットワークを介して接続されている遠
隔のプロトコル・サーバ２１３との通信にネットワーク
を利用するものである。プロセス間通信サービス２１６
は、局所的なプロトコル・サーバ２１１との通信にプロ
セス間通信システムを利用するものである。好ましい実
施例において、ＩＰＳ２１６によって使用されているプ
ロセス間通信システムは、ＵＮＩＸオペレーティングシ
ステムにおけるものと同様のパイプ・システムである。
通信サービス２１５が、プロトコル・サーバ２０９に接
続されると、このことが、ファイル記述子によって表さ
れる。「マウント」システム・コールで使用されるの
は、このようなファイル記述子である。
【００５９】括弧内の参照番号によって分かるように、
ネットワーク通信サービス２１５は、図７の分散ネット
ワーク７１３、長距離ネットワーク７１５、およびＤＭ
Ａネットワーク７０５を使用することができる。局所的
プロトコル・サービス２１１は、Gnot７１１に対する
８．５サービスのようなサービスの場合もあり、さらに
は、プロセス間通信手段によって所与のプロセス１０２
と通信を行う別のプロセス１０２の場合もある。既に指
摘したように、プロトコル・サービス２０９とマウント
・サービス２０３のようなカーネル・サービスとの間の
区別は、位置ではなく、プロトコル・サービス２０９が
トランザクションをマウント・サービス２０３によって
行うという点に過ぎない。次の８．５サービスの説明で
詳細に示すとおり、プロトコル・サービス２０９に関す
るこの特徴の利点は、局所的なプロセッサ上を走ってい
るプロセス１０２および図７のＣＰＵのような遠隔のプ
ロセッサ上を走っているプロセス１０２が、共に同一の
プロトコル・サービス２０９を使用できることである。
【００６０】プラン９のファイル操作の実施以下におい
て、プラン９のファイル操作の実施例を説明する。最初
に、ファイルを表すために使用されるデータ構造体なら
びにそのデータ構造体とプロセス１０２およびサービス
１２３との関係を説明し、次に、プロセスの名前空間１
１５を表すために使用されるデータ構造体、そして最後
に、典型的なファイル操作の例を説明する。
【００６１】プロセス１０２とファイルとの間の接続の
表現：図３〜５プロセス１０２が接続を有する先のファ
イルは、チャネル・データ構造体によって表される。あ
るファイルに対するチャネル・データ構造体は、少なく
とも、そのファイルを与えているサービス１２３を指定
し、かつサービス１２３によって与えられるqidを、プ
ロセス１０２がそのファイルを示すために使用するファ
イル記述子に関係付ける。サービス１２３がプロトコル
・サービス２０９である場合には、そのチャネルは、さ
らに、そのファイル・プロトコルにおけるファイルに対
して使用されるファイル識別子およびプロトコル・ファ
イルに対するプロトコル・チャネルを、ファイル記述子
に関係付ける。
【００６２】図３において、チャネル・データ構造体３
０１は、次の構成要素を有する。すなわち、ロック３０
３：１つ以上のプロセスが同時にチャネル３０１にアク
セスを有することを防ぐ。参照指数（ｒｅｆ）３０７：
チャネルが他のカーネル・データ構造体によって指し示
されたかどうかを示す。ネクスト／オフセット・フィー
ルド３０９：チャネル３０１が使用されていない場合、
このフィールドは、使用されていないチャネル３０１の
リストに格納されていて、さらにこの場合、使用されて
いない次のチャネル３０１を示す；チャネル３０１によ
って表されるファイルがアクセスされている場合、この
フィールドは、そのファイルへの現在のオフセットを示
す。カーネル・サービス情報（ＫＳＩＮＦＯ）３１１：
チャネル３０１によって表されるファイルを与えるカー
ネル・サービスを指定する情報が、次の２つのフィール
ドに収容される---種類３１３：このフィールドによ
り、チャネル３０１によって表されるファイルがアクセ
スされる手段としてのカーネル・サービスが指定され；
プロトコル・サービス２０９に対しては、種類フィール
ド３１３によってマウント・サービス２０３が指定され
る；装置（ＤＥＶ）３１５：このフィールドにより、カ
ーネル・サービスによって表される特定の装置が指定さ
れ；マウント・サービス２０３の場合は、装置フィール
ド３１５により、チャネル３０１によって表されるファ
イルを与えるプロトコル・サービス２０９が指定され
る。アクセス情報（ＡＩＮＦＯ）３１７：ファイル・ア
クセスを行うために必要な情報が、次の３つのフィール
ドに収容される---モード３１９：チャネルによって表
されるファイルがいかにアクセスされるかを示す；フラ
グ３１９：ファイルに関する状態情報を収容する；ｑｉ
ｄ３２３：ファイルを与えるサービスが、そのファイル
に割り当てたqidである。マウント情報（ＭＩＮＦ
Ｏ）：チャネル３０１によって表されるファイルのパス
名に影響を及ぼすbindおよびmountに関する情報がどこ
にあるかを示す。mountptr３２７：bindおよびmountに
関する情報があるデータ構造体へのポインタである。mo
untid３２９：mountptr３２７によって示されるデータ
構造体の識別子である。ファイル識別子（ＦＩＤ）３３
１：マウント・サービス２０３がチャネル３０１によっ
て表されるファイルを与えているプロトコル・サービス
２０９に与えるファイル識別子であり、かつそのファイ
ルが接続されている限り、プロトコル・サービス２０９
がそのファイルに対するqid３２３に関係付けるファイ
ル識別子である；好ましい実施例において、チャネル３
０１が生成されたとき、ファイル識別子３３１は、各チ
ャネル３０１に対し固有の値に設定される。補助情報３
３３：装置の種類３１３によって意味が変わる情報。プ
ロトコル・サービス情報（ＰＳＩＮＦＯ）３３５：チャ
ネル３０１によって表されるファイルを与えているプロ
トコル・サービスにファイル・プロトコルがいかにして
送られるかを示す情報である。プロトコル・チャネル
（ＰＣＨＡＮ）３３７：現在のチャネル構造体によって
表されるファイルに関するトランザクションのために使
用される通信サービス２１５を表すチャネル構造体３０
１へのポインタである。ｍｑｉｄ３３９：チャネル３０
１によって表されるファイルを収容しているプロトコル
・サービスにおけるファイル木構造のルート・ディレク
トリのqidである。
【００６３】各プロセス１０２は、そのプロセスが接続
を有する先のファイルの集合に関係付けられている。こ
のファイルの集合には、プロセス１０２の祖先（以前の
代のプロセス）によって確立された接続の接続先であ
り、かつプロセス１０２が「fork」システム・コールに
よって生成されたときに、それによって「継承」された
ファイル、およびプロセス１０２自体によって確立され
た接続の接続先のファイルが、含まれる。この関係付け
は、図４に示したデータ構造体４０１によって達成され
る。さらに、データ構造体４０１は、前記の集合に属す
る各ファイルを、プロセス１０２がそのファイルを参照
するために使用するファイル記述子に関係付ける。
【００６４】データ構造体４０１へのアクセスするため
の開始点は、プロセス１０２に対するユーザ・データ構
造体４０３である。ユーザ・データ構造体４０３におけ
るポインタ４１１は、ファイル記述子の配列（ＦＤＡ）
４１３を示す。ファイル記述子の配列４１３は、ファイ
ル記述子（ＦＤ）４１７によってインデックス付けされ
たチャネル４０１へのポインタの配列である。あるファ
イルが、プロセス１０２に接続されたファイルの集合に
属する場合、そのファイルに対するファイル記述子に対
応する配列４１３におけるエントリ（ＦＤＡＥ）４１５
には、そのファイルに対するチャネル構造体３０１への
ポインタ４２３が入る。このようなチャネル構造体は、
図４においてファイル・チャネル構造体４１９として現
れる。プロセス１０２が接続される接続先のファイルの
集合に対応するファイル・チャネル４１９の集合があ
る。好ましい実施例において、ファイル記述子の配列４
１３は、１００の要素を有するので、各プロセス１０２
は、１００のファイルに接続することができる。
【００６５】既に指摘したように、「bind」、「moun
t」、「chdir」および「open」などのファイル・ロケー
タ関数は、引数としてパス名を取り、そのファイルに対
するファイル記述子４１７を返す。さらに詳細に後述す
るように、パス名の解釈を目的とするファイル・チャネ
ル４１９へのアクセスが、プロセス１０２のファイル木
構造のルートに対するファイル・チャネル４１９へのユ
ーザ・データ構造体４０３におけるポインタ、およびプ
ロセス１０２のワーキング・ディレクトリに対するファ
イル・チャネルへのもう１つのポインタ４０９によって
与えられる。パス名の解釈において使用されるユーザ・
データ構造体４０３のもう１つの構成要素は、要素（Ｅ
ＬＥＭ）４０５であり、これには、現在解釈されている
パス名を構成する名前のリストにある名前が入ってい
る。
【００６６】ファイル・チャネル４１９によって表され
るファイルが、プロトコル・サービス２０９によって与
えられると、ファイル・チャネル４１９は、通信サービ
スを介するプロトコル・サービス２０９との接続を表す
プロトコル・チャネルに関係付けられる。プロトコル・
チャネルは、チャネル構造体３０１を用いても実施され
る。プロトコル・チャネルとして作用するチャネル構造
体３０１において、種類フィールド３１３によって、プ
ロセス間通信サービス２１６またはネットワーク・サー
ビス２１４（好ましい実施例においては、パイプ・サー
ビスまたはＤＡＴＡＫＩＴネットワーク通信サービス）
のいずれかが指定される。フィールド３２７、３２９お
よび３３７は、プロトコル・チャネルにおいては無意味
である。プロトコル・チャネルによって表される接続が
プロセス１０２によって開かれた場合、プロトコル・チ
ャネルへのポインタが、プロセス１０２に対するファイ
ル記述子の配列４１３に配置され、さらにプロトコル・
チャネルが、それに対応するファイル記述子を受け取
る。局所的なプロトコル・サービスへのパイプによる接
続は、そのパイプ生成しているパイプ・システム・コー
ルがプロセス１０２によって実行されたときに、開か
れ、遠隔のプロトコル・サービス２０９へのＤＡＴＡＫ
ＩＴ接続による接続は、ｓｒｖサービス中にその遠隔の
プロトコル・サービス２０９を表すファイルが開かれた
ときに、開かれる。
【００６７】実施例においてファイル・チャネル４１９
をプロトコル・チャネルならびにtmessageおよびrmessa
geを表すデータ構造体に関係付けるために使用されるデ
ータ構造体５０１を図５に示す。前記のように、ファイ
ル・チャネル４１９のＰＣＨＡＮフィールド３３７は、
プロトコル・チャネル５１７を示すが、このプロトコル
・チャネルは、チャネル構造体３０１を用いて実施され
る。tmessageおよびrmessageを表すデータ構造体は、マ
ウント・サービス配列（ＭＮＴＡ）５０２を用いて、そ
の位置が特定される。この配列には、すべてのファイル
・チャネル４１９に対して、プロトコル・サービス２０
９によって与えられるファイルを表すエントリ（ＭＮＴ
Ｅ）５０３が存在する。各エントリ５０３には、１つの
識別子および２つのポインタ---エントリ５０３に対応
するファイル・チャネル４１９へのポインタおよびマウ
ント・サービス・キュー（待ち行列）の構造体（ＭＮＴ
Ｑ）５０９へのポインタ---が含まれる。一方、ファイ
ル・チャネル４１９は、装置フィールド３１５の情報の
一部として、エントリ５０３に対する識別子を含む。マ
ウント・サービス・キューの構造体５０９には、ファイ
ル・チャネル４１９が属するプロシージャを表すデータ
構造体、プロトコル・サービス２０９への接続とファイ
ル・チャネル４１９によって表されるファイルを含むフ
ァイル木構造１２５とを表すプロトコル・チャネル５１
７へのポインタ５１５、およびメッセージ５２０の待ち
行列へのポインタ５１９が含まれる。この待ち行列にあ
るメッセージは、勿論、プロトコル・サービス２０９へ
のファイルを収容したtmessageおよびプロトコル・サー
ビス２０９からのrmessageである。従って、マウント・
サービスの待ち行列５０９によって、メッセージの待ち
行列が、プロトコル・チャネル５１７およびプロセス１
０２に関係付けられる。
【００６８】各メッセージ５２０は、少なくともマウン
ト・サービス・ヘッダ（ＭＮＴＨＤＲ）５２１から構成
される。ファイル・チャネル４１９によって表されるフ
ァイルおよびプロセスの組み合わせに対し１つ以上の未
解決のメッセージが存在することがあるので、マウント
・サービス・ヘッダ５２１には、ファイル・チャネル４
１９によって表されるプロセスとファイルの組み合わせ
に対する他のメッセージへのヘッダにヘッダ５２１を連
結するポインタ５２７および５２９が含まれる。マウン
ト・サービス・ヘッダ５２１は、さらに、ファイル・チ
ャネル４１９が所属するプロセスに対するプロセス・デ
ータ構造体へのポインタを含む。
【００６９】メッセージ５２０が、rmessageである場
合、そのメッセージのデータ以外の部分は、rhdr５２５
に置かれ、tmessageである場合は、受信されたメッセー
ジのデータ以外の部分は、thdr５２３に置かれる。この
ように、これらのフィールドには、メッセージの型、マ
ウント・サービス２０３がファイルに関係付けたファイ
ル識別子、および必要に応じたその他の情報が、含まれ
る。例えば、メッセージがライト往信（twrite）メッセ
ージの場合、thdr５２３には、そのメッセージの型、そ
のファイルのファイル識別子、書き込むべきバイト数、
および書込み開始位置のオフセットが含まれる。さら
に、thdr５２３およびrhdr５２５には、そのメッセージ
によって送信または受信されるデータを収容するマウン
ト・バッファ５３３へのポインタ５３１が含まれる。
【００７０】メッセージ７２０は、引数としてファイル
・チャネル４１９に対応するエントリ５０３およびマウ
ント・ヘッダ５２１を取る関数によって送信される。こ
の関数は、エントリ５０３を用いてプロトコル・チャネ
ル５１７の位置の特定し、マウント・ヘッダ５２１によ
って指定されたメッセージ５２０が、プロトコル・チャ
ネル５１７によって指定された接続に出力される。送信
と同時に、そのメッセージを送信中のプロセス１０２
は、応答を求めて待機する。応答は、受信されると、メ
ッセージ５２０に置かれ、プロセス１０２が起こされ、
このプロセスによって、メッセージ５２０が読まれる。
実施例においては、メッセージ内のタグを用いて、適切
なマウント・ヘッダのデータ構造体５２１の位置を特定
する。プラン９において所与のファイル・チャネル４１
９に対する構造体の位置を特定する役の関数は、その役
を果たすべく、所与のファイル・チャネル４１９へのポ
インタ５０５が入っているエントリ５０３を発見するま
でマウント・サービスの配列５０２を逐一あたってい
く。ファイル・チャネルは、その装置フィールド３１５
に対応するエントリ５０３に対する識別子を入れている
という事実によって識別することが可能である。
【００７１】以上のように、図３から図５に示したデー
タ構造により、ファイルに対するファイル記述子を有す
るプロセス１０２は、そのファイルに対して読出しおよ
び書込みなどのファイル・アクセス関数を実行すること
ができる。しかし、これだけでは、ファイル・ロケータ
関数を実行するには不十分である。なぜなら、これらの
関数には、ファイル記述子だけでなくパス名も関係する
からである。
【００７２】名前空間１１５の表現：図６、８および９
前記のように、新しいプロセス１０２の名前空間１１５
は、そのプロセス１０２の親から継承されるか、親の名
前空間を継承しないプロセス１０２に対しプラン９が利
用できるようにした「控え」の名前空間から作られるか
のいずれかである。プロセス１０２の名前空間１１５が
「控え」の名前空間からいかにして作られるかを図６に
概念的に示した。図６の「控え」の名前空間６０１は、
単一レベルのファイルを有するルート・ディレクトリ６
０３を与えるカーネル・サービスであるルート・サービ
スによって、与えられる。ルート・ディレクトリ６０３
およびファイル６０５および６１５は、他のサービス１
２３に属するファイル木構造１２５のルートが結合され
る可能性のある場所として作用するだけである。実施例
では、ファイル６０５〜６１５の集合は、サービスの種
類を機能によって分けるのに役立つ。ファイル名は、機
能に次のように対応する。dev６０５：サービスが結合
される主な場所である。Ｉ／Ｏ関数を与えるサービスお
よびその他の種々雑多な機能を有するサービスは、すべ
てdev６０５に結合される。boot６０７：プラン９が実
施されているＣＰＵをブートするサービスが結合される
場所である。ｆｄ６０９：プロセスの接続されたファイ
ルに対する複製のファイル記述子を与えるサービスが結
合される場所である。proc６１０：プラン９のプロセス
に付いての情報を与えるサービスが結合される場所であ
る。env６１１：プロセス１０２に対する環境ファイル
を与えるサービスが結合される場所である。環境ファイ
ルは、ＵＮＩＸの環境変数と同じ機能を果たす。bin６
１３：プロセス１０２によって実行されるプログラムの
ファイルを収容するサービスが結合される場所である。
そして、srv６１５：プロセス１０２が利用できるプロ
トコル・ザーバ２０９に対するプロトコル・チャネル５
１７を表すファイルを与えるサービスが結合される場所
である。
【００７３】プラン９には、控えの木構造６０１におけ
るファイル名に結合できる組み込みサービスの集合があ
る。これらのサービスには、プロセス１０２によって実
行されるプラン９のカーネル関数によってのみ結合でき
るものと、プロセス１０２によって実行される任意の関
数によって結合できるものとがある。プラン９のパス名
において、組み込みサービスの名前には、その前に文字
「＃」が付く。カーネル関数によってのみ結合され得る
組み込みサービスは、次のとおりである。すなわち、＃
／：控えの木構造６０１を与えるカーネル・ルート・サ
ービス、＃：プロセス間通信のためにＵＮＩＸ風のパイ
プを与えるカーネル・パイプ・サービス、および＃Ｍ：
プロトコル・サービス２０９に関するトランザクション
を処理するマウント・サービス６０３である。尚、カー
ネルは、ルート・サービスをプロセス１０２の名前空間
のルートに結合する。
【００７４】プロセス１０２によって実行される任意の
関数によって結合できる組み込みサービスには、次のも
のがある。＃ｂ：ブート・サービス。このサービスは、
ファイルを幾つか有し、このファイルに書き込まれる
と、このファイルによってカーネルは所与のアドレスに
分岐させられ、またこのファイルにより、カーネルは仮
想メモリの所与の位置に書き込むことができる。ブート
・サービスは、概してboot６０７に結合される。＃ｂ：
ビット・サービス。このサービスは、ビット・マップ・
スクリーンおよびマウスを表すファイルを有する。ビッ
ト・サービスは、概してdev６０５に結合される。＃
ｃ：コンソール・サービス。このサービスは、システム
・コンソールを表すファイルを有し、概してdev６０５
に結合される。＃ｄ：複製サービス。このサービスによ
って与えられるファイルは、プロセス１０２に属する接
続されたファイルに対するファイル記述子であるような
名前を有する。複製サービスは、概してfd６０９に結合
される。＃ｅ：環境サービス。このサービスによって与
えられるファイルは、概してenv６１１に結合される。
＃ｋｎａｍｅ：datakitサービス。このサービスによっ
て与えられるファイルは、ｎａｍｅによって表されるda
takitハードウェア上の会話を表す。このサービスは、
概してdev６０５に結合される。＃ｐ：プロセス・サー
ビス。これは、概してｐｒｏｃ６１０に結合される。＃
ｓ：サービス登録サービス。このサービスによって与え
られるファイルは、プロトコル・サービス２０９に接続
され既に開いているプロトコル・チャネル５１７を表
す。
【００７５】プラン９の実施例において、その名前空間
１１５を継承しなかったプロセス１０２がGnot７１１に
おいて走り始めると、Gnot７１１上で実行中のカーネル
が、bind処理を実行する。このbind処理によって、前記
の名前空間１１５には、木構造６１７として示した形式
が与えられる。木構造６０９における名前にサービスが
結合されていた場合、この事実は、「＝」の後にそのサ
ービス名を付けることによって示される。bind処理によ
って結合ディレクトリが生成された場合、この事実は、
「＝」に続く括弧内にその結合ディレクトリの構成要素
をリストとして載せることによって示される。このリス
トは、それらの構成要素が探査される順番になってい
る。木構造６１７は、bindおよびmountの処理からなる
次のような手順で生成されたものである。bind：ルート
・サービスによって与えられる木構造を、プロセス１０
２によって解釈されたパス名におけるルートを表す
「／」に結合する。「／」への参照は、ここでは「／」
６０３への参照として解釈される。mount（FD,"/",MAFT
ER,""）：マウント・サービス２０３に属するプロトコ
ル・チャネル５１７を「／」にマウントし、これによっ
て、ルート・サービスのルートおよびプロトコル・チャ
ネル５１７によって表されるプロトコル・サービス２０
９のルートからアクセス可能なファイルから成る結合デ
ィレクトリを生成する。プラン９においては、このプロ
トコル・サービス２０９によって、デフォルト・ファイ
ルサーバ７０５内にデフォルトのファイル木構造１２５
が与えられる。bind（"/68020/bin","/bin",MREPL）：
デフォルトのファイル木構造１２５におけるディレクト
リ/68020/binをルートとして持つような木構造を控えの
ファイル木構造６０１における名前bin６１３に結合す
る。ディレクトリ/68020/binには、Gnot７１１（実施例
では、モトローラ社の６８０２０プロセッサを有する）
のための実行可能なコードが入っている。bind（"/lib/
rc","/bin",MAFTER）：デフォルトの木構造１２５にお
ける/lib/rcをルートとして持つような木構造を名前bin
６１３に結合する。ディレクトリ/68020/binは既にbin
６１３に結合されているので、MAFTERが指定されてい
る。結果として、ディレクトリ/68020/binがディレクト
リ/lib/rcより先に探査されるような結合ディレクトリ
となる。bind（"#c","/dev",MREPL）：コンソール・サ
ービス＃ｃによって与えられる木構造を名前dev６０５
に結合する。最後に、bind（"#d","/fd",MREPL）：複製
サービス＃ｄによって与えられる木構造を控えの木構造
６０１における名前ｆｄに結合する。
【００７６】これらの結合の結果として、プロセッサ１
０２は、＃Ｍ１が接続される先のプロトコル・サービス
２０９のディレクトリ/68020/binにある「cc」というフ
ァイルをパス名「/bin/cc」によって参照することがで
き、また同じプロトコル・サービス２０９の/lib/rcに
ある「pwd」というファイルをパス名「/bin/pwd」によ
って参照することができる。勿論、これは、ディレクト
リ/68020/binにファイル「pwd」が無い場合である。同
様に、サービス＃ｃによって与えられるファイル「pi
d」ならば、パス名「/dev/pid」によって参照すること
ができ、またサービス＃ｄによって与えられるファイル
「０」であれば、パス名「/fd/0」によって参照するこ
とができる。
【００７７】従って、プラン９のプロセスに対する名前
空間には、名前空間１１５における名前に対して実行さ
れたbind処理およびmount処理のすべての記録が入って
いなければならない。ここでは、この記録をマウント・
テーブルと称する。本実施例のマウント・テーブルは、
ファイルに対するファイル・チャネル４１９が、そのフ
ァイルに対するパス名を明示的に表すという事実を利用
している。従って、bindおよびmountの処理記録は、bin
d処理またはmount処理で使用された古いパス名によって
表されるファイルを表すファイル・チャネル４１９と、
bind処理で使用された新たなパス名によって指定される
ファイルを表すファイル・チャネル４１９またはmount
で処理で使用されたファイル記述子に対応するファイル
・チャネル４１９との間に関係を確立することによっ
て、作ることも可能である。勿論、これらのファイル・
チャネル４１９は、すべて、現在のプロセス・グループ
１０３がその名前空間を受け継いだ元のプロセス・グル
ープ１０３の中のいくつかのプロセス１０２に接続され
ているか、または現在のプロセス・グループ１０３の中
のいくつかのプロセス１０２によって接続されているよ
うなファイルを表す。
【００７８】図８において、マウント・テーブルの構成
要素は、マウント・テーブル配列８０２から位置が特定
され、配列８０２は、ユーザ・データ構造体４０３から
位置が特定される。図８に示したように、ユーザ構造体
４０３は、プロセス（ＰＲＯＣ）のデータ構造体８２５
へのポインタ８２４を含む。各プロセス１０２は、ユー
ザ構造体４０３およびプロセス・データ構造体８２５を
持つ。ポインタ８２４は、そのプロセス１０２のプロセ
ス・データ構造体へのユーザ構造体４０３のポインタで
ある。プロセス・データ構造体８２５は、さらにマウン
ト・サービス・キューの構造体５０９におけるポインタ
５１１によっても示され、かつそれ自体に、プロセス・
グループ（ＰＲＧＲＰ）の構造体８２７へのポインタを
含んでいる。構造体８２７は、プロセス１０２が属する
プロセス・グループ１０３を表す。最終的に、プロセス
・グループ構造体８２７に、マウント・テーブル配列８
０２へのポインタ８２９が含まれることによって、ユー
ザの構造体４０３が属するプロセス１０２に対するマウ
ント・テーブル８０１の位置づけが可能となる。
【００７９】マウント・テーブル配列８０２は、新たな
パス名またはファイル記述子が結合される古いパス名の
それぞれに対する要素（ＭＴＥ）からなる。所与のマウ
ント・テーブル配列のエントリ８０３は、２つのポイン
タからなる。ポインタ８０５は、古いパス名によって指
定されるファイルを表すファイル・チャネル・データ構
造体４１９へのポインタである。マウント・テーブル８
０１との関係から、このようなデータ構造体４１９を左
手チャネル（ＬＣＨＡＮ）と称する。ポインタ８０７
は、マウント構造体８０９へのポインタである。各マウ
ント構造体８０９は、bindまたはmountの１回の処理結
果を表す。マウント構造体８０９の内容には、次のもの
が含まれる。参照フィールド（ｒｅｆ）８１１：これ
は、マウント・テーブル配列のエントリ８０３によって
示されるもの以外の左手チャネルが、マウント構造体を
使用しているかどうかを示す。終端フィールド８１３：
これは、マウント構造体８０９が、結合ディレクトリを
定義するマウント構造体８０９のリストの最後であるか
どうかを示す。マウント識別子フィールド８１５：これ
は、このマウント構造体８０９に対する固有の識別子で
あり、従って、マウント構造体８０９によって表される
bindまたはmountの処理の結果に対する識別子でもあ
る。ポインタ８１７：マウント構造体８０９が、結合デ
ィレクトリを定義しているマウント構造体８０９のリス
トの一部であり、かつそのリストの最後のマウント構造
体８０９でない場合、ポインタ８１７は、そのリストの
次のマウント構造体を示す。ポインタ８１９：このポイ
ンタは、新たなパス名によって（または、mountの場合
には、ファイル記述子によって）指定されるファイルを
表すファイル・チャネル４１９を示す。マウント・テー
ブルの関係から、このようなファイル・チャネルを右手
チャネル（ＲＣＨＡＮ）８０４と称する。
【００８０】以上から分かるように、各マウント・テー
ブル・エントリ８０３によって、左手チャネル８０２と
１つ以上の右手チャネル８０４との間の関係が確立され
る。さらに、mountまたはbind処理のためにそのパス名
の意味が変更されたファイルを表すファイル・チャネル
４１９においては、マウント・ポインタ（mountptr）フ
ィールド３２７が、そのmountまたはbind処理を表すマ
ウント構造体８０９を示し、さらにマウント識別子（mo
untid）フィールド３２９には、そのマウント構造体８
０９のマウント識別子８１５が入る。さらに、プロトコ
ル・サーバ２０９によって与えられるファイルを表すフ
ァイル・チャネル４１９は、そのファイルを与えるプロ
トコル・サービス２０９への接続に対するプロトコル・
チャネル５１７へのポインタをフィールド３３７に含
む。
【００８１】また、図８において、「mount」および「b
ind」処理のreplace、before、およびafterの各オプシ
ョンが、マウント・テーブル８０１によりいかにして実
施され得るかを説明する。replaceオプションが付いた
場合、新たなパス名を表す右手チャネル８０４を示すマ
ウント構造体８０９は、単にマウント構造体８０９のリ
ストの代わりをする。beforeオプションは、そのマウン
ト構造体８０９をマウント構造体８０９のリストの先頭
に追加するが、マウント構造体８０９のリストがない場
合には、エラーを発生する。afterオプションを付ける
と、そのマウント構造体８０９が、前記リストの最後に
追加される。この時も、そのリストがない場合には、エ
ラーとなる。結合ディレクトリが探査される場合、前記
リストの最初のマウント構造体８０９によって示される
右手チャネル８０４によって表されるディレクトリから
探査される。次に探査されるべきディレクトリは、その
リストの２番目のマウント構造体８０９によって示され
る右手チャネル８０４によって表されるディレクトリと
いうふうに、探査される。従って、左手チャネル８０２
（ａ）が、パス名／Ｍを表し、かつ右手チャネル８０４
（ａ）が、／Ｍに結合されたサービス１２３から１番目
のルート・ディレクトリを表し、かつ右手チャネル８０
４（ｂ）が、／Ｍに結合されたサービス１２３から２番
目のルート・ディレクトリを表すならば、「chdir（"/M
/."）」のようなファイル・ロケータ関数は、「Ｏ」を
求めて、最初は１番目のディレクトリを探査し、それが
そこで発見できない場合は、２番目のディレクトリを探
査する。
【００８２】前述のように、プロセス１０２が、システ
ム・コール「forkpgrp」を実行すると、必ず、プロセス
１０２に対する新たな名前空間１１５が生成される。
「forkpgrp」は、引数を１つだけ取る。この引数が、０
以外の値を持つときは、forkgrpを実行しているプロセ
ス１０２に対する既存の名前空間１１５は、新たな名前
空間１１５にコピーしてはならない。この引数が値０を
有する場合、その既存の名前空間は、コピーされるべき
ものである。「forkgrp」に「０」でない引数を付けて
実行すると、forkgrpは、単に、プロセス１０２に対す
る新たなプロセス・グループ構造体８２７および新たな
マウント・テーブル配列８０２を作るだけである。そし
て、新たな名前空間１１５を定義するbindおよびmount
処理に必要とされるようなマウント・テーブル・エント
リ８０３が、生成される。引数「０」を付けてforkpgrp
が実行されると、その「forkpgrp」システム・コールを
実行中のプロセス１０２に対するマウント・テーブル配
列８０２におけるマウント・テーブル配列のエントリ８
０３が、新たなマウント・テーブル配列８０２へとコピ
ーされる。これが行われると、所与のマウント・テーブ
ル・エントリ８０３によって示される各左手チャネル８
０２におけるｒｅｆフィールド３０７およびそのエント
リによって示される各マウント構造体８０９におけるｒ
ｅｆフィールド８１１がインクリメントされる。以上か
ら明らかなように、本実施例においてはマウント・テー
ブル８０１を実施しているので、プロセスに対し新たな
名前空間１０５を生成することは、比較的効率的かつ安
価な作業である。
【００８３】図９において、チャネル構造体３０１を長
い長方形で表した。チャネル構造体３０１のラベルは、
そのチャネル構造体３０１によって表されるファイルの
パス名を示す。第１のマウント・テーブル配列エントリ
８０３（ｂ）により、ルート「／」上のbindおよびmoun
t操作の結果が記録される。ルート「／」を表すＬＣＨ
ＡＮ８０２（ｂ）が、エントリ８０３（ｂ）および２つ
のマウント構造体８０９（ｃ）および（ｄ）を介して２
つの右手チャネルに接続されている。これらの右手チャ
ネルのうち、８０４（ｃ）は、カーネル・ルート・サー
ビスによって与えられるファイル木構造のルートに対す
るもので、８０４（ｄ）は、＃Ｍ１が接続されている先
のプロトコル・サービス２０９によって与えられるファ
イル木構造のルートに対するものである。右手チャネル
８０４（ｄ）におけるmchanポインタ３３７は、ルート
への接続を表すプロトコル・チャネル５１７を示す。
【００８４】第２のマウント・テーブル配列エントリ８
０３（ｃ）によって、左手チャネル８０２（ｃ）によっ
て表される、#/bin上のbind操作の結果が記録される。
チャネル８０２（ｃ）は、２つの右手チャネル---#M1/6
8020/binを表す８０４（ｅ）および#M1/lib/rcを表す８
０４（ｆ）---に接続されている。右手チャネル８０４
（ｄ）および（ｅ）によって表されるファイルは、＃Ｍ
１の接続先のプロトコル・サービス２０９によって与え
られるので、前記の右手チャネルは、共に、サービス２
０９への接続を与えるプロトコル・チャネル５１７への
mchanポインタ３３７を含む。さらに、左手チャネル８
０２（ｃ）によって表されるファイルのパス名#/binに
は、パス名#/が含まれる。そのディレクトリ・ファイル
は、右手チャネル８０４（ｃ）によって表される。従っ
て、左手チャネル８０２（ｃ）のマウント・ポインタ
（mountptr）フィールド３２７には、右手チャネル８０
４（ｃ）を示すマウント構造体８０９（ｃ）へのポイン
タが入る。
【００８５】マウント・テーブル９０１の残りの部分か
ら分かるように、右手チャネル８０４によって表される
構成要素を含むパス名を表すマウント・テーブル９０１
における１つ１つのファイル・チャネル４１９に、その
構成要素を表す右手チャネル８０４を示すマウント構造
体８０９へのmountptrフィールド３２７におけるポイン
タが、含まれる。従って、#/を含むパス名を有するファ
イルをいずれも表すような左手チャネル８０２（ｃ）、
８０２（ｄ）および８０２（ｅ）は、すべてマウント構
造体８０９（ｃ）を示す。一方、#M1を含むパス名を有
するファイルを双方とも表すような右手チャネル８０４
（ｅ）および８０４（ｆ）は、すべてマウント構造体８
０９（ｄ）を示す。勿論、mountptrフィールド３２７
が、マウント構造体８０９を示すときは、チャネル３０
１におけるmountidフィールド３２９が、そのマウント
構造体８０９に対するマウント識別子に設定される。
【００８６】残りのエントリ８０３（ｄ）および８０３
（ｅ）によって、カーネル・ルート・サービス#/によっ
て与えられる「控え」のディレクトリ「dev」および「f
d」への組み込みカーネル・サービスの結合が、記録さ
れる。この場合、各エントリ８０３によって、控えのデ
ィレクトリを表す左手チャネル８０２は、組み込みカー
ネル・サービスを表す右手チャネル８０４に関係付けら
れる。組み込みカーネル・サービスは、プロトコル・サ
ービスではないので、右手チャネルは、プロトコル・チ
ャネル５１７へのポインタは持っていない。
【００８７】名前空間１１５におけるパス名の分析：図
１０および１１前記のとおり、マウント・テーブル８０
１は、プラン９のファイル・チャネル４１９は、いずれ
も、そのファイル・チャネル４１９によって表されるフ
ァイルのパス名を明示的に表すという事実を利用してい
る。プラン９のオペレーティングシステムに、「bin
d」、「mount」、「chdir」および「open」などのファ
イル・ロケータ関数において、パス名が提示されると、
オペレーティングシステムは、そのパス名によって指定
されたファイルを表すファイル・チャネル４１９を得る
ことによって、そのパス名を分析して、そのファイル・
チャネル４１９へのポインタを返す。プロセス１０２の
ファイル木構造１１７は、サービス１２３によって与え
られるファイル木構造で構成されるので、パス名の分析
には、マウント・テーブル８０１および各サービス１２
３が応答するサービス要求が、共に関与する。これらの
特別なサービス要求は、walkサービス・ファイル・ロケ
ータ要求であり、場合によっては、attachサービス・フ
ァイル・ロケータ要求である。
【００８８】パス名を分析するプラン９のカーネル関数
を（チャネルへの名前として）「namec」と称する。こ
の関数の流れ図を図１０に示す。コールの端子１００３
に示したように、namecが引数として取るものは、パス
名、namecを用いるシステム・コールが必要とするファ
イル・アクセスの種類のコード、およびnamecによって
開かれるファイルがいかにして開かれるべきかを示すコ
ードである。namecは、チャネルへのポインタを返す。n
amecは、パス名の最初の文字は特に処理するが、そのほ
かは、パス名を、文字「／」によって区切られた名前の
リストとして、扱う。名前の各々を要素と称する。
【００８９】namecの最初の部分（１０６７）では、パ
ス名が始まる点を表すチャネル３０１を得る。そのチャ
ネルを得る要領は、そのパス名の始まり方による。始ま
り方には３つの可能性がある。パス名が、完全なパス名
の場合、そのパス名は、「／」で始まる。パス名が、組
み込みカーネル・サービスによって与えられるファイル
を示し、かつそのサービスが、もう１つのファイル名に
まだ結合されていない場合、「＃」で始まる。パス名が
ワーキング・ディレクトリで始まる場合、ファイル名で
始まる。
【００９０】パス名が、「／」で始まる場合、判断ブロ
ック１００５の分岐ｙが取られ、ルートに対するファイ
ル・チャネル４１９の内容が、チャネル３０１「ncha
n」にコピーされる（１００９）。前記のように、ルー
トのファイル・チャネル４１９は、そのプロセスに対す
るユーザ・データ構造体４０３から位置を特定すること
ができる。
【００９１】パス名が他のもので始まる場合、ブロック
１００５の分岐ｎが取られ、ブロック１００７におい
て、最初の要素を検査して、それが「＃」かどうかを判
断する。「＃」ならば、「＃」に続く文字によって指定
されるカーネル組み込みサービスによって、attachサー
ビス・ファイル・ロケータ要求が実行される。attachロ
ケータ要求の結果は、組み込みサービスによって与えら
れるファイル木構造１２５のルートを表すチャネル３０
１である。所与のサービスがattach要求を処理する要領
は、そのサービスによる。例えば、ルート・サービスに
対するattach関数は、包括的なattach関数であるdevatt
achを呼び出す。devattachは、引数として組み込みサー
ビスの名前、この場合は「／」、を取る。devattach
は、新たなチャネル・データ構造体３０１を獲得し、qi
dフィールド３２３をルートを指定する値に設定し、さ
らに型フィールド３１５を引数「／」から得た値に設定
する。最初の要素が、「／」でも「＃」でもない場合、
そのパス名はワーキング・ディレクトリで始まる。そこ
で、ブロック１０１３において、ワーキング・ディレク
トリを表すファイル・チャネル４１９をnchanにコピー
する。このファイル・チャネルは、プロセスに対するユ
ーザ・データ構造体４０３から位置を特定することがで
きる。
【００９２】１０６９で示した次の段階では、nchanに
よって表されるファイルに対するパス名が、bindまたは
mountの関数コールにおいて古いパス名として使用され
たかどうかを調べる。まず、パス名の最初の要素を得
る。これを行う関数により、構造体４０３におけるフィ
ールドＥＬＥＭ４０５を次の要素であるファイル名に設
定する。その上で、プロセス１０２に対するユーザ・デ
ータ構造体４０３からプロセス・グループ１０３に対す
るマウント・テーブル配列８０２の位置を特定する。各
マウント・テーブル・エントリ８０３に対する左手チャ
ネル８０２を次々にnchanと比較してゆき、nchanに「等
しい」ものが見つかるまで続ける。ここで言う「等し
い」とは、２つのチャネル３０１が同じサービス１２３
における同じファイルを表す、すなわち、それらが、そ
れらの型フィールド３１３、devフィールド３１５、お
よびqidフィールド３２３に等しい値を有するというこ
とである。
【００９３】該当する左手チャネル８０２が見つからな
い場合、判断ブロック１０１９の分岐ｎが取られ、見つ
かった場合、分岐ｙが取られて、nchanに等しい左手チ
ャネル８０２を有するエントリ８０３によって示される
右手チャネル８０４の内容をnchanにコピーする（１０
２１）。その上で、nchanにおけるmountptrフィールド
３２７を、それが右手チャネル８０４を示すマウント構
造体８０９を示すように、設定し、さらにmountidフィ
ールド３２９をマウント構造体８０９のmountidの値に
設定する。従って、パス名がbindまたはmountのコール
において古いパス名として使用された場合、nchanは、
この時点で、右手チャネル８０４によって表されるファ
イルを表す。それ以外の場合は、nchanは不変である。
【００９４】図１０の１０Ｂにおいて、namecの一部１
０７１は、パス名の残りの各要素を調べるループ１０２
５からなる。このループを通過する度に、「walk」カー
ネル関数へのコールが行われる。このコールにおいて使
用される引数は、nchan、現在の要素（ブロック１０２
９）、および現在の名前がそのファイルを表す左手チャ
ネル８０２を持つことができるか（これは、カーネル組
み込みサービス名の場合に限って不可能である）どうか
を示すフラグである。さらに詳細に後述するが、walk関
数は、要素によって指定されたファイルを表すチャネル
３０１を返す。ブロック１０３１において、そのチャネ
ル（図１０ではtchanで示す）をnchanに割り当てる。そ
して、次の要素をパス名から得る（ブロック１０３
３）。前のように、ＵＳＥＲ構造体４０３にあるＥＬＥ
Ｍフィールド４０５を次の要素に設定する。ループが終
了すると、パス名の最後の要素が処理されるべく残る。
【００９５】最後の要素を処理する要領は、いずれのシ
ステム・コールがnamecを呼び出したかによる。それがc
reateシステム・コールの場合、最後の要素は、新たな
ファイルの名前を表し、それ以外の場合は、アクセスす
るべきファイルを表す。いずれのシステム・コールがna
mecを呼び出したかは、アクセス・モード引数によって
示され、判断ブロック１０５５に示したように、以降の
処理は、その引数に依存する。尚、ブロック１０５７に
示すように、アクセス・モード引数により、ファイルの
生成が指示されている場合、最後の要素およびtchanを
用いてcreateサービス・ファイル要求を行う。ただし、
この時、tchanは、新たなファイルが生成されるべきデ
ィレクトリに対するファイル・チャネル４１９のコピー
である。結果的に、tchanは、その型フィールド３１３
およびdevフィールド３１５に、ディレクトリおよびqid
フィールド３２３におけるそのディレクトリに対するqi
dを含むサービス１２３を指定する値を収容する。creat
eサービス・ファイル要求の結果として、新たなファイ
ルがｍ生成され、その名前として最後の要素が割り当て
られ、さらに、tchanのqidフィールドが、新たなファイ
ルのqidに設定される。
【００９６】namecを呼び出したシステム・コールがcre
ate以外である場合、最後の要素は、既に存在するファ
イルの名前である。この場合も、最後の要素を用いてwa
lk関数を呼び出し、tchanを得る。このtchanは、最後の
要素によって参照される（１０５９）ファイルを表す。
その上で、tchanのフィールドをnamecのアクセス・モー
ドおよびオープン・モードの引数により要求されるとお
りに設定し（１０６１）、さらにtchanをnchanにコピー
する（１０６３）。戻り端子１０６５に示したように、
パス名引数において指定されたファイルを表すチャネル
３０１としてnchanが返される。
【００９７】図１１の開始端子１１０３において、walk
は、チャネル・データ構造体３０１、パス名の一要素、
およびその要素へのマウントが有効かどうかを示すフラ
グを取る。チャネル・データ構造体３０１は、その要素
の名前を有するファイルを求めて探査するべきディレク
トリを表す。そのディレクトリか、またはそのチャネル
・データ構造体によって表されるディレクトリと結合し
たディレクトリにおいて、その要素の名前が発見された
場合、この関数は、そのパス名の要素によって指定され
るファイルを表すチャネル・データ構造体３０１を返
す。
【００９８】そのアルゴリズムは、およそ次のとおりで
ある。まず、引数として使用されるチャネル３０１の型
フィールド３１３および装置フィールド３１５によって
指定されるサービスに対し、walkファイル・サービス要
求を行う。このwalkファイル・サービス要求には、引数
として使用される要素が含まれる。このファイル・サー
ビス要求は、成功した場合、その要素によって指定され
るファイルに対するチャネル３０１を返す。その上で、
マウント・テーブル３０８の検査によって、walk要求に
よって返されたチャネル３０１が、左手チャネル８０２
かどうかを判断し、そうでない場合、walk要求によって
返されたチャネルは、walk関数によって返される。そで
ある場合、その左手チャネル８０２に対応する右手チャ
ネル８０４をwalk関数によって返されることになってい
るチャネル３０１にコピーし、さらにチャネル３０１の
mountptrフィールドおよびmountidフィールドを、左手
チャネル８０２を示すマウント・テーブル配列エントリ
８０３によって示されるマウント・データ構造体８０９
の要求に合わせて設定する。
【００９９】ファイル・サービスが、要素によって指定
される名前を有するファイルをチャネルによって指定さ
れたディレクトリにおいて発見できない場合、walkファ
イル・サービス要求は、成功しない。このようなことが
起こる理由は２つある。すなわち、そのディレクトリに
別な名前が結合されているか、または要素に対応するフ
ァイルがそのディレクトリに存在しないかである。
【０１００】前記の第１の場合、別の名前が結合された
ときに、mountptr３２７およびmountid３２９により、
生成されたマウント構造体８０９を指定し、さらにその
マウント構造体８０９によって示される右手チャネル８
０４において指定されるサービスについて、walkサービ
ス・ファイル要求を再び試みる。そのwalkサービス・フ
ァイル要求が、成功した場合、処理を既に説明したよう
に続ける。失敗した場合、やはり、前記のいずれの可能
性もある。ここでは、要素に対応するファイルがそのデ
ィレクトリに存在しないという問題を仮定する。この場
合も２つの可能性がある。すなわち、ファイルが実際に
存在しないか、または探査されたディレクトリが結合デ
ィレクトリの一部であり、かつその結合ディレクトリの
一部である他のディレクトリが依然として探査されてい
ない可能性がある。ファイルが実際に存在しない場合に
は、実際に探査されたディレクトリに対するマウント構
造体８０９における終端フィールド８１３によって、マ
ウント構造体８０９がその結合ディレクトリを構成する
マウント構造体８０９のリストの最後のものであること
が示されるはずである。そうでなければ、マウント構造
体８０９におけるネクスト・フィールド８１７が、結合
ディレクトリにおける次のディレクトリに対するマウン
ト構造体８０９を示すことになり、その次のマウント構
造体から、探査するべき右手チャネル８０４を決定する
ことができる。この場合、次のマウント構造体によって
示される右手チャネル８０４を用いて、walkサービス・
ファイル・ロケータ要求を繰り返す。
【０１０１】詳細には、ブロック１１０５において、最
初は、これがサービス・ファイル・ロケータ要求を行う
１回目であることを示すフラグを設定し、引数として与
えられたチャネルをcchanにコピーする。ブロック１１
０７において、cchanおよび要素を用いてwalkサービス
・ファイル・ロケータ要求を行う。そのサービスがこの
要求に応じて実行する動作は、そのサービスに依存す
る。その２つの例を説明する。ルート・サービスでは、
walk要求に応じて、cchanがルート・サービスのルート
のために予約されているqidフィールド３２３に特別な
値を持っているかどうかを判断し、さらに、持っている
場合、要素がルート・サービスにより「控え」として与
えられる名前のうちの１つであるかどうかを判断する。
後者の場合、cchanのqidフィールド３２３を、前記の控
えの名前に対し予約された特別な値に設定する。前記以
外の場合、walkサービス・ファイル・ロケータ要求は失
敗する。
【０１０２】マウント・サービス２０３は、walk要求に
対し次のように応答する。前記のように、プロトコル・
サービス２０９によって与えられるファイルを表すチャ
ネル３０１のdevフィールド３１５の一部に、マウント
・サービス配列エントリ５０３を指定する識別子が含ま
れる。その識別子を用いて、マウント・サービス２０３
は、プロトコル・サービス２０９に対するプロトコル・
チャネル５１７に対するマウント・サービスの待ち行列
５０９の位置を特定し、walkサービス・ファイル・ロケ
ータ要求に必要なtmessageに対するマウント・ヘッダ５
２１を割り当て、さらにチャネルから得たファイル識別
子および要素をtmessageに配置する。プロトコル・サー
ビス２０９が、チャネルからのファイル識別子によって
指定されたディレクトリにおける要素によって指定され
る名前の付いたファイルを有する場合、プロトコル・サ
ービス２０９は、ファイルに対するqidが入ったrmassag
eを返し、そのqidは、cchanのqidフィールド３２３に置
かれる。
【０１０３】walk要求が成功した場合、チャネル３０１
がmountまたはbind操作の結果ではないことを示すよう
に、cchanのフラグ３２１が設定される（１１１９）。
次に、walk要求が２回以上行われたかどうかを判断する
（１１２１）。２回以上行われた場合、引数として受け
取ったチャネルは、返されたものではないことになり、
その引数として受け取ったチャネルは、閉じられる（１
１２３）。このクローズ操作によって、そのチャネルの
refフールドにある計数が、デクリメントされるが、こ
の時、そのrefフィールドが値０を有する場合、clunkサ
ービス要求がそのチャネルのdevフィールド３１５によ
って示されるサービスに送られ、さらにチャネル構造体
３０１がフリー・リストに返される。walk要求が行われ
たのが、これでまだ一回目である場合、このステップは
省略される。次に、判断ブロック１１３３において、cc
hanが、他の構成要素が結合されている可能性のあるパ
ス名の構成要素を表すかどうかを判断する。この状態
は、「＃」以外の構成要素に対して成立し、かつwalkの
「mountok」引数によって示される。マウントされた構
成要素があり得ない場合、マウント・テーブル８０１を
調べる必要はなく、cchanはそのまま返される（１１３
５）。そうでない場合、cchanに等しい左手チャネル８
０２を求めて、マウント・テーブル８０１を調べ、該当
する左手チャネル８０２を発見した場合、左手チャネル
８０２に対応する右手チャネル８０４の値を、右手チャ
ネル８０４を示すマウント構造体８０９に対するマウン
ト・ポインタおよびマウント識別子と共に、cchanにコ
ピーする。cchanをこのように変更して返す（ブロック
１１３７〜１１４３）。
【０１０４】walkサービス要求ブロック１１０７に戻
り、その要求が失敗した場合、まず、cchanが、mountま
たはbind要求の結果であるかどうかを判断する。そうで
あるならば、探査に失敗したのであり、結合子「Ｂ」の
ように、walk関数は、失敗を示す０を返す（端子１１４
９）。ブロック１１４５および１１４７において、walk
要求が２回以上行われた場合、cchanをクローズする。
次に、cchanのマウント・ポインタ・フィールド３２７
を用いて、マウント構造体８０９の位置を特定する（ブ
ロック１１１）。マウント構造体８０９の終端フィール
ド８１３により、そのマウント構造体８０９が、結合デ
ィレクトリを定義するマウント構造体８０９のリストの
最後にあることが示されている場合、その探査は失敗し
たのであり、walkは、結合子Ｂにおいて終了する。そう
でない場合、現在のマウント構造体８０９のネクスト・
ポインタ８１７の方が先であるから、次のマウント構造
体８０９によって示される右手チャネル８０４を一時的
なチャネルtchanにコピーする（ブロック１１１５）。
次に、tchanにおけるmountptrフィールド３２７を、次
のマウント構造体８０９を示すように設定し（ブロック
１１２５）、tchanをcchanにコピーし（１１２７）、fi
rstを０に設定し、さらに、結合子「Ｄ」によって示し
たように、ブロック１１０７において、walkサービス要
求を繰り返す。結合子Ｄによって定義されるループ１１
３１は、ブロック１１０７におけるwalk要求が成功する
か、または要素に対応するファイルが発見されなかった
ことが明かとなるまで、繰り返される。
【０１０５】ファイル・ロケータ操作の実施 プラン９における名前の分析が分かったので、「ope
n」、「bind」および「mount」などのファイル・ロケー
タ・システム・コールの実施は容易である。まず、open
システム・コールは、パス名、動作モードを指定する整
数を引数として取り、オープンされたファイルのファイ
ル記述子４１７を返す。このシステム・コールは、最初
に、現在はチャネル３０１を示していないファイル記述
子配列４１３の要素４１５の位置を確認する。その要素
の番号が、新たに開かれたファイルに対するファイル記
述子である。次に、システム・コールは、namecを呼び
出す。この時の引数は、パス名、オープンを指定するア
クセス・モード指定子、およびオープンを行うモードで
ある。前記のように、namecは、パス名を分析し、パス
名によって示されたサービスがパス名によって指定され
たファイルにある処理を行うことを指定し、かつその時
点でチャネル３０１が当該ファイルを表すファイル・チ
ャネル４１９であるように設定されたフィールドを備え
たチャネル３０１を返す。openシステム・コールは、そ
のファイル・チャネル４１９へのポインタをファイル記
述子配列の要素４１５に置いて、そのファイル記述子を
返す。
【０１０６】好ましい実施例における「bind」システム
・コールは、引数として、新たなパス名へのポインタ、
古いパス名へのポインタ、およびそのbindがreplace、b
eforeまたはafterのオプションを付けて行われているか
どうかを示すフラグを取る。このシステム・コールは、
このbindが、成功した場合は「１」の値を、失敗した場
合は「０」の値を有する整数を返す。このシステム・コ
ールは、bindとmountの両方を行う「bindmount」と称す
るカーネル関数を呼び出す。「bind」または「mount」
システム・コールによって与えられるフラグによって、
いずれを行うべきかが示される。「bind」システム・コ
ールが示されると、bindmountは、第１のパス名を付け
てnamecを呼び出して、第１のパス名によって指定され
たファイルを表す第１のチャネル３０１を得る。次に、
第２のパス名を付けてnamecを呼び出して、第２のパス
名によって指定されたファイルを表す第２のチャネル３
０１を得る。次の段階で、カーネル・マウント関数を呼
び出す。この関数は、bind操作の必要に応じてマウント
・テーブル８０１を配置し直す。
【０１０７】図１２において長方形１２０３で示したよ
うに、カーネル・マウント関数は、引数として、古いチ
ャネル、新たなチャネル、およびフラグを取り、bindま
たはmountの結果得られたマウント構造体８０９のマウ
ント識別子を返す。フラグは、bindまたはmountのシス
テム・コールのオプション・フラグから設定される。現
在の場合、古いチャネルに対する実際の引数は、第１の
チャネル３０１であり、新たなチャネルに対する実際の
引数は、第２のチャネル３０１である。
【０１０８】このアルゴリズムの最初のステップは、引
数として受け取ったチャネル３０１についてbindまたは
mountの処理を実行することができるかどうか判断する
ことである（１２０５）。両方のチャネルが、同じファ
イルを指定している（すなわち、同じqid３２３を持
つ）場合、または古いチャネルが、ディレクトリでない
ファイルを表し、かつフラグによってreplace以外のオ
プションが指定されている場合、処理は許されない。処
理が許されない場合、１２０７において、エラーとな
る。次に、既に説明したように、マウント・テーブル８
０１を探査して、古いチャネルが既にマウント・テーブ
ル８０１にある左手チャネル８０２に等しいかどうかを
判断する。等しい場合、新たなマウント・テーブル・エ
ントリ８０３は全く必要ないので、ブロック１２１１は
省略することができる。等しくない場合には、ブロック
１２１１において、空のマウント・テーブル・エントリ
８０３を入手して、そのエントリ８０３のポインタ８０
５を古いチャネルを示すように設定する。
【０１０９】次に、新たなチャネル３０１のフラグ・フ
ィールド３２１を、そのチャネルが右手チャネル８０４
であることを示すCMOUNTを示すように設定する（１２１
３）。また、フラグ・フィールド３２１により、CREATE
オプションを示すこともできる。このオプションは、右
手チャネル８０４によって表されるディレクトリにファ
イルを生成しても良いことを指定する。このオプション
が指定されると、新たなチャネル３０１のフラグ・フィ
ールド３２１が、CMOUNTオプションだけでなくCREATEオ
プションも示すように設定される（１２１５、１２１
７）。ここで、マウント関数は、新たなマウント構造体
８０９を入手して、古いチャネルに対応する左手チャネ
ル８０２に対するマウント・テーブル・エントリを新た
なチャネル３０１から作られている右手チャネル８０４
に連結する。新たなマウント構造体におけるポインタ８
１９が、新たなチャネル３０１を示すように設定される
（１２１９）。
【０１１０】結合子「Ａ」に続いて、switch文１２２１
において、フラグ引数がreplace,before、またはafter
のオプションのいずれかを示すかどうかによって、３つ
の分岐の中の１つを指定する。before分岐１２２３の場
合、ブロック１２２１において、検査により、別のディ
レクトリが既に左手チャネル８０２に結合されているか
どうかを判断する。結合されていない場合、結合ディレ
クトリは不可能であり、beforeオプションはエラーであ
る（１２３１）。そのようなディレクトリが既に存在す
る場合、replaceオプション１２２５の場合にように処
理が継続する。replaceオプションにおいては、、古い
チャネル３０１と同等の左手チャネル８０２に対応する
マウント構造体８０９のリストの先頭に、新たなマウン
ト構造体８０９が置かれる（１２３３）。replaceオプ
ション１２２５が使用されている場合、新たなマウント
構造体８０９における終端フィールド８１３が、リスト
の最後を示すように設定される（１２３４）。afterオ
プション１２２７においては、最終的に、ステップ１２
３５において再び検査を行い、結合ディレクトリが可能
かどうかを判断し、そうでない場合、エラー１２３７と
なる。可能ならば、ブロック１２３９で示したように、
マウント構造体８０９のリストの末尾に新たなマウント
構造体８０９が置かれる。次に、mountは、新たなマウ
ント構造体８０９に属するマウント識別子を返す。bind
mountを続けると、この関数は、新旧のチャネル３０１
をクローズし、それらのうち、マウント・テーブルにも
追加されず、フリー・チャネルのリスト以外には使用さ
れないものを返す。
【０１１１】システム・マウント関数コールは、新たな
パス名引数がないという点で、システム結合関数コール
とは異なる。その代わり、新たなパス名引数は、オープ
ン・プロトコル・チャネル５１７を表すファイル記述子
４１７である引数によって置き換えられている。そのよ
うなファイル記述子４１７を得る方法は、さらに詳細に
後述する。さらに、システム・マウント関数コールは、
マウントされているプロトコル・サービス２０９へと渡
されるデータからなる引数を含む。そのフラグに応じ
て、bindmountは、最初にファイル記述子４１７および
ファイル記述子配列４１３を用いて、ファイル記述子引
数によって指定されたプロトコル・チャネル５１７の位
置を特定する。
【０１１２】次に、プロトコル・チャネル５１７を用い
てマウント・サービス・アタッチ処理を実行する。アタ
ッチ処理において最初に行うことは、使用されていない
マウント・サービス配列要素５０３の位置を特定するこ
とである。これが終わると、既に説明した包括的なdeva
ttach処理を実行する。ただし、これを呼び出すのに使
用する引数は、マウント・サービス２０３を指定する
「Ｍ」である。devattachは、その型フィールド３１３
がマウント・サービス２０３を指定するように設定され
たチャネル構造体３０１を返す。そのマウント・サービ
ス２０３に対するアタッチ関数は、そのチャネルのdev
フィールド３１５を使用されていないマウント・サービ
ス配列要素５０３に対する識別子の値に設定し、さらに
前記の使用されていない要素のポインタ５０５を、それ
がチャネル構造体を示すように、設定する。次に、プロ
トコル・チャネル引数を用いて、引数によって指定され
たプロトコル・チャネル５１７に対しマウント・サービ
ス・キュー構造体５０９によって表されるメッセージ・
キューが既に存在するかどうかを判断する。存在しない
場合、割り当てられている。ここで、devattachによっ
て返されたチャネル３０１に対する識別子およびプロト
コル・サービス２０９に渡されるはずであった引数が入
ったattach往信メッセージ（tmassage）が送られる。返
信メッセージが戻ったとき、それには、プロトコル・サ
ービス２０９におけるファイル木構造１２５のルートに
対するqidが入っている。このqidは、devattachによっ
て返されたチャネル３０１のqidフィールド３２３およ
びmqidフィールド３３９へとコピーされ、さらに、メッ
セージ・キューが属するプロトコル・チャネル５１７へ
のポインタが、pchanフィールド３３７にコピーされ
る。次に、マウント・サービス・アタッチ処理の結果得
られたチャネルは、新たなチャネル３０１引数としてマ
ウント関数に与えられる。bindmount関数についてmount
が指定されると、bindmountは、ファイル記述子配列４
１３のプロトコル・チャネル５１７をクローズし、さら
にファイル記述子配列４１３からそれを削除することに
よって、終了する。
【０１１３】オープン・プロトコル・チャネル５１７の
獲得：図１３ マウント・システム・コールの引数は、オープン・プロ
トコル・チャネルのファイル記述子４１７が含まれる。
プロトコル・チャネル５１７は、プロトコル・サービス
２０９への接続であるファイルを表すチャネル３０１で
ある。好ましい実施例において、接続は、ローカル・プ
ロトコル・サービス２１１がメッセージを送受信する手
段であるパイプにおけるファイル、または通信システム
を介した遠隔のプロトコル・サービス２１３との会話を
表すファイルのいずれも良い。実施例においては、パイ
プにおけるファイルに対するファイル記述子は、そのパ
イプを生成する「pipe」システム・コールによって与え
られる。通信システムを介する会話を表すファイルに対
するファイル記述子は、次のようにして獲得される。ま
ず、「dial」関数が呼び出される。この関数は、その会
話を表すファイルを含むディレクトリのパス名を返す。
次に、その会話を表すファイルのパス名が、「open」関
数で用いられ、そのopen関数は、その会話を表すファイ
ルに対するファイル記述子を返す。
【０１１４】プロトコル・チャネル５１７が表す接続の
対象であるプロトコル・サービス２０９をプロセッサ１
０２によってsrv６１５に登録することにより、プロト
コル・チャネル５１７を一般的な用途に使用できるよう
にすることができる。すべてのサービスについて言える
ことであるが、srv６１５は、それがファイルとして管
理する資源を提供する。従って、プロトコル・サービス
２０９をsrv６１５に登録するためには、そのプロトコ
ル・サービス２０９を表すファイルをsrvによって表さ
れるディレクトリに生成し、さらにその生成したファイ
ルへの接続を表すファイルに対するファイル記述子を書
けばよい。
【０１１５】勿論、システム生成関数を呼び出せば、sr
vへのファイル生成要求が発生することになり、srvは、
この生成要求に応じて、そのファイルに対するディレク
トリ・エントリを作り、ディレクトリ・エントリに対す
るqidを生成されたファイルに対するチャネル３０１の
フィールド３２３に置き、さらにディレクトリ・エント
リへのポインタを補助フィールド３３３に置く。同様
に、システム・ライト・処理の実行も、srvへのファイ
ル書込み要求を発生する結果となり、srvは、この書込
み要求に応じて、ファイル記述子によって指定されるプ
ロトコル・チャネル５１７へのポインタをプロトコル・
サービス２０９へのディレクトリ・エントリに置く。プ
ロトコル・サービス２０９を表すファイルの名前を用い
て、オープン・システム・コールを行うと、結果的に発
生するsrv６１５に対するオープン・ファイル要求によ
って、srv６１５は、プロトコル・サービス２０９に対
するプロトコル・チャネル５１７を返すことになる。そ
して、openにより、既に述べたファイル記述子４１７と
共にプロトコル・チャネル５１７が与えられ、マウント
・システム・コールにおいて、そのファイル記述子４１
７を使用することもできる。
【０１１６】図１３において、srv６１５によって維持
されているディレクトリは、ディレクトリ・エントリ１
３０３の木構造からなる。各ディレクトリ・エントリ１
３０３は、情報１３０５および多数のポインタからな
る。これらのポインタによって、ディレクトリ・エント
リ１３０３が１つの木構造へと組織される。この木構造
の各レベルに１つ以上のディレクトリ・エントリ１３０
３があり、所与のレベルのエントリ１３０３は、内側の
ノード、すなわち木構造の次に低いレベルの点、または
プロトコル・サービス２０９を表す葉ノードのいずれか
である。以下において、内側のノードを「親」と称す
る。所与の親を有するエントリ１３０３は、次ポインタ
１３１１および後ポインタ１３１３によって子リスト１
３１０へと接続される。さらに、所与の子リスト１３１
０の各エントリ１３０３は、その親エントリ１３０３へ
のポインタ１３０９を有する。親エントリ１３０３は、
さらに子リスト１３１０における最初のエントリ１３０
３へのポインタ１３０７も有する。葉ノードは、その葉
ノードによって表されるプロトコル・サービス２０９へ
の接続を表すプロトコル・チャネル５１７へのポインタ
１３１４を持つことがある。さらに、エントリ１３０３
が、チャネル３０１によって表される場合、そのチャネ
ル３０１の補助フィールド３３３には、そのチャネルに
よって表されるエントリ１３０３へのポインタ１３０２
が収容される。
【０１１７】ディレクトリ情報１３０５は、次のフィー
ルドからなる。名前１３１５：プロトコル・サービス２
０９が登録されている場合、それを特定するために使用
される名前である。qid１３１７：そのディレクトリを
表すチャネル３０１におけるディレクトリ・エントリ１
３０３を表すqidである。type１３１９およびdev１３２
１：これらによりsrv６１５を指定する。モード１３２
３：エントリ１３０３によって表されるディレクトリが
開かれている場合、そのオープン・モードを示すように
設定される。atime１３２５：いつエントリ１３０３が
割り当てられたかを示す。mtime１３２７：いつエント
リ１３０３の親が割り当てられたか、またはエントリ１
３０３が親ならば、最後に子が生成された時間を示す。
長さ１３２９：エントリ１３０３が親ならば、子のエン
トリ１３０３の数を表す。uid１３３１：そのエントリ
１３０３を所有するユーザを命名する文字列値である。
gid１３３３：uidにおいて特定されるユーザが所属する
グループを識別する文字列値である。
【０１１８】以上、プラン９のオペレーティングシステ
ムにより、プロセスごとの名前空間がどのように実施さ
れるか、その名前空間がbindおよびmount処理によりど
のように変更できるか、ファイルの位置を特定するため
に名前空間をどのように利用できるか、さらにそのよう
に特定されたファイルに対してファイル処理をどのよう
に実行できるかについて、詳細に示した。以下におい
て、プロセスごとの名前空間にとり特に有利な２つの用
途を調べる。
【０１１９】プラン９のウィンドウシステム：図１４〜
２３ウィンドウシステムとは、オペレーティングシステ
ムの下で実行中のプロセス１０２にグラフィックス端末
上のウィンドウを与え、かつキーボードまたはマウスの
ような指示装置からウィンドウへの入力に応答するよう
な、オペレーティングシステムのサブシステムである。
Ｘウィンドウのような従来技術のウィンドウシステム
は、大きく且つ複雑なシステムである。プラン９がプロ
セスに利用可能な関数をファイル木構造として定義し、
さらにプラン９のプロセス１０２がそれ自体の名前空間
１１５を定義できることから、Ｘウィンドウなどの従来
技術のウィンドウシステムとほぼ同じ機能を備えながら
も、それより相当少ないコードしか必要としないような
ウィンドウシステムを構築することが可能となった。現
在のところ好ましい実施例は、Ｘウィンドウの大きさの
１／１０以下である。さらに、プラン９のウィンドウシ
ステムの設計で使用される原理は、他のオペレーティン
グシステムに対する異なるウィンドウシステムの設計に
も使用することができる。以降、はじめにプラン９のウ
ィンドウシステムの概要を提示し、その上で、その効率
の原因となるシステムのある側面をさらに詳細に説明す
る。
【０１２０】プラン９のウィンドウシステムの概要：図
１４および１５ プラン９の端末、すなわちGnot７１１には、キーボー
ド、グラフィック・ディスプレイ（graphics displa
y）、およびマウスが含まれる。これらの装置は、カー
ネル・サービス＃ｂおよび＃ｃをディレクトリ/dev６１
９に結合することにより、プラン９のプロセス１０２の
名前空間１１５にまとめてもよい。そのような結合を実
行すると、/dev/mouseはマウスを示し、/dev/consはキ
ーボードを示し、/dev/bitbltはグラフィック・ディス
プレイを示す。これらのファイルを開き、リードおよび
ライト処理を適切に行うことにより、グラフィック操作
を行うことができる。例えば、マウスの動きは、/dev/m
ouseへのリード処理によって決定され、/dev/bitbltに
書き込むことによってグラフィック・ディスプレイ上に
表示が生成される。
【０１２１】プラン９のウィンドウシステムは、プロト
コル・サービス２０９として実施される。ウィンドウ・
プロトコル・サービスは、Gnot７１１上にウィンドウを
有するファイルのインスタンスをプロセス１０２に与え
る。プロセスは、ウィンドウ・サービスによって与えら
れたファイルを読み・書きすることによって、ウィンド
ウを制御する。ウィンドウ・サービスは、ファイル/dev
/mouse、/dev/consおよび/dev/bitbltを含む名前空間を
有するプロセスの集合によって実施される。さらに詳細
に後述するように、これらのファイルをいかなるサービ
ス１２３によって与えてもよい。必要なことは、そのフ
ァイルに対するリードまたはライト処理が、結果的に、
端末に表示されたウィンドウからデータを読んだり、端
末に表示されたウィンドウにデータを書いたりすること
になるということだけである。最も一般的には、それら
のファイルは、カーネル・サービス＃ｂおよび＃ｃによ
って与えられるか、または問題のウィンドウ・プロトコ
ル・サービスがそのクライアントであるような別のウィ
ンドウプロトコル・サービスによって与えられ、さらに
それらのファイルによって制御されるウィンドウが、Gn
ot７１１において表示される。
【０１２２】ウィンドウ・サービスは、プロトコル・サ
ービス２０９であるため、リードおよびライト処理は、
マウント・サービス２０３に至る。マウント・サービス
２０３では、それらの処理をウィンドウ・サービスへの
往信メッセージ（tmassage）に変換し、そのウィンドウ
・サービスから返信メッセージ（rmessage）に入ったデ
ータが戻るのを待つ。そのデータが、マウント・サービ
ス２０３に戻ると、そのデータは、リードまたはライト
処理を行ったプロセス１０２に返される。ウィンドウ・
サービスは、tmessageに応じて、それらのtmessageをウ
ィンドウ・サービスの名前空間の一部であるファイル/d
ev/mouse、/dev/consおよび/dev/bitbltに対するリード
およびライトへと変換する。これらのリードおよびライ
トへの応答は、rmessageに変換されて、マウント・サー
ビス２０３に返される。このように、ウィンドウ・サー
ビスは、その名前空間におけるファイル/dev/mouse、/d
ev/consおよび/dev/bitbltを複数のプロセス１０２の間
で効率的に多重化する。または、換言すれば、ウィンド
ウ・サービスは、プロセス１０２に仮想端末の集合を与
える。
【０１２３】図１５において、ルート１５０２は、次の
ファイルからなるディレクトリである。bitblt１５０
３：このファイルに書き込むと、プロセス１０２に対す
るウィンドウにおけるグラフィック表示が変化し、この
ファイルから読み出すと、プロセス１０２に対するウィ
ンドウにおける表示に関する情報が返される。cons１５
０５：このファイルのリードにより、Gnot７１１に接続
されたキーボードからの入力を獲得し、このファイルへ
のライトによって、文字がカーソル位置の表示に出力さ
れる。hold１５０７：このファイルにより、cons１５０
５からのリードにおいて得られた新たな行の文字に対し
プロセス１０２がいかに応答するべきかを示す。mouse
１５０９：このファイルのリードにより、Gnot７１１に
接続されたマウスからの入力を得る。nbmouse５１１：
このファイルのリードによって、同様にマウスからの入
力を得るが、マウスの状態に変化は待たない。rcons１
５１３：このファイルのリードによって、Gnot７１１に
接続されたキーボードから未処理の入力を得る。snarf
１５１５：このファイルは、ウィンドウ間のデータ転送
に使用される；ライトによって、ウィンドウからsnarf
ファイルにデータが書き込まれ；リードによって、snar
fファイルのデータがウィンドウに読み込まれる。
【０１２４】プロセス１０２が、その名前空間における
ファイル木構造１５０１をマウントする度に、プロセス
１０２は、ファイル木構造１５０１の新たなインスタン
スを受け取る、すなわち、そのファイル木構造１５０１
におけるファイルのインスタンスは、そのマウント処理
を行ったプロセス１０２から結果的に生じる接続を介し
てしかアクセスできない。サービス１２３の概要におい
て指摘したように、ファイル木構造１５０１がプロセス
１０２の名前空間においてマウントされる度に、ウィン
ドウ・サービスは、ファイル木構造１５０１の新たなイ
ンスタンスを与えることができる。これは、ウィンドウ
・サービスによってプロセス１０２に与えられるファイ
ルを表すチャネル３０１が、ウィンドウ・サービスによ
って与えられるqidによって、そのファイルを識別する
からである。従って、１つのプロセス１０２に対するフ
ァイル/dev/bitbltは、別のプロセス１０２に対するフ
ァイル/dev/bitbltとは異なるqidを有するのであり、プ
ロセス１０２によるそのファイルへのライトは、そのプ
ロセス１０２に対するファイル/dev/bitbltのみに対す
るライトである。
【０１２５】図１４において、ウィンドウ・サービス１
４０５は、その名前空間にカーネル・サービス＃ｂ１４
１１および＃ｃ１４１９によって与えられるファイルを
有す、かつプロセスＰ１０２（ａ）〜Ｐ１０２（ｎ）の
集合にGnot７１１上のウィンドウを与えている。各プロ
セスＰ１０２は、パイプ１４０３によってウィンドウ・
サービス１４０５に接続されている。前記のように、ウ
ィンドウ・サービス１４０５によって与えられるファイ
ルに対する処理は、ウィンドウ・サービス１４０５とプ
ロセス１０２との間のパイプ１４０３上のtmessageおよ
びrmessage２０５および２０７となる。ウィンドウ・サ
ービス１４０５によって与えられるファイルは、図１４
において１４０６として現れる。プロセス１０２がサー
ビス１４０５によって与えられるファイル木構造１５０
２をマウントする度に、そのプロセスは、ファイル１４
０６におけるスロット１４０７を受け取る。このスロッ
トは、サービス１４０５によってプロセス１０２に与え
られるファイル１４０９（0..k）の完全な集合を含む。
従って、スロット１４０７（ａ）は、プロセス１０２
（ａ）に対するファイル１４０９（0..k）のインスタン
スからなる。
【０１２６】ウィンドウ・サービス１４０５により、所
与のプロセス１０２に対するファイル１４０９について
のファイル処理を指定するメッセージ２０５および２０
７が、カーネル・サービス＃ｂ１４１１およびカーネル
・サービス＃ｃ１４１７によって与えられるファイルに
ついての処理を指定する関数コール２１７および２１９
へと変換される。＃ｂが/dev６０５に結合されると、/d
ev/mouse１４１３に関するリード関数コール１４１２
は、マウス１４２３から入力を獲得し、一方、/dev/bit
blt１４１５に関するリード／ライト関数コール１４２
５は、表示１４２７を制御する。同様に、＃ｃが/dev60
5に結合されると、/dev/consに関するリード関数コール
１４２９は、キーボード１４３１から入力を得る。
【０１２７】ファイルシステム１４０６の実施：図１８
および１９ 好ましい実施例において、ウィンドウ・サービス１４０
５がプロセス１０２に与えるファイル木構造１５０１に
おけるファイルのインスタンスの実施および位置づけ
に、図１８のデータ構造体１８０１を使用する。プロト
コル・サービス２０９によって与えられるファイルが開
かれている場合、マウント・サービス２０３によってプ
ロトコル・サービス２０９に送られるオープンtmessage
は、ファイル識別子（ＦＩＤ）３３１を含む。このオー
プンtmessageに応じて、プロトコル・サービス２０９
は、そのファイル識別子３３１を、プロトコル・サービ
ス２０９がファイルを識別するために内部的に使用する
qid３２３に関係付ける。プロトコル・サービス２０９
によって返されるオープンrmessageは、そのqidを含
み、さらにプロトコル・サービス２０９によってそれに
関係付けられたfid３３１およびqid３２３は、共に、そ
のオープン・ファイルを表すチャネル３０１に含まれ
る。
【０１２８】まず、ファイル配列１８０３であるが、フ
ァイル配列１８０３は、プロトコル・サービス２０９に
よって現在与えられているファイルのすべてのインスタ
ンスに対するエントリ１８０５を収容する。所与のイン
スタンスのエントリ１８０５は、そのインスタンスのフ
ァイル識別子によって示される。各エントリ１８０５
は、３つのフィールドからなる。ビジー・フィールド１
８０７：エントリ１８０５が使用中かどうかを示す。フ
ィールド１８０９：インスタンスがオープンかどうかを
示す。ファイル・ポインタ・フィールド１８１１：イン
スタンスに対するファイル構造体１８１３を指し示す。
ファイル構造体１８１３は、次のフィールドからなる。
ビジー１８１５：インスタンスがビジーかどうかを示
す。ファイル型１８１７：ファイルが、ファイル木構造
１５０１におけるファイルのいずれであるかを示す。ス
ロット１８１９：ファイルがいずれのスロット１４０７
に属するかを示す値である。所与のファイル木構造１５
０１のすべてのファイルに対するファイル構造体１８１
３は、スロット１８１９に同じ値を有する。最後に、記
述ポインタ（dptr）１８２１：ディレクトリ木構造１５
０１に存在し得るファイルの記述子の配列におけるエン
トリ１８２３を指し示す。
【０１２９】ファイル型１８１７およびスロット１８１
９は、インスタンスのqid３２３を生成するために、共
に連結される。記述子エントリ（DE）１８２３は、３つ
のフィールドを有する。文字列名１８２５：ファイル木
構造１５０１における名前の１つである。ファイル型値
１８２７：名前に対応するファイル型であり、ファイル
型（ftype）フィールド１８１７と同じ値を有する。そ
して、許可フィールド１８２９：ファイルをどのように
使用できるかを示す。
【０１３０】スロット１８１９の可能な値は、それぞ
れ、そのスロットによって表されるファイル木構造１５
０１へのtmessageによって制御される表示１４２７中の
ウィンドウを表すデータ構造体に対応する。ウィンドウ
のデータ構造体１９０３を図１９に示す。構造体１９０
３は、次の種類の情報を含む。refフィールド１９０
５：スロット１８１９の値に相当するファイル木構造１
５０１があるかどうかを示す。ビジー１９０７：ウィン
ドウ・データ構造体１９０３が現在使用中かどうかを示
す。スロット１９０９：ウィンドウ１９０３が対応する
スロット値。wdesc１９１１：構造体１９０３によって
表されるウィンドウを記述する情報である。フレーム記
述１９１３：wdesc１９１１によって指定されたウィン
ドウのいずれの部分が現在表示されているかを記述する
情報。qh１９１４：テキスト１９１５における文字への
ポインタ。テキスト１９１５は、ウィンドウに表示され
るべきテキストを収容する。rawbuf１９１７：キーボー
ド１４３１からウィンドウへの生の（未処理の）入力を
収容するバッファ。コンソール・ライト情報１９１９：
ファイルcons１５０５を指定するtwriteメッセージで受
信した情報。コンソール・リード情報１９２１：ファイ
ルcons１５０５を指定するtreadメッセージに応じて送
られるべき情報。マウス・リード情報：ファイルmouse
１５０９を指定するtreadメッセージに応じて送られる
べき情報。リード・キュー・ポインタ（rqpr）１９２
５：スロットによって表されるファイル木構造１５０１
におけるファイルを指定するtreadメッセージの待ち行
列を示す。ライト・キュー・ポインタ（wqpr）１９２
７：スロットによって表されるファイル木構造１５０１
におけるインスタンスを指定するtwriteメッセージの待
ち行列を示す。kbdc１９２９：そのウィンドウにとって
重要なキーボードの文字を収容する。send１９３１：ウ
ィンドウにおける変更のためにrmessageを送信らなけれ
ばならないことを示すフラグ。ウィンドウ状態１９３
３：ウィンドウの現在の状態を示す情報。そして、ビッ
ト・リード情報１９３５：ウィンドウのビット・マップ
からビットを読み出すために必要な情報。
【０１３１】ファイル木構造１５０１に対するファイル
・ロケータ処理ウィンドウ・サービス１４０５は、プロ
トコル・サービス２０９として、マウント・サービス２
０３からtmessageを受け取ると、このtmessageに対し、
マウント・サービス２０３に返すrmessageによって応答
する。以下において、ウィンドウ・サービス１４０５が
tmessageのいくつかに応答する方法をを説明し、マウン
ト・サービス２０３とプロトコル・サービス２０９との
間の相互作用をプロトコル・サービス２０９から見た例
を与える。
【０１３２】tmessageによって指定される処理を２つあ
げれば、attachおよびwalkファイル・ロケータ処理であ
る。まず、attach処理については、既に述べたとおり、
マウント・システム・コールの実行の結果、マウント・
サービス２０３により、そのファイル記述子４１７がマ
ウント・システム・コールにおいて使用されたプロトコ
ル・チャネルによって表されるプロトコル・サービス２
０９にattach返信メッセージが送られる。好ましい実施
例では、マウント・システム・コールは、さらに、マウ
ント・サービス２０３がattach往信メッセージに入れて
プロトコル・サービス２０９に送るデータを含む。プロ
トコル・サービス２０９が、ウィンドウ・サービス１４
０５ならば、そのデータには、スロット数が含まれる。
ウィンドウ・サービス１４０５は、このattach往信メッ
セージに応じて、attach往信メッセージに含まれるファ
イル識別子に対するエントリ１８０５を発見し、ビジー
１８０７を１に、オープン１８０９を０にそれぞれ設定
する。次に、ウィンドウ・サービス１４０５は、インス
タンスにファイル構造体１８１３を割り当て、スロット
・フィールド１８１９をルート・ディレクトリを指定す
る値に設定し、さらにdptr１８２１をルート１５０２に
対するディレクトリ・エントリ１８２３を示すように設
定する。ウィンドウ・サービス１４０５によって返され
るattach返信メッセージには、ftype１８１７およびス
ロット１８１９から作られたqid３２３が含まれる。最
後に、スロットに関係付けられたウィンドウ１９０５に
おける参照カウンタがインクリメントされる。
【０１３３】既に述べたとおり、パス名の分析時に呼び
出されたチャネル３０１がプロトコル・サービス２０９
におけるファイルを表すときに、walk往信メッセージが
生成される。この往信メッセージによって、プロトコル
・サービス２０９におけるディレクトリに対するファイ
ル識別子３３１およびそのディレクトリにおけるファイ
ルの名前が指定される。返信メッセージにより、その名
前によって指定されたインスタンスのqidが、返され
る。この時、往信メッセージにおけるファイル識別子３
３１が、返されたqidに関係付けられる。好ましい実施
例において、ウィンドウ・サービス１４０５は、walk往
信メッセージに応じて、ファイル識別子３３１に対する
エントリ１８０５の位置を特定して、その名前を見る。
その名前が、ルート１５０２を示す「．」ならば、エン
トリ１８０５内のファイル・ポインタ１８１１によって
示されるファイルは、そのルート・ディレクトリを記述
する。この場合、そのファイル１８１３におけるqid３
２３が、返信メッセージに入れて返され、そうでない場
合、その名前に対応する同じフィールド１８２５を有す
る記述エントリ１８２３が見つかるまで、ファイル記述
の配列が探査される。エントリ１８２３からのftypeフ
ィールド１８２７の値およびディレクトリに対するファ
イル１８１３からのスロット１８１９の値が、保存され
る。次に、現在使用されているすべてのファイル構造体
１８１３が、探査され、保存されたスロット値をスロッ
ト１８１９に、保存されたファイル型の値をftypeフィ
ールド１８１７にそれぞれ持つものが求められる。見つ
かった場合、それらの保存された値は、qid３２３とし
て返され、見つからなかった場合は、新たなファイル構
造体１８１３が割り当てられて、ftypeフィールド１８
１７が保存されたファイル型の値から設定され、スロッ
ト１８１９が保存されたスロット値から設定され、dptr
１８２１がその名前を持っていたファイル記述の配列の
エントリを示すように設定され、ビジーが１に設定さ
れ、ファイル識別子３３１に対するエントリ１８０５の
fptr１８１１が新たなファイル構造体を示すように設定
される。そして、保存されたスロットおよびftypeの値
は、qid３２３として返される。
【０１３４】ウィンドウ・サービス１４０５の内部構
造：図１６〜１９および図２１ 好ましい実施例においては、ウィンドウ・サービス１４
０５は、プラン９のオペレーティングシステムの下で実
行する３つのプロセス１０２によって実施される。図１
６において、ウィンドウ・サービス１４０５(0)にあた
るこれら３つのプロセス１０２、ならびにカーネル・サ
ービス＃ｂ１４１１、＃ｃ１４１９およびウィンドウ・
サービス１４０５のクライアント（依頼主）であるプロ
セス１０２に対する関係を説明する。クライアントであ
るプロセス１０２は、図１６において、ＣＰ１６１５
(0)、ＣＰ１６１５(1)、および第２のウィンドウ・サー
ビス１４０５(1)を構成する３つのプロセスとして現れ
るが、これは、また、ウィンドウ・サービス１４０５
(0)のクライアントでもあり、かつそれ自体が、図１６
には示していないクライアントを有する。このように、
図１６には、３つのレベルの端末サービスが存在する。
すなわち、カーネル・サービス＃ｂおよび＃ｃによって
与えられる実端末サービス、ウィンドウ・サービス１４
０５(0)によってそのクライアントに与えられる第１水
準の仮想端末サービス、およびウィンドウ・サービス１
４０５(1)によってそのクライアントに与えられる第２
水準の仮想端末サービスである。さらに詳細に後述する
が、各水準の端末サービスは、異なる名前背景（ＮＣ）
１６２１に対応する。例えば、名前背景１６２１(0)に
おいては、ファイル名「mouse」は、カーネル・サービ
ス１４１１によって与えられるmouseファイルを示し；
名前背景１６２１(1)においては、ファイル名「mouse」
は、ウィンドウ・サービス１４０５(0)によって与えら
れるファイル木構造１５０１のうちの１つにあるファイ
ルを示し；名前背景１６２１(2)においては、ファイル
名「mouse」は、ウィンドウ・サービス１４０５(1)によ
って与えられるファイル木構造１５０１のうちの１つに
あるファイルを示す。
【０１３５】まず、ウィンドウ・サービス１４０５(0)
については、ウィンドウ・サービス１４０５(0)を構成
する３つのプロセスは、主プロセス１６１３(0)、マウ
ス従プロセス（ＭＳ）１６０３(0)、およびキーボード
従プロセス（ＫＳ）１６０５(0)である。主プロセス１
６１３(0)は、ウィンドウ・サービス１４０５(0)のクラ
イアントからパイプ１６０７(0)を介して往信メッセー
ジを受信し、この往信メッセージに応じて、返信メッセ
ージをパイプ１６０６(0)を介してクライアントに与え
る。往信メッセージおよび返信メッセージは、図１６で
は２０５（０）および２０７（０）として現れる。往信
メッセージが、＃ｂ１４１１および＃ｃ１４１９によっ
て与えられるファイルに対する処理を必要とする場合、
主プロセス１６１３(0)は、プラン９のリードおよびラ
イトのシステム・コールを用いて必要な処理を行う。前
記のとおり、プラン９のオペレーティングシステムは、
ファイルシステム・コールをファイル・サービス＃ｂま
たは＃ｃに適合する種類の要求２１７および２１９へと
自動的に変換する。
【０１３６】マウス従プロセス１６０３(0)およびキー
ボード従プロセス１６０５(0)が、必要なのは、＃ｂ１
４１１によって与えられるmouseファイルまたは＃ｃ１
４１９によって与えられるconsファイルに対するファイ
ル・リード処理を行うプロセス１０２が、そのファイル
から読み出されるべき実際のデータがない限り、ブロッ
クするからである。主プロセス１６１３(0)は、そのク
ライアントからの往信メッセージに常に応答できなけれ
ばならないので、ブロックすることはできず、従って、
＃ｂにおけるmouseファイルまたは＃ｃにおけるconsフ
ァイルに対し、リード処理を直接行うことはできない。
これらのリードは、それぞれマウス従プロセス１６０３
(0)およびキーボード従プロセス１６０５(0)によって行
われる。これら２つの従プロセスは、共に、主プロセス
１６１３(0)のクライアントである。マウス従プロセス
１６０３(0)の処理は、両者に典型的である。マウス従
プロセス１６０３(0)は、これが＃ｂ１４１１によって
与えられるファイルmouseに対してプラン９のシステム
・リード・コールを行うときのループを単に実行し、さ
らにウィンドウ・サーバ１４０５(0)によって与えられ
るファイル木構造１５０１にうちの１つにあるファイル
mouseに対してプラン９のシステム・ライト・コールを
行う。好ましい実施例における慣例により、マウス従プ
ロセス１６０３(0)およびキーボード従プロセス１６０
５(0)によって書き込まれるファイル木構造１５０１
は、常に、スロット１４０７(0)を持つものである。勿
論、プラン９のオペレーティングシステムは、ファイル
システム・コールを＃ｂによって適切な要求２１５に与
えられたmouseファイルに、ファイルシステム・コール
をパイプ１６０７を介して主プロセス１６１３に送られ
るwrite往信メッセージにウィンドウ・サーバ１４０５
(0)によって与えられるmouseファイルに自動的に変換す
る；主プロセス１６１３は、そのwrite往信メッセージ
に、他のクライアントからの往信メッセージと同じよう
に応答する。
【０１３７】以上より明らかなように、マウス従プロセ
ス１６０３(0)は、２つの異なる名前背景１６２１に存
在するmouseファイルに対してファイル処理を行ってい
る。リード処理は、名前背景１６２１(0)にあるmouseフ
ァイルに対するものであり、一方ライト処理は、名前背
景１６２１(1)にあるmouseファイルに対するものであ
る。この状態は、マウス従プロセス１６０３(0)におい
て、プラン９のopen、forkpgrp、およびmountの処理を
用いることによって達成される。これを行う方法を図１
７に示した。関数mkslave１７０１を用いて、マウス従
プロセス１６０３(0)およびキーボード従プロセス１６
０５(0)の両方を作る。この関数は、２つの引数---パス
名、および各リード処理の時に読むべきバイト数を指定
する計数---を持ち、それが生成した従プロセスのプロ
セス識別子（pid）を返す。
【０１３８】mkslave１７０１は、主プロセス１６１３
(0)によって、引数「/dev/mouse」および「１０」を付
けて呼び出される。主プロセス１６１３(0)は、その中
でカーネル・サービス＃ｂ１４１１がカーネル・ルート
・ファイル・サービスによって与えられるファイル/dev
に結合されているような名前空間１１５を有するので、
パス名「/dev/mouse」は分析されて、カーネル・サービ
ス＃ｂ１４１１によって与えられるファイル「mouse」
を表すチャネル３０１を指定するファイル記述子４１７
となる。この事実は、図１７の最上部にある表記「名前
背景１６２１(0)」によって示される。主プロセス１６
１３(0)は、マウス従プロセス１６０３(0)を生成するた
めにmkslave１７０１を使用する時点で、既にパイプ１
６０７(0)生成し、かつウィンドウ・サービス１４０５
(0)をsrvに登録している。ウィンドウ・サービス１４０
５(0)を表すsrvのファイルに書き込まれるファイル記述
子は、パイプ１６０７(0)によって表されるファイルに
対するファイル記述子のうちの１つである。このファイ
ル記述子は、以下において「ｃｆｄ」と称するが、ウィ
ンドウ・サービス１４０５(0)のクライアントが往信メ
ッセージを書き込むファイルを表す。
【０１３９】mkslave１７０１が最初に行うことは、パ
ス名引数荷よって指定されたファイルを開くことである
（１７０５）。依然として名前背景１６２１(0)にある
ので、そのファイルは、＃ｂ１４１１によって与えられ
るファイル「mouse」である。オープン処理の結果とし
て、ファイル記述子ｆｄ１は、この時点で、＃ｂのファ
イル「mouse」を表す。次に、fork関数を含んだswitch
文がくる（１７０７）。このfork関数は、親プロセス１
６１３(0)の背景のコピーを有し、従ってｆｄ１のコピ
ーを有する新たな子プロセス１０２を生成する。その子
プロトコル・サービス２０９は、また親プロセス１６１
３(0)と同じ名前空間１０５を有する。このswithc文に
は３つの分岐がある。第１の分岐１７０９は、fork関数
の実行中の発生するエラーを処理する。第２の分岐１７
１３は、親プロセス１６１３(0)によって実行される
が、子プロセス１６０３(0)によっては実行されないよ
うなコードである。ブロック１７３７および１７３９に
よって示したように、このコードは、ｆｄ１の親プロセ
ス１６１３(0)のコピーをクローズし、子プロセス１６
０３(0)のpidであるpidを返す。
【０１４０】switch文の第３の分岐１７１５は、子プロ
セス１６０３(0)によってのみ実行されるコードであ
る。まず、子プロセス１６０３(0)に新たな名前空間１
０５を与えるために「forkpgrp」が実行される。forkgr
pが引数「０」と共に呼び出されるので、その新たな名
前空間は、親プロセス１６１３の名前空間１０５のコピ
ーである。次に、システム・マウント処理が、行われる
（１７２１）。このマウントは、ｃｆｄ---これは、ウ
ィンドウ・サービス１４０５(0)のクライアントによっ
て使用されるパイプ１６０７(0)の最後を表す---を、BE
FOREオプションを用いて、新たな名前空間１０５におけ
るディレクトリ/devに結合する。マウント処理の結果と
して、サービス１４０５(0)のファイル１４０６のスロ
ット０にあるファイル木構造１５０１は、/devに結合さ
れていて、/dev/consなどのファイルへの参照は、この
時点で、ファイル１４０６のスロット０におけるファイ
ルconsへの参照となる。しかし、プロセス１６０３(0)
の名前空間１０５は変化し、「ｃｆｄ」は/devにマウン
トされているので、オープン・システム・コールにおけ
るパス名引数は、この時点で、サービス＃ｂ１４１１
におけるファイル「mouse」ではなく、サービス１４０
５(0)のスロット０のファイル木構造にあるファイル「m
ouse」と分析される。この名前背景の変化を図１７にブ
ロック１７１７に続く波線によって示した。ブロック１
７１７において、名前背景１６２１(0)は、名前背景１
６２１(1)から分離される。
【０１４１】オープン・システム・コールによって返さ
れたファイル記述子４１７は、「ｆｄ２」に割り当てら
れる。従って、この時点で、ｆｄ１は、サービス１４１
１におけるファイル「mouse」を表し、ｆｄ２は、サー
ビス１４０５(0)のスロット０にあるファイル「mouse」
を表す。switch１７０７の第３の分岐の残りの部分は、
マウス従プロセス１６０３が、ｆｄ１を用いてリード・
システム・コールを行うループ１７３５であり、それ
は、サービス＃ｂ１４１１におけるmouseファイルを読
み（１７２５）、さらにｆｄ２およびサービス＃ｂ１４
１１におけるmouseファイルから受け取ったデータを用
いてライト・システム・コールを行い、そのデータをサ
ービス１４０５(0)のスロット０にあるmouseファイルに
書き込む（１７３３）。書込みが失敗の場合、すなわ
ち、サービス＃ｂ１４１１から受け取っただけのデータ
をサービス１４０５(0)に書き込むことができない場
合、このプロセスは、出る（１７３１）。キーボード従
プロセス１６０５(0)も全く同じようにして生成される
が、mkslave１７０１の呼び出しでは、パス名として「/
dev/rcons」を指定し、バイト長として「１」を指定す
る点が異なる。従って、キーボード従プロセス１６０５
によるｆｄ１に対する各リードは、キーボードから１文
字を読み、プロセス１６０５によるｆｄ２に対する各ラ
イトは、スロット０にあるファイル木構造１５０１の
「rcons」ファイルに１文字を書き込む。ここでは「rco
ns」が使用されるので、ウィンドウ・サービス１４０５
(0)は、文字を、ちょうどそれらがキーボードから入力
されたとおりに受け取る。
【０１４２】mkslave関数によって、プラン９における
ファイル・アクセス処理、ならびに「fork」および「fo
rkpgrp」システム・コールのセマンティックス（意味と
動作の関係）の基本的な意義がいくつか説明される。ま
ず、ファイル・アクセス処理では、パス名ではなくファ
イル記述子４１７によってファイルを参照する；代わっ
て、ファイル記述子がチャネルを参照し、そして、チャ
ネル３０１が所与のファイルを表す限り、そのチャネル
を参照するファイル記述子を使用するファイル・アクセ
ス処理は、所与のファイルをアクセスすることになる。
さらに、「fork」が新たなプロセス１０２を生成する
と、その新たなプロセス１０２は、古いプロセス１０２
の背景のコピーを受け取る。この背景にはファイル記述
子配列４１３が含まれる；従って、新たなプロセス１０
２は、そのforkシステム・コールを実行したプロセス１
０２に対し開かれていた任意のファイルに対してファイ
ル・アクセス処理を行うことができる。最後に、「fork
pgrp」は、新たな名前空間１１５を生成するとき、fork
pgrpを実行しているプロセス１０２に対し新たなマウン
ト・テーブル８０１を生成するに過ぎない；そのプロセ
ス１０２に対するファイル記述子配列４１３は、不変の
ままである。このようなことから、mkslave１７０３を
実行するプロセス１０２は、同じパス名を用いて、カー
ネル・サービス＃ｃ１４１９のファイル「rcons」およ
びウィンドウ・サービス１４０５のファイル「rcons」
を開くことができる。さらに詳細に後述するように、フ
ァイル・アクセス処理、「fork」および「forkpgrp」の
セマンティックスにより、サービスの再帰的な生成も可
能である、すなわち、サービスは、クライアントとし
て、それ自体の別のインスタンスを持つことができる。
【０１４３】また、パイプ１６０７(0)は、主プロセス
１６１３(0)をそのクライアント１６１５(0および1)お
よびウィンドウ・サービス１４０５(1)に接続する。パ
イプ１６０７は、主プロセス１６１３(0)によって生成
されたので、主プロセス１６１３(0)は、それが返信メ
ッセージを書き込む先のパイプ１６０７(0)内のファイ
ルを表すサービス・ファイル記述子１６１７(0)を有す
る。各クライアント・プロセスは、そのクライアントが
往信メッセージを書き込む先のパイプ１６０７(0)内の
ファイルを表すクライアント・ファイル記述子１６１９
(0)を有する。クライアント・プロセスは、主プロセス
１６１３(0)によって、生成され、かつクライアント・
ファイル記述子１６１９(0)が与えられている。Gnot711
のユーザが画面１２７において新たなウィンドウを要求
する度に、新たなクライアント・プロセスが、生成され
る。好ましい実施例において、新たなウィンドウは、マ
ウス１４２３を用いて画面１４２７上のメニューからそ
の選択肢を選ぶことによって、要求される。
【０１４４】マウス１４２３によってメニューから新た
なウィンドウを選択すると、結果として、マウス従プロ
セス１６０３(0)が、サービス＃ｂ１４１１によって与
えられるmouseファイルに対するリードを完了し、そのm
ouseファイルから読み出したデータをサービス１４０５
(0)のスロット０にあるmouseファイルに書き込む。結果
的に、主プロセス１６１３(0)へのパイプ１６０７(0)上
に往信メッセージが発生し、この往信メッセージに応じ
て、主プロセス１６１３(0)は、新たなウィンドウに対
しウィンドウ構造体１９０３を位置付けて用意する。次
に、主プロセス１６１３(0)は、引数として新たなウィ
ンドウに対するスロットを用いて関数「spawn」を呼び
出す。spawnは、クライアント・プロセス１６１５を生
成し、引数において指定されたスロットに対するウィン
ドウ・サービス１４０５(0)におけるファイル木構造１
５０１をクライアント・プロセス１６１５の名前空間１
０５の一部とし、さらに新たなクライアント・プロセス
１６１５におけるシェル・プログラムを実行する。
【０１４５】図２１において、spawn関数２１０１は、
まず同期パイプをオープンする（２１０５）。同期パイ
プの目的は、新たなクライアント・プロセス１６１５が
走るまで、主プロセス１６１３(0)が進まないことを確
実にするためである。次に、switch文におけるforkシス
テム・コールを実行することによって、クライアント・
プロセス１６１５が生成される（２１０７）。forkに関
しエラーがあった場合、分岐２１０９が取られ、エラー
を示す値−１が返される。forkが成功した場合、主プロ
セス１６１３(0)が、分岐２１１３に示したように進行
する；synchパイプを読み（２１１５）、子に対するpid
を返す（２１１７）。新たなクライアント・プロセス１
６１５がsynchパイプにデータを置くまで、主プロセス
１６１３(0)は、リードを完了できないので、主プロセ
ス１６１３は、新たなクライアント・プロセス１６１５
が走るまでは、戻らない。
【０１４６】分岐２１０７は、新たなクライアント・プ
ロセスがどのように進むかを示す。まず、新たなクライ
アント・プロセス１６１５は、forkpgrpを実行すること
によって、新たな名前空間を得る（２１１９）。引数
「０」が使用されるので、その新たな名前空間は、主プ
ロセス１６１３の名前空間のコピーである。そこで、ク
ライアント・プロセス１６１５は、主プロセス１６１３
(0)が実行を継続できるように、synchパイプへのライト
を行う（２１２１）。次に、プロセス１６１５は、ウィ
ンドウ・サービス１４０５(0)からファイル木構造１５
０１をマウントするべき標準の場所を示すパス名にｃｄ
ｆ１６１９(0)をマウントする。これを行うために使用
されるマウント・システム・コールは、引数としてスロ
ット数を含む（２１２３）。前記のように、クライアン
ト・プロセス１６１５におけるマウント・システム・コ
ールの結果として、attach往信メッセージがパイプ１６
０７(0)を介してウィンドウ・サービス１４０５(0)に送
られる；ウィンドウ・サービス１４０５(0)が、このatt
ach往信メッセージに応じて、スロット数によって指定
されたスロットにおけるファイル木構造１５０１のルー
トに対するqidを返し、そのqidが、cfd１６１９によっ
て指定されるチャネル３０１に置かれる（勿論、クライ
アント・プロセス１６１５は、生成されたときに、cfd
１６１９の新たなコピーが与えられた）。次に、bindシ
ステム・コールを用いて、ファイル木構造１５０１がマ
ウントされた先のパス名を/devに結合する（２１２
５）。「BEFORE」オプションを使用するので、/dev/mou
seのようなパス名は、この時、スロット数によって指定
されるスロットにあるファイル木構造１５０１における
ファイル「mouse」へと分析される。
【０１４７】次に、synchパイプに対するファイル記述
子によって表されるファイル、パイプ１６０６(0)のサ
ービス端、および標準Ｉ／Ｏがクローズされる（ブロッ
ク２１２７、２１２９、２１３１）。プラン９の慣例に
より、あるプロセスに属する標準Ｉ／Ｏに対するファイ
ルは、ファイル記述子０および１を有する；従って、ス
テップ２１３１においてこれらのファイルをクローズす
ることにより、それらの記述子は、以降の用途に確実に
使用できるようになる。次に、読み出すために/dev/con
sを開く（２１３３）。このオープン・システム・コー
ルによって、walk往信メッセージが発生し、これによ
り、ファイル２４０６の適切なスロットに/dev/consに
対するファイル木構造１８１３が生成され、さらに前記
コールによりopen往信メッセージが発生し、これによっ
て、１に設定されているファイルに対するエントリ１８
０５に対するファイル１８０９が開かれる。openは、ク
ライアント・プロセス１６１５に対するファイル記述子
配列４１３の最初からファイル記述子４１７を捜し始め
るので、openによって返されるファイル記述子は、ファ
イル記述子０となり、/dev/consは、標準入力ファイル
として作用することになる。続いて、openシステム・コ
ールは、読むために/dev/consをオープンする；結果は
既に説明したとおりであるが（２１３５）、openによっ
て返されるファイル記述子４１７は、ファイル記述子１
となり、/dev/consは、標準出力ファイルとして作用す
る点が異なる。ステップ２１３７において、ファイル記
述子１がオープンされるので、ファイル記述子２---こ
れは、慣例により標準エラー・ファイルを表す---がフ
ァイル記述子１と同じファイルを表すことになり、エラ
ー・メッセージが、/dev/consに出力される。最後に、
シェル・プログラム---プラン９のユーザ・インタフェ
ースを与えるーーーが、実行される（２１３９）。
【０１４８】ここで、新たなクライアント・プロセス１
６１５が、ウィンドウ・サービス１４０５に対するプロ
グラムを実行すると、結果は、ウィンドウ・サービス１
４０５(0)のクライアントである新たなウィンドウ・サ
ービス１４０５(1)である。ウィンドウ・サービス１４
０５(1)は、ウィンドウ・サービス１４０５(0)と同じ構
成要素を有し、その従プロセスおよびクライアント・プ
ロセスにパイプ１６０７(1)によって接続されている。
ウィンドウ・サービス１４０５(1)は、ウィンドウ・サ
ービス１４０５(0)と全く同様に作用するが、新たなク
ライアント・プロセス１６１５(1)の名前空間１０５に
設けられている、すなわち、/dev/mouseまたは/dev/con
sなどのパス名は新たなクライアント・プロセス１６１
５に属するサービス１４０５(0)のスロット１４０７に
あるファイル木構造１５０１におけるファイルを指す点
が異なる。従って、これらのファイルに対するリードお
よびライトは、カーネル・サービス＃ｂおよび＃ｃの代
わりに、ウィンドウ・サービス１４０５(0)へのパイプ
１６０７(0)を介する往信メッセージを発生する結果と
なる。そして、ウィンドウ・サービス１４０５(0)が、
ウィンドウ・サービス１４０５(1)からの往信メッセー
ジに応じて、カーネル・サービス＃ｂおよび＃ｃへの要
求を生成する。
【０１４９】主プロセス１６１３の内部構造：図２０ 図２０において、主プロセス１６１３は、クライアント
・プロセス１６１５、マウス従プロセス１６０３、およ
びキーボード従プロセス１６０５からの往信メッセージ
２０５および２０７を処理し、それらの往信メッセージ
に応じて、ウィンドウ・データ構造体１９０３を更新す
る。そして、＃ｂ１４１１および＃ｃ１４１９によって
与えられるファイルに対するファイル・アクセス・シス
テム・コールにおいてウィンドウ・データ構造体１９０
３の情報を使用する。好ましい実施例において、主プロ
セス１６１３は、次の主な構成要素を含む。Ｉ／Ｏ関数
２０１９：ウィンドウ・サービス１４０５のクライアン
ト、マウス従プロセス１６０３およびキーボード従プロ
セス１６０５からの往信メッセージ２０５および２０７
に応答する。マウス制御タスク２００８：Ｉ／Ｏ関数２
０１９がマウス従プロセス１６０３から受信する往信メ
ッセージを処理するタスク。キーボード制御タスク２０
０９：Ｉ／Ｏ関数２０１９がキーボード従プロセス１６
０５から受信した往信メッセージを処理するタスク。ウ
ィンドウ制御タスク２００５：ウィンドウ・データ構造
体１９０３のデータをマウス１４２３からの入力の要求
どおりに更新するタスク。各ウィンドウ１９０３(0・・n)
に対応する端末制御タスク２０１５(0..n)：キーボード
制御２００９およびウィンドウ制御２００５からの入力
の要求どおりに対応するウィンドウ２０１３の状態を変
更し、そのウィンドウが属するクライアント・プロセス
１６１５に要求どおりの返信メッセージを送り、さらに
変更したとおりにウィンドウを表示するために、＃ｂ１
４１１および＃ｃ１４１９によって与えられたファイル
にライト処理を行う。
【０１５０】主プロセス１６１３のタスク構成要素は、
ウィンドウ１９０３の状態を変更する事象に応じて主プ
ロセス１６１３が計画して走らせる主プロセス１６１３
の内部のエンティティである。従って、これらのタスク
は、プロセスの一般的性質をいくつか有するが、プラン
９のプロセス１０２ではない。特に、それらは、すべ
て、名前空間１０５も含めて主プロセス１６１３の背景
を共有する。タスクのスケジュリング規則は次のとおり
である。すなわち、あるタスクが責任を有する資源の状
態を変更するＩ／Ｏ関数２０１９において、メッセージ
が受信されると、直ちに、そのタスクが、実行予定のキ
ュウーに配置され、そのキュウーが空の場合は、直ちに
Ｉ／Ｏ関数２０１９が実行される。
【０１５１】構成要素２００１の処理は、およそ次のと
おりである。Ｉ／Ｏ関数２０１９は、往信メッセージを
得るために、パイプ１６０７のサービス・ファイル記述
子１６１７によって指定されるファイルを読む。往信メ
ッセージが、ファイル位置づけ処理を指定した場合、Ｉ
／Ｏ関数２０１９は、そのメッセージ自体を処理して、
適切な返信メッセージを返す。前記の往信メッセージ
が、ファイル・アクセス処理を指定した場合、Ｉ／Ｏ関
数２０１９は、そのメッセージを送ったプロセスに属す
るウィンドウ構造体１９０３(i)を見つけ、その構造体
１９０３の情報を矢印２０１９で示したように更新し
て、端末制御２０１５(i)を走らせる予定をする。端末
制御タスク２０１５(i)が走る場合、ウィンドウ１９０
３(i)を矢印２０２３および２０２５で示したように更
新し、その更新により必要とされる動作を行う。そのよ
うな動作の例としては、矢印２０７によって示したよう
なウィンドウ１９０３(i)が属するプロセスへの返信メ
ッセージがある。この返信メッセージは、パイプ１６０
７にあるクライアント・ファイル記述子１６１９によっ
て表されるファイルに書き込まれる。もう１つの例は、
矢印２１９によって示したような、ウィンドウ１９０３
(i)に対応する画面１４２７におけるウィンドウを再描
画する＃ｂ１４１１および＃ｃ１４１９へのライト処理
である。少し時間をおいて、Ｉ／Ｏ関数２０１９は、実
行を再開し、パイプ１６０７から新たに往信メッセージ
を読む。
【０１５２】マウス従プロセス１６０３およびキーボー
ド従プロセス１６０５からメッセージを受信するのは、
特殊な場合である。メッセージがマウス従プロセス１６
０３からのもでであれば、Ｉ／Ｏ関数２０１９は、その
メッセージをグローバルな記憶装置のマウス・メッセー
ジ２００２に書き込み、マウス制御タスク２００８を予
定する。そのタスク２００８が、走ると、マウス・メッ
セージ２００２をマウス・データ２００６に変換し、さ
らにウィンドウ制御２００５を予定に入れる。ウィンド
ウ制御２００５は、マウス・データ２００６を調べて、
現在のウィンドウ２０１３を決定する。現在のウィンド
ウ２０１３とは、マウス１４２３からデータを受信した
ときにカーソルが位置していた画面１４２７上のウィン
ドウに対応するウィンドウ構造体１９０３のことであ
る。マウス・データ２００６が、現在のウィンドウ２０
１３と一致しない画面１４２７内のウィンドウを示す場
合、ウィンドウ制御２００５は、マウス・データ２００
６によって指定される画面１４２７内のウィンドウに対
応するウィンドウ構造体１９０３を新たな現在のウィン
ドウ２０１３とする。そして、現在のウィンドウ２０１
３をマウス・メッセージによって要求されるように更新
して、その新たな現在のウィンドウに対する端末制御２
０１５を予定する。端末制御２０１５が実行すると、端
末制御２０１５は、画面を再描画するライト処理を行
い、必要なメッセージをマウス従プロセス１６０３に送
る。メッセージが、キーボード従プロセス１６０５から
のものである場合、Ｉ／Ｏ関数２０１９は、マウス従プ
ロセスで示したように進むが、新たに入力された文字が
グローバルな記憶装置のKBDC２００４に書き込まれて、
キーボード制御２００９が予定される点が異なる。キー
ボード制御２００９が走ると、現在のウィンドウ２０１
３を変更し、現在のウィンドウ２０１３に対する端末制
御２０１５を予定する。端末制御２０１５は、既に説明
した処理を行う。
【０１５３】［詳細な例：保持ファイル１５０７に対す
る処理：図２２および２３］ ウィンドウ・サービス１４０５によって与えられるファ
イル木構造１５０１の「保持」ファイル１５０７は、対
話的なプログラムのための文字入力インタフェースの改
良を実施する場合に、使用する。このようなインタフェ
ースにおける典型的な問題部分は、この改良によって解
決される。このようなインタフェースにおいては、行の
端を示すのに使用される行終端コード（一般に、改行ま
たは復帰）は、３つの異なる機能を有する。すなわち、
一連のテキストを表示する場合、それをどのように行に
分割するかを指定する；対話的なプログラムに入力され
ている場合、最後の行の終端子と現在の行の終端子との
間のテキストの文字列が送られるべきことを指定する；
および、コマンド行インタフェースの場合、最後の行の
終端子と現在の行の終端子との間のテキストの文字列が
実行されるべきことを指定する。従って、典型的な対話
型ユーザ・インタフェースにおいては、ユーザが、行終
端コードを使用する場合、その行に関しては終了してお
り、その行は、そのユーザが行終端コードを使用したと
きのままの状態で、表示され、送られ、そして実行され
る。
【０１５４】この構造に本質的な問題は明白であり、従
来の技術は、その幾つかを特殊な文字によって解決して
きた。こうして、表示のために改行を阻止するべく特殊
文字を用いることがあり、コマンド行インタフェースで
は、コマンド行の入力が次の行へと続くことを示すため
に別な特殊文字をたいてい使用する。これまで解決され
てこなかったものは、行が行終端文字に応じて対話型プ
ログラムに送られるという事実から起こる問題である。
その結果、対話型プログラムでは、行終端コードを入力
するまでは、その行を編集することが許されるが、一
方、僅かに編集プログラムにおいては、行を入力し、行
終端コードを入力した後に、入力済みの行に戻って編集
することが一般に許される。この問題に有効な解決策と
言えば、ファイルから入力を読み出すような対話型プロ
グラムを設計し、入力ファイルをエディタを用いて生成
したうえで、そのファイルを対話型プログラムに与える
ことぐらいであった。必要であり、かつウィンドウ・サ
ービス１４０５によって与えられるものは、ユーザが指
定するまでは入力中の文字列が送られないようにする方
法である。
【０１５５】ウィンドウ・サービス１４０５では、この
問題を次のように扱う。第１のモードにおいて、行終端
コードにより、これまでのように行が送られるようにす
る。第２のモードにおいて、端末においてキーを叩くこ
とにより入力されると、そのモードに入ったときから出
るまでの間に入力文字が、そのモードから出た時点で送
られる。ここでは、第２のモードを保持モードと称す
る。好ましい実施例において、保持モードからは、入っ
たときに使用したものと同じキーを叩くことによって出
る。さらに、好ましい実施例において使用されるカーソ
ルおよびウィンドウの境界線の形によって、そのウィン
ドウが現在、保持モードにあるかどうかを示す。好まし
い実施例では、カーソルは矢印である。保持モードにお
けるカーソルは、中抜きの矢印であり、その他の場合
は、ベタの矢印である。
【０１５６】図２２において、ウィンドウ構造体１９０
３におけるウィンドウ記述情報には、現在のカーソルに
対するビット・マップを示すcursorpフィールド２２０
３が含まれる。qh１９１４は、テキスト１９１５におけ
る現在位置を示すポインタであり、代わりに、ウィンド
ウ・データ構造体１９０３(i)によって表されるウィン
ドウに表示されているテキストを収容している。
【０１５７】cons read info１９２１は、３つのフィー
ルドからなり、ウィンドウ構造体１９０３(i)に対応す
るファイル木構造１５０１にあるファイルconsおよびrc
onsに対するリードを指定する最も最近のtreadメッセー
ジからの情報を格納する。それらのフィールドは、次の
とおりである。rtag２２０５：メッセージからのタグを
収容する。rfid２２０７：メッセージからのfidを収容
する。rcnt２２０９：メッセージからの計数であり、読
み出すべき文字数を指定する。RQPTR１９２７は、優先
するtreadを満たすために実行されるべき未解決のリー
ドの待ち行列を指し示す。この待ち行列の各要素２２１
３は、それが対応するtreadメッセージからのrtag、rfi
dおよびrcntを持つ。KBDC１９２９は、キーボードから
読み出されるべき最後の文字を収容し、hold２２１１
は、ウィンドウ１９０３(i)が保持モードかどうかを示
すフラグである。
【０１５８】保持モードは、treadメッセージに応じて
データを送るために使用されるので、好ましい実施例に
おいてtreadメッセージが処理される様子を最初に説明
する。好ましい実施例において、Ｉ／Ｏ関数２０１９
が、rconsまたはconsに対するリードを指定するtreadメ
ッセージを受信すると、Ｉ／Ｏ関数２０１９は、qid３
２３を用いて、rconsまたはconsが入っているファイル
木構造１５０１に対するスロットを確認したうえで、そ
のスロットに対応するウィンドウ構造体１９０３の所在
を特定する。次に、図２３の流れ図２３３３で示したよ
うに、treadメッセージからのtagをウィンドウ構造体１
９０３(k)のrtag２２０５に、同じくそのメッセージか
らのfidをrfid２２０７に、計数をrcnt２２０９に、そ
れぞれ書き込む（２３３５）。ここで、Ｉ／Ｏ関数２０
１９が、スケジュラを呼び出すと、これが、タスク２０
０８、２００５、２００９または２０１５のうち、タス
クの待ち行列において次に実行するべきものを実行させ
る（２３３７）。
【０１５９】端末制御２０１５(k)が、次に走ると、流
れ図２３１３に示した処理を行う。rfid２２０７は、０
に等しくないので（２３２５）、新たなtreadメッセー
ジを受信する。結果的に、新たなrqe２２１３を生成し
（２３１７）、rtag２２０５、rfid２２０７、およびrc
nt２２０９からのフィールドを０に設定し、新たなrqe
２２１３を待ち行列の最後に置く。cons read info１９
１９に示されたリード処理に対するリード・キューにお
けるエントリを作ると、端末制御２０１５(k)は、次
に、リード・キューが空かどうかを判断し、空ならば、
待ち行列の最初のエントリ２２１３を処理する（２３２
５）。流れ図２３２３に示したように、エントリを処理
する要領は、ウィンドウ１９０３(k)が保持モードにあ
ることをhold２２１１が示しているかどうかに依存す
る。ウィンドウ１９０３(k)が保持モードにあることをh
old２２１１が示している場合、リード処理において送
られた文字数をエントリ２２１３におけるrcntの最小値
に設定し、テキスト１９１５の最後とqh１９１４によっ
て現在印が付けられている位置との間の文字、すなわ
ち、qh１９１４によって印が付けられている位置とテキ
スト１９１５の最後との間の行終端文字の数は単に無視
する。そのうえで、エントリ２２１３からのtagおよびf
id、および文字が入ったrreadメッセージをウィンドウ
１９０３(k)が属するプロセスに送る。最後に、最後に
送られた文字に続くテキスト１９１５を示すようにqhを
更新し、要求待ち行列の次の要素を示すようにRQPTR１
９２５を更新する。
【０１６０】hold２２１１が、ウィンドウ１９０３(k)
が保持モードでないことを示す場合、制御はブロック２
３２６に戻る。ここで、ｎをrcntの最小値に設定する
と、次の改行からqh１９１４によって区別される位置ま
での文字の数、すなわちｎにより、qhから次の改行文字
までのテキスト１９１５にある文字のみの数が指定され
る。これらが、このとき、ブロック２３２９において送
られる文字である。そして、qh１９１４を、次の改行文
字に続く文字を示すように更新する。
【０１６１】実施例においては、エスケープ・キーを叩
いて保持モードに入り、再びエスケープ・キーを叩くこ
とによって出る。このように、エスケープ・キーは、保
持モードと行終端子により行が送られるモード（以降、
非保持モードと称する）との間でトグル・スイッチとし
て作用する。流れ図２３０１は、エスケープ・キーに応
じてholdフィールド２２１１がどのように設定・解除さ
れるかを示す。前記のように、キーボード従プロセス１
６０５は、文字を受信すると、ウィンドウ・サービス１
４０５のスロット０のファイルrconsへのライトを行
う。このライトの結果、twriteメッセージが主プロセス
１６１３によって受信される。Ｉ／Ｏ関数２０１９が、
スロット０のrconsへのtwriteメッセージの処理を行う
べく、KBDC２００４に文字を置き、キーボード制御タス
ク２００９を予定する。キーボード制御２００９は、KB
DC２００４の内容を現在のウィンドウ２０１３のKEYBDC
１９２９に書き込み、現在のウィンドウ２０１３に対応
する端末制御２０１５を実行するべきタスクの待ち行列
に配置した後、スケジュラを呼び出す。少し時間をおい
て、ウィンドウ制御タスク２００５が走る；これが走る
と、そのウィンドウ構造体１９０３にあるKEYBDC１９２
９を調べるコードを実行する。このコードに対する流れ
図を図２３の２３０１に示す。ブロック２３０３におい
て、KEYBDC１９２９からKBDC１９２９を取り出す。判断
ブロック２３０５において、それを検査し、それがエス
ケープ文字ならば、hold２２１１を反転し（２３０
７）、hold２２１１の新たな値によって要求されるとお
りにカーソルを設定し（２３０９）、さらに新たな値の
要求どおりに画面の境界線を設定する（２３１１）。実
施例では、流れ図２３０１、２３１３、および２３１４
が、この順に端末制御２０１５によって実行される。こ
られの流れ図の実行後、端末制御２０１５は、エスケー
プ・キーの入力結果がGnot７１１のユーザに直ちに見え
るように、ウィンドウ２０１３を再描画する。
【０１６２】ウィンドウ・サービス１４０５の好ましい
実施例により、クライアント・プロセス１６１５に対
し、そのプロセス１６１５に対応するウィンドウ構造体
１９０３におけるhold２２１１を設定する方法が与えら
れる。これを行うために、クライアント・プロセス１６
１５は、保持ファイル１５０７に対しクローズ・システ
ム・コールを実行する。クローズ・システム・コールの
結果、tclunkメッセージが発生する。Ｉ／Ｏ関数２０１
９は、このtclunkメッセージに応じて、対応するウィン
ドウ構造体１９０３のhold２２１１を設定する。また、
実施例により、リードまたはライト処理が無意味である
ようなファイルに対し、それらの処理がどのように扱わ
れるかの例も提供される。すなわち、Ｉ／Ｏ関数２０１
９は、hold１５０７を指定するtreadメッセージを受信
すると、返されるデータの長さが０であるようなrread
メッセージを返す。同様に、Ｉ／Ｏ関数２０１９は、前
記のファイルに対するtwriteメッセージを受信すると、
書き込まれるデータの長さが０であるようなrwriteメッ
セージを返す。
【０１６３】ＣＰＵコマンドの実施：図２４〜２６ 図７において、プラン９のオペレーティングシステム
は、Gnot端末７１１の他に高性能ＣＰＵ７０３およびフ
ァイルサーバ７０５を含む分散型システム７０１におい
て実施されている。Gnot端末７１１内部のプロセッサ上
ではいかなるプログラムを実行してもよいが、Gnotプロ
セッサは、エディタまたはデバッガなどの対話型プログ
ラムを実行させるように使用し、高性能ＣＰＵ７０３
は、コンパイラまたはデータ・ベース・システムなどの
処理集約型のプログラムの実行に使用する方が概して効
率的である。そのために、シェルを走らせているGnot端
末７１１のユーザは、CPUコマンドを使用する。
【０１６４】CPUコマンドは、オプションの引数として
ＣＰＵ７０３の名前を取る。引数が与えられない場合
は、デフォルトのＣＰＵ７０３が選ばれる。タイプする
かマウスによって選択することによって、CPUコマンド
が入力されると、そのCPUコマンドが入力されたウィン
ドウが、CPUコマンドにおいて選択されたＣＰＵ７０３
で走っているプロセス１０２に対するウィンドウとな
る。プロセス１０２は、シェル・プログラムを実行して
いるので、ユーザは、そのＣＰＵ７０３において、単に
プログラム名をシェルに指定するだけで、他のプログラ
ムを実行することができる。CPUコマンドが実施される
様式の重要な意義は、ＣＰＵ７０３上を走行中のプロセ
ス１０２が、Gnot７１１上のCPUコマンドを実行したプ
ロセス１０２の名前空間１１５とほぼ同じ名前空間１１
５を有する点にある。所与のパス名は、Gnot７１１上を
走っているプロセス１０２においてそうであるように、
ＣＰＵ７０３上を走っているプロセス１０２における同
じファイルへと分析される。異なるのは、位置の変更に
よって必要になるものだけである。例えば、プロセス・
サービスにおけるファイルは、Gnot７１１上の情報では
なく、ＣＰＵ７０３上の情報を含む。
【０１６５】図２４に、CPUコマンドの実行の前と後に
おけるシステム７０１の構成要素の間の関係の概略を示
す。２４０１と記した図の部分は、実行前の関係を示
す。ＣＰＵ２４０３(a)（これは、Gnot７１１のＣＰＵ
でもよい）は、ユーザ・プロセス２４０５(a)を走らせ
ている。ファイルシステム１０９(a)によって、ユーザ
・プロセス２４０５(a)は、ネットワーク７１３、７１
５および７０９からなるネットワーク２４０９を介し
て、ファイル・サービス７０５の１つであるファイル・
サービス２４１１のファイルに対し、読み書きを行って
いる。また、ユーザ・プロセス２４０５(a)は、ファイ
ルシステム１０９(a)を用いて、ウィンドウ・サービス
１４０５によって与えられるファイルに対する処理を行
っていて、これによって、ディスプレイ、キーボード、
およびマウス２４０７(a)（この場合、Gnot７１１のデ
ィスプレイ、キーボード、およびマウス）を制御してい
る。ＣＰＵ７０３の１つであるＣＰＵ２４０３(b)は、
ユーザ・プロセス２４０５(a)とシステムの他の構成要
素との間の相互作用に関するものは何も持っていない。
【０１６６】ユーザ・プロセス２４０５(a)は、CPUコマ
ンドを受信する時点で、シェル・プログラムを走らせて
いる。このCPUコマンドに応じて、シェル・プログラム
は、名前空間も含めてユーザ・プロセス２４０５(a)と
同じ環境を有する子プロセスを生成し、他のプロセスが
終了するまで、それ自体停止する。さらに詳細に後述す
るように、子プロセスは、CPUサービス（CPUS）２４１
３を設定する。CPUサービス２４１３が、メッセージを
プロセッサ２４０３(b)に送ると、結果として、プロセ
ッサ２４０３(b)にプロセス２４０５(b)が生成される。
このように、CPUコマンドの実行後、ユーザ・プロセス
２４０５(a)は、ＣＰＵ２４０３(a)での走行を止めてお
り、ユーザ・プロセス２４０５(b)が、プロセッサ２４
０３(b)上で走っている。ユーザ・プロセス２４０５(b)
は、ファイル・サービス１０９(b)によって、ファイル
を読み書きしている。ユーザ・プロセス２４０５(b)
は、ユーザ・プロセス２４０５(a)が持つものとほぼ同
じ名前空間１１５を有するので、読み書きされているフ
ァイルは、ファイル・サービス２４１１によって与えら
れるファイルおよびＣＰＵ２４０３(a)上で実行したサ
ービス１２３によって与えられるファイルである。勿
論、これらのファイルには、ウィンドウ・サービス１４
０５によって与えられるファイルも含まれる。ＣＰＵ２
４０３(a)上に配置されたサービス１２３によって与え
られるファイルに対する処理は、ＣＰＵサービス２４１
３によって扱われる。ユーザ・プロセス２４０５(b)
が、ＣＰＵ２４０３(a)上のサービスによって与えられ
るファイルに対する処理を指定すると、ファイルシステ
ム１０９(b)により、ネットワーク２４０９を介してCPU
サービス２４１３に行く往信メッセージへと変換され
る。ここで、CPUサービス２４１３は、ＣＰＵ２４０３
(a)においてそのファイルに対し往信メッセージで指定
された処理をファイルシステム１０９(a)を用いて実行
し、その結果を返信メッセージによって返す。従って、
ユーザ・プロセス２４０５(b)の観点からすれば、CPUサ
ービス２４１３は、ユーザ・プロセス２４０５(a)の名
前空間１１５からユーザ・プロセス２４０５(b)にファ
イルを与えるサービスである。
【０１６７】CPUサービス２４１３の実施：図２５およ
び２６ 図２４１３に、CPUサービス２４１３の好ましい実施例
の概要を示す。ウィンドウ・サービス１４０５に加え、
CPUサービス２４１３により、プラン９のサービス１２
３の簡潔性、柔軟性および能力が例示される。CPUサー
ビス２４１３は、多数の成分プロセス１０２を有する。
成分プロセスの名前空間１１５には、ユーザ・プロセス
２４０５の名前空間１１５のコピーも含まれる。通信プ
ロセスは、ファイルシステム１０９(b)からＣＰＵパイ
プ２５０１を介して往信メッセージを受信して、そのメ
ッセージをサービス・パイプ（SERVP）２５０５に書き
込む。マルチプレクサ・プロセス（ＭＰＸ）２５０７
は、サービス・パイプ２５０５を読み、往信メッセージ
に応じて、CPUサービスのファイルシステム２５２３に
あるファイルに対して処理を行う。ファイルシステム２
５２３には、ユーザ・プロセス２４０５(b)がプロセッ
サ２４０３(b)に置かれたサービス１２３において開い
た各ファイル２５１３に対応するサービス・ファイル２
５２１がある。処理の結果発生する返信メッセージは、
ＣＰＵパイプ２５０１を介してファイルシステム１０９
(b)に返される。
【０１６８】オープン・ファイル２５１３へのファイル
・アクセス処理は、オープン・ファイル・プロセス２５
１１によって行われる。各オープン・ファイル２５１３
に対しオープン・ファイル・プロセス２５１１がある；
オープン・ファイル・プロセス２５１１は、それがその
ファイルに関するファイル・アクセス往信メッセージを
マルチプレクサ・プロセス２５０７から受信する手段で
あるような別個のパイプ２５０９を有し、さらに各プロ
セス２５１１は、サービス・パイプ２５０５に接続され
ている。各プロセス２５１１は、さらにそのデータの一
部として、そのオープン・ファイル２５１３に対するフ
ァイル記述子２５１７を有する。マルチプレクサ２５０
７からのファイル・アクセス往信メッセージに応じて、
ファイル記述子２５１７を用いて、そのオープン・ファ
イル２５１３に対するアクセス処理を行った後、プロセ
ス２５１１は、往信メッセージの結果をオープン・ファ
イル・プロセス２５１１からの返信メッセージとして、
サービス・パイプ２５０５に書き込む。マルチプレクサ
・プロセス２５０７は、その往信メッセージに応じて、
単にそれをＣＰＵパイプ２５０１に書き込む。さらに詳
細に後述するように、その処理を実行するために各プロ
セス２５１１および２５０７によって必要とされる情報
は、プロセス２５１１の各々に対するサービス・データ
構造体（ＳＲＶＤ）２５１９およびマルチプレクサ・プ
ロセス２５２５に対するサービス・データ構造体２５１
５に収容される。
【０１６９】図２６に、サービス・データ構造体２６２
３、およびCPUサービス・ファイルシステム２５２３に
おけるファイルを表すのに使用されるデータ構造体を詳
細に示す。まず、サービス・データ構造体２６２３であ
るが、フィールド２６２５は、サービス・データ構造体
２６２３が属するプロセスがファイル処理を実行するた
めに用いるプロシージャへのポインタから成る。MPX SR
Vデータ２５２５の場合、サービス・ファイル要求の各
々にプロシージャがある。リードおよびライト以外のす
べての要求に対するプロシージャは、ファイルシステム
２５２３に対する処理を行う。リードおよびライトに対
するプロシージャは、ファイルのオープン・ファイル・
プロセス２５１１に対するパイプ２５０９にライト処理
を行うことによって、リードまたはライトされているフ
ァイル２５１３に対応するオープン・ファイル・プロセ
ス２５１１に処理を渡す。オープン・ファイルSRVデー
タ２５１９の場合、リードおよびライト処理に対するプ
ロシージャしかなく、これらのプロシージャは、単に、
オープン・ファイル・プロセス２５１１に対するＦＤ２
５１７によって指定されたファイルに適切な処理を行
い、応答として受信した返信メッセージをサービス・パ
イプ２５０５に書き込むだけである。
【０１７０】SRVD２６２３のその他の内容は、次のとお
りである。RFD２６２７：SRVD２６２３が属するプロセ
スがメッセージを読むために使用するファイル記述子。
WFD２６２９：メッセージを書くために使用されるファ
イル記述子。DSIZE２６３１：DATA２６３７の大きさ。t
hdr２６３３：往信メッセージがRFD２６２７に基づきプ
ロセスによって読まれたときの往信メッセージのヘッダ
を収容する。rhdr２６３３：返信メッセージがWFD２６
２９に基づいてプロセスによって書かれたときの返信メ
ッセージのヘッダを収容する。DATA２６３７：往信メッ
セージまたは返信メッセージのデータを収容する。
【０１７１】MPX SRVD２５１５においては、WFD２６２
９は、MPX２５０７によって読まれるメッセージが書き
込まれる先のサービス・パイプ２５０５におけるファイ
ルのファイル記述子であり（すなわち、MPX２５０７は
メッセージをそれ自体に書く）、WFD２６２９は無効で
ある。OF SRVD２５２９においては、RFD２６２７は、オ
ープン・ファイル・プロセス２５１１がメッセージを読
む読出し元のパイプ２５０９におけるファイルのファイ
ル記述子であり、WFD２６２９は、オープン・ファイル
・プロセス２５１１がメッセージを書き込む先のサービ
ス・パイプ２５０５におけるファイルのファイル記述子
である。
【０１７２】続いて、CPUサービス・ファイルシステム
２５２３に付いてであるが、このファイルシステムは、
図２６の２５２３に示したデータ構造体を用いて実施さ
れる。CPUサービス２４１３によって与えられる各CPUサ
ービス・ファイル２５２１(i)は、ＣＰＵ２４０３(a)上
で実行中のサービスによってプロセッサ２４０３(b)上
で動作中のユーザ・プロセス２４０５(b)に与えられる
ファイル２５１３(i)に対応する。各CPUサービス・ファ
イル２５２１(i)は、ファイル・ポインタ配列（FPA）２
６０３内にエントリを有する。各エントリ２６０５(i)
は、ファイル２５１３(i)に関する往信メッセージ要求
処理においてファイルシステム１０９によって与えられ
るfid３３１によってインデックスが与えられる。この
エントリにおけるフィールドは、次のとおりである。FP
２６０７：ファイル・エントリ２６１５へのポインタで
あり、エントリ２６１５は、サービス・ファイル２５２
１に対応するオープン・ファイル２５１３(i)に関する
情報からなる。FD２６０９：オープン・ファイル２５１
３(i)のファイル記述子。OFPPID２６１１：オープン・
ファイル２５１３(i)およびサービス・ファイル２５２
１(i)に対応するオープン・ファイル・プロセス２５１
１(i)に対するプロセス識別子。最後に、オープン・フ
ァイル・プロセス・パイプ（OFPP）２６１３：パイプ２
５０９(i)に対するファイル記述子の配列。ファイル・
エントリ２６１５は、オープン・ファイル２５１３(i)
に関する情報を収容する。この情報は、ファイル２５１
３(i)の所在を特定するファイルシステム１０９からのw
alk要求の過程で得られる。FNAMEP２６１７は、ファイ
ル２５１３(i)のパス名である文字列FNAME２６９１への
ポインタである。QID３２３、DEV３１５、およびTYPE３
１３は、ファイル２５１３(i)に対するチャネル３０１
からの対応する値である。REF２６２１は、ファイル・
エントリ２６１５が再利用可能かどうかを示す参照カウ
ンタである。実施例において、ファイル・ポインタ配列
２６０３、およびファイル・エントリ２６１５の配列
は、CPUサービス２４１３が処理を開始したときに生成
される。
【０１７３】ＣＰＵサービス２４１３の動作 CPUサービス２４１３の処理の例を、attach、walk、ope
n、およびclunkの各要求によって与えられる。attach要
求により、サービス１２３によって与えられるファイル
木構造が、そのattach要求をしているプロセス１０２に
利用できるようになる。attach要求に対する往信メッセ
ージには、アタッチされているサービス１２３のルート
に対するfid３３１が含まれる。attachが成功ならば、
返信メッセージには、そのルートに対するqid３２３お
よびfid３３１が含まれる。CPUサービス２４１３の場
合、このサービスによって与えられるファイル木構造
は、ユーザ・プロセス２４０５(a)に属するファイル木
構造である。MPXプロセス２５０７は、往信メッセージ
を受信すると、MPXプロセス２５０７のMPX SRVD２５１
５において指定されるattach関数を呼び出す。この関数
は、fid３３１に対応するFPACE２６０３を生成する。FP
ACE２６０３において、フィールド２６０９、２６１
１、および２６１３は、すべて、空値を有する。次に、
attach関数が、ルート「／」に関するstat要求をする
と、これにより、ユーザ・プロセス２４０５の名前空間
１１５のqid３２３が返される。ここで、この関数は、
ファイル・エントリ２６１５を生成し、「／」をファイ
ル名２６１９に、qidをqid３２３にそれぞれ配置し、参
照カウントを１に設定する。その後、SRVD２５２５のth
dr２６３３にあるqid３２３をルートのqid３２３に設定
する。最後に、関数「srveply」を呼び出すと、これ
が、qidが入った返信メッセージを生成して、これをサ
ービス・パイプ２５０５に書き込む。MPXプロセス２５
０７は、この返信メッセージを受信すると、それをcpu
パイプ２５０１に書く。
【０１７４】walk要求の往信メッセージには、ディレク
トリに対するqid３２３に関係付けられたfid３３１およ
びそのディレクトリ内のファイルの名前が含まれる。wa
lkが、成功した場合、fid３３１は、提示されたファイ
ルに関係付けられ、さらに提案されたファイルに対する
qid３２３が、fid３３１と共に返信メッセージで返され
る。MPXプロセス２５０７は、walk往信メッセージを受
信すると、SRVD２５１５において指定されるwalk関数を
呼び出す。walk関数は、fid３１１に対応するFPAE２６
０５の所在を特定し、さらにFPAE２６０５のファイル・
エントリ２６１５の所在を特定する。次に、往信メッセ
ージにおける名前によって指定されたファイルのパス名
を生成するために、その指定されたファイルの名前をFN
AME２６１９に入っているパス名に追加する。そのうえ
で、stat要求を行って、そのパス名で指定されるファイ
ルの状態情報を得る。次に、REF２６２１が実行され
る。REF２６２１が、値１を有する場合、提示されたフ
ァイルに対して、ファイル・エントリ２６１５を使用す
ることができる。この場合、stat要求によって獲得した
qid、dev、およびtypeの値が、ファイル・エントリ２６
１５のフィールド３２３、３１５および３１３に書き込
まれ、FNAME２６１９が、そのファイルのパス名に設定
され、さらにMPX SRVD２５１５のthdr２６３３における
３２３が、そのファイルの対するqidに設定される。REF
２６２１が、１を越える値を有する場合、新たなファイ
ル・エントリ２６１５が割り当てられ、そのフィールド
およびthdr２６３３が、前記のように設定され、さらに
FP２６０７が、新たなファイル・エントリ２６１５を示
すように設定される。そのうえで、返信メッセージが、
fid３３１およびqid３２３と共に返される。
【０１７５】open要求の往信メッセージには、開かれる
ファイルのfid３３１および開かれたファイルのモード
を示す値が含まれる。返信メッセージには、開かれたフ
ァイルのfid３３１およびqid３２３が含まれる。open関
数は、open往信メッセージに応じてMPXプロセス２５０
７によって実行され、fid３３１を用いて適切なファイ
ル・ポインタ配列エントリ（FPAE）２６０５の所在を特
定し、FPAE２６０５に対するファイル・エントリ２６１
５の所在を特定し、さらにFNAME２６１９にあるパス名
およびモードの値を用いてopenシステム・コールを行
う。このコールは、そのファイルのファイル記述子を返
す。次に、そのオープン・ファイルに対しパイプ２５０
９が生成される。そのオープン・ファイルのファイル記
述子が、FPAE２６０５のFDフィールド２６０９に置か
れ、さらにパイプ２５０９に対するファイル記述子が、
オープン・ファイル・プロセス・パイプ（OFPP）２６１
３に置かれる。次に、開かれたファイルに対応するオー
プン・ファイル・プロセス２５１１が、生成され、さら
にそのSERVD２５１９構造体が、オープン・ファイル・
プロセスがパイプ２５０９から読み出し、サービス・パ
イプ２５０５に書き込むように、設定される。オープン
・ファイル・プロセスのプロセス識別子が、オープン・
ファイル・プロセスpidフィールド（OFPPID）２６１１
に置かれる。このうえで、thdr２６３３のqidフィール
ドが、ファイル・エントリ２６１５から設定され、その
fidおよびqidが、返信メッセージに入れられて返され
る。
【０１７６】clunk要求により、サービス１２３は、fid
３３１とqid３２３との間の関係付けを止めるように要
求される。この要求の往信メッセージには、fid３３１
が含まれる。返信メッセージは、単にそのfidを返す。c
lunk関数は、マルチプレクサ・プロセスによって実行さ
れ、fid３３１を用いて、適切なFPAE２６０５の所在を
特定する。そのエントリを見つけると、フィールドOFPP
ID２６１１において指定されるオープン・ファイル・プ
ロセス２５１１を終了させ、オープン・ファイル・プロ
セス２５１１が読み出していたパイプ２５０９にあるフ
ァイルをクローズし、フィールドFD２６０９にあるファ
イル記述子によって指定されるオープン・ファイルをク
ローズし、さらにフィールド２６０９、２６１１および
２６１３を、そのファイルが使用されていないことを示
すように設定する。次に、ファイル・エントリ２６１５
のREF２６２１をデクリメントし、デクリメントされた
フィールドが値０を有するならば、FNAME２６１９を解
放し、さらにFPAE２６０５のファイル・ポインタ２６０
７を０に設定する。最後に、fid３３１と共に返信メッ
セージを返す。
【０１７７】ＣＰＵサービス２４１３とユーザ・プロセ
ス２４０５(b)との接続 ユーザ・プロセス２４０５(a)が、シェル・コマンドを
実行すると、そのユーザ・プロセス２４０５(a)と同じ
名前空間を有する子プロセス１０２が生成される。生成
された子プロセス１０２は、最初に、カーネル環境サー
ビスによって与えられるファイル木構造にある「cpudi
r」と称するファイルを生成し、その現在のワーキング
・ディレクトリ（これは、ユーザ・プロセス２４０５
(a)のそれである）の名前をそのファイルに書き込む。
次に、このプロセスは、ダイヤル関数においてCPUコマ
ンドで指定されたＣＰＵ７０３の名前を使用する。ダイ
ヤル関数は、ユーザ・プロセス２４０５(a)（これも、
子プロセスを使用する）のユーザを求めてネットワーク
２４０９経由で指定されたＣＰＵ７０３を呼び出し、こ
の呼び出しの終了と同時に、指定されたＣＰＵ７０３
（図２４では、ＣＰＵ２４０３(b)と示した）への接続
を与える。このうえで、サービス・パイプ２５０５、お
よびCPUサービス・ファイルシステム２５２３に対する
データ構造体が、生成される。最後に、通信プロセス
が、生成され、かつそのネットワーク接続に対するファ
イル記述子に接続され、さらにマルチプレクサ・プロセ
ス２５０７が、生成され、かつサービス・パイプ２５０
５およびCPUパイプ２５０１に接続される。勿論、通信
サービス２５０３は、CPUパイプ２５０１についてリー
ドを行うので、この時点で、CPUサービス２４１３は、
ユーザ・プロセス２４０５(a)からの入力を待ってい
る。
【０１７８】ＣＰＵ２４０３(b)において、ネットワー
ク２４０９への接続を傾聴し、かつネットワーク２４０
９に接続された他のエンティティから呼をＣＰＵ２４０
３(b)が受信したときに応答するようなプロセス１０２
が存在する。そのプロセスは、子プロセス１０２を開始
することによって、ユーザ・プロセス２４０５(a)から
の呼に応答する。子プロセス１０２は、ネットワーク接
続を表すファイルのパス名を入手し、さらに引数０を付
けてforkpgrpを行って、新たな名前空間１１５を得る。
つぎに、子プロセス１０２は、/dev/userがコールを行
ったユーザの名前を収容するように、その新たな名前空
間１１５を設定し、/srv/bootを開いてデフォルト・フ
ァイル・サービス２４１１のルートへの接続に対するフ
ァイル記述子を獲得し、さらに「／」を「＃／」および
ファイル・サービス２４１１によって与えられるファイ
ル木構造のルートへと結合する。そして、子プロセス１
０２は、/dev/userにあるユーザ名を用いて子プロセス
１０２のワーキング・ディレクトリをユーザのワーキン
グ・ディレクトリとし、標準入力、標準出力、および標
準エラーを、それらがネットワーク接続へと接続される
ように、設定する。さらに、結合処理をいくつか行う。
その終了時には、/binは、ＣＰＵ２４０３(b)によって
実行できるコードを収容するディレクトリに変わり、/b
inは、シェル・プログラムのコードを収容する/lib/rc
に結合されていて、さらにカーネル・サービスは、控え
のファイル木構造６０１における適切な位置に結合され
ている。この時点で、子プロセス１０２は、分岐してユ
ーザ・プロセス２４０５(b)を生成する。このユーザ・
プロセス２４０５(b)は、子プロセス１０２の名前空間
１１５を受け継いでいる。
【０１７９】ユーザ・プロセス２４０５(b)は、ユーザ
・プロセス２４０５(b)の名前空間１１５の設定の仕上
げを行うCPUサーブと称するプログラムの名前をシェル
・プログラムに与えて、これを実行する。次に、ユーザ
・プロセス２４０５(b)が、replaceオプション付きのシ
ステム・マウント・コールを行うと、ディレクトリ「/m
nt/term」が、ネットワーク接続を表すファイル記述子
にマウントされる。/mnt/termは、キーボード、マウス
およびディスプレイがそれによって制御されるようなフ
ァイルに対して使用される、ユーザ・プロセス２４０５
(b)の名前空間におけるディレクトリである。
【０１８０】マウントの結果として、このとき「/mnt/t
erm」には、ユーザ・プロセス２４０５(a)の名前空間１
１５にあるファイルが含まれる。これらのファイルに
は、ディレクトリ/fd６０９が含まれる。このディレク
トリのファイルは、値として、ユーザ・プロセス２４０
５(a)によって現在使用されているファイル記述子を有
する。従って、ファイル/fd/0、/fd/1、および/fd/2
は、ユーザ・プロセス２４０５(a)の標準入力、標準出
力、および標準エラーに対するファイル記述子を収容す
る。ユーザ・プロセス２４０５(a)は、ウィンドウ・サ
ービス１４０５を使用中であり、そのウィンドウ・サー
ビス１４０５によって与えられるファイルconsを/dev/c
onsに結合しているので、標準入力、標準出力、および
標準エラーに対するファイル記述子は、ウィンドウ・サ
ービス１４０５によって与えられるファイルconsを指定
する。次に、ユーザ・プロセス２４０５(b)は、それ自
体の標準入力、出力、およびエラーをクローズし、それ
によってファイル記述子０、１、および２を解放し、そ
して直ちに、/fd/0、/fd/1、および/fd/2における識別
子によって指定されるファイルを開く。従って、ユーザ
・プロセス２４０５(b)における標準入力、出力、およ
びエラーに対するリードおよびライトにより、ユーザ・
プロセス２４０５(a)におけるcons---代わって、端末２
４０７(a)におけるキーボードおよびディスプレイを表
す---に対するリードおよびライトが発生する結果とな
る。
【０１８１】同様に、マウントの結果として、/mnt/ter
mは、ディレクトリ/mnt/term/envを含み、さらに、これ
が、ファイル「cpudir」を含むが、ファイルcpudirは、
ユーザ・プロセス２４０５(a)のワーキング・ディレク
トリを収容するように、ユーザ・プロセス２４０５(a)
によって設定されたものである。次に、ユーザ・プロセ
ス２４０５(b)は、/mnt/term/env/cpudirを開き、それ
を読み、さらにディレクトリ変更コマンドを指定してシ
ェルを実行する。ディレクトリ変更コマンドにおいて、
「cpudir」から読み出した値が、引数として使用され
る。その結果、ユーザ・プロセス２４０５(a)の現在の
ディレクトリにおいて、新たなシェルが走り始める。次
に、この新たなシェルは、ユーザが定義したスクリプト
を実行する。このスクリプトは、ユーザがシェルを実行
する度に走らされ、ユーザ・プロセス２４０５(b)の名
前空間をさらにユーザ向きに変更することができる。一
般に、シェル・スクリプトは、次の内容を行うシステム
結合コールの実行をもたらすシェル・コマンド含む。 bind("/mnt/term/mnt/8.5","/dev/",AFTER) bind("/mnt/term/mnt/8.5/cons","/dev/cons",REPLACE) 最初の結合コールによって、8.5にあるファイル（ウィ
ンドウ・サービス１４０５によってユーザ・プロセス２
４０５(a)に与えられるファイル）が、/devに結合さ
れ；AFTERオプションが使用されているので、そのディ
レクトリが探査される前に、以前に結合されていたすべ
てのディレクトリが、ウィンドウ・サービス１４０５に
よって与えられるファイルを求めて探査される。２番目
の結合コールによって、ウィンドウ・サービス１４０５
によって与えられるファイルconsが、/dev/consに結合
される。/dev/cons自体が、以前にカーネル・サービス
＃ｃを/devに結合した結合処理の結果である。従って、
/devは、ウィンドウ・サービス１４０５によって与えら
れるファイルconsが結合されている先のファイルであ
る。REPLACEが使用されているので、パス名/dev/cons
は、以降、ウィンドウ・サービス１４０５によってユー
ザ・プロセス２４０５(a)に与えられたファイルconsを
示すことになる。consからのリードにより、端末２４０
７(a)のキーボードにおいて入力されたデータを受信す
るようになり、一方、consへのライトにより、端末２４
０７(a)の画面上にデータを表示するようになる。
【０１８２】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例が考えられるが、それらはいずれも本発明の技
術的範囲に包含される。
【０１８３】尚、特許請求の範囲に記載した参照番号
は、発明の容易なる理解のためで、その技術的範囲を制
限するように解釈されるべきではない。
【０１８４】
【発明の効果】以上述べたように、本発明のオペレーテ
ィングシステムによれば、各プロセスが、独立した階層
（名前空間）を持ち、かつ、プロセスどうしが、異なる
プロセッサ上で実行中でも、互いに他のプロセスの名前
空間を利用することができるので、分散型システムのよ
うな大規模なシステムにおいても効率的に名前を管理す
ることができる。
【図面の簡単な説明】
【図１】本発明のオペレーティングシステムによって与
えられるプロセスごとの名前空間の概要を示す図であ
る。
【図２】本オペレーティングシステムにおけるマウント
・サービスおよびプロトコル・サービスの概要を示す図
である。
【図３】チャネル・データ構造体の線図である。
【図４】オープン・ファイルを位置づけるために使用さ
れるデータ構造体の線図である。
【図５】プロトコル・サービスとの間でプロトコルの受
け渡しに使用されるデータ構造体の線図である。
【図６】ルート・サービスによって与えられるファイル
木構造およびある結合操作、およびマウント操作が行わ
れた後のファイル木構造の線図である。
【図７】本発明のオペレーティングシステムが実施され
る分散システムの線図である。
【図８】本発明のマウント・テーブルの線図である。
【図９】図６の第２のファイル構造に対するマウント・
テーブルの線図である。
【図１０】１０Ａおよび１０Ｂは、好ましい実施例にお
けるnamec関数の流れ図である。
【図１１】１１Ａおよび１１Ｂは、好ましい実施例にお
けるwalk関数の流れ図である。
【図１２】１２Ａおよび１２Ｂは、好ましい実施例にお
けるmount関数の流れ図である。
【図１３】好ましい実施例においてプロトコル・サービ
スを登録するために使用されるデータ構造体の線図であ
る。
【図１４】本発明のオペレーティングシステムと共に用
いられるウィンドウ・サービスの概要を示す図である。
【図１５】ウィンドウ・サービスによって与えられるフ
ァイル木構造の線図である。
【図１６】ウィンドウ・サービスの構造の概要を示す図
である。
【図１７】ウィンドウ・サービスにおいて実行されるmk
slave関数の流れ図である。
【図１８】ウィンドウ・サービスによって与えられるフ
ァイル木構造の実施例の線図である。
【図１９】ウィンドウサービスで利用されるウィンドウ
・データ構造体の線図である。
【図２０】ウィンドウ・サービスの一部の内部構造の線
図である。
【図２１】ウィンドウ・サービスにおいて実行されるsp
awn関数の流れ図である。
【図２２】保持モードの好ましい実施例にとって重要な
ウィンドウ・データ構造体のある部分の線図である。
【図２３】好ましい実施例において保持モードに対して
行われた処理のある部分の流れ図である。
【図２４】ＣＰＵコマンドの作用の概要を示す図であ
る。
【図２５】ＣＰＵサービスの内部データ構造体を示す線
図である。
【図２６】ＣＰＵサービスによって用いられるデータ構
造体を示す線図である。
【符号の説明】
１０１ サービスのアーキテクチャ １０２ プロセス １０３ プロセス・グループ １１３ ファイル・ロケータ関数 １１１ ファイル・アクセス関数 １１５ 名前空間 １１７、１２５ ファイル木構造 １２３ サービス １２７、１２９ ルート・ディレクトリ・ファイル １３１ データ・ファイル
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ケニス エル．トンプソン アメリカ合衆国 07023 ニュージャー ジィ、ワッチャング、リッジ ロード 336 (56)参考文献 ＵＫＵＵＧ，ＵＮＩＸ−ＴＨＥ ＬＥ ＧＥＮＤ ＥＶＯＬＶＥＳ ＰＲＯＣＥ ＥＤＩＮＧＳ ＯＦ ＴＨＥ ＳＵＭＭ ＥＲ 1990 ＵＫＵＵＧ ＣＯＮＦＥＲ ＥＮＣＥ：Ｒｏｂ Ｐｉｋｅ Ｄａｖｅ Ｐｒｅｓｏｔｔｏ，Ｋｅｎ Ｔｏｍｐ ｓｏｎ，Ｈｏｗａｒｄ Ｔｒｋｋｅｙ ”Ｐｌａｎ９ ｆｒｏｍ Ｂｅｌｌ Ｌａｂｓ"

Claims (21)

    (57)【特許請求の範囲】
  1. 【請求項１】 マルチプロセスオペレーティングシステ
    ムを実行するコンピュータシステムにおいて、該マルチ
    プロセスオペレーティングシステムは、プログラムを実
    行する複数のプロセスと一つ以上の名前空間とを作成
    し、各プロセスはそれぞれ一つの現在の名前空間に対応
    し、一つのプロセスに対応する名前空間はプログラムを
    実行する際に該一つのプロセスがプログラムの実行時に
    参照可能な前記コンピュータシステム内のエンティティ
    の名前の集合であり、前記コンピュータシステムは、 任意のプロセスが該プロセスの現在の名前空間とは異な
    る新しい名前空間を作成して現在の名前空間と置換する
    ためにプログラムの実行時に使用可能な新名前空間作成
    手段を前記オペレーティングシステム内に有することを
    特徴とするコンピュータシステム。
  2. 【請求項２】 前記新しい名前空間内の名前の集合が名
    前からなる単一の木構造に編成されることを特徴とする
    請求項１のシステム。
  3. 【請求項３】 任意のプロセスが該プロセスの現在の名
    前空間内の任意の名前と現在の名前空間内の別の名前と
    の結合を変更するためにプログラムの実行時に使用可能
    な現名前空間変更手段をさらに有することを特徴とする
    請求項１のシステム。
  4. 【請求項４】 前記マルチプロセスオペレーティングシ
    ステムは、プログラムを実行しているプロセスが前記現
    名前空間変更手段を使用しているときには特殊モードに
    入らないことを特徴とする請求項３のシステム。
  5. 【請求項５】 前記現名前空間変更手段は、名前空間内
    の第１名前をエンティティの名前の集合に関連づけるこ
    とにより該第１名前の結合を変更することを特徴とする
    請求項３のシステム。
  6. 【請求項６】 前記第１名前に関連づけられている名前
    の集合は名前空間内に既に存在する名前の集合であるこ
    とを特徴とする請求項５のシステム。
  7. 【請求項７】 前記現名前空間変更手段は、前記第１名
    前をエンティティの名前の別の集合に関連づけることに
    より該第１名前の結合を変更することを特徴とする請求
    項５のシステム。
  8. 【請求項８】 前記現名前空間変更手段が前記第１名前
    を前記別の集合に関連づける場合、前記第１名前に現在
    関連づけられている名前の集合を前記別の集合で置き換
    えるか、または、前記別の集合を前記第１名前に現在関
    連づけられている名前の集合と結合することを特徴とす
    る請求項７のシステム。
  9. 【請求項９】 前記現名前空間変更手段が前記別の集合
    を前記第１名前に現在関連づけられている名前の集合と
    結合する場合、前記現名前空間変更手段は、前記第１名
    前に現在関連づけられている名前が前記別の集合内の名
    前に対してどのように並べられるべきかに関する、プロ
    グラムを実行中のプロセスによる指定に応答して、該指
    定に従って名前を並べることを特徴とする請求項８のシ
    ステム。
  10. 【請求項１０】 前記第１名前に現在関連づけられてい
    る名前の集合は前記現在の名前空間に付加されることを
    特徴とする請求項７のシステム。
  11. 【請求項１１】 名前の集合は木構造を有し、前記現名
    前空間変更手段は前記第１名前を該木構造のルートに関
    連づけることを特徴とする請求項１０のシステム。
  12. 【請求項１２】 名前の集合を提供し、該名前の集合に
    よって表されるエンティティの集合に対する操作を実行
    するサービス手段を前記オペレーティングシステム内に
    さらに有することを特徴とする請求項１０のシステム。
  13. 【請求項１３】 前記サービス手段によって提供される
    名前の集合によって表されるエンティティの集合は、該
    名前の集合を自己の名前空間に付加する各プロセスごと
    に固有のものであることを特徴とする請求項１２のシス
    テム。
  14. 【請求項１４】 前記サービス手段は複数のサービス手
    段のうちの一つであり、 各サービス手段は、該サービス手段によって提供される
    名前の集合によって表されるエンティティを制御するた
    めに同一の操作の集合を使用することを特徴とする請求
    項１２のシステム。
  15. 【請求項１５】 前記複数のサービス手段のうちのいく
    つかはプロトコルサービス手段であり、 プロセスとプロトコルサービス手段の間の通信は、すべ
    てのプロトコルサービス手段に対して同一のプロトコル
    によることを特徴とする請求項１４のシステム。
  16. 【請求項１６】 前記コンピュータシステムは、通信手
    段によって接続されたコンポーネントを含む分散コンピ
    ューティングシステムで動作し、 プロトコルサービス手段のうちのいくつかは、前記プロ
    セスを実行中のコンポーネントとは異なるリモートコン
    ポーネント上に位置し、 前記プロセスと、前記リモートコンポーネント上に位置
    するプロトコルサービス手段の間の通信は前記通信手段
    によることを特徴とする請求項１５のシステム。
  17. 【請求項１７】 前記新しい名前空間内の名前の集合が
    名前からなる単一の木構造に編成されることを特徴とす
    る請求項３のシステム。
  18. 【請求項１８】 前記オペレーティングシステムは、ス
    タブ木構造として編成されたあらかじめ定義された名前
    の集合を前記現名前空間変更手段に提供し、前記現名前
    空間変更手段は該スタブ木構造を前記単一の木構造のル
    ートに結合することを特徴とする請求項１７のシステ
    ム。
  19. 【請求項１９】 前記新名前空間作成手段を使用する際
    に、プログラムを実行中のプロセスは、前記新名前空間
    作成手段が該プロセスの現在の名前空間からの名前を含
    む新しい名前空間を作成することまたは空の新しい名前
    空間を作成することを指定し、前記新名前空間作成手段
    が該プロセスによって指定されたように応答することを
    特徴とする請求項１のシステム。
  20. 【請求項２０】 前記オペレーティングシステムは、プ
    ロセスがプログラムの実行時に使用可能な、エンティテ
    ィをプロセスからアクセス可能にする手段をさらに有
    し、 一つのエンティティがプロセスからのアクセス可能性を
    獲得した場合、該アクセス可能性は該プロセスの新しい
    名前空間の作成によっては影響を受けないことを特徴と
    する請求項１のシステム。
  21. 【請求項２１】 ファイル名を有し、該ファイル名を有
    するファイルに対する操作に応答してサービス手段によ
    って制御されるエンティティを表すファイルの集合を提
    供する一つ以上のサービス手段と、 プロセスの名前空間内の名前を有するファイルを該プロ
    セスからアクセス可能にし、アクセス可能なファイルに
    対する操作を実行する、プロセスからアクセス可能なフ
    ァイル操作手段と、 ファイル名を名前空間内の名前に関連づけることによっ
    て該名前の結合を変更する現名前空間変更手段とをさら
    に有することを特徴とする請求項１のシステム。
JP3196061A 1990-07-11 1991-07-11 コンピュータシステム Expired - Fee Related JP2724256B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US55121890A 1990-07-11 1990-07-11
US551218 1990-07-11
US70265191A 1991-05-17 1991-05-17
US702651 1991-05-17

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP9221547A Division JPH10124376A (ja) 1990-07-11 1997-08-18 コンピュータシステムでキャラクタコード列からなる入力を変換して出力する方法

Publications (2)

Publication Number Publication Date
JPH04233654A JPH04233654A (ja) 1992-08-21
JP2724256B2 true JP2724256B2 (ja) 1998-03-09

Family

ID=27069681

Family Applications (2)

Application Number Title Priority Date Filing Date
JP3196061A Expired - Fee Related JP2724256B2 (ja) 1990-07-11 1991-07-11 コンピュータシステム
JP9221547A Pending JPH10124376A (ja) 1990-07-11 1997-08-18 コンピュータシステムでキャラクタコード列からなる入力を変換して出力する方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP9221547A Pending JPH10124376A (ja) 1990-07-11 1997-08-18 コンピュータシステムでキャラクタコード列からなる入力を変換して出力する方法

Country Status (7)

Country Link
US (1) US5623666A (ja)
EP (1) EP0466486B1 (ja)
JP (2) JP2724256B2 (ja)
AU (1) AU649455B2 (ja)
CA (1) CA2046723C (ja)
DE (1) DE69129479T2 (ja)
ES (1) ES2116276T3 (ja)

Families Citing this family (145)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5826017A (en) * 1992-02-10 1998-10-20 Lucent Technologies Apparatus and method for communicating data between elements of a distributed system using a general protocol
CA2110243C (en) * 1992-12-31 1998-08-11 Philip Steven Winterbottom Apparatus and methods for making a portion of a first name space available as a portion of a second name space
CA2121612A1 (en) * 1993-05-21 1994-11-22 Chung-Hwa Herman Rao Methods and apparatus for making and using distributed applications
US7174352B2 (en) * 1993-06-03 2007-02-06 Network Appliance, Inc. File system image transfer
US5963962A (en) * 1995-05-31 1999-10-05 Network Appliance, Inc. Write anywhere file-system layout
US6138126A (en) * 1995-05-31 2000-10-24 Network Appliance, Inc. Method for allocating files in a file system integrated with a raid disk sub-system
JP3541039B2 (ja) * 1993-08-03 2004-07-07 サン・マイクロシステムズ，インコーポレイテッド コンピュータアプリケーションのためのフレキシブル多重プラットフォームパーティショニング
FR2715486B1 (fr) * 1994-01-21 1996-03-29 Alain Nicolas Piaton Procédé de comparaison de fichiers informatiques.
US6418484B1 (en) * 1994-06-17 2002-07-09 Sun Microsystems, Inc. Method of remotely executing computer processes
US7424731B1 (en) 1994-10-12 2008-09-09 Touchtunes Music Corporation Home digital audiovisual information recording and playback system
US8661477B2 (en) 1994-10-12 2014-02-25 Touchtunes Music Corporation System for distributing and selecting audio and video information and method implemented by said system
WO1996012255A1 (fr) 1994-10-12 1996-04-25 Technical Maintenance Corporation Systeme de reproduction audio-visuelle numerique intelligent
US7188352B2 (en) * 1995-07-11 2007-03-06 Touchtunes Music Corporation Intelligent digital audiovisual playback system
US5724512A (en) * 1995-04-17 1998-03-03 Lucent Technologies Inc. Methods and apparatus for storage and retrieval of name space information in a distributed computing system
JP3335801B2 (ja) * 1995-07-05 2002-10-21 株式会社日立製作所 異種ファイルへのアクセスを可能とする情報処理システム及びその制御方法
US6487580B1 (en) * 1995-09-25 2002-11-26 International Business Machines Corporation Method and system for managing concurrently executable computer processes
JP3738787B2 (ja) * 1995-10-19 2006-01-25 富士ゼロックス株式会社 資源管理装置及び資源管理方法
US5941943A (en) * 1996-06-17 1999-08-24 International Business Machines Corporation Apparatus and a method for creating isolated sub-environments using host names and aliases
US5805786A (en) * 1996-07-23 1998-09-08 International Business Machines Corporation Recovery of a name server managing membership of a domain of processors in a distributed computing environment
FR2753868A1 (fr) 1996-09-25 1998-03-27 Technical Maintenance Corp Procede de selection d'un enregistrement sur un systeme numerique de reproduction audiovisuel et systeme pour mise en oeuvre du procede
US5909542A (en) * 1996-11-20 1999-06-01 Cfi Proservices, Inc. Distributed computing system for executing intercommunicating applications programs
JPH10240603A (ja) * 1997-02-27 1998-09-11 Fuji Xerox Co Ltd ファイル管理装置及びファイル転送方法
US6678724B2 (en) * 1997-03-12 2004-01-13 Microsoft Corporation Common namespace for internet and local filesystem objects
US5946685A (en) * 1997-06-27 1999-08-31 Sun Microsystems, Inc. Global mount mechanism used in maintaining a global name space utilizing a distributed locking mechanism
US6044465A (en) * 1997-07-07 2000-03-28 International Business Machines Corporation User profile storage on and retrieval from a non-native server domain for use in a client running a native operating system
US7574727B2 (en) 1997-07-23 2009-08-11 Touchtunes Music Corporation Intelligent digital audiovisual playback system
FR2769165B1 (fr) 1997-09-26 2002-11-29 Technical Maintenance Corp Systeme sans fil a transmission numerique pour haut-parleurs
US6173293B1 (en) * 1998-03-13 2001-01-09 Digital Equipment Corporation Scalable distributed file system
US6654881B2 (en) * 1998-06-12 2003-11-25 Microsoft Corporation Logical volume mount manager
US6119131A (en) * 1998-06-12 2000-09-12 Microsoft Corporation Persistent volume mount points
US6496839B2 (en) 1998-06-12 2002-12-17 Microsoft Corporation Persistent names for logical volumes
US6487577B1 (en) * 1998-06-29 2002-11-26 Intel Corporation Distributed compiling
FR2781582B1 (fr) 1998-07-21 2001-01-12 Technical Maintenance Corp Systeme de telechargement d'objets ou de fichiers pour mise a jour de logiciels
US8028318B2 (en) 1999-07-21 2011-09-27 Touchtunes Music Corporation Remote control unit for activating and deactivating means for payment and for displaying payment status
FR2781591B1 (fr) * 1998-07-22 2000-09-22 Technical Maintenance Corp Systeme de reproduction audiovisuelle
FR2781593B1 (fr) 1998-07-22 2001-01-12 Technical Maintenance Corp Telecommande pour systeme de reproduction audiovisuelle numerique intelligent
FR2781580B1 (fr) 1998-07-22 2000-09-22 Technical Maintenance Corp Circuit de commande de son pour systeme de reproduction audiovisuelle numerique intelligent
US6219028B1 (en) * 1998-08-19 2001-04-17 Adobe Systems Incorporated Removing a cursor from over new content
US6467050B1 (en) 1998-09-14 2002-10-15 International Business Machines Corporation Method and apparatus for managing services within a cluster computer system
US6405217B1 (en) * 1998-09-21 2002-06-11 Microsoft Corporation State-based implementation of transactions on a file system
US6230190B1 (en) * 1998-10-09 2001-05-08 Openwave Systems Inc. Shared-everything file storage for clustered system
US6236999B1 (en) * 1998-11-05 2001-05-22 Bea Systems, Inc. Duplicated naming service in a distributed processing system
US6581088B1 (en) 1998-11-05 2003-06-17 Beas Systems, Inc. Smart stub or enterprise javaTM bean in a distributed processing system
US6571274B1 (en) * 1998-11-05 2003-05-27 Beas Systems, Inc. Clustered enterprise Java™ in a secure distributed processing system
US6385643B1 (en) 1998-11-05 2002-05-07 Bea Systems, Inc. Clustered enterprise Java™ having a message passing kernel in a distributed processing system
US8726330B2 (en) 1999-02-22 2014-05-13 Touchtunes Music Corporation Intelligent digital audiovisual playback system
US6546415B1 (en) 1999-05-14 2003-04-08 Lucent Technologies Inc. Network management system using a distributed namespace
FR2796482B1 (fr) 1999-07-16 2002-09-06 Touchtunes Music Corp Systeme de gestion a distance d'au moins un dispositif de reproduction d'informations audiovisuelles
US6629127B1 (en) * 1999-07-26 2003-09-30 Microsoft Corporation Methods and systems for processing HTTP requests
US7634453B1 (en) 1999-08-13 2009-12-15 Storage Technology Corporation Distributed file data location
US6553387B1 (en) * 1999-11-29 2003-04-22 Microsoft Corporation Logical volume configuration data management determines whether to expose the logical volume on-line, off-line request based on comparison of volume epoch numbers on each extents of the volume identifiers
US6684231B1 (en) * 1999-11-29 2004-01-27 Microsoft Corporation Migration of friendly volumes
FR2805377B1 (fr) * 2000-02-23 2003-09-12 Touchtunes Music Corp Procede de commande anticipee d'une selection, systeme numerique et juke-box permettant la mise en oeuvre du procede
FR2805060B1 (fr) 2000-02-16 2005-04-08 Touchtunes Music Corp Procede de reception de fichiers lors d'un telechargement
FR2805072B1 (fr) * 2000-02-16 2002-04-05 Touchtunes Music Corp Procede d'ajustement du volume sonore d'un enregistrement sonore numerique
DE10018327A1 (de) * 2000-04-13 2001-10-25 Sep Elektronik Gmbh Mehrprozess-Anwendungsmanagement
US7080078B1 (en) * 2000-05-09 2006-07-18 Sun Microsystems, Inc. Mechanism and apparatus for URI-addressable repositories of service advertisements and other content in a distributed computing environment
FR2808906B1 (fr) 2000-05-10 2005-02-11 Touchtunes Music Corp Dispositif et procede de gestion a distance d'un reseau de systemes de reproduction d'informations audiovisuelles
US6721880B1 (en) 2000-05-31 2004-04-13 Lucent Technologies Inc. Method and apparatus for maintaining configuration information in a computing environment
FR2811175B1 (fr) * 2000-06-29 2002-12-27 Touchtunes Music Corp Procede de distribution d'informations audiovisuelles et systeme de distribution d'informations audiovisuelles
AU2001269548A1 (en) * 2000-06-29 2002-01-08 Inus Technology Inc. Modeling method for discrete event system using event flow chart
FR2811114B1 (fr) 2000-06-29 2002-12-27 Touchtunes Music Corp Dispositif et procede de communication entre un systeme de reproduction d'informations audiovisuelles et d'une machine electronique de divertissement
US6498937B1 (en) 2000-07-14 2002-12-24 Trw Inc. Asymmetric bandwidth wireless communication techniques
US6886004B2 (en) * 2000-08-24 2005-04-26 Red Hat, Inc. Method and apparatus for atomic file look-up
FR2814085B1 (fr) 2000-09-15 2005-02-11 Touchtunes Music Corp Procede de divertissement base sur les jeux concours a choix multiples
WO2002057917A2 (en) 2001-01-22 2002-07-25 Sun Microsystems, Inc. Peer-to-peer network computing platform
US7058629B1 (en) * 2001-02-28 2006-06-06 Oracle International Corporation System and method for detecting termination of an application instance using locks
US7069317B1 (en) 2001-02-28 2006-06-27 Oracle International Corporation System and method for providing out-of-band notification of service changes
US6892205B1 (en) 2001-02-28 2005-05-10 Oracle International Corporation System and method for pre-compiling a source cursor into a target library cache
US7444335B1 (en) 2001-02-28 2008-10-28 Oracle International Corporation System and method for providing cooperative resource groups for high availability applications
NL1018008C1 (nl) * 2001-05-07 2002-11-08 Jean-Luc Rochet Werkwijze en systeem voor het uitvoeren van gepersonifieerde interactieve geautomatiseerde elektronisch marketing van de leverancier van marketingdiensten.
US6718327B1 (en) * 2001-08-31 2004-04-06 Openwave Systems Inc. Fault-tolerant queue with autonomous client operation
US7444393B2 (en) * 2001-10-30 2008-10-28 Keicy K. Chung Read-only storage device having network interface, a system including the device, and a method of distributing files over a network
JP2003208343A (ja) * 2002-01-10 2003-07-25 Ricoh Co Ltd ファイル作成・閲覧方法、ファイル作成方法、ファイル閲覧方法、ファイル構造及びプログラム
JP3862588B2 (ja) * 2002-04-11 2006-12-27 キヤノン株式会社 通信装置及びその制御方法
US8103589B2 (en) 2002-09-16 2012-01-24 Touchtunes Music Corporation Digital downloading jukebox system with central and local music servers
US9646339B2 (en) 2002-09-16 2017-05-09 Touchtunes Music Corporation Digital downloading jukebox system with central and local music servers
US7822687B2 (en) * 2002-09-16 2010-10-26 Francois Brillon Jukebox with customizable avatar
US10373420B2 (en) 2002-09-16 2019-08-06 Touchtunes Music Corporation Digital downloading jukebox with enhanced communication features
US8584175B2 (en) 2002-09-16 2013-11-12 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US8332895B2 (en) 2002-09-16 2012-12-11 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US11029823B2 (en) 2002-09-16 2021-06-08 Touchtunes Music Corporation Jukebox with customizable avatar
US8151304B2 (en) 2002-09-16 2012-04-03 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US7502370B2 (en) 2003-01-21 2009-03-10 Nextio Inc. Network controller for obtaining a plurality of network port identifiers in response to load-store transactions from a corresponding plurality of operating system domains within a load-store architecture
US7174413B2 (en) * 2003-01-21 2007-02-06 Nextio Inc. Switching apparatus and method for providing shared I/O within a load-store fabric
US7493416B2 (en) 2003-01-21 2009-02-17 Nextio Inc. Fibre channel controller shareable by a plurality of operating system domains within a load-store architecture
US7917658B2 (en) * 2003-01-21 2011-03-29 Emulex Design And Manufacturing Corporation Switching apparatus and method for link initialization in a shared I/O environment
US8102843B2 (en) * 2003-01-21 2012-01-24 Emulex Design And Manufacturing Corporation Switching apparatus and method for providing shared I/O within a load-store fabric
US7836211B2 (en) * 2003-01-21 2010-11-16 Emulex Design And Manufacturing Corporation Shared input/output load-store architecture
US7188209B2 (en) * 2003-04-18 2007-03-06 Nextio, Inc. Apparatus and method for sharing I/O endpoints within a load store fabric by encapsulation of domain information in transaction layer packets
US8032659B2 (en) * 2003-01-21 2011-10-04 Nextio Inc. Method and apparatus for a shared I/O network interface controller
US7457906B2 (en) * 2003-01-21 2008-11-25 Nextio, Inc. Method and apparatus for shared I/O in a load/store fabric
US7046668B2 (en) * 2003-01-21 2006-05-16 Pettey Christopher J Method and apparatus for shared I/O in a load/store fabric
US8346884B2 (en) 2003-01-21 2013-01-01 Nextio Inc. Method and apparatus for a shared I/O network interface controller
US7698483B2 (en) * 2003-01-21 2010-04-13 Nextio, Inc. Switching apparatus and method for link initialization in a shared I/O environment
US7953074B2 (en) 2003-01-21 2011-05-31 Emulex Design And Manufacturing Corporation Apparatus and method for port polarity initialization in a shared I/O device
US7512717B2 (en) 2003-01-21 2009-03-31 Nextio Inc. Fibre channel controller shareable by a plurality of operating system domains within a load-store architecture
US7103064B2 (en) * 2003-01-21 2006-09-05 Nextio Inc. Method and apparatus for shared I/O in a load/store fabric
US7219183B2 (en) * 2003-01-21 2007-05-15 Nextio, Inc. Switching apparatus and method for providing shared I/O within a load-store fabric
US7617333B2 (en) * 2003-01-21 2009-11-10 Nextio Inc. Fibre channel controller shareable by a plurality of operating system domains within a load-store architecture
US7664909B2 (en) 2003-04-18 2010-02-16 Nextio, Inc. Method and apparatus for a shared I/O serial ATA controller
US7827156B2 (en) * 2003-02-26 2010-11-02 Microsoft Corporation Issuing a digital rights management (DRM) license for content based on cross-forest directory information
JP4022764B2 (ja) * 2003-06-26 2007-12-19 日本電気株式会社 情報処理装置、ファイル管理方法およびプログラム
JP4278452B2 (ja) * 2003-08-04 2009-06-17 株式会社日立製作所 計算機システム
US7380246B2 (en) * 2003-12-15 2008-05-27 Lenovo (Singapore) Pte. Ltd. Method and system of accessing at least one target file in a computer system with an operating system with file locking implemented with byte-range locking
US20050131960A1 (en) * 2003-12-15 2005-06-16 Reed Benjamin C. Method and system of accessing at least one target file in a computer system with an operating system with file locking implemented at file-open time
US8463748B1 (en) * 2004-02-05 2013-06-11 Emc Corporation File system quiescing
US7275071B2 (en) * 2004-02-27 2007-09-25 Scientific-Atlanta, Inc. Method of distributing content information over a broadcast file system
US7230520B2 (en) * 2004-05-03 2007-06-12 Dell Products L.P. Method and apparatus for RF access to system ID and fault information
US20060074940A1 (en) * 2004-10-05 2006-04-06 International Business Machines Corporation Dynamic management of node clusters to enable data sharing
JP4038216B2 (ja) * 2005-05-10 2008-01-23 ファナック株式会社 シーケンスプログラム編集装置
US7797273B2 (en) * 2006-03-27 2010-09-14 Emoze Ltd. System and a method for reliable symmetric data synchronization
US9171419B2 (en) 2007-01-17 2015-10-27 Touchtunes Music Corporation Coin operated entertainment system
US9330529B2 (en) 2007-01-17 2016-05-03 Touchtunes Music Corporation Game terminal configured for interaction with jukebox device systems including same, and/or associated methods
US9953481B2 (en) 2007-03-26 2018-04-24 Touchtunes Music Corporation Jukebox with associated video server
DE102007026242A1 (de) * 2007-05-30 2008-12-11 Carad Beteiligungen Gmbh Datenspeichereinrichtung
US8332887B2 (en) 2008-01-10 2012-12-11 Touchtunes Music Corporation System and/or methods for distributing advertisements from a central advertisement network to a peripheral device via a local advertisement server
US10290006B2 (en) 2008-08-15 2019-05-14 Touchtunes Music Corporation Digital signage and gaming services to comply with federal and state alcohol and beverage laws and regulations
WO2010005569A1 (en) 2008-07-09 2010-01-14 Touchtunes Music Corporation Digital downloading jukebox with revenue-enhancing features
US8806611B2 (en) * 2008-12-02 2014-08-12 At&T Intellectual Property I, L.P. Message administration system
US10564804B2 (en) 2009-03-18 2020-02-18 Touchtunes Music Corporation Digital jukebox device with improved user interfaces, and associated methods
US9292166B2 (en) 2009-03-18 2016-03-22 Touchtunes Music Corporation Digital jukebox device with improved karaoke-related user interfaces, and associated methods
US10719149B2 (en) 2009-03-18 2020-07-21 Touchtunes Music Corporation Digital jukebox device with improved user interfaces, and associated methods
CN106056367A (zh) 2009-03-18 2016-10-26 踏途音乐公司 娱乐服务器及相关的社交网络系统
US8683576B1 (en) * 2009-09-30 2014-03-25 Symantec Corporation Systems and methods for detecting a process to establish a backdoor connection with a computing device
CN105374380A (zh) 2010-01-26 2016-03-02 踏途音乐公司 具有改进的用户界面的数字点播设备和相关方法
US9342072B2 (en) * 2010-09-24 2016-05-17 Fisher-Rosemount Systems, Inc. Methods and apparatus to display process control device information
US8725978B2 (en) * 2011-06-30 2014-05-13 Red Hat, Inc. Using symbol information for categorization of dynamic memory allocations
US8719539B2 (en) * 2011-06-30 2014-05-06 Red Hat, Inc. Using heuristics for field types of a structure to categorize dynamic memory allocations
US20130067346A1 (en) * 2011-09-09 2013-03-14 Microsoft Corporation Content User Experience
CA2971002A1 (en) 2011-09-18 2013-03-21 Touchtunes Music Corporation Digital jukebox device with karaoke and/or photo booth features, and associated methods
US11151224B2 (en) 2012-01-09 2021-10-19 Touchtunes Music Corporation Systems and/or methods for monitoring audio inputs to jukebox devices
JP5567069B2 (ja) * 2012-06-11 2014-08-06 株式会社三菱東京Ｕｆｊ銀行 データベースサーバ
US9092455B2 (en) 2012-07-17 2015-07-28 Microsoft Technology Licensing, Llc Image curation
US10346422B2 (en) * 2012-10-18 2019-07-09 International Business Machines Corporation Use of proxy objects for integration between a content management system and a case management system
US20140114864A1 (en) 2012-10-22 2014-04-24 International Business Machines Corporation Case management integration with external content repositories
WO2015070070A1 (en) 2013-11-07 2015-05-14 Touchtunes Music Corporation Techniques for generating electronic menu graphical user interface layouts for use in connection with electronic devices
US9276938B2 (en) * 2013-11-27 2016-03-01 General Electric Company Cross-enterprise workflow
KR102533342B1 (ko) 2014-03-25 2023-05-17 터치튠즈 뮤직 컴퍼니, 엘엘씨 향상된 사용자 인터페이스를 가지는 디지털 주크박스 장치 및 관련 방법
US10678412B2 (en) 2014-07-31 2020-06-09 Microsoft Technology Licensing, Llc Dynamic joint dividers for application windows
US10254942B2 (en) 2014-07-31 2019-04-09 Microsoft Technology Licensing, Llc Adaptive sizing and positioning of application windows
US10592080B2 (en) 2014-07-31 2020-03-17 Microsoft Technology Licensing, Llc Assisted presentation of application windows
US9836464B2 (en) 2014-07-31 2017-12-05 Microsoft Technology Licensing, Llc Curating media from social connections
KR102263357B1 (ko) * 2017-04-19 2021-06-11 한국전자통신연구원 분산 파일시스템 환경에서 사용자 수준 dma i/o를 지원하는 시스템 및 그 방법
US11941104B2 (en) * 2020-12-03 2024-03-26 Red Hat, Inc. Utilizing extended file attributes for working directory

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4525780A (en) * 1981-05-22 1985-06-25 Data General Corporation Data processing system having a memory using object-based information and a protection scheme for determining access rights to such information
US5060150A (en) * 1987-01-05 1991-10-22 Motorola, Inc. Process creation and termination monitors for use in a distributed message-based operating system
US4853843A (en) * 1987-12-18 1989-08-01 Tektronix, Inc. System for merging virtual partitions of a distributed database
US5032979A (en) * 1990-06-22 1991-07-16 International Business Machines Corporation Distributed security auditing subsystem for an operating system
US5237680A (en) * 1990-09-27 1993-08-17 Sun Microsystems, Inc. Method for incremental rename propagation between hierarchical file name spaces

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ＵＫＵＵＧ，ＵＮＩＸ−ＴＨＥ ＬＥＧＥＮＤ ＥＶＯＬＶＥＳ ＰＲＯＣＥＥＤＩＮＧＳ ＯＦ ＴＨＥ ＳＵＭＭＥＲ １９９０ ＵＫＵＵＧ ＣＯＮＦＥＲＥＮＣＥ：Ｒｏｂ Ｐｉｋｅ Ｄａｖｅ Ｐｒｅｓｏｔｔｏ，Ｋｅｎ Ｔｏｍｐｓｏｎ，Ｈｏｗａｒｄ Ｔｒｋｋｅｙ "Ｐｌａｎ９ ｆｒｏｍ Ｂｅｌｌ Ｌａｂｓ"

Also Published As

Publication number Publication date
EP0466486B1 (en) 1998-05-27
JPH04233654A (ja) 1992-08-21
AU649455B2 (en) 1994-05-26
US5623666A (en) 1997-04-22
ES2116276T3 (es) 1998-07-16
DE69129479D1 (de) 1998-07-02
EP0466486A3 (en) 1993-08-11
DE69129479T2 (de) 1998-11-05
EP0466486A2 (en) 1992-01-15
JPH10124376A (ja) 1998-05-15
CA2046723A1 (en) 1992-01-12
AU8033491A (en) 1992-01-16
CA2046723C (en) 1998-11-24

Similar Documents

Publication Publication Date Title
JP2724256B2 (ja) コンピュータシステム
JP2779587B2 (ja) コンピュータシステムに用いる名前スペースの一部分を別の名前スペースの一部分として利用可能にするための装置及びその方法
JP3439337B2 (ja) ネットワーク管理システム
US6499036B1 (en) Method and apparatus for data item movement between disparate sources and hierarchical, object-oriented representation
US6314460B1 (en) Method and apparatus for analyzing a storage network based on incomplete information from multiple respective controllers
US5724512A (en) Methods and apparatus for storage and retrieval of name space information in a distributed computing system
Pike et al. Plan 9 from bell labs
US20030093420A1 (en) Method and system for retrieving sharable information using a hierarchically dependent directory structure
JPH04246742A (ja) 異なるファイル・システムにまたがる記憶管理システム
JPH11224196A (ja) リモート・オブジェクト・アクセス
JPS62119664A (ja) コンピユ−タ　ネツトワ−ク内での遠隔プロセス実行法
JPH058455B2 (ja)
JP4060890B2 (ja) 階層化ドライバ入出力システム内の複数ドライバによる入出力要求の再処理を可能にするファイル・システム・プリミティブ
Zwaenepoel et al. Perseus: Retrospective on a portable operating system
JPH08153010A (ja) 情報処理方法及び装置及びシステム
Forin et al. Parallel processing with Agora
Benkiran et al. A communication system architecture for the office
Abécassis YOODA: Handling Distribution Through OODBMS
Lamberts et al. Paragon parallel programming environment on sun workstations
Tag et al. Design of an object-oriented distributed system: experience with CSA
Liao et al. The THUDSOS distributed operating system
Zhou et al. Berkeley, California 94720
JPH0756743A (ja) モジュ−ル管理方法および装置
Juhász et al. JGrid design document
JPH06250920A (ja) 情報処理装置の最適化方法

Legal Events

Date Code Title Description
R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081128

Year of fee payment: 11

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081128

Year of fee payment: 11

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091128

Year of fee payment: 12

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101128

Year of fee payment: 13

LAPS Cancellation because of no payment of annual fees