udev（ユーデブ）は、Linuxにおける動的デバイスノード管理機構で、ハードウェアの接続・切断イベントに応じて /dev 配下のデバイスファイルを自動生成・削除し、ルールに基づく命名やパーミッション設定、関連スクリプトの起動などを実現する仕組みです。2003年頃に登場し、静的に /dev を作成していた devfs を置き換える形で広く採用されました。現在は systemd プロジェクトに統合され、systemd-udevd デーモンとして提供されています。USBデバイスの自動マウント、ネットワークインターフェイスの安定命名、特殊機器への権限設定など、現代のデスクトップ・サーバー双方で欠かせない基盤技術です。
この記事の目次
- udevを構成する3つの基本要素
- udevルール作成の典型的なフロー
- udevを扱う際の重要な留意点
- devfs時代とudev時代の比較
- まとめ
udevを構成する3つの基本要素
udevの中核を担うのは、systemd-udevdというデーモンです。カーネルがホットプラグイベント（uevent）をnetlink経由で発信すると、udevdがこれを受信して対象デバイスの属性をsysfsから読み取り、必要な /dev エントリの作成・削除や属性付与、関連処理の起動を行います。ブート時には /sys 配下を走査して既存デバイスを一括処理する「coldplug」も担当し、起動完了時には現実のハードウェア状態に応じた /dev ツリーが整っています。
udevの挙動を制御するのがudevルールファイルで、/lib/udev/rules.d/ にディストリビューション標準が、/etc/udev/rules.d/ にサイト固有のカスタマイズが配置されます。ルールはSUBSYSTEM、ACTION、KERNEL、ATTR、ENV などの条件と、SYMLINK、OWNER、GROUP、MODE、RUN といったアクションを組み合わせた宣言的な記述で、対象デバイスにマッチした際にどのような処理を行うかを明示します。sysfsの属性情報と一体で動作することで、柔軟かつ堅牢な動的管理を実現しています。
udevルール作成の典型的なフロー
新しいデバイスに対するudevルールを作る基本手順は、まず対象デバイスがsysfs上のどこに現れるかを把握することから始まります。udevadm info -q path -n /dev/sda のように対象デバイス名から sysfs パスを取得し、続いて udevadm info -a -p
条件が決まったら /etc/udev/rules.d/99-myrule.rules のようなファイルを作成し、SUBSYSTEM=="usb", ATTR{idVendor}=="abcd", ATTR{idProduct}=="1234", SYMLINK+="my-device", MODE="0666" といった行を記述します。番号の若いファイルから順に処理されるため、優先度や上書き関係を意識して命名するのがコツです。ルール反映には udevadm control --reload を実行し、udevadm test /sys/... で実際にマッチするかをドライランで確認できます。これにより、デバイスを抜き差しすることなく安全にルールを検証できます。
udevを扱う際の重要な留意点
udevルールを書く上で最初に意識すべきは処理順序で、/lib と /etc の同名ファイルは /etc が優先され、ルールファイル名の数値プレフィックスが小さい順に処理されます。標準提供されているルールを安易に上書きするとシステム更新時に消える恐れがあるため、必要なら同じファイル名で /etc 側に上書きするか、より大きな数値プレフィックスのファイルでルールを追加するアプローチが推奨されます。
ATTR照合の落とし穴も重要です。一つのデバイスはsysfs上で複数階層に渡る親子関係を持っており、ある属性は当該ノード自体に、別の属性は親ノードに存在することが多々あります。同じルール行内では原則として単一ノードの属性しか参照できないため、親階層の属性を参照したい場合は ATTRS（複数形）を使用します。RUNで重いシェルスクリプトを呼び出すとデバイス処理が遅延しイベントキューが詰まるため、systemd unit の RUN+="" やトリガによる非同期化が推奨されます。ネットワークインターフェイス命名は systemd の predictable network interface names（enp3s0等）に統一する設計が現代のベストプラクティスです。
devfs時代とudev時代の比較
udev登場以前のLinuxではdevfsという仕組みがあり、カーネルが直接 /dev ノードを生成・管理していました。しかしカーネル内にポリシーロジックが入り込み、命名規則の柔軟性に乏しく、ユーザー空間からの拡張が困難という問題を抱えていました。SCSIディスクの順序が起動ごとに変わるなど、運用上の悩みも多く存在しました。
udevは「メカニズムはカーネル、ポリシーはユーザー空間」というUnix哲学に沿った設計で、デバイスノードの動的生成・命名・権限付与を柔軟に制御できる現代的な仕組みを提供しました。ATTR{serial}や by-id、by-path、by-uuid などの安定識別子が利用可能になり、ホットプラグ運用にも十分対応できるようになっています。現在ではsystemdに統合され、デスクトップからエッジデバイス、組み込みLinuxまで広く活用されています。組み込み環境ではudev代替としてmdevやBusyBox組み込みのものを使うケースもありますが、汎用Linuxにおいてudevが事実上の標準である状況は当面続くと考えられます。
まとめ
udevは、Linuxにおける動的デバイス管理の中核を担う存在で、ハードウェアの接続から /dev ノード生成・命名・パーミッション設定・関連処理起動までを宣言的なルールで統一的に制御します。systemdと統合された現在の実装は信頼性が高く、デスクトップ・サーバー・組み込み問わず幅広く採用されています。sysfsと組み合わせて理解することで、ハードウェアとカーネルとユーザー空間の関係が立体的に見えてきます。日常的に意識されにくいものの、現代Linuxの土台を確実に支える基盤技術です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント