Différences

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

--- udev [Le 19/03/2011, 15:05]
79.132.253.34 [Règles basiques]
+++ 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 correspondent 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.
+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 94: / Ligne 94: @@
   * ''SYMLINK'' - **liste** des liens symboliques, ceux-ci étant les noms alternatifs pour le périphérique.
-Comme il a été dit au début, //udev// crée un seul vrai périphérique "node" pour un périphérique. Si vous souhaitez fournir plusieurs noms pour ce périphérique, utilisez le lien symbolique. Avec l'assignation ''SYMLINK'', vous créez une liste de liens symboliques, qui pointent vers le périphérique "node". Pour utiliser cette liste de liens, nous introduisons un nouvel opérateur ''+='', qui permet d'ajouter des éléments à la liste. Vous pouvez utiliser plusieurs noms sur la liste quelque soit la règle en les séparant par un espace.
+Comme il a été dit au début, //udev// crée un seul vrai périphérique "node" pour un périphérique. Si vous souhaitez fournir plusieurs noms pour ce périphérique, utilisez le lien symbolique. Avec l'assignation ''SYMLINK'', vous créez une liste de liens symboliques, qui pointent vers le périphérique "node". Pour utiliser cette liste de liens, nous introduisons un nouvel opérateur ''+='', qui permet d'ajouter des éléments à la liste. Vous pouvez utiliser plusieurs noms sur la liste quelle que soit la règle en les séparant par un espace.
 <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 108: / Ligne 108: @@
 ====Les attributs de sysfs====
-Les clef introduites précédemment semblent avoir des possibilités limitées. Cependant, vous pouvez avoir besoin d'un contrôle plus précis : pour identifier un périphérique par le numéro du //vendor//, le nom exact du produit, le numéro de série, la capacité de stockage, le nombre de partitions, etc.
+Les clefs introduites précédemment semblent avoir des possibilités limitées. Cependant, vous pouvez avoir besoin d'un contrôle plus précis : pour identifier un périphérique par le numéro du //vendor//, le nom exact du produit, le numéro de série, la capacité de stockage, le nombre de partitions, etc.
 Certains pilotes exportent ces informations dans le //sysfs//, et //udev// vous permet d'utiliser ces informations pour vos propres règles, à l'aide de la clé ''ATTR'' par syntaxe particulière.
@@ 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é 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.
+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 contient 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//.
+//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 :
 <code>find /sys -name dev</code>
@@ Ligne 170: / Ligne 171: @@
 Par exemple, sur un système, le répertoire ''/sys/block/sda'' peut être le chemin du périphérique du disque dur (fourni par la commande "udevadm info -q path -n /dev/sda"). Il est lié au contrôleur sur lequel celui-ci est connecté avec le lien symbolique ''/sys/block/sda/device/'', qui en même temps est lié au pilote du périphérique avec le lien symbolique ''/sys/block/sda/device/driver/''.
-Quand vous écrivez des règles basées sur les informations de //sysfs//, vous devez simplement remplacer les attributs par ceux trouvés dans ces fichiers. Par exemple, on peux lire la taille du disque dur avec :
+Quand vous écrivez des règles basées sur les informations de //sysfs//, vous devez simplement remplacer les attributs par ceux trouvés dans ces fichiers. Par exemple, on peut lire la taille du disque dur avec :
 <code>cat /sys/block/sda/size
 234441648</code>
-On peut donc utiliser dans une règle //udev// ''ATTR{size}=="234441648"'' pour identifier ce disque. Comme //udev// fait une recherche dans toute la branche du périphérique, on peux aussi choisir d'afficher une autre partie de cette branche (e.g. ''attributes'' dans ''/sys/class/block/sda/device/''). Cependant il y a d'autres choses à prendre en considération quand on utilise d'autres parties de la branche, comme cela est décrit plus loin.
+On peut donc utiliser dans une règle //udev// ''ATTR{size}=="234441648"'' pour identifier ce disque. Comme //udev// fait une recherche dans toute la branche du périphérique, on peut aussi choisir d'afficher une autre partie de cette branche (e.g. ''attributes'' dans ''/sys/class/block/sda/device/''). Cependant il y a d'autres choses à prendre en considération quand on utilise d'autres parties de la branche, comme cela est décrit plus loin.
 Bien que cela serve d'introduction utile pour la structure du //sysfs// et pour comprendre le fonctionnement de //udev//, le changement avec //sysfs// est souvent une perte de temps qui n'est donc pas nécessaire.
