Zelfstudie over het schrijven van basisregels voor udev in Linux

  • Eustace Evans
  • 0
  • 1372
  • 199
>

Doelstelling

De basisconcepten achter udev begrijpen en leren hoe u eenvoudige regels schrijft

Voorwaarden

  • Root-machtigingen

Moeilijkheidsgraad

MEDIUM

Conventies

  • # - vereist dat gegeven linux-commando's worden uitgevoerd met root-privileges, hetzij direct als rootgebruiker, hetzij door gebruik van sudo opdracht
  • $ - vereist dat gegeven linux-commando's worden uitgevoerd als een gewone niet-geprivilegieerde gebruiker

Invoering

In een GNU / Linux-systeem, terwijl ondersteuning op laag niveau van apparaten op kernelniveau wordt afgehandeld, wordt het beheer van daaraan gerelateerde gebeurtenissen beheerd in gebruikersruimte door udev, en meer precies door de udevd demon. Leren schrijven van regels die moeten worden toegepast op het optreden van die gebeurtenissen kan erg nuttig zijn om het gedrag van het systeem te wijzigen en aan te passen aan onze behoeften.

Hoe regels zijn georganiseerd

Udev-regels worden gedefinieerd in bestanden met de extensie .reglement uitbreiding. Er zijn twee hoofdlocaties waar die bestanden kunnen worden geplaatst: /usr/lib/udev/rules.d het is de map die wordt gebruikt voor door het systeem geïnstalleerde regels, /etc/udev/rules.d/ is gereserveerd voor op maat gemaakte regels.
De bestanden waarin de regels zijn gedefinieerd, worden conventioneel genoemd met een nummer als voorvoegsel (bijv 50-udev-default.rules) en worden verwerkt in lexicale volgorde, onafhankelijk van de directory waarin ze zich bevinden. Bestanden geïnstalleerd in /etc/udev/rules.d, overschrijf echter degene met dezelfde naam die in het standaardpad van het systeem zijn geïnstalleerd.

De syntaxis van de regels

De syntaxis van udev-regels is niet erg ingewikkeld als je de logica erachter begrijpt. Een regel bestaat uit twee hoofdgedeelten: het "match" -gedeelte, waarin we de voorwaarden definiëren voor de regel die moet worden toegepast, met behulp van een reeks sleutels gescheiden door een komma, en het "action" -gedeelte, waarin we enkele soort actie, als aan de voorwaarden is voldaan.

Een testcase

Wat is een betere manier om mogelijke opties uit te leggen dan door een daadwerkelijke regel te configureren? Als voorbeeld gaan we een regel definiëren om het touchpad uit te schakelen wanneer een muis is aangesloten. Het is duidelijk dat de attributen die in de regeldefinitie worden verstrekt, mijn hardware weerspiegelen.
We zullen onze regel in de /etc/udev/rules.d/99-togglemouse.rules bestand met behulp van onze favoriete teksteditor. Een regeldefinitie kan zich over meerdere regels uitstrekken, maar als dat het geval is, moet een backslash worden gebruikt vóór het newline-teken, als een regelvervolging, net als in shellscripts. Hier is onze regel:
 ACTION == "add" \, ATTRS idProduct == "c52f" \, ATTRS idVendor == "046d" \, ENV DISPLAY = ": 0" \, ENV XAUTHORITY = "/ run / user / 1000 / gdm / Xauthority "\, RUN + =" / usr / bin / xinput --disable 16 " 
Laten we het analyseren.

Operatoren

Allereerst een uitleg van de gebruikte en mogelijke operators:

== en! = operators

De == is de gelijkheidsoperator en de != is de ongelijkheidsoperator. Door ze te gebruiken, stellen we vast dat voor de regel die moet worden toegepast, de gedefinieerde sleutels respectievelijk moeten overeenkomen of niet overeenkomen met de gedefinieerde waarde.

De toewijzingsoperatoren: = en: =

De = toewijzingsoperator, wordt gebruikt om een ​​waarde toe te wijzen aan de sleutels die er een accepteren. Wij gebruiken de : = operator, in plaats daarvan, wanneer we een waarde willen toewijzen en we willen ervoor zorgen dat deze niet wordt overschreven door andere regels: de waarden die met deze operator zijn toegewezen, kunnen in feite niet worden gewijzigd.

De operatoren + = en - =

De += en -= operatoren worden gebruikt om respectievelijk een waarde toe te voegen of te verwijderen uit de lijst met waarden die voor een specifieke sleutel zijn gedefinieerd.

De sleutels die we hebben gebruikt

