JPH0748177B2 - データ処理システムの構成方法 - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明は、データ処理システムの構成（configuratio
n）に関し、具体的には、このシステムの初期プログラ
ム・ロード中にオブジェクトを動的に構成するために、
オブジェクト指向データベースにおけるオブジェクトと
して、データ処理システムの物理装置及び論理デバイス
を表すことに関する。

B.従来の技術 データ処理システムがそれに接続されたデバイスを利用
するためには、オペレーティング・システムが、データ
処理システムに接続されたデバイスを知っていなければ
ならない。データ処理システムに接続されたデバイス及
び構成部品は、その構成環境と呼ばれる。既知のオペレ
ーティング・システムとして、AT＆Ｔが開発したUNIXオ
ペレーティング・システムがある。UNIXオペレーティン
グ・システムのカーネルは、カーネル内のデバイス・ド
ライバとIPL処理の間の関係が非常に静的であるように
構築されていた。IPL時に、システムは、どの物理エン
ティティがそのシステムに接続されているかを決定する
ことができたが、カーネル中でこの知識を動的に反映さ
せることはできなかった。データ処理システムのユーザ
は、どの物理デバイスがシステムに接続されているかを
知らなければならず、静的にその構成を示して、システ
ムに接続された物理デバイスの変更（追加または削除）
をカーネルが知るようにしなければならなかった。次
に、ユーザは、システム資源を利用できるようにするた
めに、カーネルを再構築しシステムを再ブートしなけれ
ばならなかった。さらに、この処理は、物理的実デバイ
スで使用される構成と同様の方式で論理エンティティ
（非実デバイス）の構成に対処することができなかっ
た。

米国特許第4649479号明細書に記載されているように、
新しいデバイスは、UNIXシステム構成を表す/etc/maste
r及び/etc/systemと呼ばれるファイル内で静的に定義さ
れていた。ユーザは、このデバイス構成を修正すると
き、カーネルにこれらの構成変更を知らせるために、シ
ステムを再IPLしなければならなかった。この方法の問
題点は、構成の動的変更が反映されないことである。さ
らに重要なことに、構成の状態を適切に反映させるため
には、ユーザはUNIXシステム構成ファイルの形式とセマ
ンティクスを理解しなければならない。

従来、構成処理はユーザにとって退屈なものであった。
物理的実デバイスを構成するために、ユーザは、機械の
電源を切ってアダプタとデバイスを追加し、機械の電源
をまた入れ、新しい物理デバイスが追加されたことをカ
ーネルに知らせるために構成ファイルを修正し、カーネ
ルが新しいデバイスと対話するための適切な情報とデバ
イス・ドライバをもつようにカーネルを再構築し、次い
でシステムを再IPLしなければならなかった。それに
は、ユーザがこうしたタスクをどう実行するかについて
具体的な知識をもっている必要がある。こうした処理手
順は、システムに接続された物理デバイスを変更するこ
とを望む非専任のユーザに要求するには複雑すぎる。さ
らに、この処理は本当の問題、すなわちエンティティ間
の複雑な相互関係を定義することに加えて、（論理エン
ティティであれ、擬似エンティティであれ、実エンティ
ティであれ）任意のエンティティをシステムに組み込む
ことを対象としていない。

C.発明が解決しようとする課題 本発明の一目的は、物理エンティティ及び論理エンティ
ティの両方を一貫した類似の方式で構成するために、IP
L処理に抽象オブジェクトを処理させることにある。

本発明の他の目的は、オブジェクトが表す対象が物理エ
ンティティであれ論理エンティティであれ、動的にオブ
ジェクトを定義し、構成し、起動し、停止することにあ
る。

本発明の他の目的は、IPL処理がシステムの動的性質を
適切に反映できるように、オブジェクト間の関係を表す
ことにある。

本発明の他の目的は、一般的な機能をデバイス特有の実
施態様及びハードウェア特有の実施態様と適切に分離す
る、階層的システムを得ることにある。

本発明の他の目的は、様々な顧客特有の環境に合わせて
その挙動が容易に調整できる、データ主導システムを提
供することにある。

本発明の他の目的は、IPL中にカーネルとデバイス・ド
ライバの動的結合／結合解除を利用して、システム構成
を表す目的でIPL及びカーネル再構築を最小にするため
の動的に構成可能なシステムを提供することである。

本発明の他の目的は、新しいデバイスが容易に追加でき
る、拡張可能なシステムを提供することにある。

本発明の他の目的は、カーネルを再ブートすることなく
デバイス・ドライバを動的にオペレーテイング・システ
ムのカーネルにロードできるデータ処理システムの構成
方法を提供することにある。

D.課題を解決するための手段 本発明によるデータ処理システムの構成方法は、オブジ
エクト指向（すなわち駆動）データベースの使用により
オブジエクトの包括的な定義を可能にし、IPL時には、
オブジエクトは、論理エンテイテイ及び物理エンテイテ
イと見做される。エンテイテイ（すなわちデバイス）が
物理的であれ、論理的であれ、エンテイテイ間の接続関
係及び従属関係を示す接続性グラフ（デバイス・グラフ
とも呼ぶ）を表わす。好ましくは、一方のエンテイテイ
が他方のエンテイテイ内に含まれていることを示す包含
グラフを表わしてもよい。

本発明の構成は次の通りである。

1.データ処理システムの構成要素である複数のデバイス
と、該データ処理システムを構成するため必要な事象の
シーケンスを定義する構成ルールとを、オブジエクト指
向データベース中に記憶されている各々に対応するオブ
ジエクト・クラスの形で表わすステツプと、 データ処理システムを動的に構成するため、定義メソツ
ド、構成メソツド、起動メソツド、停止メソツド、構成
解除メソツドなどの複数のメソツドを、オブジエクト・
データ管理プログラムの制御の下に、上記デバイスのオ
ブジエクトに関連付けるステツプと、 データ処理システムのブートに当り、上記構成ルール・
オブジエクトからの指針の下に構成管理プログラムによ
り上記メソツドを呼び出し、そのメソツド動作を、デバ
イスの属性とは無関係に、上記デバイス・オブジエクト
に関して遂行するステツプと、 より成るデータ処理システムの構成方法。

2.デバイス間の接続性及び従属性の関係を上記オブジエ
クト指向データベース中に表わしておくとステツプと、 上記接続性及び従属性の関係を調査してデータ処理シス
テムの上記デバイス・オブジエクトを構成するステツプ
と、 を含む上記請求項１に記載したデータ処理システムの構
成方法。

作用について説明する。オブジエクト・データ管理プロ
グラムは、適切なメソツドを特定のオブジエクトに関連
付けるための支援を行う。上記メソツドには、特定のオ
ブジエクトに対して特定の動作（たとえば、定義構成、
構成解除、起動、停止など）を実行するのに必要な事象
の動作またはシーケンスが含まれる。このようにして、
オブジエクト指向データベースを使用してオブジエクト
間の関係（グラフ）を表わすことにより、IPL処理は論
理エンテイテイ及び物理エンテイテイを動的に構成する
ことができる。

データ処理システムがブートされるときに、上記メソツ
ドを呼び出して特定のメソツド動作を遂行するための機
能が構成管理プログラムにより提供される。この構成管
理プログラムは、ルール・ベース方式であり、IPL時に
こうしたオブジェクトを定義し構成するのに必要な事象
のシーケンスを理解する。本発明のシステムは、マイク
ロチャンネル及びSCSIアーキテクチャを利用して、シス
テム内の各デバイスを自動的に検出する。新しい各デバ
イスは、オブジェクト指向データベースにオブジェクト
として自動的に追加され、他のオブジェクトに対する関
係が示される。これは、検出されたデバイスに基づく適
切なメソッドを構成管理プログラムが呼び出すことによ
って実施される。この技術を用いると、IPL終了時に、
カーネルは、どんなハードウェアが存在するかを自動的
に知り、ユーザの介入なしにハードウェアと直接対話す
ることができる。

どのデバイスがシステムに接続されているかを決定し、
物理デバイス及び論理デバイスをオブジェクト指向デー
タベース内のオブジェクトとみなすことにより、IPL中
にシステム内で物理エンティティ及び論理エンティティ
を自動的に構成する、IPL処理が作成される。このよう
にして、物理エンティティ及び論理エンティティと通信
するのに必要なデバイス・ドライバ（カーネル拡張）を
含むカーネルが、IPL時に動的に構築される。

E.実施例 本明細書で使用する用語を以下のように定義する。

アダプタとは、入出力バスに接続されたデバイスの簡略
な定義である。

構成管理プログラムとは、IPL中にデバイス構成を管理
するプログラムである。

コンテナとは、他のデバイスまたはコンテナを含む機器
設置場所で交換可能な部品（FRU）である。たとえば、
固有入出力（NIO）カードなどドロワーやボード（カー
ド）のような受動エンティティである。たとえば、拡張
ボックスは、複数のアダプタ・カードを入れることので
きるコンテナである。コンテナはそれ自体デバイスでは
ないが、デバイスと同様の方式で表される。コンテナ
は、その構成に関するメソッドを持つこともできる。各
実デバイスごとに、交換部品とデバイスの間の関係を決
定するため、コンテナに対する関係（包含とよぶ）が存
在する。コンテナは、実際のFRU情報のオブジェクト・
クラス名でもある。

カスタマイズとは、実際のデバイス情報のオブジェクト
・クラス名の集合である。

デバイスとは、論理回路、コネクタ、ワイヤなどの能動
型エンティティである。本明細書では、デバイスという
用語は一般的な意味で使用し、さらに他のデバイス（た
とえば、アダプタ、バスなど）に物理的に接続できる、
マルチプレクサと呼ばれるデバイス、他のデバイス（た
とえば、プリンタ、ディスク、ディスプレイなど）には
接続できない、端末デバイスと呼ばれるデバイス、擬似
デバイスと呼ばれるソフトウェア指向デバイス（たとえ
ば、HFT、pty）を指す。

デバイス構成とは、あるデバイスをシステムで既知のも
のにし使用可能にするために実行される、一連のステッ
プをいう。このステップには、構成すべきデバイスの実
際の存在を検出すること、構成データベース内でデバイ
スを定義すること、デバイス・ドライバを初期設定する
のに必要なデータ構造を構築すること、デバイス・ドラ
イバをロードし初期制定すること、デバイスを使用可能
にすることなどがある。

動的構成とは、システムにおける以下の機能をいう。す
なわち、デバイスの状態の変更を検出すること、IPL及
び走行時にデバイス・ドライバとカーネルを動的に結合
／結合解除できること、基礎ハードウェアの相互接続が
変わってもシステムを構成できること、及びIPLやカー
ネル再構築を必要とせずに走行時にデバイスを構成でき
ることである。

マルチプレクサとは、他のデバイスをさらに接続するデ
バイスである。たとえば、SCSIアダプタは、ディスク、
印刷装置、表示装置などの端末デバイスをさらに接続す
るマルチプレクサである。バスは、そのスロットでアダ
プタを接続することができる他のマルチプレクサであ
る。

事前定義とは、システムが使用可能なすべての可能な論
理デバイス及び論理デバイスを定義するオブジェクトの
集合であり、本明細書では構成のために可能なすべての
デバイスの「総体」を指す。

擬似デバイスとは、物理デバイスすなわちハードウェア
・デバイスに対抗するものとしての論理デバイスであ
る。擬似デバイスは、ソフトウェアで実施された非ハー
ドウェア・デバイスである。これらの擬似デバイスは、
多重化デバイス（たとえば、システム・コンソール）ま
たは端末（たとえば、pty、エラー）デバイスでもよ
い。ある種の擬似デバイス（たとえば、pty−擬似端末
デバイス）は、実デバイスのように動作するので、本発
明でIPL中に管理される。

端末デバイスとは、マルチプレクサではないデバイス
で、他のデバイスを物理的にそれに接続することができ
ない（たとえば、端末、プリンタなど）。

オブジエクト及び属性（アトリビユート）は、オブジエ
クト指向データベースのプログラミング分野では周知の
用語である。たとえば、オブジエクトとは、変数の形で
表わされている関係付けられたデータの集合及びそのデ
ータを操作するメソツド（プロシデユア）を含むソフト
ウエア・パケツトであり、一方、属性とは、前記変数の
値である（たとえば、第５図を参照されたい）。

