/dev ディレクトリ内にあるデバイスノードは、それぞれ 関連するカーネルデバイスに対して、アクセスを提供するためのものです。 udev を利用することで、 /dev ディレクトリは現在のカーネル状態を反映するように なります。各カーネルデバイスには 1 つのデバイスファイルが存在します。ある デバイスがシステムから取り外されると、デバイスノードが削除されます。

/dev ディレクトリの内容はテンポラリファイルシステム 上に存在していて、全てのファイルはシステム起動時に作成されます。設計上、 このディレクトリ内に手動でファイルを作成しても、システムを再起動すると ファイルは消えてしまいます。関連するカーネルの状態に関わらず /dev ディレクトリ内に存在すべき固定のファイルや ディレクトリについては、 /lib/udev/devices ディレクトリ内に配置することができます。システム起動時に左記の ディレクトリ内容は /dev ディレクトリに、 /lib/udev/devices に存在したものと同じ所有権設定と パーミッションのままコピーされます。

必要なデバイス情報は sysfs ファイルシステムから受け取る仕組みです。カーネルが検出して初期化した 各デバイスに対して、デバイス名の付いたディレクトリが作成されます。 このディレクトリにはデバイス固有の情報を含む属性ファイルが入っています。

デバイスが追加されたり削除されたりするたびに、カーネルは udev に対して変更を通知するため uevent を送信します。 udev デーモンは、起動時に /etc/udev/rules.d/*.rules ファイルから提供される全てのルールを読み込んで処理し、メモリ内に記憶します。 ルールファイルを変更したり追加または削除したりした場合は、 udevadm control reload_rules コマンドを利用して、 デーモンに対してメモリ内の記憶を読み込み直すように指定することができます。 同じことが /etc/init.d/boot.udev reload コマンドでも 行なうことができます。 udev のルールと書式について、詳しくは 12.6項 「udev ルールによるカーネル側デバイスイベント処理への影響」 をお読みください。

それぞれ受信したイベントは、提供されたルールセットとの適合処理を行ないます。 各ルールは、追加したりイベントの環境キーを変更したりすることができるほか、 作成するデバイスノードに対して特定の名前を要求したり、ノードを示す シンボリックリンクを追加したり、デバイスノード作成後に実行すべきプログラム を追加したりすることができます。ドライバ中枢部分の uevents は、カーネルの netlink ソケットを利用して受信します。

カーネルのバスドライバは、デバイスに対する探査を行ないます。カーネルはデバイスを 検出すると、それぞれに対して内部用のデバイス構造を作成し、ドライバの中枢部から uevent の形で udev デーモンに 送信します。バスデバイスは特別に作成した ID の形で、自分自身がどんな種類の デバイスであるのかを識別できる値になっています。通常、これらの ID は製造元 ID と製品 ID 、およびサブシステム固有の値から構成されています。各バスは それらの ID について独自の方針を持っていて、それらは MODALIAS と呼ばれます。まとめると、カーネルはデバイス情報を取得してそれらの情報から MODALIAS ID 文字列を生成し、イベントとともにその値を 送信します。 USB マウスの場合、たとえば下記のようになります:

MODALIAS=usb:v046DpC03Ed2000dc00dsc00dp00ic03isc01ip02

各デバイスドライバには、処理可能なそれぞれのデバイスに対して、既知の別名を 保持しています。その一覧はカーネルモジュールファイル自身に含まれる形に なっています。 depmod プログラムは利用可能な全てのモジュールに対して ID の一覧を読み込み、カーネルの /lib/modules ディレクトリ以下の modules.alias ファイルを作成します。 このような構造から、モジュールの読み込みは、 MODALIAS を含んだ各イベントに対して modprobe を呼び出すだけの 簡易な処理で実現できるようになっています。 modprobe $MODALIAS が呼び出されると、モジュールが提供する 別名情報の一覧内を検索し、適合する項目があればそのモジュールを読み込むように なっています。これらの処理は全て udev から自動的に実行されます。

udev が起動する前の起動処理時に 発生した全てのデバイスイベントは、読み込むことができません。これはこれらの イベントを処理するための仕組みがルートファイルシステム内に存在していて、 その時点ではそれらを利用できないためです。このような損失をカバーするため、 カーネルは sysfs ファイル システム内の各デバイスディレクトリ内に uevent という ファイルを提供しています。これらのファイルに add と 書き込むことで、起動時に送信され失われてしまったものと同じイベントを再送する ことができます。 /sys 内にある全ての uevent ファイルに対して単純に繰り返して処理するだけで、デバイスノードを作成して デバイスの設定を実施するために必要な、全てのイベントを再送することができます。

たとえば、その時点ではドライバを用意することができない理由から、初期の起動処理で USB マウスの準備は行なわれません。そのためデバイス検出のイベントは失われ、 それらのデバイスに対するカーネルモジュールの発見もできなくなってしまいます。 接続されている可能性のあるデバイスを手動で検索する代わりに、 udev はルートファイルシステムの 準備が完了すると、カーネルが検出した全てのデバイスに対して イベントを要求し、 USB マウスに対するイベントが再度送信されるようにしています。 マウント済みのルートファイルシステム内にカーネルモジュールが見つかると、 USB マウスが利用できるようになります。

ユーザ側からは、デバイスのコールドプラグ (システム起動時から接続すること) と 稼働時のデバイス検出には確認できる違いはありません。両方のケースとも同じ ルールが適用され、同じ設定済みプログラムが実行されます。

udevadm monitor プログラムを使用すると、ドライバ中枢部の イベントと udev のイベント処理 タイミングについて視覚化を行なうことができます。

UEVENT[1185238505.276660] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1 (usb)
UDEV  [1185238505.279198] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1 (usb)
UEVENT[1185238505.279527] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0 (usb)
UDEV  [1185238505.285573] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0 (usb)
UEVENT[1185238505.298878] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10 (input)
UDEV  [1185238505.305026] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10 (input)
UEVENT[1185238505.305442] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/mouse2 (input)
UEVENT[1185238505.306440] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/event4 (input)
UDEV  [1185238505.325384] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/event4 (input)
UDEV  [1185238505.342257] add   /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10/mouse2 (input)

UEVENT の行には、 netlink を介してカーネルが送信した イベントを表示しています。 UDEV の行には、完了済みの udev イベントハンドラを表示しています。 タイミング情報はマイクロ秒単位で表示されます。 UEVENT と UDEV の行の時間差は、 udev がそのイベントの処理を行なうために費やした時間か、もしくは関連していたり既に 実行中だったりするイベントと同期を待ちあわせるため、実行を遅らせた時間を 表わします。たとえばハードディスクのパーティションに対するイベントは、 常にディスクそのもののイベントが完了するまで待機します。これは、ディスク全体の イベントが問い合わせるハードウエア情報に依存して動作するためです。

udevadm monitor --env コマンドを入力すると、完全な イベント環境を表示します:

ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0/input/input10
SUBSYSTEM=input
SEQNUM=1181
NAME="Logitech USB-PS/2 Optical Mouse"
PHYS="usb-0000:00:1d.2-1/input0"
UNIQ=""
EV=7
KEY=70000 0 0 0 0
REL=103
MODALIAS=input:b0003v046DpC03Ee0110-e0,1,2,k110,111,112,r0,1,8,amlsfw

udev は syslog にもメッセージを 送信します。 syslog 上のどの場所にメッセージを 送信するかを制御する syslog 既定の優先度 (priority) 設定は、 udev の設定ファイル /etc/udev/udev.conf で指定することができます。 既に起動中のデーモンに対して priority を変更するように指定したい場合は、 udevadm control log_priority=レベル/番号 のように実行します。

udev のルールは、カーネルがイベント 自身に追加したプロパティ情報や、カーネルが sysfs 経由で エクスポートした情報であれば、どんなものにでも適合させることができます。 また、ルールでは外部のプログラムから得られる 追加情報を要求することもできます。また、それぞれのイベントは提供された全ての ルールに対して適合性を確認します。全てのルールは /etc/udev/rules.d ディレクトリ内に配置します。

ルールファイル内のそれぞれの行には、少なくとも 1 対のキーと値が書かれています。 キーには 2 種類のものがあります。それは適合キーと代入キーです。全ての適合キー がその値と適合するとそのルールが適用され、代入キーで指定された値が代入されます。 適合ルールにはデバイスノードの名前のほか、ノードを指し示すシンボリックリンクや イベント処理の一部として指定したプログラムを指定することもできます。適合する ルールが見つからない場合は、デバイスノードの作成には既定のデバイスノード名が 使用されます。ルールの文法と提供されている適合キーまたは取り込みデータについては、 それぞれ udev のマニュアルページで 説明しています。下記の例では、 udev のルール文法に関する基本的な内容を説明しています。下記の例は /etc/udev/rules.d/50-udev-default.rules ファイル内に 存在するルールからの抜粋です。

# console
KERNEL=="console", MODE="0600", OPTIONS="last_rule"

# serial devices
KERNEL=="ttyUSB*", ATTRS{product}=="[Pp]alm*Handheld*", SYMLINK+="pilot"

# printer
SUBSYSTEM=="usb", KERNEL=="lp*", NAME="usb/%k", SYMLINK+="usb%k", GROUP="lp"

# kernel firmware loader
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"

console のルールには 3 種類のキーが含まれています: 1 つは適合キー (KERNEL) で、残りの 2 つは代入キー (MODE, OPTIONS) になっています。 KERNEL 適合ルールでは、デバイス一覧を検索して console の種類に該当する任意の項目を探します。 厳密に一致した項目だけに対して適合と判断し、ルールを実行するように設定されて います。また、 MODE キーではデバイスノードに対して特別な パーミッションを設定しています。この場合、このデバイスの所有者に対して読み込み と書き込みの権限を付与しています。 OPTIONS キーでは、 この種類のデバイスに対して適用すべきルールの最後を指定しています。 この種類のデバイスに対して、これ以降に何らかのルールが書かれていても、 それらは無視されます。

次に serial devices のルールは 50-udev-default.rules 内には現在はありませんが、 説明を行なうには便利であるため記載しました。このルールには 2 つの適合キー (KERNEL と ATTRS) と 1 つの代入キー (SYMLINK) が含まれています。 KERNEL キーは、 ttyUSB の種類を持つ全てのデバイスを検索します。 ワイルドカード * を使用することで、このキーはこれらの デバイスの複数に適合するようになっています。 2 つめの適合キーである ATTRS は、任意の ttyUSB デバイスに 対して、 sysfs 内の product 属性 ファイルを読み込んで、特定の文字列が含まれているかどうかを確認しています。 代入キー (SYMLINK) では、このデバイスのシンボリックリンク を /dev/pilot ディレクトリに追加するように指定して います。このキーで使用されている演算子 (+=) は、 udev に対してこの動作を追加で 実行するよう指定しているもので、以前のルールやその後のルールで既にシンボリック リンクを設定済みであっても追加できるようにしているものです。このルールには 2 つの 適合キーが存在するため、両方の条件に該当した場合にのみこのルールが適用されます。

また、 printer のルールは USB プリンタを扱う ためのもので、ルール全体を適用するかどうかを判断するための、 2 つの適合キー (SUBSYSTEM と KERNEL) が含まれています。 3 つ存在する代入キーでは、この種類のデバイスに対する命名 (NAME) とシンボリックリンクの作成 (SYMLINK) 、および この種類のデバイスに対するグループ指定 (GROUP) を 行なっています。 KERNEL キー内には * というワイルドカードを含んでいるため、複数の lp プリンタ デバイスに適合するようになっています。置換文字列はそれぞれ NAME と SYMLINK のキーで使用されていて、内部のデバイス名に 置き換えるような作りになっています。たとえば 1 台目の lp USB プリンタであれば、 /dev/usblp0 のようになります。

さらに kernel firmware loader のルールでは、 その実行時に udev に対して外部の ヘルパースクリプトを起動して、追加のファームウエアを読み込むように指定しています。 また、 SUBSYSTEM の 適合キーでは firmware サブシステムを対象としています。 ACTION キーは、デバイスが firmware サブシステムに属しているかどうかを追加で判断するように指定しています。 最後の RUN+= キーでは、読み込むべきファームウエアの場所を 判断するため、 firmware.sh スクリプトを実行するように 指定しています。

いくつかの汎用ルールを下記に示します:

動的なデバイスディレクトリと udev ルールの 仕組みにより、全てのディスクデバイスに対して、その認識順序や接続方法に依存しない固定の 名前が存在するようになっています。カーネルが作成するそれぞれのブロックデバイスは、 特定のバスやドライブ種類、ファイルシステムについて知っているツールを実行することで 確認を行ないます。動的なカーネル提供のデバイスノード名とともに、 udev ではそのデバイスを指し示す シンボリックリンクの形で、固定の構造を生成する仕組みになっています:

/dev/disk
|-- by-id
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B -> ../../sda
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part1 -> ../../sda1
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part6 -> ../../sda6
|   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part7 -> ../../sda7
|   |-- usb-Generic_STORAGE_DEVICE_02773 -> ../../sdd
|   `-- usb-Generic_STORAGE_DEVICE_02773-part1 -> ../../sdd1
|-- by-label
|   |-- Photos -> ../../sdd1
|   |-- SUSE10 -> ../../sda7
|   `-- devel -> ../../sda6
|-- by-path
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part6 -> ../../sda6
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part7 -> ../../sda7
|   |-- pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sr0
|   |-- usb-02773:0:0:2 -> ../../sdd
|   |-- usb-02773:0:0:2-part1 -> ../../sdd1
`-- by-uuid
    |-- 159a47a4-e6e6-40be-a757-a629991479ae -> ../../sda7
    |-- 3e999973-00c9-4917-9442-b7633bd95b9e -> ../../sda6
    `-- 4210-8F8C -> ../../sdd1

下記のファイルやディレクトリは、 udev を構成するために欠くことのできないものです:

udev の仕組みについてさらなる 情報を得るには、下記のマニュアルページをお読みください: