Gentoo udev ガイド

1.  udevって何?

/devディレクトリ

Linuxはウィルスの一種かコーヒーのブランドの何かかな思う人たちの中で、Linuxユーザがシステムのハードウェアについて話すとき、「スラッシュdevスラッシュ何とか」という言葉を使うと、確かに奇妙に映るでしょう。 ですが、幸運なユーザ(読者であるあなたも含む)にとって/dev/hda1と使うのは、プライマリマスタIDEの一番目のパーティションについて話しているということを説明するのには手っ取り早い方法ですよね?

私たちの全てがデバイスファイルとは何であるかを知っています。そのうちの幾人かは/devディレクトリでls -lを実行して、その結果をより詳しく見たときに、なぜデバイスファイルが特別な数値を持っているのかさえも知っています。しかし、プライマリマスタIDEディスクが/dev/hdaとして参照されるということを、私たちは常に当然だと考えます。あなたはこのように判断しないかもしれませんが、そうであればそれは設計上の欠陥です。

USBやIEEE1394、ホットスワップ可能なPCIのようなホットプラグ可能デバイスについて考えてみてください...何が一番目のデバイスですか。 そしてそれはどれだけの期間ですか。一番目のものが外されたとき、他のデバイスは何と名前を割り当てられるでしょうか。 現在進行中のトランザクションにどう影響するでしょうか。 あなたのママが、たまたま一番目のプリンタだったレーザープリンタのプラグを引き抜くことにしたために、印刷ジョブがすごく新しいレーザプリンタから、ほとんど死んでしまっているマトリックスプリンタに突然移動されてしまうことは嬉しいですか。

udevの話題に入りましょう。udevプロジェクトの目標は、以下のように興味深くもあり必要なことでもあります。

• ユーザスペースでの実行
• デバイスファイルを動的に作成/削除
• 一貫性のある命名規則の提供
• ユーザスペース向けAPIの提供

これらの特徴を提供するために、udevは三つに分かれたプロジェクトで開発されています。それはnamedevとlibsysfs、そしてもちろんudevです。

namedev

namedevは、デバイスの命名規則を、udevプログラムとは分離して定義することを可能にします。 これは、柔軟な命名規則方針や体系を独立した団体が開発することを可能にします。 デバイスネーミングサブシステム(namedev)は、udevから使用できる標準インターフェースを提供します。