米国特許出願第07/352571号明細書は、オブジェクト指
向データベースを使って構成データの知識を記憶し、複
数の構成可能定義域（ドメイン）についてそれを管理す
るシステム管理機能を記載している。本発明は、実デバ
イスと論理デバイスの両方を含むデバイスとして知られ
る構成可能定義域を構成するためのシステム及び方法を
提供するものである。本発明のシステムは、マイクロチ
ャンネル及びSCSIアーキテクチャを利用して、システム
の各デバイスを自動的に検出する。自動的にシステム内
でデバイスを検出できるマイクロチャンネル・アーキテ
クチャは、現在は放棄されている米国特許出願第07/021
391号の継続出願である米国継続特許出願第07/296387号
の明細書に記載されている。本発明の方法は、デバイス
構成可能定義域を表すオブジェクトの集合を識別する。
２つの異なる事象があると、データベースはデバイス構
成可能定義域を構成するオブジェクトの集合を表すこと
ができる。オブジェクトの集合は、IPL時にまたは１組
の走行対話型サービス中に定義される。本発明はIPL時
に発生する事象を反映するものである。

本発明のシステム及び方法は、データ処理システム内の
物理エンティティ及び論理エンティティを表すオブジェ
クトを動的に定義し、起動し、停止し、定義解除し、構
成解除する。カーネルは、動作環境がデータ処理システ
ムのエンド・ユーザに利用可能な物理エンティティ及び
論理エンティティを表すように、IPL中にシステムに接
続されたすべてのオブジェクトについての知識を動的に
供給される。このシステムのIPL処理は、物理エンティ
ティと論理エンティティを区別せず、抽象的な意味でオ
ブジェクトを扱う。

使用する構成処理は、システム構成データを、第4A図に
一緒に示したコンテナ・グラフとデバイス・グラフとい
う異なる２種のグラフに分類できることを中心とする。
第4B図は、別にデバイス・グラフを示し、第4C図は、別
にコンテナ・グラフを示す。

第4B図のデバイス・グラフ400は、実デバイス及び擬似
デバイスを相互接続する。デバイス・グラフは、物理デ
バイス間の接続性、論理デバイスと物理デバイスの間の
従属性、及び論理デバイス間の従属性を示す。実線451
は接続性を示し、破線452は従属性を示す。デバイス・
グラフは、グラフのノード（デバイス）と各ノード間の
その辺（接続名空間）451、452とを記載する構成データ
を具体的に図示する。これらのグラフで表されるデバイ
スには基本的に次の３種がある。１）バス404、SCSIア
ダプタ406、RS232アダプタ430などのマルチプレクサ・
デバイス、２）端末、ディスク428、印刷装置436などの
端末デバイス、３）高機能端末（HFT）424、PTYなどの
擬似デバイスがある。すべてのデバイスがこれらの３つ
の形式の１つに当てはまると仮定する。したがって、デ
ータをどう表すかは、部分的には全体構造にこれら３つ
の形式のデバイスが収容されるために、単純になる。基
本的な違いとして、各マルチプレクサ・デバイス404、4
06、430は、それぞれそれと通信する方法を表す手段と
してその接続名空間451で記載しなければならないが、
それ自体名前空間をもたない端末デバイス426、428は、
それが接続されている先のマルチプレクサ・デバイスに
対する関係と一緒に表す必要があるという特徴をもって
いるだけである。擬似デバイスはマルチプレクサ・デバ
イスまたは端末デバイスのどちらかの特徴を持つ。

デバイス・グラフ400（第4B図）は、いくつかのオブジ
ェクト・クラスで表される。しかし、事前定義オブジェ
クト・クラス300（第３図）及びカスタマイズ・オブジ
ェクト・クラス500（第５図）の２つの主クラスは、デ
バイス情報のすべての核として使用される。事前定義オ
ブジェクト・クラス300（第３図）は、すべての可能な
デバイス構成、それらの接続、省略時の値、及び選択の
ためのテンプレートとして使用される。カスタマイズ・
オブジェクト・クラス500（第５図）は、実際のデバイ
ス構成を表すように調整された適切な１組の事前定義オ
ブジェクトから構成される。

コンテナ・グラフ460（第4C図）は、機器設置場所での
交換のための包含情報を表す。コンテナ・グラフは、交
換可能部品の階層及びそれらの相互の関係を示す。表さ
れる関係は、１本の木ではなく、木401、411、403、405
の集合となる。デバイス・グラフの各ノードに、交換可
能部品とそれに接続されたデバイスの間の関係またはそ
の逆の関係を決定するための、コンテナ・グラフとの関
係が存在する。

コンテナ・グラフ460（第4C図）は、デバイス・グラフ
を表すのに使用されたオブジェクト・クラスと同様のオ
ブジェクト・クラスによって表される。コンテナ用の事
前定義オブジェクト・クラス300（第３図）は、次の２
つの基本的目的に使用される。１）デバイス・グラフ用
の事前定義オブジェクト・クラスと同様のすべての有効
なハードウェア構成のリポジトリ（repository）であ
る。２）コンテナ情報とデバイス情報の間のマッピング
を行なう。事前定義コンテナ・オブジェクト・クラス32
0は、コンテナ・グラフ460とデバイス・グラフ400の関
係を表す。カスタマイズ・コンテナ・オブジェクト・ク
ラス525（第５図）は多数の木として表された実際のコ
ンテナ情報に関するリポジトリとして使用される。コン
テナ・オブジェクト・クラスは、カスタマイズ構成デー
タベース内でカスタマイズ・デバイス・オブジェクトに
併合される。論理デバイスを表すオブジェクトは包含情
報をもたない。

第１図を参照すると、構成データベース15（第１図）は
デバイス構成を支援するのに必要な情報をすべて記憶す
る。構成データベースは、デバイス関連情報に加えて、
構成規則70を含む。構成規則70は、デバイス構成を実行
する際に構成管理プログラムに指針を与えるものであ
る。構成データベースは、オブジェクト・データ・管理
プログラム（ODM）20を介してアクセスされる。オブジ
ェクト・データ管理プログラム20は、常に構成情報の表
現を１組のオブジェクト・クラス300、500としてグルー
プ化する。

構成データベース15は、後で第３図及び第５図を参照し
てさらに詳しく示すように、事前定義デバイス構成情報
300及びカスタマイズ・デバイス構成情報500を含む。事
前定義情報（第３図）は、システムによって支援される
すべての可能なデバイス及びコンテナの構成データを含
む。支援されるデバイスは、構成データベース内に事前
定義デバイス・オブジェクト330を有する。

構成データベース内の情報は、オブジェクト・データ管
理プログラム内のリンク305（第３図）を介して相互に
関連づけられる。カスタマイズ情報500（第５図）は、
システム内で実際に定義または構成されたデバイスの構
成データを含む。構成データベース15を構成するオブジ
ェクト・クラスの集合はデバイス構成情報だけに限られ
ず、構成規則70、スプーラ・サブシステム及びバックエ
ンドを支援するオブジェクト、ファイル・システム−論
理ボリューム管理プログラムの構成を支援するオブジェ
クト、ネットワーク構成を支援するオブジェクト、ライ
センス・プログラム製品の構成を支援するオブジェク
ト、カーネル構成を支援するオブジェクト、診断支援オ
ブジェクトなどを含む。

事前定義オブジェクト・クラス300は、すべてのデバイ
スに対する共通情報を表す。各デバイス・オブジェクト
ごとに、定義61、構成62、起動63など各オブジェクトに
対する特定の動作を実行する１組のメソッド60がある。
これらのメソッドは、特定のオブジェクト及びそれが表
すデバイスの形式に特有である（たとえば、scsi_defin
e,scsi_config,scsi_start,scsi_stop,rs232_define,rs
232_config他）。各デバイスについて属性オブジェクト
・クラス540として表したデバイス従属情報に対する関
係505（第５図）が存在し、所与のデバイスに対する状
態オブジェクト・クラス550に対する関係505が存在し、
そしてデバイスの形式に応じてその接続名空間を定義す
る接続オブジェクト・クラス520に対する関係505が存在
する。さらに、デバイスの形式に応じて、その包含情報
を定義する包含オブジェクト・クラス525に対して関係5
25が存在することもある。デバイス・ドライバをもつ各
デバイスについては、デバイス・ドライバの特性を定義
するデバイス・ドライバ・オブジェクト・クラス560も
存在する。

第１図を再度参照して、構成管理プログラム10について
さらに説明する。構成管理プログラム10は、事前定義ク
ラス300（第３図）内で定義されているオブジェクト及
びカスタマイズ・デバイス・オブジェクト・クラス500
（第５図）内にあるオブジェクトに対して作用する。事
前定義デバイス300は、システム上で構成できる可能な
オブジェクトの「総体」を表し、カスタマイズ・デバイ
ス500は、その「総体」のうちから使用される実際の１
組のカスタマイズされたデバイスを表す。構成管理プロ
グラム10はカスタマイズ・オブジェクト500にアクセス
して、IPL時にシステム内にあった物理エンティティが
表されていることを検証する。物理エンティティが見つ
かったがカスタマイズ・オブジェクトの集合500中で反
映されていない場合、構成管理プログラム10は事前定義
デバイス・オブジェクト300にアクセスして、同じ形式
のオブジェクトを見つけ、その定義メソッド61を呼び出
す。定義メソッド61は、事前定義クラス300からオブジ
ェクト・インスタンスを定義し、それに、クラスに固有
のすべての属性を付けてカスタマイズ・クラス500内に
表わす。この物理エンティティがカスタマイズ・オブジ
ェクト・クラスの集合に定義されると、物理エンティテ
ィが定義されたことになる。カーネル及びファイル・シ
ステムに、物理エンティティが存在することを知らせな
ければならない。それには、デバイス・ドライバをカー
ネルに動的に結合し、特殊ファイルを作成する必要があ
る。構成管理プログラム10は特定のオブジェクトによっ
て表されるその特定の物理エンティティの構成メソッド
62を呼び出す。オブジェクトに対する構成メソッド62
は、特定のオブジェクトが存在することをカーネル80及
びファイル・システムに知らせるのに必要な動作を実行
する。構成メソッドはカーネルに、そのオブジェクトに
対するデバイス・ドライバをロードするよう指示する。
構成メソッド62は、（定義メソッド61）によって定義さ
れた）そのオブジェクトについてカスタマイズ・デバイ
ス・オブジェクト500に照会し、デバイス・ドライバに
送られるデバイス依存の構造または情報を作成し、メジ
ャー番号（major number）とマイナー番号（minor numb
er）を獲得するための適切な低レベル・デバイス・コマ
ンドまたはルーチンを発行し、システム・コールを発行
してデバイス・ドライバをカーネルに結合し、デバイス
依存情報を用いてそれを初期設定する。デバイス・ドラ
イバ情報、特にメジャー数を用いて、デバイス・ドライ
バをデバイス・スイッチ・テーブルを介してカーネルに
結合する。構成管理プログラムは、それに接続されたデ
バイスに対する接続情報を使用する。構成管理プログラ
ムがアダプタを構成する場合、そのアダプタに他のデバ
イスが接続されていることがある。構成メソッド62は、
多重化装置のためにも、こうした接続デバイスを見つ
け、それらの定義メソッド61を呼び出すことにより、こ
うした接続デバイスがカスタマイズ・データベース500
内で定義されるようにする。したがって、構成メソッド
62は、それに接続されたオブジェクトのために他の定義
メソッド61を呼び出す。このプロセスは、接続情報をデ
ータベース内に散布し、接続グラフ400（第4B図）を確
立し維持する責任をもつ。

第１図を参照すると、構成管理プログラム10は、オブジ
ェクト・データ管理プログラム20によって管理されるオ
ブジェクト指向データベース15内のデバイス・オブジェ
クト300、500及びそれに関連するメソッド60によって主
として駆動される、小さく簡単なプログラムである。構
成管理プログラム10は、オブジェクト300、500の集合と
して表されるシステムを構成するために必要な事象の順
序を理解するという点でルール・ベース式である。さら
に、構成管理プログラム10は、（その規則から）構成順
序に関して異なるオブジェクト形式に対する従属性を知
る。構成管理プログラム10を支配する規則は、規則オブ
ジェクト・クラス70内で定義される。これらの規則は、
構成規則オブジェクト・クラス内で見つけられ、オブジ
ェクト指向データベース機能をもたらすオブジェクト・
データ管理プログラム20を使ってアクセスされる。

構成管理プログラム10は、呼び出されると、第７図の構
成規則オブジェクト・クラス70を開き、構成規則オブジ
ェクトを読み取って、何をどんな順序で構成するかを決
定する。構成規則は、その処理及び指令方針によって構
成管理プログラムに指針を与える一般的規則をもたら
す。さらに、構成規則は、他のいくつかの情報、たとえ
ばIPLの前に診断を実行するべきかどうか、どんな特殊
デバイスを構成する必要があるか、それらをいつ構成す
るか、ユーザの確認なしで自動的に資源に対する衝突を
解決するかどうか（省略時は自動的に衝突を解決する）
などの方針を含むことができる。

構成管理プログラムの構成は以下の通りである。頂点
（apex）規則は、システム上のすべてのデバイスが第4B
図に示すようなグラフ構造400の要素としてみられるこ
とを構成管理プログラムに知らせる。構成管理プログラ
ムは、指定されたデバイスを頂点にとり、グラフ構造の
底部まで走査して、グラフ内のすべての要素を構成す
る。

順序規則は以下の通りである。実デバイス用の木構造に
加えて、多くのノードのクラスタがある。各ノード形式
（type）は特定の相互関係をもつ論理デバイスのグルー
プである。ノード形式には、たとえばHFT形式（typ
e）、IF形式、TCP形式、PTY形式などがある。この規則
は、構成管理プログラムに、こうしたノード形式が何
で、それらのノード形式間の優先順序がどうであるかを
告げる。構成管理プログラムは、ノード形式をいつ構成
するかを構成管理プログラムに知らせるのに十分なカス
タマイズ情報がないとき、この規則を参照する。ノード
形式が論理デバイスに対するものであるときは、構成管
理プログラムは常に定義メソッドを実行して、そのデバ
イスに関する接続オブジェクト・クラス中で従属性を定
義する。順序規則は構成管理プログラムに、どのデバイ
スをどんな順序で初期プログラム・ロードする必要があ
るかを知らせる。すべての基本実デバイス、たとえばハ
ードディスク、フロッピー・ディスク、LED、キーボー
ドなどを構成するように構成管理プログラムに指示する
第１段順序規則がある。基本デバイスとは、システムを
立ち上げるのに必要なデバイスである。構成するとは、
こうした基本実デバイスに適切なデバイス・ドライバを
カーネルに結合するという意味である。第２段順序規則
は、構成管理プログラムに、ボリューム・グループsy
s、他のボリューム・グループHFT、TCP/IPなどを構成す
るよう指示する。この規則は、システムにあるボリュー
ム・グループ、たとえば複数の物理ディスクにあるボリ
ューム・グルーブのすべてを構成する。ボリューム・グ
ループは、物理ディスクを検査するので、論理エンティ
ティである。sysは、非基本実デバイス、たとえば印刷
装置、端末などを含む。他のボリューム・グループは、
マウス、コンソール、ライト・ペンなどを管理または制
御する論理デバイスである高機能端末を含む。これら
は、実デバイスであるが、すべてHFTと呼ばれる論理デ
バイスによって管理される。トークン・リングと呼ばれ
る物理デバイス上で走行するTCP/IPと呼ばれるネットワ
ークにも、論理デバイスが存在し得る。実デバイスが構
成されると、物理デバイスを制御する論理デバイスが構
成できる。したがって、構成管理プログラムは、順序規
則を取り上げて、異なる形式の構成可能ノードを走査す
る。次に構成管理プログラムは、構成可能デバイスのす
べてをカーネル内に動的にロードし、システムの現状を
反映するようにデータベースを更新する。

検証規則は、IPLが終了する前に診断機能を呼び出した
り、プログラム製品またはデバイスを検査する必要があ
ることを構成管理プログラムに知らせる。この規則は、
診断ルーチンと規則ルーチンのどちらを呼び出すかを構
成管理プログラムに知らせる。

併合規則は、RAMディスク上のブート・イメージをルー
ト・ファイル・システムと併合するかどうかを構成管理
プログラムに知らせる。NVRAM規則は、NVRAMからカスタ
マイズ・デバイス・オブジェクトをロードするか、それ
ともスクラッチからシステム構成を開始するかを構成管
理プログラムに知らせる。

第７図は、構成規則オブジェクト70を示す。オブジェク
トの構成規則集合は、規則形式（type）71、規則値72、
及びIPL段階73を含む。順序規則形式74では、IPLの第１
段階で、構成管理プログラムが、システム及び論理ボリ
ューム管理プログラムを構成する。システムは物理エン
ティティであり、論理ボリューム管理プログラムは論理
エンティティである。IPLの第１段階で、構成管理プロ
グラムはまた、NVRAMロード規則形式75に応じて、前のI
PLからの任意の構成情報をNVRAMからメモリにロードす
るものと仮定されている。併合規則形式76は、IPLの第
１段階の後で、任意の新しい情報が古い構成に併合され
ることを記述する。この第１段階は、ページャー（page
r）を実オペレーティング・システムに導入するために
最小数のオブジェクトを構成する。第２段階は、他のす
べてのカスタマイズ・オブジェクトを導入して構成す
る。したがって、IPLの第２段階ではより多くのエンテ
ィティ72が順序規則77中にリストされる。それには、ル
ート・ボリューム・グループ、すなわちディスクを構成
すること、システムのすべての物理デバイスを構成する
こと、論理ボリューム管理プログラム、ボリューム・グ
ループの論理エンティティ、HFT、及びネットワークが
含まれる。検証規則形式78は、IPLの第２段階の終り
に、構成管理プログラムが、ソフトウェア（LPP、ライ
センス・プログラム製品）が大丈夫で、機械が診断中ず
っと良好であることを検証するように指示する。

メソッド60（第１図）は、条件に基づいて機能を実行す
る、プログラム、スクリプトまたはプロセスである。オ
ブジェクト・データ管理プログラム20は、特定の機能動
作を実行するために、この場合は構成管理プログラムか
ら要求されたときに、１つまたは複数のメソッド60が呼
び出される環境を用意する。デバイス・オブジェクト・
クラス300は、定義61、構成62、起動63、停止など定義
された多くのメソッドをもつ。各メソッド記述子ごと
に、当該の名前の機能を実行するコードがある。すなわ
ち、構成メソッドは、あるオブジェクトに対する構成処
理を実行する。それらのメソッドは、その呼出しの後に
状態、定義済み、構成済み、起動済みなどのオブジェク
トの状態を示す。

これらのメソッドは、その成功または失敗を示す０また
は−１を戻す。成功の時、メソッドは情報をstdoutバッ
ファに書き込むことができる。失敗の時、方法はエラー
条件とコードをstderrバッファに書き込んで、エラーが
生じたことを示す。たとえば、いくつかのエラー・コー
ドは、成功の場合は０であり、失敗で診断上の問題があ
る場合は１、失敗でコードの定義が失敗した場合は２、
失敗でデバイスの定義が失敗した場合は３等々である。
戻りコードがそのメソッドの各中間段から戻されたとき
に戻りコードを検査するのは、呼出しを行なったプログ
ラムの責任である。

カスタマイズ・オブジェクト・クラス500（第５図）
は、デバイスを定義し、構成し、起動するためにそのメ
ソッドを利用する。一般に、これらのメソッドは以下の
機能を提供する。

定義メソッド61は、事前定義オブジェクト・クラス300
（第３図）から適切なオブジェクトを得て、それをカス
タマイズ・オブジェクト・クラス500（第５図）に追加
する。定義メソッドの一般規則は、１）オブジェクトが
定義されていない場合は、省略時設定をオーバライドす
る入力を受け入れてオブジェクトを追加し、２）それが
定義されている場合は、その属性を変更する入力を受け
入れる。定義メソッドは、その特定のクラス及び形式の
すべてのデバイスにわたって検証処理を実行して、カス
タマイズ・デバイス550中で定義された設定との衝突が
ないことを確かめる。一般に、定義メソッドが呼び出さ
れるのは、カスタマイズ・オブジェクトが存在しないと
き、たとえば既存のシステムにとって新しいシステムま
たはデバイスが見つかったときだけである。

構成メソッド62は、カスタマイズ・オブジェクト・クラ
スからデバイス定義構造（DDS）570（第５図）を検索ま
たは構築し、デバイス・ドライバを結合して初期設定
し、カスタマイズ・オブジェクト中で構成フラグをセッ
トすることにより、特定のデバイスをオペレーティング
・システムに知らせる。構成メソッドの一部として、そ
れはハードウェア特有のデータ、すなわち通し番号を引
き出す。これらのデータは、それが存在しないまたは正
しくない場合にカスタマイズ・オブジェクト・クラス中
で更新する必要がある。接続されたデバイスについて照
会する前に、マイクロコードがデバイスにロードされ
る。さらに、構成メソッドは、その特定の構成段に対す
る適切なコードでLEDを更新する。デバイスが新しいま
たはなくなった場合、構成メソッドは、構成変更フラグ
をセットして、構成の変更を示す。マルチプレクサ・デ
バイスについては、構成メソッドは、それに接続された
デバイスがあるかどうかそのデバイスを照会し、そのデ
バイスがカスタマイズ・デバイス・オブジェクト・クラ
ス500中でまだ定義されていない場合は、接続されたデ
バイスに対して定義メソッドを呼び出す。

変更メソッドは、デバイスがカスタマイズされた後に特
定のデバイスの変更を行なう。デバイスに応じて、変更
メソッドは、ioctl、コマンドまたはメソッド（たとえ
ば、構成解除、定義、構成）を呼び出して、その機能を
実行することができる。

起動メソッドは、そのデバイスに対する関連アプリケー
ションまたは制御サブシステムへの通信を可能にし、カ
スタマイズ・オブジェクト中で機能フラグをセットす
る。

構成解除メソッドは、カーネルからのデバイス・ドライ
バのアンロードや、構成フラグを適切にセットしてその
デバイスが構成されていないことを示す等の動作を実行
する。場合によっては、それに、ファイル・システムか
らの/devエントリの除去がさらに必要となることもあ
る。このメソッドは、構成が変更されたのが見つかった
ときに診断で使用される。

他のメソッドには、停止メソッドと定義解除メソッドが
ある。停止メソッドは、関連アプリケーションまたは制
御サブシステムとの通信を不能にし、そのデバイスに対
してカスタマイズ・オブジェクト中の起動フラグをリセ
ットする。定義解除メソッドは、カスタマイズ・オブジ
ェクト・クラスからデバイスを削除する。あるデバイス
がカスタマイズ・オブジェクト・クラス500中で見つか
らない場合、それはシステムに対して定義されていな
い。

次に第6A図ないし第6F図を参照して、上記のメソッドの
より詳細な説明を行なう。

第6A図の定義メソッド61は、所与のデバイスのカスタマ
イズ・デバイス・オブジェクトを作成するために呼び出
される。デバイス・カスタマイズ処理は、事前定義デバ
イス・オブジェクトのインスタンスを生成し、事前定義
オブジェクトから関連情報を抽出し、抽出した属性と既
存のカスタマイズ・オブジェクトの間の衝突を検出／解
決し、その結果得られた情報を作成したカスタマイズ・
デバイス・オブジェクトに記憶することを含む。

定義メソッドはまた、デバイス・インスタンスに固有の
必要な情報を導き出すことも含む。この必要な情報に
は、デバイス・インスタンスの論理名（カスタマイズ・
デバイス・オブジェクトに割り当てられた名前でもあ
る）とデバイス・インスタンスの関連する接続及び位置
情報などがある。