@@ Ligne 216: / Ligne 217: @@
 </code>
-Comme vous pouvez le voir, ''udevadm info'' renvoie une liste d'informations que vous pouvez utiliser dans vos règles //udev//. Avec l'exemple précédant on peux créer deux règles pour ce périphérique :
+Comme vous pouvez le voir, ''udevadm info'' renvoie une liste d'informations que vous pouvez utiliser dans vos règles //udev//. Avec l'exemple précédant on peut créer deux règles pour ce périphérique :
 <code>
@@ Ligne 224: / Ligne 225: @@
 </code>
-Dans ces exemple, vous avez pu voir la **séparation des informations** (''type 1'' et ''type 2''), car vous **ne** pouvez **pas** mélanger ces informations dans une règle, sinon elle ne fonctionnera pas. En effet, ils sont considérés comme des périphériques différents (''looking at device '/block/sda''' et ''looking at device '/devices/pci0000:00/0000:00:07.0/host0/target0:0:0/0:0:0:0''' sont **deux** périphériques **distincts**).
+Dans ces exemples, vous avez pu voir la **séparation des informations** (''type 1'' et ''type 2''), car vous **ne** pouvez **pas** mélanger ces informations dans une règle, sinon elle ne fonctionnera pas. En effet, ils sont considérés comme des périphériques différents (''looking at device '/block/sda''' et ''looking at device '/devices/pci0000:00/0000:00:07.0/host0/target0:0:0/0:0:0:0''' sont **deux** périphériques **distincts**).
 Par exemple, cette règle est **invalide** :
@@ Ligne 237: / Ligne 238: @@
 Notez aussi que les attributs donnés par ''udevadm info'' sont séparés par des espaces (voyez ''ST3120827AS'' dans l'exemple précédent). Dans vos règles, vous pouvez spécifier les espaces supplémentaires, ou les couper comme précédemment.
-La où ''udevadm info'' se complique, c'est que vous devez connaître les branches supérieures (''/sys/block/sda'' dans l'exemple précédant), ce qui n'est pas toujours évident. Cependant, comme en général vous écrivez des règles pour les périphériques "nodes" existants, vous pouvez utiliser //udev// pour trouver la branche supérieure :
+Là où ''udevadm info'' se complique, c'est que vous devez connaître les branches supérieures (''/sys/block/sda'' dans l'exemple précédant), ce qui n'est pas toujours évident. Cependant, comme en général vous écrivez des règles pour les périphériques "nodes" existants, vous pouvez utiliser //udev// pour trouver la branche supérieure :
 <code>udevadm info -a -p $(udevadm info -q path -n /dev/sda)</code>
@@ Ligne 243: / Ligne 244: @@
 Apparement, il y a beaucoup plus simple :
 <code>udevadm info -a -n /dev/sda</code>
-voir meme :
+voire même :
 <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 307: / Ligne 373: @@
 <code>KERNEL=="sdb", RUN+="/usr/bin/my_program"</code>
-Quand ''/usr/bin/my_program'' est exécuté, plusieurs informations de //udev// sont accessibles par les variables d'environnement. Ceci inclue les clef comme ''SUBSYSTEM''. Vous pouvez aussi utiliser la variable d'environnement ''ACTION'' pour détecter si le périphérique est connecté (valeur "''add''") ou déconnecté (valeur "''remove''").
+Quand ''/usr/bin/my_program'' est exécuté, plusieurs informations de //udev// sont accessibles par les variables d'environnement. Ceci inclut les clefs comme ''SUBSYSTEM''. Vous pouvez aussi utiliser la variable d'environnement ''ACTION'' pour détecter si le périphérique est connecté (valeur "''add''") ou déconnecté (valeur "''remove''").
 ====Interactions avec l'environnement====