Laten we nu de sleutels analyseren die we in de regel hebben gebruikt. Allereerst hebben we de ACTIE key: door het te gebruiken, hebben we gespecificeerd dat onze regel moet worden toegepast wanneer een specifieke gebeurtenis plaatsvindt voor het apparaat. Geldige waarden zijn toevoegen, verwijderen en verandering
We hebben toen de ATTRS trefwoord om een ​​attribuut op te geven dat moet worden vergeleken. We kunnen de kenmerken van een apparaat weergeven door de udevadm info commando, met de naam of sysfs pad:
 udevadm info -ap /devices/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 begint met het apparaat gespecificeerd door het devpath en loopt vervolgens door de keten van bovenliggende apparaten. Het drukt voor elk gevonden apparaat alle mogelijke attributen af ​​in het udev-regelsleutelformaat. Een regel die overeenkomt, kan worden samengesteld door de attributen van het apparaat en de attributen van één enkel ouderapparaat. kijken naar apparaat '/devices/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 == "input" DRIVER == "" ATTR name == "Logitech USB-ontvanger" ATTR phys == "usb-0000: 00: 1d.0-1.2 / input1" ATTR eigenschappen  == "0" ATTR uniq == "" kijken naar bovenliggend apparaat '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1/ 0003: 046D: C52F.0010 ': KERNELS == "0003: 046D: C52F.0010" SUBSYSTEMS == "hid" DRIVERS == "hid-generiek" ATTRS country == "00" kijken naar ouderapparaat' / devices / pci0000: 00/0000: 00: 1d.0 / usb2 / 2-1 / 2-1.2 / 2-1.2: 1.1 ': KERNELS == "2-1.2: 1.1" SUBSYSTEMEN == "usb" DRIVERS == "usbhid" ATTRS geautoriseerd == "1" ATTRS bAlternateSetting == "0" ATTRS bInterfaceClass == "03" ATTRS bInterfaceNumber == "01" ATTRS bInterfacePr == "00" ATTRS  bInterfaceSubClass == "00" ATTRS bNumEndpoints == "01" ATTRS supports_autosuspend == "1" kijkt naar het ouderapparaat '/devices/pci0000:00/0000:00:1d.0/usb2/2-1 /2-1.2 ': KERNELS == "2-1.2" SUBSYSTEMEN == "usb" DRIVERS == "usb" ATTRS geautoriseerd == "1" ATTRS avo_reset_quirk == "0" ATTRS bConfigurationValue == "1" ATTRS bDeviceClass == "00" ATTRS bDeviceProtocol == "00" ATTRS bDeviceSubClass == "00" ATTRS  bMaxPacketSize0 == "8" ATTRS bMaxPower == "98mA" ATTRS bNumConfigurations == "1" ATTRS bNumInterfaces == "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 manufacturer == "Logitech" ATTRS maxchild == "0" ATTRS product == "USB-ontvanger" ATTRS quirks = = "0x0" ATTRS verwijderbare == "verwijderbare" ATTRS speed == "12" ATTRS urbnum == "1401" ATTRS versie == "2.00" […] 


Hierboven ziet u de afgekapte uitvoer die wordt ontvangen na het uitvoeren van de opdracht. Zoals je kunt lezen uit de output zelf, udevadm begint met het opgegeven pad dat we hebben opgegeven en geeft ons informatie over alle bovenliggende apparaten. Merk op dat attributen van het apparaat in enkelvoud worden gerapporteerd (bijv KERNEL), terwijl de bovenliggende in meervoudsvorm (bijv KERNELS). De bovenliggende informatie kan deel uitmaken van een regel, maar er kan slechts naar één van de ouders tegelijk worden verwezen: het combineren van attributen van verschillende bovenliggende apparaten zal niet werken. In de regel die we hierboven hebben gedefinieerd, hebben we de kenmerken van één ouderapparaat gebruikt: idProduct en idVendor.
Het volgende dat we in onze regel hebben gedaan, is het gebruiken van de ENV trefwoord: het kan worden gebruikt om omgevingsvariabelen in te stellen of te proberen overeen te komen. We hebben een waarde toegekend aan de SCHERM en XAUTHORITY degenen. Deze variabelen zijn essentieel bij het programmatisch communiceren met de X-server om de benodigde informatie in te stellen: met de SCHERM variabele, specificeren we op welke computer de server draait, naar welk scherm en naar welk scherm we verwijzen, en met XAUTHORITY we bieden het pad naar het bestand dat Xorg-authenticatie- en autorisatie-informatie bevat. Dit bestand bevindt zich meestal in de "home" -map van de gebruiker.
Ten slotte hebben we de RENNEN trefwoord: dit wordt gebruikt om externe programma's uit te voeren. Heel belangrijk: dit wordt niet onmiddellijk uitgevoerd, maar de verschillende acties worden uitgevoerd zodra alle regels zijn geparseerd. In dit geval hebben we de xinput hulpprogramma om de status van het touchpad te wijzigen. Ik zal de syntaxis van xinput hier niet uitleggen, het zou niet in verband staan, merk dat maar op 16 is de id van het touchpad.
Zodra onze regel is ingesteld, kunnen we deze debuggen door de udevadm-test opdracht. Dit is handig voor foutopsporing, maar het voert niet echt opdrachten uit die zijn opgegeven met de RENNEN sleutel:
$ 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
Wat we aan de opdracht hebben verstrekt, is de actie die moet worden gesimuleerd met behulp van de --actie optie en het sysfs-pad van het apparaat. Als er geen fouten worden gerapporteerd, zou onze regel goed moeten zijn. Om het in de echte wereld uit te voeren, moeten we de regels opnieuw laden:
# udevadm control - herladen
Deze opdracht laadt de regelbestanden opnieuw, maar heeft alleen effect op nieuw gegenereerde gebeurtenissen.
We hebben de basisconcepten en logica gezien die worden gebruikt om een ​​udev-regel te maken, maar we hebben alleen maar de oppervlakte van de vele opties en mogelijke instellingen bekrast. De manpage van udev biedt een uitputtende lijst: raadpleeg deze pagina voor meer diepgaande kennis.



Niemand heeft nog op dit artikel gereageerd.

Een verzameling nuttige informatie over het Linux-besturingssysteem en nieuwe technologieën
Nieuwe artikelen, praktische tips, gedetailleerde recensies en handleidingen. Voel je thuis in de wereld van het Linux-besturingssysteem