Hauptseite
Programmierung & Skripten
Tutorial zum Schreiben von grundlegenden Udev -Regeln unter Linux

Programmierung & Skripten

Tutorial zum Schreiben von grundlegenden Udev -Regeln unter Linux

1482
386
Ilja Köpernick

Zielsetzung

Verständnis der Basiskonzepte hinter Udev und lernen, wie man einfache Regeln schreibt

Anforderungen

Wurzelberechtigungen

Schwierigkeit

MITTEL

Konventionen

# - Erfordert, dass gegebene Linux -Befehle entweder mit Root -Berechtigungen ausgeführt werden müssen
direkt als Stammbenutzer oder durch Verwendung von sudo Befehl
$ - Erfordert, dass die angegebenen Linux-Befehle als regelmäßiger nicht privilegierter Benutzer ausgeführt werden können

Einführung

In einem GNU/Linux -System wird die Verwaltung von Ereignissen, die mit ihnen im Zusammenhang mit ihnen im Zusammenhang mit ihnen in Verbindung gebracht werden Udev, und genauer von der Udevd Dämon. Das Lernen, wie man Regeln schreibt, die auf das Auftreten dieser Ereignisse angewendet werden können, kann wirklich nützlich sein, um das Verhalten des Systems zu ändern und es an unsere Bedürfnisse anzupassen.

Wie Regeln organisiert sind

UDEV -Regeln werden in Dateien mit dem definiert .Regeln Verlängerung. Es gibt zwei Hauptstandorte, an denen diese Dateien platziert werden können: /usr/lib/Udev/Regeln.D Es ist das Verzeichnis, das für systeminstallierte Regeln verwendet wird, /etc/udev/Regeln.D/ ist für maßgefertigte Regeln reserviert.

Die Dateien, in denen die Regeln definiert sind, werden konventionell mit einer Nummer als Präfix bezeichnet (e.G 50-udev-Default.Regeln) und werden unabhängig von dem Verzeichnis, in dem sie sich befinden, in lexikalischer Reihenfolge verarbeitet. Dateien installiert in /etc/udev/Regeln.D, Überschreiben Sie jedoch diejenigen mit demselben Namen, die im System Standard -Pfad installiert sind.

Die Regelnsyntax

Die Syntax der Udev -Regeln ist nicht sehr kompliziert, wenn Sie die Logik dahinter verstanden haben. Eine Regel besteht aus zwei Hauptabschnitten: dem "Match" -Teil, in dem wir die Bedingungen für die Anwendung der Regel definieren, wobei eine Reihe von Schlüssel verwendet werden Art der Handlung, wenn die Bedingungen erfüllt sind.

Ein Testfall

Was für eine bessere Möglichkeit, mögliche Optionen zu erklären, als eine tatsächliche Regel zu konfigurieren? Als Beispiel werden wir eine Regel definieren, um das Touchpad zu deaktivieren, wenn eine Maus verbunden ist. Offensichtlich spiegeln die in der Regeldefinition angegebenen Attribute meine Hardware wider.

Wir werden unsere Regel in die schreiben /etc/udev/Regeln.D/99-Togglemouse.Regeln Datei mit Hilfe unseres bevorzugten Texteditors. Eine Regeldefinition kann sich über mehrere Zeilen erstrecken, aber wenn dies der Fall ist, muss vor dem Newline -Zeichen ein Backslash als Zeilen -Fortsetzung verwendet werden, genau wie in Shell -Skripten. Hier ist unsere Regel:

Action == "add" \, attrs idproduct == "c52f" \, attrs idvendor == "046d" \, env display = ": 0" \, env xAuthority = "/run/ Benutzer/1000/gdm/xAuthority "\, run+="/usr/bin/xinput -disable 16 "

Lassen Sie es uns analysieren.

Betreiber

Zunächst eine Erklärung der verwendeten und möglichen Operatoren:

== und != Operatoren

