Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
適用先 openSUSE Leap 15.7

16 udev による動的なカーネルデバイス管理 Edit source

カーネルは、それが実行中であったとしても、ほぼ全てのデバイスを追加したり削除したりすることができます。また、デバイスの状態の変化 (デバイスの接続や取り外し) についても、その情報をユーザスペース側に配信する必要がありますし、接続時や認識時に設定を行う必要もあります。また、デバイスによっては、ユーザ側にその認識状態を知らせる必要があるものもあります。 udev では、 /dev ディレクトリ内にあるデバイスノードファイルやシンボリックリンクファイルを動的に管理するのに必要な、インフラストラクチャを提供しています。また、 udev のルールでは、カーネルのデバイスイベントを処理する外部プログラムを定義する機能も提供しています。これにより udev は、カーネルのデバイス処理の一部として独自のスクリプトを動作させることができるほか、デバイスの処理時に必要な追加のデータを要求したり、取り込んだりすることができるようになっています。

16.1 /dev ディレクトリ Edit source

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

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

16.2 カーネルの ueventudev Edit source

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

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

受信したそれぞれのイベントは、読み込んだルールに対して適合可否を判断します。ルール側では環境キーを追加したり変更したりすることができるほか、作成すべきデバイスノードの名前を指定したり、ノードを指し示すシンボリックリンクを追加したり、デバイスノードの作成後に実行すべきプログラムなどを指定したりすることができます。なお、 uevent はカーネルの netlink ソケットを介して受信されます。

16.3 ドライバ/カーネルモジュール/デバイス Edit source

カーネルのバスドライバがデバイスを探索します。カーネルは検出されたデバイスごとに内部デバイス構造を作成し、ドライバコアが 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 によって発動される処理です。

16.4 システムの起動と初期デバイス設定 Edit source

システムの起動時、 udev が動作する前に発生したデバイスのイベントは、読み込まれずに失われてしまいます。これは、これらのイベントを処理するインフラストラクチャがルートファイルシステム内に存在しているため、起動処理中には利用できないためです。このような問題を解決するため、カーネル側では sysfs ファイルシステム内の各デバイスのディレクトリ内に uevent ファイルを用意しています。このファイルに add を書き込むと、カーネルは起動時に送信したものと同じイベントを再送するようになっています。 /sys ディレクトリ内にある全ての uevent ファイルに対して、同じことを繰り返すことで、必要なデバイスノードの作成とデバイスの設定を行うことができるようになっています。

たとえば起動時に USB マウスを接続していた場合、ドライバは起動時には利用できないため、初期の起動ロジックでは準備が行われません。そのため、デバイスの検出イベントは失われ、デバイスに対応するカーネルモジュールの検出も失敗します。そのため udev では、ルートファイルシステムの準備が完了した段階で、接続されている全てのデバイスを手作業で検索するのではなく、カーネルから発せられた起動時の全てのイベントを取得します。これにより、 USB マウスのイベントが届くようになりますので、ルートファイルシステム内のカーネルモジュールを読み込んで初期化することができるようになっています。

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

16.5 動作中の udev デーモンの監視 Edit source

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= レベル/番号 で設定することができます。

16.6 udev ルールによるカーネルのデバイスイベント処理の調整 Edit source

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 の既定のルールから引用されているものです。

例 16.1: 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 種類のマッチキー ( KERNELATTRS ) と、 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 プリンタデバイスに合致する仕組みになっていのす。また、 NAMESYMLINK には置換が設定されていて、これによって内部デバイス名からそれぞれを拡張できるようになっています。たとえば lp という内部名の最初の USB プリンタであれば、 /dev/usblp0 のような名前になります。

kernel firmware loaderudev から実行時に外部のヘルパースクリプトを実行して、追加のファームウエアを読み込むためのものです。 SUBSYSTEM のマッチキーは firmware サブシステムを検索します。 ACTION キーは、 firmware サブシステムに属する任意のデバイスが追加されたかどうかを判断しています。 RUN+= キーは firmware.sh スクリプトの実行を指定していて、これによってファームウエアの読み込みを行います。

全てのルールに対して適用される、一般的な規約は下記の通りです:

  • それぞれのルールには、カンマ区切りで 1 つまたは複数のキー/値の対を指定します。

  • キーの操作は演算子で決定します。 udev では複数の演算子に対応しています。

  • それぞれの値は引用符で括らなければなりません。

  • ルールファイル内の 1 行は 1 つのルールに対応します。ルールが 1 行に収まらない場合は、シェルでの記法と同じく、行末に \ を記述して次の行に続けます。

  • udev のルールでは、シェル形式のパターンマッチに対応しています。具体的には * , ? , [] の各パターンを利用することができます。

  • udev では置換に対応しています。

