第 18 章 システムとデバイスの構成

オペレーティングシステムのカーネルとそのインタフェースは大幅に変更されています。SunOS 4 のデバイスドライバは、バイナリ互換を提供していません。この章では、カーネルおよびシステム開発者に影響を与える Solaris 7 の変更点について説明します。

• 「システム構成」

• 「再構成ブート」

• 「開発者に関係するデバイスの命名規則」

システム構成

システム構成の変更点には、動的にロード可能なカーネルとカーネルの配置、config コマンドと boot コマンド、/etc/system ファイルがあります。

動的にロードされるカーネル

以前の SunOS リリースと異なり、Solaris 7 のカーネルは動的に構成されます。現在のカーネルは小さな静的コアと動的にロードできる多くのカーネルモジュールで構成されます。ドライバ、ファイルシステム、STREAMS モジュール、またその他のモジュールは、ブート時または実行時に、必要に応じて自動的にロードされます。これらのモジュールは使用されなくなるとアンロードされます。モジュールは、そのメモリ領域が必要になるまで、メモリ内に維持されます。modinfo(1M) は、現在システムにロードされているモジュールに関する情報を提供します。

modload(1M) コマンドと modunload(1M) コマンドは、Solaris 7 ではまだ使用できますが、動作が異なります。Solaris 7 では、これらのコマンドの使用方法に制限があり、ロード可能なドライバをシステムに正しくインストールするには不十分です。modunload は現在アンロード可能な (ビジー状態ではない) モジュールをすべてアンロードする機能が含まれます。次のように modunload を使用してください。

# modunload -i 0

カーネルの配置

以前は 1 つのファイル /vmunix にあったカーネルの内容は、現在ではディレクトリ階層の複数のモジュールに別れています。デフォルトでは、ディレクトリ階層は /platform/'uname -i'/kernel、/kernel、/usr/kernel です。

モジュールに対するディレクトリ検索パスは、/etc/system ファイルの moddir 変数により設定できます。system(4) のマニュアルページを参照してください。通常、最初にロードされるのは /platform/'uname -i'/kernel/unix です。kernel(1M) のマニュアルページを参照してください。

config コマンド

SunOS 4 リリースでは、config コマンドを使用して、/vmunix がオブジェクトファイルから再リンクできるようにシステム構成ファイルを生成しました。次の Solaris 7 の機能により、このコマンドは必要なくなります。

• ロード可能モジュール

• /etc/system ファイル (system(4) のマニュアルページを参照)

• OpenBoot PROM (OBP) からのデバイスツリー情報

• /kernel/drv と /usr/kernel/drv にある driver.confファイル

/etc/system ファイル

システム構成情報は、現在 /etc/system ファイルに設定されています。また、このファイルはロード可能なモジュールのカーネルの処理方法も変更します。このファイルには、次の形式のコマンドが含まれます。

set parameter=value

たとえば、SunOS 4 ソフトウェアにおいて、MAXUSERS は config(8) を使用して設定されました。Solaris 7 では、/etc/system ファイルの中の次のような行により設定されます。

set maxusers = number

ロード可能なモジュールに影響を与えるコマンドは、次の形式になります。

set module:variable=value

/etc/system ファイルに対して行われた変更は、システムをリブートする際に影響を与えます (system(4) のマニュアルページを参照)。

boot コマンド

Solaris 7 では、次のブートプログラムが使用できます。

• ufsboot - ディスクまたは CD からブートする

• inetboot - ネットワークからブートする

  ディスクからブートする場合、PROM は、一次ブートブロックがローカルディスクのブロック 1 から 15 にあるものと仮定とします。installboot(1M) を使用し、次のようにブートブロックを作成します。

  # installboot /usr/platform/'uname -i'/lib/fs/ufs/bootblk /dev/rdsk/c0t3d0s0

システムファームウェアは、一次ブートストラップ (ブートブロック) プログラムをメモリにロードし、それを実行します。ブートブロックは、UFS ファイルシステムを読み取るプログラムで、二次ブートプログラム (/platform/'uname -i'/ufsboot) をメモリにロードします。

ufsboot は /kernel/unix をロードします。それから /kernel/unix は、ルートファイルシステムのマウントが可能となるまで、ufsboot を使って /kernel ディレクトリ階層からモジュールをロードします。

これらの動作の間、ブートブロックと ufsboot は、ファームウェアによって提供されるドライバを使用します。ufsboot またはブートブロックのいずれにも、ドライバコードはまったく含まれません。ufsboot が SBus カード PROM ドライバを使用するため、ufsboot コードを変更して新しいディスクタイプで新しい SBus カードを取り込む必要はありません。

ネットワークを通してブートする場合、ブートプログラムは SunOS 4 ソフトウェアのディスクレスブートと同じように実行されます。ただし、現在、ブートプログラムは inetboot と呼ばれ、クライアントの vfstab ファイルエントリは異なります。ディスクレスのブート時の情報については、『Solaris のシステム管理 (第 1 巻)』を参照してください。

