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

コンピュータシステム

Info

Publication number
JPH04233654A
JPH04233654A JP3196061A JP19606191A JPH04233654A JP H04233654 A JPH04233654 A JP H04233654A JP 3196061 A JP3196061 A JP 3196061A JP 19606191 A JP19606191 A JP 19606191A JP H04233654 A JPH04233654 A JP H04233654A
Authority
JP
Japan
Prior art keywords
file
service
name
namespace
channel
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.)
Granted
Application number
JP3196061A
Other languages
English (en)
Other versions
JP2724256B2 (ja
Inventor
Robert C Pike
ロバート　チャールズ　パイク
L Thompson Kenneth
ケニス　エル．トンプソン
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 Inc
Original Assignee
American Telephone and Telegraph Co Inc
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 American Telephone and Telegraph Co Inc filed Critical American Telephone and Telegraph Co Inc
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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 【０００１】 【産業上の利用分野】本発明は、概して電算システムに
関し、さらに詳細には分散型電算システム、即ちシステ
ムの構成要素が通信媒体によって接続されているような
電算システムに関する。 【０００２】 【従来の技術】電算機システムにおいてプログラムの実
行に利用できる多くの要素実体が、名前、即ちアドレス
ではないが、それによって指定されるその実体を位置づ
けるためにプログラムによって使用される識別子を有す
る。 【０００３】そのような名前の付けられた実体の一般的
な例は、ファイルである。オペレーティング・システム
のファイル・システムの構成要素によって、利用者は、
ファイルに文字列からなる名前を与えかつその文字列の
名前を用いてファイルを位置づけることができる。その
ほかの名前の付けられた実体には、端末またはプリンタ
などの装置がある。実体を位置づけするためにプログラ
ムが使用する名前の集合は、名前空間と称し、その範囲
内でプログラムが実行する。オペレーティング・システ
ムによって、名前空間の編成の仕方が決定される。階層
的な編成の一般的な形は、単一の木構造である。名前空
間におけるすべて名前は、単一のルートを有する木構造
へと編成される。この木構造の内側のノードにある名前
は、ディレクトリを表し；葉のノードにある名前は、普
通の実体を表す。このような木構造において実体または
ディレクトリを位置づけるために、プログラムでは、そ
の実体若しくはディレクトリの名前、および木構造のル
ートとその実体若しくはディレクトリとの間のすべての
ディレクトリ名を指定するか、または実体若しくはディ
レクトリの名前、およびプロセスの現在のディレクトリ
と実体若しくはディレクトリとの間のすべてのディレク
トリ名を指定する。実体を位置づけるのに必要な名前の
組み合わせを実体の「パス名」と称する。 【０００４】分散型システムの設計における１つの問題
は、名前空間を如何に定義するかである。１つの方法は
、アモエバ（Ａｍｏｅｂａ）分散型システムの例に示さ
れるように、単にこの問題を無視することである。アモ
エバ・システムは、１９９０年５月のＩＥＥＥコンピュ
ータにおけるマレンダ（Ｍｕｌｌｅｎｄｅｒ）他による
「１９９０年代のアモエバＡ分散型オペレーティング・
システム（Ａｍｏｅｂａ−Ａ　Ｄｉｓｔｒｉｂｕｔｅｄ
　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　ｆｏｒ　ｔｈｅ
　１９９０’ｓ）」に説明されているが、このオペレー
ティング・システムでは、名前空間は定義されていない
。その代わり、このシステムには、名前サーバと称する
構成要素を含めることができる。名前サーバによって名
前空間が定義される。 【０００５】オペレーティング・システムによって名前
空間が定義されている場合、いくつかの方法がとられて
いる。この方法については、カリフォルニア州バークレ
イのカリフォルニア大学出版により１９９０年発行、カ
マー（Ｃｏｍｅｒ）、ドロムズ（Ｄｒｏｍｓ）およびマ
ーター（Ｍｕｒｔａｇｈ）共著の「電算システム（Ｃｏ
ｍｐｕｔｉｎｇ　Ｓｙｓｔｅｍｓ）」における「ティル
デ命名方式の実験的実施（Ａｎ　Ｅｘｐｒｅｍｅｎｔａ
ｌ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｏｆ　ｔｈｅ　Ｔｉ
ｌｄｅ　Ｎａｍｉｎｇ　Ｓｙｓｔｅｍ）」（ｐ．４８７
−ｐ．５１５）に、さらに詳細な説明がある。１つの方
法は、分散システムにおけるすべての名前を単一の全シ
ステム的な名前の階層に含めることである。場合によっ
ては、名前の階層に、その名前によって表される実体が
位置づけられるシステム構成要素の名前を含めることも
ある。この方法に関する１つの難しさは、名前空間の純
然たる大きさである。一般のプログラムでは２、３の名
前しか使わないが、プログラムや利用者が集まれば、莫
大な階層を処理しなければならない。さらに、システム
構成要素の名前が名前の階層に含まれる場合には、何れ
の構成要素が求めている実体を有するかを利用者または
プログラムが知る必要がある。明らかに、これらの難し
さの程度は、分散システムの規模が拡大するほど、増大
する。 【０００６】大きさの問題は、名前空間を分割すること
によって扱われてきた。名前空間を分割する１つの方法
は、プロセッサまたはワーク・ステーションごとに行う
ものである。名前空間を分割するもう１つの方法は、利
用者ごとに行うものである。 【０００７】利用者による分割も、プロセッサによる分
割も、コンピュータ・システムにおいてプログラムを実
行する実体はプロセスであり、利用者や機械ではないと
いう事実には対処していない。名前空間を除くすべての
点において、プログラムが実行する環境は、それを実行
するプロセスの環境である。例えば、プログラムが一時
的な変数を生成すると、その変数は、そのプログラムを
実行しているプロセスの環境の一部であり、それをアク
セスできるのは、そのプロセスだけである。しかし、プ
ログラムが一時的なファイルを生成すると、そのファイ
ルは、その下でプロセスが実行している名前空間の一部
となるが、これは、その名前空間が、全システム的な名
前空間か、あるプログラムに対する名前空間か、または
ある利用者に対する名前空間かを問わない。 【０００８】一般に、同じ名前空間で実行中の２つのプ
ロセスによって使用される同じ名前は同じ実体を指すと
いう事実のために、重大な命名上の問題が起こる。例え
ば、一時的なファイルのような実体が、真に単一のプロ
セスのみに関係しているならば、プロセスは、その実体
に対して、名前空間における唯一無二の名前を生成しな
ければならない。２つのプロセスが異なる名前空間を持
っている場合、そのような固有の名前を生成する必要性
、およびそれらの使用から生じる複雑さが、避けられる
。プロセスごとの名前空間が無いことによって起こる難
しさは、分散システムに限らないが、プロセスが走って
いる名前空間の大きさが拡大するほど明らかに厳しくな
るので、分散システムによって与えられる名前空間が大
きくなるほど、その難しさも増す。 【０００９】 【発明が解決しようとする課題】各プロセスが名前の独
立した階層（名前空間）を持ち、かつプロセスどうしが
異なるプロセッサ上で実行中でも、互いに他のプロセス
の名前空間を利用することを許すことにより、大規模な
システムにおいても、効率的に名前を管理することがで
きる分散型オペレーテインク・システムを与えることで
ある。 【００１０】 【課題を解決するための手段】ここに開示する本発明の
１つは、次の構成要素によって特徴付けられるマルチプ
ロセス・オペレーティング・システムである。即ち、１
つまたはそれ以上の名前空間；各名前空間に関係付けら
れたプロセスの集合；何れのプロセスにも利用可能で、
そのプロセスに関係付けられた名前空間における名前の
意味を変更するための名前空間変更手段；および何れの
プロセスにも利用可能で、そのプロセスの現在の名前空
間との関係を終了させ、そのプロセスに新たに生成され
た名前空間を関係つけるための新名前空間生成手段であ
る。 【００１１】そのほか、本発明には次のものが含まれる
。即ち、名前の単一の木構造からなるプロセスごとの名
前空間、単一の木構造における名前の意味を変更する名
前空間変更手段、名前の意味の変更記録を保持する簡潔
な手段、ファイルに対する操作によって実体を管理する
ように実体がファイルによって表されるようなサービス
、プロセスの名前空間のルートに結合するために所定の
ファイル木構造を与えるオペレーティング・システムの
ルート・サービス、ファイル操作をファイル・プロトコ
ルに変換するオペレーティング・システムのマウント・
サービス、マウント・サービスによって与えられるファ
イル・プロトコルの集合にすべて応答するプロトコル・
サービス、およびプロセスごとに実体を管理するファイ
ルを与えるサービスなどである。さらに、本発明には、
キーボードからコマンドを入力するための改良された方
法、およびあるプロセス上に位置するサービスによって
与えられるファイルへのアクセスを離れたプロセッサ上
で実行しているプロセスに与える方法も含まれる。 【００１２】 【実施例】実施例において用いる参照番号は、２つの部
分を有する。即ち、下位２桁の数字は、１つの図面にお
ける番号であり、残りの桁は、図面番号である。従って
、参照番号１１５によって特定される項目は、図１に最
初に現れる。 【００１３】次の好ましい実施例の詳細な説明は、本発
明が具体化される第７案のオペレーティング・システム
の概要から開始する。概要に続いて、付加的な題材によ
り第９案の次のような内容−−−第９案によりプロセス
に対する名前空間を生成する方法、第９案のウィンドウ
・システム、およびＣＰＵコマンド−−−をさらに詳細
に説明する。 【００１４】第９案のオペレーティング・システムの概
要：図７第９案は、種々のコンピュータおよびネットワ
ークの上で実施される汎用のマルチユーザ過般分散型シ
ステムである。 【００１５】第９案は、サービス関数の線に沿って分割
される。ＣＰＵサーバにより処理の権限が大きな（過負
荷がかけられていない）マルチプロセッサに集中され、
ファイル・サーバにより記憶のための格納場所が提供さ
れ、端末によりウィンドウ・システムを操作するための
ビットマップ・スクリーンおよびマウスを備えた専用の
コンピュータがシステムの各利用者に与えられる。処理
およびファイル格納のサービスを共有することにより、
プログラマのグループに共同意識を与え、費用を償却し
、かつ管理・運営を集中化し、従って、その単純化を行
う。 【００１６】各部分は、単一のプロトコルによって通信
を行うが、プロトコルは、適切なネットワークによって
提供される信頼性のあるデータ伝達層上に構築されてい
て、各サービスをルートを有するファイル木構造として
定義する。ファイルとは通常考えられないサービスに対
しても、統一された設計によって、顕著かつ有益な単純
化が可能となる。各プロセスは、そのプロセスが使用し
ているすべてのサービスへの連結を含み、それによって
それらのサービスに関するファイルへの連結も含む局部
的なファイル名空間を有する。端末の重要な仕事の１つ
は、名前空間にあるサービスによって表されるように利
用者向けに用意したシステム全体の概念（ｖｉｅｗ）を
与えるようにすることである。 【００１７】効率的に利用するために、本システムは、
ＣＰＵサーバ、ファイル・サーバ、および端末を必要と
する。端末は、部門別かまたはそれより大きな単位のコ
ンピュータ・センタの水準でサービスを与えることを意
図したものである。ＣＰＵサーバおよびファイル・サー
バは、大きな機械であり、調節された電源を有する空調
付きの機械室に収容することが望ましい。 【００１８】以降、第９案の基本的な構成要素を述べる
。名前空間およびその使用方法を説明し、さらに第９案
の概念が種々の問題に如何にして適用できるかを解説す
る普通でないサービスの例を幾つか提示する。 【００１９】ＣＰＵサーバ いくつかのコンピュータが第９案のＣＰＵサービスを与
える。製品のＣＰＵサーバは、２５ＭＨｚ　ＭＩＰＳの
プロセッサおよび１２８メガバイトのメモリを有するが
、ディスクは無く、ファイル・サーバへの毎秒２０メガ
バイトのブロックＤＭＡ接続を行うシリコン・グラフィ
クス（Ｓｉｌｉｃｏｎ　Ｇｒａｐｈｉｃｓ）のパワー・
シリーズ（Ｐｏｗｅｒ　Ｓｅｒｉｅｓ）の機械である。 また、これは、端末および第９案以外のシステムに接続
するためにＤａｔａｋｉｔおよびＥｔｈｅｒｎｅｔコン
トローラも備えている。オペレーティング・システムは
、ｆｏｒｋおよびｅｘｅｃシステム・コールに基づくプ
ロセスおよび大部分は遠隔のファイル・サーバによって
決定されるファイルの通常の概念を与える。ＣＰＵサー
バへの接続がひとたび確立されると、利用者は、通常ど
おりに見える環境の下で、コマンド・インタプリタにコ
マンドをタイプ入力することができる。 【００２０】ＣＰＵサーバは、コンパイル、テキスト処
理、およびその他のアプリケーションを実行する。ＣＰ
Ｕサーバは、それ自体の外部記憶装置を持たず、それが
アクセスする永久ファイルはすべて遠隔のサーバによっ
て与えられる。利用者のプロセスによって与えられるサ
ービスまたは活性なプロセスを集めたイメージなどの名
前空間の一時的な部分は、局部的に存在し得るが、ＣＰ
Ｕサーバがリブートされると、それらは消滅する。普通
の端末どおしがそれらのタスクに対して交換可能である
ように、第９案のＣＰＵサーバどおしは、それらのタス
ク、即ち処理に対して交換可能である。 【００２１】ファイル・サーバ 第９案のファイル・サーバは、すべての永久ファイルを
保持する。現在のサーバは、２つのプロセッサ、６４メ
ガバイトのメモリ、６００メガバイトの磁気ディスク、
および３００ギガバイト相当の追記型（ＷＯＲＭ）光デ
ィスク・ユニットを備えたもう１つのシリコン・グラフ
ィックスのコンピュータである。このサーバは、毎秒２
０メガバイトのＤＭＡリンクを通して第９案のＣＰＵサ
ーバに接続され、また通常のネットワークを通して端末
およびその他の機械に接続される。 【００２２】ファイル・サーバは、クライアント（依頼
者）に対し、ディスク、ブロックまたはファイルの配列
などではなくファイル・システムを提示する。ファイル
は、木構造の枝の標識となる斜線で区切られた構成要素
によって命名され、入出力のためにバイト・レベルでア
ドレス指定される。サーバにおけるファイルの位置は、
クライアントには見ることができない。真のファイル・
システムは、ＷＯＲＭに存在し、磁気ディスクの２水準
のキャッシュおよびＲＡＭを通してアクセスされる。最
近利用されたファイルの内用は、ＲＡＭに駐在して、高
速リンクを介するＤＭＡによりＣＰＵサーバに迅速に送
られる。この転送は、局部メモリほどは速くないが正規
のディスクよりはるかに高速である。磁気ディスクは、
ＷＯＲＭに対するキャッシュとして作用すると同時に、
ＲＡＭに対するバックアップ媒体として作用する。高速
リンクについては、クライアントがデータをキャッシュ
する必要がある；そのかわり、ファイル・サーバがその
すべてのクライアントに対しキャッシュ処理を集中化し
て、分散されたキャッシュの問題を回避している。 【００２３】端　　末 ここでは第９案に対する標準の端末をＧｎｏｔ（ノット
）と称する。Ｇｎｏｔは、限定地域で設計された機械で
あり、数百台が製造された。この端末のハードウェアは
、ディスクの無いワークステーションのようであり、４
乃至８メガバイトのメモリ、２５ＭＨｚの６８０００プ
ロセッサ、１画素あたり２ビットで１０２４ｘ１０２４
画素の画面、キーボード、およびマウスを備えている。 この端末は、外部記憶装置も拡張バスも無い。これは、
端末であって、ワークステーションではないからである
。毎秒２メガビットのパケット交換分散網によって、端
末がＣＰＵサーバおよびファイル・サーバに接続される
。コンパイルのような用途には帯域幅が狭いが、端末を
意図した目的−−−ウィンドウ・システム、つまり第９
案の他の部分への多重化インタフェースを与えること−
−−には十分すぎるほどである。 【００２４】ワークステーションとは異なり、Ｇｎｏｔ
は、コンパイルを扱わない；これは、ＣＰＵサーバによ
って行われる。端末では、ＣＰＵサーバのオペレーティ
ング・システムを単一のさらに小型のプロセッサ用にビ
ットマップ・グラフィックスのサポートを付けて変更し
たものを実行させ、これを用いてウィンドウ・システム
およびテキスト・エディタなどのプログラムを実行させ
る。 ファイルは、標準のファイル・サーバによって端末網接
続を介して与えられる。 【００２５】旧式の文字端末のように、すべてのＧｎｏ
ｔは、局部的にもファイル・サーバ上にも独自の記憶装
置を持っていないので、同等である。この端末は高価で
はないので、研究センタの各人が２台；１台は職場に、
もう１台は自宅に持つことができる。自宅に居てＧｎｏ
ｔで仕事をしている人は、職場と全く同じシステムを見
ることになる。これは、ファイルおよび処理資源がすべ
て効率的に共有・維持できれば、それらは職場に残って
いるからである。 【００２６】ネットワーク 第９案は、構成要素を接続する種々のネットワークを有
する。ＣＰＵサーバおよびファイル・サーバは、ブロッ
クＤＭＡコントローラを介して通信を行う。これは、例
えばコンピュータ・センタまたは部門ごとの処理資源の
規模に対して実際的であるにすぎない。さらにはなれた
機械どおしは、ＥｔｈｅｒｎｅｔまたはＤａｔａｋｉｔ
などの通常のネットワークで接続される。端末またはＣ
ＰＵサーバは、性能面を考慮しなければ、遠隔のファイ
ル・サーバを全く透過的に利用することができる。Ｄａ
ｔａｋｉｔネットワークは全国的な範囲にわたるので、
第９案のシステムは、大規模に構築することができる。 費用を低く抑えるために、Ｇｎｏｔは、標準の電話線お
よび単一チップインタフェースを用いる安価なネットワ
ークを使用する。（処理効率は、毎秒約１２０キロバイ
トとかなり高い。）端末は単に通信を仲介する−−−フ
ァイル・サーバに接続するようにＣＰＵサーバに指示は
するが、結果としての通信には関与しない−−−だけな
ので、端末の対する比較的低い帯域幅も、システムの全
体的な性能には影響がない。 【００２７】図７は、第９案の構成要素およびトポロジ
ー（位相幾何学的配置表現）を示す図である。第９案の
システム７０１は、ファイル・サーバ７０５、ＣＰＵ７
０５、およびＧｎｏｔ７１１から成る。ＣＰＵ７０３お
よびファイル・サーバ７０５のクラスタ７１７、および
Ｇｎｏｔ７１１のクラスタ７１９は、全国的な長距離通
信ネットワーク７１５によって接続されている。クラス
タ７１９の内部のＧｎｏｔ７１１は、ＬＡＮなどの分散
型ネットワーク７１３によって接続され、クラスタ７１
７の内部のファイル・サーバ７０５およびＣＰＵ７０３
は、高速ＤＭＡリンク７０９によって接続されている。 【００２８】名前空間 第９案には２種類の名前空間がある。即ち、ネットワー
ク上の種々のサーバの名前のグローバル（全体）空間お
よびプロセッサから見えるファイルおよびサーバのロー
カル（局所）空間である。Ｄａｔａｋｉｔに接続されて
いる機械およびサーバの名前は、階層的であり、例えば
、ｎｊ／ｍｈ／ａｓｔｒｏ／ｈｅｌｉｘと言うように、
（大まかに）地域を、そして建物、部門、部門における
機械を定義する。ネットワークによって、その機械に対
する命名が為されるので、グローバル名の命名の問題は
、第９案において直接扱う必要はない。しかし、第９案
の基本的な作用として、ネットワーク・サービスをプロ
セスごとに基づくローカル名前空間に結び付けることが
あげられる。このローカル名前空間のきめ細かい管理は
、カスタマイズ可能性、透過性、および異種混交性の問
題に取り組むのに使用される。 【００２９】第９案のサービスと通信するためのプロト
コルは、ファイル指向であり、すべてのサービスによっ
てファイル・システムを実現しなければならない。つま
り、局所的なものであれ全体的なものであれ、各サービ
スは、サーバの名前空間と称する階層へと集められるフ
ァイル状のオブジェクトの集合へと配置される。ファイ
ル・サーバにとっては、これは些細な必要条件である。 他のサービスについては、さらに想像的にならなければ
ならない場合がある。例えば、印字サービスであれば、
プロセスが印字されるべきファイルを生成する場所のデ
ィレクトリとして実施される。その他の例は次の節で説
明するので、僅かな間、ネットワーク中に分布する普通
のファイル・サーバの集合のみを考えることにする。 【００３０】プログラムがあるサービスを（そのネット
ワークに本来あり第９案に含まれない機構を用いて）呼
び出すと、プログラムは、そのサービスの名前空間のル
ートに接続される。通常、ファイル指向のシステム・コ
ールの集合へとローカル・オペレーティング・システム
によって仲介されるようなプロトコルを用いて、プログ
ラムは、前記の名前空間におけるファイルに対し、オー
プン、生成、削除、読出し、および書込みを行うことに
よって、サービスにアクセスする。 【００３１】ネットワーク上で利用可能なサービスの集
合から、第９案の利用者は、所望のものを選択する：個
人的なファイルが駐在するファイル・サーバ、恐らくは
、データが蓄えられている他のファイル・サーバ、また
はグループの計画のためのソフトウェアが書かれている
部門的なファイル・サーバ。それらの種々のサービスの
名前空間は、ａｔｔａｃｈと称する第９案の基本的な演
算子によって、収集されて利用者自身の個人的な名前空
間に連結される。利用者の名前空間は、使用中のサービ
スのすべての空間の統一によって形成される。ローカル
名前空間は、各利用者に対し、一般には端末ごとに、ロ
ーカル・オペレーティング・システムによって作られる
。名前空間は、プロセスごとのレベルで変更可能である
が、実際には、ログ・イン時に作られ、その利用者のす
べてのプロセスによって共有される。 【００３２】システムのログ・インするには、端末にお
いて、何れのファイル・サーバを接続するべきかを端末
に命令する。端末は、サーバを呼び出し、利用者の真正
を証明し（以下参照）、さらにそのサーバからオペレー
ティング・システムをロードする。次に、端末は、利用
者の個人的なディレクトリにあるプロファイル（ｐｒｏ
ｆｉｌｅ）と称するファイルを読む。プロファイルには
、何れのサービスがデフォルトで使用されるべきか、ま
たそれらをローカル名前空間の何れの場所に結び付ける
べきかを明示するコマンドが、入っている。例えば、使
用されるべき主なファイル・サーバは、ローカル名前空
間のルート　／　に結び付けられ、プロセス・ファイル
・システムは、ディレクトリ／ｐｒｏｃに結び付けられ
る。その後、プロファイルは、ウィンドウ・システムを
開始させるのが一般的である。 【００３３】ウィンドウ・システムにおける各ウィンド
ウ内で、局所的にコマンドを実行する場合に使用される
コマンド・インタプリタが、プロファイルによって作ら
れた名前空間において解釈されたファイル名を用いて、
実行される。コンパイルなどの演算集約的なアプリケー
ションについては、利用者は、コマンドを実行させるた
めにＣＰＵサーバを（自動的に、または名前によって）
選択するコマンドｃｐｕを走らせる。ｃｐｕとタイプし
た後、利用者には、コマンド・インタプリタからの正規
のプロンプトが見える。しかし、そのコマンド・インタ
プリタは、ｃｐｕコマンド自体と同じ名前空間−−−デ
ィレクトリも同じ現在のディレクトリ−−−にあるＣＰ
Ｕサーバ上を実行している。端末は、その名前空間の記
述をＣＰＵサーバに送り、そのＣＰＵサーバにおいて、
同一の名前空間を作って、端末によって作られたシステ
ムのカスタマイズされた概念が、ＣＰＵサーバ上にある
ものと同じにする。（名前空間の記述は、名前空間それ
自体以外で使用されることが多いので、ＣＰＵサーバは
、可能であれば、端末による仲介を要求せずに高速リン
クを使用する。）ｃｐｕコマンドは、後続のコマンドの
効率に影響を与えるだけであり、利用可能なサービスや
それらアクセス方法には無関係である。 【００３４】サービスを見つけるサービスも含めて、第
９案において利用可能なサービスの大きなカタログがあ
るが、使用法およびこの設計の可能性を説明するには、
２、３のサービスで十分である。 【００３５】プロセス・ファイル・システムローカル・
サービスの一例は、「プロセス・ファイル・システム」
であり、これによって、ファイル指向インタフェースに
よるプロセスの実行の検査およびデバッグが可能となる
。 【００３６】プロセス・ファイル・システムのルートは
、慣例どうりディレクトリ／ｐｒｏｃに結び付ける。 （第９案において慣例は重要である；名前空間は、いや
おうなしに作られるが、多くのプログラムには、名前空
間がある形式を持つことを必要とするような慣例的な名
前が組み込まれる。プログラム／ｂｉｎ／ｒｃ（コマン
ド・インタプリタ）が何れのサーバから来るかは重要で
はないが、そのプログラムは、それを要求するコマンド
によってアクセス可能となるような名前を持たなければ
ならない。）結び付けた後は、ディレクトリ／ｐｒｏｃ
それ自体に、システムにおける各ローカル・プロセスに
対して、そのプロセス特有の数的識別子を有する１つの
サブディレクトリが含まれる。（遠隔のＣＰＵサーバで
走っているプロセスも見えるようにすることができる；
これは、後述する。）各サブディレクトリには、そのプ
ロセスの概念を実施するファイルの集合が含まれる。例
えば、／ｐｒｏｃ／７７／ｍｅｍには、プロセス番号７
７の仮想メモリのイメージが入っている。第９案の／ｐ
ｒｏｃにより、他のファイルを通して他の関数が実施さ
れる。ここで、各プロセスに対して与えられるファイル
のリストを掲げる。プロセス・イメージの仮想メモリ；
ファイルにおけるオフセットは、そのプロセスにおける
仮想アドレスに対応する。プロセスの制御動作；このフ
ァイルに（ｗｒｉｔｅシステム・コールによって）送ら
れたメッセージによって、プロセスは、停止、終了、実
行の再開などを行う。プログラムの発生源であるファイ
ル；これは、一般に、対象のプロセスのシンボル・テー
ブルを調べるためにデバッガによって使用されるが、名
前は別としてすべての点においてオリジナル・ファイル
である；従って、そのプログラムを新たな例示するよう
に、コマンド・インタプリタに対し「／ｐｒｏｃ／７７
／ｔｅｘｔ」とタイプ入力することもできる。適切な許
可を有するプロセスであれば、他のプロセスのノート（
ｎｏｔｅ）ファイルを書いて、プロセス間通信のために
非同期メッセージをそれに送ることができる。このファ
イルは、例えばプロセスがゼロで割ると言うような誤動
作をする場合に、（毒入りの）メッセージを送るために
、システムによっても使用される。プロセス状態の一定
形式のＡＳＣＩＩ表現；これには、そのプロセスが実行
される元のファイルの名前、それが消費したＣＰＵ時間
、現在の状態などが含まれる。 【００３７】状態（ｓｔａｔｕｓ）ファイルは、異種混
交性および過般性がシステムの機能のためにファイル・
サーバ・モデルによって如何に処理され得るかを説明す
るものである。ｃａｔ　／ｐｒｏｃ／＊／ｓｔａｔｕｓ
というコマンドによって、システムにおけるすべてのプ
ロセスの状態が（読むことは可能であるが幾分見にくく
）表示される；実際には、プロセス状態コマンドｐｓが
、そのように集められたＡＳＣＩＩテキストを書式化す
るものである。ｐｓに対するデータ源は、１ページの長
さであり、機械を問わず完全な過般性がある。いくつか
種類の異なる機械のプロセスに対するファイルが／ｐｒ
ｏｃに入っている場合でも、同様の実施が有効である。 【００３８】／ｐｒｏｃが与えるサービスが、多様では
あっても、ファイルとしてのプロセスの概念を十分使用
していないことは、全く無意味である。例えば、プロセ
スを終了させるために、そのプロセス・ファイルを削除
しようとしても無駄であり、プロセス・ファイルを生成
することによって、新たなプロセスを開始することもで
きない。ファイルは、プロセスの有効な概念（ａｃｔｉ
ｖｅｖｉｅｗ）を与えるが、ファイルを文字どおり表す
わけではない。 サービスをファイル・システムとして設計する場合、こ
の区別が重要である。 【００３９】第９案のサービスのアーキテクチャの概要
：図１ 既に述べたように、サービスは、ファイル・システムと
して実施される、つまり、第９案のオペレーティング・
システムによってコンピュータ上で実行中のプロセスに
とっては、サービスはファイルの集合として映る。プロ
セスは、サービスによって与えられる「ファイル」にフ
ァイル読出し操作を行うことによって、サービスからデ
ータを得ることができ、それらの「ファイル」にファイ
ル書込み操作を行うことによって、サービスにデータを
与えることができる。プロセス・サービスによって与え
られる「ファイル・システム」について既に詳細に説明
したように、サービスは、実際にファイルを保持する必
要はなく、プロセスによるファイル操作への要求に対し
、単に、それらを保持しているかのように反応するだけ
でよい。例えば、プロセスがサービスによって保持され
ているある「ファイル」を読む場合、サービスは、その
「ファイル」を読むプロセスにデータを与えなければな
らない。 【００４０】サービスとプロセスとの間の関係の概要を
図１に示す。サービスのアーキテクチャ１０１は、プロ
セスが１つまたはそれ以上のサービス１２３にアクセス
するためにファイル・システムを如何に使用するかを示
している。プロセス１０２は、Ｇｎｏｔ７１１またはＣ
ＰＵ７０３の何れかにおいて実行中であり、サービスは
、プロセス１０２が実行中のプロセッサに対して局所的
に実施されることもあれば、ファイル・サーバ７０５の
ような遠隔の装置において実施されることもある。 【００４１】図１に示したように、各サービスは、その
サービスを使用するプロセッサ１０２に１つ以上のファ
イルの木構造を与える。ファイルの木構造は、データ・
ファイル１３１とディレクトリ・ファイル１２７および
１２９とから成り立つ。ディレクトリ・ファイルは、フ
ァイルのリストが入っているファイルである。ディレク
トリ・ファイルに掲げられたファイルは、ディレクトリ
・ファイルかデータ・ファイルの何れかである。ファイ
ル木構造１２５（ａ）から分かるように、データ・ファ
イル１３１Ｂ、ＣおよびＤが、ファイル木構造の「葉」
であるのに対し、ディレクトリ・ファイル１２９は、そ
の木構造が分岐する点を占める。木構造全体の根元には
、単一のルート・ディレクトリ・ファイル１２７がある
。サービス１２３中の各ファイルは、ファイル名を有す
る。好ましい実施例では、ファイル名は、文字列である
。 【００４２】プロセス１０２は、第９案のオペレーティ
ング・システムによって与えられるファイル・システム
関数へのコールによって、サービス１２３中のファイル
にアクセスする。関数には主な種類が２つある。ファイ
ル・ロケータ関数（ＦＬ）１１３；ファイルを位置づけ
る。ファイル・アクセス関数（ＦＡ）１１１；ファイル
・ロケータ関数１１３によってファイルが位置づけられ
た後に、そのファイルをアクセスする。ファイル・ロケ
ータ関数１１３へのコールは、矢印１０７で表し、ファ
イル・アクセス関数１１１へのコールは、矢印１０５に
よって表す。 【００４３】前述のように、第９案の各プロセス１０２
は、名前空間に関係付けられている。プロセス１０２の
名前空間により、サービス１２３によって与えられる何
れのファイルにプロセス１２がアクセスできるかが決定
される。好ましい実施例におけるプロセス１０２の名前
空間は、ファイル木構造１２５および（または）それら
の木構造の下位木構造から構成させる単一のファイル木
構造１１７からなる。このように、ファイル・ロケータ
関数１１３によって維持・使用される名前空間１１５（
ｏ）は、プロセス１０２（ａ）に対する名前空間である
。図１から分かるように、プロセス１０２（ａ）の名前
空間には、サービス１２３（ａ）からの１２５（ａ）お
よびサービス１２３（ｋ）からのファイル木構造１２５
（ｋ）を含むファイル木構造１１７（ｏ）が、入ってい
るが、サービス１２３（ｂ）からのファイル木構造１２
５（ｂ）は含んでいない。ファイル木構造１１７（ｏ）
は、プロセス１０２のファイル木構造１１７（ｏ）のデ
ィレクトリ・ファイル「Ｘ」を木構造１２５（ａ）のル
ートと同じにし、かつファイル木構造１１７（ｏ）のデ
ィレクトリ・ファイル「Ｙ」をファイル木構造１２５（
ｋ）のルートと同じにすることによって、構成された。 「Ｘ」および「Ｙ」それ自体が如何にして名前空間１１
５（ｏ）に存在するようになったかは、詳細に後述する
。 【００４４】名前空間１１５（ｏ）において、ファイル
は、パス名によって位置が特定される。パス名は、位置
が特定されるべきファイルの名前、およびそのファイル
の位置を特定している元のファイル木構造における点か
らそのファイルまでのすべてのディレクトリ・ファイル
の名前を含むファイル名リストである。そのファイルの
位置を特定している元のファイル木構造における点は、
ワーキング・ディレクトリと称する。従って、ワーキン
グ・ディレクトリが、ディレクトリ・ファイルＸならば
、前記のパス名は、Ａ／Ｃである。Ａ／Ｃにおける文字
「／」は、パス名における名前を区切る役目をする。 さらに、任意のファイルは、その完全なパス名−−−ル
ート・ディレクトリを表す文字「／」、ルート・ディレ
クトリとそのファイルとの間のすべてのディレクトリ名
、およびそのファイル名−−−を指定することによって
位置を特定することができる。それらのファイル名も「
／」によって区切られる。従って、名前空間１１５（ｏ
）におけるファイルＣの完全なパス名は、／Ｘ／Ａ／Ｃ
である。 【００４５】第９案においては、多数のプロセス１０２
が、１つの名前空間を共有する。ある名前空間を共有す
るプロセス１０２によって、１つのプロセス・グループ
１０３が構成される。従って、プロセス・グループ１０
３（ｏ）に所属するプロセスは、ファイル木構造１１７
（ｏ）によって定義される名前空間１１５（ｏ）を共有
し、一方、プロセス・グループ１０３（ｚ）におけるプ
ロセスは、名前空間１１５（ｚ）を共有する。プロセス
は、第９案において、システム・コール「ｆｏｒｋ」に
よって生成される。新たに生成されたプロセス１０２は
、その「ｆｏｒｋ」システム・コールを行ったプロセス
１０２と同じ名前空間１１５に関係付けられた状態を維
持するので、そのｆｏｒｋシステム・コールを行ったプ
ロセス１０２と同じプロセス・グループに属する。プロ
セス１０２がシステム・コール「ｆｏｒｋｐｇｒｐ」を
行うと、新たなプロセス・グループが確立される。この
コールは、引数を１つだけ持つ；即ち、新たなプロセス
・グループがプロセス１０２の古い名前空間１０５のコ
ピーを受け取るか、または最小限のデフォルトの名前空
間１０５を受け取るかを示すフラグである。システム・
コールを実行することによって、そのシステム・コール
を行っているプロセス１０２は新たなプロセス・グルー
プに置かれる。ｆｏｒｋｐｇｒｐシステム・コールによ
って、プロセス１０２に対し新たな名前空間１１５が確
立されると、新たな名前空間１１５における変化は、そ
のｆｏｒｋｐｇｒｐシステム・コールを行っているプロ
セス１０２が以前に所属していたプロセス・グループ１
０３の古い名前空間には、影響を与えない。 【００４６】プロセス・グループ１０３に属するプロセ
スは、そのプロセス・グループに対する名前空間１１５
を変更することができる。これを行うには、プロセスは
、２つの名前空間修正関数のうちの１つを使用する。 第１の関数は、「ｂｉｎｄ（結合）」であり、その名前
空間に既に存在する名前を新たなパス名によって指定さ
れるファイルと同じにする。ｂｉｎｄの実行後は、古い
パス名によって指定されたファイルへの参照は、新たな
パス名によって指定されるファイルへの参照へと変換さ
れる。例えば、名前空間１１５（ｏ）においてＡという
ルートを有する下位木構造をその名前空間においてＨと
いうルートを有する下位木構造で置き換える場合には、
名前空間１１５（ｏ）における「ｂｉｎｄ（”／Ｙ／Ｈ
”，”／Ｘ／Ａ”）」というシステム・コールが使用さ
れる。このｂｉｎｄの後、パス名／Ｘ／Ａ／Ｋは、下位
木構造ＨのファイルＫを参照することになる。 【００４７】第２の関数は、「ｍｏｕｎｔ」であり、名
前空間に既にある名前をサービス１２３のルートと同じ
にするものである。詳細は後述するが、サービスのルー
トは、小さい整数のタファイル記述子（ファイル・ディ
スクリプタ）によって表される。従って、マウント関数
「ｍｏｕｎｔ（ＦＤ，”／Ｘ”）」によって、ファイル
木構造１１７（ｏ）のディレクトリ名「Ｘ」は、サービ
ス１２３（ａ）のファイル木構造１２５（ａ）のルート
と同じになる。マウントした後は、パス名／Ｘ／Ａによ
ってファイル木構造１２５（ａ）のファイルＡが参照さ
れる。 【００４８】第９案における「ｍｏｕｎｔ」および「ｂ
ｉｎｄ」の更なる改良点は、パス名どうしの間またはフ
ァイル記述子とパス名との間に３種類の異なる関係を指
定できることである。第１の関係は、置換である。この
関係が指定された場合、新たな名前またはファイル記述
子によって参照されるものが、すべて古い名前によって
参照されるものに置き代わる。第２および第３の関係に
より、結合ディレクトリと称するものが確立される。結
合ディレクトリが確立されると、ｂｉｎｄ関数において
使用される古い名前と新たな名前は、共にディレクトリ
・ファイルを示さなければならず、またｍｏｕｎｔコマ
ンドにおける古い名前は、ディレクトリ・ファイルを示
さなければならないが、他方、ファイル記述子は、サー
ビス１２３中のファイル木構造のルートを示さなければ
ならない。ｂｉｎｄまたはｍｏｕｎｔの作用は、新旧の
ディレクトリ・ファイルの結合体である新たなディレク
トリを確立することである。関係ｂｅｆｏｒｅによって
、古いディレクトリの前に新たなディレクトリが探査さ
れるような結合ディレクトリが確立され、もう１つの関
係ａｆｔｅｒによって、古いディレクトリの後に新たな
ディレクトリが探査されるような結合ディレクトリが確
立される。従って、結合コマンド「ｂｉｎｄ（”／Ｙ／
Ｈ”，”／Ｘ／Ａ”，ＢＥＦＯＲＥ）」により、ファイ
ルＩ、Ｊ、ＫがファイルＢおよびＣより先行するような
ディレクトリが確立され、ファイル・ロケータ関数１１
３がパス名／Ｘ／Ａ／Ｃに応答する場合、その関数は、
まずディレクトリＨを通って探査し、次にディレクトリ
Ａを通って探査することになる。ロケータ関数がファイ
ルを求めてディレクトリを探査する順序をこのように決
定することにより、結合ディレクトリは、ＵＮＩＸのよ
うなオペレーティング・システムにおけるリスト探査に
よって与えられる制御と同じ種類の制御を与える。 【００４９】名前空間の配置を変えずにファイルの位置
を特定するファイル・ロケータ関数１１３は、引数とし
てパス名を取り、ファイル記述子を返す。ここにおいて
、ファイル記述子は、ファイルを参照するためにファイ
ル・アクセス関数において使用される小さい整数である
。ファイル・ロケータ関数１１３には、パス名によって
指定されたディレクトリ・ファイルをプロセス１０２の
ワーキング・ディレクトリに変更する「ｃｈｄｉｒ」、
およびパス名によって指定されたファイルを開く「ｏｐ
ｅｎ」が含まれる。「ｃｈｄｉｒ」および「ｏｐｅｎ」
は、ワーキング・ディレクトリのファイルおよび開かれ
たファイルに対するファイル記述子をそれぞれ返す。さ
らに、「ｃｒｅａｔｅ」関数は、パス名において指定さ
れたファイルが生成されると言う点を除けば、「ｏｐｅ
ｎ」と同様に作用する。 そして、ファイル・アクセス関数１０５は、ファイルの
読出し・書込み、ファイルの状態の設定・獲得、および
ファイルのクローズを行う場合に、ファイル・ロケータ
関数によって与えられるファイル記述子を使用する。 【００５０】アーキテクチャ１０１において、ファイル
・システム１０９は、プロセス１０２によって行われる
ファイル・アクセス・コール１０５およびファイル・ロ
ケータ・コール１０７をサービス・ファイル操作要求に
変換する。各サービス・ファイル操作要求によって、サ
ービス１２３に、そのファイル木構造１２５のうちの１
つにあるファイルに対してある操作を実行することを要
求する。このような要求には２種類ある：矢印１１９で
示したサービス・ファイル・アクセス要求、および矢印
１２１で示したシステム・ファイル・ロケータ要求であ
る。あるサービス１２３に対する要求１１９および１２
１は、関数呼び出し（ファンクション・コール）の形式
を取り、他のサービス１２３に対しては、要求はファイ
ル・プロトコルの形式を取る。関数読出しの場合、ファ
イルは、ファイル名またはファイル記述子（ｄｅｓｃｒ
ｉｐｔｏｒ）によって表され；ファイル・プロトコルの
場合、ファイルは、ファイル名またはファイル識別子（
ｉｄｅｎｔｉｆｉｅｒ）によって表される。以降の説明
のために、ファイル記述子およびファイル識別子をファ
イル指定子（ｓｐｅｃｉｆｉｅｒ）という用語に包括す
る。 【００５１】ファイル・システム１０９において、プロ
セス１０２によって使用されるファイル記述子は、サー
ビス１２３によって与えられるファイル・ハンドルｑｉ
ｄに関係付けられる。この関係付けは、ファイル記述子
のファイル識別子への関係付け、およびファイル識別子
のｑｉｄへの関係付けによって、直接的または間接的に
行われる。プロセス１０２によって使用されるファイル
記述子とｑｉｄとの間に関係付けがある場合、プロセス
１０２は、ｑｉｄによって表されるファイルへの接続（
ｃｏｎｎｅｃｔｉｏｎ）があると称する。同様に、サー
ビス１２３において、ｑｉｄは、１つ以上のファイル指
定子に関係付けられている。所与のｑｉｄに関係付けら
れたファイル指定子を有するシステム・ファイル要求を
発生させるファイル・システム・コール１０５によって
、ｑｉｄによって指定されるファイルに対してファイル
操作が行われることになる。 【００５２】ファイルを名前、即ちサービス１２３にお
けるｑｉｄではなく、名前、即ちファイル指定子によっ
て表すことの利点は、異なるサービスによって、名前お
よびｑｉｄの間に異なる関係を確立することができるこ
とである。例えば、前記のプロセス・サービスなどのサ
ービスにおいては、すべてのプロセスによって使用され
るファイル名がファイルの単一の集合を示すことが有益
であり；詳細に後述する予定の８．５ウィンドウ・サー
ビスのような他のサービスでは、各プロセスによって使
用されるファイル名は、そのプロセス固有のファイル集
合を示す。結果として、アーキテクチャ１０１における
ファイル名は、Ｃなどのプログラミング言語における変
数の性質と類似の性質を有する。ファイル名のあるもの
は、グローバルな静的変数名に似ている；グローバルな
静的変数名が、その変数名が現れるすべてのコードにお
いて同一のメモリ位置を示すように、プロセス・サービ
スによって与えられるようなファイル名は、すべてのプ
ロセスにおいて同じファイルを示す。ファイル名の中に
は、局所的変数名に似たものがある；局所的変数名が、
プロシージャの呼び出しの度に異なるメモリ位置を示す
ように、８．５サーバによって与えられるようなファイ
ル名は、各プロセスにおいて異なるファイルを示す。フ
ァイル名が何れの性質を有するかは、勿論、そのファイ
ルを与えるサービス１２３によって決定される。変数に
ついて用いられる用語との類似性により、サービス１２
３が、そのファイルのインスタンスを与えると言える。 従って、プロセス・サービスにより、そのファイルの各
々の単一のインスタンスが与えられ、そのサービスによ
って与えられるファイルの１つへの接続を有するプロセ
ス１０２は、そのファイルへの接続を有する他のすべて
プロセス１０２と同じファイルにアクセスすることがで
きる。一方、ウィンドウ・サービスは、そのファイル木
構造のルートとの接続を確立する各プロセス１０２に対
し、そのファイル木構造におけるファイルの別個のイン
スタンスを与え；ウィンドウ・サービスによって与えら
れるファイルとの接続を有するプロセス１０２は、その
ファイルの多数のインスタンスの１つへの接続を有する
。 【００５３】各サービス１２３は、次の種類のサービス
・ファイル・ロケータ要求１２１を処理することができ
る。ａｔｔａｃｈ：指定されたサービス１２３における
ファイル木構造のルートに対するファイル指定子が与え
られると、そのルートに対するｑｉｄをファイル・シス
テム１０９に返す。ｗａｌｋ：所与の名前を有するファ
イルを求めてファイル指定子によって指定されたディレ
クトリ・ファイルを探査し、かつ求めるファイルが見つ
かった場合、そのファイルのｑｉｄにファイル指定子を
関係付けて、そのｑｉｄを返す。ｃｒｅａｔｅ：ファイ
ル指定子によって指定されたディレクトリ・ファイルに
新たなファイルを生成し、そのファイルに指定された名
前を与え、そのファイル指定子を新たなファイルに対す
るｑｉｄに関係付け、さらにそのｑｉｄを返す。ｒｅｍ
ｏｖｅ：ファイル指定子によって指定されたファイルを
サーバから削除し、ファイル指定子をｑｉｄから切り放
し、さらに削除中のファイルの名前を返す。 【００５４】さらに、各サービスは、次の種類のサービ
ス・ファイル・アクセス要求を処理することができる。 ｏｐｅｎ：ファイル・アクセス操作のために、ファイル
指定子によって指定されたファイルを準備し、そのファ
イル指定子に関係付けられたｑｉｄを返す。ｃｌｏｎｅ
：ファイルを表す第１のファイル指定子およびファイル
をまだ表していない第２のファイル指定子が与えられた
場合、第２のファイル指定子を第１のファイル指定子に
関係付けられたファイルに関係付ける。ｒｅａｄ：ファ
イル指定子、そのファイルにおけるオフセット、および
総数が与えられた場合、オフセットで始まる総数で指定
された数のバイトを読み出す。ｗｒｉｔｅ：ファイル指
定子、そのファイルにおけるオフセット、総数、および
データが与えられた場合、オフセットで始まる総数で指
定された数のバイトにデータを書き込む。ｃｌｕｎｋ：
ファイル指定子が与えられた場合、ファイル指定子とそ
のファイルとの間の関係付けを終了させる。ｓｔａｔ：
ファイル指定子およびファイル状態情報を得るためにサ
ービスによって必要とされる情報が与えられた場合、そ
のファイルの状態を返す。ｗｓｔａｔ：ファイル指定子
およびファイルの状態を変更するためにサービスによっ
て必要とされる情報が与えられた場合、そのファイルの
状態を変更する。 【００５５】すべてのサービス１２３は、前記の操作を
実施できなければならないが、操作が、実際には、全く
作用しなかったり、エラーを生じたりする場合もある。 例えば、サービス１２３が、プリンタで、書込み専用「
ファイル」しか実施できない場合には、読出し操作によ
ってエラーを生じることになる。 【００５６】カーネル・サービスおよびプロトコル・サ
ービス：図２ 第９案の好ましい実施例には、２種類のサービスがある
。カーネル・サービスは、サービス・ファイル操作要求
２０５および２０７が、第９案のカーネル関数の呼び出
しによって実施されるサービスである。プロトコル・サ
ービスは、サービス・ファイル操作要求２０５および２
０７が、第９案のファイル・プロトコルによって実施さ
れるサービスである。プロトコル・サービスにおいて、
各サービス・ファイル操作要求は、プロセス１０２のた
めにプロトコル・サービスに対して送られる往信メッセ
ージ（ｔｍｅｓｓａｇｅ）によって開始される。プロト
コル・サービスは、その往信メッセージに対し、プロト
コル・サービスからそのプロセスに返される情報を入れ
た返信メッセージ（ｒｍｅｓｓａｇｅ）によって応答す
る。プロトコル・サービスに対するサービス・ファイル
操作要求を構成する往信メッセージおよび返信メッセー
ジは、トランザクション（処理）と称する。例えば、プ
ロトコル・サービスに対するサービス・ファイル・リー
ド操作要求は、次のようなリード往信メッセージ（ｔｒ
ｅａｄ）およびリード返信メッセージ（ｒｒｅａｄ）か
らなるリード・トランザクションである。 ｔｒｅａｄ：　型指定子、ファイル識別子、タグ、オフ
セット、総数 ｒｒｅａｄ：　型指定子、ファイル識別子、タグ、総数
、データ ファイル識別子は、ファイル・システム１０９における
ファイル記述子、およびファイル・システム１０９およ
びプロトコル・サービスにおけるｑｉｄに関係付けられ
ている。ｔｒｅａｄメッセージには、このメッセージが
リード往信メッセージであることを示す型指定子、ファ
イル識別子、このメッセージを識別するタグ、読出しを
開始するべきファイル内のオフセット、およびバイト数
が、含まれる。ｒｒｅａｄメッセージには、このメッセ
ージがリード返信メッセージであることを示す型指定子
、ファイル識別子、このメッセージを識別するタグ、実
際に読み出されるバイト数、およびデータそのものが、
含まれる。 読出しの結果、エラーとなった場合、プロトコル・サー
ビス２０９は、ｒｒｅａｄメッセージの代わりに、エラ
ー・メッセージを返す。それは次のような形式である。 ｒｅｒｒｏｒ：　型指定子、タグ、エラー・メッセージ
文字列【００５７】各プロトコル・サービス２０９は、
先に掲げたサービス・ファイル操作要求のそれぞれに対
応するトランザクションを実行できなければならない。 プロトコル・サービス２０９に求められることは、これ
だけであるから、プロトコル・サービス２０９は、マウ
ント・サービス２０３が実行しているプロセッサのアー
キテクチャと完全に異なるアーキテクチャを有するプロ
セッサ上に実現しても良い。プロトコル・サービス２０
９を使用するために必要なことは、それによってプロト
コルが送受信され得るようなプロトコル・サービス２０
９への接続だけである。さらに、好ましい実施例では、
プロトコルによって送りかつ戻されるデータは、所与の
ファイル木構造を与えるすべてのプロトコル・サービス
２０９によって使用される所定の書式を有する。従って
、プロセス１０２は、このプロセス１０２がその上で実
行中の機械の種類またはプロトコル・サービス２０９が
その上で実行中の機械の種類にかかわらず、所与のファ
イル木構造を与える任意のプロトコル・サービスを使用
することができる。 【００５８】図２において、プロトコル・サービス（Ｐ
Ｓ）２０９は、前記のサービス・ファイル・ロケータ要
求およびサービス・ファイル・アクセス要求に対応する
ファイル・プロトコルを伴うファイル・ロケータ・トラ
ンザクション２０５およびファイル・アクセス・トラン
ザクション２０７を実行する。特殊なカーネル・サービ
スであるマウント・サービス２０３が、サービス・ファ
イル・ロケータ要求を指定する関数コール２１７および
サービス・ファイル・アクセス要求を指定する関数コー
ル２１９をファイル・システム１０９から受信する。次
に、マウント・サービス２０３は、これらの関数コール
に応じて、プロトコル・サービス２０９により対応する
トランザクションを行う。このトランザクションを行う
ために、マウント・サービス２０３は、多数の通信サー
ビス２１５を利用する。このような通信サービスには、
２種類ある：ネットワーク通信サービス（ＮＳ）２１４
およびプロセス間通信サービス（ＩＰＳ）２１６である
。ネットワーク通信サービスは、プロセス１０２が実行
中のＣＰＵにネットワークを介して接続されている遠隔
のプロトコル・サーバ２１３との通信にネットワークを
利用するものである。プロセス間通信サービス２１６は
、局所的なプロトコル・サーバ２１１との通信にプロセ
ス間通信システムを利用するものである。好ましい実施
例において、ＩＰＳ２１６によって使用されているプロ
セス間通信システムは、ＵＮＩＸオペレーティング・シ
ステムにおけるものと同様のパイプ・システムである。 通信サービス２１５が、プロトコル・サーバ２０９に接
続されると、このことが、ファイル記述子によって表さ
れる。「マウント」システム・コールで使用されるのは
、このようなファイル記述子である。 【００５９】括弧内の参照番号によって分かるように、
ネットワーク通信サービス２１５は、図７の分散ネット
ワーク７１３、長距離ネットワーク７１５、およびＤＭ
Ａネットワーク７０５を使用することができる。局所的
プロトコル・サービス２１１は、Ｇｎｏｔ７１１に対す
る８．５サービスのようなサービスの場合もあり、さら
には、プロセス間通信手段によって所与のプロセス１０
２と通信を行う別のプロセス１０２の場合もある。既に
指摘したように、プロトコル・サービス２０９とマウン
ト・サービス２０３のようなカーネル・サービスとの間
の区別は、位置ではなく、プロトコル・サービス２０９
がトランザクションをマウント・サービス２０３によっ
て行うという点に過ぎない。次の８．５サービスの説明
で詳細に示すとおり、プロトコル・サービス２０９に関
するこの特徴の利点は、局所的なプロセッサ上を走って
いるプロセス１０２および図７のＣＰＵのような遠隔の
プロセッサ上を走っているプロセス１０２が、共に同一
のプロトコル・サービス２０９を使用できることである
。 【００６０】第９案のファイル操作の実施以下において
、第９案のファイル操作の実施例を説明する。最初に、
ファイルを表すために使用されるデータ構造体ならびに
そのデータ構造体とプロセス１０２およびサービス１２
３との関係を説明し、次に、プロセスの名前空間１１５
を表すために使用されるデータ構造体、そして最後に、
典型的なファイル操作の例を説明する。 【００６１】プロセス１０２とファイルとの間の接続の
表現：図３〜５ プロセス１０２が接続を有する先のファイルは、チャネ
ル・データ構造体によって表される。あるファイルに対
するチャネル・データ構造体は、少なくとも、そのファ
イルを与えているサービス１２３を指定し、かつサービ
ス１２３によって与えられるｑｉｄを、プロセス１０２
がそのファイルを示すために使用するファイル記述子に
関係付ける。サービス１２３がプロトコル・サービス２
０９である場合には、そのチャネルは、さらに、そのフ
ァイル・プロトコルにおけるファイルに対して使用され
るファイル識別子およびプロトコル・ファイルに対する
プロトコル・チャネルを、ファイル記述子に関係付ける
。 【００６２】図３において、チャネル・データ構造体３
０１は、次の構成要素を有する。即ち、ロック３０３：
１つ以上のプロセスが同時にチャネル３０１にアクセス
を有することを防ぐ。参照指数（ｒｅｆ）３０７：チャ
ネルが他のカーネル・データ構造体によって指し示され
たかどうかを示す。ネクスト／オフセット・フィールド
３０９：チャネル３０１が使用されていない場合、この
フィールドは、使用されていないチャネル３０１のリス
トに格納されていて、さらにこの場合、使用されていな
い次のチャネル３０１を示す；チャネル３０１によって
表されるファイルがアクセスされている場合、このフィ
ールドは、そのファイルへの現在のオフセットを示す。 カーネル・サービス情報（ＫＳＩＮＦＯ）３１１：チャ
ネル３０１によって表されるファイルを与えるカーネル
・サービスを指定する情報が、次の２つのフィールドに
収容される−−−種類３１３：このフィールドにより、
チャネル３０１によって表されるファイルがアクセスさ
れる手段としてのカーネル・サービスが指定され；プロ
トコル・サービス２０９に対しては、種類フィールド３
１３によってマウント・サービス２０３が指定される；
装置（ＤＥＶ）３１５：このフィールドにより、カーネ
ル・サービスによって表される特定の装置が指定され；
マウント・サービス２０３の場合は、装置フィールド３
１５により、チャネル３０１によって表されるファイル
を与えるプロトコル・サービス２０９が指定される。ア
クセス情報（ＡＩＮＦＯ）３１７：ファイル・アクセス
を行うために必要な情報が、次の３つのフィールドに収
容される−−−モード３１９：チャネルによって表され
るファイルが如何にアクセスされるかを示す；フラグ３
１９：ファイルに関する状態情報を収容する；ｑｉｄ３
２３：ファイルを与えるサービスが、そのファイルに割
り当てたｑｉｄである。マウント情報（ＭＩＮＦＯ）：
チャネル３０１によって表されるファイルのパス名に影
響を及ぼすｂｉｎｄおよびｍｏｕｎｔに関する情報がど
こにあるかを示す。ｍｏｕｎｔｐｔｒ３２７：ｂｉｎｄ
およびｍｏｕｎｔに関する情報があるデータ構造体への
ポインタである。ｍｏｕｎｔｉｄ３２９：ｍｏｕｎｔｐ
ｔｒ３２７によって示されるデータ構造体の識別子であ
る。ファイル識別子（ＦＩＤ）３３１：マウント・サー
ビス２０３がチャネル３０１によって表されるファイル
を与えているプロトコル・サービス２０９に与えるファ
イル識別子であり、かつそのファイルが接続されている
限り、プロトコル・サービス２０９がそのファイルに対
するｑｉｄ３２３に関係付けるファイル識別子である；
好ましい実施例において、チャネル３０１が生成された
とき、ファイル識別子３３１は、各チャネル３０１に対
し固有の値に設定される。補助情報３３３：装置の種類
３１３によって意味が変わる情報。プロトコル・サービ
ス情報（ＰＳＩＮＦＯ）３３５：チャネル３０１によっ
て表されるファイルを与えているプロトコル・サービス
にファイル・プロトコルが如何にして送られるかを示す
情報である。プロトコル・チャネル（ＰＣＨＡＮ）３３
７：現在のチャネル構造体によって表されるファイルに
関するトランザクションのために使用される通信サービ
ス２１５を表すチャネル構造体３０１へのポインタであ
る。ｍｑｉｄ３３９：チャネル３０１によって表される
ファイルを収容しているプロトコル・サービスにおける
ファイル木構造のルート・ディレクトリのｑｉｄである
。 【００６３】各プロセス１０２は、そのプロセスが接続
を有する先のファイルの集合に関係付けられている。こ
のファイルの集合には、プロセス１０２の祖先（以前の
代のプロセス）によって確立された接続の接続先であり
、かつプロセス１０２が「ｆｏｒｋ」システム・コール
によって生成されたときに、それによって「継承」され
たファイル、およびプロセス１０２自体によって確立さ
れた接続の接続先のファイルが、含まれる。この関係付
けは、図４に示したデータ構造体４０１によって達成さ
れる。さらに、データ構造体４０１は、前記の集合に属
する各ファイルを、プロセス１０２がそのファイルを参
照するために使用するファイル記述子に関係付ける。 【００６４】データ構造体４０１へのアクセスするため
の開始点は、プロセス１０２に対するユーザ・データ構
造体４０３である。ユーザ・データ構造体４０３におけ
るポインタ４１１は、ファイル記述子の配列（ＦＤＡ）
４１３を示す。ファイル記述子の配列４１３は、ファイ
ル記述子（ＦＤ）４１７によってインデックス付けされ
たチャネル４０１へのポインタの配列である。あるファ
イルが、プロセス１０２に接続されたファイルの集合に
属する場合、そのファイルに対するファイル記述子に対
応する配列４１３におけるエントリ（ＦＤＡＥ）４１５
には、そのファイルに対するチャネル構造体３０１への
ポインタ４２３が入る。このようなチャネル構造体は、
図４においてファイル・チャネル構造体４１９として現
れる。プロセス１０２が接続される接続先のファイルの
集合に対応するファイル・チャネル４１９の集合がある
。好ましい実施例において、ファイル記述子の配列４１
３は、１００の要素を有するので、各プロセス１０２は
、１００のファイルに接続することができる。 【００６５】既に指摘したように、「ｂｉｎｄ」、「ｍ
ｏｕｎｔ」、「ｃｈｄｉｒ」および「ｏｐｅｎ」などの
ファイル・ロケータ関数は、引数としてパス名を取り、
そのファイルに対するファイル記述子４１７を返す。さ
らに詳細に後述するように、パス名の解釈を目的とする
ファイル・チャネル４１９へのアクセスが、プロセス１
０２のファイル木構造のルートに対するファイル・チャ
ネル４１９へのユーザ・データ構造体４０３におけるポ
インタ、およびプロセス１０２のワーキング・ディレク
トリに対するファイル・チャネルへのもう１つのポイン
タ４０９によって与えられる。パス名の解釈において使
用されるユーザ・データ構造体４０３のもう１つの構成
要素は、要素（ＥＬＥＭ）４０５であり、これには、現
在解釈されているパス名を構成する名前のリストにある
名前が入っている。 【００６６】ファイル・チャネル４１９によって表され
るファイルが、プロトコル・サービス２０９によって与
えられると、ファイル・チャネル４１９は、通信サービ
スを介するプロトコル・サービス２０９との接続を表す
プロトコル・チャネルに関係付けられる。プロトコル・
チャネルは、チャネル構造体３０１を用いても実施され
る。プロトコル・チャネルとして作用するチャネル構造
体３０１において、種類フィールド３１３によって、プ
ロセス間通信サービス２１６またはネットワーク・サー
ビス２１４（好ましい実施例においては、パイプ・サー
ビスまたはＤＡＴＡＫＩＴネットワーク通信サービス）
の何れかが指定される。フィールド３２７、３２９およ
び３３７は、プロトコル・チャネルにおいては無意味で
ある。プロトコル・チャネルによって表される接続がプ
ロセス１０２によって開かれた場合、プロトコル・チャ
ネルへのポインタが、プロセス１０２に対するファイル
記述子の配列４１３に配置され、さらにプロトコル・チ
ャネルが、それに対応するファイル記述子を受け取る。 局所的なプロトコル・サービスへのパイプによる接続は
、そのパイプ生成しているパイプ・システム・コールが
プロセス１０２によって実行されたときに、開かれ、遠
隔のプロトコル・サービス２０９へのＤＡＴＡＫＩＴ接
続による接続は、ｓｒｖサービス中にその遠隔のプロト
コル・サービス２０９を表すファイルが開かれたときに
、開かれる。 【００６７】実施例においてファイル・チャネル４１９
をプロトコル・チャネルならびにｔｍｅｓｓａｇｅおよ
びｒｍｅｓｓａｇｅを表すデータ構造体に関係付けるた
めに使用されるデータ構造体５０１を図５に示す。前記
のように、ファイル・チャネル４１９のＰＣＨＡＮフィ
ールド３３７は、プロトコル・チャネル５１７を示すが
、このプロトコル・チャネルは、チャネル構造体３０１
を用いて実施される。ｔｍｅｓｓａｇｅおよびｒｍｅｓ
ｓａｇｅを表すデータ構造体は、マウント・サービス配
列（ＭＮＴＡ）５０２を用いて、その位置が特定される
。この配列には、すべてのファイル・チャネル４１９に
対して、プロトコル・サービス２０９によって与えられ
るファイルを表すエントリ（ＭＮＴＥ）５０３が存在す
る。各エントリ５０３には、１つの識別子および２つの
ポインタ−−−エントリ５０３に対応するファイル・チ
ャネル４１９へのポインタおよびマウント・サービス・
キュー（待ち行列）の構造体（ＭＮＴＱ）５０９へのポ
インタ−−−が含まれる。一方、ファイル・チャネル４
１９は、装置フィールド３１５の情報の一部として、エ
ントリ５０３に対する識別子を含む。マウント・サービ
ス・キューの構造体５０９には、ファイル・チャネル４
１９が属するプロシージャを表すデータ構造体、プロト
コル・サービス２０９への接続とファイル・チャネル４
１９によって表されるファイルを含むファイル木構造１
２５とを表すプロトコル・チャネル５１７へのポインタ
５１５、およびメッセージ５２０の待ち行列へのポイン
タ５１９が含まれる。この待ち行列にあるメッセージは
、勿論、プロトコル・サービス２０９へのファイルを収
容したｔｍｅｓｓａｇｅおよびプロトコル・サービス２
０９からのｒｍｅｓｓａｇｅである。従って、マウント
・サービスの待ち行列５０９によって、メッセージの待
ち行列が、プロトコル・チャネル５１７およびプロセス
１０２に関係付けられる。 【００６８】各メッセージ５２０は、少なくともマウン
ト・サービス・ヘッダ（ＭＮＴＨＤＲ）５２１から構成
される。ファイル・チャネル４１９によって表されるフ
ァイルおよびプロセスの組み合わせに対し１つ以上の未
解決のメッセージが存在することがあるので、マウント
・サービス・ヘッダ５２１には、ファイル・チャネル４
１９によって表されるプロセスとファイルの組み合わせ
に対する他のメッセージへのヘッダにヘッダ５２１を連
結するポインタ５２７および５２９が含まれる。マウン
ト・サービス・ヘッダ５２１は、さらに、ファイル・チ
ャネル４１９が所属するプロセスに対するプロセス・デ
ータ構造体へのポインタを含む。 【００６９】メッセージ５２０が、ｒｍｅｓｓａｇｅで
ある場合、そのメッセージのデータ以外の部分は、ｒｈ
ｄｒ５２５に置かれ、ｔｍｅｓｓａｇｅである場合は、
受信されたメッセージのデータ以外の部分は、ｔｈｄｒ
５２３に置かれる。このように、これらのフィールドに
は、メッセージの型、マウント・サービス２０３がファ
イルに関係付けたファイル識別子、および必要に応じた
その他の情報が、含まれる。例えば、メッセージがライ
ト往信（ｔｗｒｉｔｅ）メッセージの場合、ｔｈｄｒ５
２３には、そのメッセージの型、そのファイルのファイ
ル識別子、書き込むべきバイト数、および書込み開始位
置のオフセットが含まれる。さらに、ｔｈｄｒ５２３お
よびｒｈｄｒ５２５には、そのメッセージによって送信
または受信されるデータを収容するマウント・バッファ
５３３へのポインタ５３１が含まれる。 【００７０】メッセージ７２０は、引数としてファイル
・チャネル４１９に対応するエントリ５０３およびマウ
ント・ヘッダ５２１を取る関数によって送信される。こ
の関数は、エントリ５０３を用いてプロトコル・チャネ
ル５１７の位置の特定し、マウント・ヘッダ５２１によ
って指定されたメッセージ５２０が、プロトコル・チャ
ネル５１７によって指定された接続に出力される。送信
と同時に、そのメッセージを送信中のプロセス１０２は
、応答を求めて待機する。応答は、受信されると、メッ
セージ５２０に置かれ、プロセス１０２が起こされ、こ
のプロセスによって、メッセージ５２０が読まれる。 実施例においては、メッセージ内のタグを用いて、適切
なマウント・ヘッダのデータ構造体５２１の位置を特定
する。第９案において所与のファイル・チャネル４１９
に対する構造体の位置を特定する役の関数は、その役を
果たすべく、所与のファイル・チャネル４１９へのポイ
ンタ５０５が入っているエントリ５０３を発見するまで
マウント・サービスの配列５０２を逐一あたっていく。 ファイル・チャネルは、その装置フィールド３１５に対
応するエントリ５０３に対する識別子を入れているとい
う事実によって識別することが可能である。 【００７１】以上のように、図３から図５に示したデー
タ構造により、ファイルに対するファイル記述子を有す
るプロセス１０２は、そのファイルに対して読出しおよ
び書込みなどのファイル・アクセス関数を実行すること
ができる。しかし、これだけでは、ファイル・ロケータ
関数を実行するには不十分である。なぜなら、これらの
関数には、ファイル記述子だけでなくパス名も関係する
からである。 【００７２】名前空間１１５の表現：図６、８および９
前記のように、新しいプロセス１０２の名前空間１１５
は、そのプロセス１０２の親から継承されるか、親の名
前空間を継承しないプロセス１０２に対し第９案が利用
できるようにした「控え」の名前空間から作られるかの
何れかである。プロセス１０２の名前空間１１５が「控
え」の名前空間から如何にして作られるかを図６に概念
的に示した。図６の「控え」の名前空間６０１は、単一
レベルのファイルを有するルート・ディレクトリ６０３
を与えるカーネル・サービスであるルート・サービスに
よって、与えられる。ルート・ディレクトリ６０３およ
びファイル６０５および６１５は、他のサービス１２３
に属するファイル木構造１２５のルートが結合される可
能性のある場所として作用するだけである。実施例では
、ファイル６０５〜６１５の集合は、サービスの種類を
機能によって分けるのに役立つ。ファイル名は、機能に
次のように対応する。ｄｅｖ６０５：サービスが結合さ
れる主な場所である。Ｉ／Ｏ関数を与えるサービスおよ
びその他の種々雑多な機能を有するサービスは、すべて
ｄｅｖ６０５に結合される。ｂｏｏｔ６０７：第９案が
実施されているＣＰＵをブートするサービスが結合され
る場所である。ｆｄ６０９：プロセスの接続されたファ
イルに対する複製のファイル記述子を与えるサービスが
結合される場所である。ｐｒｏｃ６１０：第９案のプロ
セスに付いての情報を与えるサービスが結合される場所
である。ｅｎｖ６１１：プロセス１０２に対する環境フ
ァイルを与えるサービスが結合される場所である。環境
ファイルは、ＵＮＩＸの環境変数と同じ機能を果たす。 ｂｉｎ６１３：プロセス１０２によって実行されるプロ
グラムのファイルを収容するサービスが結合される場所
である。そして、ｓｒｖ６１５：プロセス１０２が利用
できるプロトコル・ザーバ２０９に対するプロトコル・
チャネル５１７を表すファイルを与えるサービスが結合
される場所である。 【００７３】第９案には、控えの木構造６０１における
ファイル名に結合できる組み込みサービスの集合がある
。これらのサービスには、プロセス１０２によって実行
される第９案のカーネル関数によってのみ結合できるも
のと、プロセス１０２によって実行される任意の関数に
よって結合できるものとがある。第９案のパス名におい
て、組み込みサービスの名前には、その前に文字「＃」
が付く。カーネル関数によってのみ結合され得る組み込
みサービスは、次のとおりである。即ち、＃／：控えの
木構造６０１を与えるカーネル・ルート・サービス、＃
：プロセス間通信のためにＵＮＩＸ風のパイプを与える
カーネル・パイプ・サービス、および＃Ｍ：プロトコル
・サービス２０９に関するトランザクションを処理する
マウント・サービス６０３である。尚、カーネルは、ル
ート・サービスをプロセス１０２の名前空間のルートに
結合する。 【００７４】プロセス１０２によって実行される任意の
関数によって結合できる組み込みサービスには、次のも
のがある。＃ｂ：ブート・サービス。このサービスは、
ファイルを幾つか有し、このファイルに書き込まれると
、このファイルによってカーネルは所与のアドレスに分
岐させられ、またこのファイルにより、カーネルは仮想
メモリの所与の位置に書き込むことができる。ブート・
サービスは、概してｂｏｏｔ６０７に結合される。＃ｂ
：ビット・サービス。このサービスは、ビット・マップ
・スクリーンおよびマウスを表すファイルを有する。ビ
ット・サービスは、概してｄｅｖ６０５に結合される。 ＃ｃ：コンソール・サービス。このサービスは、システ
ム・コンソールを表すファイルを有し、概してｄｅｖ６
０５に結合される。＃ｄ：複製サービス。このサービス
によって与えられるファイルは、プロセス１０２に属す
る接続されたファイルに対するファイル記述子であるよ
うな名前を有する。複製サービスは、概してｆｄ６０９
に結合される。＃ｅ：環境サービス。このサービスによ
って与えられるファイルは、概してｅｎｖ６１１に結合
される。 ＃ｋｎａｍｅ：ｄａｔａｋｉｔサービス。このサービス
によって与えられるファイルは、ｎａｍｅによって表さ
れるｄａｔａｋｉｔハードウェア上の会話を表す。この
サービスは、概してｄｅｖ６０５に結合される。＃ｐ：
プロセス・サービス。これは、概してｐｒｏｃ６１０に
結合される。＃ｓ：サービス登録サービス。このサービ
スによって与えられるファイルは、プロトコル・サービ
ス２０９に接続され既に開いているプロトコル・チャネ
ル５１７を表す。 【００７５】第９案の実施例において、その名前空間１
１５を継承しなかったプロセス１０２がＧｎｏｔ７１１
において走り始めると、Ｇｎｏｔ７１１上で実行中のカ
ーネルが、ｂｉｎｄ処理を実行する。このｂｉｎｄ処理
によって、前記の名前空間１１５には、木構造６１７と
して示した形式が与えられる。木構造６０９における名
前にサービスが結合されていた場合、この事実は、「＝
」の後にそのサービス名を付けることによって示される
。ｂｉｎｄ処理によって結合ディレクトリが生成された
場合、この事実は、「＝」に続く括弧内にその結合ディ
レクトリの構成要素をリストとして載せることによって
示される。このリストは、それらの構成要素が探査され
る順番になっている。木構造６１７は、ｂｉｎｄおよび
ｍｏｕｎｔの処理からなる次のような手順で生成された
ものである。ｂｉｎｄ：ルート・サービスによって与え
られる木構造を、プロセス１０２によって解釈されたパ
ス名におけるルートを表す「／」に結合する。「／」へ
の参照は、ここでは「／」６０３への参照として解釈さ
れる。ｍｏｕｎｔ（ＦＤ，”／”，ＭＡＦＴＥＲ，””
）：マウント・サービス２０３に属するプロトコル・チ
ャネル５１７を「／」にマウントし、これによって、ル
ート・サービスのルートおよびプロトコル・チャネル５
１７によって表されるプロトコル・サービス２０９のル
ートからアクセス可能なファイルから成る結合ディレク
トリを生成する。第９案においては、このプロトコル・
サービス２０９によって、デフォルト・ファイル・サー
バ７０５内にデフォルトのファイル木構造１２５が与え
られる。ｂｉｎｄ（”／６８０２０／ｂｉｎ”，”／ｂ
ｉｎ”，ＭＲＥＰＬ）：デフォルトのファイル木構造１
２５におけるディレクトリ／６８０２０／ｂｉｎをルー
トとして持つような木構造を控えのファイル木構造６０
１における名前ｂｉｎ６１３に結合する。ディレクトリ
／６８０２０／ｂｉｎには、Ｇｎｏｔ７１１（実施例で
は、モトローラ社の６８０２０プロセッサを有する）の
ための実行可能なコードが入っている。ｂｉｎｄ（”／
ｌｉｂ／ｒｃ”，”／ｂｉｎ”，ＭＡＦＴＥＲ）：デフ
ォルトの木構造１２５における／ｌｉｂ／ｒｃをルート
として持つような木構造を名前ｂｉｎ６１３に結合する
。ディレクトリ／６８０２０／ｂｉｎは既にｂｉｎ６１
３に結合されているので、ＭＡＦＴＥＲが指定されてい
る。結果として、ディレクトリ／６８０２０／ｂｉｎが
ディレクトリ／ｌｉｂ／ｒｃより先に探査されるような
結合ディレクトリとなる。ｂｉｎｄ（”＃ｃ”，”／ｄ
ｅｖ”，ＭＲＥＰＬ）：コンソール・サービス＃ｃによ
って与えられる木構造を名前ｄｅｖ６０５に結合する。 最後に、ｂｉｎｄ（”＃ｄ”，”／ｆｄ”，ＭＲＥＰＬ
）：複製サービス＃ｄによって与えられる木構造を控え
の木構造６０１における名前ｆｄに結合する。 【００７６】これらの結合の結果として、プロセッサ１
０２は、＃Ｍ１が接続される先のプロトコル・サービス
２０９のディレクトリ／６８０２０／ｂｉｎにある「ｃ
ｃ」というファイルをパス名「／ｂｉｎ／ｃｃ」によっ
て参照することができ、また同じプロトコル・サービス
２０９の／ｌｉｂ／ｒｃにある「ｐｗｄ」というファイ
ルをパス名「／ｂｉｎ／ｐｗｄ」によって参照すること
ができる。勿論、これは、ディレクトリ／６８０２０／
ｂｉｎにファイル「ｐｗｄ」が無い場合である。同様に
、サービス＃ｃによって与えられるファイル「ｐｉｄ」
ならば、パス名「／ｄｅｖ／ｐｉｄ」によって参照する
ことができ、またサービス＃ｄによって与えられるファ
イル「０」であれば、パス名「／ｆｄ／０」によって参
照することができる。 【００７７】従って、第９案のプロセスに対する名前空
間には、名前空間１１５における名前に対して実行され
たｂｉｎｄ処理およびｍｏｕｎｔ処理のすべての記録が
入っていなければならない。ここでは、この記録をマウ
ント・テーブルと称する。本実施例のマウント・テーブ
ルは、ファイルに対するファイル・チャネル４１９が、
そのファイルに対するパス名を明示的に表すという事実
を利用している。従って、ｂｉｎｄおよびｍｏｕｎｔの
処理記録は、ｂｉｎｄ処理またはｍｏｕｎｔ処理で使用
された古いパス名によって表されるファイルを表すファ
イル・チャネル４１９と、ｂｉｎｄ処理で使用された新
たなパス名によって指定されるファイルを表すファイル
・チャネル４１９またはｍｏｕｎｔで処理で使用された
ファイル記述子に対応するファイル・チャネル４１９と
の間に関係を確立することによって、作ることも可能で
ある。勿論、これらのファイル・チャネル４１９は、す
べて、現在のプロセス・グループ１０３がその名前空間
を受け継いだ元のプロセス・グループ１０３の中のいく
つかのプロセス１０２に接続されているか、または現在
のプロセス・グループ１０３の中のいくつかのプロセス
１０２によって接続されているようなファイルを表す。 【００７８】図８において、マウント・テーブルの構成
要素は、マウント・テーブル配列８０２から位置が特定
され、配列８０２は、ユーザ・データ構造体４０３から
位置が特定される。図８に示したように、ユーザ構造体
４０３は、プロセス（ＰＲＯＣ）のデータ構造体８２５
へのポインタ８２４を含む。各プロセス１０２は、ユー
ザ構造体４０３およびプロセス・データ構造体８２５を
持つ。ポインタ８２４は、そのプロセス１０２のプロセ
ス・データ構造体へのユーザ構造体４０３のポインタで
ある。プロセス・データ構造体８２５は、さらにマウン
ト・サービス・キューの構造体５０９におけるポインタ
５１１によっても示され、かつそれ自体に、プロセス・
グループ（ＰＲＧＲＰ）の構造体８２７へのポインタを
含んでいる。構造体８２７は、プロセス１０２が属する
プロセス・グループ１０３を表す。最終的に、プロセス
・グループ構造体８２７に、マウント・テーブル配列８
０２へのポインタ８２９が含まれることによって、ユー
ザの構造体４０３が属するプロセス１０２に対するマウ
ント・テーブル８０１の位置づけが可能となる。 【００７９】マウント・テーブル配列８０２は、新たな
パス名またはファイル記述子が結合される古いパス名の
それぞれに対する要素（ＭＴＥ）からなる。所与のマウ
ント・テーブル配列のエントリ８０３は、２つのポイン
タからなる。ポインタ８０５は、古いパス名によって指
定されるファイルを表すファイル・チャネル・データ構
造体４１９へのポインタである。マウント・テーブル８
０１との関係から、このようなデータ構造体４１９を左
手チャネル（ＬＣＨＡＮ）と称する。ポインタ８０７は
、マウント構造体８０９へのポインタである。各マウン
ト構造体８０９は、ｂｉｎｄまたはｍｏｕｎｔの１回の
処理結果を表す。マウント構造体８０９の内容には、次
のものが含まれる。参照フィールド（ｒｅｆ）８１１：
これは、マウント・テーブル配列のエントリ８０３によ
って示されるもの以外の左手チャネルが、マウント構造
体を使用しているかどうかを示す。終端フィールド８１
３：これは、マウント構造体８０９が、結合ディレクト
リを定義するマウント構造体８０９のリストの最後であ
るかどうかを示す。マウント識別子フィールド８１５：
これは、このマウント構造体８０９に対する固有の識別
子であり、従って、マウント構造体８０９によって表さ
れるｂｉｎｄまたはｍｏｕｎｔの処理の結果に対する識
別子でもある。ポインタ８１７：マウント構造体８０９
が、結合ディレクトリを定義しているマウント構造体８
０９のリストの一部であり、かつそのリストの最後のマ
ウント構造体８０９でない場合、ポインタ８１７は、そ
のリストの次のマウント構造体を示す。ポインタ８１９
：このポインタは、新たなパス名によって（または、ｍ
ｏｕｎｔの場合には、ファイル記述子によって）指定さ
れるファイルを表すファイル・チャネル４１９を示す。 マウント・テーブルの関係から、このようなファイル・
チャネルを右手チャネル（ＲＣＨＡＮ）８０４と称する
。 【００８０】以上から分かるように、各マウント・テー
ブル・エントリ８０３によって、左手チャネル８０２と
１つ以上の右手チャネル８０４との間の関係が確立され
る。さらに、ｍｏｕｎｔまたはｂｉｎｄ処理のためにそ
のパス名の意味が変更されたファイルを表すファイル・
チャネル４１９においては、マウント・ポインタ（ｍｏ
ｕｎｔｐｔｒ）フィールド３２７が、そのｍｏｕｎｔま
たはｂｉｎｄ処理を表すマウント構造体８０９を示し、
さらにマウント識別子（ｍｏｕｎｔｉｄ）フィールド３
２９には、そのマウント構造体８０９のマウント識別子
８１５が入る。さらに、プロトコル・サーバ２０９によ
って与えられるファイルを表すファイル・チャネル４１
９は、そのファイルを与えるプロトコル・サービス２０
９への接続に対するプロトコル・チャネル５１７へのポ
インタをフィールド３３７に含む。 【００８１】また、図８において、「ｍｏｕｎｔ」およ
び「ｂｉｎｄ」処理のｒｅｐｌａｃｅ、ｂｅｆｏｒｅ、
およびａｆｔｅｒの各オプションが、マウント・テーブ
ル８０１により如何にして実施され得るかを説明する。 ｒｅｐｌａｃｅオプションが付いた場合、新たなパス名
を表す右手チャネル８０４を示すマウント構造体８０９
は、単にマウント構造体８０９のリストの代わりをする
。ｂｅｆｏｒｅオプションは、そのマウント構造体８０
９をマウント構造体８０９のリストの先頭に追加するが
、マウント構造体８０９のリストがない場合には、エラ
ーを発生する。ａｆｔｅｒオプションを付けると、その
マウント構造体８０９が、前記リストの最後に追加され
る。この時も、そのリストがない場合には、エラーとな
る。結合ディレクトリが探査される場合、前記リストの
最初のマウント構造体８０９によって示される右手チャ
ネル８０４によって表されるディレクトリから探査され
る。次に探査されるべきディレクトリは、そのリストの
２番目のマウント構造体８０９によって示される右手チ
ャネル８０４によって表されるディレクトリというふう
に、探査される。従って、左手チャネル８０２（ａ）が
、パス名／Ｍを表し、かつ右手チャネル８０４（ａ）が
、／Ｍに結合されたサービス１２３から１番目のルート
・ディレクトリを表し、かつ右手チャネル８０４（ｂ）
が、／Ｍに結合されたサービス１２３から２番目のルー
ト・ディレクトリを表すならば、「ｃｈｄｉｒ（”／Ｍ
／．”）」のようなファイル・ロケータ関数は、「Ｏ」
を求めて、最初は１番目のディレクトリを探査し、それ
がそこで発見できない場合は、２番目のディレクトリを
探査する。 【００８２】前述のように、プロセス１０２が、システ
ム・コール「ｆｏｒｋｐｇｒｐ」を実行すると、必ず、
プロセス１０２に対する新たな名前空間１１５が生成さ
れる。 「ｆｏｒｋｐｇｒｐ」は、引数を１つだけ取る。この引
数が、０以外の値を持つときは、ｆｏｒｋｇｒｐを実行
しているプロセス１０２に対する既存の名前空間１１５
は、新たな名前空間１１５にコピーしてはならない。こ
の引数が値０を有する場合、その既存の名前空間は、コ
ピーされるべきものである。「ｆｏｒｋｇｒｐ」に「０
」でない引数を付けて実行すると、ｆｏｒｋｇｒｐは、
単に、プロセス１０２に対する新たなプロセス・グルー
プ構造体８２７および新たなマウント・テーブル配列８
０２を作るだけである。そして、新たな名前空間１１５
を定義するｂｉｎｄおよびｍｏｕｎｔ処理に必要とされ
るようなマウント・テーブル・エントリ８０３が、生成
される。引数「０」を付けてｆｏｒｋｐｇｒｐが実行さ
れると、その「ｆｏｒｋｐｇｒｐ」システム・コールを
実行中のプロセス１０２に対するマウント・テーブル配
列８０２におけるマウント・テーブル配列のエントリ８
０３が、新たなマウント・テーブル配列８０２へとコピ
ーされる。これが行われると、所与のマウント・テーブ
ル・エントリ８０３によって示される各左手チャネル８
０２におけるｒｅｆフィールド３０７およびそのエント
リによって示される各マウント構造体８０９におけるｒ
ｅｆフィールド８１１がインクリメントされる。以上か
ら明らかなように、本実施例においてはマウント・テー
ブル８０１を実施しているので、プロセスに対し新たな
名前空間１０５を生成することは、比較的効率的かつ安
価な作業である。 【００８３】図９において、チャネル構造体３０１を長
い長方形で表した。チャネル構造体３０１のラベルは、
そのチャネル構造体３０１によって表されるファイルの
パス名を示す。第１のマウント・テーブル配列エントリ
８０３（ｂ）により、ルート「／」上のｂｉｎｄおよび
ｍｏｕｎｔ操作の結果が記録される。ルート「／」を表
すＬＣＨＡＮ８０２（ｂ）が、エントリ８０３（ｂ）お
よび２つのマウント構造体８０９（ｃ）および（ｄ）を
介して２つの右手チャネルに接続されている。これらの
右手チャネルのうち、８０４（ｃ）は、カーネル・ルー
ト・サービスによって与えられるファイル木構造のルー
トに対するもので、８０４（ｄ）は、＃Ｍ１が接続され
ている先のプロトコル・サービス２０９によって与えら
れるファイル木構造のルートに対するものである。右手
チャネル８０４（ｄ）におけるｍｃｈａｎポインタ３３
７は、ルートへの接続を表すプロトコル・チャネル５１
７を示す。 【００８４】第２のマウント・テーブル配列エントリ８
０３（ｃ）によって、左手チャネル８０２（ｃ）によっ
て表される、＃／ｂｉｎ上のｂｉｎｄ操作の結果が記録
される。 チャネル８０２（ｃ）は、２つの右手チャネル−−−＃
Ｍ１／６８０２０／ｂｉｎを表す８０４（ｅ）および＃
Ｍ１／ｌｉｂ／ｒｃを表す８０４（ｆ）−−−に接続さ
れている。右手チャネル８０４（ｄ）および（ｅ）によ
って表されるファイルは、＃Ｍ１の接続先のプロトコル
・サービス２０９によって与えられるので、前記の右手
チャネルは、共に、サービス２０９への接続を与えるプ
ロトコル・チャネル５１７へのｍｃｈａｎポインタ３３
７を含む。さらに、左手チャネル８０２（ｃ）によって
表されるファイルのパス名＃／ｂｉｎには、パス名＃／
が含まれる。そのディレクトリ・ファイルは、右手チャ
ネル８０４（ｃ）によって表される。従って、左手チャ
ネル８０２（ｃ）のマウント・ポインタ（ｍｏｕｎｔｐ
ｔｒ）フィールド３２７には、右手チャネル８０４（ｃ
）を示すマウント構造体８０９（ｃ）へのポインタが入
る。 【００８５】マウント・テーブル９０１の残りの部分か
ら分かるように、右手チャネル８０４によって表される
構成要素を含むパス名を表すマウント・テーブル９０１
における１つ１つのファイル・チャネル４１９に、その
構成要素を表す右手チャネル８０４を示すマウント構造
体８０９へのｍｏｕｎｔｐｔｒフィールド３２７におけ
るポインタが、含まれる。従って、＃／を含むパス名を
有するファイルを何れも表すような左手チャネル８０２
（ｃ）、８０２（ｄ）および８０２（ｅ）は、すべてマ
ウント構造体８０９（ｃ）を示す。一方、＃Ｍ１を含む
パス名を有するファイルを双方とも表すような右手チャ
ネル８０４（ｅ）および８０４（ｆ）は、すべてマウン
ト構造体８０９（ｄ）を示す。勿論、ｍｏｕｎｔｐｔｒ
フィールド３２７が、マウント構造体８０９を示すとき
は、チャネル３０１におけるｍｏｕｎｔｉｄフィールド
３２９が、そのマウント構造体８０９に対するマウント
識別子に設定される。 【００８６】残りのエントリ８０３（ｄ）および８０３
（ｅ）によって、カーネル・ルート・サービス＃／によ
って与えられる「控え」のディレクトリ「ｄｅｖ」およ
び「ｆｄ」への組み込みカーネル・サービスの結合が、
記録される。この場合、各エントリ８０３によって、控
えのディレクトリを表す左手チャネル８０２は、組み込
みカーネル・サービスを表す右手チャネル８０４に関係
付けられる。組み込みカーネル・サービスは、プロトコ
ル・サービスではないので、右手チャネルは、プロトコ
ル・チャネル５１７へのポインタは持っていない。 【００８７】名前空間１１５におけるパス名の分析：図
１０および１１ 前記のとおり、マウント・テーブル８０１は、第９案の
ファイル・チャネル４１９は、いずれも、そのファイル
・チャネル４１９によって表されるファイルのパス名を
明示的に表すという事実を利用している。第９案のオペ
レーティング・システムに、「ｂｉｎｄ」、「ｍｏｕｎ
ｔ」、「ｃｈｄｉｒ」および「ｏｐｅｎ」などのファイ
ル・ロケータ関数において、パス名が提示されると、オ
ペレーティング・システムは、そのパス名によって指定
されたファイルを表すファイル・チャネル４１９を得る
ことによって、そのパス名を分析して、そのファイル・
チャネル４１９へのポインタを返す。プロセス１０２の
ファイル木構造１１７は、サービス１２３によって与え
られるファイル木構造で構成されるので、パス名の分析
には、マウント・テーブル８０１および各サービス１２
３が応答するサービス要求が、共に関与する。これらの
特別なサービス要求は、ｗａｌｋサービス・ファイル・
ロケータ要求であり、場合によっては、ａｔｔａｃｈサ
ービス・ファイル・ロケータ要求である。 【００８８】パス名を分析する第９案のカーネル関数を
（チャネルへの名前として）「ｎａｍｅｃ」と称する。 この関数の流れ図を図１０に示す。コールの端子１００
３に示したように、ｎａｍｅｃが引数として取るものは
、パス名、ｎａｍｅｃを用いるシステム・コールが必要
とするファイル・アクセスの種類のコード、およびｎａ
ｍｅｃによって開かれるファイルが如何にして開かれる
べきかを示すコードである。ｎａｍｅｃは、チャネルへ
のポインタを返す。ｎａｍｅｃは、パス名の最初の文字
は特に処理するが、そのほかは、パス名を、文字「／」
によって区切られた名前のリストとして、扱う。名前の
各々を要素と称する。 【００８９】ｎａｍｅｃの最初の部分（１０６７）では
、パス名が始まる点を表すチャネル３０１を得る。その
チャネルを得る要領は、そのパス名の始まり方による。 始まり方には３つの可能性がある。パス名が、完全なパ
ス名の場合、そのパス名は、「／」で始まる。パス名が
、組み込みカーネル・サービスによって与えられるファ
イルを示し、かつそのサービスが、もう１つのファイル
名にまだ結合されていない場合、「＃」で始まる。パス
名がワーキング・ディレクトリで始まる場合、ファイル
名で始まる。 【００９０】パス名が、「／」で始まる場合、判断ブロ
ック１００５の分岐ｙが取られ、ルートに対するファイ
ル・チャネル４１９の内容が、チャネル３０１「ｎｃｈ
ａｎ」にコピーされる（１００９）。前記のように、ル
ートのファイル・チャネル４１９は、そのプロセスに対
するユーザ・データ構造体４０３から位置を特定するこ
とができる。 【００９１】パス名が他のもので始まる場合、ブロック
１００５の分岐ｎが取られ、ブロック１００７において
、最初の要素を検査して、それが「＃」かどうかを判断
する。「＃」ならば、「＃」に続く文字によって指定さ
れるカーネル組み込みサービスによって、ａｔｔａｃｈ
サービス・ファイル・ロケータ要求が実行される。ａｔ
ｔａｃｈロケータ要求の結果は、組み込みサービスによ
って与えられるファイル木構造１２５のルートを表すチ
ャネル３０１である。所与のサービスがａｔｔａｃｈ要
求を処理する要領は、そのサービスによる。例えば、ル
ート・サービスに対するａｔｔａｃｈ関数は、包括的な
ａｔｔａｃｈ関数であるｄｅｖａｔｔａｃｈを呼び出す
。ｄｅｖａｔｔａｃｈは、引数として組み込みサービス
の名前、この場合は「／」、を取る。ｄｅｖａｔｔａｃ
ｈは、新たなチャネル・データ構造体３０１を獲得し、
ｑｉｄフィールド３２３をルートを指定する値に設定し
、さらに型フィールド３１５を引数「／」から得た値に
設定する。最初の要素が、「／」でも「＃」でもない場
合、そのパス名はワーキング・ディレクトリで始まる。 そこで、ブロック１０１３において、ワーキング・ディ
レクトリを表すファイル・チャネル４１９をｎｃｈａｎ
にコピーする。このファイル・チャネルは、プロセスに
対するユーザ・データ構造体４０３から位置を特定する
ことができる。 【００９２】１０６９で示した次の段階では、ｎｃｈａ
ｎによって表されるファイルに対するパス名が、ｂｉｎ
ｄまたはｍｏｕｎｔの関数コールにおいて古いパス名と
して使用されたかどうかを調べる。まず、パス名の最初
の要素を得る。これを行う関数により、構造体４０３に
おけるフィールドＥＬＥＭ４０５を次の要素であるファ
イル名に設定する。その上で、プロセス１０２に対する
ユーザ・データ構造体４０３からプロセス・グループ１
０３に対するマウント・テーブル配列８０２の位置を特
定する。各マウント・テーブル・エントリ８０３に対す
る左手チャネル８０２を次々にｎｃｈａｎと比較してゆ
き、ｎｃｈａｎに「等しい」ものが見つかるまで続ける
。ここで言う「等しい」とは、２つのチャネル３０１が
同じサービス１２３における同じファイルを表す、即ち
、それらが、それらの型フィールド３１３、ｄｅｖフィ
ールド３１５、およびｑｉｄフィールド３２３に等しい
値を有するということである。 【００９３】該当する左手チャネル８０２が見つからな
い場合、判断ブロック１０１９の分岐ｎが取られ、見つ
かった場合、分岐ｙが取られて、ｎｃｈａｎに等しい左
手チャネル８０２を有するエントリ８０３によって示さ
れる右手チャネル８０４の内容をｎｃｈａｎにコピーす
る（１０２１）。その上で、ｎｃｈａｎにおけるｍｏｕ
ｎｔｐｔｒフィールド３２７を、それが右手チャネル８
０４を示すマウント構造体８０９を示すように、設定し
、さらにｍｏｕｎｔｉｄフィールド３２９をマウント構
造体８０９のｍｏｕｎｔｉｄの値に設定する。従って、
パス名がｂｉｎｄまたはｍｏｕｎｔのコールにおいて古
いパス名として使用された場合、ｎｃｈａｎは、この時
点で、右手チャネル８０４によって表されるファイルを
表す。それ以外の場合は、ｎｃｈａｎは不変である。 【００９４】図１０の１０Ｂにおいて、ｎａｍｅｃの一
部１０７１は、パス名の残りの各要素を調べるループ１
０２５からなる。このループを通過する度に、「ｗａｌ
ｋ」カーネル関数へのコールが行われる。このコールに
おいて使用される引数は、ｎｃｈａｎ、現在の要素（ブ
ロック１０２９）、および現在の名前がそのファイルを
表す左手チャネル８０２を持つことができるか（これは
、カーネル組み込みサービス名の場合に限って不可能で
ある）どうかを示すフラグである。さらに詳細に後述す
るが、ｗａｌｋ関数は、要素によって指定されたファイ
ルを表すチャネル３０１を返す。ブロック１０３１にお
いて、そのチャネル（図１０ではｔｃｈａｎで示す）を
ｎｃｈａｎに割り当てる。そして、次の要素をパス名か
ら得る（ブロック１０３３）。前のように、ＵＳＥＲ構
造体４０３にあるＥＬＥＭフィールド４０５を次の要素
に設定する。ループが終了すると、パス名の最後の要素
が処理されるべく残る。 【００９５】最後の要素を処理する要領は、何れのシス
テム・コールがｎａｍｅｃを呼び出したかによる。それ
がｃｒｅａｔｅシステム・コールの場合、最後の要素は
、新たなファイルの名前を表し、それ以外の場合は、ア
クセスするべきファイルを表す。何れのシステム・コー
ルがｎａｍｅｃを呼び出したかは、アクセス・モード引
数によって示され、判断ブロック１０５５に示したよう
に、以降の処理は、その引数に依存する。尚、ブロック
１０５７に示すように、アクセス・モード引数により、
ファイルの生成が指示されている場合、最後の要素およ
びｔｃｈａｎを用いてｃｒｅａｔｅサービス・ファイル
要求を行う。ただし、この時、ｔｃｈａｎは、新たなフ
ァイルが生成されるべきディレクトリに対するファイル
・チャネル４１９のコピーである。結果的に、ｔｃｈａ
ｎは、その型フィールド３１３およびｄｅｖフィールド
３１５に、ディレクトリおよびｑｉｄフィールド３２３
におけるそのディレクトリに対するｑｉｄを含むサービ
ス１２３を指定する値を収容する。ｃｒｅａｔｅサービ
ス・ファイル要求の結果として、新たなファイルがｍ生
成され、その名前として最後の要素が割り当てられ、さ
らに、ｔｃｈａｎのｑｉｄフィールドが、新たなファイ
ルのｑｉｄに設定される。 【００９６】ｎａｍｅｃを呼び出したシステム・コール
がｃｒｅａｔｅ以外である場合、最後の要素は、既に存
在するファイルの名前である。この場合も、最後の要素
を用いてｗａｌｋ関数を呼び出し、ｔｃｈａｎを得る。 このｔｃｈａｎは、最後の要素によって参照される（１
０５９）ファイルを表す。 その上で、ｔｃｈａｎのフィールドをｎａｍｅｃのアク
セス・モードおよびオープン・モードの引数により要求
されるとおりに設定し（１０６１）、さらにｔｃｈａｎ
をｎｃｈａｎにコピーする（１０６３）。戻り端子１０
６５に示したように、パス名引数において指定されたフ
ァイルを表すチャネル３０１としてｎｃｈａｎが返され
る。 【００９７】図１１の開始端子１１０３において、ｗａ
ｌｋは、チャネル・データ構造体３０１、パス名の一要
素、およびその要素へのマウントが有効かどうかを示す
フラグを取る。チャネル・データ構造体３０１は、その
要素の名前を有するファイルを求めて探査するべきディ
レクトリを表す。そのディレクトリか、またはそのチャ
ネル・データ構造体によって表されるディレクトリと結
合したディレクトリにおいて、その要素の名前が発見さ
れた場合、この関数は、そのパス名の要素によって指定
されるファイルを表すチャネル・データ構造体３０１を
返す。 【００９８】そのアルゴリズムは、およそ次のとおりで
ある。まず、引数として使用されるチャネル３０１の型
フィールド３１３および装置フィールド３１５によって
指定されるサービスに対し、ｗａｌｋファイル・サービ
ス要求を行う。このｗａｌｋファイル・サービス要求に
は、引数として使用される要素が含まれる。このファイ
ル・サービス要求は、成功した場合、その要素によって
指定されるファイルに対するチャネル３０１を返す。そ
の上で、マウント・テーブル３０８の検査によって、ｗ
ａｌｋ要求によって返されたチャネル３０１が、左手チ
ャネル８０２かどうかを判断し、そうでない場合、ｗａ
ｌｋ要求によって返されたチャネルは、ｗａｌｋ関数に
よって返される。そである場合、その左手チャネル８０
２に対応する右手チャネル８０４をｗａｌｋ関数によっ
て返されることになっているチャネル３０１にコピーし
、さらにチャネル３０１のｍｏｕｎｔｐｔｒフィールド
およびｍｏｕｎｔｉｄフィールドを、左手チャネル８０
２を示すマウント・テーブル配列エントリ８０３によっ
て示されるマウント・データ構造体８０９の要求に合わ
せて設定する。 【００９９】ファイル・サービスが、要素によって指定
される名前を有するファイルをチャネルによって指定さ
れたディレクトリにおいて発見できない場合、ｗａｌｋ
ファイル・サービス要求は、成功しない。このようなこ
とが起こる理由は２つある。即ち、そのディレクトリに
別な名前が結合されているか、または要素に対応するフ
ァイルがそのディレクトリに存在しないかである。 【０１００】前記の第１の場合、別の名前が結合された
ときに、ｍｏｕｎｔｐｔｒ３２７およびｍｏｕｎｔｉｄ
３２９により、生成されたマウント構造体８０９を指定
し、さらにそのマウント構造体８０９によって示される
右手チャネル８０４において指定されるサービスについ
て、ｗａｌｋサービス・ファイル要求を再び試みる。そ
のｗａｌｋサービス・ファイル要求が、成功した場合、
処理を既に説明したように続ける。失敗した場合、やは
り、前記の何れの可能性もある。ここでは、要素に対応
するファイルがそのディレクトリに存在しないという問
題を仮定する。この場合も２つの可能性がある。即ち、
ファイルが実際に存在しないか、または探査されたディ
レクトリが結合ディレクトリの一部であり、かつその結
合ディレクトリの一部である他のディレクトリが依然と
して探査されていない可能性がある。ファイルが実際に
存在しない場合には、実際に探査されたディレクトリに
対するマウント構造体８０９における終端フィールド８
１３によって、マウント構造体８０９がその結合ディレ
クトリを構成するマウント構造体８０９のリストの最後
のものであることが示されるはずである。そうでなけれ
ば、マウント構造体８０９におけるネクスト・フィール
ド８１７が、結合ディレクトリにおける次のディレクト
リに対するマウント構造体８０９を示すことになり、そ
の次のマウント構造体から、探査するべき右手チャネル
８０４を決定することができる。この場合、次のマウン
ト構造体によって示される右手チャネル８０４を用いて
、ｗａｌｋサービス・ファイル・ロケータ要求を繰り返
す。 【０１０１】詳細には、ブロック１１０５において、最
初は、これがサービス・ファイル・ロケータ要求を行う
１回目であることを示すフラグを設定し、引数として与
えられたチャネルをｃｃｈａｎにコピーする。ブロック
１１０７において、ｃｃｈａｎおよび要素を用いてｗａ
ｌｋサービス・ファイル・ロケータ要求を行う。そのサ
ービスがこの要求に応じて実行する動作は、そのサービ
スに依存する。その２つの例を説明する。ルート・サー
ビスでは、ｗａｌｋ要求に応じて、ｃｃｈａｎがルート
・サービスのルートのために予約されているｑｉｄフィ
ールド３２３に特別な値を持っているかどうかを判断し
、さらに、持っている場合、要素がルート・サービスに
より「控え」として与えられる名前のうちの１つである
かどうかを判断する。 後者の場合、ｃｃｈａｎのｑｉｄフィールド３２３を、
前記の控えの名前に対し予約された特別な値に設定する
。前記以外の場合、ｗａｌｋサービス・ファイル・ロケ
ータ要求は失敗する。　 【０１０２】マウント・サービス２０３は、ｗａｌｋ要
求に対し次のように応答する。前記のように、プロトコ
ル・サービス２０９によって与えられるファイルを表す
チャネル３０１のｄｅｖフィールド３１５の一部に、マ
ウント・サービス配列エントリ５０３を指定する識別子
が含まれる。その識別子を用いて、マウント・サービス
２０３は、プロトコル・サービス２０９に対するプロト
コル・チャネル５１７に対するマウント・サービスの待
ち行列５０９の位置を特定し、ｗａｌｋサービス・ファ
イル・ロケータ要求に必要なｔｍｅｓｓａｇｅに対する
マウント・ヘッダ５２１を割り当て、さらにチャネルか
ら得たファイル識別子および要素をｔｍｅｓｓａｇｅに
配置する。プロトコル・サービス２０９が、チャネルか
らのファイル識別子によって指定されたディレクトリに
おける要素によって指定される名前の付いたファイルを
有する場合、プロトコル・サービス２０９は、ファイル
に対するｑｉｄが入ったｒｍａｓｓａｇｅを返し、その
ｑｉｄは、ｃｃｈａｎのｑｉｄフィールド３２３に置か
れる。 【０１０３】ｗａｌｋ要求が成功した場合、チャネル３
０１がｍｏｕｎｔまたはｂｉｎｄ操作の結果ではないこ
とを示すように、ｃｃｈａｎのフラグ３２１が設定され
る（１１１９）。 次に、ｗａｌｋ要求が２回以上行われたかどうかを判断
する（１１２１）。２回以上行われた場合、引数として
受け取ったチャネルは、返されたものではないことにな
り、その引数として受け取ったチャネルは、閉じられる
（１１２３）。このクローズ操作によって、そのチャネ
ルのｒｅｆフールドにある計数が、デクリメントされる
が、この時、そのｒｅｆフィールドが値０を有する場合
、ｃｌｕｎｋサービス要求がそのチャネルのｄｅｖフィ
ールド３１５によって示されるサービスに送られ、さら
にチャネル構造体３０１がフリー・リストに返される。 ｗａｌｋ要求が行われたのが、これでまだ一回目である
場合、このステップは省略される。次に、判断ブロック
１１３３において、ｃｃｈａｎが、他の構成要素が結合
されている可能性のあるパス名の構成要素を表すかどう
かを判断する。この状態は、「＃」以外の構成要素に対
して成立し、かつｗａｌｋの「ｍｏｕｎｔｏｋ」引数に
よって示される。マウントされた構成要素があり得ない
場合、マウント・テーブル８０１を調べる必要はなく、
ｃｃｈａｎはそのまま返される（１１３５）。そうでな
い場合、ｃｃｈａｎに等しい左手チャネル８０２を求め
て、マウント・テーブル８０１を調べ、該当する左手チ
ャネル８０２を発見した場合、左手チャネル８０２に対
応する右手チャネル８０４の値を、右手チャネル８０４
を示すマウント構造体８０９に対するマウント・ポイン
タおよびマウント識別子と共に、ｃｃｈａｎにコピーす
る。ｃｃｈａｎをこのように変更して返す（ブロック１
１３７〜１１４３）。 【０１０４】ｗａｌｋサービス要求ブロック１１０７に
戻り、その要求が失敗した場合、まず、ｃｃｈａｎが、
ｍｏｕｎｔまたはｂｉｎｄ要求の結果であるかどうかを
判断する。そうであるならば、探査に失敗したのであり
、結合子「Ｂ」のように、ｗａｌｋ関数は、失敗を示す
０を返す（端子１１４９）。ブロック１１４５および１
１４７において、ｗａｌｋ要求が２回以上行われた場合
、ｃｃｈａｎをクローズする。 次に、ｃｃｈａｎのマウント・ポインタ・フィールド３
２７を用いて、マウント構造体８０９の位置を特定する
（ブロック１１１）。マウント構造体８０９の終端フィ
ールド８１３により、そのマウント構造体８０９が、結
合ディレクトリを定義するマウント構造体８０９のリス
トの最後にあることが示されている場合、その探査は失
敗したのであり、ｗａｌｋは、結合子Ｂにおいて終了す
る。そうでない場合、現在のマウント構造体８０９のネ
クスト・ポインタ８１７の方が先であるから、次のマウ
ント構造体８０９によって示される右手チャネル８０４
を一時的なチャネルｔｃｈａｎにコピーする（ブロック
１１１５）。 次に、ｔｃｈａｎにおけるｍｏｕｎｔｐｔｒフィールド
３２７を、次のマウント構造体８０９を示すように設定
し（ブロック１１２５）、ｔｃｈａｎをｃｃｈａｎにコ
ピーし（１１２７）、ｆｉｒｓｔを０に設定し、さらに
、結合子「Ｄ」によって示したように、ブロック１１０
７において、ｗａｌｋサービス要求を繰り返す。結合子
Ｄによって定義されるループ１１３１は、ブロック１１
０７におけるｗａｌｋ要求が成功するか、または要素に
対応するファイルが発見されなかったことが明かとなる
まで、繰り返される。 【０１０５】ファイル・ロケータ操作の実施第９案にお
ける名前の分析が分かったので、「ｏｐｅｎ」、「ｂｉ
ｎｄ」および「ｍｏｕｎｔ」などのファイル・ロケータ
・システム・コールの実施は容易である。まず、ｏｐｅ
ｎシステム・コールは、パス名、動作モードを指定する
整数を引数として取り、オープンされたファイルのファ
イル記述子４１７を返す。このシステム・コールは、最
初に、現在はチャネル３０１を示していないファイル記
述子配列４１３の要素４１５の位置を確認する。その要
素の番号が、新たに開かれたファイルに対するファイル
記述子である。次に、システム・コールは、ｎａｍｅｃ
を呼び出す。この時の引数は、パス名、オープンを指定
するアクセス・モード指定子、およびオープンを行うモ
ードである。前記のように、ｎａｍｅｃは、パス名を分
析し、パス名によって示されたサービスがパス名によっ
て指定されたファイルにある処理を行うことを指定し、
かつその時点でチャネル３０１が当該ファイルを表すフ
ァイル・チャネル４１９であるように設定されたフィー
ルドを備えたチャネル３０１を返す。ｏｐｅｎシステム
・コールは、そのファイル・チャネル４１９へのポイン
タをファイル記述子配列の要素４１５に置いて、そのフ
ァイル記述子を返す。 【０１０６】好ましい実施例における「ｂｉｎｄ」シス
テム・コールは、引数として、新たなパス名へのポイン
タ、古いパス名へのポインタ、およびそのｂｉｎｄがｒ
ｅｐｌａｃｅ、ｂｅｆｏｒｅまたはａｆｔｅｒのオプシ
ョンを付けて行われているかどうかを示すフラグを取る
。このシステム・コールは、このｂｉｎｄが、成功した
場合は「１」の値を、失敗した場合は「０」の値を有す
る整数を返す。このシステム・コールは、ｂｉｎｄとｍ
ｏｕｎｔの両方を行う「ｂｉｎｄｍｏｕｎｔ」と称する
カーネル関数を呼び出す。「ｂｉｎｄ」または「ｍｏｕ
ｎｔ」システム・コールによって与えられるフラグによ
って、何れを行うべきかが示される。「ｂｉｎｄ」シス
テム・コールが示されると、ｂｉｎｄｍｏｕｎｔは、第
１のパス名を付けてｎａｍｅｃを呼び出して、第１のパ
ス名によって指定されたファイルを表す第１のチャネル
３０１を得る。次に、第２のパス名を付けてｎａｍｅｃ
を呼び出して、第２のパス名によって指定されたファイ
ルを表す第２のチャネル３０１を得る。次の段階で、カ
ーネル・マウント関数を呼び出す。この関数は、ｂｉｎ
ｄ操作の必要に応じてマウント・テーブル８０１を配置
し直す。 【０１０７】図１２において長方形１２０３で示したよ
うに、カーネル・マウント関数は、引数として、古いチ
ャネル、新たなチャネル、およびフラグを取り、ｂｉｎ
ｄまたはｍｏｕｎｔの結果得られたマウント構造体８０
９のマウント識別子を返す。フラグは、ｂｉｎｄまたは
ｍｏｕｎｔのシステム・コールのオプション・フラグか
ら設定される。現在の場合、古いチャネルに対する実際
の引数は、第１のチャネル３０１であり、新たなチャネ
ルに対する実際の引数は、第２のチャネル３０１である
。 【０１０８】このアルゴリズムの最初のステップは、引
数として受け取ったチャネル３０１についてｂｉｎｄま
たはｍｏｕｎｔの処理を実行することができるかどうか
判断することである（１２０５）。両方のチャネルが、
同じファイルを指定している（即ち、同じｑｉｄ３２３
を持つ）場合、または古いチャネルが、ディレクトリで
ないファイルを表し、かつフラグによってｒｅｐｌａｃ
ｅ以外のオプションが指定されている場合、処理は許さ
れない。処理が許されない場合、１２０７において、エ
ラーとなる。次に、既に説明したように、マウント・テ
ーブル８０１を探査して、古いチャネルが既にマウント
・テーブル８０１にある左手チャネル８０２に等しいか
どうかを判断する。等しい場合、新たなマウント・テー
ブル・エントリ８０３は全く必要ないので、ブロック１
２１１は省略することができる。等しくない場合には、
ブロック１２１１において、空のマウント・テーブル・
エントリ８０３を入手して、そのエントリ８０３のポイ
ンタ８０５を古いチャネルを示すように設定する。 【０１０９】次に、新たなチャネル３０１のフラグ・フ
ィールド３２１を、そのチャネルが右手チャネル８０４
であることを示すＣＭＯＵＮＴを示すように設定する（
１２１３）。また、フラグ・フィールド３２１により、
ＣＲＥＡＴＥオプションを示すこともできる。このオプ
ションは、右手チャネル８０４によって表されるディレ
クトリにファイルを生成しても良いことを指定する。こ
のオプションが指定されると、新たなチャネル３０１の
フラグ・フィールド３２１が、ＣＭＯＵＮＴオプション
だけでなくＣＲＥＡＴＥオプションも示すように設定さ
れる（１２１５、１２１７）。ここで、マウント関数は
、新たなマウント構造体８０９を入手して、古いチャネ
ルに対応する左手チャネル８０２に対するマウント・テ
ーブル・エントリを新たなチャネル３０１から作られて
いる右手チャネル８０４に連結する。新たなマウント構
造体におけるポインタ８１９が、新たなチャネル３０１
を示すように設定される（１２１９）。 【０１１０】結合子「Ａ」に続いて、ｓｗｉｔｃｈ文１
２２１において、フラグ引数がｒｅｐｌａｃｅ，ｂｅｆ
ｏｒｅ、またはａｆｔｅｒのオプションの何れかを示す
かどうかによって、３つの分岐の中の１つを指定する。 ｂｅｆｏｒｅ分岐１２２３の場合、ブロック１２２１に
おいて、検査により、別のディレクトリが既に左手チャ
ネル８０２に結合されているかどうかを判断する。結合
されていない場合、結合ディレクトリは不可能であり、
ｂｅｆｏｒｅオプションはエラーである（１２３１）。 そのようなディレクトリが既に存在する場合、ｒｅｐｌ
ａｃｅオプション１２２５の場合にように処理が継続す
る。ｒｅｐｌａｃｅオプションにおいては、、古いチャ
ネル３０１と同等の左手チャネル８０２に対応するマウ
ント構造体８０９のリストの先頭に、新たなマウント構
造体８０９が置かれる（１２３３）。ｒｅｐｌａｃｅオ
プション１２２５が使用されている場合、新たなマウン
ト構造体８０９における終端フィールド８１３が、リス
トの最後を示すように設定される（１２３４）。ａｆｔ
ｅｒオプション１２２７においては、最終的に、ステッ
プ１２３５において再び検査を行い、結合ディレクトリ
が可能かどうかを判断し、そうでない場合、エラー１２
３７となる。可能ならば、ブロック１２３９で示したよ
うに、マウント構造体８０９のリストの末尾に新たなマ
ウント構造体８０９が置かれる。次に、ｍｏｕｎｔは、
新たなマウント構造体８０９に属するマウント識別子を
返す。ｂｉｎｄｍｏｕｎｔを続けると、この関数は、新
旧のチャネル３０１をクローズし、それらのうち、マウ
ント・テーブルにも追加されず、フリー・チャネルのリ
スト以外には使用されないものを返す。 【０１１１】システム・マウント関数コールは、新たな
パス名引数がないという点で、システム結合関数コール
とは異なる。その代わり、新たなパス名引数は、オープ
ン・プロトコル・チャネル５１７を表すファイル記述子
４１７である引数によって置き換えられている。そのよ
うなファイル記述子４１７を得る方法は、さらに詳細に
後述する。さらに、システム・マウント関数コールは、
マウントされているプロトコル・サービス２０９へと渡
されるデータからなる引数を含む。そのフラグに応じて
、ｂｉｎｄｍｏｕｎｔは、最初にファイル記述子４１７
およびファイル記述子配列４１３を用いて、ファイル記
述子引数によって指定されたプロトコル・チャネル５１
７の位置を特定する。 【０１１２】次に、プロトコル・チャネル５１７を用い
てマウント・サービス・アタッチ処理を実行する。アタ
ッチ処理において最初に行うことは、使用されていない
マウント・サービス配列要素５０３の位置を特定するこ
とである。これが終わると、既に説明した包括的なｄｅ
ｖａｔｔａｃｈ処理を実行する。ただし、これを呼び出
すのに使用する引数は、マウント・サービス２０３を指
定する「Ｍ」である。ｄｅｖａｔｔａｃｈは、その型フ
ィールド３１３がマウント・サービス２０３を指定する
ように設定されたチャネル構造体３０１を返す。そのマ
ウント・サービス２０３に対するアタッチ関数は、その
チャネルのｄｅｖフィールド３１５を使用されていない
マウント・サービス配列要素５０３に対する識別子の値
に設定し、さらに前記の使用されていない要素のポイン
タ５０５を、それがチャネル構造体を示すように、設定
する。次に、プロトコル・チャネル引数を用いて、引数
によって指定されたプロトコル・チャネル５１７に対し
マウント・サービス・キュー構造体５０９によって表さ
れるメッセージ・キューが既に存在するかどうかを判断
する。存在しない場合、割り当てられている。ここで、
ｄｅｖａｔｔａｃｈによって返されたチャネル３０１に
対する識別子およびプロトコル・サービス２０９に渡さ
れるはずであった引数が入ったａｔｔａｃｈ往信メッセ
ージ（ｔｍａｓｓａｇｅ）が送られる。返信メッセージ
が戻ったとき、それには、プロトコル・サービス２０９
におけるファイル木構造１２５のルートに対するｑｉｄ
が入っている。このｑｉｄは、ｄｅｖａｔｔａｃｈによ
って返されたチャネル３０１のｑｉｄフィールド３２３
およびｍｑｉｄフィールド３３９へとコピーされ、さら
に、メッセージ・キューが属するプロトコル・チャネル
５１７へのポインタが、ｐｃｈａｎフィールド３３７に
コピーされる。次に、マウント・サービス・アタッチ処
理の結果得られたチャネルは、新たなチャネル３０１引
数としてマウント関数に与えられる。ｂｉｎｄｍｏｕｎ
ｔ関数についてｍｏｕｎｔが指定されると、ｂｉｎｄｍ
ｏｕｎｔは、ファイル記述子配列４１３のプロトコル・
チャネル５１７をクローズし、さらにファイル記述子配
列４１３からそれを削除することによって、終了する。 【０１１３】オープン・プロトコル・チャネル５１７の
獲得：図１３ マウント・システム・コールの引数は、オープン・プロ
トコル・チャネルのファイル記述子４１７が含まれる。 プロトコル・チャネル５１７は、プロトコル・サービス
２０９への接続であるファイルを表すチャネル３０１で
ある。好ましい実施例において、接続は、ローカル・プ
ロトコル・サービス２１１がメッセージを送受信する手
段であるパイプにおけるファイル、または通信システム
を介した遠隔のプロトコル・サービス２１３との会話を
表すファイルの何れも良い。実施例においては、パイプ
におけるファイルに対するファイル記述子は、そのパイ
プを生成する「ｐｉｐｅ」システム・コールによって与
えられる。通信システムを介する会話を表すファイルに
対するファイル記述子は、次のようにして獲得される。 まず、「ｄｉａｌ」関数が呼び出される。この関数は、
その会話を表すファイルを含むディレクトリのパス名を
返す。 次に、その会話を表すファイルのパス名が、「ｏｐｅｎ
」関数で用いられ、そのｏｐｅｎ関数は、その会話を表
すファイルに対するファイル記述子を返す。 【０１１４】プロトコル・チャネル５１７が表す接続の
対象であるプロトコル・サービス２０９をプロセッサ１
０２によってｓｒｖ６１５に登録することにより、プロ
トコル・チャネル５１７を一般的な用途に使用できるよ
うにすることができる。すべてのサービスについて言え
ることであるが、ｓｒｖ６１５は、それがファイルとし
て管理する資源を提供する。従って、プロトコル・サー
ビス２０９をｓｒｖ６１５に登録するためには、そのプ
ロトコル・サービス２０９を表すファイルをｓｒｖによ
って表されるディレクトリに生成し、さらにその生成し
たファイルへの接続を表すファイルに対するファイル記
述子を書けばよい。 【０１１５】勿論、システム生成関数を呼び出せば、ｓ
ｒｖへのファイル生成要求が発生することになり、ｓｒ
ｖは、この生成要求に応じて、そのファイルに対するデ
ィレクトリ・エントリを作り、ディレクトリ・エントリ
に対するｑｉｄを生成されたファイルに対するチャネル
３０１のフィールド３２３に置き、さらにディレクトリ
・エントリへのポインタを補助フィールド３３３に置く
。同様に、システム・ライト・処理の実行も、ｓｒｖへ
のファイル書込み要求を発生する結果となり、ｓｒｖは
、この書込み要求に応じて、ファイル記述子によって指
定されるプロトコル・チャネル５１７へのポインタをプ
ロトコル・サービス２０９へのディレクトリ・エントリ
に置く。プロトコル・サービス２０９を表すファイルの
名前を用いて、オープン・システム・コールを行うと、
結果的に発生するｓｒｖ６１５に対するオープン・ファ
イル要求によって、ｓｒｖ６１５は、プロトコル・サー
ビス２０９に対するプロトコル・チャネル５１７を返す
ことになる。そして、ｏｐｅｎにより、既に述べたファ
イル記述子４１７と共にプロトコル・チャネル５１７が
与えられ、マウント・システム・コールにおいて、その
ファイル記述子４１７を使用することもできる。　 【０１１６】図１３において、ｓｒｖ６１５によって維
持されているディレクトリは、ディレクトリ・エントリ
１３０３の木構造からなる。各ディレクトリ・エントリ
１３０３は、情報１３０５および多数のポインタからな
る。これらのポインタによって、ディレクトリ・エント
リ１３０３が１つの木構造へと組織される。この木構造
の各レベルに１つ以上のディレクトリ・エントリ１３０
３があり、所与のレベルのエントリ１３０３は、内側の
ノード、即ち木構造の次に低いレベルの点、またはプロ
トコル・サービス２０９を表す葉ノードの何れかである
。以下において、内側のノードを「親」と称する。所与
の親を有するエントリ１３０３は、次ポインタ１３１１
および後ポインタ１３１３によって子リスト１３１０へ
と接続される。さらに、所与の子リスト１３１０の各エ
ントリ１３０３は、その親エントリ１３０３へのポイン
タ１３０９を有する。親エントリ１３０３は、さらに子
リスト１３１０における最初のエントリ１３０３へのポ
インタ１３０７も有する。葉ノードは、その葉ノードに
よって表されるプロトコル・サービス２０９への接続を
表すプロトコル・チャネル５１７へのポインタ１３１４
を持つことがある。さらに、エントリ１３０３が、チャ
ネル３０１によって表される場合、そのチャネル３０１
の補助フィールド３３３には、そのチャネルによって表
されるエントリ１３０３へのポインタ１３０２が収容さ
れる。 【０１１７】ディレクトリ情報１３０５は、次のフィー
ルドからなる。名前１３１５：プロトコル・サービス２
０９が登録されている場合、それを特定するために使用
される名前である。ｑｉｄ１３１７：そのディレクトリ
を表すチャネル３０１におけるディレクトリ・エントリ
１３０３を表すｑｉｄである。ｔｙｐｅ１３１９および
ｄｅｖ１３２１：これらによりｓｒｖ６１５を指定する
。モード１３２３：エントリ１３０３によって表される
ディレクトリが開かれている場合、そのオープン・モー
ドを示すように設定される。ａｔｉｍｅ１３２５：いつ
エントリ１３０３が割り当てられたかを示す。ｍｔｉｍ
ｅ１３２７：いつエントリ１３０３の親が割り当てられ
たか、またはエントリ１３０３が親ならば、最後に子が
生成された時間を示す。 長さ１３２９：エントリ１３０３が親ならば、子のエン
トリ１３０３の数を表す。ｕｉｄ１３３１：そのエント
リ１３０３を所有する利用者を命名する文字列値である
。 ｇｉｄ１３３３：ｕｉｄにおいて特定される利用者が所
属するグループを識別する文字列値である。 【０１１８】以上、第９案のオペレーティング・システ
ムにより、プロセスごとの名前空間がどのように実施さ
れるか、その名前空間がｂｉｎｄおよびｍｏｕｎｔ処理
によりどのように変更できるか、ファイルの位置を特定
するために名前空間をどのように利用できるか、さらに
そのように特定されたファイルに対してファイル処理を
どのように実行できるかについて、詳細に示した。以下
において、プロセスごとの名前空間にとり特に有利な２
つの用途を調べる。 【０１１９】第９案のウィンドウ・システム：図１４〜
２３ ウィンドウ・システムとは、オペレーティング・システ
ムの下で実行中のプロセス１０２にグラフィックス端末
上のウィンドウを与え、かつキーボードまたはマウスの
ような指示装置からウィンドウへの入力に応答するよう
な、オペレーティング・システムのサブシステムである
。Ｘウィンドウのような従来技術のウィンドウ・システ
ムは、大きく且つ複雑なシステムである。第９案がプロ
セスに利用可能な関数をファイル木構造として定義し、
さらに第９案のプロセス１０２がそれ自体の名前空間１
１５を定義できることから、Ｘウィンドウなどの従来技
術のウィンドウ・システムとほぼ同じ機能を備えながら
も、それより相当少ないコードしか必要としないような
ウィンドウ・システムを構築することが可能となった。 現在のところ好ましい実施例は、Ｘウィンドウの大きさ
の１／１０以下である。さらに、第９案のウィンドウ・
システムの設計で使用される原理は、他のオペレーティ
ング・システムに対する異なるウィンドウ・システムの
設計にも使用することができる。以降、はじめに第９案
のウィンドウ・システムの概要を提示し、その上で、そ
の効率の原因となるシステムのある側面をさらに詳細に
説明する。 【０１２０】第９案のウィンドウ・システムの概要：図
１４および１５ 第９案の端末、即ちＧｎｏｔ７１１には、キーボード、
グラフィック・ディスプレイ（ｇｒａｐｈｉｃｓ　ｄｉ
ｓｐｌａｙ）、およびマウスが含まれる。これらの装置
は、カーネル・サービス＃ｂおよび＃ｃをディレクトリ
／ｄｅｖ６１９に結合することにより、第９案のプロセ
ス１０２の名前空間１１５にまとめてもよい。そのよう
な結合を実行すると、／ｄｅｖ／ｍｏｕｓｅはマウスを
示し、／ｄｅｖ／ｃｏｎｓはキーボードを示し、／ｄｅ
ｖ／ｂｉｔｂｌｔはグラフィック・ディスプレイを示す
。これらのファイルを開き、リードおよびライト処理を
適切に行うことにより、グラフィック操作を行うことが
できる。例えば、マウスの動きは、／ｄｅｖ／ｍｏｕｓ
ｅへのリード処理によって決定され、／ｄｅｖ／ｂｉｔ
ｂｌｔに書き込むことによってグラフィック・ディスプ
レイ上に表示が生成される。 【０１２１】第９案のウィンドウ・システムは、プロト
コル・サービス２０９として実施される。ウィンドウ・
プロトコル・サービスは、Ｇｎｏｔ７１１上にウィンド
ウを有するファイルのインスタンスをプロセス１０２に
与える。プロセスは、ウィンドウ・サービスによって与
えられたファイルを読み・書きすることによって、ウィ
ンドウを制御する。ウィンドウ・サービスは、ファイル
／ｄｅｖ／ｍｏｕｓｅ、／ｄｅｖ／ｃｏｎｓおよび／ｄ
ｅｖ／ｂｉｔｂｌｔを含む名前空間を有するプロセスの
集合によって実施される。さらに詳細に後述するように
、これらのファイルを如何なるサービス１２３によって
与えてもよい。必要なことは、そのファイルに対するリ
ードまたはライト処理が、結果的に、端末に表示された
ウィンドウからデータを読んだり、端末に表示されたウ
ィンドウにデータを書いたりすることになるということ
だけである。最も一般的には、それらのファイルは、カ
ーネル・サービス＃ｂおよび＃ｃによって与えられるか
、または問題のウィンドウ・プロトコル・サービスがそ
のクライアントであるような別のウィンドウプロトコル
・サービスによって与えられ、さらにそれらのファイル
によって制御されるウィンドウが、Ｇｎｏｔ７１１にお
いて表示される。 【０１２２】ウィンドウ・サービスは、プロトコル・サ
ービス２０９であるため、リードおよびライト処理は、
マウント・サービス２０３に至る。マウント・サービス
２０３では、それらの処理をウィンドウ・サービスへの
往信メッセージ（ｔｍａｓｓａｇｅ）に変換し、そのウ
ィンドウ・サービスから返信メッセージ（ｒｍｅｓｓａ
ｇｅ）に入ったデータが戻るのを待つ。そのデータが、
マウント・サービス２０３に戻ると、そのデータは、リ
ードまたはライト処理を行ったプロセス１０２に返され
る。ウィンドウ・サービスは、ｔｍｅｓｓａｇｅに応じ
て、それらのｔｍｅｓｓａｇｅをウィンドウ・サービス
の名前空間の一部であるファイル／ｄｅｖ／ｍｏｕｓｅ
、／ｄｅｖ／ｃｏｎｓおよび／ｄｅｖ／ｂｉｔｂｌｔに
対するリードおよびライトへと変換する。これらのリー
ドおよびライトへの応答は、ｒｍｅｓｓａｇｅに変換さ
れて、マウント・サービス２０３に返される。このよう
に、ウィンドウ・サービスは、その名前空間におけるフ
ァイル／ｄｅｖ／ｍｏｕｓｅ、／ｄｅｖ／ｃｏｎｓおよ
び／ｄｅｖ／ｂｉｔｂｌｔを複数のプロセス１０２の間
で効率的に多重化する。または、換言すれば、ウィンド
ウ・サービスは、プロセス１０２に仮想端末の集合を与
える。 【０１２３】図１５において、ルート１５０２は、次の
ファイルからなるディレクトリである。ｂｉｔｂｌｔ１
５０３：このファイルに書き込むと、プロセス１０２に
対するウィンドウにおけるグラフィック表示が変化し、
このファイルから読み出すと、プロセス１０２に対する
ウィンドウにおける表示に関する情報が返される。ｃｏ
ｎｓ１５０５：このファイルのリードにより、Ｇｎｏｔ
７１１に接続されたキーボードからの入力を獲得し、こ
のファイルへのライトによって、文字がカーソル位置の
表示に出力される。ｈｏｌｄ１５０７：このファイルに
より、ｃｏｎｓ１５０５からのリードにおいて得られた
新たな行の文字に対しプロセス１０２が如何に応答する
べきかを示す。ｍｏｕｓｅ１５０９：このファイルのリ
ードにより、Ｇｎｏｔ７１１に接続されたマウスからの
入力を得る。ｎｂｍｏｕｓｅ５１１：このファイルのリ
ードによって、同様にマウスからの入力を得るが、マウ
スの状態に変化は待たない。ｒｃｏｎｓ１５１３：この
ファイルのリードによって、Ｇｎｏｔ７１１に接続され
たキーボードから未処理の入力を得る。ｓｎａｒｆ１５
１５：このファイルは、ウィンドウ間のデータ転送に使
用される；ライトによって、ウィンドウからｓｎａｒｆ
ファイルにデータが書き込まれ；リードによって、ｓｎ
ａｒｆファイルのデータがウィンドウに読み込まれる。 【０１２４】プロセス１０２が、その名前空間における
ファイル木構造１５０１をマウントする度に、プロセス
１０２は、ファイル木構造１５０１の新たなインスタン
スを受け取る、即ち、そのファイル木構造１５０１にお
けるファイルのインスタンスは、そのマウント処理を行
ったプロセス１０２から結果的に生じる接続を介してし
かアクセスできない。サービス１２３の概要において指
摘したように、ファイル木構造１５０１がプロセス１０
２の名前空間においてマウントされる度に、ウィンドウ
・サービスは、ファイル木構造１５０１の新たなインス
タンスを与えることができる。これは、ウィンドウ・サ
ービスによってプロセス１０２に与えられるファイルを
表すチャネル３０１が、ウィンドウ・サービスによって
与えられるｑｉｄによって、そのファイルを識別するか
らである。従って、１つのプロセス１０２に対するファ
イル／ｄｅｖ／ｂｉｔｂｌｔは、別のプロセス１０２に
対するファイル／ｄｅｖ／ｂｉｔｂｌｔとは異なるｑｉ
ｄを有するのであり、プロセス１０２によるそのファイ
ルへのライトは、そのプロセス１０２に対するファイル
／ｄｅｖ／ｂｉｔｂｌｔのみに対するライトである。 【０１２５】図１４において、ウィンドウ・サービス１
４０５は、その名前空間にカーネル・サービス＃ｂ１４
１１および＃ｃ１４１９によって与えられるファイルを
有す、かつプロセスＰ１０２（ａ）〜Ｐ１０２（ｎ）の
集合にＧｎｏｔ７１１上のウィンドウを与えている。各
プロセスＰ１０２は、パイプ１４０３によってウィンド
ウ・サービス１４０５に接続されている。前記のように
、ウィンドウ・サービス１４０５によって与えられるフ
ァイルに対する処理は、ウィンドウ・サービス１４０５
とプロセス１０２との間のパイプ１４０３上のｔｍｅｓ
ｓａｇｅおよびｒｍｅｓｓａｇｅ２０５および２０７と
なる。ウィンドウ・サービス１４０５によって与えられ
るファイルは、図１４において１４０６として現れる。 プロセス１０２がサービス１４０５によって与えられる
ファイル木構造１５０２をマウントする度に、そのプロ
セスは、ファイル１４０６におけるスロット１４０７を
受け取る。このスロットは、サービス１４０５によって
プロセス１０２に与えられるファイル１４０９（０．．
ｋ）の完全な集合を含む。 従って、スロット１４０７（ａ）は、プロセス１０２（
ａ）に対するファイル１４０９（０．．ｋ）のインスタ
ンスからなる。 【０１２６】ウィンドウ・サービス１４０５により、所
与のプロセス１０２に対するファイル１４０９について
のファイル処理を指定するメッセージ２０５および２０
７が、カーネル・サービス＃ｂ１４１１およびカーネル
・サービス＃ｃ１４１７によって与えられるファイルに
ついての処理を指定する関数コール２１７および２１９
へと変換される。＃ｂが／ｄｅｖ６０５に結合されると
、／ｄｅｖ／ｍｏｕｓｅ１４１３に関するリード関数コ
ール１４１２は、マウス１４２３から入力を獲得し、一
方、／ｄｅｖ／ｂｉｔｂｌｔ１４１５に関するリード／
ライト関数コール１４２５は、表示１４２７を制御する
。同様に、＃ｃが／ｄｅｖ６０５に結合されると、／ｄ
ｅｖ／ｃｏｎｓに関するリード関数コール１４２９は、
キーボード１４３１から入力を得る。 【０１２７】ファイル・システム１４０６の実施：図１
８および１９ 好ましい実施例において、ウィンドウ・サービス１４０
５がプロセス１０２に与えるファイル木構造１５０１に
おけるファイルのインスタンスの実施および位置づけに
、図１８のデータ構造体１８０１を使用する。プロトコ
ル・サービス２０９によって与えられるファイルが開か
れている場合、マウント・サービス２０３によってプロ
トコル・サービス２０９に送られるオープンｔｍｅｓｓ
ａｇｅは、ファイル識別子（ＦＩＤ）３３１を含む。こ
のオープンｔｍｅｓｓａｇｅに応じて、プロトコル・サ
ービス２０９は、そのファイル識別子３３１を、プロト
コル・サービス２０９がファイルを識別するために内部
的に使用するｑｉｄ３２３に関係付ける。プロトコル・
サービス２０９によって返されるオープンｒｍｅｓｓａ
ｇｅは、そのｑｉｄを含み、さらにプロトコル・サービ
ス２０９によってそれに関係付けられたｆｉｄ３３１お
よびｑｉｄ３２３は、共に、そのオープン・ファイルを
表すチャネル３０１に含まれる。 【０１２８】まず、ファイル配列１８０３であるが、フ
ァイル配列１８０３は、プロトコル・サービス２０９に
よって現在与えられているファイルのすべてのインスタ
ンスに対するエントリ１８０５を収容する。所与のイン
スタンスのエントリ１８０５は、そのインスタンスのフ
ァイル識別子によって示される。各エントリ１８０５は
、３つのフィールドからなる。ビジー・フィールド１８
０７：エントリ１８０５が使用中かどうかを示す。フィ
ールド１８０９：インスタンスがオープンかどうかを示
す。ファイル・ポインタ・フィールド１８１１：インス
タンスに対するファイル構造体１８１３を指し示す。 ファイル構造体１８１３は、次のフィールドからなる。 ビジー１８１５：インスタンスがビジーかどうかを示す
。ファイル型１８１７：ファイルが、ファイル木構造１
５０１におけるファイルの何れであるかを示す。スロッ
ト１８１９：ファイルが何れのスロット１４０７に属す
るかを示す値である。所与のファイル木構造１５０１の
すべてのファイルに対するファイル構造体１８１３は、
スロット１８１９に同じ値を有する。最後に、記述ポイ
ンタ（ｄｐｔｒ）１８２１：ディレクトリ木構造１５０
１に存在し得るファイルの記述子の配列におけるエント
リ１８２３を指し示す。 【０１２９】ファイル型１８１７およびスロット１８１
９は、インスタンスのｑｉｄ３２３を生成するために、
共に連結される。記述子エントリ（ＤＥ）１８２３は、
３つのフィールドを有する。文字列名１８２５：ファイ
ル木構造１５０１における名前の１つである。ファイル
型値１８２７：名前に対応するファイル型であり、ファ
イル型（ｆｔｙｐｅ）フィールド１８１７と同じ値を有
する。そして、許可フィールド１８２９：ファイルをど
のように使用できるかを示す。 【０１３０】スロット１８１９の可能な値は、それぞれ
、そのスロットによって表されるファイル木構造１５０
１へのｔｍｅｓｓａｇｅによって制御される表示１４２
７中のウィンドウを表すデータ構造体に対応する。ウィ
ンドウのデータ構造体１９０３を図１９に示す。構造体
１９０３は、次の種類の情報を含む。ｒｅｆフィールド
１９０５：スロット１８１９の値に相当するファイル木
構造１５０１があるかどうかを示す。ビジー１９０７：
ウィンドウ・データ構造体１９０３が現在使用中かどう
かを示す。スロット１９０９：ウィンドウ１９０３が対
応するスロット値。ｗｄｅｓｃ１９１１：構造体１９０
３によって表されるウィンドウを記述する情報である。 フレーム記述１９１３：ｗｄｅｓｃ１９１１によって指
定されたウィンドウの何れの部分が現在表示されている
かを記述する情報。ｑｈ１９１４：テキスト１９１５に
おける文字へのポインタ。テキスト１９１５は、ウィン
ドウに表示されるべきテキストを収容する。ｒａｗｂｕ
ｆ１９１７：キーボード１４３１からウィンドウへの生
の（未処理の）入力を収容するバッファ。コンソール・
ライト情報１９１９：ファイルｃｏｎｓ１５０５を指定
するｔｗｒｉｔｅメッセージで受信した情報。コンソー
ル・リード情報１９２１：ファイルｃｏｎｓ１５０５を
指定するｔｒｅａｄメッセージに応じて送られるべき情
報。マウス・リード情報：ファイルｍｏｕｓｅ１５０９
を指定するｔｒｅａｄメッセージに応じて送られるべき
情報。リード・キュー・ポインタ（ｒｑｐｒ）１９２５
：スロットによって表されるファイル木構造１５０１に
おけるファイルを指定するｔｒｅａｄメッセージの待ち
行列を示す。ライト・キュー・ポインタ（ｗｑｐｒ）１
９２７：スロットによって表されるファイル木構造１５
０１におけるインスタンスを指定するｔｗｒｉｔｅメッ
セージの待ち行列を示す。ｋｂｄｃ１９２９：そのウィ
ンドウにとって重要なキーボードの文字を収容する。ｓ
ｅｎｄ１９３１：ウィンドウにおける変更のためにｒｍ
ｅｓｓａｇｅを送信らなければならないことを示すフラ
グ。ウィンドウ状態１９３３：ウィンドウの現在の状態
を示す情報。そして、ビット・リード情報１９３５：ウ
ィンドウのビット・マップからビットを読み出すために
必要な情報。 【０１３１】ファイル木構造１５０１に対するファイル
・ロケータ処理 ウィンドウ・サービス１４０５は、プロトコル・サービ
ス２０９として、マウント・サービス２０３からｔｍｅ
ｓｓａｇｅを受け取ると、このｔｍｅｓｓａｇｅに対し
、マウント・サービス２０３に返すｒｍｅｓｓａｇｅに
よって応答する。以下において、ウィンドウ・サービス
１４０５がｔｍｅｓｓａｇｅのいくつかに応答する方法
をを説明し、マウント・サービス２０３とプロトコル・
サービス２０９との間の相互作用をプロトコル・サービ
ス２０９から見た例を与える。 【０１３２】ｔｍｅｓｓａｇｅによって指定される処理
を２つあげれば、ａｔｔａｃｈおよびｗａｌｋファイル
・ロケータ処理である。まず、ａｔｔａｃｈ処理につい
ては、既に述べたとおり、マウント・システム・コール
の実行の結果、マウント・サービス２０３により、その
ファイル記述子４１７がマウント・システム・コールに
おいて使用されたプロトコル・チャネルによって表され
るプロトコル・サービス２０９にａｔｔａｃｈ返信メッ
セージが送られる。好ましい実施例では、マウント・シ
ステム・コールは、さらに、マウント・サービス２０３
がａｔｔａｃｈ往信メッセージに入れてプロトコル・サ
ービス２０９に送るデータを含む。プロトコル・サービ
ス２０９が、ウィンドウ・サービス１４０５ならば、そ
のデータには、スロット数が含まれる。 ウィンドウ・サービス１４０５は、このａｔｔａｃｈ往
信メッセージに応じて、ａｔｔａｃｈ往信メッセージに
含まれるファイル識別子に対するエントリ１８０５を発
見し、ビジー１８０７を１に、オープン１８０９を０に
それぞれ設定する。次に、ウィンドウ・サービス１４０
５は、インスタンスにファイル構造体１８１３を割り当
て、スロット・フィールド１８１９をルート・ディレク
トリを指定する値に設定し、さらにｄｐｔｒ１８２１を
ルート１５０２に対するディレクトリ・エントリ１８２
３を示すように設定する。ウィンドウ・サービス１４０
５によって返されるａｔｔａｃｈ返信メッセージには、
ｆｔｙｐｅ１８１７およびスロット１８１９から作られ
たｑｉｄ３２３が含まれる。最後に、スロットに関係付
けられたウィンドウ１９０５における参照カウンタがイ
ンクリメントされる。 【０１３３】既に述べたとおり、パス名の分析時に呼び
出されたチャネル３０１がプロトコル・サービス２０９
におけるファイルを表すときに、ｗａｌｋ往信メッセー
ジが生成される。この往信メッセージによって、プロト
コル・サービス２０９におけるディレクトリに対するフ
ァイル識別子３３１およびそのディレクトリにおけるフ
ァイルの名前が指定される。返信メッセージにより、そ
の名前によって指定されたインスタンスのｑｉｄが、返
される。この時、往信メッセージにおけるファイル識別
子３３１が、返されたｑｉｄに関係付けられる。好まし
い実施例において、ウィンドウ・サービス１４０５は、
ｗａｌｋ往信メッセージに応じて、ファイル識別子３３
１に対するエントリ１８０５の位置を特定して、その名
前を見る。 その名前が、ルート１５０２を示す「．」ならば、エン
トリ１８０５内のファイル・ポインタ１８１１によって
示されるファイルは、そのルート・ディレクトリを記述
する。この場合、そのファイル１８１３におけるｑｉｄ
３２３が、返信メッセージに入れて返され、そうでない
場合、その名前に対応する同じフィールド１８２５を有
する記述エントリ１８２３が見つかるまで、ファイル記
述の配列が探査される。エントリ１８２３からのｆｔｙ
ｐｅフィールド１８２７の値およびディレクトリに対す
るファイル１８１３からのスロット１８１９の値が、保
存される。次に、現在使用されているすべてのファイル
構造体１８１３が、探査され、保存されたスロット値を
スロット１８１９に、保存されたファイル型の値をｆｔ
ｙｐｅフィールド１８１７にそれぞれ持つものが求めら
れる。見つかった場合、それらの保存された値は、ｑｉ
ｄ３２３として返され、見つからなかった場合は、新た
なファイル構造体１８１３が割り当てられて、ｆｔｙｐ
ｅフィールド１８１７が保存されたファイル型の値から
設定され、スロット１８１９が保存されたスロット値か
ら設定され、ｄｐｔｒ１８２１がその名前を持っていた
ファイル記述の配列のエントリを示すように設定され、
ビジーが１に設定され、ファイル識別子３３１に対する
エントリ１８０５のｆｐｔｒ１８１１が新たなファイル
構造体を示すように設定される。そして、保存されたス
ロットおよびｆｔｙｐｅの値は、ｑｉｄ３２３として返
される。 【０１３４】ウィンドウ・サービス１４０５の内部構造
：図１６〜１９および図２１ 好ましい実施例においては、ウィンドウ・サービス１４
０５は、第９案のオペレーティング・システムの下で実
行する３つのプロセス１０２によって実施される。図１
６において、ウィンドウ・サービス１４０５（０）にあ
たるこれら３つのプロセス１０２、ならびにカーネル・
サービス＃ｂ１４１１、＃ｃ１４１９およびウィンドウ
・サービス１４０５のクライアント（依頼主）であるプ
ロセス１０２に対する関係を説明する。クライアントで
あるプロセス１０２は、図１６において、ＣＰ１６１５
（０）、ＣＰ１６１５（１）、および第２のウィンドウ
・サービス１４０５（１）を構成する３つのプロセスと
して現れるが、これは、また、ウィンドウ・サービス１
４０５（０）のクライアントでもあり、かつそれ自体が
、図１６には示していないクライアントを有する。この
ように、図１６には、３つのレベルの端末サービスが存
在する。 即ち、カーネル・サービス＃ｂおよび＃ｃによって与え
られる実端末サービス、ウィンドウ・サービス１４０５
（０）によってそのクライアントに与えられる第１水準
の仮想端末サービス、およびウィンドウ・サービス１４
０５（１）によってそのクライアントに与えられる第２
水準の仮想端末サービスである。さらに詳細に後述する
が、各水準の端末サービスは、異なる名前背景（ＮＣ）
１６２１に対応する。例えば、名前背景１６２１（０）
においては、ファイル名「ｍｏｕｓｅ」は、カーネル・
サービス１４１１によって与えられるｍｏｕｓｅファイ
ルを示し；名前背景１６２１（１）においては、ファイ
ル名「ｍｏｕｓｅ」は、ウィンドウ・サービス１４０５
（０）によって与えられるファイル木構造１５０１のう
ちの１つにあるファイルを示し；名前背景１６２１（２
）においては、ファイル名「ｍｏｕｓｅ」は、ウィンド
ウ・サービス１４０５（１）によって与えられるファイ
ル木構造１５０１のうちの１つにあるファイルを示す。 【０１３５】まず、ウィンドウ・サービス１４０５（０
）については、ウィンドウ・サービス１４０５（０）を
構成する３つのプロセスは、主プロセス１６１３（０）
、マウス従プロセス（ＭＳ）１６０３（０）、およびキ
ーボード従プロセス（ＫＳ）１６０５（０）である。主
プロセス１６１３（０）は、ウィンドウ・サービス１４
０５（０）のクライアントからパイプ１６０７（０）を
介して往信メッセージを受信し、この往信メッセージに
応じて、返信メッセージをパイプ１６０６（０）を介し
てクライアントに与える。往信メッセージおよび返信メ
ッセージは、図１６では２０５（０）および２０７（０
）として現れる。往信メッセージが、＃ｂ１４１１およ
び＃ｃ１４１９によって与えられるファイルに対する処
理を必要とする場合、主プロセス１６１３（０）は、第
９案のリードおよびライトのシステム・コールを用いて
必要な処理を行う。前記のとおり、第９案のオペレーテ
ィング・システムは、ファイル・システム・コールをフ
ァイル・サービス＃ｂまたは＃ｃに適合する種類の要求
２１７および２１９へと自動的に変換する。 【０１３６】マウス従プロセス１６０３（０）およびキ
ーボード従プロセス１６０５（０）が、必要なのは、＃
ｂ１４１１によって与えられるｍｏｕｓｅファイルまた
は＃ｃ１４１９によって与えられるｃｏｎｓファイルに
対するファイル・リード処理を行うプロセス１０２が、
そのファイルから読み出されるべき実際のデータがない
限り、ブロックするからである。主プロセス１６１３（
０）は、そのクライアントからの往信メッセージに常に
応答できなければならないので、ブロックすることはで
きず、従って、＃ｂにおけるｍｏｕｓｅファイルまたは
＃ｃにおけるｃｏｎｓファイルに対し、リード処理を直
接行うことはできない。 これらのリードは、それぞれマウス従プロセス１６０３
（０）およびキーボード従プロセス１６０５（０）によ
って行われる。これら２つの従プロセスは、共に、主プ
ロセス１６１３（０）のクライアントである。マウス従
プロセス１６０３（０）の処理は、両者に典型的である
。マウス従プロセス１６０３（０）は、これが＃ｂ１４
１１によって与えられるファイルｍｏｕｓｅに対して第
９案のシステム・リード・コールを行うときのループを
単に実行し、さらにウィンドウ・サーバ１４０５（０）
によって与えられるファイル木構造１５０１にうちの１
つにあるファイルｍｏｕｓｅに対して第９案のシステム
・ライト・コールを行う。好ましい実施例における慣例
により、マウス従プロセス１６０３（０）およびキーボ
ード従プロセス１６０５（０）によって書き込まれるフ
ァイル木構造１５０１は、常に、スロット１４０７（０
）を持つものである。勿論、第９案のオペレーティング
・システムは、ファイル・システム・コールを＃ｂによ
って適切な要求２１５に与えられたｍｏｕｓｅファイル
に、ファイル・システム・コールをパイプ１６０７を介
して主プロセス１６１３に送られるｗｒｉｔｅ往信メッ
セージにウィンドウ・サーバ１４０５（０）によって与
えられるｍｏｕｓｅファイルに自動的に変換する；主プ
ロセス１６１３は、そのｗｒｉｔｅ往信メッセージに、
他のクライアントからの往信メッセージと同じように応
答する。 【０１３７】以上より明らかなように、マウス従プロセ
ス１６０３（０）は、２つの異なる名前背景１６２１に
存在するｍｏｕｓｅファイルに対してファイル処理を行
っている。リード処理は、名前背景１６２１（０）にあ
るｍｏｕｓｅファイルに対するものであり、一方ライト
処理は、名前背景１６２１（１）にあるｍｏｕｓｅファ
イルに対するものである。この状態は、マウス従プロセ
ス１６０３（０）において、第９案のｏｐｅｎ、ｆｏｒ
ｋｐｇｒｐ、およびｍｏｕｎｔの処理を用いることによ
って達成される。これを行う方法を図１７に示した。関
数ｍｋｓｌａｖｅ１７０１を用いて、マウス従プロセス
１６０３（０）およびキーボード従プロセス１６０５（
０）の両方を作る。この関数は、２つの引数−−−パス
名、および各リード処理の時に読むべきバイト数を指定
する計数−−−を持ち、それが生成した従プロセスのプ
ロセス識別子（ｐｉｄ）を返す。 【０１３８】ｍｋｓｌａｖｅ１７０１は、主プロセス１
６１３（０）によって、引数「／ｄｅｖ／ｍｏｕｓｅ」
および「１０」を付けて呼び出される。主プロセス１６
１３（０）は、その中でカーネル・サービス＃ｂ１４１
１がカーネル・ルート・ファイル・サービスによって与
えられるファイル／ｄｅｖに結合されているような名前
空間１１５を有するので、パス名「／ｄｅｖ／ｍｏｕｓ
ｅ」は分析されて、カーネル・サービス＃ｂ１４１１に
よって与えられるファイル「ｍｏｕｓｅ」を表すチャネ
ル３０１を指定するファイル記述子４１７となる。この
事実は、図１７の最上部にある表記「名前背景１６２１
（０）」によって示される。主プロセス１６１３（０）
は、マウス従プロセス１６０３（０）を生成するために
ｍｋｓｌａｖｅ１７０１を使用する時点で、既にパイプ
１６０７（０）生成し、かつウィンドウ・サービス１４
０５（０）をｓｒｖに登録している。ウィンドウ・サー
ビス１４０５（０）を表すｓｒｖのファイルに書き込ま
れるファイル記述子は、パイプ１６０７（０）によって
表されるファイルに対するファイル記述子のうちの１つ
である。このファイル記述子は、以下において「ｃｆｄ
」と称するが、ウィンドウ・サービス１４０５（０）の
クライアントが往信メッセージを書き込むファイルを表
す。 【０１３９】ｍｋｓｌａｖｅ１７０１が最初に行うこと
は、パス名引数荷よって指定されたファイルを開くこと
である（１７０５）。依然として名前背景１６２１（０
）にあるので、そのファイルは、＃ｂ１４１１によって
与えられるファイル「ｍｏｕｓｅ」である。オープン処
理の結果として、ファイル記述子ｆｄ１は、この時点で
、＃ｂのファイル「ｍｏｕｓｅ」を表す。次に、ｆｏｒ
ｋ関数を含んだｓｗｉｔｃｈ文がくる（１７０７）。こ
のｆｏｒｋ関数は、親プロセス１６１３（０）の背景の
コピーを有し、従ってｆｄ１のコピーを有する新たな子
プロセス１０２を生成する。その子プロトコル・サービ
ス２０９は、また親プロセス１６１３（０）と同じ名前
空間１０５を有する。このｓｗｉｔｈｃ文には３つの分
岐がある。第１の分岐１７０９は、ｆｏｒｋ関数の実行
中の発生するエラーを処理する。第２の分岐１７１３は
、親プロセス１６１３（０）によって実行されるが、子
プロセス１６０３（０）によっては実行されないような
コードである。ブロック１７３７および１７３９によっ
て示したように、このコードは、ｆｄ１の親プロセス１
６１３（０）のコピーをクローズし、子プロセス１６０
３（０）のｐｉｄであるｐｉｄを返す。 【０１４０】ｓｗｉｔｃｈ文の第３の分岐１７１５は、
子プロセス１６０３（０）によってのみ実行されるコー
ドである。まず、子プロセス１６０３（０）に新たな名
前空間１０５を与えるために「ｆｏｒｋｐｇｒｐ」が実
行される。ｆｏｒｋｇｒｐが引数「０」と共に呼び出さ
れるので、その新たな名前空間は、親プロセス１６１３
の名前空間１０５のコピーである。次に、システム・マ
ウント処理が、行われる（１７２１）。このマウントは
、ｃｆｄ−−−これは、ウィンドウ・サービス１４０５
（０）のクライアントによって使用されるパイプ１６０
７（０）の最後を表す−−−を、ＢＥＦＯＲＥオプショ
ンを用いて、新たな名前空間１０５におけるディレクト
リ／ｄｅｖに結合する。マウント処理の結果として、サ
ービス１４０５（０）のファイル１４０６のスロット０
にあるファイル木構造１５０１は、／ｄｅｖに結合され
ていて、／ｄｅｖ／ｃｏｎｓなどのファイルへの参照は
、この時点で、ファイル１４０６のスロット０における
ファイルｃｏｎｓへの参照となる。しかし、プロセス１
６０３（０）の名前空間１０５は変化し、「ｃｆｄ」は
／ｄｅｖにマウントされているので、オープン・システ
ム・コールにおけるパス名引数は、この時点で、サービ
ス＃ｂ１４１１　におけるファイル「ｍｏｕｓｅ」では
なく、サービス１４０５（０）のスロット０のファイル
木構造にあるファイル「ｍｏｕｓｅ」と分析される。こ
の名前背景の変化を図１７にブロック１７１７に続く波
線によって示した。ブロック１７１７において、名前背
景１６２１（０）は、名前背景１６２１（１）から分離
される。 【０１４１】オープン・システム・コールによって返さ
れたファイル記述子４１７は、「ｆｄ２」に割り当てら
れる。従って、この時点で、ｆｄ１は、サービス１４１
１におけるファイル「ｍｏｕｓｅ」を表し、ｆｄ２は、
サービス１４０５（０）のスロット０にあるファイル「
ｍｏｕｓｅ」を表す。ｓｗｉｔｃｈ１７０７の第３の分
岐の残りの部分は、マウス従プロセス１６０３が、ｆｄ
１を用いてリード・システム・コールを行うループ１７
３５であり、それは、サービス＃ｂ１４１１におけるｍ
ｏｕｓｅファイルを読み（１７２５）、さらにｆｄ２お
よびサービス＃ｂ１４１１におけるｍｏｕｓｅファイル
から受け取ったデータを用いてライト・システム・コー
ルを行い、そのデータをサービス１４０５（０）のスロ
ット０にあるｍｏｕｓｅファイルに書き込む（１７３３
）。書込みが失敗の場合、即ち、サービス＃ｂ１４１１
から受け取っただけのデータをサービス１４０５（０）
に書き込むことができない場合、このプロセスは、出る
（１７３１）。キーボード従プロセス１６０５（０）も
全く同じようにして生成されるが、ｍｋｓｌａｖｅ１７
０１の呼び出しでは、パス名として「／ｄｅｖ／ｒｃｏ
ｎｓ」を指定し、バイト長として「１」を指定する点が
異なる。従って、キーボード従プロセス１６０５による
ｆｄ１に対する各リードは、キーボードから１文字を読
み、プロセス１６０５によるｆｄ２に対する各ライトは
、スロット０にあるファイル木構造１５０１の「ｒｃｏ
ｎｓ」ファイルに１文字を書き込む。ここでは「ｒｃｏ
ｎｓ」が使用されるので、ウィンドウ・サービス１４０
５（０）は、文字を、ちょうどそれらがキーボードから
入力されたとおりに受け取る。 【０１４２】ｍｋｓｌａｖｅ関数によって、第９案にお
けるファイル・アクセス処理、ならびに「ｆｏｒｋ」お
よび「ｆｏｒｋｐｇｒｐ」システム・コールのセマンテ
ィックス（意味と動作の関係）の基本的な意義がいくつ
か説明される。まず、ファイル・アクセス処理では、パ
ス名ではなくファイル記述子４１７によってファイルを
参照する；代わって、ファイル記述子がチャネルを参照
し、そして、チャネル３０１が所与のファイルを表す限
り、そのチャネルを参照するファイル記述子を使用する
ファイル・アクセス処理は、所与のファイルをアクセス
することになる。 さらに、「ｆｏｒｋ」が新たなプロセス１０２を生成す
ると、その新たなプロセス１０２は、古いプロセス１０
２の背景のコピーを受け取る。この背景にはファイル記
述子配列４１３が含まれる；従って、新たなプロセス１
０２は、そのｆｏｒｋシステム・コールを実行したプロ
セス１０２に対し開かれていた任意のファイルに対して
ファイル・アクセス処理を行うことができる。最後に、
「ｆｏｒｋｐｇｒｐ」は、新たな名前空間１１５を生成
するとき、ｆｏｒｋｐｇｒｐを実行しているプロセス１
０２に対し新たなマウント・テーブル８０１を生成する
に過ぎない；そのプロセス１０２に対するファイル記述
子配列４１３は、不変のままである。このようなことか
ら、ｍｋｓｌａｖｅ１７０３を実行するプロセス１０２
は、同じパス名を用いて、カーネル・サービス＃ｃ１４
１９のファイル「ｒｃｏｎｓ」およびウィンドウ・サー
ビス１４０５のファイル「ｒｃｏｎｓ」を開くことがで
きる。さらに詳細に後述するように、ファイル・アクセ
ス処理、「ｆｏｒｋ」および「ｆｏｒｋｐｇｒｐ」のセ
マンティックスにより、サービスの再帰的な生成も可能
である、即ち、サービスは、クライアントとして、それ
自体の別のインスタンスを持つことができる。 【０１４３】また、パイプ１６０７（０）は、主プロセ
ス１６１３（０）をそのクライアント１６１５（０およ
び１）およびウィンドウ・サービス１４０５（１）に接
続する。パイプ１６０７は、主プロセス１６１３（０）
によって生成されたので、主プロセス１６１３（０）は
、それが返信メッセージを書き込む先のパイプ１６０７
（０）内のファイルを表すサービス・ファイル記述子１
６１７（０）を有する。各クライアント・プロセスは、
そのクライアントが往信メッセージを書き込む先のパイ
プ１６０７（０）内のファイルを表すクライアント・フ
ァイル記述子１６１９（０）を有する。クライアント・
プロセスは、主プロセス１６１３（０）によって、生成
され、かつクライアント・ファイル記述子１６１９（０
）が与えられている。Ｇｎｏｔ７１１の利用者が画面１
２７において新たなウィンドウを要求する度に、新たな
クライアント・プロセスが、生成される。好ましい実施
例において、新たなウィンドウは、マウス１４２３を用
いて画面１４２７上のメニューからその選択肢を選ぶこ
とによって、要求される。 【０１４４】マウス１４２３によってメニューから新た
なウィンドウを選択すると、結果として、マウス従プロ
セス１６０３（０）が、サービス＃ｂ１４１１によって
与えられるｍｏｕｓｅファイルに対するリードを完了し
、そのｍｏｕｓｅファイルから読み出したデータをサー
ビス１４０５（０）のスロット０にあるｍｏｕｓｅファ
イルに書き込む。結果的に、主プロセス１６１３（０）
へのパイプ１６０７（０）上に往信メッセージが発生し
、この往信メッセージに応じて、主プロセス１６１３（
０）は、新たなウィンドウに対しウィンドウ構造体１９
０３を位置付けて用意する。次に、主プロセス１６１３
（０）は、引数として新たなウィンドウに対するスロッ
トを用いて関数「ｓｐａｗｎ」を呼び出す。ｓｐａｗｎ
は、クライアント・プロセス１６１５を生成し、引数に
おいて指定されたスロットに対するウィンドウ・サービ
ス１４０５（０）におけるファイル木構造１５０１をク
ライアント・プロセス１６１５の名前空間１０５の一部
とし、さらに新たなクライアント・プロセス１６１５に
おけるシェル・プログラムを実行する。 【０１４５】図２１において、ｓｐａｗｎ関数２１０１
は、まず同期パイプをオープンする（２１０５）。同期
パイプの目的は、新たなクライアント・プロセス１６１
５が走るまで、主プロセス１６１３（０）が進まないこ
とを確実にするためである。次に、ｓｗｉｔｃｈ文にお
けるｆｏｒｋシステム・コールを実行することによって
、クライアント・プロセス１６１５が生成される（２１
０７）。ｆｏｒｋに関しエラーがあった場合、分岐２１
０９が取られ、エラーを示す値−１が返される。ｆｏｒ
ｋが成功した場合、主プロセス１６１３（０）が、分岐
２１１３に示したように進行する；ｓｙｎｃｈパイプを
読み（２１１５）、子に対するｐｉｄを返す（２１１７
）。新たなクライアント・プロセス１６１５がｓｙｎｃ
ｈパイプにデータを置くまで、主プロセス１６１３（０
）は、リードを完了できないので、主プロセス１６１３
は、新たなクライアント・プロセス１６１５が走るまで
は、戻らない。 【０１４６】分岐２１０７は、新たなクライアント・プ
ロセスがどのように進むかを示す。まず、新たなクライ
アント・プロセス１６１５は、ｆｏｒｋｐｇｒｐを実行
することによって、新たな名前空間を得る（２１１９）
。引数「０」が使用されるので、その新たな名前空間は
、主プロセス１６１３の名前空間のコピーである。そこ
で、クライアント・プロセス１６１５は、主プロセス１
６１３（０）が実行を継続できるように、ｓｙｎｃｈパ
イプへのライトを行う（２１２１）。次に、プロセス１
６１５は、ウィンドウ・サービス１４０５（０）からフ
ァイル木構造１５０１をマウントするべき標準の場所を
示すパス名にｃｄｆ１６１９（０）をマウントする。こ
れを行うために使用されるマウント・システム・コール
は、引数としてスロット数を含む（２１２３）。前記の
ように、クライアント・プロセス１６１５におけるマウ
ント・システム・コールの結果として、ａｔｔａｃｈ往
信メッセージがパイプ１６０７（０）を介してウィンド
ウ・サービス１４０５（０）に送られる；ウィンドウ・
サービス１４０５（０）が、このａｔｔａｃｈ往信メッ
セージに応じて、スロット数によって指定されたスロッ
トにおけるファイル木構造１５０１のルートに対するｑ
ｉｄを返し、そのｑｉｄが、ｃｆｄ１６１９によって指
定されるチャネル３０１に置かれる（勿論、クライアン
ト・プロセス１６１５は、生成されたときに、ｃｆｄ１
６１９の新たなコピーが与えられた）。次に、ｂｉｎｄ
システム・コールを用いて、ファイル木構造１５０１が
マウントされた先のパス名を／ｄｅｖに結合する（２１
２５）。「ＢＥＦＯＲＥ」オプションを使用するので、
／ｄｅｖ／ｍｏｕｓｅのようなパス名は、この時、スロ
ット数によって指定されるスロットにあるファイル木構
造１５０１におけるファイル「ｍｏｕｓｅ」へと分析さ
れる。 【０１４７】次に、ｓｙｎｃｈパイプに対するファイル
記述子によって表されるファイル、パイプ１６０６（０
）のサービス端、および標準Ｉ／Ｏがクローズされる（
ブロック２１２７、２１２９、２１３１）。第９案の慣
例により、あるプロセスに属する標準Ｉ／Ｏに対するフ
ァイルは、ファイル記述子０および１を有する；従って
、ステップ２１３１においてこれらのファイルをクロー
ズすることにより、それらの記述子は、以降の用途に確
実に使用できるようになる。次に、読み出すために／ｄ
ｅｖ／ｃｏｎｓを開く（２１３３）。このオープン・シ
ステム・コールによって、ｗａｌｋ往信メッセージが発
生し、これにより、ファイル２４０６の適切なスロット
に／ｄｅｖ／ｃｏｎｓに対するファイル木構造１８１３
が生成され、さらに前記コールによりｏｐｅｎ往信メッ
セージが発生し、これによって、１に設定されているフ
ァイルに対するエントリ１８０５に対するファイル１８
０９が開かれる。ｏｐｅｎは、クライアント・プロセス
１６１５に対するファイル記述子配列４１３の最初から
ファイル記述子４１７を捜し始めるので、ｏｐｅｎによ
って返されるファイル記述子は、ファイル記述子０とな
り、／ｄｅｖ／ｃｏｎｓは、標準入力ファイルとして作
用することになる。続いて、ｏｐｅｎシステム・コール
は、読むために／ｄｅｖ／ｃｏｎｓをオープンする；結
果は既に説明したとおりであるが（２１３５）、ｏｐｅ
ｎによって返されるファイル記述子４１７は、ファイル
記述子１となり、／ｄｅｖ／ｃｏｎｓは、標準出力ファ
イルとして作用する点が異なる。ステップ２１３７にお
いて、ファイル記述子１がオープンされるので、ファイ
ル記述子２−−−これは、慣例により標準エラー・ファ
イルを表す−−−がファイル記述子１と同じファイルを
表すことになり、エラー・メッセージが、／ｄｅｖ／ｃ
ｏｎｓに出力される。最後に、シェル・プログラム−−
−第９案のユーザ・インタフェースを与えるーーーが、
実行される（２１３９）。 【０１４８】ここで、新たなクライアント・プロセス１
６１５が、ウィンドウ・サービス１４０５に対するプロ
グラムを実行すると、結果は、ウィンドウ・サービス１
４０５（０）のクライアントである新たなウィンドウ・
サービス１４０５（１）である。ウィンドウ・サービス
１４０５（１）は、ウィンドウ・サービス１４０５（０
）と同じ構成要素を有し、その従プロセスおよびクライ
アント・プロセスにパイプ１６０７（１）によって接続
されている。 ウィンドウ・サービス１４０５（１）は、ウィンドウ・
サービス１４０５（０）と全く同様に作用するが、新た
なクライアント・プロセス１６１５（１）の名前空間１
０５に設けられている、即ち、／ｄｅｖ／ｍｏｕｓｅま
たは／ｄｅｖ／ｃｏｎｓなどのパス名は新たなクライア
ント・プロセス１６１５に属するサービス１４０５（０
）のスロット１４０７にあるファイル木構造１５０１に
おけるファイルを指す点が異なる。従って、これらのフ
ァイルに対するリードおよびライトは、カーネル・サー
ビス＃ｂおよび＃ｃの代わりに、ウィンドウ・サービス
１４０５（０）へのパイプ１６０７（０）を介する往信
メッセージを発生する結果となる。そして、ウィンドウ
・サービス１４０５（０）が、ウィンドウ・サービス１
４０５（１）からの往信メッセージに応じて、カーネル
・サービス＃ｂおよび＃ｃへの要求を生成する。 【０１４９】主プロセス１６１３の内部構造：図２０図
２０において、主プロセス１６１３は、クライアント・
プロセス１６１５、マウス従プロセス１６０３、および
キーボード従プロセス１６０５からの往信メッセージ２
０５および２０７を処理し、それらの往信メッセージに
応じて、ウィンドウ・データ構造体１９０３を更新する
。そして、＃ｂ１４１１および＃ｃ１４１９によって与
えられるファイルに対するファイル・アクセス・システ
ム・コールにおいてウィンドウ・データ構造体１９０３
の情報を使用する。好ましい実施例において、主プロセ
ス１６１３は、次の主な構成要素を含む。Ｉ／Ｏ関数２
０１９：ウィンドウ・サービス１４０５のクライアント
、マウス従プロセス１６０３およびキーボード従プロセ
ス１６０５からの往信メッセージ２０５および２０７に
応答する。マウス制御タスク２００８：Ｉ／Ｏ関数２０
１９がマウス従プロセス１６０３から受信する往信メッ
セージを処理するタスク。キーボード制御タスク２００
９：Ｉ／Ｏ関数２０１９がキーボード従プロセス１６０
５から受信した往信メッセージを処理するタスク。ウィ
ンドウ制御タスク２００５：ウィンドウ・データ構造体
１９０３のデータをマウス１４２３からの入力の要求ど
おりに更新するタスク。各ウィンドウ１９０３（０・・
ｎ）に対応する端末制御タスク２０１５（０．．ｎ）：
キーボード制御２００９およびウィンドウ制御２００５
からの入力の要求どおりに対応するウィンドウ２０１３
の状態を変更し、そのウィンドウが属するクライアント
・プロセス１６１５に要求どおりの返信メッセージを送
り、さらに変更したとおりにウィンドウを表示するため
に、＃ｂ１４１１および＃ｃ１４１９によって与えられ
たファイルにライト処理を行う。 【０１５０】主プロセス１６１３のタスク構成要素は、
ウィンドウ１９０３の状態を変更する事象に応じて主プ
ロセス１６１３が計画して走らせる主プロセス１６１３
の内部の実体である。従って、これらのタスクは、プロ
セスの一般的性質をいくつか有するが、第９案のプロセ
ス１０２ではない。特に、それらは、すべて、名前空間
１０５も含めて主プロセス１６１３の背景を共有する。 タスクのスケジュリング規則は次のとおりである。即ち
、あるタスクが責任を有する資源の状態を変更するＩ／
Ｏ関数２０１９において、メッセージが受信されると、
直ちに、そのタスクが、実行予定のキュウーに配置され
、そのキュウーが空の場合は、直ちにＩ／Ｏ関数２０１
９が実行される。 【０１５１】構成要素２００１の処理は、およそ次のと
おりである。Ｉ／Ｏ関数２０１９は、往信メッセージを
得るために、パイプ１６０７のサービス・ファイル記述
子１６１７によって指定されるファイルを読む。往信メ
ッセージが、ファイル位置づけ処理を指定した場合、Ｉ
／Ｏ関数２０１９は、そのメッセージ自体を処理して、
適切な返信メッセージを返す。前記の往信メッセージが
、ファイル・アクセス処理を指定した場合、Ｉ／Ｏ関数
２０１９は、そのメッセージを送ったプロセスに属する
ウィンドウ構造体１９０３（ｉ）を見つけ、その構造体
１９０３の情報を矢印２０１９で示したように更新して
、端末制御２０１５（ｉ）を走らせる予定をする。端末
制御タスク２０１５（ｉ）が走る場合、ウィンドウ１９
０３（ｉ）を矢印２０２３および２０２５で示したよう
に更新し、その更新により必要とされる動作を行う。そ
のような動作の例としては、矢印２０７によって示した
ようなウィンドウ１９０３（ｉ）が属するプロセスへの
返信メッセージがある。この返信メッセージは、パイプ
１６０７にあるクライアント・ファイル記述子１６１９
によって表されるファイルに書き込まれる。もう１つの
例は、矢印２１９によって示したような、ウィンドウ１
９０３（ｉ）に対応する画面１４２７におけるウィンド
ウを再描画する＃ｂ１４１１および＃ｃ１４１９へのラ
イト処理である。少し時間をおいて、Ｉ／Ｏ関数２０１
９は、実行を再開し、パイプ１６０７から新たに往信メ
ッセージを読む。 【０１５２】マウス従プロセス１６０３およびキーボー
ド従プロセス１６０５からメッセージを受信するのは、
特殊な場合である。メッセージがマウス従プロセス１６
０３からのもでであれば、Ｉ／Ｏ関数２０１９は、その
メッセージをグローバルな記憶装置のマウス・メッセー
ジ２００２に書き込み、マウス制御タスク２００８を予
定する。そのタスク２００８が、走ると、マウス・メッ
セージ２００２をマウス・データ２００６に変換し、さ
らにウィンドウ制御２００５を予定に入れる。ウィンド
ウ制御２００５は、マウス・データ２００６を調べて、
現在のウィンドウ２０１３を決定する。現在のウィンド
ウ２０１３とは、マウス１４２３からデータを受信した
ときにカーソルが位置していた画面１４２７上のウィン
ドウに対応するウィンドウ構造体１９０３のことである
。マウス・データ２００６が、現在のウィンドウ２０１
３と一致しない画面１４２７内のウィンドウを示す場合
、ウィンドウ制御２００５は、マウス・データ２００６
によって指定される画面１４２７内のウィンドウに対応
するウィンドウ構造体１９０３を新たな現在のウィンド
ウ２０１３とする。そして、現在のウィンドウ２０１３
をマウス・メッセージによって要求されるように更新し
て、その新たな現在のウィンドウに対する端末制御２０
１５を予定する。端末制御２０１５が実行すると、端末
制御２０１５は、画面を再描画するライト処理を行い、
必要なメッセージをマウス従プロセス１６０３に送る。 メッセージが、キーボード従プロセス１６０５からのも
のである場合、Ｉ／Ｏ関数２０１９は、マウス従プロセ
スで示したように進むが、新たに入力された文字がグロ
ーバルな記憶装置のＫＢＤＣ２００４に書き込まれて、
キーボード制御２００９が予定される点が異なる。キー
ボード制御２００９が走ると、現在のウィンドウ２０１
３を変更し、現在のウィンドウ２０１３に対する端末制
御２０１５を予定する。端末制御２０１５は、既に説明
した処理を行う。 【０１５３】詳細な例：保持ファイル１５０７に対する
処理：図２２および２３ ウィンドウ・サービス１４０５によって与えられるファ
イル木構造１５０１の「保持」ファイル１５０７は、対
話的なプログラムのための文字入力インタフェースの改
良を実施する場合に、使用する。このようなインタフェ
ースにおける典型的な問題部分は、この改良によって解
決される。このようなインタフェースにおいては、線の
端を示すのに使用される線終端コード（一般に、改行ま
たは復帰）は、３つの異なる機能を有する。即ち、一連
のテキストを表示する場合、それをどのように行に分割
するかを指定する；対話的なプログラムに入力されてい
る場合、最後の行の終端子と現在の行の終端子との間の
テキストの文字列が送られるべきことを指定する；およ
び、コマンド行インタフェースの場合、最後の行の終端
子と現在の行の終端子との間のテキストの文字列が実行
されるべきことを指定する。従って、典型的な対話型ユ
ーザ・インタフェースにおいては、利用者が、行終端コ
ードを使用する場合、その行に関しては終了しており、
その行は、その利用者が行終端コードを使用したときの
ままの状態で、表示され、送られ、そして実行される。 【０１５４】この構造に本質的な問題は明白であり、従
来の技術は、その幾つかを特殊な文字によって解決して
きた。こうして、表示のために改行を阻止するべく特殊
文字を用いることがあり、コマンド行インタフェースで
は、コマンド行の入力が次の行へと続くことを示すため
に別な特殊文字をたいてい使用する。これまで解決され
てこなかったものは、行が行終端文字に応じて対話型プ
ログラムに送られるという事実から起こる問題である。 その結果、対話型プログラムでは、行終端コードを入力
するまでは、その行を編集することが許されるが、一方
、僅かに編集プログラムにおいては、行を入力し、行終
端コードを入力した後に、入力済みの行に戻って編集す
ることが一般に許される。この問題に有効な解決策と言
えば、ファイルから入力を読み出すような対話型プログ
ラムを設計し、入力ファイルをエディタを用いて生成し
たうえで、そのファイルを対話型プログラムに与えるこ
とぐらいであった。必要であり、かつウィンドウ・サー
ビス１４０５によって与えられるものは、利用者が指定
するまでは入力中の文字列が送られないようにする方法
である。 【０１５５】ウィンドウ・サービス１４０５では、この
問題を次のように扱う。第１のモードにおいて、行終端
コードにより、これまでのように行が送られるようにす
る。第２のモードにおいて、端末においてキーを叩くこ
とにより入力されると、そのモードに入ったときから出
るまでの間に入力文字が、そのモードから出た時点で送
られる。ここでは、第２のモードを保持モードと称する
。好ましい実施例において、保持モードからは、入った
ときに使用したものと同じキーを叩くことによって出る
。さらに、好ましい実施例において使用されるカーソル
およびウィンドウの境界線の形によって、そのウィンド
ウが現在、保持モードにあるかどうかを示す。好ましい
実施例では、カーソルは矢印である。保持モードにおけ
るカーソルは、中抜きの矢印であり、その他の場合は、
ベタの矢印である。 【０１５６】図２２において、ウィンドウ構造体１９０
３におけるウィンドウ記述情報には、現在のカーソルに
対するビット・マップを示すｃｕｒｓｏｒｐフィールド
２２０３が含まれる。ｑｈ１９１４は、テキスト１９１
５における現在位置を示すポインタであり、代わりに、
ウィンドウ・データ構造体１９０３（ｉ）によって表さ
れるウィンドウに表示されているテキストを収容してい
る。 【０１５７】ｃｏｎｓ　ｒｅａｄ　ｉｎｆｏ１９２１は
、３つのフィールドからなり、ウィンドウ構造体１９０
３（ｉ）に対応するファイル木構造１５０１にあるファ
イルｃｏｎｓおよびｒｃｏｎｓに対するリードを指定す
る最も最近のｔｒｅａｄメッセージからの情報を格納す
る。それらのフィールドは、次のとおりである。ｒｔａ
ｇ２２０５：メッセージからのタグを収容する。ｒｆｉ
ｄ２２０７：メッセージからのｆｉｄを収容する。ｒｃ
ｎｔ２２０９：メッセージからの計数であり、読み出す
べき文字数を指定する。ＲＱＰＴＲ１９２７は、優先す
るｔｒｅａｄを満たすために実行されるべき未解決のリ
ードの待ち行列を指し示す。この待ち行列の各要素２２
１３は、それが対応するｔｒｅａｄメッセージからのｒ
ｔａｇ、ｒｆｉｄおよびｒｃｎｔを持つ。ＫＢＤＣ１９
２９は、キーボードから読み出されるべき最後の文字を
収容し、ｈｏｌｄ２２１１は、ウィンドウ１９０３（ｉ
）が保持モードかどうかを示すフラグである。 【０１５８】保持モードは、ｔｒｅａｄメッセージに応
じてデータを送るために使用されるので、好ましい実施
例においてｔｒｅａｄメッセージが処理される様子を最
初に説明する。好ましい実施例において、Ｉ／Ｏ関数２
０１９が、ｒｃｏｎｓまたはｃｏｎｓに対するリードを
指定するｔｒｅａｄメッセージを受信すると、Ｉ／Ｏ関
数２０１９は、ｑｉｄ３２３を用いて、ｒｃｏｎｓまた
はｃｏｎｓが入っているファイル木構造１５０１に対す
るスロットを確認したうえで、そのスロットに対応する
ウィンドウ構造体１９０３の所在を特定する。次に、図
２３の流れ図２３３３で示したように、ｔｒｅａｄメッ
セージからのｔａｇをウィンドウ構造体１９０３（ｋ）
のｒｔａｇ２２０５に、同じくそのメッセージからのｆ
ｉｄをｒｆｉｄ２２０７に、計数をｒｃｎｔ２２０９に
、それぞれ書き込む（２３３５）。ここで、Ｉ／Ｏ関数
２０１９が、スケジュラを呼び出すと、これが、タスク
２００８、２００５、２００９または２０１５のうち、
タスクの待ち行列において次に実行するべきものを実行
させる（２３３７）。 【０１５９】端末制御２０１５（ｋ）が、次に走ると、
流れ図２３１３に示した処理を行う。ｒｆｉｄ２２０７
は、０に等しくないので（２３２５）、新たなｔｒｅａ
ｄメッセージを受信する。結果的に、新たなｒｑｅ２２
１３を生成し（２３１７）、ｒｔａｇ２２０５、ｒｆｉ
ｄ２２０７、およびｒｃｎｔ２２０９からのフィールド
を０に設定し、新たなｒｑｅ２２１３を待ち行列の最後
に置く。ｃｏｎｓ　ｒｅａｄ　ｉｎｆｏ１９１９に示さ
れたリード処理に対するリード・キューにおけるエント
リを作ると、端末制御２０１５（ｋ）は、次に、リード
・キューが空かどうかを判断し、空ならば、待ち行列の
最初のエントリ２２１３を処理する（２３２５）。流れ
図２３２３に示したように、エントリを処理する要領は
、ウィンドウ１９０３（ｋ）が保持モードにあることを
ｈｏｌｄ２２１１が示しているかどうかに依存する。ウ
ィンドウ１９０３（ｋ）が保持モードにあることをｈｏ
ｌｄ２２１１が示している場合、リード処理において送
られた文字数をエントリ２２１３におけるｒｃｎｔの最
小値に設定し、テキスト１９１５の最後とｑｈ１９１４
によって現在印が付けられている位置との間の文字、即
ち、ｑｈ１９１４によって印が付けられている位置とテ
キスト１９１５の最後との間の行終端文字の数は単に無
視する。 そのうえで、エントリ２２１３からのｔａｇおよびｆｉ
ｄ、および文字が入ったｒｒｅａｄメッセージをウィン
ドウ１９０３（ｋ）が属するプロセスに送る。最後に、
最後に送られた文字に続くテキスト１９１５を示すよう
にｑｈを更新し、要求待ち行列の次の要素を示すように
ＲＱＰＴＲ１９２５を更新する。 【０１６０】ｈｏｌｄ２２１１が、ウィンドウ１９０３
（ｋ）が保持モードでないことを示す場合、制御はブロ
ック２３２６に戻る。ここで、ｎをｒｃｎｔの最小値に
設定すると、次の改行からｑｈ１９１４によって区別さ
れる位置までの文字の数、即ちｎにより、ｑｈから次の
改行文字までのテキスト１９１５にある文字のみの数が
指定される。 これらが、このとき、ブロック２３２９において送られ
る文字である。そして、ｑｈ１９１４を、次の改行文字
に続く文字を示すように更新する。 【０１６１】実施例においては、エスケープ・キーを叩
いて保持モードに入り、再びエスケープ・キーを叩くこ
とによって出る。このように、エスケープ・キーは、保
持モードと行終端子により行が送られるモード（以降、
非保持モードと称する）との間でトグル・スイッチとし
て作用する。流れ図２３０１は、エスケープ・キーに応
じてｈｏｌｄフィールド２２１１がどのように設定・解
除されるかを示す。前記のように、キーボード従プロセ
ス１６０５は、文字を受信すると、ウィンドウ・サービ
ス１４０５のスロット０のファイルｒｃｏｎｓへのライ
トを行う。このライトの結果、ｔｗｒｉｔｅメッセージ
が主プロセス１６１３によって受信される。Ｉ／Ｏ関数
２０１９が、スロット０のｒｃｏｎｓへのｔｗｒｉｔｅ
メッセージの処理を行うべく、ＫＢＤＣ２００４に文字
を置き、キーボード制御タスク２００９を予定する。キ
ーボード制御２００９は、ＫＢＤＣ２００４の内容を現
在のウィンドウ２０１３のＫＥＹＢＤＣ１９２９に書き
込み、現在のウィンドウ２０１３に対応する端末制御２
０１５を実行するべきタスクの待ち行列に配置した後、
スケジュラを呼び出す。少し時間をおいて、ウィンドウ
制御タスク２００５が走る；これが走ると、そのウィン
ドウ構造体１９０３にあるＫＥＹＢＤＣ１９２９を調べ
るコードを実行する。このコードに対する流れ図を図２
３の２３０１に示す。ブロック２３０３において、ＫＥ
ＹＢＤＣ１９２９からＫＢＤＣ１９２９を取り出す。判
断ブロック２３０５において、それを検査し、それがエ
スケープ文字ならば、ｈｏｌｄ２２１１を反転し（２３
０７）、ｈｏｌｄ２２１１の新たな値によって要求され
るとおりにカーソルを設定し（２３０９）、さらに新た
な値の要求どおりに画面の境界線を設定する（２３１１
）。実施例では、流れ図２３０１、２３１３、および２
３１４が、この順に端末制御２０１５によって実行され
る。こられの流れ図の実行後、端末制御２０１５は、エ
スケープ・キーの入力結果がＧｎｏｔ７１１の利用者に
直ちに見えるように、ウィンドウ２０１３を再描画する
。 【０１６２】ウィンドウ・サービス１４０５の好ましい
実施例により、クライアント・プロセス１６１５に対し
、そのプロセス１６１５に対応するウィンドウ構造体１
９０３におけるｈｏｌｄ２２１１を設定する方法が与え
られる。これを行うために、クライアント・プロセス１
６１５は、保持ファイル１５０７に対しクローズ・シス
テム・コールを実行する。クローズ・システム・コール
の結果、ｔｃｌｕｎｋメッセージが発生する。Ｉ／Ｏ関
数２０１９は、このｔｃｌｕｎｋメッセージに応じて、
対応するウィンドウ構造体１９０３のｈｏｌｄ２２１１
を設定する。また、実施例により、リードまたはライト
処理が無意味であるようなファイルに対し、それらの処
理がどのように扱われるかの例も提供される。即ち、Ｉ
／Ｏ関数２０１９は、ｈｏｌｄ１５０７を指定するｔｒ
ｅａｄメッセージを受信すると、返されるデータの長さ
が０であるようなｒｒｅａｄメッセージを返す。同様に
、Ｉ／Ｏ関数２０１９は、前記のファイルに対するｔｗ
ｒｉｔｅメッセージを受信すると、書き込まれるデータ
の長さが０であるようなｒｗｒｉｔｅメッセージを返す
。 【０１６３】ＣＰＵコマンドの実施：図２４〜２６図７
において、第９案のオペレーティング・システムは、Ｇ
ｎｏｔ端末７１１の他に高性能ＣＰＵ７０３およびファ
イル・サーバ７０５を含む分散型システム７０１におい
て実施されている。Ｇｎｏｔ端末７１１内部のプロセッ
サ上では如何なるプログラムを実行してもよいが、Ｇｎ
ｏｔプロセッサは、エディタまたはデバッガなどの対話
型プログラムを実行させるように使用し、高性能ＣＰＵ
７０３は、コンパイラまたはデータ・ベース・システム
などの処理集約型のプログラムの実行に使用する方が概
して効率的である。そのために、シェルを走らせている
Ｇｎｏｔ端末７１１の利用者は、ＣＰＵコマンドを使用
する。 【０１６４】ＣＰＵコマンドは、オプションの引数とし
てＣＰＵ７０３の名前を取る。引数が与えられない場合
は、デフォルトのＣＰＵ７０３が選ばれる。タイプする
かマウスによって選択することによって、ＣＰＵコマン
ドが入力されると、そのＣＰＵコマンドが入力されたウ
ィンドウが、ＣＰＵコマンドにおいて選択されたＣＰＵ
７０３で走っているプロセス１０２に対するウィンドウ
となる。プロセス１０２は、シェル・プログラムを実行
しているので、利用者は、そのＣＰＵ７０３において、
単にプログラム名をシェルに指定するだけで、他のプロ
グラムを実行することができる。ＣＰＵコマンドが実施
される様式の重要な意義は、ＣＰＵ７０３上を走行中の
プロセス１０２が、Ｇｎｏｔ７１１上のＣＰＵコマンド
を実行したプロセス１０２の名前空間１１５とほぼ同じ
名前空間１１５を有する点にある。所与のパス名は、Ｇ
ｎｏｔ７１１上を走っているプロセス１０２においてそ
うであるように、ＣＰＵ７０３上を走っているプロセス
１０２における同じファイルへと分析される。異なるの
は、位置の変更によって必要になるものだけである。例
えば、プロセス・サービスにおけるファイルは、Ｇｎｏ
ｔ７１１上の情報ではなく、ＣＰＵ７０３上の情報を含
む。 【０１６５】図２４に、ＣＰＵコマンドの実行の前と後
におけるシステム７０１の構成要素の間の関係の概略を
示す。２４０１と記した図の部分は、実行前の関係を示
す。ＣＰＵ２４０３（ａ）（これは、Ｇｎｏｔ７１１の
ＣＰＵでもよい）は、ユーザ・プロセス２４０５（ａ）
を走らせている。ファイル・システム１０９（ａ）によ
って、ユーザ・プロセス２４０５（ａ）は、ネットワー
ク７１３、７１５および７０９からなるネットワーク２
４０９を介して、ファイル・サービス７０５の１つであ
るファイル・サービス２４１１のファイルに対し、読み
書きを行っている。また、ユーザ・プロセス２４０５（
ａ）は、ファイル・システム１０９（ａ）を用いて、ウ
ィンドウ・サービス１４０５によって与えられるファイ
ルに対する処理を行っていて、これによって、ディスプ
レイ、キーボード、およびマウス２４０７（ａ）（この
場合、Ｇｎｏｔ７１１のディスプレイ、キーボード、お
よびマウス）を制御している。ＣＰＵ７０３の１つであ
るＣＰＵ２４０３（ｂ）は、ユーザ・プロセス２４０５
（ａ）とシステムの他の構成要素との間の相互作用に関
するものは何も持っていない。 【０１６６】ユーザ・プロセス２４０５（ａ）は、ＣＰ
Ｕコマンドを受信する時点で、シェル・プログラムを走
らせている。このＣＰＵコマンドに応じて、シェル・プ
ログラムは、名前空間も含めてユーザ・プロセス２４０
５（ａ）と同じ環境を有する子プロセスを生成し、他の
プロセスが終了するまで、それ自体停止する。さらに詳
細に後述するように、子プロセスは、ＣＰＵサービス（
ＣＰＵＳ）２４１３を設定する。ＣＰＵサービス２４１
３が、メッセージをプロセッサ２４０３（ｂ）に送ると
、結果として、プロセッサ２４０３（ｂ）にプロセス２
４０５（ｂ）が生成される。 このように、ＣＰＵコマンドの実行後、ユーザ・プロセ
ス２４０５（ａ）は、ＣＰＵ２４０３（ａ）での走行を
止めており、ユーザ・プロセス２４０５（ｂ）が、プロ
セッサ２４０３（ｂ）上で走っている。ユーザ・プロセ
ス２４０５（ｂ）は、ファイル・サービス１０９（ｂ）
によって、ファイルを読み書きしている。ユーザ・プロ
セス２４０５（ｂ）は、ユーザ・プロセス２４０５（ａ
）が持つものとほぼ同じ名前空間１１５を有するので、
読み書きされているファイルは、ファイル・サービス２
４１１によって与えられるファイルおよびＣＰＵ２４０
３（ａ）上で実行したサービス１２３によって与えられ
るファイルである。勿論、これらのファイルには、ウィ
ンドウ・サービス１４０５によって与えられるファイル
も含まれる。ＣＰＵ２４０３（ａ）上に配置されたサー
ビス１２３によって与えられるファイルに対する処理は
、ＣＰＵサービス２４１３によって扱われる。ユーザ・
プロセス２４０５（ｂ）が、ＣＰＵ２４０３（ａ）上の
サービスによって与えられるファイルに対する処理を指
定すると、ファイル・システム１０９（ｂ）により、ネ
ットワーク２４０９を介してＣＰＵサービス２４１３に
行く往信メッセージへと変換される。ここで、ＣＰＵサ
ービス２４１３は、ＣＰＵ２４０３（ａ）においてその
ファイルに対し往信メッセージで指定された処理をファ
イル・システム１０９（ａ）を用いて実行し、その結果
を返信メッセージによって返す。従って、ユーザ・プロ
セス２４０５（ｂ）の観点からすれば、ＣＰＵサービス
２４１３は、ユーザ・プロセス２４０５（ａ）の名前空
間１１５からユーザ・プロセス２４０５（ｂ）にファイ
ルを与えるサービスである。 【０１６７】ＣＰＵサービス２４１３の実施：図２５お
よび２６ 図２４１３に、ＣＰＵサービス２４１３の好ましい実施
例の概要を示す。ウィンドウ・サービス１４０５に加え
、ＣＰＵサービス２４１３により、第９案のサービス１
２３の簡潔性、柔軟性および能力が例示される。ＣＰＵ
サービス２４１３は、多数の成分プロセス１０２を有す
る。成分プロセスの名前空間１１５には、ユーザ・プロ
セス２４０５の名前空間１１５のコピーも含まれる。通
信プロセスは、ファイル・システム１０９（ｂ）からＣ
ＰＵパイプ２５０１を介して往信メッセージを受信して
、そのメッセージをサービス・パイプ（ＳＥＲＶＰ）２
５０５に書き込む。マルチプレクサ・プロセス（ＭＰＸ
）２５０７は、サービス・パイプ２５０５を読み、往信
メッセージに応じて、ＣＰＵサービスのファイル・シス
テム２５２３にあるファイルに対して処理を行う。ファ
イル・システム２５２３には、ユーザ・プロセス２４０
５（ｂ）がプロセッサ２４０３（ｂ）に置かれたサービ
ス１２３において開いた各ファイル２５１３に対応する
サービス・ファイル２５２１がある。処理の結果発生す
る返信メッセージは、ＣＰＵパイプ２５０１を介してフ
ァイル・システム１０９（ｂ）に返される。 【０１６８】オープン・ファイル２５１３へのファイル
・アクセス処理は、オープン・ファイル・プロセス２５
１１によって行われる。各オープン・ファイル２５１３
に対しオープン・ファイル・プロセス２５１１がある；
オープン・ファイル・プロセス２５１１は、それがその
ファイルに関するファイル・アクセス往信メッセージを
マルチプレクサ・プロセス２５０７から受信する手段で
あるような別個のパイプ２５０９を有し、さらに各プロ
セス２５１１は、サービス・パイプ２５０５に接続され
ている。各プロセス２５１１は、さらにそのデータの一
部として、そのオープン・ファイル２５１３に対するフ
ァイル記述子２５１７を有する。マルチプレクサ２５０
７からのファイル・アクセス往信メッセージに応じて、
ファイル記述子２５１７を用いて、そのオープン・ファ
イル２５１３に対するアクセス処理を行った後、プロセ
ス２５１１は、往信メッセージの結果をオープン・ファ
イル・プロセス２５１１からの返信メッセージとして、
サービス・パイプ２５０５に書き込む。マルチプレクサ
・プロセス２５０７は、その往信メッセージに応じて、
単にそれをＣＰＵパイプ２５０１に書き込む。さらに詳
細に後述するように、その処理を実行するために各プロ
セス２５１１および２５０７によって必要とされる情報
は、プロセス２５１１の各々に対するサービス・データ
構造体（ＳＲＶＤ）２５１９およびマルチプレクサ・プ
ロセス２５２５に対するサービス・データ構造体２５１
５に収容される。 【０１６９】図２６に、サービス・データ構造体２６２
３、およびＣＰＵサービス・ファイル・システム２５２
３におけるファイルを表すのに使用されるデータ構造体
を詳細に示す。まず、サービス・データ構造体２６２３
であるが、フィールド２６２５は、サービス・データ構
造体２６２３が属するプロセスがファイル処理を実行す
るために用いるプロシージャへのポインタから成る。Ｍ
ＰＸＳＲＶデータ２５２５の場合、サービス・ファイル
要求の各々にプロシージャがある。リードおよびライト
以外のすべての要求に対するプロシージャは、ファイル
・システム２５２３に対する処理を行う。リードおよび
ライトに対するプロシージャは、ファイルのオープン・
ファイル・プロセス２５１１に対するパイプ２５０９に
ライト処理を行うことによって、リードまたはライトさ
れているファイル２５１３に対応するオープン・ファイ
ル・プロセス２５１１に処理を渡す。オープン・ファイ
ルＳＲＶデータ２５１９の場合、リードおよびライト処
理に対するプロシージャしかなく、これらのプロシージ
ャは、単に、オープン・ファイル・プロセス２５１１に
対するＦＤ２５１７によって指定されたファイルに適切
な処理を行い、応答として受信した返信メッセージをサ
ービス・パイプ２５０５に書き込むだけである。 【０１７０】ＳＲＶＤ２６２３のその他の内容は、次の
とおりである。ＲＦＤ２６２７：ＳＲＶＤ２６２３が属
するプロセスがメッセージを読むために使用するファイ
ル記述子。 ＷＦＤ２６２９：メッセージを書くために使用されるフ
ァイル記述子。ＤＳＩＺＥ２６３１：ＤＡＴＡ２６３７
の大きさ。ｔｈｄｒ２６３３：往信メッセージがＲＦＤ
２６２７に基づきプロセスによって読まれたときの往信
メッセージのヘッダを収容する。ｒｈｄｒ２６３３：返
信メッセージがＷＦＤ２６２９に基づいてプロセスによ
って書かれたときの返信メッセージのヘッダを収容する
。ＤＡＴＡ２６３７：往信メッセージまたは返信メッセ
ージのデータを収容する。 【０１７１】ＭＰＸ　ＳＲＶＤ２５１５においては、Ｗ
ＦＤ２６２９は、ＭＰＸ２５０７によって読まれるメッ
セージが書き込まれる先のサービス・パイプ２５０５に
おけるファイルのファイル記述子であり（即ち、ＭＰＸ
２５０７はメッセージをそれ自体に書く）、ＷＦＤ２６
２９は無効である。ＯＦ　ＳＲＶＤ２５２９においては
、ＲＦＤ２６２７は、オープン・ファイル・プロセス２
５１１がメッセージを読む読出し元のパイプ２５０９に
おけるファイルのファイル記述子であり、ＷＦＤ２６２
９は、オープン・ファイル・プロセス２５１１がメッセ
ージを書き込む先のサービス・パイプ２５０５における
ファイルのファイル記述子である。 【０１７２】続いて、ＣＰＵサービス・ファイル・シス
テム２５２３に付いてであるが、このファイル・システ
ムは、図２６の２５２３に示したデータ構造体を用いて
実施される。ＣＰＵサービス２４１３によって与えられ
る各ＣＰＵサービス・ファイル２５２１（ｉ）は、ＣＰ
Ｕ２４０３（ａ）上で実行中のサービスによってプロセ
ッサ２４０３（ｂ）上で動作中のユーザ・プロセス２４
０５（ｂ）に与えられるファイル２５１３（ｉ）に対応
する。各ＣＰＵサービス・ファイル２５２１（ｉ）は、
ファイル・ポインタ配列（ＦＰＡ）２６０３内にエント
リを有する。各エントリ２６０５（ｉ）は、ファイル２
５１３（ｉ）に関する往信メッセージ要求処理において
ファイル・システム１０９によって与えられるｆｉｄ３
３１によってインデックスが与えられる。このエントリ
におけるフィールドは、次のとおりである。ＦＰ２６０
７：ファイル・エントリ２６１５へのポインタであり、
エントリ２６１５は、サービス・ファイル２５２１に対
応するオープン・ファイル２５１３（ｉ）に関する情報
からなる。ＦＤ２６０９：オープン・ファイル２５１３
（ｉ）のファイル記述子。ＯＦＰＰＩＤ２６１１：オー
プン・ファイル２５１３（ｉ）およびサービス・ファイ
ル２５２１（ｉ）に対応するオープン・ファイル・プロ
セス２５１１（ｉ）に対するプロセス識別子。最後に、
オープン・ファイル・プロセス・パイプ（ＯＦＰＰ）２
６１３：パイプ２５０９（ｉ）に対するファイル記述子
の配列。ファイル・エントリ２６１５は、オープン・フ
ァイル２５１３（ｉ）に関する情報を収容する。この情
報は、ファイル２５１３（ｉ）の所在を特定するファイ
ル・システム１０９からのｗａｌｋ要求の過程で得られ
る。ＦＮＡＭＥＰ２６１７は、ファイル２５１３（ｉ）
のパス名である文字列ＦＮＡＭＥ２６９１へのポインタ
である。ＱＩＤ３２３、ＤＥＶ３１５、およびＴＹＰＥ
３１３は、ファイル２５１３（ｉ）に対するチャネル３
０１からの対応する値である。ＲＥＦ２６２１は、ファ
イル・エントリ２６１５が再利用可能かどうかを示す参
照カウンタである。実施例において、ファイル・ポイン
タ配列２６０３、およびファイル・エントリ２６１５の
配列は、ＣＰＵサービス２４１３が処理を開始したとき
に生成される。 【０１７３】ＣＰＵサービス２４１３の動作ＣＰＵサー
ビス２４１３の処理の例を、ａｔｔａｃｈ、ｗａｌｋ、
ｏｐｅｎ、およびｃｌｕｎｋの各要求によって与えられ
る。ａｔｔａｃｈ要求により、サービス１２３によって
与えられるファイル木構造が、そのａｔｔａｃｈ要求を
しているプロセス１０２に利用できるようになる。ａｔ
ｔａｃｈ要求に対する往信メッセージには、アタッチさ
れているサービス１２３のルートに対するｆｉｄ３３１
が含まれる。ａｔｔａｃｈが成功ならば、返信メッセー
ジには、そのルートに対するｑｉｄ３２３およびｆｉｄ
３３１が含まれる。ＣＰＵサービス２４１３の場合、こ
のサービスによって与えられるファイル木構造は、ユー
ザ・プロセス２４０５（ａ）に属するファイル木構造で
ある。ＭＰＸプロセス２５０７は、往信メッセージを受
信すると、ＭＰＸプロセス２５０７のＭＰＸ　ＳＲＶＤ
２５１５において指定されるａｔｔａｃｈ関数を呼び出
す。この関数は、ｆｉｄ３３１に対応するＦＰＡＣＥ２
６０３を生成する。ＦＰＡＣＥ２６０３において、フィ
ールド２６０９、２６１１、および２６１３は、すべて
、空値を有する。次に、ａｔｔａｃｈ関数が、ルート「
／」に関するｓｔａｔ要求をすると、これにより、ユー
ザ・プロセス２４０５の名前空間１１５のｑｉｄ３２３
が返される。ここで、この関数は、ファイル・エントリ
２６１５を生成し、「／」をファイル名２６１９に、ｑ
ｉｄをｑｉｄ３２３にそれぞれ配置し、参照カウントを
１に設定する。その後、ＳＲＶＤ２５２５のｔｈｄｒ２
６３３にあるｑｉｄ３２３をルートのｑｉｄ３２３に設
定する。最後に、関数「ｓｒｖｅｐｌｙ」を呼び出すと
、これが、ｑｉｄが入った返信メッセージを生成して、
これをサービス・パイプ２５０５に書き込む。ＭＰＸプ
ロセス２５０７は、この返信メッセージを受信すると、
それをｃｐｕパイプ２５０１に書く。 【０１７４】ｗａｌｋ要求の往信メッセージには、ディ
レクトリに対するｑｉｄ３２３に関係付けられたｆｉｄ
３３１およびそのディレクトリ内のファイルの名前が含
まれる。ｗａｌｋが、成功した場合、ｆｉｄ３３１は、
提示されたファイルに関係付けられ、さらに提案された
ファイルに対するｑｉｄ３２３が、ｆｉｄ３３１と共に
返信メッセージで返される。ＭＰＸプロセス２５０７は
、ｗａｌｋ往信メッセージを受信すると、ＳＲＶＤ２５
１５において指定されるｗａｌｋ関数を呼び出す。ｗａ
ｌｋ関数は、ｆｉｄ３１１に対応するＦＰＡＥ２６０５
の所在を特定し、さらにＦＰＡＥ２６０５のファイル・
エントリ２６１５の所在を特定する。次に、往信メッセ
ージにおける名前によって指定されたファイルのパス名
を生成するために、その指定されたファイルの名前をＦ
ＮＡＭＥ２６１９に入っているパス名に追加する。その
うえで、ｓｔａｔ要求を行って、そのパス名で指定され
るファイルの状態情報を得る。次に、ＲＥＦ２６２１が
実行される。ＲＥＦ２６２１が、値１を有する場合、提
示されたファイルに対して、ファイル・エントリ２６１
５を使用することができる。この場合、ｓｔａｔ要求に
よって獲得したｑｉｄ、ｄｅｖ、およびｔｙｐｅの値が
、ファイル・エントリ２６１５のフィールド３２３、３
１５および３１３に書き込まれ、ＦＮＡＭＥ２６１９が
、そのファイルのパス名に設定され、さらにＭＰＸ　Ｓ
ＲＶＤ２５１５のｔｈｄｒ２６３３における３２３が、
そのファイルの対するｑｉｄに設定される。ＲＥＦ２６
２１が、１を越える値を有する場合、新たなファイル・
エントリ２６１５が割り当てられ、そのフィールドおよ
びｔｈｄｒ２６３３が、前記のように設定され、さらに
ＦＰ２６０７が、新たなファイル・エントリ２６１５を
示すように設定される。そのうえで、返信メッセージが
、ｆｉｄ３３１およびｑｉｄ３２３と共に返される。 【０１７５】ｏｐｅｎ要求の往信メッセージには、開か
れるファイルのｆｉｄ３３１および開かれたファイルの
モードを示す値が含まれる。返信メッセージには、開か
れたファイルのｆｉｄ３３１およびｑｉｄ３２３が含ま
れる。ｏｐｅｎ関数は、ｏｐｅｎ往信メッセージに応じ
てＭＰＸプロセス２５０７によって実行され、ｆｉｄ３
３１を用いて適切なファイル・ポインタ配列エントリ（
ＦＰＡＥ）２６０５の所在を特定し、ＦＰＡＥ２６０５
に対するファイル・エントリ２６１５の所在を特定し、
さらにＦＮＡＭＥ２６１９にあるパス名およびモードの
値を用いてｏｐｅｎシステム・コールを行う。このコー
ルは、そのファイルのファイル記述子を返す。次に、そ
のオープン・ファイルに対しパイプ２５０９が生成され
る。そのオープン・ファイルのファイル記述子が、ＦＰ
ＡＥ２６０５のＦＤフィールド２６０９に置かれ、さら
にパイプ２５０９に対するファイル記述子が、オープン
・ファイル・プロセス・パイプ（ＯＦＰＰ）２６１３に
置かれる。次に、開かれたファイルに対応するオープン
・ファイル・プロセス２５１１が、生成され、さらにそ
のＳＥＲＶＤ２５１９構造体が、オープン・ファイル・
プロセスがパイプ２５０９から読み出し、サービス・パ
イプ２５０５に書き込むように、設定される。オープン
・ファイル・プロセスのプロセス識別子が、オープン・
ファイル・プロセスｐｉｄフィールド（ＯＦＰＰＩＤ）
２６１１に置かれる。このうえで、ｔｈｄｒ２６３３の
ｑｉｄフィールドが、ファイル・エントリ２６１５から
設定され、そのｆｉｄおよびｑｉｄが、返信メッセージ
に入れられて返される。 【０１７６】ｃｌｕｎｋ要求により、サービス１２３は
、ｆｉｄ３３１とｑｉｄ３２３との間の関係付けを止め
るように要求される。この要求の往信メッセージには、
ｆｉｄ３３１が含まれる。返信メッセージは、単にその
ｆｉｄを返す。ｃｌｕｎｋ関数は、マルチプレクサ・プ
ロセスによって実行され、ｆｉｄ３３１を用いて、適切
なＦＰＡＥ２６０５の所在を特定する。そのエントリを
見つけると、フィールドＯＦＰＰＩＤ２６１１において
指定されるオープン・ファイル・プロセス２５１１を終
了させ、オープン・ファイル・プロセス２５１１が読み
出していたパイプ２５０９にあるファイルをクローズし
、フィールドＦＤ２６０９にあるファイル記述子によっ
て指定されるオープン・ファイルをクローズし、さらに
フィールド２６０９、２６１１および２６１３を、その
ファイルが使用されていないことを示すように設定する
。次に、ファイル・エントリ２６１５のＲＥＦ２６２１
をデクリメントし、デクリメントされたフィールドが値
０を有するならば、ＦＮＡＭＥ２６１９を解放し、さら
にＦＰＡＥ２６０５のファイル・ポインタ２６０７を０
に設定する。最後に、ｆｉｄ３３１と共に返信メッセー
ジを返す。 【０１７７】ＣＰＵサービス２４１３とユーザ・プロセ
ス２４０５（ｂ）との接続 ユーザ・プロセス２４０５（ａ）が、シェル・コマンド
を実行すると、そのユーザ・プロセス２４０５（ａ）と
同じ名前空間を有する子プロセス１０２が生成される。 生成された子プロセス１０２は、最初に、カーネル環境
サービスによって与えられるファイル木構造にある「ｃ
ｐｕｄｉｒ」と称するファイルを生成し、その現在のワ
ーキング・ディレクトリ（これは、ユーザ・プロセス２
４０５（ａ）のそれである）の名前をそのファイルに書
き込む。 次に、このプロセスは、ダイヤル関数においてＣＰＵコ
マンドで指定されたＣＰＵ７０３の名前を使用する。ダ
イヤル関数は、ユーザ・プロセス２４０５（ａ）（これ
も、子プロセスを使用する）の利用者を求めてネットワ
ーク２４０９経由で指定されたＣＰＵ７０３を呼び出し
、この呼び出しの終了と同時に、指定されたＣＰＵ７０
３（図２４では、ＣＰＵ２４０３（ｂ）と示した）への
接続を与える。このうえで、サービス・パイプ２５０５
、およびＣＰＵサービス・ファイル・システム２５２３
に対するデータ構造体が、生成される。最後に、通信プ
ロセスが、生成され、かつそのネットワーク接続に対す
るファイル記述子に接続され、さらにマルチプレクサ・
プロセス２５０７が、生成され、かつサービス・パイプ
２５０５およびＣＰＵパイプ２５０１に接続される。勿
論、通信サービス２５０３は、ＣＰＵパイプ２５０１に
ついてリードを行うので、この時点で、ＣＰＵサービス
２４１３は、ユーザ・プロセス２４０５（ａ）からの入
力を待っている。 【０１７８】ＣＰＵ２４０３（ｂ）において、ネットワ
ーク２４０９への接続を傾聴し、かつネットワーク２４
０９に接続された他の実体から呼をＣＰＵ２４０３（ｂ
）が受信したときに応答するようなプロセス１０２が存
在する。そのプロセスは、子プロセス１０２を開始する
ことによって、ユーザ・プロセス２４０５（ａ）からの
呼に応答する。子プロセス１０２は、ネットワーク接続
を表すファイルのパス名を入手し、さらに引数０を付け
てｆｏｒｋｐｇｒｐを行って、新たな名前空間１１５を
得る。つぎに、子プロセス１０２は、／ｄｅｖ／ｕｓｅ
ｒがコールを行った利用者の名前を収容するように、そ
の新たな名前空間１１５を設定し、／ｓｒｖ／ｂｏｏｔ
を開いてデフォルト・ファイル・サービス２４１１のル
ートへの接続に対するファイル記述子を獲得し、さらに
「／」を「＃／」およびファイル・サービス２４１１に
よって与えられるファイル木構造のルートへと結合する
。そして、子プロセス１０２は、／ｄｅｖ／ｕｓｅｒに
あるユーザ名を用いて子プロセス１０２のワーキング・
ディレクトリを利用者のワーキング・ディレクトリとし
、標準入力、標準出力、および標準エラーを、それらが
ネットワーク接続へと接続されるように、設定する。さ
らに、結合処理をいくつか行う。その終了時には、／ｂ
ｉｎは、ＣＰＵ２４０３（ｂ）によって実行できるコー
ドを収容するディレクトリに変わり、／ｂｉｎは、シェ
ル・プログラムのコードを収容する／ｌｉｂ／ｒｃに結
合されていて、さらにカーネル・サービスは、控えのフ
ァイル木構造６０１における適切な位置に結合されてい
る。 この時点で、子プロセス１０２は、分岐してユーザ・プ
ロセス２４０５（ｂ）を生成する。このユーザ・プロセ
ス２４０５（ｂ）は、子プロセス１０２の名前空間１１
５を受け継いでいる。 【０１７９】ユーザ・プロセス２４０５（ｂ）は、ユー
ザ・プロセス２４０５（ｂ）の名前空間１１５の設定の
仕上げを行うＣＰＵサーブと称するプログラムの名前を
シェル・プログラムに与えて、これを実行する。次に、
ユーザ・プロセス２４０５（ｂ）が、ｒｅｐｌａｃｅオ
プション付きのシステム・マウント・コールを行うと、
ディレクトリ「／ｍｎｔ／ｔｅｒｍ」が、ネットワーク
接続を表すファイル記述子にマウントされる。／ｍｎｔ
／ｔｅｒｍは、キーボード、マウスおよびディスプレイ
がそれによって制御されるようなファイルに対して使用
される、ユーザ・プロセス２４０５（ｂ）の名前空間に
おけるディレクトリである。 【０１８０】マウントの結果として、このとき「／ｍｎ
ｔ／ｔｅｒｍ」には、ユーザ・プロセス２４０５（ａ）
の名前空間１１５にあるファイルが含まれる。これらの
ファイルには、ディレクトリ／ｆｄ６０９が含まれる。 このディレクトリのファイルは、値として、ユーザ・プ
ロセス２４０５（ａ）によって現在使用されているファ
イル記述子を有する。従って、ファイル／ｆｄ／０、／
ｆｄ／１、および／ｆｄ／２は、ユーザ・プロセス２４
０５（ａ）の標準入力、標準出力、および標準エラーに
対するファイル記述子を収容する。ユーザ・プロセス２
４０５（ａ）は、ウィンドウ・サービス１４０５を使用
中であり、そのウィンドウ・サービス１４０５によって
与えられるファイルｃｏｎｓを／ｄｅｖ／ｃｏｎｓに結
合しているので、標準入力、標準出力、および標準エラ
ーに対するファイル記述子は、ウィンドウ・サービス１
４０５によって与えられるファイルｃｏｎｓを指定する
。次に、ユーザ・プロセス２４０５（ｂ）は、それ自体
の標準入力、出力、およびエラーをクローズし、それに
よってファイル記述子０、１、および２を解放し、そし
て直ちに、／ｆｄ／０、／ｆｄ／１、および／ｆｄ／２
における識別子によって指定されるファイルを開く。従
って、ユーザ・プロセス２４０５（ｂ）における標準入
力、出力、およびエラーに対するリードおよびライトに
より、ユーザ・プロセス２４０５（ａ）におけるｃｏｎ
ｓ−−−代わって、端末２４０７（ａ）におけるキーボ
ードおよびディスプレイを表す−−−に対するリードお
よびライトが発生する結果となる。 【０１８１】同様に、マウントの結果として、／ｍｎｔ
／ｔｅｒｍは、ディレクトリ／ｍｎｔ／ｔｅｒｍ／ｅｎ
ｖを含み、さらに、これが、ファイル「ｃｐｕｄｉｒ」
を含むが、ファイルｃｐｕｄｉｒは、ユーザ・プロセス
２４０５（ａ）のワーキング・ディレクトリを収容する
ように、ユーザ・プロセス２４０５（ａ）によって設定
されたものである。次に、ユーザ・プロセス２４０５（
ｂ）は、／ｍｎｔ／ｔｅｒｍ／ｅｎｖ／ｃｐｕｄｉｒを
開き、それを読み、さらにディレクトリ変更コマンドを
指定してシェルを実行する。ディレクトリ変更コマンド
において、「ｃｐｕｄｉｒ」から読み出した値が、引数
として使用される。その結果、ユーザ・プロセス２４０
５（ａ）の現在のディレクトリにおいて、新たなシェル
が走り始める。次に、この新たなシェルは、利用者が定
義したスクリプトを実行する。このスクリプトは、利用
者がシェルを実行する度に走らされ、ユーザ・プロセス
２４０５（ｂ）の名前空間をさらに利用者向きに変更す
ることができる。一般に、シェル・スクリプトは、次の
内容を行うシステム結合コールの実行をもたらすシェル
・コマンド含む。 ｂｉｎｄ（”／ｍｎｔ／ｔｅｒｍ／ｍｎｔ／８．５”，
”／ｄｅｖ／”，ＡＦＴＥＲ）ｂｉｎｄ（”／ｍｎｔ／
ｔｅｒｍ／ｍｎｔ／８．５／ｃｏｎｓ”，”／ｄｅｖ／
ｃｏｎｓ”，ＲＥＰＬＡＣＥ）最初の結合コールによっ
て、８．５にあるファイル（ウィンドウ・サービス１４
０５によってユーザ・プロセス２４０５（ａ）に与えら
れるファイル）が、／ｄｅｖに結合され；ＡＦＴＥＲオ
プションが使用されているので、そのディレクトリが探
査される前に、以前に結合されていたすべてのディレク
トリが、ウィンドウ・サービス１４０５によって与えら
れるファイルを求めて探査される。２番目の結合コール
によって、ウィンドウ・サービス１４０５によって与え
られるファイルｃｏｎｓが、／ｄｅｖ／ｃｏｎｓに結合
される。／ｄｅｖ／ｃｏｎｓ自体が、以前にカーネル・
サービス＃ｃを／ｄｅｖに結合した結合処理の結果であ
る。従って、／ｄｅｖは、ウィンドウ・サービス１４０
５によって与えられるファイルｃｏｎｓが結合されてい
る先のファイルである。ＲＥＰＬＡＣＥが使用されてい
るので、パス名／ｄｅｖ／ｃｏｎｓは、以降、ウィンド
ウ・サービス１４０５によってユーザ・プロセス２４０
５（ａ）に与えられたファイルｃｏｎｓを示すことにな
る。ｃｏｎｓからのリードにより、端末２４０７（ａ）
のキーボードにおいて入力されたデータを受信するよう
になり、一方、ｃｏｎｓへのライトにより、端末２４０
７（ａ）の画面上にデータを表示するようになる。 【０１８２】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例が考えられるが、それらはいずれも本発明の技
術的範囲に包含される。 【０１８３】尚、特許請求の範囲に記載した参照番号は
、発明の容易なる理解のためで、その技術的範囲を制限
するように解釈されるべきではない。 【０１８４】 【発明の効果】以上述べたように、本発明のオペレーテ
ィング・システムによれば、各プロセスが、独立した階
層（名前空間）を持ち、かつ、プロセスどうしが、異な
るプロセッサ上で実行中でも、互いに他のプロセスの名
前空間を利用することができるので、分散型システムの
ような大規模なシステムにおいても効率的に名前を管理
することができる。
【図面の簡単な説明】
【図１】本発明のオペレーティング・システムによって
与えられるプロセスごとの名前空間の概要を示す図であ
る。
【図２】本オペレーティング・システムにおけるマウン
ト・サービスおよびプロトコル・サービスの概要を示す
図である。
【図３】チャネル・データ構造体の線図である。
【図４】オープン・ファイルを位置づけるために使用さ
れるデータ構造体の線図である。
【図５】プロトコル・サービスとの間でプロトコルの受
け渡しに使用されるデータ構造体の線図である。
【図６】ルート・サービスによって与えられるファイル
木構造およびある結合操作、およびマウント操作が行わ
れた後のファイル木構造の線図である。
【図７】本発明のオペレーティング・システムが実施さ
れる分散システムの線図である。
【図８】本発明のマウント・テーブルの線図である。
【図９】図６の第２のファイル構造に対するマウント・
テーブルの線図である。
【図１０】１０Ａおよび１０Ｂは、好ましい実施例にお
けるｎａｍｅｃ関数の流れ図である。
【図１１】１１Ａおよび１１Ｂは、好ましい実施例にお
けるｗａｌｋ関数の流れ図である。
【図１２】１２Ａおよび１２Ｂは、好ましい実施例にお
けるｍｏｕｎｔ関数の流れ図である。
【図１３】好ましい実施例においてプロトコル・サービ
スを登録するために使用されるデータ構造体の線図であ
る。
【図１４】本発明のオペレーティング・システムと共に
用いられるウィンドウ・サービスの概要を示す図である
。
【図１５】ウィンドウ・サービスによって与えられるフ
ァイル木構造の線図である。
【図１６】ウィンドウ・サービスの構造の概要を示す図
である。
【図１７】ウィンドウ・サービスにおいて実行されるｍ
ｋｓｌａｖｅ関数の流れ図である。
【図１８】ウィンドウ・サービスによって与えられるフ
ァイル木構造の実施例の線図である。
【図１９】ウィンドウサービスで利用されるウィンドウ
・データ構造体の線図である。
【図２０】ウィンドウ・サービスの一部の内部構造の線
図である。
【図２１】ウィンドウ・サービスにおいて実行されるｓ
ｐａｗｎ関数の流れ図である。
【図２２】保持モードの好ましい実施例にとって重要な
ウィンドウ・データ構造体のある部分の線図である。
【図２３】好ましい実施例において保持モードに対して
行われた処理のある部分の流れ図である。
【図２４】ＣＰＵコマンドの作用の概要を示す図である
。
【図２５】ＣＰＵサービスの内部データ構造体を示す線
図である。
【図２６】ＣＰＵサービスによって用いられるデータ構
造体を示す線図である。
【符号の説明】
１０１　　サービスのアーキテクチャ １０２　　プロセス １０３　　プロセス・グループ １１３　　ファイル・ロケータ関数 １１１　　ファイル・アクセス関数 １１５　　名前空間１１５ １１７、１２５ファイル木構造 １２３　　サービス １２７、１２９ルート・ディレクトリ・ファイル１３１
　　データ・ファイル

Claims (22)

    【特許請求の範囲】
  1. 【請求項１】　　複数の名前空間（１１５）と、前記名
    前空間の所与の１つに関連する複数のプロセス（１０２
    ）とを有することを特徴とする多重プロセス操作システ
    ム。
  2. 【請求項２】　　いずれのプロセスにも利用可能で、現
    行名前空間を有するプロセスの関連を終了させ、新たに
    形成された名前空間を有するプロセスに関連させる新名
    前空間形成手段（８２７、８０２）を更に有し、この新
    名前空間は、いずれのプロセス形成手段とは異なること
    を特徴とする請求項１のシステム。
  3. 【請求項３】　　前記プロセスに関連する名前空間内の
    いずれもの名前の結合を変更する名前空間変更手段（８
    ０１）を更に有することを特徴とする請求項１のシステ
    ム。
  4. 【請求項４】　　前記名前空間変更手段が、前記名前空
    間内の第１名前の結合を、前記第１名前を１組の名前に
    関連付けることにより、変更することを特徴とする請求
    項３のシステム。
  5. 【請求項５】　　前記名前空間変更手段が、前記名前空
    間内の第１名前の結合を前記第１名前を１組の名前に関
    連付けることにより、変更することを特徴とする請求項
    ３のシステム。
  6. 【請求項６】　　前記名前空間変更手段が、前記の第１
    名前の結合を、前記第１名前を別の組の名前に関連付け
    ることにより、変更することを特徴とする請求項４のシ
    ステム。
  7. 【請求項７】　　前記名前空間変更手段が、前記の第１
    名前を、前記別の組の名前に関連付ける場合、前記名前
    空間変更手段は、交互に、前記の組の名前を別の組の名
    前で置き換え、別の組の名前を前記の組の名前に結合す
    ることを特徴とする請求項６のシステム。
  8. 【請求項８】　　前記名前空間変更手段が、別の組の名
    前を前記の組の名前に結合する場合、前記名前空間変更
    手段が、前記の組の名前に本来存在する名前と別の組の
    名前との間の順序を指定することを特徴とする請求項６
    のシステム。
  9. 【請求項９】　　前記新名前空間変更手段が、前記プロ
    セスの現行の名前空間のコピーである新名前空間のプロ
    セスに関連させるか、空である新名前空間を有するプロ
    セスに関連させるかのいずれかが実行可能であることを
    特徴とする請求項２のシステム。
  10. 【請求項１０】　　前記プロセスの現行の名前空間の新
    名前が、前記プロセスにアクセス可能な実態を表し、前
    記プロセスにアクセス可能な実態のいずれかを形成する
    手段を有し、前記実態の１つが前記プロセスにアクセス
    可能になると、このアクセス可能性は、プロセス用の新
    名前空間の形成には影響されないことを特徴とする請求
    項２のシステム。
  11. 【請求項１１】　　複数のサービス（１２３）が、実態
    （１２５）を複数のクライアント（１０２）に提供し、
    各クライアントは、その固定されたセットから要求（１
    １９）をサービスに提供する手段（１０９）を有し、各
    サービスは、固定されたセットに属する要求に応答する
    ことを特徴とするコンピュータシステム。
  12. 【請求項１２】　　サービスにより提供される実態は、
    ファイルの形態を採り、　　前記要求は、ファイル上の
    操作要求であることを特徴とする請求項１１のコンピュ
    ータシステム。
  13. 【請求項１３】　　前記要求は、付属要求を含み、各サ
    ービスは、その付属要求を形成するクライアントに入手
    可能なサービスにより提供されるファイルの例を形成す
    ることにより、付属要求に応答する手段を有することを
    特徴とする請求項１２のコンピュータシステム。
  14. 【請求項１４】　　各クライアントは、名前の付された
    実態を配置する名前空間（１１５）を有し、各サービス
    は、ファイル名前の組を提供し、付属要求の形成に際し
    て、要求を形成するクライアントは、ファイル名前の組
    の中のファイル名前をその名前空間に組み入れることを
    特徴とする請求項１３のコンピュータシステム。
  15. 【請求項１５】　　前記要求は、ファイルを名前で配置
    するウォーク要求を含み、このウォーク要求は、クライ
    アントにより提供される名前の付されたファイルと名前
    の付されたファイルの名前用の第１識別子を有し、各サ
    ービスは、名前によりファイルを探し、そのファイルが
    発見された場合、第１識別子をサービスにより提供され
    る第２識別子と関連づけることにより、前記ウォーク要
    求に応答することを特徴とする請求項１４のコンピュー
    タシステム。
  16. 【請求項１６】　　前記要求は、第１識別子を第２識別
    子から関連を解くクランク要求を含み、このクランク要
    求は、第１識別子を有し、各サービスは、第１識別子を
    第２識別子から関連を解くことにより、前記クランク要
    求に応答することを特徴とする請求項１５のコンピュー
    タシステム。
  17. 【請求項１７】　　第１のサービスは、要求が操作シス
    テムコール（２１７、２１９）の形式でなされるカーネ
    ルサービス（２０３）であり、第２のサービスは、要求
    がメッセージ（２０５、２０７）の形式でなされるプロ
    トコールサービス（２０９）であることを特徴とする請
    求項１１ないし１６のいずれかのコンピュータシステム
    。
  18. 【請求項１８】　　前記カーネルサービスは、操作シス
    テムコール形式の第１サービスを受信し、この第１サー
    ビスを、対応するメッセージ形式の第２サービスに変換
    することを特徴とする請求項１７のコンピュータシステ
    ム。
  19. 【請求項１９】　　コンピュータシステムに採用される
    、一連のキャラクタコードからなる入力をその受信者に
    伝送する方法において、列内のキャラクタコードのある
    ものの受信が一連のキャラクタが送信されるべきキャラ
    クタコードのあるものに先行させるような第１モードで
    入力を受信するステップと、キャラクタコードのあるも
    のが無視されるような第２モードを指示する為に、入力
    を受信する実態の値を設定するステップと、第１モード
    を指示する為に、前記値が設定されるまで、キャラクタ
    コードのあるものに関係なく、入力を受信するステップ
    と、全体の受信された入力を送信するステップと、第１
    モードの操作を繰り返すステップとからなることを特徴
    とするキャラクタコード伝送方法。
  20. 【請求項２０】　　コンピュータシステムが表示手段を
    有し、前記値が第２モードを指示しない場合、第１表示
    モードに従って、表示手段に入力を表示させるステップ
    と、前記値が第２モードを指示する場合、第２表示モー
    ドに従って、表示手段に入力を表示させるステップと、
    を更に有することを特徴とする請求項１９の方法。
  21. 【請求項２１】　　コンピュータシステムがキーボード
    を有し、第２モードを指示する為、値を設定するステッ
    プが、キーボードのキーを打つことにより実行され、入
    力を受信するステップが、そのキーが再度打たれるまで
    継続することを特徴とする請求項１９ないし２０のいず
    れかの方法。
  22. 【請求項２２】　　前記値を設定するステップが、コン
    ピュータシステムで実行されるプログラムの制御下で実
    行されることを特徴とする請求項２１の方法。
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 true JPH04233654A (ja) 1992-08-21
JP2724256B2 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)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06348511A (ja) * 1993-05-21 1994-12-22 American Teleph & Telegr Co <Att> プログラム実行分割装置およびクライアント・サーバシステム
JPH08339355A (ja) * 1995-04-17 1996-12-24 At & T Ipm Corp 分散形システムでの処理タスク実行呼び出し方法及び装置
JPH10240603A (ja) * 1997-02-27 1998-09-11 Fuji Xerox Co Ltd ファイル管理装置及びファイル転送方法
JP2013257627A (ja) * 2012-06-11 2013-12-26 Bank Of Tokyo-Mitsubishi Ufj Ltd データベースサーバ
JP2020187790A (ja) * 2010-09-24 2020-11-19 フィッシャー−ローズマウント システムズ，インコーポレイテッド プロセス制御装置情報を表示する方法、並びに、装置

Families Citing this family (143)

* 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
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
EP0746816B1 (en) * 1993-08-03 2001-10-24 Sun Microsystems, Inc. Flexible multi-platform partitioning for computer applications
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
US7188352B2 (en) 1995-07-11 2007-03-06 Touchtunes Music Corporation Intelligent digital audiovisual playback system
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
ES2143556T3 (es) 1994-10-12 2000-05-16 Touchtunes Music Corp Sistema de reproduccion audiovisual digital inteligente.
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
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
US6119131A (en) * 1998-06-12 2000-09-12 Microsoft Corporation Persistent volume mount points
US6654881B2 (en) 1998-06-12 2003-11-25 Microsoft Corporation Logical volume mount manager
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
FR2781580B1 (fr) 1998-07-22 2000-09-22 Technical Maintenance Corp Circuit de commande de son pour systeme de reproduction audiovisuelle numerique intelligent
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
FR2781593B1 (fr) 1998-07-22 2001-01-12 Technical Maintenance Corp Telecommande pour systeme de reproduction audiovisuelle numerique intelligent
FR2781591B1 (fr) 1998-07-22 2000-09-22 Technical Maintenance Corp Systeme de reproduction audiovisuelle
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
US6571274B1 (en) 1998-11-05 2003-05-27 Beas Systems, Inc. Clustered enterprise Java™ in a secure distributed processing 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
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
US6684231B1 (en) * 1999-11-29 2004-01-27 Microsoft Corporation Migration of friendly volumes
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
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
KR100433678B1 (ko) * 2000-06-29 2004-05-31 주식회사 아이너스기술 이벤트 흐름 차트를 이용한 이산 이벤트 시스템의 모델링방법
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
AU2002234258A1 (en) * 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
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
US7058629B1 (en) * 2001-02-28 2006-06-06 Oracle International Corporation System and method for detecting termination of an application instance using locks
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 キヤノン株式会社 通信装置及びその制御方法
US8332895B2 (en) 2002-09-16 2012-12-11 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US9646339B2 (en) 2002-09-16 2017-05-09 Touchtunes Music Corporation Digital downloading jukebox system with central and local music servers
US11029823B2 (en) 2002-09-16 2021-06-08 Touchtunes Music Corporation Jukebox with customizable avatar
US8584175B2 (en) 2002-09-16 2013-11-12 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US8103589B2 (en) 2002-09-16 2012-01-24 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
US8151304B2 (en) 2002-09-16 2012-04-03 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US12100258B2 (en) 2002-09-16 2024-09-24 Touchtunes Music Company, Llc Digital downloading jukebox with enhanced communication features
US10373420B2 (en) 2002-09-16 2019-08-06 Touchtunes Music Corporation Digital downloading jukebox with enhanced communication features
US8346884B2 (en) 2003-01-21 2013-01-01 Nextio Inc. Method and apparatus for a shared I/O network interface controller
US7046668B2 (en) * 2003-01-21 2006-05-16 Pettey Christopher J Method and apparatus for shared I/O in a load/store fabric
US7664909B2 (en) 2003-04-18 2010-02-16 Nextio, Inc. Method and apparatus for a shared I/O serial ATA controller
US7698483B2 (en) * 2003-01-21 2010-04-13 Nextio, Inc. Switching apparatus and method for link initialization in a shared I/O environment
US7457906B2 (en) * 2003-01-21 2008-11-25 Nextio, Inc. Method and apparatus for shared I/O in a load/store fabric
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
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
US7103064B2 (en) * 2003-01-21 2006-09-05 Nextio Inc. Method and apparatus for shared I/O in a load/store fabric
US7174413B2 (en) * 2003-01-21 2007-02-06 Nextio Inc. Switching apparatus and method for providing shared I/O within a load-store fabric
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
US8032659B2 (en) * 2003-01-21 2011-10-04 Nextio Inc. Method and apparatus for a shared I/O network interface controller
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
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
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
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
US7836211B2 (en) * 2003-01-21 2010-11-16 Emulex Design And Manufacturing Corporation Shared input/output load-store architecture
US7219183B2 (en) * 2003-01-21 2007-05-15 Nextio, Inc. Switching apparatus and method for providing shared I/O within a load-store fabric
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
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 株式会社日立製作所 計算機システム
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
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
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
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
US9171419B2 (en) 2007-01-17 2015-10-27 Touchtunes Music Corporation Coin operated entertainment system
US12450978B2 (en) 2007-01-17 2025-10-21 Touchtunes Music Company Llc. Coin operated entertainment system
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
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
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
US8849435B2 (en) 2008-07-09 2014-09-30 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
US12112093B2 (en) 2009-03-18 2024-10-08 Touchtunes Music Company, Llc Entertainment server and associated social networking services
US10719149B2 (en) 2009-03-18 2020-07-21 Touchtunes Music Corporation Digital jukebox device with improved user interfaces, and associated methods
CN102449658A (zh) 2009-03-18 2012-05-09 踏途音乐公司 娱乐服务器及相关的社交网络系统
US9292166B2 (en) 2009-03-18 2016-03-22 Touchtunes Music Corporation Digital jukebox device with improved karaoke-related user interfaces, and associated methods
US10564804B2 (en) 2009-03-18 2020-02-18 Touchtunes Music Corporation Digital jukebox device with improved user interfaces, and associated methods
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
CA3034363C (en) 2010-01-26 2021-04-06 Touchtunes Music Corporation Digital jukebox device with improved user interfaces, and associated methods
US8719539B2 (en) * 2011-06-30 2014-05-06 Red Hat, Inc. Using heuristics for field types of a structure to categorize dynamic memory allocations
US8725978B2 (en) * 2011-06-30 2014-05-13 Red Hat, Inc. Using symbol information for categorization of dynamic memory allocations
US20130067346A1 (en) * 2011-09-09 2013-03-14 Microsoft Corporation Content User Experience
GB2511003B (en) 2011-09-18 2015-03-04 Touchtunes Music Corp 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
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
US9921717B2 (en) 2013-11-07 2018-03-20 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 터치튠즈 뮤직 컴퍼니, 엘엘씨 향상된 사용자 인터페이스를 가지는 디지털 주크박스 장치 및 관련 방법
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
US10254942B2 (en) 2014-07-31 2019-04-09 Microsoft Technology Licensing, Llc Adaptive sizing and positioning of application windows
US10678412B2 (en) 2014-07-31 2020-06-09 Microsoft Technology Licensing, Llc Dynamic joint dividers for application windows
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
UKUUG UNIX-THE LEGEND EVOLVES PROCEEDINGS OF THE SUMMER 1990 UKUUG CONFERENCE 1990 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06348511A (ja) * 1993-05-21 1994-12-22 American Teleph & Telegr Co <Att> プログラム実行分割装置およびクライアント・サーバシステム
JPH08339355A (ja) * 1995-04-17 1996-12-24 At & T Ipm Corp 分散形システムでの処理タスク実行呼び出し方法及び装置
JPH10240603A (ja) * 1997-02-27 1998-09-11 Fuji Xerox Co Ltd ファイル管理装置及びファイル転送方法
JP2020187790A (ja) * 2010-09-24 2020-11-19 フィッシャー−ローズマウント システムズ，インコーポレイテッド プロセス制御装置情報を表示する方法、並びに、装置
JP2013257627A (ja) * 2012-06-11 2013-12-26 Bank Of Tokyo-Mitsubishi Ufj Ltd データベースサーバ

