Linux カーネルは uevent を通じて、デバイスの変化をユーザー空間へ通知します。現在の多くのディストリビューションでは、systemd-udevd が udev ルールとデバイスデータベースを使ってイベントを処理します。カーネルが生成する devtmpfs と組み合わさり、アプリケーションが /dev 周辺で目にする所有者、権限、属性、シンボリックリンクが作られます。
デバイス · レッスン 5
udev
udev がカーネルのデバイスイベントを処理し、ポリシー、権限、永続リンクを適用する仕組みを学びます。
カーネルイベントからデバイスポリシーへ
デバイスが追加、変更、移動、削除されると、udev は次の処理を行えます。
- sysfs の属性とイベントプロパティを読み取る
- デバイスノードへ所有者、グループ、モードのポリシーを適用する
/dev/disk/by-id/...などの安定したシンボリックリンクを追加する- 他のサービス向けにデバイスへタグを付ける
- 範囲を限定した補助処理を実行する
実際のデバイスとドライバーを担当するのは、引き続きカーネルです。/dev からノードを削除してもハードウェアが物理的に取り外されるわけではなく、mknod でノードを手動作成しても、未対応のハードウェアが出現したりドライバーがバインドされたりはしません。
デバイスの変化に対する udev の処理は、通常何によって開始されますか？
ルールの場所と優先順位
ルールは一般に次の場所にあります。
/usr/lib/udev/rules.d/: ベンダーまたはパッケージが提供するルール/run/udev/rules.d/: 揮発性のランタイムルール/etc/udev/rules.d/: ローカル管理者のポリシー
ファイルはファイル名の辞書順で処理され、同名ファイルがある場合は、インストールされた udev 実装の規則に従い、優先度の高いディレクトリのものが低いディレクトリのものを置き換えます。ローカルルールには意図の明確なファイル名を付け、列挙名ではなく安定した属性に一致させてください。
一つのルールが一致するすべてのデバイスへ影響し得るため、範囲を慎重にテストします。ローカルな上書きまたは補足ルールで対応できる場合は、パッケージのルールを直接編集してはいけません。
ローカル管理者の永続的な udev ルールを置くためのディレクトリはどれですか？
`udevadm` でデバイスを調べる
既存のノードについて udev のプロパティを問い合わせます。
$ udevadm info --query=all --name=/dev/sda
現在のシステムに存在するノードを使ってください。udevadm info --attribute-walk --name=... は sysfs の親階層に沿って属性を表示でき、ルールの作成に役立ちます。udevadm monitor --kernel --udev --property はカーネルイベントと処理済みイベントを監視します。デバイス識別子が現れる場合があるため、記録した出力は適切に扱ってください。
udevadm info --query=all --name=/dev/sda は何を要求しますか？
ルール変更を慎重に適用する
ルールファイルを再読み込みすると、今後のイベント処理が変わります。既存デバイスの状態がすべて自動的に再構築されるわけではありません。手動でイベントを発生させると多数のデバイスやサービスへ影響する場合があるため、対象を絞り、インストール済み udevadm の文書に従ってください。テストコマンドでルール評価を模擬できますが、実イベントの副作用をすべて再現できるとは限りません。
権限や名前を変更する前に、ローカルルールをバックアップし、構文を検証し、既知のテストデバイス一つを観察し、復旧手段を確保します。udev のイベント処理内で長時間かかる作業を直接行わず、適切なサービスへ委ねてください。
udev ルールの再読み込みによって主に変わるものは何ですか？
Linux でハードウェアデバイスを調査するを利用して、管理された環境で udevadm のプロパティ、sysfs パス、/dev のリンクを対応付けてください。
レッスン完了
udev を完了しました
udev を、カーネルイベントとユーザー空間のデバイスポリシーの間に位置付けられるようになりました。
uevent と sysfs 属性を udev ルールの照合に関連付ける。
ベンダー、ランタイム、ローカルのルール配置を区別する。
udevadmでプロパティとイベントの流れを調べる。狭くテストした範囲だけでルールを再読み込みし、イベントを発生させる。