@@ Ligne 327: / Ligne 393: @@
 La clef ''OPTIONS'' est une liste d'options supplémentaire pour le traitement de la règle :
-   * ''all_partitions'': crée autant de partitions que possible pour un disque, plutôt que seulement celles créés au démarrage;
+   * ''all_partitions'': crée autant de partitions que possible pour un disque, plutôt que seulement celles créées au démarrage;
    * ''ignore_device'': ignore complétement l'événement;
@@ 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>
-(pour les périphériques dont le noyau à mis un nom du type "''sd?1''"", qui sont sur le bus SCSI, et dont le modèle est "''X250,...''", ajouter un lien nommé ''camera'')
+(pour les périphériques auxquels  le noyau a attribué un nom du type "''sd?1''"", qui sont sur le bus SCSI, et dont le modèle est "''X250,...''", ajouter un lien nommé ''camera'')
@@ 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 430: / Ligne 496: @@
 ====Interfaces Réseau====
-Etant référencés par leur noms, les interfaces réseau n'ont par défaut pas de périphérique "node" attribué. L'écriture de règle reste cependant identique.
+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 445: / Ligne 511: @@
 Une fois le fichier de //udev// modifié, vous devrez recharger le pilote pour faire appliquer cette règle. Vous pouvez soit décharger et recharger le module du noyau correspondant, soit redémarrer votre ordinateur. Vous devrez aussi reconfigurer votre système pour utiliser «''lan''» à la place de «''eth0''».
-//Note//: Il peut y avoir quelques problèmes pour le faire fonctionner (l'interface n'est pas renommée) tant que l'on n'a pas **complétement** retiré toutes les références à «''eth0''». Après ça, vous pourrez utiliser «''lan''» à la place de «''eth0''» dans n'importe quel utilitaire, comme ''ifconfig''.
+//Note//: Il peut y avoir quelques problèmes pour le faire fonctionner (l'interface n'est pas renommée) tant que l'on n'a pas **complètement** retiré toutes les références à «''eth0''». Après ça, vous pourrez utiliser «''lan''» à la place de «''eth0''» dans n'importe quel utilitaire, comme ''ifconfig''.
+===Fixer son adresse MAC===
+Certaines cartes réseaux changent d’adresse MAC à chaque redémarrage ; on peut lire dans les messages kernel :
+<code>
+dmesg
+forcedeth 0000:00:07.0: Invalid MAC address detected: ff:ff:ff:ff:ff:ff - Please complain to your hardware vendor.
+forcedeth 0000:00:07.0: Using random MAC address: 26:f1:b2:e5:d5:24
+</code>
+Si l'on souhaite avoir une adresse MAC fixe, on peut la configurer avec //udev// de la façon suivante :
+<code>
+KERNEL=="eth*", DRIVERS=="forcedeth", PROGRAM="/sbin/ip link set dev %k address xx:xx:xx:xx:xx:xx"
+</code>
+Dans cette illustration  le driver est "forcedeth" : il vous faudra peut-être le remplacer par le vôtre. Il faut également renseigner une adresse MAC valide.
 ====Manettes de jeu====
-Les manettes de jeu apparaissent comme ''/dev/input/jsX'' et certaines ''/dev/input/eventX''. Certaines applications (//Wine// par exemple) veulent accéder aux manettes par ''/dev/input/eventX'', mais cela n'est pas forcément possible du fait des droits de ces fichiers :
+Les manettes de jeu apparaissent comme ''/dev/input/jsX'' voire ''/dev/input/eventX''. Certaines applications (//Wine// par exemple) veulent accéder aux manettes par ''/dev/input/eventX'', mais cela n'est pas forcément possible du fait des droits de ces fichiers :
 On peut ajouter la règle :
@@ Ligne 459: / Ligne 542: @@
 qui donnent les droits de lecture/écriture à tout le monde dans le premier cas, ou à toutes les personnes du groupe ''SOMEGROUP'' dans le deuxième cas.
 =====Essais et deboggage=====
@@ Ligne 466: / 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, si celui-ci est déjà branché au PC, ne vous attendez pas à ce que le lien symbolique soit créé.
+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 re-lecture 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 486: / 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.