マイナー番号領域の管理

dev_t は、メジャー番号領域とマイナー番号領域からなります。メジャー番号領域は Solaris により、マイナー番号領域はデバイスドライバ領域により管理されます。Sun Cluster では、マイナー番号の動作はユーザー領域とカーネル領域とで異なります。

クラスタ全体で有効な dev_t

歴史的な理由のため、デバイスノード (とそのパス) は整数型 dev_t で識別されます。dev_t は、プログラマやシステム管理者が通常使用するシステムインタフェースの一部です。stat(2) システムコールとバックアップユーティリティは dev_t を直接処理します。dev_t は、また、デバイスドライバ開発者向けのプログラミングインタフェースでもあります。

Sun Cluster は、プロセスが実行されたホストにかかわらず、2 つの等しい dev_t は同じデバイスを指すと仮定します。このモデルは、(この特徴に基づいて書かれた) プログラムが、2 つのデバイスの等価性を確立する時に有効です。Sun Cluster は、マイナー番号の二重ビューを導入し、二重ビューを実装するために必要なインタフェースを導入します。カーネルの中で、dev_t はドライバのメジャー番号に対応し、さらに、そのドライバが ddi_create_minor_node(9F) で作成したマイナー番号に対応しています。Sun Cluster では、ユーザー領域から使用される時のマイナー番号である外部マイナー番号がデバイス構成マネージャによって管理され、一意なクラスタ全体で使用できる番号を割り当てています。

この二重番号付け方式は、残念ながら 1 つの欠点を持っています。つまり、カーネルで作成された特定のマイナー番号が、ユーザー領域では異なるマイナー番号で使用されている可能性があります。この矛盾は、マイナー番号のパターンからいくつかのデバイスの特性を確認できると期待しているユーザー領域プログラムには役立ちません。

この矛盾の例として、マイナー番号のビットパターンを使用して、ディスクの特定のスライスやテープデバイスの密度などを指定する場合などがあります。このクラスの問題は、主に、大域的に一意なインスタンス番号を使用することによって軽減できます。デバイスのインスタンス番号をマイナー番号に符号化することによって、ドライバはクラスタ全体で一意な dev_t の値が作成されます。つまり、カーネル領域とユーザー領域間で値が異なるマイナー番号が発生する問題を回避できます。

標準の Solaris エントリポイント (open、close、ioctl など) で渡されるすべての dev_t 値はカーネルのマイナー番号を符号化します。getminor(9F) インタフェースを使用すると、このマイナー番号を抽出できます。しかし、dev_t 値が ioctl データの一部としてユーザー領域から渡された場合、その dev_t 値はユーザー領域で符号化されたマイナー番号を持っています。ドライバが内部マイナー番号と外部マイナー番号の間で正しく対応付けができるように、新しい DDI インタフェース ddi_getiminor(9F) が導入されました。