皆さん,
動的デバイス管理ツールudev
udevとはsystemdの別名です。
すみません,
- ※1
- systemdの本業である
「initシステム」 とudevが担うデバイスの認識は, 特にシステム起動時やホットプラグ動作時は相補的な作業となります。たとえばデバイスを検知することで特定のサービスを起動する場合など, より密に連携するためにコードをマージすることになったようです。ただし 「udevは欲しいけどsystemdは使わない」 といったユースケースもあります。一応, udev単体でもビルドできることになっていますが, Gentooなどはudevをeudevとしてフォークしているようです。また, 組み込み系で使われているYoctoもudevをインストールしようとするとまずeudevが使われます。
udevは具体的には次のような流れでデバイスを認識し,
- カーネルが追加・
削除されたデバイスを認識する - ueventによってudevに変更内容が通知される
- udevは通知された内容をもとに事前に設定されたルールに従って処理する
たとえばPCIやUSB,
udev自身がルールに従って主体的に情報を収集し,
- 適切なモジュールの自動ロード
- ストレージ接続・
切断時のマウント・ アンマウント - 各種デバイスファイルの権限の変更
- デバイス認識に伴うスクリプトの実行
- デバイスファイルやシンボリックリンクの作成
- サービスの起動・
停止
特に任意のファイル名やシンボリックリンクの作成は,
udevのルールと変更方法
udevがインストールされたシステムにおいて,
udevのルールファイルは以下のいずれかのディレクトリに保存されています。
- /etc/
udev/ rules. d:システムの管理者が作成・ 変更することを想定したルールファイルの保存場所 - /run/
udev/ rules. d:一時的に作成されるルールファイルの保存場所 - /lib/
udev/ rules. d:パッケージ等システムが提供するルールファイルの保存場所
上記ディレクトリのうち
複数のディレクトリで同じファイル名だった場合は,
- ※2
- もちろん拡張子を
「.rules」 以外に変えるという方法もありますが, 「/lib」 以下のファイルはパッケージのアップデートによって復活する可能性があるので注意が必要です。
モジュール自動ロードのルールファイル
具体的なルールファイルの中身を見てみましょう。
# do not edit this file, it will be overwritten on update
ACTION!="add", GOTO="drivers_end"
ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN{builtin}+="kmod load tifm_sd"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN{builtin}+="kmod load tifm_ms"
SUBSYSTEM=="memstick", RUN{builtin}+="kmod load ms_block mspro_block"
SUBSYSTEM=="i2o", RUN{builtin}+="kmod load i2o_block"
SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}+="kmod load ppdev"
KERNEL=="mtd*ro", ENV{MTD_FTL}=="smartmedia", RUN{builtin}+="kmod load sm_ftl"
LABEL="drivers_end"
ルールファイルはキーバリューの変数をベースにした判定システムです。変数にはカーネルからueventと渡されるものだけでなく,
変数には
ルールは1行ずつ処理されていきます。上記ファイルの内容を順番に見ていきましょう。