Differences between revisions 10 and 11
Revision 10 as of 2013-10-24 15:13:50
Size: 10431
Editor: ?JulienGaulmin
Comment: udevadm control (without terminal e)
Revision 11 as of 2013-11-10 22:31:01
Size: 10439
Comment: Sync with English master
Deletions are marked like this. Additions are marked like this.
Line 77: Line 77:
$ udevinfo -a -p $(udevinfo -q path -n /dev/ttyS1) $ udevadm info -a -p $(udevadm info -q path -n /dev/ttyS1)

Traduction(s): English - Français - Italiano - Русский

udev - Gestion dynamique des périphériques avec Linux


udev remplace le Device File System (DevFS) à partir des séries 2.6 du noyau de Linux. Il permet d'identifier, de façon dynamique, les périphériques à partir de leurs propriétés comme l'ID du vendeur et l'ID du périphérique. udev est exécuté dans l'espace utilisateur à la différence de devfs qui était exécuté dans l'espace noyau.

udev permet l'usage de règles pour spécifier quel nom sera donné à un périphérique, quel que soit le port sur lequel il est branché. Par exemple, on peut avoir une règle pour toujours monter un disque dur de marque "iRiver" et de nom "ABC" comme /dev/iriver. Ce "nommage" toujours identique d'un périphériques garantit que des scripts dépendant de l'existence d'un périphérique particulier fonctionnent à tout coup.

Présentation

Le système udev est composé de quelques services du noyau et du démon udevd. Le noyau avertit le démon udevd que tel ou tel événement est arrivé. Le démon udevd est configuré pour répondre aux événements par les actions correspondantes. L'information sur l'événement vient du noyau - les actions se produisent dans l'espace utilisateur. Les réponses aux événements sont configurables dans des "règles".

Le démon udevd, comme les autres démons, est lancé au démarrage grâce à un script init : /etc/rcS.d/udev. Son fichier de configuration est /etc/udev/udev.conf. Les fichiers de règles (qui ne sont rien d'autre qu'une configuration supplémentaire d'udevd) sont dans /etc/udev/rules.d. Tous les fichiers de ce répertoire, dont les noms se terminent par ".rules", sont analysés par ordre alphabétique. Quand le fichier de configuration ou les fichiers de règles sont modifiés, le démon udevd doit être redémarré (ou, comme on le dit plus bas dans cette page, on peut se servir du programme udevadm).

La plupart des fichiers /etc/udev/rules.d sont des liens vers des fichiers situés ailleurs. L'auteur suppose que c'est fait pour que lorsque les fichiers de règles sont modifiés, les fichiers de sauvegarde de l'éditeur ne restent pas dans l'espace des règles où ils pourraient être utilisés au démarrage suivant du démon. Aussi, dans la mesure où les liens peuvent avoir des noms différents des fichiers originaux, ils peuvent être ordonnés sans se soucier du nom qu'ils portent (comme c'est le cas des scripts init).

udev a été créé pour répondre à des événements du type connexion à chaud (hotplug). Il y a beaucoup de documentations qui se réfèrent à la création des références de périphériques en réponse à l'apparition de nouveaux périphériques. Mais udev est plus général ; il peut exécuter des commandes arbitraires de l'espace utilisateur en réponse à l'apparition de nouveaux périphériques ou n'importe quel événement transmis par le noyau.

Les moments où udevd est actif sont :

  1. Au démarrage, il analyse les fichiers de configuration et les fichiers de règles et construit une base de données des règles en mémoire.
  2. Quand un événement se produit, il vérifie sa base de données et effectue les actions appropriées.

Règles

Règles pour les règles :

  1. Chaque règle doit tenir sur une seule ligne (ces lignes peuvent être coupées par un retour à la ligne avec un \ juste avant le retour à la ligne)
  2. Les règles consistent en "correspondances" et "actions"
  3. Correspondances et actions sont des triplets "clé" "opérateur" "valeur" (Key, operator, value)
  4. Les correspondances ont == ou != comme opérateur
  5. Les actions ont = (affectation) comme opérateur
  6. Les correspondances contrôle un ou plusieurs attributs de l'événement pour voir si l'action doit être effectuée
  7. Les actions spécifient ce qui doit se passer
  8. Exemple de correspondance : BUS=="usb"

  9. Exemple d'action : NAME="mydev"

  10. Exemple de règle :

    KERNEL=="sd*[0-9]|dasd*[0-9]", ENV{ID_SERIAL}=="?*", \
            SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
  11. Toutes les règles qui trouvent une correspondance doivent être exécutées
  12. Les premières règles ont la priorité sur les règles suivantes - aussi vous mettrez vos règles de personnalisation parmi les premiers fichiers de la liste rules.d file
  13. Les actions de type key="value" remplacent les autres actions
  14. Les actions de type key+="value" s'ajoutent aux actions exécutées, par exemple SYMLINK+="foo" signifie "en plus des autres liens symboliques, quels qu'ils soient, que vous allez créer pour cet événement, vous allez aussi en créer un appelé foo"

Ensemble de règles