16.6.1 udev ルール内での演算子の使用 Edit source

代入キーの場合は、代入するキーの種類によって利用できる演算子が異なります。マッチキーの場合は通常、値と比較するための様々な演算子を利用することができます。マッチキーでは、下記の演算子を指定することができます:

==

一致しているかどうかを判断します。値にパターンマッチが指定されている場合は、そのパターンに一致するかどうかを判断します。

!=

不一致を判断します。値にパターンマッチが指定されている場合は、そのパターンに一致していないかどうかを判断します。

代入キーの場合は、下記の演算子を指定することができます:

=

キーに対して値を代入します。以前に値や値のリストが代入されていた場合は、その値は消去され、指定した単一の値が代入されます。

+=

項目の一覧内に値を追加します。

:=

最終値を代入します。後続のルールで変更ができなくなります。

16.6.2 udev ルール内での置換の使用 Edit source

udev ではプレースホルダや置換の仕組みを利用することができます。これは他のスクリプトでも利用できる仕組みに似たもので、 udev のルールでは下記のものを使用することができます:

%r , $root

デバイスのディレクトリ (既定では /dev)

%p , $devpath

DEVPATH の値

%k , $kernel

KERNEL の値もしくは内部デバイス名

%n , $number

デバイスの番号

%N , $tempnode

デバイスファイルの一時的な名前

%M , $major

デバイスのメジャー番号

%m , $minor

デバイスのマイナー番号

%s{属性名} , $attr{属性名}

sysfs の属性の値 (属性名 で名前を指定します)

%E{変数名} , $env{変数名}

環境変数の値 (変数名 で名前を指定します)

%c , $result

PROGRAM の出力

%%

% 文字そのもの

$$

$ 文字そのもの

16.6.3 udev マッチキーの使用 Edit source

マッチキーは udev のルールを適用する際、条件を指定するものです。下記のマッチキーを使用することができます:

ACTION

イベントアクションの名前 (デバイスを追加する場合は add に、デバイスを削除する場合は remove になります)

DEVPATH

イベントデバイスのデバイスパス (たとえば DEVPATH=/bus/pci/drivers/ipw3945 のように指定すると、 ipw3945 ドライバに関連する全てのイベントに合致するようになります)

KERNEL

イベントデバイスの内部 (カーネル) 名

SUBSYSTEM

イベントデバイスのサブシステム名 (たとえば SUBSYSTEM=usb のように指定すると、 USB デバイスに関連する全てのイベントに合致するようになります)

ATTR{ファイル名}

イベントの sysfs 属性 (たとえば vendor 内に特定の文字列が含まれているかどうかを調べるには、 ATTR{vendor}=="On[sS]tream" のように指定します)

KERNELS

udev に対して、該当するデバイス名を上位方向に検索させる指定

SUBSYSTEMS

udev に対して、該当するデバイスのサブシステム名を上位方向に検索させる指定

DRIVERS

udev に対して、該当するデバイスのドライバ名を上位方向に検索させる指定

ATTRS{ファイル名}

udev に対して、該当する sysfs の属性名を上位方向に検索させる指定

ENV{キー}

環境変数の値 (たとえば ENV{ID_BUS}="ieee1394" のように指定すると、 FireWire バス ID に関連する全てのイベントに合致するようになります)

PROGRAM

udev に対して外部プログラムを実行する指定 (成功を表す場合、プログラムは 0 を返さなければなりません。また、プログラムが STDOUT に出力した実行結果は、 RESULT キーでチェックすることができます)

RESULT

直近の PROGRAM の出力 (PROGRAM キーと同じルール内に含めるか、後続のルールで指定する必要があります)

16.6.4 udev 代入キーの使用 Edit source

上述のように合致すべき条件を指定するマッチキーとは異なり、代入キーではudev が管理するデバイスノードに対して、値や名前、アクションなどを代入します。

NAME

作成すべきデバイスノードの名前 (ルール内でデバイスノード名が設定されると、NAME キーがある他のルールは全て無視されるようになります)

SYMLINK

このノードに対して作成すべき関連シンボリックリンクの名前 (特定のデバイスノードに対して、複数のルールでシンボリックリンクを作成することができます。また、 1 つのルール内でも、スペースで区切って指定することで、複数のシンボリックリンクを作成することができます。

OWNER, GROUP, MODE

新しいデバイスノードのアクセス権 (ここで何らかの値を指定すると、内蔵されている既定のルールが上書きされます)

ATTR{キー}

イベントデバイスの sysfs 属性に対して書き込むべき値 (== 演算子を使用した場合、このキーはマッチキーとして作用し、特定の sysfs 属性と比較が行われることに注意してください)

ENV{キー}

udev に対して、この環境変数に設定すべき値 (== 演算子を使用した場合、このキーはマッチキーとして作用し、特定の sysfs 属性と比較が行われることに注意してください)

RUN

udev に対して、このデバイス向けに実行すべきプログラムの一覧への追加 (ただし、後続の処理が遅延したりすることのないよう、短時間で終了する処理にしてください)

LABEL

GOTO でジャンプできる先のラベル指定

GOTO

udev に対して、ラベルで指定した位置までいくつかのルールを読み飛ばす指定

IMPORT{種類}

外部プログラムの出力などをイベント環境に読み込む指定 (udev は複数の種類の変数を取り込むことができます。種類を指定しない場合、udev はファイルのアクセス権をもとに実行可否を自身で判断するようになります)

  • program を指定すると、 udev は外部プログラムを実行して出力を取り込みます。

  • file を指定すると、 udev はテキストファイルから取り込みを行います。

  • parent を指定すると、 udev は親デバイスに保存されているキーを取り込みます。

WAIT_FOR_SYSFS

udev に対して、指定した sysfs ファイルが作成されるまで待機する指定 (たとえば WAIT_FOR_SYSFS="ioerr_cnt" のように指定すると、 udevioerr_cnt ファイルが作成されるまで待機します)

OPTIONS

OPTION キーには下記のような値を指定することができます:

  • last_rule を指定すると、 udev は後続の全てのルールを無視するようになります。

  • ignore_device を指定すると、 udev はこのイベントを完全に無視するようになります。

  • ignore_remove を指定すると、 udev はこのデバイスに対して後から発生する削除イベントを無視するようになります。

  • all_partitions を指定すると、 udev はブロックデバイス内に存在する全てのパーティションに対して、デバイスノードを作成するようになります。

16.7 デバイスの命名の恒久化 Edit source

動的なデバイスディレクトリと 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

16.8 udev で使用されるファイル Edit source

/sys/*

Linux カーネルが提供する仮想ファイルシステムで、既知のすべてのデバイスに対する情報を保持しています。この情報は、 udev/dev 内にデバイスノードを作成する際に用いられます。

/dev/*

動的に作成されたデバイスノードと、 systemd-tmpfiles で指定された固定の内容が含まれます。詳しくは systemd-tmpfiles(8) のマニュアルページをお読みください。

下記のファイルやディレクトリは、 udev インフラストラクチャにとって重要なものとなっています:

/etc/udev/udev.conf

udev のメインの設定ファイルです。

/etc/udev/rules.d/*

システム固有の udev マッチングルールが含まれています。ここに独自のルールを設定することで、 /usr/lib/udev/rules.d/* にある既定のルールを変更したり、上書きしたりすることができます。

ファイルはアルファベット/数字順に読み込まれます。また、低い優先順位のファイルに書かれたルールは、より高い優先順位のファイルに書かれたルールによって変更されたり、上書きされたりします。数字の小さいものほど高い優先順位が割り当てられます。

/usr/lib/udev/rules.d/*

既定の udev イベントマッチングルールが含まれています。このディレクトリ内にあるファイルは、それぞれのパッケージが所有しているファイルであるため、将来の更新によって上書きされることがあります。そのため、このディレクトリ内にあるファイルに対しては、追加や削除、編集などを行ってはなりません。追加や削除、編集などを行いたい場合は、 /etc/udev/rules.d ディレクトリをお使いください。

/usr/lib/udev/*

udev のルールから呼び出されるヘルパープログラムです。

/usr/lib/tmpfiles.d/ および /etc/tmpfiles.d/

/dev 以下に配置する固定の内容を設定する場所です。

16.9 さらなる情報 Edit source

udev のインフラストラクチャについて、詳しくは下記のマニュアルページをお読みください:

udev

udev に関する一般的な情報のほか、ルールやその他の重要な設定問題について説明しています。

udevadm

udevadmudev の実行時の振る舞いを制御する際に使用するもので、カーネルイベントの要求やイベントキューの管理、シンプルなデバッグ機構などが提供されています。

udevd

udev イベント管理デーモンに関する情報が記されています。

このページを印刷