Différences

Ci-dessous, les différences entre deux révisions de la page.

--- udev [Le 07/11/2012, 00:40]
87.88.6.185 [Activez vos règles]
+++ udev [Le 11/09/2022, 11:41] (Version actuelle)
moths-art Suppression des espaces en fin de ligne (détecté et corrigé via le bot wiki-corrector (https://forum.ubuntu-fr.org/viewtopic.php?id=2067892)
@@ Ligne 10: / Ligne 10: @@
 Comme vous l'aurez compris, ceci est un tutoriel sur UDEV. Il est très complet, il explique en détail le fonctionnement de la bête. Je vous conseille de ne pas le lire en diagonale: il contient beaucoup d'informations, toutes nécessaires pour faire fonctionner correctement vos règles.
-En général une règle s'écrit en quelques lignes dans un fichiers ''.rules'', mais nécessite beaucoup de rigueur pour qu'elle fonctionne.
+En général une règle s'écrit en quelques lignes dans un fichiers ''.rules'' qui se trouve dans  /etc/udev/rules.d, mais nécessite beaucoup de rigueur pour qu'elle fonctionne.
 **Donc prenez votre temps pour tout lire jusqu'au bout et comprendre ce que vous faites** !
@@ Ligne 18: / Ligne 18: @@
 ====Terminologie: devfs, sysfs, nodes, etc.====
 Voici une introduction basique.
 Sur les systèmes à base de Linux, le répertoire ''/dev'' sert à contenir les périphériques sous forme de fichier, les "nodes", qui se rapportent aux périphériques système. Chaque "node" se réfère à un périphérique, qui peut -ou pas- exister. Les applications utilisateur peuvent utiliser ces "nodes" pour interagir avec le périphérique. Par exemple, le serveur graphique X va "écouter" ''/dev/input/mice'' qui se réfère à la souris et faire bouger le pointeur à l'écran.
-Le répertoire original ''/dev'' contenait tous les périphériques du système, c'est pourquoi il était si volumineux. **Devfs** a été créé pour simplifier cette utilisation, mais ce système a montré ses limites lorsqu'il y a des problèmes compliqués à résoudre.
+Le répertoire original ''/dev'' contenait tous les fichiers correspondant à tous les périphériques possibles et imaginables que l'on pouvait trouver dans une configuration matérielle. De ce fait, il était très volumineux. **Devfs** a été créé pour simplifier cette utilisation, mais ce système a montré ses limites lorsqu'il y a des problèmes compliqués à résoudre.
 //**Udev**// est le nouveau système pour gérer le répertoire ''/dev'', conçu pour repousser les limites mises en avant par les précédentes versions de ''/dev'', et fournir un lien robuste. Dans le but de créer et nommer les périphériques dans ''/dev'', les "nodes" qui correspondent aux périphériques système, //udev// fait le lien entre les informations données par //sysfs// et les règles données par l'utilisateur. Ce wiki a pour but d'expliquer comment écrire les règles //udev//.
@@ Ligne 30: / Ligne 30: @@
 ====Pourquoi ?====
 Les règles //udev// sont flexibles et très puissantes. Voici quelques exemples de ce que vous pouvez faire :
   * changer le nom assigné par défaut à un périphérique;
-  * donner un nom alternatif/persistant à un périphérique en créant un lien symbolique;
+  * donner un nom alternatif ou permanent à un périphérique en créant un lien symbolique;
   * nommer un périphérique en fonction de la sortie d'un programme;
@@ Ligne 42: / Ligne 42: @@
   * lancer un script quand un périphérique est créé ou supprimé (en général pour un périphérique qui se branche à chaud, comme l'USB);
   * renommer les interfaces réseaux
 L'écriture de règles n'est pas une solution s'il n'existe pas du tout de périphérique "node" pour votre périphérique particulier. S'il n'y a pas de règle, //udev// va créer le périphérique "node" avec le nom donné par défaut par le noyau.
-Il y a plusieurs avantages à avoir un nom de périphérique constant. Supposons que vous ayez deux périphériques USB : une webcam et un clé USB. Ces périphériques sont normalement assignés aux périphériques "nodes" ''/dev/sda'' et ''/dev/sdb'', mais cela dépend de l'ordre dans lequel ils ont été connectés. C'est pourquoi il est plus pratique de nommer les périphériques à chaque fois de la même manière, par exemple ''/dev/camera'' et ''/dev/flashdisk''.
+Il y a plusieurs avantages à avoir un nom de périphérique constant. Supposons que vous ayez deux périphériques USB : une webcam et une clé USB. Ces périphériques sont normalement assignés aux périphériques "nodes" ''/dev/sda'' et ''/dev/sdb'', mais cela dépend de l'ordre dans lequel ils ont été connectés. C'est pourquoi il est plus pratique de nommer les périphériques à chaque fois de la même manière, par exemple ''/dev/camera'' et ''/dev/flashdisk''.
 ====Donner un nom persistant à un périphérique====
@@ Ligne 53: / Ligne 53: @@
 //Udev// fournit un nom persistant pour certains types de périphériques. C'est un dispositif très pratique, qui signifie que vous n'avez pas besoin d'écrire de règle pour ceux-ci.
-Par exemple, //Udev// fournit des noms persistants pour les périphériques de stockage dans le répertoire ''/dev/disk''. Pour les voir, vous pouvez utilisez la commande suivante :
+Par exemple, //Udev// fournit des noms persistants pour les périphériques de stockage dans le répertoire ''/dev/disk''. Pour les voir, vous pouvez utiliser la commande suivante :
 <code>ls -lR /dev/disk</code>
@@ Ligne 63: / Ligne 63: @@
 ====Fichiers de règles et syntaxes====
-Pour décider comment nommer un périphérique et quelles actions faire, //udev// utilise une série de fichiers de règles. Ces fichiers se trouvent dans le répertoire ''/etc/udev/rules.d'', et doivent tous avoir l'extension ''.rules''.
+Pour décider comment nommer un périphérique et quelles actions a faire, //udev// utilise une série de fichiers de règles. Ces fichiers se trouvent dans le répertoire ''/etc/udev/rules.d'', et doivent tous avoir l'extension ''.rules''.
 Les règles //udev// créées par défaut sont dans le fichier ''/lib/udev/rules.d/50-udev-default.rules''. Il pourrait être intéressant d'y jeter un œil – il contient quelques exemples -, et certaines règles contiennent un exemple de sortie de //devfs// que vous trouverez dans ''/dev'' par défaut. Cependant, il est conseillé de ne pas écrire de règle directement dedans.
 Les fichiers de ''/lib/udev/rules.d/'' sont triés par ordre **alphabétique**, et dans certaines circonstances, l'ordre dans lequel ils sont analysés est important. En général, vous voulez que vos propres règles soient prises en compte avant les règles créées par défaut, donc créez votre fichier comme ceci: ''/etc/udev/rules.d/10-local.rules'' (le nombre 10 influe sur l'ordre de prise en compte) et écrivez vos propres règles dans ce fichier.
-Dans un fichier de règles, les lignes commençant par "''#''" sont traitées comme des commentaires. Toutes les autres lignes sont donc considérées comme des règles. Les règles s'écrivent sur une seule ligne (on ne les coupe pas par un passage à la ligne avec //ENTREÉ//).
+Dans un fichier de règles, les lignes commençant par "''#''" sont traitées comme des commentaires. Toutes les autres lignes sont donc considérées comme des règles. Les règles s'écrivent sur une seule ligne (on ne les coupe pas par un passage à la ligne avec //ENTRÉE//).
 Un périphérique peut être contrôlé par plusieurs règles. Ceci peut être avantageux lorsque par exemple, nous écrivons deux règles pour un périphérique, qui donnent un nom différent pour le même périphérique. Les deux règles seront appliquées même si ces règles sont dans des fichiers séparés. Il est important de comprendre que //udev// ne s'interrompt pas quand il trouve une règle, il continue sa recherche et tente d'appliquer chaque règle trouvée.
@@ Ligne 74: / Ligne 74: @@
 ====Syntaxe d'une règle====
 Chaque règle est faite d'un ensemble de //clefs de correspondances// et de //clefs d'assignation//, séparées par des virgules. Les //clefs de correspondances// sont les conditions utilisées pour identifier le périphérique sur lequel la règle agit. **Quand toute la série de ces clefs de correspondance correspond bien au périphérique, alors la règle est appliquée et les actions des clefs d'assignation sont appliquées**. Chaque règle doit se composer d'au moins une clef de correspondance et d'une clef d'assignation.
 Prenons par exemple :
@@ Ligne 97: / Ligne 97: @@
 <code>KERNEL=="hdb", NAME="my_spare_disk"</code>
-Soit la règle : «//pour le périphérique que le noyau à appelé ''hdb'', le renommer en ''my_spare_disk''//». Le périphérique "node" apparaîtra maintenant comme ''/dev/my_spare_disk''.
+Soit la règle : «//pour le périphérique que le noyau a appelé ''hdb'', le renommer en ''my_spare_disk''//». Le périphérique "node" apparaîtra maintenant comme ''/dev/my_spare_disk''.
 <code>KERNEL=="hdb", DRIVER=="ide-disk", SYMLINK+="sparedisk"</code>
@@ Ligne 125: / Ligne 125: @@
 Pour écrire des règles agissant sur plusieurs périphériques similaires, les opérateurs de substitution de //udev// (à la manière de ''printf'') sont très utiles. Vous pouvez inclure simplement ces opérateurs dans n'importe quel assignement dans vos règles, et //udev// les évaluera quand ils seront exécutés.
-Les opérateurs les plus communs sont ''%k'' et ''%n''. ''%k'' est remplacé par le nom que le noyau avait assigné au périphérique, e.g. ''sda3'' pour le périphérique qui apparaîtra par défaut sur ''/dev/sda3''. ''%n'' est remplacé par le numéro que le noyau à assigné au périphérique (pour le périphérique de stockage, c'est le numéro de partition), e.g. ''3'' pour ''/dev/sda3''.
+Les opérateurs les plus communs sont ''%k'' et ''%n''. ''%k'' est remplacé par le nom que le noyau avait assigné au périphérique, e.g. ''sda3'' pour le périphérique qui apparaîtra par défaut sur ''/dev/sda3''. ''%n'' est remplacé par le numéro que le noyau a assigné au périphérique (pour le périphérique de stockage, c'est le numéro de partition), e.g. ''3'' pour ''/dev/sda3''.
 //Udev// fournit d'autres opérateurs de substitution pour créer des fonctions plus avancées que vous pourrez consulter dans l'aide de //udev// (dans une console, tapez ''man udev''). Il y a une syntaxe alternative pour ces opérateurs - ''$kernel'' et ''$number'' pour les exemples précédents. Et si vous voulez utiliser un ''%'' littéral dans une règle, il vous suffira de mettre ''%%''; si vous voulez utiliser un ''$'' littéral dans une règle, mettez ''$$''.
@@ Ligne 136: / Ligne 136: @@
 La première règle assure que le périphérique "node" appelé ''mice'' (pour une souris) apparaîtra exclusivement dans le répertoire ''/dev/input'' (donc ''/dev/input/mice'', au lieu du défaut ''/dev/mice''). La deuxième règle assure que le périphérique "node" ''loop0'' soit créé comme ''/dev/loop/0'', mais crée aussi un lien symbolique ''/dev/loop0'' pour être compatible.
 On peut se demander quel est le véritable intérêt dans le cas de ces deux règles, car elles peuvent être utilisées sans aucun opérateur de substitution. Le véritable intérêt des substitutions va être expliqué dans la section suivante.
 ====Reconnaissance évoluée de noms====
@@ Ligne 153: / Ligne 153: @@
 KERNEL=="hiddev*", NAME="usb/%k"
 </code>
-La première règle est pour les lecteurs de disquette, et assure que tous les périphériques "nodes" seront placés par leur numéro dans le répertoire ''/dev/floppy''.
+La première règle est pour les lecteurs de disquette, elle assure que tous les périphériques "nodes" seront placés par leur numéro dans le répertoire ''/dev/floppy'' et ajoute un lien avec le nom par défaut dans ''/dev/''.
 La seconde règle place tous les périphériques dont le nom commence par ''hiddev'' dans le répertoire ''/dev/usb'' sans modifier le nom que le noyau leur a donné.
@@ Ligne 161: / Ligne 162: @@
 ====Organisation de sysfs====
 L'utilisation de //sysfs// a été brièvement évoquée précédemment. Dans le but d'écrire des règles basées sur ces informations, il vous faut connaître le nom des attributs et leurs valeurs.
 //Sysfs// a une structure très simple. Il est logiquement divisé en répertoires, chacun comportant un certain nombre de fichiers (//attributs//) qui contiennent en général une seule valeur. Certains liens symboliques sont présents, parcourant plusieurs branches de "l'arbre" //sysfs//.
 Certains répertoires sont situés sur les niveaux supérieurs du dispositif. Le niveau supérieur lie d'autres parties de //sysfs// vers le périphérique en question. Les chemins des périphériques du niveau supérieur sont classifiés dans le répertoire //sysfs//, contenant un fichier ''dev''. La commande suivante permet de les lister :
@@ Ligne 246: / Ligne 247: @@
 <code>udevadm info -a -n sda</code>
+====Trouver un périphérique tout juste branché====
+Pour un périphérique USB, tapez la commande suivante :
+  find /dev/bus/usb/ ! -type d -mmin -5
+ou bien la commande :
+  find /sys/devices/ -type d -mmin -5 | grep net/usb.$
+puis faire un **''udevadm info''** sur le résultat :
+<code>$ udevadm info /sys/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0
+P: /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0
+E: DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0
+E: ID_BUS=usb
+E: ID_MM_CANDIDATE=1
+E: ID_MODEL=Sailfish
+E: ID_MODEL_ENC=Sailfish
+E: ID_MODEL_ID=0a02
+E: ID_NET_NAME_MAC=enx827fe191698f
+E: ID_NET_NAME_PATH=enp0s18u1u3
+E: ID_REVISION=0228
+E: ID_SERIAL=Jolla_Sailfish_0123456789
+E: ID_SERIAL_SHORT=0123456789
+E: ID_TYPE=generic
+E: ID_USB_DRIVER=rndis_host
+E: ID_USB_INTERFACES=:e00103:0a0000:
+E: ID_USB_INTERFACE_NUM=00
+E: ID_VENDOR=Jolla
+E: ID_VENDOR_ENC=Jolla
+E: ID_VENDOR_FROM_DATABASE=Advanced Micro Devices, Inc.
+E: ID_VENDOR_ID=2931
+E: IFINDEX=29
+E: INTERFACE=usb0
+E: SUBSYSTEM=net
+E: USEC_INITIALIZED=275352985
+</code>
+Autre méthode plus rapide mais plus compliquée à comprendre, tapez la commande suivante puis brancher et débrancher le périphérique :
+<code>
+$ udevadm monitor --prop --udev | egrep "DEVNAME=|DEVPATH=|ID_MODEL=|ID_SERIAL|ID_VENDOR=|SUBSYSTEM="
+DEVNAME=/dev/bus/usb/001/004
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3
+ID_MODEL=Sailfish
+ID_SERIAL=Jolla_Sailfish_0123456789
+ID_SERIAL_SHORT=0123456789
+ID_VENDOR=Jolla
+SUBSYSTEM=usb
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0
+SUBSYSTEM=usb
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.1
+SUBSYSTEM=usb
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0
+ID_MODEL=Sailfish
+ID_SERIAL=Jolla_Sailfish_0123456789
+ID_SERIAL_SHORT=0123456789
+ID_VENDOR=Jolla
+SUBSYSTEM=net
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0/queues/tx-0
+SUBSYSTEM=queues
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0/queues/rx-0
+SUBSYSTEM=queues
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0/queues/rx-0
+SUBSYSTEM=queues
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0/queues/tx-0
+SUBSYSTEM=queues
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.1
+SUBSYSTEM=usb
+DEVPATH=/devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3:1.0/net/usb0
+ID_MODEL=Sailfish
+</code>
 ====Méthodes Alternatives====
@@ Ligne 351: / Ligne 417: @@
 </code>
 On peut maintenant faire une règle comme celle-ci :
 <code>BUS=="usb", ATTR{serial}=="L72010011070626380", SYMLINK+="epson_680"</code>
@@ Ligne 359: / Ligne 425: @@
 ====Appareil photo USB====
 Comme la plupart des appareils photo, mon appareil photo est identifié comme un disque dur externe branché en USB, utilisant le transport SCSI. Pour accéder à ses photos, on monte le périphérique et on copie les images sur son disque dur.
 Tous les appareils photo ne fonctionnent pas forcément avec cette méthode : certains utilisent un protocole non-storage comme les appareils photo supportés par [[http://www.gphoto.org/|gphoto2]].
@@ Ligne 381: / Ligne 447: @@
 Notre règle va donc devoir différencier les deux. Pour résoudre ceci, vous devez chercher ce qui diffère entre ''sdb'' et ''sdb1''. C'est étonnement simple : seul le nom diffère, donc nous pouvons utiliser une règle simple sur le champ ''NAME''.
 Ma règle est alors :
 <code>KERNEL=="sd?1", BUS=="scsi", ATTR{model}=="X250,D560Z,C350Z", SYMLINK+="camera"</code>
@@ Ligne 394: / Ligne 460: @@
 <code>BUS=="usb", KERNEL=="sd*", ATTR{product}=="USB 2.0 Storage Device", NAME="%k", SYMLINK+="usbhd%n"</code>
 Cette règle crée des liens symboliques comme ceci :
    * ''/dev/usbhd'' – Le périphérique pour ''fdisk'';
@@ Ligne 402: / Ligne 468: @@
 ====Lecteurs de carte USB====
 Les Lecteurs de carte USB (//CompactFlash//, //SmartMedia//, etc.) sont encore un autre type de périphériques de stockage USB, avec un usage différent.
 Ces périphériques n'informent pas l'ordinateur hôte lors d'un changement de média. Ainsi, si vous connectez le périphérique sans carte, puis que vous y insérez une carte, l'ordinateur ne va pas le détecter et vous n'aurez pas accès à la partition de votre carte.
@@ Ligne 413: / Ligne 479: @@
 ====Palm USB====
-Ces périphériques se déclarent comme des ports série USB, donc par défaut vous n'aurez que le périphérique ''ttyUSB1''. Les utilitaires pour //palm// cherchent en général ''/dev/pilot'', nombre d'utilisateurs apprécieront q'une règle gère cela. [[http://www.clasohm.com/blog/one-entry?entry%5fid=12096|Le post du blog de Carsten Clasohm]] propose une solution, voici la règle qu'il suggère :
+Ces périphériques se déclarent comme des ports série USB, donc par défaut vous n'aurez que le périphérique ''ttyUSB1''. Les utilitaires pour //palm// cherchent en général ''/dev/pilot'', nombre d'utilisateurs apprécieront qu'une règle gère cela. [[http://www.clasohm.com/blog/one-entry?entry%5fid=12096|Le post du blog de Carsten Clasohm]] propose une solution, voici la règle qu'il suggère :
 <code>BUS=="usb", ATTR{product}=="Palm Handheld*", KERNEL=="ttyUSB[1359]", SYMLINK+="pilot"</code>
@@ Ligne 432: / Ligne 498: @@
 Etant référencées par leur noms, les interfaces réseau n'ont par défaut pas de périphérique "node" attribué. L'écriture de règles reste cependant identique.
 Il est logique d'utiliser simplement l'adresse MAC de votre interface dans la règle, puisque celle-ci est unique. Cependant, soyez certain d'utiliser l'adresse MAC exacte, telle que montrée par //udevadm info//, sinon votre règle ne fonctionnera pas.
 <code> udevadm info -a -p /sys/class/net/eth0
@@ Ligne 482: / Ligne 548: @@
 Si vous êtes sur un noyau avec le support //inotify//, //udev// surveillera votre répertoire de règles et prendra en compte automatiquement les modifications faites dans vos règles.
 A l'encontre de ceci, **//udev// ne remontera pas automatiquement les périphériques, mais tentera d'appliquer les règles**. Par exemple, si vous écrivez une règle pour ajouter un lien symbolique pour votre appareil photo alors que celui-ci est déjà branché au PC, ne vous attendez pas à ce que le lien symbolique soit créé.
-Pour créer le lien symbolique, vous pouvez simplement débrancher et rebrancher votre appareil photo. Dans le cas où le périphérique ne peut pas être débranché, vous pouvez lancer dans une console la commande ''udevtrigger''.
+Pour créer le lien symbolique, vous pouvez simplement débrancher et rebrancher votre appareil photo. Si le périphérique ne peut pas être débranché, vous pouvez lancer dans une console la commande ''udevadm trigger''.
-Si votre noyau n'a pas le support //inotify//, les nouvelles règles ne seront pas détectées automatiquement. Dans ce cas, vous devrez demander la relecture de celles-ci en lançant dans une console la commande ''udevcontrol reload_rules'' après avoir créé ou modifié une règle pour que cela prenne effet.
+Si votre noyau n'a pas le support //inotify//, les nouvelles règles ne seront pas détectées automatiquement. Dans ce cas, vous devrez demander la relecture de celles-ci en lançant dans une console la commande ''sudo udevadm control --reload'' après avoir créé ou modifié une règle pour que cela prenne effet.
 ====udevtest====
@@ Ligne 501: / Ligne 567: @@
 Notez que le préfixe ''/sys'' a été supprimé des arguments de la ligne de commande de ''udevtest'', la raison étant que //udev// opère sur le chemin du périphérique. Notez aussi que //udevtest// est juste un outil de test/debug, cela ne créera pas de périphérique, contrairement à ce que //udevtest// vous dit (c'est une simulation) !
-Dans le cas où udevtest ne fonctionnerait pas, il est aussi possible d'utiliser udevadm comme suivant (pour l'exemple, votre périphérique est un disque dur externe qui se nomme sdb) :
+Dans le cas où //udevtest// ne fonctionnerait pas, il est aussi possible d'utiliser //udevadm// comme dans l'exemple suivant (où le périphérique est un disque dur externe qui se nomme sdb) :
 <code>
 udevadm test /sys/block/sdb
 </code>
 =====Auteur et contact=====
 [[http://www.reactivated.net/writing_udev_rules.html|Ce document a été rédigé originellement en anglais]] par Daniel Drake <dan@reactivated.net> et traduit par [[utilisateurs:Acp]]. Les retours en anglais sont appréciés par Daniel Drake :) et modifié par la suite.
 Pour le support, envoyez un mail (en anglais) à la mailing liste de linux hotplug : <linux-hotplug-devel@lists.sourceforge.net>.
 Copyright (C) 2003-2006 Daniel Drake.