現在のところnamedevによって一つの命名体系だけが提供されます。 それはLANANAによって提供され、現在のLinuxシステムの大多数によって採用されているので、ほとんどのLinuxユーザにとても馴染みやすいです。 (訳注: LANANA - Linux Assigned Name And Number Authority - http://www.lanana.org/)

namedevは、デバイスの名前を見つけるために、5つのステップを踏みます。 デバイスの名前がそのステップの一つで見つかると、その名前が使用されます。 それらのステップは、以下の通りです。

• ラベルまたはシリアルナンバー
• バスデバイスナンバー
• バストポロジ
• 静的に与えられる名前
• カーネルが提供する名前

ラベルまたはシリアルナンバーのステップは、デバイスが固有の識別子を持つかどうかをチェックします。例えばUSBデバイスは、固有のUSBシリアルナンバーを持っています。SCSIデバイスは固有のUUIDを持っています。namedevが、指定された設定ファイルで、この固有ナンバーと一致するものを見つけた場合、設定ファイルで提供される名前を使用します。

バスデバイスナンバーのステップは、デバイスバスナンバーをチェックします。 ホットスワップ可能でない環境にとっては、このステップはハードウェアデバイスを識別するのに十分に機能します。例えば、PCIバスナンバーは、システムの生存期間中にめったに変わりません。この場合もやはり、namedevは、指定された設定ファイルの中でこの位置関係と一致するものを見つけたら、設定ファイルで提供される名前を使用します。

同様にバストポロジのステップは、ユーザがデバイスを抜き差しして変更しない限り、定義を変更しないやや静的な方法です。ユーザによって提供される設定とデバイスの位置が一致した場合、併記されている名前が使用されます。

四つ目のステップ、静的に与えられる名前は、単純な文字列の置換です。カーネルの名前(デフォルトの名前)が、指定される置換文字列に一致する場合、置換した名前が使用されます。

最後のステップ(カーネルが提供する名前)は、あらゆる状況に対応します。 このステップは、カーネルによって提供されるデフォルトの名前を取得します。 現在のLinuxシステム上で使用されるデバイスの命名規則に一致するので、ほとんどの状況において十分機能します。

libsysfs

udevは、sysfs仮想ファイルシステムを通してカーネルと情報のやりとりを行います。 libsysfsプロジェクトは、sysfsファイルシステムによって提供される情報に、共通の方法でアクセスするための、共通API層を提供します。 このAPIは、ハードウェアの種類が何であろうと、すべてのハードウェアに対して問い合わせることを可能にします。

udev

カーネルがデバイス構造のイベントを検知すると、udevに対して確認するように指示します。udevは/etc/udev/rules.d/ディレクトリにあるルールに従います。そして、udevは、/dev構造上で必要なアクション（デバイスファイルの作成や削除）を行うためカーネルから提供された情報を利用します。

2.  Gentooでのudevの使用

必要条件

udevは、(デフォルトの2007.0のプロファイルにあるgentoo-sourcesのような)カーネル2.6との組み合わせで使用されるように意図されています。 このようなカーネルを使用しているなら、最新のsys-apps/baselayoutバージョンを使用しているか確認する必要があります。必要な条件はこれだけです。

# emerge udev

カーネルに関しては、以下のオプションを必ず有効にしてください。

General setup --->
  [*] Support for hot-pluggable devices

File systems --->
   [*] Inotify file change notification support
   [*]   Inotify support for userspace
  Pseudo filesystems --->
    [*] /proc file system support
    [*] Virtual memory file system support (former shm fs)

もし、genkernelを使っているならば、特に何もする必要はありません。Genkernelはデフォルトでudevをセットアップします。

設定

システムを快適にするためにGentooが提供しているudev設定を使用したい場合は、これ以上読まないでください。 Gentooはudevを使いますが、デバイスノードが欠けるようなことがないよう、静的な/devを継続します。 Gentooのinitスクリプトは、devfsdデーモンを実行しませんし、ブート時にdevfsを停止状態にします。

しかし、あなたが頑固な人で、udev開発者が意図する(udevがまだサポートしていないことによるデバイスノード不足の障害も含む)通りに、udevだけのシステムを走らせたいなら、必ずこのまま読み続けてください。

デバイスファイルノードの保存機能を停止します。 /etc/conf.d/rcの中のRC_DEVICE_TARBALL変数を編集し、それにnoを設定してください。

RC_DEVICE_TARBALL="no"

カーネルにdevfsサポートが含まれているなら、ブートローダ設定でそれを無効にできます。 カーネルパラメータにgentoo=nodevfsを追加してください。 devfsを使用しudevを無効にしたいなら、カーネルパラメータにgentoo=noudevを追加してください。

3.  既知の問題

ブート時のデバイスノードファイル不足

/dev/nullが見つからないというエラーが発生するか、最初のコンソールがないのが原因でうまくブートできない場合の問題は、/devがマウントされてudevによって処理される前に利用可能でなければならない、いくつかのデバイスファイルが不足しているということです。古いメディアからインストールされるGentooマシンで共通の問題です。

sys-apps/baselayout-1.8.12もしくはそれ以降のバージョンで実行している場合、ブートプロセスは最低でもなんとか完走するので、この問題は多少解決されます。しかし、うるさい警告をなくすために、以下で述べられる通りにして不足しているデバイスノードを作成するべきです。

/devファイルシステムがマウントされる前に存在しているデバイスノードを確認するために、以下のコマンドを実行してください。

# mkdir test
# mount --bind / test
# cd test/dev
# ls

うまくブートするために必要なデバイスは、/dev/nullと/dev/consoleです。もし上記のテストでそれらが表示されないなら、手動で作成しなければなりません。以下のコマンドをtest/dev/ディレクトリで実行してください。

# mknod -m 660 console c 5 1
# mknod -m 660 null c 1 3

完了したら、test/ディレクトリをアンマウントすることを忘れないでください。

# cd ../..
# umount test
# rmdir test

udevとnvidia

udevのみのシステムでnVidia社が開発したドライバを使用し、Xサーバが起動に失敗したら、以下のものを確認してください。

• /etc/modules.autoload.d/kernel-2.6にnvidiaモジュールが記述されているか
• baselayoutのバージョンがsys-apps/baselayout-1.8.12と同じかより大きいものであるか

DevFSとudevの間で一貫しない名前付け

二つの動的なデバイス管理方法に一貫した名前付けスキーマを持つという、私たちの意図にも関わらず、名前の食い違いが時々発生します。

HP Smart Array 5i RAID コントローラ（正確にはccissカールモジュール）に関して、この種の障害が報告されました。 udevでは、このデバイスは、X,Y,Zを規則的な番号として/dev/cciss/cXdYpZという名前になります。 devfsでは、/dev/hostX/targetY/partZまたは/dev/cciss/cXdYからのシンボリックリンクになります。

この場合、/etc/fstabとブートローダ設定ファイルを状況に応じてアップデートをするのを忘れないでください。

同じことが、udevではすでに作成されない/dev/mouseのような/devに存在していたシンボリックリンクでも起きます。 Xの設定ファイルを念入りにチェックし、マウスのDeviceルールが、存在するデバイスファイルを指しているかどうか見てください。

devfsとudev間のターミナルの名前の違卯という別な問題もあります。 devfsではターミナルをttyと呼び、udevではvcとttyと呼びます。 これにより、/etc/securityを使ってrootのコンソールログインを制限している場合には問題を引き起こすかもしれません。 rootがコンソールからログインできるよう、/etc/securityのなかにtty1とvc1があるかどうか確かめてください。

ブロックデバイスのリネーム

最近のudev（104以上）と新しめのカーネルバージョン(2.6.19以上）が一緒になると、カーネルのlibataの実装変更によっては、ディスクデバイスの名前が変更されるかもしれません。 /dev/hdcにあるCD-RWデバイスは/dev/sr0に変更されるかもしれません。 一方、これは通常の問題ではなく、別な場所でデバイスを探すためにハードコードされたアプリケーションにおいて問題となりえます。 例えば、media-sound/ripはディスクを見つけるのに、/dev/cdromを前提しますが、 新しいカーネルとudevにより、/dev/cdrom1に名前が変更されていた場合には問題となります。

これらの問題への対応として、/etc/udev/rules.d/70-persistent-cd.rulesを編集し、正しい名前を割り当てなければなりません。

udevルールを書くためにのより詳しい情報は、Daniel Drakeのガイドを読むようにしてください。 （訳注：日本語訳）

ネットワークデバイスのリネーム

ネットワークデバイス（USB WiFiカードなど）の抜き差しにより、ネットワークデバイス名が一つずつインクリメントされることがあります。

こうしたことが起きた場合、wlan0、wlan1、wlan2といったものが見られます。 これは、udevがすでにあるルールをリロードする代わりに、ルールファイルにルールを追加するためです。 udevはルールディレクトリをinotifyにより監視していますので、カーネルコンフィグでinotifyサポートを有効にする必要があります。

File systems --->
  [*] Inotify file change notification support
  [*]   Inotify support for userspace

これで、udevによりネットワークデバイスに対する正しい名前が維持されます。

udevが予期できない順序でモジュールをロードする

ときどき、udevは意図しない、予期できない、もしくはランダムな順番でモジュールをロードします。 とくに、マルチメディアデバイスのほか、同じタイプの複数デバイスがシステムにある場合によく起こります。 割り当てられたデバイス番号に影響を及ぼします。たとえば、サウンドカードで番号が変わっている場合があります。

デバイス番号及び/又はモジュールロード順を固定するための方法はあまり多くありません。 理想を言えば、モジュールパラメータを求めるデバイス番号を特定するために使えばよいのです。 ALSAのようなモジュールでは、indexパラメータを持っています。 こうしたインデックスパラメータを使っているモジュールでは、次に示すように調整することができます。 この例では、システムは二つのサウンドカードをもっています。 インデックスが0のカードが第一カードと指定されます。 一度パラメータが変わってしまったならば、モジュールコンフィグファイルは更新される必要があります。

# echo "option snd-ice1724 index=0" >> /etc/modules.d/alsa
# echo "option snd-ymfpci index=1" >> /etc/modules.d/alsa
# update-modules

上の例はよい解決策ですが、全てのモジュールがインデックスのようなパラメータをサポートしているわけではありません。 こうしたモジュールについては、正しいモジュールロード順を強制する必要があるでしょう。 まず、ブラックリストにそうしたモジュールを記載することで、udevの自動ロードを止めなければいけません。 ロードされるときの正しい名前を使っていることを確認してください。 PCI デバイスでは、pciutilsパッケージにあるpcimodulesの出力から得られるモジュール名を使う必要があります。 次の例は、DVBモジュールを使う例です。

# echo "blacklist b2c2-flexcop-pci" >> /etc/modprobe.d/dvb
# echo "blacklist budget" >> /etc/modprobe.d/dvb
# update-modules

次に、モジュールを正しい順にロードさせます。 それらを、/etc/modules.autoload.d/kernel-2.6に ロードして欲しい適切な順で加えます。

# echo "budget" >> /etc/modules.autoload.d/kernel-2.6
 # echo "b2c2-flexcop-pci" >> /etc/modules.autoload.d/kernel-2.6

その他の問題

デバイスノードが、/etc/modules.autoload.d/kernel-2.6からモジュールが自動でロードされるときには作成されず、modprobeで手動でモジュールをロードしたときには作成されるなら、sys-apps/baselayout-1.8.12かそれ以降のバージョンに更新してみるべきです。

フレームバッファデバイス(/dev/fb/*)のためのサポートは、2.6.6-rc2のバージョンからカーネルに備わっています。

2.6.4より古いカーネルに対しては、/dev/ptsファイルシステムのサポートを明示的に含めなければなりません。

File systems --->
  Pseudo filesystems --->
    [*] /dev/pts file system for Unix98 PTYs

4.  資料と謝辞

Greg Kroah-Hartman(IBM社)による、Linuxシンポジウム(カナダ、オンタリオ州、オタワ - 2003年)でのudev議論は、udevアプリケーションに関して確実な理解を広めました。

Decibel's UDEV Primer(訳注: decibelsのUDEV手引書)(日本語訳)は、udevとGentooについての詳細な文書です。

Gentoo開発者仲間のDaniel DrakeによるWriting udev rules(訳注: udevルールの書き方)(日本語訳)は、udevの設定をカスタマイズする方法を学ぶためのすばらしい文書です。

このドキュメントの内容は、他のものが明示されない限りは、 CC-BY-SA-2.5ライセンスです。 Gentoo Name and Logo Usage Guidelines (日本語訳)が適用されます。