ブートの相違点の要約

表 18-1 には、SunOS 4 と Solaris 7 とのブートシーケンスの相違点を要約します。

再構成ブート

再構成ブートは、接続されたすべてのデバイスをチェックし、/devices と /dev にそれらの名前を構築するようシステムに指示します。新しいハードウェアをシステムに追加したときは、再構成ブートを行います。次のように -r オプションを使ってブートを開始します。

ok> boot -r

既存のタイプ (ドライバはすでにインストールされている) のデバイスを別に追加して、再構成ブートを忘れた場合、次のコマンドを使用して新しいデバイスを認識するようにシステムに指示することができます。

# touch /reconfigure
# _INIT_RECONFIG=YES /etc/init.d/drvconfig
# _INIT_RECONFIG=YES /etc/init.d/devlinks

開発者に関係するデバイスの命名規則

この節では、「デバイス命名規則」の説明を拡張して、システムとカーネル開発者に関係するデバイス命名規則を中心に説明します。

/devices

/devices ツリーは、カーネルで認識されたデバイスのツリーを表します。このツリーは drvconfig(1M) プログラムによって構成されます。通常 drvconfig(1M) は、システムが -r フラグでブートされた場合のみ実行されます。「再構成ブート」を参照してください。drvconfig は、ブート時に接続されて準備しているデバイス (ドライバのある) を格納するように /devices を構成します。

デバイスドライバがデバイスの存在を確認すると、デバイスドライバは ddi_create_minor_node(9F) を呼び出してエントリを作成します。

デバイスをシステムに追加するには add_drv(1M) コマンドを使用します。ドライバが正常に追加された場合、add_drv(1M) は drvconfig も実行します。

/dev

Solaris 7 では、/dev は /devices の中の実際のエントリへシンボリックリンクを作成するユーティリティプログラムによって管理されます。

• disks(1M)

• tapes(1M)

• ports(1M)

• devlinks(1M)

  スクリプトを実行して、 /dev から /devices へ適切なリンクを作成することができます。/devices 名がハードウェアの一意の名前であるのに対し、 /dev 名はより簡単で親しみやすいという利点があります。

デバイスドライバの命名規則

システムにおける各デバイスは、デバイスドライバによって駆動されます。デバイスドライバは、デバイスの多くのインスタンスを管理します。デバイスは以下のような名前を与えられます。

• 物理名

• 論理名

• インスタンス名

物理名

物理名は /devices に格納されています。物理名はハードウェアについて記述し、プラットホームおよび構成に依存します。以下に例を示します。

/devices/vme/xdc@6d,ee80/xd@0,0:g

物理名を使用すると、どのハードウェアが使用されているかを識別することができます。たとえば、 xdc@6d,ee80 は、VME A16, D32 空間のアドレス 0xee80 にあるディスクコントローラを指します。vme(4)、driver.conf(4) のマニュアルページを参照してください。

論理名

論理名は /dev に格納されています。論理名はデバイスの物理名のプラットホーム固有の内容をできるだけ抽象化しています。たとえば xd というデバイスの論理名は次のようになります。

/dev/dsk/c2d0s6 (コントローラ 2、スレーブ 0、スライス 6 (4.x パーティション `g'))

また、sd というデバイスの論理名は次のようになります。

/dev/dsk/c0t3d0s0 (コントローラ 3、ターゲット 0、lun 0、スライス 0 (4.x パーティション `a'))

論理名は、コントローラのタイプについてはなにも表していません。つまり、SCSI でも IPI でも差はなく、両方とも単にディスクであるということです。

ディスク名

ディスク名は、SunOS 4 リリースで使用されていた英字 a〜h ではなくスライス番号 0〜7 の SVR4 規約に従っています。

ディスク名は、ブロックディスクデバイスについては /dev/dsk/*、raw ディスクについては /dev/rdsk/* という SVR4 規約に従っています。詳細については、『Solaris のシステム管理 (第 1 巻)』を参照してください。

インスタンス名

インスタンス名とは、システムの n 番目のデバイスを意味します。たとえば、sd20 のようになります。

インスタンス名は、ドライバエラーメッセージでレポートされることがあります。次のように dmesg(1M) の出力を見ると、物理名へのインスタンス名のバインディングを知ることができます。

sd9 at esp2: target 1 lun 1
sd9 is /sbus@1,f8000000/esp@0,800000/sd@1,0
     <SUN0424 cyl 1151 alt 2 hd 9 sec 80>

インスタンス名がデバイスに割り当てられると、その名前がそのデバイスにバインドされたままになります。

インスタンス番号はデバイスのマイナー番号でコード化されます。リブートしてもインスタンス番号を一貫したものにするために、システムはそれらを /etc/path_to_inst ファイルに記録します。このファイルは起動時にだけ読み込まれ、現在は add_drv(1M) および drvconfig(1M) コマンドによって更新されます。/etc/path_to_inst ファイルについては、path_to_inst(4) のマニュアルページを参照してください。