定義メソッドが従うステップを第6A図に示す。定義メソ
ッドは、ステップ601で呼び出されると、デバイス記述
（たとえば、デバイス・クラスとデバイス・サブクラス
とデバイス形式とデバイスがどこに接続されているかの
組合せ）または論理名が渡される。ステップ602で、関
連する事前定義デバイス・オブジェクトからカストマイ
ズ・デバイス・オブジェクトを作成するために定義メソ
ッドが呼び出される場合、ステップ607で、デバイス記
述が渡される。カスタマイズ・デバイス・オブジェクト
がすでにデータベース中で作成され、カスタマイズ・デ
バイス・オブジェクト上の既存の属性を変更するために
定義メソッドが呼び出される場合は、ステップ603で、
論理名が渡される。

特定のデバイスに関連する定義メソッドは、ステップ60
8で、事前定義データベースからカスタマイズ・デバイ
ス・オブジェクトのどの属性が抽出できるかを知り、ス
テップ609で、カスタマイズ・デバイス・オブジェクト
に固有のどの属性を導き出すべきかを知る。カスタマイ
ズ・デバイス・オブジェクトの属性は、とりわけ、接続
情報とデバイス情報及び関連デバイス・ドライバ情報を
含むことができる。

定義メソッドは、呼出し側から属性名−属性値の対のリ
ストを受け入れ、その結果ステップ604で、ユーザがカ
スタマイズ・オブジェクトに対する変更したい属性を指
定できるようになる。定義メソッドは、ステップ605
で、呼出し側が供給した属性値が範囲内にあるかどうか
妥当性検査を行なう責任をもつ。一般的低レベル属性妥
当性検査ルーチンは、定義メソッドがデバイス・オブジ
ェクト属性の妥当性検査を行なうのを助ける。属性値妥
当性検査処理では、所与のデバイス属性に対する有効オ
プションを含む、事前定義データベース中のオブジェク
ト・クラスを照会する必要があることもある。

ステップ609で、カスタマイズ・デバイス・オブジェク
トの固有の属性を導出する際、及びステップ605で、呼
出し側供給の属性値の妥当性検査を行なう際に、定義メ
ソッドは、導出／供給された属性値が既存のカスタマイ
ズ・デバイス・オブジェクトと衝突しないことを検証す
る。定義メソッドは、どの特定の属性が他のカスタマイ
ズ・オブジェクトと衝突し得るかを知っている。実際の
衝突検出処理は、特別のレベル・コマンドまたはルーチ
ン（busresolveやattvalなど）によって行なわれる。

導出／供給された属性値が、他の関連するカスタマイズ
・デバイス・オブジェクトとの衝突をもたらす場合、定
義メソッドは、ステップ617で、２つのオプションを与
える。ａ）ステップ612で、呼出し側に直ちに戻り、
（適切なエラー・コードを使って）衝突の性質を報告す
るオプションと、ｂ）ステップ613で、衝突を実際に解
決するオプションである。この場合も、実際の衝突解決
処理は、特別の低レベル・コマンドまたはルーチンによ
って行なえる。衝突解決処理は、属性に利用できる実現
可能な値がない場合は失敗する。衝突解決に失敗した場
合、定義メソッドは適切なエラー・コードを呼出し側に
戻す。

定義メソッドは、衝突が解決されたことを示すIPL/実行
時フラグを受け入れ、衝突解決手順を飛び越す。これが
発生するのは、IPL中に、アダプタ間の衝突を解決する
ためにbusresolveがバス構成メソッドによって呼び出さ
れ、次いでアダプタを定義するためにアダプタ定義メソ
ッドが呼び出されるときである。

定義メソッドは、ステップ614で、衝突解決処理が首尾
よく完了した後でのみデータベース中の作成されたカス
タマイズ・デバイス・オブジェクトをコミットする。ス
テップ615で、オブジェクトが作成された後に、カスタ
マイズ・デバイス・オブジェクトの状況フラグが、定義
メソッドによって「定義済み」状態にセットされる。

定義メソッドは、呼出し側に、同じ接続アドレス上で作
成された複数のデバイス・オブジェクトを可能にするオ
プションを提供する。接続アドレスとは、デバイスがど
こに接続されているかの記述である。たとえば、ユーザ
は、同じデバイス接続アドレスに接続された複数のデバ
イス・オブジェクトを定義し、それらの１つだけを構成
することができる。物理デバイスの場合は、定義メソッ
ドは、エンクロージャ・デバイスのデバイス名を受け取
り、カスタマイズ・データベース中に包含情報を生成す
る。論理デバイスに関する定義メソッドは、カスタマイ
ズ・データベースからそれらのデバイスに関する従属性
を推論し、適切な論理デバイス・インスタンスを定義す
るなどの追加機能を提供する。論理デバイスに関する定
義メソッドは、常にIPL時に構成管理プログラムによっ
て走行される。定義メソッドは、その従属性のすべてを
定義し、そのデバイス形式のすべてのインスタンスにつ
いてそれらを接続オブジェクト・クラスに入れる。以後
のIPLで見つかった新しい物理デバイスについては、新
しい物理デバイスの新しい論理従属性が定義メソッドに
よって追加される。さらに、論理デバイス・オブジェク
トがカスタマイズ・データベースに対して定義される。

第6B図で構成メソッド62が３つの基本機能を実行するた
めに呼び出される。第１に、ユーザがデバイス・ドライ
バを介してデバイスと会話を始められるように、所与の
デバイスに関連するデバイス・ドライバを準備する。第
２に、そのデバイスに関連する情報を抽出する。第３
に、所与のデバイスに接続されるまたは従属する、構成
しようとするデバイスの定義を準備する。

デバイス・ドライバ準備処理は、下記のステップを含
む。

１）構成すべき所与のデバイスのDDS構造を得る。DDS
（定義デバイス構造）とは、所与のデバイスに関連する
デバイス・ドライバを初期設定するために作成される情
報である。所与のデバイスのDDSは、そのDDSをその所与
のデバイスが従属するデバイスのDDSに接合することに
よって構築できる。

２）そのデバイスに関連するデバイス・ドライバのメジ
ャー・デバイス番号とマイナー・デバイス番号を指定す
る。

３）デバイス・ドライバがまだロードされてない場合、
それをロードする。

４）特定のデバイス・インスタンスに対する適切なDDS
構造でデバイス・ドライバを初期設定する。

５）必要に応じて特殊ファイルとも呼ばれる適切な/dev
エントリを作成する。

上記のステップを完了した後、デバイス・ドライバに関
する限り、デバイスは準備ができている。

構成すべき所与のデバイスが、それに接続されたまたは
従属する他のデバイスをもつ場合、所与のデバイスに実
際に接続されるデバイスの定義を準備するため、構成メ
ソッドは追加のステップを取る。この準備処理は下記の
ステップを含む。

１）どのデバイスが実際に接続されるかについて所与の
デバイスのドライバを介して照会する（実現可能な場
合）。

２）適切な定義メソッドを呼び出すことにより、カスタ
マイズ・データベース中で検出されたデバイス（まだ定
義されていない場合）を定義する。

３）どのデバイスが所与のデバイスに接続されているか
または従属するかについて、カスタマイズ・データベー
ス（すなわち、接続オブジェクト・クラス）に照会す
る。

４）すでに定義済みであり構成する必要のあるデバイス
のリストを呼出し側（すなわち、構成管理プログラム）
に戻す。

次に、第6B図を参照して、構成メソッドのステップにつ
いて説明する。構成メソッドは、ステップ620で呼び出
されると、ステップ621で、構成すべきデバイスの論理
名を渡される。ステップ622で、所与の論理名をもつカ
スタマイズ・デバイス・オブジェクトがデータベース中
で見つからない場合、ステップ623で、このメソッドは
失敗し、ステップ624で、適切なエラー・コードを戻
す。ステップ625で、構成メソッドが呼び出されて、カ
スタマイズ・デバイス・オブジェクトがすでに「構成済
み」状態にある場合、ステップ626で構成メソッドは、
デバイス・インスタンスが実際にすでにカーネル中で構
成されていることを検証する。そうでない場合は、ステ
ップ627で、構成メソッドは、構成する必要のあるデバ
イスを照会して戻す。

構成メソッドは、呼び出されるとき、システムがIPL段
階または実行中にあることを示すフラグを渡される。構
成メソッドは、IPL中に構成デバイスに関するLED上にチ
ェックポイントをLEDで表示するだけである。このLED表
示は、どのデバイスが現在構成中であるかをユーザに知
らせ、システムの構成状況をユーザに示すために使用さ
れる。

構成メソッドは、所与のデバイスが接続されまたは従属
する先のデバイス（親デバイス）が「構成済み」状態に
あり、他のデバイスは同じ接続アドレスに対して構成さ
れていないことを検証する。

そのデバイスが関連するデバイス・ドライバをもつ場
合、デバイス・ドライバが構成メソッドによってロード
され初期設定される。ステップ628で、デバイス・ドラ
イバに対するDDS構造を得ることも構成メソッドの責任
である。ロードすべきデバイス・ドライバ（すなわち、
デバイス・ドライバ形式）が、カスタマイズ・デバイス
・オブジェクトに記録された情報から推論される。デバ
イス・ドライバがまだロードされてない場合、構成メソ
ッドは、sysconfig（）システム・コールを使ってそれ
をロードする。ステップ630でデバイス・ドライバがロ
ードされたとすると、構成メソッドは、ステップ631
で、そのデバイス・インスタンスに対するデバイス・ド
ライバを初期設定する。この場合も、初期設定はsyscon
fig（）システム・コールを使って行なわれる。sysconf
ig（）を呼び出してデバイス・ドライバを初期設定する
前に、構成メソッドは、ステップ629で、そのデバイス
・インスタンスに関連するメジャー・デバイス番号とマ
イナー・デバイス番号を生成する。メジャー・デバイス
番号もマイナー・デバイス番号も、IPL中を通じて保存
できるように構成データベース中に維持される。ある一
般的低レベル・ルーチンが、デバイス・ドライバ・イン
スタンスに対する有効メジャー・デバイス番号を得るの
に利用できる。また別の一般的低レベル・ルーチンが、
そのデバイス・ドライバ・インスタンスのもので次の利
用可能なマイナー番号を生成するのに利用できる。その
デバイスに特別のマイナー番号生成ルーチンが必要な場
合、構成メソッドは、適切なデバイス特有のマイナー番
号生成ルーチンを呼び出す。デバイス・インスタンスに
対するデバイス・ドライバを初期設定すべくsysconfig
（）を呼び出すために、構成メソッドは、デバイス・イ
ンスタンスに関連するメジャー番号とマイナー番号及び
そのDDS構造を渡す。

構成メソッドは、デバイス・ドライバに関連する構成し
たインスタンスのカウントを維持する。そのカウントが
事前定義した限界より大きい場合、構成処理は失敗し、
適切なエラー・コードが戻される。このカウントは、デ
バイス・ドライバをいつロード及びアンロードすべきか
の標識として使用できることに注意されたい。

ステップ631で、デバイス・ドライバ初期設定処理中に
下記のことが行なわれる。デバイス・ドライバ・インス
タンスが、供給されたDDS構造で初期設定される。その
デバイスが、マイクロコードをダウンロードすることを
必要とする場合、デバイス初期設定ルーチンは、DDSに
記録されたマイクロコード・パス名を用いてマイクロコ
ードをダウンロードする。デバイスが（たとえば、通信
アダプタが必要とする）バッファ・プールの割振りを必
要とする場合、デバイス初期設定ルーチンはその割振り
を行なう。

ステップ632で、デバイス・ドライバを首尾よく初期設
定した後で始めて、構成メソッドは、カスタマイズ・デ
バイス・オブジェクトの状況フラグを「構成済み」に設
定する。ステップ633で、構成メソッドは、構成された
デバイスに関連する必要な特殊ファイル・エントリを/d
ev中に作成する。そのデバイスに特有の/devエントリに
名前をつけるのに使用される特別の規約が（それがある
場合）知られており、構成メソッドによって使用され
る。構成されたすべてのデバイスが/dev中の特殊ファイ
ル・エントリの作成を必要とするわけではないことに注
意されたい。またあるデバイスは/dev中に複数のエント
リを作成することを必要とすることにも注意されたい。
入口点のさまざまな組合せをもつフロッピー・ディスケ
ット・ドライバなどのデバイスではそうである。

