/dev ディレクトリ内にあるデバイスノードは、対応するカーネルデバイスへのアクセス機能を提供します。 udev を使用する環境では、 /dev ディレクトリはカーネル側での現状を反映したものになっています。それぞれのカーネルデバイスはデバイスファイルという形で提供され、システムからデバイスが取り外されると、デバイスノードも削除されるようになっています。

/dev ディレクトリの内容は一時的なファイルシステムとして用意されているもので、システムが起動するたびに新しくデバイスファイルを作成しています。手作業でデバイスファイルを作成したり変更したりしても、そのような構造から、システムを再起動するとリセットされてしまいます。 /dev 内に、カーネル側の認識とは無関係に、固定で配置すべきファイルやディレクトリがある場合は、 systemd-tmpfiles を利用して作成する必要があります。設定ファイルはそれぞれ /usr/lib/tmpfiles.d/ と /etc/tmpfiles.d/ にあります。詳しくは systemd-tmpfiles(8) のマニュアルページをお読みください。

必要なデバイス情報は sysfs ファイルシステム経由で開示されています。それぞれのデバイスに対して、カーネルが認識し準備を行うと、デバイス名のディレクトリを作成します。ここには属性ファイルのほか、デバイス固有のプロパティファイルなどが含まれています。

デバイスが追加されたり削除されたりすると、カーネルは uevent を送信し、 udev に変更を通知します。 udev デーモンは、その起動時に /usr/lib/udev/rules.d/*.rules および /etc/udev/rules.d/*.rules にあるファイルから、設定されている全てのルールを読み込み、メモリ内に保持します。ルールファイルを変更したり、追加もしくは削除を行ったりした場合は、 udevadm control --reload コマンドでデーモン側に再読み込みを依頼することができます。 udev のルールとその文法について、詳しくは 16.6項 「udev ルールによるカーネルのデバイスイベント処理の調整」 をお読みください。

受信したそれぞれのイベントは、読み込んだルールに対して適合可否を判断します。ルール側では環境キーを追加したり変更したりすることができるほか、作成すべきデバイスノードの名前を指定したり、ノードを指し示すシンボリックリンクを追加したり、デバイスノードの作成後に実行すべきプログラムなどを指定したりすることができます。なお、 uevent はカーネルの 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 マウスのイベントが届くようになりますので、ルートファイルシステム内のカーネルモジュールを読み込んで初期化することができるようになっています。

ユーザスペース側では、起動時にデバイスを接続しても起動後にデバイスを接続しても、目に見える違いはありません。いずれの場合も、同じルールが適用され、同じ設定プログラムが動作します。

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 がイベントを処理するのにかかった時間か、もしくは 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 の優先順位は、 udev の設定ファイルである /etc/udev/udev.conf で設定します。実行中のデーモンのログ優先順位は、 udevadm control --log_priority= レベル/番号 で設定することができます。

udev のルールは、カーネルがイベント自身に付与するプロパティ情報のほか、カーネルが sysfs で開示する任意の情報を条件として設定することができます。このほか、外部プログラムから追加の情報を取得することもできます。また、それぞれのイベントは提供されている全てのルールに対して適合可否を判断します。全てのルールは /usr/lib/udev/rules.d/ (既定のルール) および /etc/udev/rules.d (システム固有の設定) 内に配置されます。

ルールファイルの各行には、少なくとも 1 つ以上のキーと値の対が含まれています。キーには 2 種類のものがあり、それぞれマッチ (適合可否) キーと代入キーと呼ばれています。ルール内のマッチキーで指定された全ての条件が満たされると、そのルールが適用され、代入キーに対して値が割り当てられます。また、マッチキーのルールではデバイスノードの名前を指定することができるほか、ノードを指し示すシンボリックリンクを追加したり、イベント処理の一部として指定したプログラムを起動したりすることができます。なお、いずれのルールにも該当しない場合は、デバイスノードを作成する際に既定のデバイス名が使われます。ルールの文法やマッチキーの一覧、およびデータの取り込み方法などについては、 udev のマニュアルページをお読みください。下記の例では、 udev のルールに関する基本的な文法の説明を行っています。ルールの例は、 /usr/lib/udev/rules.d/50-udev-default.rules にある udev の既定のルールから引用されているものです。

# コンソール
KERNEL=="console", MODE="0600", OPTIONS="last_rule"

# シリアルデバイス
KERNEL=="ttyUSB*", ATTRS{product}=="[Pp]alm*Handheld*", SYMLINK+="pilot"

# プリンタ
SUBSYSTEM=="usb", KERNEL=="lp*", NAME="usb/%k", SYMLINK+="usb%k", GROUP="lp"

# カーネルファームウエアローダ
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 には置換が設定されていて、これによって内部デバイス名からそれぞれを拡張できるようになっています。たとえば 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 のインフラストラクチャについて、詳しくは下記のマニュアルページをお読みください: