Inhaltsverzeichnis
/dev-Verzeichnis
Der Kernel kann fast jedes Gerät in einem laufenden System hinzufügen oder entfernen. Änderungen des Gerätestatus (ob ein Gerät angeschlossen oder entfernt wird) müssen an den userspace weitergegeben werden. Geräte müssen konfiguriert werden, sobald sie angeschlossen und erkannt wurden. Die Benutzer eines bestimmten Geräts müssen über Änderungen im erkannten Status dieses Geräts informiert werden. udev bietet die erforderliche Infrastruktur, um die Geräteknotendateien und symbolischen Links im /dev-Verzeichnis dynamisch zu warten. udev-Regeln bieten eine Methode, um externe Werkzeuge an die Ereignisverarbeitung des Kernelgeräts anzuschließen. Auf diese Weise können Sie die udev-Gerätebehandlung anpassen. Beispielsweise, indem Sie bestimmte Skripten hinzufügen, die als Teil der Kernel-Gerätebehandlung ausgeführt werden, oder indem Sie zusätzliche Daten zur Auswertung bei der Gerätebehandlung anfordern und importieren.
Die Geräteknoten im /dev-Verzeichnis ermöglichen den Zugriff auf die entsprechenden Kernel-Geräte. Mithilfe von udev spiegelt das /dev-Verzeichnis den aktuellen Status des Kernel wieder. Jedes Kernel-Gerät verfügt über eine entsprechende Gerätedatei. Falls ein Gerät vom System getrennt wird, wird der Geräteknoten entfernt.
Der Inhalt des /dev-Verzeichnisses wird auf einem temporären Dateisystem gespeichert und alle Dateien werden bei jedem Systemstart gerendert. Manuell erstellte oder bearbeitete Dateien sind nicht dazu ausgelegt, einen Neustart zu überstehen. Statische Dateien und Verzeichnisse, die unabhängig vom Status des entsprechenden Kernel-Geräts immer im /dev-Verzeichnis vorhanden sein sollten, können im Verzeichnis /lib/udev/devices platziert werden. Beim Systemstart wird der Inhalt des entsprechenden Verzeichnisses in das /dev-Verzeichnis kopiert und erhält dieselbe Eigentümerschaft und dieselben Berechtigungen wie die Dateien in /lib/udev/devices.
Die erforderlichen Geräteinformationen werden vom sysfs-Dateisystem exportiert. Für jedes Gerät, das der Kernel erkannt und initialisiert hat, wird ein Verzeichnis mit dem Gerätenamen erstellt. Es enthält Attributdateien mit gerätespezifischen Eigenschaften.
Jedes Mal, wenn ein Gerät hinzugefügt oder entfernt wird, sendet der Kernel ein uevent, um udev über die Änderung zu informieren. Der udev-Daemon liest und analysiert alle angegebenen Regeln aus den /etc/udev/rules.d/*.rules-Dateien einmalig beim Start und speichert diese. Wenn Regeldateien geändert, hinzugefügt oder entfernt werden, kann der Dämon die Arbeitsspeicherrepräsentation aller Regeln mithilfe des Kommandos udevadm control reload_rules wieder laden. Dies ist auch beim Ausführen von /etc/init.d/boot.udev reload möglich. Weitere Informationen zu den udev-Regeln und deren Syntax finden Sie unter Abschnitt 19.6, „Einflussnahme auf das Gerätemanagemet über dynamischen Kernel mithilfe von udev-Regeln“.
Jedes empfangene Ereignis wird mit dem Satz der angegebenen Regeln abgeglichen. Die Regeln können Ereignisergebnisschlüssel hinzufügen oder ändern, einen bestimmten Namen für den zu erstellenden Geräteknoten anfordern, auf den Knoten verweisende Symlinks hinzufügen oder Programme hinzufügen, die ausgeführt werden sollen, nachdem der Geräteknoten erstellt wurde. Die Treiber-Core-uevents werden von einem Kernel-Netlink-Socket empfangen.
Die Kernel-Bus-Treiber prüfen, ob Geräte vorhanden sind. Für jedes erkannte Gerät erstellt der Kernel eine interne Gerätestruktur, während der Treiber-Core ein uevent an den udev-Dämon sendet. Bus-Geräte identifizieren sich mithilfe einer speziell formatierten ID, die Auskunft über die Art des Geräts gibt. Normalerweise bestehen diese IDs aus einer Hersteller- und einer Produkt-ID und anderen das Subsystem betreffenden Werten. Jeder Bus weist ein eigenes Schema für diese IDs auf, das so genannte MODALIAS-Schema. Der Kernel bedient sich der Geräteinformationen, verfasst daraus eine MODALIAS-ID-Zeichenkette und sendet diese Zeichenkette zusammen mit dem Ereignis. Beispiel für eine USB-Maus:
MODALIAS=usb:v046DpC03Ed2000dc00dsc00dp00ic03isc01ip02
Jeder Gerätetreiber verfügt über eine Liste bekannter Aliasse für Geräte, die er behandeln kann. Die Liste ist in der Kernel-Moduldatei selbst enthalten. Das Programm depmod liest die ID-Listen und erstellt die Datei modules.alias im Verzeichnis /lib/modules des Kernel für alle zurzeit verfügbaren Module. Bei dieser Infrastruktur ist das Laden des Moduls ein ebenso müheloser Vorgang, wie das Aufrufen von modprobe für jedes Ereignis, das über einen MODALIAS-Schlüssel verfügt. Falls modprobe $MODALIAS aufgerufen wird, gleicht es den für das Gerät verfassten Geräte-Alias mit den Aliassen von den Modulen ab. Falls ein übereinstimmender Eintrag gefunden wird, wird das entsprechende Modul geladen. Dies alles wird automatisch von udev ausgelöst.
Alle Geräteereignisse, die während des Bootvorgangs stattfinden, bevor der udev-Daemon ausgeführt wird, gehen verloren. Dies liegt daran, dass die Infrastruktur für die Behandlung dieser Ereignisse sich auf dem Root-Dateisystem befindet und zu diesem Zeitpunkt nicht verfügbar ist. Diesen Verlust fängt der Kernel mit der Datei uevent ab, die sich im Geräteverzeichnis jedes Geräts im sysfs-Dateisystem befindet. Durch das Schreiben von add in die entsprechende Datei sendet der Kernel dasselbe Ereignis, das während des Bootvorgangs verloren gegangen ist, neu. Eine einfache Schleife über alle uevent-Dateien in /sys löst alle Ereignisse erneut aus, um die Geräteknoten zu erstellen und die Geräteeinrichtung durchzuführen.
Beispielsweise kann eine USB-Maus, die während des Bootvorgangs vorhanden ist, nicht durch die frühe Bootlogik initialisiert werden, da der Treiber zum entsprechenden Zeitpunkt nicht verfügbar ist. Das Ereignis für die Geräteerkennung ist verloren gegangen und konnte kein Kernel-Modul für das Gerät finden. Anstatt manuell nach möglicherweise angeschlossenen Geräten zu suchen, fordert udev lediglich alle Geräteereignisse aus dem Kernel an, wenn das Root-Dateisystem verfügbar ist. Das Ereignis für die USB-Maus wird also lediglich erneut ausgeführt. Jetzt wird das Kernel-Modul auf dem eingehängten Root-Dateisystem gefunden und die USB-Maus kann initialisiert werden.
Von userspace aus gibt es keinen erkennbaren Unterschied zwischen einer coldplug-Gerätesequenz und einer Geräteerkennung während der Laufzeit. In beiden Fällen werden dieselben Regeln für den Abgleich verwendet und dieselben konfigurierten Programme ausgeführt.
Das Programm udevadm monitor kann verwendet werden, um die Treiber-Core-Ereignisse und das Timing der udev-Ereignisprozesse zu visualisieren.
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)
Die UEVENT-Zeilen zeigen die Ereignisse an, die der Kernel an Netlink gesendet hat. Die UDEV-Zeilen zeigen die fertig gestellten udev-Ereignisbehandlungsroutinen an. Das Timing wird in Mikrosekunden angegeben. Die Zeit zwischen UEVENT und UDEV ist die Zeit, die udev benötigt hat, um dieses Ereignis zu verarbeiten oder der udev-Daemon hat eine Verzögerung bei der Ausführung der Synchronisierung dieses Ereignisses mit zugehörigen und bereits ausgeführten Ereignissen erfahren. Beispielsweise warten Ereignisse für Festplattenpartitionen immer, bis das Ereignis für den primären Datenträger fertig gestellt ist, da die Partitionsereignisse möglicherweise auf die Daten angewiesen sind, die das Ereignis für den primären Datenträger von der Hardware angefordert hat.
udevadm monitor --env zeigt die vollständige Ereignisumgebung an:
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 sendet auch Meldungen an syslog. Die Standard-syslog-Priorität, die steuert, welche Meldungen an syslog gesendet werden, wird in der udev-Konfigurationsdatei /etc/udev/udev.conf angegeben. Die Protokollpriorität des ausgeführten Dämons kann mit udevadm control log_priority=level/number geändert werden.
Eine udev-Regel kann mit einer beliebigen Eigenschaft abgeglichen werden, die der Kernel der Ereignisliste hinzufügt oder mit beliebigen Informationen, die der Kernel in sysfs exportiert. Die Regel kann auch zusätzliche Informationen aus externen Programmen anfordern. Jedes Ereignis wird gegen alle angegebenen Regeln abgeglichen. Alle Regeln befinden sich im Verzeichnis /etc/udev/rules.d/.
Jede Zeile in der Regeldatei enthält mindestens ein Schlüsselwertepaar. Es gibt zwei Arten von Schlüsseln: die Übereinstimmungsschlüssel und Zuweisungsschlüssel. Wenn alle Übereinstimmungsschlüssel mit ihren Werten übereinstimmen, wird diese Regel angewendet und der angegebene Wert wird den Zuweisungsschlüsseln zugewiesen. Eine übereinstimmende Regel kann den Namen des Geräteknotens angeben, auf den Knoten verweisende Symlinks hinzufügen oder ein bestimmtes Programm als Teil der Ereignisbehandlung ausführen. Falls keine übereinstimmende Regel gefunden wird, wird der standardmäßige Geräteknotenname verwendet, um den Geräteknoten zu erstellen. Ausführliche Informationen zur Regelsyntax und den bereitgestellten Schlüsseln zum Abgleichen oder Importieren von Daten werden auf der man-Seite von udev beschrieben. Nachfolgend finden Sie einige Beispielregeln, die Sie in die grundlegende Regelsyntax von udev einführen. Sämtliche Beispielregeln stammen aus dem udev-Standardregelsatz, der sich in /etc/udev/rules.d/50-udev-default.rules befindet.
Beispiel 19.1. udev-Beispielregeln
# console
KERNEL=="console", MODE="0600", OPTIONS="last_rule"
# serial devices
KERNEL=="ttyUSB*", ATTRS{product}=="[Pp]alm*Handheld*", SYMLINK+="pilot"
# printer
SUBSYSTEM=="usb", KERNEL=="lp*", NAME="usb/%k", SYMLINK+="usb%k", GROUP="lp"
# kernel firmware loader
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"
Die Regel Konsole besteht aus drei Schlüsseln: einem Übereinstimmungsschlüssel (KERNEL) und zwei Zuweisungsschlüsseln (MODE, OPTIONS). Der Übereinstimmungsschlüssel KERNEL durchsucht die Geräteliste nach Elementen des Typs console. Nur exakte Übereinstimmungen sind gültig und lösen die Ausführung dieser Regel aus. Der Zuweisungsschlüssel MODE weist dem Geräteknoten spezielle Berechtigungen zu, in diesem Fall Lese- und Schreibberechtigung nur für den Eigentümer des Geräts. Der Schlüssel OPTIONS bewirkt, dass diese Regel auf Geräte dieses Typs als letzte Regel angewendet wird. Alle nachfolgenden Regeln, die mit diesem Gerätetyp übereinstimmen, werden nicht mehr angewendet.
Die Regel serial devices steht in 50-udev-default.rules nicht mehr zur Verfügung; es lohnt sich jedoch, sie sich dennoch anzusehen. Sie besteht aus zwei Übereinstimmungsschlüsseln (KERNEL und ATTRS) und einem Zuweisungsschlüssel (SYMLINK). Der Übereinstimmungsschlüssel KERNEL sucht nach allen Geräten des Typs ttyUSB. Durch den Platzhalter * trifft dieser Schlüssel auf mehrere dieser Geräte zu. Der zweite Übereinstimmungsschlüssel (ATTRS) überprüft, ob die Attributdatei product in sysfs der jeweiligen ttyUSB-Geräte eine bestimmte Zeichenkette enthält. Der Zuweisungsschlüssel SYMLINK bewirkt, dass dem Gerät unter /dev/pilot ein symbolischer Link hinzugefügt wird. Der Operator dieses Schlüssels (+=) weist udev an, diese Aktion auch dann auszuführen, wenn dem Gerät bereits durch frühere (oder auch erst durch spätere) Regeln andere symbolische Links hinzugefügt wurden. Die Regel wird nur angewendet, wenn die Bedingungen beider Übereinstimmungsschlüssel erfüllt sind.
Die Regel printer gilt nur für USB-Drucker. Sie enthält zwei Übereinstimmungsschlüssel (SUBSYSTEM und KERNEL), die beide zutreffen müssen, damit die Regel angewendet wird. Die drei Zuweisungsschlüssel legen den Namen dieses Gerätetyps fest (NAME), die Erstellung symbolischer Gerätelinks (SYMLINK) sowie die Gruppenmitgliedschaft dieses Gerätetyps (GROUP). Durch den Platzhalter * im Schlüssel KERNEL trifft diese Regel auf mehrere lp-Druckergeräte zu. Sowohl der Schlüssel NAME als auch der Schlüssel SYMLINK verwenden Ersetzungen, durch die der Zeichenkette der interne Gerätename hinzugefügt wird. Der symbolische Link für den ersten lp-USB-Drucker würde zum Beispiel /dev/usblp0 lauten.
Die Regel kernel firmware loader weist udev an, während der Laufzeit weitere Firmware mittels eines externen Hilfsskripts zu laden. Der Übereinstimmungsschlüssel SUBSYSTEM sucht nach dem Subsystem firmware. Der Schlüssel ACTION überprüft, ob bereits Geräte des Subsystems firmware hinzugefügt wurden. Der Schlüssel RUN+= löst die Ausführung des Skripts firmware.sh aus, das die noch zu ladende Firmware lokalisiert.
Die folgenden allgemeinen Eigenschaften treffen auf alle Regeln zu:
Jede Regel besteht aus einem oder mehreren, durch Kommas getrennten Schlüssel-/Wertepaaren.
Die Aktion eines Schlüssels wird durch seinen Operator festgelegt. udev-Regeln unterstützen verschiedene Operatoren.
Jeder angegebene Wert muss in Anführungszeichen eingeschlossen sein.
Jede Zeile der Regeldatei stellt eine Regel dar. Falls eine Regel länger als eine Zeile ist, verbinden Sie die Zeilen wie bei jeder anderen Shell-Syntax mit \.
udev-Regeln unterstützen Shell-typische Übereinstimmungsregeln für die Schemata *, ? und [].
udev-Regeln unterstützen Ersetzungen.
Bei der Erstellung von Schlüsseln stehen Ihnen je nach gewünschtem Schlüsseltyp verschiedene Operatoren zur Auswahl. Übereinstimmungsschlüssel werden in der Regel nur zum Auffinden eines Wertes verwendet, der entweder mit dem Suchwert übereinstimmt oder explizit nicht mit dem gesuchten Wert übereinstimmt. Übereinstimmungsschlüssel enthalten einen der folgenden Operatoren:
==
Suche nach übereinstimmendem Wert. Wenn der Schlüssel ein Suchschema enthält, sind alle Ergebnisse gültig, die mit diesem Schema übereinstimmen.
!=
Suche nach nicht übereinstimmendem Wert. Wenn der Schlüssel ein Suchschema enthält, sind alle Ergebnisse gültig, die mit diesem Schema übereinstimmen.
Folgende Operatoren können für Zuweisungsschlüssel verwendet werden:
=
Weist einem Schlüssel einen Wert zu. Wenn der Schlüssel zuvor aus einer Liste mit mehreren Werten bestand, wird der Schlüssel durch diesen Operator auf diesen Einzelwert zurückgesetzt.
+=
Fügt einem Schlüssel, der eine Liste mehrerer Einträge enthält, einen Wert hinzu.
:=
Weist einen endgültigen Wert zu. Eine spätere Änderung durch nachfolgende Regeln ist nicht möglich.
udev-Regeln unterstützen sowohl Platzhalter als auch Ersetzungen. Diese setzen Sie genauso ein wie in anderen Skripten. Folgende Ersetzungen können in udev-Regeln verwendet werden:
%r, $root
Standardmäßig das Geräteverzeichnis /dev.
%p, $devpath
Der Wert von DEVPATH.
%k, $kernel
Der Wert von KERNEL oder der interne Gerätename.
%n, $number
Die Gerätenummer.
%N, $tempnode
Der temporäre Name der Gerätedatei.
%M, $major
Die höchste Nummer des Geräts.
%m, $minor
Die niedrigste Nummer des Geräts.
%s{attribute}, $attr{attribute}
Der Wert eines sysfs-Attributs (das durch attribute festgelegt ist).
%E{variable}, $attr{variable}
Der Wert einer Umgebungsvariablen (die durch variable festgelegt ist).
%c, $result
Die Ausgabe von PROGRAM.
%%
Das %-Zeichen.
$$
Das $-Zeichen.
Übereinstimmungsschlüssel legen Bedingungen fest, die erfüllt sein müssen, damit eine udev-Regel angewendet werden kann. Folgende Übereinstimmungsschlüssel sind verfügbar:
ACTION
Der Name der Ereignisaktion, z. B. add oder remove beim Hinzufügen oder Entfernen eines Geräts.
DEVPATH
Der Gerätepfad des Ereignisgeräts, zum Beispiel DEVPATH=/bus/pci/drivers/ipw3945 für die Suche nach allen Ereignissen in Zusammenhang mit dem Treiber ipw3945.
KERNEL
Der interne Name (Kernel-Name) des Ereignisgeräts.
SUBSYSTEM
Das Subsystem des Ereignisgeräts, zum Beispiel SUBSYSTEM=usb für alle Ereignisse in Zusammenhang mit USB-Geräten.
ATTR{Dateiname}
sysfs-Attribute des Ereignisgeräts. Für die Suche nach einer Zeichenkette im Attributdateinamen vendor können Sie beispielsweise ATTR{vendor}=="On[sS]tream" verwenden.
KERNELS
Weist udev an, den Gerätepfad aufwärts nach einem übereinstimmenden Gerätenamen zu durchsuchen.
SUBSYSTEMS
Weist udev an, den Gerätepfad aufwärts nach einem übereinstimmenden Geräte-Subsystemnamen zu durchsuchen.
DRIVERS
Weist udev an, den Gerätepfad aufwärts nach einem übereinstimmenden Gerätetreibernamen zu durchsuchen.
ATTRS{Dateiname}
Weist udev an, den Gerätepfad aufwärts nach einem Gerät mit übereinstimmenden sysfs-Attributwerten zu durchsuchen.
ENV{Schlüssel}
Der Wert einer Umgebungsvariablen, zum Beispiel ENV{ID_BUS}="ieee1394 für die Suche nach allen Ereignissen in Zusammenhang mit der FireWire-Bus-ID.
PROGRAM
Weist udev an, ein externes Programm auszuführen. Damit es erfolgreich ist, muss das Programm mit Beendigungscode Null abschließen. Die Programmausgabe wird in stdout geschrieben und steht dem Schlüssel RESULT zur Verfügung.
RESULT
Überprüft die Rückgabezeichenkette des letzten PROGRAM-Aufrufs. Diesen Schlüssel können Sie entweder sofort der Regel mit dem PROGRAM-Schlüssel hinzufügen oder erst einer nachfolgenden Regel.
Im Gegensatz zu den oben beschriebenen Übereinstimmungsschlüsseln beschreiben Zuweisungsschlüssel keine Bedingungen, die erfüllt werden müssen. Sie weisen den Geräteknoten, die von udev gewartet werden, Werte, Namen und Aktionen zu.
NAME
Der Name des zu erstellenden Geräteknotens. Nachdem der Knotenname durch eine Regel festgelegt wurde, werden alle anderen Regeln mit dem Schlüssel NAME, die auf diesen Knoten zutreffen, ignoriert.
SYMLINK
Der Name eines symbolischen Links, der dem zu erstellenden Knoten hinzugefügt werden soll. Einem Geräteknoten können mittels mehrerer Zuweisungsregeln mehrere symbolische Links hinzugefügt werden. Ebenso können Sie aber mehrere symbolische Links für einen Knoten auch in einer Regel angeben. Die Namen der einzelnen Symlinks müssen in diesem Fall jeweils durch ein Leerzeichen getrennt sein.
OWNER, GROUP, MODE
Die Berechtigungen für den neuen Geräteknoten. Die hier angegebenen Werte überschreiben sämtliche kompilierten Werte.
ATTR{Schlüssel}
Gibt einen Wert an, der in ein sysfs-Attribut des Ereignisgeräts geschrieben werden soll. Wenn der Operator == verwendet wird, überprüft dieser Schlüssel, ob der Wert eines sysfs-Attributs mit dem angegebenen Wert übereinstimmt.
ENV{Schlüssel}
Weist udev an, eine Umgebungsvariable zu exportieren. Wenn der Operator == verwendet wird, überprüft dieser Schlüssel, ob der Wert einer Umgebungsvariable mit dem angegebenen Wert übereinstimmt.
RUN
Weist udev an, der Liste der für dieses Gerät auszuführenden Programme ein Programm hinzuzufügen. Sie sollten hier nur sehr kurze Aufgaben angeben. Anderenfalls laufen Sie Gefahr, dass weitere Ereignisse für dieses Gerät blockiert werden.
LABEL
Fügt der Regel eine Bezeichnung hinzu, zu der ein GOTO direkt wechseln kann.
GOTO
Weist udev an, eine Reihe von Regeln auszulassen und direkt mit der Regel fortzufahren, die die von GOTO angegebene Bezeichnung enthält.
IMPORT{Typ}
Lädt Variablen in die Ereignisumgebung, beispielsweise die Ausgabe eines externen Programms. udev kann verschiedene Variablentypen importieren. Wenn kein Typ angegeben ist, versucht udev den Typ anhand des ausführbaren Teils der Dateiberechtigungen selbst zu ermitteln.
program weist udev an, ein externes Programm auszuführen und dessen Ausgabe zu importieren.
file weist udev an, eine Textdatei zu importieren.
parent weist udev an, die gespeicherten Schlüssel des übergeordneten Geräts zu importieren.
WAIT_FOR_SYSFS
Weist udev an, auf die Erstellung der angegebenen sysfs-Datei für ein bestimmtes Gerät zu warten. Beispiel: WAIT_FOR_SYSFS="ioerr_cnt" fordert udev auf, so lange zu warten, bis die Datei ioerr_cnt erstellt wurde.
OPTIONEN
Der Schlüssel OPTION kann mehrere mögliche Werte haben:
last_rule weist udev an, alle nachfolgenden Regeln zu ignorieren.
ignore_device weist udev an, dieses Ereignis komplett zu ignorieren.
ignore_remove weist udev an, alle späteren Entfernungsereignisse für dieses Gerät zu ignorieren.
all_partitions weist udev an, für alle vorhandenen Partitionen eines Blockgeräts Geräteknoten zu erstellen.
Das dynamische Geräteverzeichnis und die Infrastruktur für die udev-Regeln ermöglichen die Bereitstellung von stabilen Namen für alle Laufwerke unabhängig von ihrer Erkennungsreihenfolge oder der für das Gerät verwendeten Verbindung. Jedes geeignete Blockgerät, das der Kernel erstellt, wird von Werkzeugen mit speziellen Kenntnissen über bestimmte Busse, Laufwerktypen oder Dateisysteme untersucht. Gemeinsam mit dem vom dynamischen Kernel bereitgestellten Geräteknotennamen unterhält udev Klassen permanenter symbolischer Links, die auf das Gerät verweisen:
/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/sys/*
Virtuelles, vom Linux-Kernel bereitgestelltes Dateisystem, das alle zur Zeit bekannten Geräte exportiert. Diese Informationen werden von udev zur Erstellung von Geräteknoten in /dev verwendet.
/dev/*
Dynamisch erstellte Geräteknoten und statische Inhalte, die beim Booten aus /lib/udev/devices/* kopiert werden.
Die folgenden Dateien und Verzeichnisse enthalten die entscheidenden Elemente der udev-Infrastruktur:
/etc/udev/udev.conf
Wichtigste udev-Konfigurationsdatei.
/etc/udev/rules.d/*
udev-Ereigniszuordnungsregeln.
/lib/udev/devices/*
Statischer /dev-Inhalt.
/lib/udev/*
Von den udev-Regeln aufgerufene Helferprogramme.
Weitere Informationen zur udev-Infrastruktur finden Sie auf den folgenden man-Seiten:
Allgemeine Informationen zu udev, Schlüsseln, Regeln und anderen wichtigen Konfigurationsbelangen.
udevadm kann dazu verwendet werden, das Laufzeitverhalten von udev zu kontrollieren, Kernel-Ereignisse abzurufen, die Ereigniswarteschlange zu verwalten und einfache Methoden zur Fehlersuche bereitzustellen.
Informationen zum udev-Ereignisverwaltungs-Daemon.