ステップ634で、マルチプレクサ・デバイスを構成する
際、構成メソッドは、（実現可能な場合）マルチプレク
サ・デバイスに実際に接続されたデバイスの定義を準備
する。この準備処理は、その関連するデバイス・ドライ
バが、どんなデバイスが実際に接続されているかを照会
する能力をもつ、マルチプレクサ・デバイスにだけ必要
である。この準備処理は、マルチプレクサ・デバイスが
初期設定され、そのマイクロコードが（ある場合）ダウ
ンロードされた後で始めて行なわれる。マルチプレクサ
またはデバイスに実際に何が接続されているかを照会す
るため、構成メソッドは、関連デバイス・ドライバのio
ctlサービスを利用する。ステップ635で、検出されたデ
バイスが識別できる場合、ステップ636で、構成メソッ
ドは、こうした検出デバイスをデータベース中で定義す
るために適切な定義メソッドを呼び出す。接続されたデ
バイスに自己識別性がある場合、構成メソッドは、カス
タマイズ・デバイス・オブジェクトに記録されたデバイ
スと実際のデバイスの識別が一致するかどうか検証す
る。構成メソッドは、実現可能な場合、デバイスが入れ
替わった状況を解決しようと試み、カスタマイズ・デー
タベースと実際のデバイスの不一致をマークする。

ステップ637で、構成メソッドは、カスタマイズ・デー
タベースを照会し、その構成メソッドを走行させる必要
のあるデバイスのリストを、呼出し側（構成管理プログ
ラムまたは高レベル・コマンド）に戻す。こうしたデバ
イスに対する構成メソッドをいつどのようにして呼び出
すかを決定するのは構成管理プログラムの責任である。
たとえば、構成管理プログラムは、HFTやTR（トークン
・リングIF）などの擬似デバイスに対する構成方法をい
つ呼び出すかを知るために、カスタマイズ接続オブジェ
クトを参照する。論理デバイスに関する構成メソッド
は、従属性マップを検査し、次いでどんな従属オブジェ
クトが現実に構成されたかカスタマイズ・オブジェクト
を検査する。次に、構成メソッドは、構成すべき従属デ
バイスが十分に見つかったかどうか判定する。論理デバ
イスに対する構成メソッドも、接続オブジェクト・クラ
スに基づいて、それに従属するデバイスを戻す。

起動メソッドは、アプリケーションまたは制御サブシス
テムに、デバイスがそれらの制御に利用できることを知
らせるために呼び出される。これは、複数の制御サブシ
ステムまたはアプリケーションに知らせることを含む。
デバイスに関する限り、デバイス・ドライバは、それに
関連する構成メソッドを使って構成された後で使用でき
ることを思い起こされたい。起動メソッドの役割は、ア
プリケーション処理がそのデバイスの使用を開始できる
ように、必要な追加ステップを実行することである。ア
プリケーション処理のためにデバイスを起動するのに必
要な追加ステップは、デバイスごとに変わる。たとえ
ば、TCP/IPinetのインスタンスを構成した後で、起動メ
ソッドは、ホスト名、経路、及びifconfigコマンドを呼
び出して、経路情報を初期設定しネットワーク・インタ
フェースを使用可能にする。

次に第6C図を参照して、起動メソッド63について説明す
る。起動メソッドは、デバイスを使用すべくアプリケー
ションまたはサブシステムに対して利用可能にし、また
は知らせるために実行すべき追加ステップを知ってい
る。アプリケーション処理が使用できるようにデバイス
を準備するのに必要な追加ステップを実行するため、利
用可能なときは既存のコマンドを呼び出す。ステップ68
0で起動メソッドが呼び出されると、ステップ681で、起
動すべきデバイスの論理名が起動メソッドにパスされ
る。ステップ682で、所与の論理名をもつカスタマイズ
・デバイス・オブジェクトが見つからなかった場合、ス
テップ683で、起動メソッドは失敗する。ステップ684
で、カスタマイズ・デバイス・オブジェクトが見つかっ
たが、「構成済み」状態にない場合も、ステップ685
で、起動メソッドは失敗する。起動メソッドが成功した
場合、ステップ686で、カスタマイズ・デバイス・オブ
ジェクトの状況フラグを「起動済み」に設定する。成功
しなかった場合は、状況フラグは変更されない。デバイ
スが「起動済み」状態にあるということは、アプリケー
ション処理のためにそれを準備するのに必要な追加ステ
ップが既に実行されたことを意味する。何らかの理由
で、起動すべきデバイスがオンラインでない場合、起動
メソッドは失敗し、適切なエラー・コードと共に戻され
る。注意：通常、物理デバイスは、起動メソッド及び停
止メソッドをもたない。

第6D図の停止メソッド64は、それに対応する起動メソッ
ドによって実行された一連の動作を取り消すために呼び
出される。たとえば、TCP/IPinetインスタンスを停止す
る際、停止メソッドは、それらのTCP/IPセッションを停
止するためにメッセージをユーザに送り、ネットワーク
・インタフェースを使用不能にするためにifconfigコマ
ンドを呼び出す。停止されたデバイスのデバイス・ドラ
イバに関しては、デバイス・ドライバ入口点を直接呼び
出すことにより、そのデバイスは、おそらく依然として
使用できる。ただし、そのデバイスは、デバイスの起動
を必要とするアプリケーションまたはサブシステムにと
って利用不可能である。

停止メソッドのステップは以下の通りである。停止メソ
ッドは、対応する起動メソッドによって実行された一連
のステップを取り消すのに必要なステップを知ってい
る。それ自体の一連の動作を実行した後で、ステップ64
7で、停止メソッドは、そのデバイスを関連するアプリ
ケーションまたはサブシステムにとって利用不可能にす
る。アプリケーション処理がさらに使用できるようにデ
バイスを停止するため、利用可能なときは既存のコマン
ドを呼び出す。ステップ641で、停止メソッドが呼び出
されると、ステップ642で、停止すべきデバイスの論理
名が停止メソッドに渡される。ステップ643で、所与の
論理名をもつカストマイズ・デバイス・オブジェクトが
見つからなかった場合は、ステップ644で、停止メソッ
ドは失敗する。ステップ645で、カスタマイズ・デバイ
ス・オブジェクトが見つかったが、「起動済み」状態に
はない場合も、ステップ646で、停止メソッドは失敗す
る。停止メソッドが成功した場合、ステップ648で、カ
スタマイズ・デバイス・オブジェクトの状況フラグを
「構成済み」に設定する。成功しない場合は、状況フラ
グは変更されない。

第6E図の構成解除メソッド65は、デバイス・ドライバに
対して構成メソッド62によって実行されたステップを取
り消すために呼び出される。デバイス・ドライバ構成解
除ステップは、次のステップを含む。１）そのデバイス
・ドライバからのデバイス・インスタンスを終了する。
２）カーネルからデバイス・ドライバを（もし必要な
ら）アンロードする。３）必要なら、メジャー・デバイ
ス番号とマイナー・デバイス番号を解放し、適切な/dev
エントリを削除する。デバイスを構成解除するとは、そ
れがシステム中でもはや使用できないことを意味する。

第6E図を参照すると、構成解除メソッドのステップは以
下の通りである。ステップ651で構成解除メソッドが呼
び出されると、ステップ652で、構成解除すべきデバイ
スの論理名が構成解除メソッドに渡される。ステップ65
3で、所与の論理名に関連するカスタマイズ・デバイス
・オブジェクトが、データベース中に見つからなかった
場合、ステップ654で、構成解除メソッドは失敗する。
ステップ655で、カスタマイズ・デバイス・オブジェク
トが見つかったが、「構成済み」状態にない場合も、ス
テップ656で、構成解除メソッドは失敗する。失敗する
と、構成解除メソッドは適切なエラー・コードを戻す。

構成解除メソッドは、ステップ657で、そのデバイス・
ドライバからのデバイス・インスタンスを終了させるた
め、sysconfig（）システム・コールを呼び出す。構成
メソッドは、デバイス・ドライバに関連する構成された
インスタンスのカウントを増分する。そのインスタンス
・カウントがゼロになると、ステップ658で、構成解除
メソッドは、sysconfig（）システム・コールを呼び出
すことにより、カーネルからデバイス・ドライバ・コー
ドをアンロードする。デバイス・インスタンスが首尾よ
く終了した後、ステップ659で、構成解除メソッドは、
デバイスの特性に応じて、そのデバイスに割り当てられ
たマイナー・デバイス番号を解放する。マイナー・デバ
イス番号が解放されると、ステップ660で、構成解除メ
ソッドは、/dev中のデバイス・インスタンスに関連する
特殊ファイル・エントリを除去する。一般に、（デバイ
スによって提供される入口点の集合に応じて）１つまた
は複数の特殊ファイル・エントリが１つのデバイスに関
連付けられる。ステップ661で、デバイスの特性に応じ
て、それがデバイス・ドライバの最後のデバイス・イン
スタンスである場合、ステップ662で、構成解除メソッ
ドは、そのデバイスに割り当てられたメジャー・デバイ
ス番号を解放する。メジャー・デバイス番号が解放され
ると、ステップ633で、構成解除メソッドは、/dev中の
デバイス・ドライバに関連する特殊ファイル・エントリ
のすべてを除去する。メジャー・デバイス番号またはマ
イナー・デバイス番号が解放されない場合、デバイス
は、そのデバイスが次に構成されるときも同じデバイス
番号を得ることに注意されたい。ステップ664で、構成
解除メソッドは、構成解除されたデバイスに関連するカ
スタマイズ・デバイス・オブジェクトの状況フラグを、
「定義済み」に設定し戻す。

第6F図の定義解除メソッド66は、カスタマイズ・デバイ
ス・オブジェクトと、データベースに記憶された所与の
デバイスの関連オブジェクトを除去するために呼び出さ
れる。カスタマイズ・データベースで定義解除されたデ
バイスは、もはやシステムには知られない。ステップ67
0で定義解除メソッドが呼び出されると、ステップ671
で、定義解除すべきデバイスの論理名が定義解除メソッ
ドに渡される。ステップ672で、所与の論理名をもつカ
スタマイズ・デバイス・オブジェクトが見つからなかっ
た場合、ステップ673で、定義解除メソッドは失敗す
る。ステップ675で、カスタマイズ・デバイス・オブジ
ェクトが見つかったが、「定義済み」状態にない場合
も、定義解除メソッドは失敗する。失敗すると、ステッ
プ674で、適切なエラー・コードが戻される。ステップ6
76で、定義解除メソッドは、カスタマイズ・デバイス・
オブジェクトを、DDS構造、接続オブジェクト、属性オ
ブジェクト、/devエントリなどの関連情報と共に除去す
る。これがこのデバイス・ドライバに対する最後のデバ
イス・インスタンスである場合、メジャー・デバイス番
号が解放される。

第８図は、オブジェクトが、呼び出されるメソッドに基
づいて様々な状態をどのように通過するかを示す状態遷
移図である。定義メソッド61が呼び出されると、オブジ
ェクトが定義状態161になる。構成メソッド62が、オブ
ジェクトを構成状態162に置くために呼び出される。構
成状態162から開始状態163に移るには、起動メソッド63
を呼び出す。起動状態163から構成162に戻るには、停止
メソッド64を呼び出す。定義状態161に戻るには、構成
解除メソッド65を呼び出す。データベースからオブジェ
クトを除去するには、定義解除メソッド66を呼び出す。
第８図はまた、オブジェクトをその構成状態で有効に保
持するが、その属性は変更する、オブジェクトの再構成
67も示している。

上記の諸メソッドは、物理及び論理デバイスの構成時に
使用される。上記の諸メソッドを、物理デバイス、すな
わちバスの構成を参照してさらに説明する。ただし、バ
スはマルチプレクサ・デバイスとみなされる。バス構成
とは、概念的に、適切なバス・カスタマイズ・オブジェ
クトをデータベース中で定義し、実際にバスに何が接続
されるかを検出し、アダプタ属性間の衝突を解決するこ
とを意味する。バス・デバイス・メソッドは以下の通り
である。