Also Published As

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

Similar Documents

Publication Publication Date Title
JP2724256B2 (ja) コンピュータシステム
EP0605959B1 (en) Apparatus and methods for making a portion of a first name space available as a portion of a second name space
JP3439337B2 (ja) ネットワーク管理システム
US4901231A (en) Extended process for a multiprocessor system
Presotto et al. Plan 9, a distributed system
US6654741B1 (en) URL mapping methods and systems
JP4603106B2 (ja) オブジェクトの遠隔的ブラウズ方法及びシステム
PL176975B1 (pl) Sposób skutecznego buforowania zbiorów w systemie zbiorów rozproszonych
US20030093420A1 (en) Method and system for retrieving sharable information using a hierarchically dependent directory structure
JPH08339355A (ja) 分散形システムでの処理タスク実行呼び出し方法及び装置
US4849877A (en) Virtual execution of programs on a multiprocessor system
JPH07146844A (ja) 製造装置の制御および調整を行う統合オートメーション開発システムおよび方法
US20020042814A1 (en) Processing common work using flexible command strings
JPH11224196A (ja) リモート・オブジェクト・アクセス
CN113672334A (zh) 一种容器管理方法及装置
US7752225B2 (en) Replication and mapping mechanism for recreating memory durations
Chesson The network UNIX system
JP2000503430A (ja) 分散処理
CN120909587A (zh) 微前端应用操作方法、装置、设备、存储介质和程序产品
JP3489216B2 (ja) ファイルシステム
US5764909A (en) Self-configuring device connection for a data independent type computer system in a network
US6308226B1 (en) Communication method and system for objects movable in network
JPH09160847A (ja) クライアント・サーバ型分散処理システム
CN115016774A (zh) 一种idc数据中心行业动环数据采集系统
US6032176A (en) Data-independent type computer system: processing machine, data machine and man-machine interface therein

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