Der == ist der Gleichstellungsoperator und der != ist der Ungleichheitsoperator. Durch die Verwendung der Verwendung stellen wir fest, dass die definierten Schlüssel, damit die Regel angewendet wird, übereinstimmen oder nicht mit dem definierten Wert übereinstimmen muss.

Die Zuordnungsoperatoren: = und: =

Der = Zuweisungsoperator wird verwendet, um den Schlüssel einen Wert zuzuweisen, der einen akzeptiert. Wir benutzen das : = Der Bediener, wenn wir einen Wert zuweisen und sicherstellen möchten, dass er nicht von anderen Regeln überschrieben wird: Die mit diesem Bediener zugewiesenen Werte können nicht geändert werden.

Die += und -= Operatoren

Der += Und -= Operatoren werden jeweils verwendet, um einen Wert aus der Liste der für einen bestimmten Schlüssel definierten Werte hinzuzufügen oder zu entfernen.

Die Schlüssel, die wir benutzt haben

Lassen Sie uns nun die Schlüssel analysieren, die wir in der Regel verwendet haben. Erstens haben wir das AKTION Schlüssel: Durch die Verwendung haben wir angegeben, dass unsere Regel angewendet werden soll, wenn ein bestimmtes Ereignis für das Gerät auftritt. Gültige Werte sind hinzufügen, entfernen Und ändern

Wir haben dann das benutzt Attrs Schlüsselwort, um ein Attribut anzugeben, das übereinstimmt. Wir können ein Geräteattribute mithilfe der auflisten Udevadm Info Befehl, den Namen bereitgestellt oder sysfs Weg:

Udevadm Info -AP/Geräte/PCI0000: 00/0000: 00: 1D.0/USB2/2-1/2-1.2/2-1.2: 1.1/0003: 046D: C52F.0010/input/input39 Udevadm Info startet mit dem vom DevPath angegebenen Gerät und steigt dann die Kette der übergeordneten Geräte hinauf. Es druckt für jedes gefundene Gerät, alle möglichen Attribute im UDEV -Regelnschlüsselformat. Eine zu übereinstimmende Regel kann durch die Attribute des Geräts und die Attribute eines einzigen übergeordneten Geräts komponiert werden. Betrachten Sie Geräte/Geräte/PCI0000: 00/0000: 00: 1D.0/USB2/2-1/2-1.2/2-1.2: 1.1/0003: 046D: C52F.0010/input/input39 ': kernel == "input39" subsystem == "Eingabe" Driver == "" attr name == "Logitech USB-Empfänger" Attr Phys == "USB-0000: 00: 1D.0-1.2/input1 "Attr.0/USB2/2-1/2-1.2/2-1.2: 1.1/0003: 046D: C52F.0010 ': kernel == "0003: 046d: c52f.0010 "Subsysteme ==" HID "Treiber ==" HID-Generic "Attrs Country ==" 00 "betrachtet das übergeordnete Gerät '/devices/pci0000: 00/0000: 00: 1d.0/USB2/2-1/2-1.2/2-1.2: 1.1 ': Kerne == "2-1.2: 1.1 "subsystems ==" USB "TRIFERS ==" USBHID "attrs autorisiert ==" 1 "attrs balternatesetting ==" 0 "attr Attrs BinterfaceProtocol == "00" Attrs BinterFaCesUbClass == "00" Attrs Bnumendpoints == "01" Attrs Supports_autosuspend == "1" und übergeordnete Geräte '/Venture/pci0000: 00000000000000000000: 0000000000: 00: 1d.0/USB2/2-1/2-1.2 ': Kerne == "2-1.2 "subsystems ==" USB "treiber ==" USB "attrs autorisiert ==" 1 "attrs meide_reset_quirk ==" 0 "attrs bconfigurationValue ==" 1 "attr ATTRSbDeviceProtocol=="00" ATTRSbDeviceSubClass=="00" ATTRSbMaxPacketSize0=="8" ATTRSbMaxPower=="98mA" ATTRSbNumConfigurations=="1" ATTRSbNumInterfaces= = "2" attrs bcdDevice == "3000" attrs bmattributes == "a0" attrs busnum == "2" attrs configuration == "rqr30.00_B0009 "attrs devnum ==" 12 "attrs devPath ==" 1.2 "attrs idProduct ==" C52F "attrs idvendor ==" 046D "attrs ltm_capable ==" no "attrs Hersteller ==" logitech "attrs maxchild ==" 0 "attr  == "USB -Empfänger" attrs Quirks == "0x0" attr 2.00 "[…]