バス定義メソッドは、単に構成データベース中の事前定
義された１組のオブジェクトからカスタマイズ・バス・
デバイス・オブジェクトを作成するだけである。カスタ
マイズ・アダプタ・デバイス・オブジェクトをデータベ
ース内で作成する前に、アダプタの接続点をもたらすバ
ス・オブジェクトが定義される。

バス構成メソッドは、バスを検査し、どのアダプタ・カ
ードがどのスロットに接続されているかを検出し、アダ
プタ資源間の衝突を解決する。バス構成メソッドは、IP
L段階１中にすべてのベース・アダプタを構成し、IPL段
階２中に他のすべてのアダプタを構成する。

バスを検査するには、低レベル・コマンド“busquery"
を呼び出す。コマンド“busquery"は、バスに実際に接
続されたアダプタ・カードを識別するデバイスidのリス
トを戻す。各アダプタ・カードのスロット番号も戻され
る。次にバス構成メソッドがアダプタ・カードidのリス
トを使って、データベース中のカスタマイズ・アダプタ
・オブジェクトを更新する。バス構成メソッドは、以下
の規則に従う。１）バス構成メソッドは、通常IPL中に
構成管理プログラムによって呼び出される。２）バス構
成メソッドは、アダプタ・カードidを使って事前定義構
成データベース中のアダプタ・オブジェクトを引き出
す。３）NIO（固有入出力）や拡張アダプタ・カードな
どバス拡張とみなされる各アダプタ・カードについて
は、バス構成メソッドは、こうしたバス拡張アダプタ・
カードに接続されたすべてのアダプタを検出しなければ
ならない。４）検出されたアダプタすべてについて、バ
ス構成メソッドは、それらのオブジェクトを引き出し、
メモリ中に作業用テンプレートを作成し、アダプタ間の
衝突を解決するためにbusresolveコマンドを呼び出す。
衝突が解決されると、アダプタ定義メソッドを使って、
構成データベースが更新される。この場合、定義メソッ
ドに、衝突が解決されたことを示すIPLフラグがパスさ
れる。５）各アダプタ・オブジェクトごとに、バス構成
メソッドはIPL間の変更を反映する「不在」、「新規」
または「同じ」のフラグを立てなければならない。６）
バス構成のメソッドは、呼出し側である構成管理プログ
ラムに、構成する必要のあるアダプタのリストを戻す。

バス定義解除メソッドは、単に構成データベース中のカ
スタマイズ・バス・オブジェクトを検出するだけであ
る。バス定義解除メソッドは、構成されたアダプタが削
除時にバスに接続される場合、失敗する。

“Busquery":この機能は、デバイス特有の低レベル・バ
ス・コマンド中にカプセル化されている。このコマンド
は、バス上の各スロットを検査して、どのアダプタ・カ
ードが現在接続されているかを判定する。何がスロット
に接続されているか判定するために、適切な照会コール
がマシン・デバイス・ドライバに発行される。各スロッ
トごとに、このコマンドは、接続されたアダプタ・カー
ドの形式を識別するidを戻す。このコマンドの呼出し側
は、接続アダプタを見つけるために戻されたidを使用す
ることができる。

“Busresolve":これは、バス内の衝突を解決する低レベ
ル・バス・コマンド中にカプセル化されている。この低
レベル・コマンドは、通常、アダプタ属性間の衝突を検
出し解決するため、バス構成メソッド及びアダプタ定義
メソッドによって呼び出される。衝突を解決するとき、
このコマンドは、ベース・デバイスとユーザ希望属性を
考慮する必要がある。ベース・デバイスとして指定され
たアダプタは、非ベース・アダプタよりも優先される。
低レベル・コマンドは、以下の異なるオプションで呼び
出すことができる。１）アダプタ衝突が検出された場合
は失敗するようにコマンドに指令する。このコマンド
は、失敗した場合、呼出し側に適切なエラー・コードを
戻す。２）衝突が検出された場合、衝突を解決するよう
にコマンドに指令する。成功したとき、このコマンドは
データベースを更新して、衝突解決の結果として各アダ
プタに割り当てられた新しい属性を記録する。失敗した
場合は、このコマンドは適切なエラー・コードを呼出し
側に戻す。

バス構成メソッドによって使用される２つの低レベル・
デバイス・コマンド／ルーチンは、“busquery"コマン
ドと“busresolve"コマンドであった。一般に、低レベ
ル・デバイス・コマンド／ルーチンは、デバイス構成処
理にとって基本的なシステム・レベル・サービス及び特
殊機能を実行する。各メソッドごとに、１組の特殊コマ
ンドがカプセル化されている。デバイス特有のコマンド
のこともある。メソッドが使用するコマンド／インタフ
ェースは、低レベル・コマンド／ルーチンと呼ばれる。
次に追加のいくつかの低レベル・デバイス・コマンドに
ついて説明する。

一般的低レベル・ルーチン“ddsbuild"は、デバイス従
属構造（DDS）情報を構成する。カスタマイズ・デバイ
ス・オブジェクト及び属性リストがある場合、このルー
チンは、データベースに記憶されたDDSテンプレート情
報を使用して、デバイスに対する適切なDDS構造を構築
する。生成されたDDS構造570は、第５図に示すようにデ
ータベースに記憶される。DDSテンプレート情報は、デ
ータベース中の特殊オブジェクト・クラスに記憶され
る。各固有DDSテンプレートにそれぞれ１つのオブジェ
クト・クラスが割り振られる。各デバイス・オブジェク
トは、DDSテンプレート・オブジェクト・クラスの名前
と関連付けられる。

一般的低レベル・ルーチン“ddsjoin"は、所与のテバイ
スのDDSを、所与のデバイスが従属するデバイスのDDSと
接合する。その結果得られるDDSは、所与のデバイスの
挙動に影響を及ぼすその先祖デバイスからの情報をも
つ。

一般的低レベル・ルーチン“genmajor"は、所与のデバ
イス・インスタンスに対する有効メジャー・デバイス番
号を割り当てる。すべてのデバイス・ドライバ・インス
タンスは、固有のメジャー・デバイス番号をもつ。デバ
イス・インスタンスが、関連するデバイス・ドライバ・
インスタンスの最初のものであるとき、このルーチン
は、利用可能な最小の番号をそのデバイスのメジャー・
デバイス番号として割り当てる。デバイス・インスタン
スがデバイス・ドライバ・インスタンスの最初のインス
タンスではないとき、このルーチンは、関連するデバイ
ス・ドライバのメジャー・デバイス番号を戻す。

一般的低レベル・ルーチン“genminor"は、デバイス・
インスタンスのマイナー・デバイス番号を生成するた
め、構成メソッドによって呼び出される。デバイス・ド
ライバ・インスタンスに関連するすべてのデバイス・イ
ンスタンスは、固有のマイナー・デバイス番号をもつ。
固有のマイナー・デバイス番号を作成するため、genmin
orは、カスタマイズ・データベースから、所与のデバイ
ス・ドライバ・インスタンスに関連するすべてのカスタ
マイズ・デバイス・オブジェクトを引き出す。所与のデ
バイス・ドライバ・インスタンス内のできるだけ小さな
（正の整数）未使用のマイナー番号が戻される。構成メ
ソッドは、この一般的低レベル・ルーチンを使用する代
りに、そのデバイス・インスタンスに対して（複数の）
マイナー・デバイス番号を作成する特殊なメソッドをも
つ。この特殊な場合の構成メソッドは、それ自体のデバ
イス特有のマイナー・デバイス番号生成ルーチンを呼び
出す。

一般的低レベル・ルーチン“attrval"は、所与の属性値
が範囲内にあるかどうか妥当性検査を行なうため、諸メ
ソッド及びより高レベルのプログラムによって呼び出さ
れる。属性値の妥当性検査を行なうには、“attrval"に
デバイス・オブジェクト、属性名、及び属性値を与え
る。“attrval"ルーチンは、事前定義データベース中の
属性の定義済みオプション（すなわち、有効範囲）を引
き出すことができる。次に、所与の属性値が許容範囲内
にあることを検証するため、事前定義オプションが、
“attrval"によって解析される。

上記の低レベル・コマンド／ルーチンは一般的なコマン
ド／ルーチンである。以下に記載の低レベル・コマンド
／ルーチンは、デバイス特有のものである。

TTYポートを構成する低レベル・デバイス・コマンド
は、TTYポートがTTY、プリンタ、モデム、プロッタ、ま
たは他のシリアル・デバイスとして構成されていると
き、諸メソッドによって呼び出される。このコマンド
は、ポート・オブジェクト・クラスの情報を変更する。
ポート・オブジェクト・クラスは、すべてのシステム端
末ポートの名前と特性を含む。“getty"プロセスは、情
報の基本ユーザである。ポートを追加するには、新しい
デバイス名、正確な速度、端末モデル、パリティ、ログ
イン・モード、使用可能、／使用不可能状況、遠隔フラ
グ、及びその他の関連変数をポート・オブジェクト・ク
ラス中で作成しなければならない。ポートを変更するに
は、ポート・オブジェクト・クラスの対応するエントリ
を更新しなければならない。ポートを削除するとは、ポ
ート・オブジェクト・クラスから対応するエントリを除
去することを意味する。

低レベル・コマンドは、擬似端末を追加または削除する
ときに擬似端末に対する構成メソッド及び構成解除メソ
ッドによって呼び出される。すべての擬似端末で、関連
する仮想デバイスの対:ptsとptcがある。ptsに対しては
大部分のデバイス属性が定義されている。このコマンド
は、ptsから対応するptcデバイスを生成し、その対等pt
sが構成されるときptcデバイスが構成されているように
する。

TTYポートを使用可能または使用不能にする低レベル・
コマンドは、通常、起動メソッド及び停止メソッドによ
って呼び出される。このコマンドは、TTYポートをシス
テム・ログイン処理のために利用可能または利用不可能
にする。その入力パラメータは、使用可能または使用不
能にされるポートの論理デバイス名である。ポートを使
用不能にする際は、このコマンドは、特定のポートで走
行するロギング・プログラムを殺すので（ロギング・プ
ログラムが使用中の時でも）、そのポートが後のログイ
ンで利用不可能になる。

他の低レベル・コマンドには以下のものがある。

ベース復元ユーティリティは、NMIを介してNVRAMを読み
取り、それをカスタマイズ・オブジェクト及びコンテナ
・オブジェクトとしてRAM中のブート・ファイル・シス
テムにロードする。ベース復元コマンドは、ODMオブジ
ェクト・クラスを読み取り、コマンド行で指定された目
標に書き込まれる標準形式でオブジェクトをパックする
一般的機能である、ODMpack機能を使用する。

ベース・セーブ・ユーティリティは、ベース・カスタマ
イズ情報（カスタマイズ及びコンテナ）の内容を取り、
それをパックし、NMIを使ってNVRAMにダンプし戻す。ベ
ース・セーブ・コマンドは、パック・オブジェクトを読
み取り、それらをODM構造の現バージョンにアンパック
する一般的機能である、ODMpack機能を使用する。

Mkboot（Bootbuildと同じ）は、/dev/RAMdiskを開き、
その内容をブート論理ボリュームにコピーするユーティ
リティである。

ADF formatコマンドは、供給された、アダプタがODM書
式に変換されたADFファイルを読み取る。目標は、コマ
ンド行に供給され、通常、これは事前定義オブジェクト
・クラスである。

MKiplistコマンドは、マシンのブート時にROSが見るIPL
デバイスのリストをユーサが変更できるようにする。こ
れは、NVRAMのハードウェア部分に影響を及ぼす。

LoadRVコマンドは、入力デバイスを読み取り、NMIを介
してNVRAMに書き込むことにより、デバイス・ドライバ
をNVRAMのソフトウェア部分にロードする。

Quserコマンドは、待ち行列デバイス管理プログラムが
所有する資源が使用中であるかどうか判定し、使用中の
場合は、それを使用しているもののpidを戻す。

構成管理プログラムは、構成処理自体についてはほとん
ど知らず、単にその初期構成規則を得て、構成方式に応
じて処理するだけである。さらに、構成管理プログラム
は、ハードウェア従属である。構成管理プログラムは以
下の方式で処理する。