Règles pour les ensembles de règles :

  1. Toutes les règles sont réunies dans un seul espace, néanmoins elles sont réparties en plusieurs fichiers.
  2. L'unique organisation dans l'espace des règles est la possibilité de placer des étiquettes et ensuite de sauter un groupe de règles pendant "la recherche de correspondances entre l'événement et les règles" en sautant en avant avec une action GOTO.

  3. Il y a un autre type de règle appelé "étiquette" : par exemple LABEL="persistent_storage_end" Elles sont utilisée par les règles ordinaires qui ont des actions "GOTO", par exemple :

    ACTION!="add", GOTO="persistent_storage_end"
    Notez qu'avec ce type de règle, le terme ACTION est un attribut d'un événement et est utilisé comme condition pour décider si l'action GOTO action doit être déclenchée.
  4. C'est une bonne idée de limiter la destination du GOTO à l'intérieur du fichier (sinon vous devrez faire attention si vous réordonnez les fichiers).
  5. Evitez les sauts vers une étiquette antérieure (n'essayez pas, mais imaginez que ça pourrait aboutir à une boucle infinie. Peut-être que le code de udev vérifie cela, mais si le code l'ignore (au mieux) pourquoi se tracasser ?)
  6. On peut créer des variables dans l'espace ENV dans une règle et s'y référer dans des règles ultérieures
  7. Il existe une fonction pour créer des règles dynamiques (exemple : voir z45_persistent-net-generator.rules)

Liste noire

Liste noire des modules du noyau

Nom de périphérique permanent

Dans cet exemple, vous voulez faire en sorte que votre carte 3G ait un nom permanent.

1. Connectez la "carte" (ou le périphérique)

2. Exécutez la commande suivante sur le périphérique approprié ;

$ udevadm info --name=/dev/ttyS1 --attribute-walk

Notez que sur les très vieux systèmes, on peut avoir à utiliser plutôt la commande suivante :
$ udevadm info -a -p $(udevadm info -q path -n /dev/ttyS1)

Udevadm démarre par le périphérique spécifié par le devpath puis remonte la chaîne des périphériques parents. Il écrit pour chaque périphérique trouvé, tous les attributs possibles au format des clés des règles de udev. Une règle pour une correspondance peut être composé par les attributs du périphérique et ceux du périphérique parent.

  looking at device '/class/tty/ttyS1':
    KERNEL=="ttyS1"
    SUBSYSTEM=="tty"
    DRIVER==""
    ATTR{dev}=="4:65"

  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0.0':
    KERNELS=="0.0"
    SUBSYSTEMS=="pcmcia"
    DRIVERS=="serial_cs"
    ATTRS{modalias}=="pcmcia:m00A4c1AAFf02fn00pfn00pa32607776pbD9E73B13pcAF9C4D7Fpd00000000"
    ATTRS{prod_id3}=="NRM6831"
    ATTRS{prod_id2}=="Merlin UMTS Modem"
    ATTRS{prod_id1}=="Novatel Wireless"
    ATTRS{card_id}=="0x1aaf"
    ATTRS{manf_id}=="0x00a4"
    ATTRS{func_id}=="0x02"
    ATTRS{pm_state}=="on"
    ATTRS{function}=="0x00"

  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:15:00.0':
    KERNELS=="0000:15:00.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="yenta_cardbus"
    ATTRS{msi_bus}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{enable}=="2"
    ATTRS{numa_node}=="0"
    ATTRS{modalias}=="pci:v00001180d00000476sv000017AAsd000020C6bc06sc07i00"
    ATTRS{local_cpus}=="00000003"
    ATTRS{irq}=="16"
    ATTRS{class}=="0x060700"
    ATTRS{subsystem_device}=="0x20c6"
    ATTRS{subsystem_vendor}=="0x17aa"
    ATTRS{device}=="0x0476"
    ATTRS{vendor}=="0x1180"

  looking at parent device '/devices/pci0000:00/0000:00:1e.0':
    KERNELS=="0000:00:1e.0"
    SUBSYSTEMS=="pci"
    DRIVERS==""
    ATTRS{msi_bus}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{enable}=="1"
    ATTRS{numa_node}=="0"
    ATTRS{modalias}=="pci:v00008086d00002448sv00000000sd00000000bc06sc04i01"
    ATTRS{local_cpus}=="00000003"
    ATTRS{irq}=="0"
    ATTRS{class}=="0x060401"
    ATTRS{subsystem_device}=="0x0000"
    ATTRS{subsystem_vendor}=="0x0000"
    ATTRS{device}=="0x2448"
    ATTRS{vendor}=="0x8086"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""
    ATTRS{uevent}==""

3. Créez un fichier dans /etc/udev/rules.d, habituellement appelé z21_persistent-local.rules.

ATTRS{prod_id2}=="Merlin UMTS Modem", ATTRS{prod_id1}=="Novatel Wireless", SYMLINK+="MerlinUMTS"
##On peut écrire autrement :
# ATTRS{card_id}=="0x1aaf", ATTRS{manf_id}=="0x00a4", SYMLINK+="MerlinUMTS"

4. Forcez une nouvelle exécution des scripts (ou redémarrez ;)

udevadm control --reload-rules
udevadm test -a -p $(udevadm info -q path -n /dev/ttyS1)

Un exemple plus détaillé se trouve dans semu5 dans comp.os.linux.questions. Il y a aussi un guide sur l'écriture des règles udev.

Références


CategorySystemAdministration | CategoryLocalResourcesManagement | CategoryBootProcess