Oben ist die abgeschnittene Ausgabe, die nach dem Ausführen des Befehls empfangen wird. Wie Sie es aus der Ausgabe selbst lesen können, Udevadm beginnt mit dem angegebenen Pfad, den wir zur Verfügung gestellt haben, und gibt uns Informationen zu allen übergeordneten Geräten. Beachten Sie, dass Attribute des Geräts in singulärer Form (e) angegeben werden.G Kernel), während die Eltern in Pluralform (e.G Kerne). Die übergeordneten Informationen können Teil einer Regel sein, aber nur einer der Eltern kann jeweils referenziert werden: Das Mischen von Attributen verschiedener übergeordneter Geräte funktioniert nicht. In der oben definierten Regel haben wir die Attribute eines übergeordneten Geräts verwendet: Idprodukt Und idvendor.

Das nächste, was wir in unserer Regel getan haben, ist, die zu verwenden Env Schlüsselwort: Es kann verwendet werden, um Umgebungsvariablen sowohl festzulegen als auch zu versuchen. Wir haben dem einen Wert zugewiesen ANZEIGE Und XAUTHORITY Einsen. Diese Variablen sind wichtig, wenn Sie programmatisch mit dem X -Server interagieren, um einige benötigte Informationen einzurichten: mit dem ANZEIGE Variable geben wir an, auf welchen Computer der Server ausgeführt wird, auf welchen Anzeige und auf welchen Bildschirm wir verweisen und mit XAUTHORITY Wir bieten den Pfad zur Datei, die die XORG -Authentifizierung und Autorisierungsinformationen enthält. Diese Datei befindet sich normalerweise im Verzeichnis „Home“ der Benutzer.

Endlich haben wir das benutzt LAUFEN Schlüsselwort: Dies wird verwendet, um externe Programme auszuführen. Sehr wichtig: Dies wird nicht sofort ausgeführt, aber die verschiedenen Aktionen werden ausgeführt, sobald alle Regeln analysiert wurden. In diesem Fall haben wir die verwendet Xinput Nützlichkeit, um den Status des Touchpads zu ändern. Ich werde hier nicht die Syntax von XInput erklären, sie wäre nicht mehr als 16 ist die ID des Touchpads.

Sobald unsere Regel festgelegt ist, können wir sie debuggen, indem wir die verwenden Udevadm -Test Befehl. Dies ist nützlich für das Debuggen, aber es wird nicht wirklich die Befehle ausgeführt, die mit dem angegeben wurden LAUFEN Taste:

$ udevadm test --Action = "add"/devices/pci0000: 00/0000: 00: 1d.0/USB2/2-1/2-1.2/2-1.2: 1.1/0003: 046D: C52F.0010/input/input39

Was wir dem Befehl zur Verfügung gestellt haben, ist die zu simulieren --Aktion Option und der SYSFS -Pfad des Geräts. Wenn keine Fehler gemeldet werden, sollte unsere Regel gut zu gehen sein. Um es in der realen Welt zu führen, müssen wir die Regeln neu laden:

# Udevadm Steuer

Dieser Befehl lädt die Regelndateien jedoch nur auf neue generierte Ereignisse aus.

Wir haben die grundlegenden Konzepte und Logik gesehen. Die Udev-Manpage bietet eine umfassende Liste.