第１に、config_ruleオブジェクト・クラスからその起
動デバイスを得て、適切なメソッドを呼び出す。一般
に、これは、そのシステム・オブジェクトに対するメソ
ッドを実行することを意味する。マルチプレクサ・デバ
イス・オブジェクトを獲得してその構成メソッドを呼び
出すことによって見つかった各マルチプレクサについて
は、LEDをロードし、DDSを得、低レベル・コマンドを実
行し（当該の場合）、デバイス・ドライバを結合し、de
v/エントリを作成し（必要な場合）、デバイス・ドライ
バを初期設定し、マイクロコードをダウンロードし（必
要な場合）、デバイス特有の情報を収集し、１組のカス
タマイズ・オブジェクトを更新し、接続された（端末）
デバイスを照会し、デバイスがまだカスタマイズに知ら
れていない場合は、見つかった各接続（端末）デバイス
に対して定義メソッドを呼び出すという、構成メソッド
のステップを繰り返す。端末デバイス・オブジェクトを
獲得し、その構成メソッドを呼び出すことによって見つ
かった各端末デバイスについては、LEDをロードし、DDS
を得、低レベル・デバイス・コマンドを実行し（当該の
場合）、デバイス・ドライバを結合し、/devエントリを
作成し（必要な場合）、デバイス・ドライバを初期設定
し、デバイス特有の情報を収集し、１組のカスタマイズ
・オブジェクト中の任意のデバイス構成情報を更新する
という、構成ステップのステップを繰り返す。次に、構
成管理プログラムは、まだ構成されていないデバイスが
あれば、それを構成処理する。

IPL中に構成管理プログラムは以下のガイドラインに従
う。呼び出された後で構成管理プログラムが実行する最
初の動作は、データベースから構成規則を検索すること
である。構成管理プログラムによって実行される動作
は、規則から推論できる。構成管理プログラムは、連続
して構成する必要のあるデバイスのすべてを構成する。
デバイス構成の正確な順序は、構成規則、デバイス接続
性情報、及びデータベースに記憶されたデバイス属性に
よって指示される。構成管理プログラムを呼び出すと
き、それがIPLの第１段階と第２段階のどちらで呼び出
されるかを構成管理プログラムに示す、適切なフラグを
供給する。IPLの第１段階中に呼び出されると、構成管
理プログラムは、ベース・デバイスの最小の集合を構成
する。ベース・システムはルート・ファイル・システム
を含んでいる。最小のベース・システムを構成する際、
構成管理プログラムは、以下の情報集合によって制限さ
れる。１）RAMのブート情報からロードされた、可能な
ベース・デバイスに対する事前定義デバイス・オブジェ
クトと、２）NVRAMからロードされたアンパックされた
ベース・デバイスのカスタマイズ・デバイス・オブジェ
クトである。局所NVRAMがない場合、ベース・カスタマ
イズ・デバイス・オブジェクトは、いくつかの資源から
くる。１）ブート・デバイスにカスタマイズ・オブジェ
クトを記憶することを必要とするブート情報から、２）
ネットワークNVRAMサーバーから、及び３）NVRAMの等価
物（すなわち、その内容がシステム中のIPL間で持続す
る任意のメモリ）からである。ベース・カスタマイズ・
デバイス・オブジェクトがNVRAM（たとえば、最初のIP
L）中で見つからない場合、構成管理プログラムは、ブ
ート情報とともに来たベース・デバイスに対する事前定
義デバイス・オブジェクトだけに基づいてベース・シス
テムを構成する。構成管理プログラムは、IPL処理中に
いずれかのベース・デバイスが変更された場合、NVRAM
を更新する。

第2Aは、IPL及び構成処理を示す流れ図である。まず、
ステップ201で、マシンの電源を入れる。ブートストラ
ップ・プログラムは、非揮発性RAM（NVRAM）またはROM
から１組の有効なIPLデバイスを読み取り、ステップ202
で、ディスク、ディスケット、ローカル・エリア・ネッ
トワーク（LAN）などの適切なIPLデバイスからカーネル
をブートする。このステップは、ブート情報（カーネ
ル、デバッガ、ブートFSなど）をRAMにロードすること
を含む。この時点で、ブート・ファイル・システムは、
事前定義オブジェクトだけを含む。次に、ステップ203
で、カーネルが実行される。このステップは、実メモ
リ、入出力チャネル、レジスタ、割込みマスク、ページ
・テーブル、仮想メモリなどを初期設定し、デバッガを
ロードし、ブート・ファイル・システムをRAMに装填す
ることを含む。ステップ204で、ブート・ファイル・シ
ステムから初期設定プログラムが実行され、段階１に対
する構成管理プログラムを起動する。

IPLの第１段階は、LED、ディスケット、論理ボリューム
管理プログラム、物理ボリューム、ルート・ボリューム
・グループなどのベース・デバイスを構成するだけであ
る。ベース・デバイスとは、システムを起動するために
必要な最小数のエンティティである。次に、ステップ20
5で、構成管理プログラムが実行される。第１段階で
は、ステップ206で、NVRAMに以前にセーブされた情報を
利用する。ブート・ファイル・システムの一部として、
ベース・デバイスに対する事前定義オブジェクト・クラ
スの事前定義情報を提供する１組の構成オブジェクトが
存在する。この段階からのベース・カスタマイズ・オブ
ジェクトの実際の構成が、ODMオブジェクトとしてRAM中
のブート・ファイル・システムに書き込まれる。IPLの
第１段階でデバイスの定義メソッドは、事前定義オブジ
ェクト・クラスからオブジェクトを獲得し、RAM中のブ
ート・ファイル・システムのカスタマイズ・オブジェク
ト・クラスに書き込む。この段階のデバイスの構成メソ
ッドは、RAM中のブート・ファイル・システムにあるオ
ブジェクトに影響を及ぼす。

第2B図は、構成管理プログラムの段階１の実行を示す流
れ図である。構成管理プログラムは、ステップ206で、
従来のIPLから利用できる構成情報があるかどうか判定
する。ある場合は、ベース復元ユーティリティを実行し
て、NVRAMからのベース構成情報（規則、デバイス・ド
ライバ、カスタマイズ・オブジェクト）があればそれを
ロードし、ステップ207で、それをブートRAMファイル・
システム（ramkisk）にロードする。すべてのベース・
デバイスは、ステップ208で、「不在」に設定される。
ステップ209で、構成管理プログラムは構成規則を読み
取り、何をどんな順序で構成するかを決定する。この段
階の規則は一般に、システム、続いて論理ボリューム管
理プログラムなどを順序づける。こうした規則の１つ
は、一般にシステム・オブジェクトである、システムの
頂点を指示する。

ステップ210は、頂点オブジェクト（一般にシステム・
オブジェクト）が定義されているかどうかを決定する。
定義されていない場合、ステップ211で、構成管理プロ
グラムは、頂点オブジェクトに対する定義メソッドを呼
び出す。定義メソッドは、そのオブジェクトがカスタマ
イズに知られていない場合にのみ実行される。ステップ
211は、IPL制御ブロックからの情報を併合することを含
む。ステップ212は、システムに接続されたオブジェク
ト（一般に、バス）を見つけて定義し、バスが定義され
ているかどうか判定し、そうでない場合に定義メソッド
を実行し、システムに接続されたオブジェクト（一般
に、バス）を構成管理プログラムに戻すことを含む。

次に、ステップ213で、バスの構成メソッドが実行され
る。これは、以下のステップを含む。１）バスに接続さ
れたベース・オブジェクト（一般に、アダプタ）を、カ
スタマイズ・ベース・デバイスをヒントとして使って見
つけ定義する。ヒントがないか、またはNVRAMが不良の
場合、そのバスが事前定義オブジェクト・クラスのベー
ス・デバイスかどうか検査する。アダプタが定義されて
いるかどうかをさらに検査し、そうでない場合は、定義
メソッドを実行する。２）バスに接続されたオブジェク
ト（一般に、アダプタ）を構成管理プログラムに戻す。

次に、ステップ214で、アダプタの構成メソッドが実行
される。このステップは、アダプタに対するデバイス・
ドライバを構成することを含む。さらに、アダプタに接
続されたベース・オブジェクト（一般に、端末デバイ
ス）を、カスタマイズ・ベース・デバイスをヒントとし
て使って見つけ定義する。ヒントがないか、またはNVRA
Mが不良で、それがSCSIアダプタである場合、SCSIバス
が、事前定義オブジェクト・クラスのベース・デバイス
かどうか検査する。接続デバイス（一般に、端末デバイ
ス）を求めてアダプタを照会し、定義メソッドを実行す
る。構成が異なり、または見つからない場合、診断のた
めに変更フラグが（「新規」または「不在」に）更新さ
れる。アダプタ（一般に、端末デバイス）に接続された
オブジェクトが構成管理プログラムに戻される。

次に、以下のステップが実行される。見つかったすべて
のデバイスが構成され、構成／起動方法が実行される。
バス、メモリ、浮動小数点などが構成できない場合、エ
ラー・コード（255）を戻して終了する。次に、ルート
・ボリューム・グループをオンに（Varlyon）する。ル
ート・ボリューム・グループが不良で、システムが大丈
夫な場合、エラー・コード（１）を戻して終了する。ル
ート・ボリューム・グループが大丈夫で、システムが大
丈夫な場合、sysconfig（）システム・コールが呼び出
されて、論理ボリューム・デバイス番号でシステム・パ
ラメータを設定することによりカーネルにルート・デバ
イスとルート論理ボリュームを知らせ、（０）を戻して
終了する。ルート・ボリューム・グループが見つから
ず、システムが大丈夫な場合、導入プログラムが実行さ
れて、物理ボリュームを取り出し、ルート・ボリューム
・グループを作成し、ルート・ボリューム・グループを
オンに（Varyon）し、ルート、診断、ページャ、ブート
などの論理ボリュームを作成し、論理ボリューム・デバ
イス番号でシステム・パラメータを設定することにより
カーネルに新しいルート・デバイスとルート論理ボリュ
ームを知らせるために、sysconfig（）システム呼出し
を呼び出し、ページャを起動し、論理ボリューム上にフ
ァイル・システムを作成し、またはユーサ・ディレクト
リをマウントし、すべてのルート論理ボリュームにマル
チ・メディアを散布し、（LEDを使ってもっとディスケ
ットを挿入するよう指示する）、RAMファイル・システ
ムで見つかった/devエントリを実ルート・サブシステム
上に複製し、またはユーザ・ディレクトリを取り外し、
ルート・ボリューム・グループをオフに（Varyoff）
し、成功した場合は（０）を戻し、そうでない場合はエ
ラー・コード（１）を戻して終了する。

ステップ215で、初期設定プログラムが終了し、制御は
カーネルに戻る。これは、RAMファイル・システム（ram
disk）を取り外し、ハード・ディスク上のルート・ファ
イル・システムに変更を加え、ルート・ファイル・シス
テムからinitを実行して段階２に対する構成管理プログ
ラムを起動することを含む。

この第２段階では、RAMファイル・システム中で見つか
ったベース・カスタマイズ・オブジェクト（構成フラグ
がセットされたベース・デバイス）が、ルート・ファイ
ル・システム中で見つかったベース・カスタマイズ・オ
ブジェクトに併合される。さらに、必要なすべての/dev
エントリが、ルート・ファイル・システム中に存在す
る。併合処理の後の第２段階は、基本的に第１段階と同
じである。主な違いは、この段階で決定される構成が、
すべての非ベース・デバイスに対するものであることで
ある。この段階からのカスタマイズ情報は、ODMオブジ
ェクトとしてルート・ファイル・システム中に完全に記
憶される。この第２段階では、ルート・ファイル・シス
テム内に、ブート・ファイル・システム内で見つかるよ
りも大きな事前定義オブジェクトの集合と、システムの
最後の実際の既知の構成を表すカスタマイズ・オブジェ
クト及びコンテナ・オブジェクトがある。カスタマイズ
・オブジェクト及びコンテナ・オブジェクトは、デバイ
スまたはバス構成コマンドによって実行される構成変更
の目標である。この段階の終りで、ベース・カスタマイ
ズ・オブジェクトがすべてベース・セーブ・コマンドを
使ってNVRAMにダンプされる。これは、ベース・デバイ
スの最終状態を反映するためである。この時点で、NVRA
Mが利用可能と仮定すると、ベース・カスタマイズ・オ
ブジェクトのVRAMバージョンはブート・ファイル・シス
テム・バージョンより優先される。この段階でのデバイ
スの定義メソッドは、事前定義オブジェクト・クラスか
らオブジェクトを得て、ルート・ファイル・システムの
カスタマイズ・オブジェクト・クラスにそれを追加す
る。この第２段階でのデバイスの構成メソッドは、ルー
ト・ファイル・システムで見つかったカスタマイズ・オ
ブジェクト・クラスで直接変更を実行する。カスタマイ
ス・オブジェクトの宛先は２つの段階で異なるが、すべ
ての低レベル・コマンドへのインタフェースは同じまま
である。とちらの場合も、データがODMインタフェース
を介してファイル・システムに読み取られ書き込まれ
る。一方の場合は、ファイル・システムがRAMにあり、
他方の場合は、ファイル・システムはディスク・ベース
である。

構成管理プログラムの段階２についての上記の記述は、
第2C図により具体的に示されている。まず、ステップ22
2で、RAMディスクをルート・ファイル・システムのもと
で装填する。ステップ224で、RAMファイル・システム中
のベース・カスタマイズが、ルート・ファイル・システ
ムと併合される。ステップ226で、構成管理プログラム
は、ベース・オペレーティング・システムを導入する必
要があるかどうか決定する。ステップ226で、ベース・
オペレーティング・システムの導入が実行され、ベース
・オペレーティング・システムがまだ導入されていない
場合、ステップ227で、初期プログラム・ロードされ
る。ステップ228で、何をどんな順序で構成するかを決
定するために、構成規則オブジェクトを読み取る（順序
規則はシステム、Ivm、HFT,tcpなど）。ステップ229
で、すべての非ベース・デバイスが「不在」に設定され
る。

次に、ステップ230で、バスの構成メソッドを実行す
る。これは、バスに接続された非ベース・オブジェクト
（一般に、アダプタ）を見つけ定義することを含む。こ
れは、さらにアダプタが定義されているかどうか決定す
ることを含み、定義されていない場合は、定義メソッド
が実行される。構成が異なる場合は、または見つからな
い場合、変更フラグが診断のために（「新規」または
「不在」に）更新される。バスに接続されたオブジェク
ト（一般に、アダプタ）が構成管理プログラムに戻され
る。

次に、ステップ235で、アダプタの構成メソッドを実行
する。これは、アダプタのデバイス・ドライバを構成す
ること、及びステップ236でアダプタに接続された非ベ
ース・オブジェクト（一般に、端末デバイス）を見つけ
定義することを含む。この後者のステップは、接続デバ
イス（一般に、端末デバイス）に対するアダプタを照会
し、それらの定義メソッドを実行することを含む。構成
が異なる場合、または見つからない場合、変更フラグが
診断のために（「新規」または「不在」に）更新され
る。アダプタに接続されたオブジェクト（一般に、端末
デバイス）が構成管理プログラムに戻される。

以下のステップが実行される。ステップ237で、見つか
ったすべてのデバイス（端末）が構成され、それらの構
成／起動方法が実行される。システムが構成されると、
論理デバイスが構成規則とカスタマイズ・オブジェクト
に基づいて構成される。ステップ238で、構成管理プロ
グラムは、構成変更フラグが「新規」または「不在」に
設定されたオブジェクトを獲得する。構成が異なる場
合、ステップ239で、診断が実行されて、カスタマイズ
／コンテナ・オブジェクトを更新する。診断が実行され
るのは、構成が変更した（以前には存在しなかった）た
めにマシンガ初めて初期プログラム・ロードされるとき
である。最後に、ステップ241で、構成管理プログラム
は、NVRAM更新ユーティリティを実行して、ルート・フ
ァイル・システム中のベース・カスタマイズ・オブジェ
クトの内容を取り、それをパックされた形でNVRAMにダ
ンプして戻す。衝突により、ベース・カスタマイズが変
更されることがある。この時点で、IPLが完了する。

次に論理デバイスの構成の説明を行なう。論理デバイス
とは、実デバイスのように動作するソフトウェアに基づ
くデバイスである。擬似デバイス（たとえば、コンソー
ル、HFT）は、他のハードウェアに基づくデバイスに従
属する。これらの擬似デバイスは、その従属性（すなわ
ち、それらがその上で走行するハードウェア）が構成さ
れた後で始めて構成できる。デバイス間の従属性は、構
成データベースに記録される。論理デバイスの例には、
TCP/IP、高機能端末（HFT）、及び論理ボリューム管理
プログラム（lvm）を含む。

論理デバイスの構成は、他のデバイスのそれによく似て
いる。各論理デバイスは、構成データベース中に事前定
義デバイス・オブジェクトをもつ。構成管理プログラム
と高レベル・デバイス・コマンドは、論理デバイスを構
成するため、適切なメソッドと低レベル・コマンドを呼
び出す。

論理デバイスを構成する際に以下の規則に従う。

1.ある形式の擬似デバイスは、そのデバイス・ドライバ
がカーネルと事前に結合され、そのカスタマイズ・デー
タベースがベース・オペレーティング・システム内に含
まれている。これらのデバイスは、通常IPL中または走
行に構成する必要がない。しかし、そのカスタマイズ・
データベースが失われた後でそれを確立するために、IP
L中にこれらのデバイスを構成するためにこうしたデバ
イスが共用する１組の構成メソッドがある。これは、カ
スタマイズ・データベースが失われたときにユーザがベ
ース・オペレーティング・システムを再導入するのを妨
げるためである。この１組の構成メソッドは、すべての
事前結合デバイスを構成し、１つの定義メソッドと１つ
の構成メソッドだけを含む。他のメソッドは必要ない。

2.事前結合論理デバイスに対する高レベルのデバイス・
コマンドはない。事前結合論理デバイスは、事前に初期
設定して、カスタマイズ構成データベースに入れられて
いる。

3.走行時間中に構成できる論理テバイスは、実デバイス
として扱われ、したがって実デバイスと同じ構成戦略を
使用できる。走行時にこれらのデバイスを構成するのに
利用可能な１組の高レベル・デバイス・コマンドがあ
る。

4.構成管理プログラムは、カスタマイズ接続情報と適切
な構成規則を使ってIPL中に論理デバイスを自動的に構
成する。

5.論理デバイスと実デバイスの間の従属性及び異なる論
理デバイス間の従属性は、データベースの接続オブジェ
クト・クラス中で保持される。論理デバイスの構成中に
こうした従属性が確立され記録される。

6.IPL中に、構成管理プログラムは従属性情報と所定順
序との組合せを、論理デバイスをいつ構成するかに関す
るヒントとして使用する。たとえば、コンソールは、従
属性情報が構成管理プログラムにコンソールをいつ構成
すべきかを教えない場合でさえ構成しなければならない
論理デバイスであり、所定の順序が副次的ヒントとして
使用できる。

7.論理デバイスの定義メソッドは、データベースに記録
された構成情報に基づいてそのデバイス・インスタンス
を自動的に定義できるように、適切な知能を組み込まれ
ている。構成管理プログラムに異なるノード形式を構成
する順序を教える、順序規則がある。論理デバイスが順
序規則中で記述されている場合、定義メソッドは、IPL
時に必ず構成管理プログラムによって実行される。定義
メソッドは、その従属性のすべてを定義し、そのデバイ
ス形式のすべてのインスタンスについてそれを接続オブ
ジェクト・クラスに入れる。以後のIPLで見つかった新
しし物理デバイスでは、新しい物理デバイスの新しい論
理従属性が、定義メソッドによって追加される。たとえ
ば、HFT定義メソッドは、どんな物理デバイスが見つか
ったか、何でHFTを構成するか、及びHFTインスタンスを
どのように定義するかについてカスタマイズ・データベ
ースを探索する知能をもつ。

8.論理デバイスの構成メソッドは、従属性マップを見、
カスタマイズ・オブジェクトを見て、どんな従属性オブ
ジェクトが実際に構成されたかを調べる。次に構成メソ
ッドは、構成すべき従属性デバイスが十分に見つかった
かどうかを判定する。論理デバイスの構成メソッドは、
また接続オブジェクト・クラスに基づいてそれに従属す
るデバイスを戻す。たとえば、HFT構成メソッドは、接
続オブジェクト・クラスを見て、どの物理デバイスがす
でに構成されているかを知る。次に、HFT構成メソッド
は、構成された構成要素に基づいてHFTの構成を試み
る。

F.発明の効果 本発明を用いれば、入出力機器の追加、除去等のシステ
ム構成の変更を容易に行なうことができる。

【図面の簡単な説明】

第１図は、IPL/構成処理の構成要素が相互にどのように
組み合わされるかを示す構成図である。 第2A図は、IPL及び構成処理を示す流れ図である。 第2B図は、構成管理プログラムの第１段階の実行を示す
流れ図である。 第2C図は、構成管理プログラムの第２段階を示す流れ図
である。 第３図は、構成データベース中の事前定義構成情報の構
造を示す図である。 第4A図は、システム構成データをグループ分けするため
のコンテナ・グラフとデバイス・グラフである。 第4B図は、システム構成データをグループ分けするため
のデバイス・グラフである。 第4C図は、システム構成データをグループ分けするため
のコンテナ・グラフである。 第５図は、構成データベース中のカスタマイズ構成情報
の構造を示す図である。 第6A図は、定義メソッドの流れ図である。 第6B図は、構成メソッドの流れ図である。 第6C図は、起動メソッドの流れ図である。 第6D図は、停止メソッドの流れ図である。 第6E図は、構成解除メソッドの流れ図である。 第6F図は、定義解除メソッドの流れ図である。 第７図は、構成規則オブジェクトを示す図である。 第８図は、デバイス状況状態遷移図である。 10……構成管理プログラム、15……構成データベース、
20……オブジェクト・データ管理プログラム（ODM）、6
0……メソッド、61……定義メソッド、62……構成メソ
ッド、63……起動メソッド、64……停止メソッド、65…
…構成解除メソッド、66……定義解除メソッド、70……
構成規則、80……カーネル。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ミイーン―サング・パトリツク・ゴール アメリカ合衆国テキサス州オウスチン、ピ ツクフエア・ドライブ11304番地 (72)発明者 ジヨン・クラウデ・オークイン、サード アメリカ合衆国テキサス州オウスチン、ベ リイヒル・ウエイ3907番地 (72)発明者 ピイーター・マネバツト・ヴアルデス アメリカ合衆国テキサス州オウスチン、ノ ール・クレスト・ループ9205番地 (56)参考文献 情報処理学会第36回（昭和63年前期）講 演論文集Ｐ．633−642

Claims (2)

【特許請求の範囲】
1. 【請求項１】データ処理システムの構成要素である複数
   のデバイスと、該データ処理システムを構成するため必
   要な事象のシーケンスを定義する構成ルールとを、オブ
   ジエクト指向データベース中に記憶されている各々に対
   応するオブジエクト・クラスの形で表わすステツプと、 データ処理システムを動的に構成するため、定義メソツ
   ド、構成メソツド、起動メソツド、停止メソツド、構成
   解除メソツドなどの複数のメソツドを、オブジエクト・
   データ管理プログラムの制御の下に、上記デバイスのオ
   ブジエクトに関連付けるステツプと、 データ処理システムのブートに当り、上記構成ルール・
   オブジエクトからの指針の下に構成管理プログラムによ
   り上記メソツドを呼び出し、そのメソツド動作を、デバ
   イスの属性とは無関係に、上記デバイス・オブジエクト
   に関して遂行するステツプと、 より成るデータ処理システムの構成方法。
2. 【請求項２】デバイス間の接続性及び従属性の関係を上
   記オブジエクト指向データベース中に表わしておくとス
   テツプと、 上記接続性及び従属性の関係を調査してデータ処理シス
   テムの上記デバイス・オブジエクトを構成するステツプ
   と、 を含む上記請求項１に記載したデータ処理システムの構
   成方法。