OldGentooWiki:Création de règles Udev

Création de règles Udev

Udev est utilisé à partir des noyaux utilisant la branche 2.6. Cette solution utilise la méthode Espace Utilisateur(Userspace) pour créer de manière dynamique les entrées(nodes) dans le répertoire /dev.

L'ancienne méthode utilisant DevFS n'est plus utilisée depuis la sortie officielle de la branche 2.6.

Depuis quelques années, l'utilisation de Udev a évolué de même que les fameuses règles qui permettent une très grande flexibilité au niveau des périphériques.

Sur un système récent, Udev permet d'obtenir des noms de périphérique standard sans la moindre modification de la part de l'utilisateur. Par contre, certains d'entre vous vont désirer modifier celles-ci pour configurer au maximum la gestion de leurs périphériques.

Sur un système linux typique, le répertoire /dev est utilisé pour définir des entrées qui vont se référer à certains périphériques de votre système. Chaque entrée va s'attacher à un périphérique(concept de noeuds ou nodes en Anglais) si celle-ci existe bien sûr. Les applications qui s'exécutent en mode espace utilisateur(Userspace) vont utiliser ces entrées pour pouvoir s'interfacer physiquement à votre périphérique.

Par exemple, le serveur X va écouter sur l'entrée /dev/input/mouse et il va traduire le contenu de cette entrée en mouvement de la souris.

À l'époque, le répertoire /dev contenait des dizaines d'entrées, car il devait contenir presque tout ce qui pouvait exister et surtout être utilisé sous Linux.

Par la suite DevFS est arrivé et celui-ci a amélioré le sort de du répertoire /dev, car il pouvait dynamiquement créer les entrées de /dev à la volée.

Par contre, il était réputé pour avoir quelques problèmes avec certains périphériques et c'était difficile à gérer à ce moment.

Puis, Udev est arrivé dans le décor et cela à instaurer une nouvelle méthode pour gérer le répertoire /dev. Udev a été construit pour corriger des lacunes de DevFS tout en étant plus facile d'entretien.

Pour pouvoir créer dynamiquement une entrée dans /dev, Udev utilise le système de fichiers virtuel SysFs via le répertoire /sys pour découvrir un nouveau périphérique et il utilise des règles qui sont décrites à la fois dans les règles de base de Udev en plus d'appliquer celles qui peuvent être décrites par l'utilisateur.

Ce guide va vous décrire le processus d'écriture d'une règle de Udev définie par l'utilisateur.

Sysfs est un système de fichiers virtuel introduit par le noyau Linux 2.6. Sysfs permet d'exporter depuis l'espace noyau (Kernel Space)vers l'espace utilisateur(User Space) des informations sur les périphériques du système et leurs pilotes et est également utilisé pour configurer certaines fonctionnalités du noyau.

SysFs est administré directement par le noyau et des informations sont disponibles à propos des périphériques qui sont branchés dans le système en temps réel.

Udev utilise ces informations pour créer adéquatement les entrées dans le répertoire /dev.

Les règles de Udev sont très flexibles et surtout très performantes.

Voici des exemples de ce que vous pouvez accomplir en utilisant des règles Udev.

• Renommer une entrée par défaut dans /dev pour un nouveau nom
• Créer un lien symbolique vers une entrée dans /dev
• Créer une entrée dans /dev basée sur l'exécution d'un programme
• Changer les permissions et le propriétaire d'une entrée dans /dev
• Lancer un script lorsqu'une entrée dans /dev est créée ou supprimée
• Renommer une interface réseau

L'écriture de règles n'est pas une manière de régler un problème lorsque pour une raison quelconque, le noyau refuse de créer une entrée dans le répertoire /dev.

De plus, même s'il n'existe pas de règle pour gérer un périphérique, le noyau va être en mesure de créer une entrée par défaut dans le répertoire /dev.

L'utilisation de règles pour standardiser l'entrée d'un périphérique a beaucoup d'avantage. Par exemple, si vous avez 2 périphériques USB, une caméra et une clé USB, il y a de forte chance que ces périphériques vont avoir comme entrée /dev/sdb et /dev/sdc dépendamment de l'ordre dans lequel ils ont été insérés. Ce comportement peut causer des problèmes pour certains utilisateurs qui veulent fixer de manière permanente l'entrée dans /dev comme par exemple /dev/camera et /dev/cleusb.

Udev définit de manière permanente le nom de certain périphérique par défaut. C'est une fonctionnalité très intéressante et cela peut convenir dans la plupart des situations. Dans ce cas, vous n'aurez jamais la nécessité d'écrite vos propres règles.

Pour illustrer ce fait, nous allons regarder le contenu des entrées qui sont dans le répertoire /dev/disk en utilisant la commande :

# ls -lR /dev/disk

Ceci fonctionne de la même manière pour tous ces types de périphériques de stockage.

Par exemple, Udev va créer l'entrée permanente /dev/disk/by-id/scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part8 qui est en fait un lien symbolique qui pointe sur la partition racine dans cet exemple.

/dev/disk:
total 0
drwxr-xr-x 2 root root 400 nov 13 12:19 by-id
drwxr-xr-x 2 root root 120 nov 13 12:19 by-label
drwxr-xr-x 2 root root 240 nov 13 12:19 by-path
drwxr-xr-x 2 root root 180 nov 13 12:19 by-uuid

/dev/disk/by-id:
total 0
lrwxrwxrwx 1 root root  9 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903 -> ../../sda
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part6 -> ../../sda6
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part7 -> ../../sda7
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part8 -> ../../sda8
lrwxrwxrwx 1 root root 10 nov 13 12:19 ata-WDC_WD6400AAKS-00A7B0_WD-WCASY0825903-part9 -> ../../sda9
lrwxrwxrwx 1 root root  9 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903 -> ../../sda
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part6 -> ../../sda6
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part7 -> ../../sda7
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part8 -> ../../sda8
lrwxrwxrwx 1 root root 10 nov 13 12:19 scsi-SATA_WDC_WD6400AAKS-_WD-WCASY0825903-part9 -> ../../sda9

/dev/disk/by-label:
total 0
lrwxrwxrwx 1 root root 10 nov 13 12:19 APP -> ../../sda2
lrwxrwxrwx 1 root root 10 nov 13 12:19 Divers -> ../../sda5
lrwxrwxrwx 1 root root  9 nov 13 12:19 Need\x20for\x20Speed\x28TM\x29\x20SHIFT -> ../../sr0
lrwxrwxrwx 1 root root 10 nov 13 12:19 PONT -> ../../sda6

/dev/disk/by-path:
total 0
lrwxrwxrwx 1 root root  9 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part6 -> ../../sda6
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part7 -> ../../sda7
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part8 -> ../../sda8
lrwxrwxrwx 1 root root 10 nov 13 12:19 pci-0000:00:1f.2-scsi-0:0:0:0-part9 -> ../../sda9
lrwxrwxrwx 1 root root  9 nov 13 12:19 pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sr0

/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root root 10 nov 13 12:19 02ecdf1c-bf7e-42c8-a7f1-ed3c2e92e94a -> ../../sda9
lrwxrwxrwx 1 root root 10 nov 13 12:19 3A7C6EE97C6E9EFF -> ../../sda1
lrwxrwxrwx 1 root root 10 nov 13 12:19 5EC2AB1FC2AAFB03 -> ../../sda5
lrwxrwxrwx 1 root root 10 nov 13 12:19 778b8c9d-1b0e-4e89-b475-273885768f54 -> ../../sda8
lrwxrwxrwx 1 root root 10 nov 13 12:19 A2B7-FCDC -> ../../sda6
lrwxrwxrwx 1 root root 10 nov 13 12:19 CABCFCBBBCFCA2DD -> ../../sda2
lrwxrwxrwx 1 root root 10 nov 13 12:19 d19ef636-5e94-476d-98fe-521a78ecfde6 -> ../../sda7

Le fonctionnement des fichiers rules

Lorsque Udev doit déterminer le nom d'une périphérique et qu'il doit appliquer une action précise, Udev va lire une série de règles pour avant d'identifier la périphérique en question.

Les règles par défaut sont dans le répertoire suivant : /lib/udev/rules.d et elles doivent toutes avoir l'extension rules.

Par défaut, Udev va utiliser les règles qui sont dans le fichier suivant : 50-udev-default.rules et toutes les autres fichiers sont spécifique à votre distribution.

Ces fichiers peuvent être intéressant, car il y a plein de trucs là dedans. Par contre, il ne faut pas modifier le contenu de ce répertoire.

Les fichiers dans le répertoire /lib/udev/rules.d sont lu de manière numérique, donc il peut arriver que l'ordre dans lequel les règles sont lu a beaucoup d'importance. En général, lorsqu'on veut créer nos propres règles, on va les insérer dans le fichier suivant : 10-local.rules .

Lorsqu'on écrit un fichier rules, les commentaires commencent par le caractère # et il faut que la règle soit écrite sur une seule ligne.

Il faut noter qu'un périphérique peut appliquer plus d'un fichier rules ou même plus d'une règle. Ce comportement peut être très pratique, car par exemple si on a écrit 2 règles qui s'applique au même périphérique, nous pouvons par exemple avoir 2 entrées pour ce périphérique dans /dev. Il est important de comprendre que Udev ne va pas arrêter de lire les fichiers rules quand il va avoir exécuté une règle qui correspond au périphérique en cours de traitement, il va lire tous les fichiers rules sans exception pour chaque périphérique.

La syntaxe des fichiers rules

Chaque règle est construite à partir d'une série de clé de recherche et qui sont séparés par des virgules. La valeur de la clé de rechercher correspond à un champ de venant de SysFs et le tout suivi d'une clé d'assignation.

Lorsque toutes les clés correspondent, le périphérique va être géré par Udev et celui-ci va exécuter la règle.

Toutes les règles devaient avoir au moins une clé de recherche qu'une clé d'assignation pour que la règle puisse s'exécuter.

La clé de recherche devrait être dans une expression avec ==, tandis que la clé d'assignation devrait être dans une expression =.

KERNEL=="sdb", NAME="ma_cle_usb"

Les règles de base

Udev fournit plusieurs clés de recherche qui peuvent être utilisés pour identifier de manière très précise un périphérique. Pour avoir une ligne complète, vous être invitez à lire le manuel de udev.

• KERNEL - Correspond au nom du périphérique identifié par le noyau
• SUBSYSTEM - Correspond au nom de la catégorie du périphérique identifié par le noyau
• DRIVER - Correspond au nom du pilote que le noyau utilise pour faire fonctionner le périphérique

Lorsque votre règle a clairement identifié votre périphérique, Udev passe maintenant en mode action et il va exécuter les commandes d'assignations. Pour obtenir une liste complète des clés d'assignation, vous êtes invité à lire le manuel de Udev.

• NAME - Ce champ va permettre d'assigner le nom de l'entrée dans le répertoire /dev
• SYMLINK - Permet de créer un nom alternatif à l'entrée déjà existante dans le répertoire /dev

Il faut noter que Udev crée physiquement qu'une seule entrée par périphérique. Par contre, si vous voulez utiliser des noms alternatifs pour un périphérique en particulier, vous devez utiliser des liens symboliques qui sont en fait des noms alternatifs et qui vont pointer physiquement sur l'entrée d'origine. Bref, cela fonctionne de la même manière qu'un lien symbolique sur un fichier.

Si vous voulez utiliser un nom alternatif, vous devez utiliser l'opérateur += . Vous pouvez aussi déclarer plusieurs noms alternatif en utilisant une liste de nom qui doivent être séparés par un espace.

KERNEL=="hdb", NAME="mon_disque_urgence"
KERNEL=="hdb", DRIVER=="ide-disk", SYMLINK+="disque_urgence urgence backup"

La première règle dit : le périphérique qui correspond à hdb dans le noyau, au lieu de le déclarer comme étant /dev/hdb, je veux qu'il se nomme /dev/mon_disque_urgence .

La deuxième règle dit : le périphérique qui correspond à hdb dans le noyau et qui utilise le pilote ide-disk, je veux qu'en plus du nom par défaut donné par Udev, je veux que Udev crée les entrées disque_urgence,urgence et backup qui vont tous pointer sur /dev/hdb .

Il est à noter que la plupart du temps, on va créer des noms alternatif, car on ne veut pas modifier la structure par défaut des périphériques que Udev va déclarer, donc on ne devrait pas utiliser la variable NAME.

Voici une règle typique lorsqu'on veut créer plusieurs entrées qui vont pointer sur un lecteur CD/DVD :

    KERNEL=="sr0", SYMLINK+="cdrom cdrom0 dvd dvdrw"

Comment utiliser les attributs de SysFs lors de la création de règles

Jusqu'à maintenant, nous avons vu des règles simples pour modifier ou ajouter des entrées. Par contre, pour un usage optimal, il faut s'assurer que les règles vont être assez précise pour affecter seulement un périphérique et ceci dans le but d'éviter de créer des bugs. Pour s'assurer que notre règle va fonctionner, il est préférable de cibler notre périphérique en se servant des valeurs qui sont fournit par le système de fichiers virtuel SysFs, soit par exemple, le numéro de série du périphérique, la taille de celui-ci, une adresse unique, bref quelque chose qui va l'identifier hors de tout doute. Plusieurs pilotes dans le noyau Linux vont fournir ce genre d'information dans le système de fichier virtuel SysFs. Ainsi, c'est avec ce genre d'information qu'on va pouvoir travailler avec Udev via la clé de recherche ATTR.

SUBSYSTEM=="block", size=="234441648", SYMLINK+="mon_disque"

L'hiérarchie des périphériques

Le noyau Linux représente les périphériques à travers une structure de répertoire et ces informations sont le résultat du système de fichiers virtuel SysFs. Par exemple, la représentation d'un disque dur va être en fait, un sous-répertoire de SCSI disk device, qui est à son tour un sous-répertoire de Serial ATA Controller Device et qui est à son tour un sous-répertoire de PCI bus device.

Sachant cela, lorsque vous allez écrire des règles Udev, vous allez devoir exploiter ce concept pour arriver hors de tout doute à identifier un périphérique et faire exécuter une règle pour celui-ci.

Nous avons vu jusqu'à maintenant les 4 clés de recherche (KERNEL/SUBSYSTEM/DRIVER/ATTR) qui nous permettent d'identifier un périphérique sans plus. Par contre, il est avantageux d'identifier de manière plus précise un périphérique pour être certain d'appliquer la règle à celui-ci seulement.

• KERNELS - Permet d'identifier un périphérique en utilisant celui identifié par le noyau.
• SUBSYSTEMS - Permet d'identifier un périphérique en utilisant sa sous-classe
• DRIVERS - Permet d'identifier un périphérique en utilisant le nom du pilote utilisé par le noyau
• ATTRS - Permet d'identifier un périphérique en utilisant une caractéristique déclarée dans le système de fichiers virtuel SysFS.

Gardez en tête ce principe, car c'est en utilisant celui-ci qu'on va pouvoir écrire des règles Udev qui vont bien s'exécuter.

Caractère de substitutions

Lorsqu'on doit écrire une règle Udev, il se peut que vous ayez à gérer plusieurs périphériques de la même famille, Udev permet d'utiliser un caractère de substitution pour gérer ce genre de situation.

Le caractère %k et %n sont ceux qui sont le plus utilisé.

•  %k ou $kernel retourne comme information le nom du périphérique identifié par le noyau, par exemple "sda3".
•  %n ou $number retourne comme information la valeur numérique du périphérique identifié par le noyau, par exemple pour "sda3", le résulat retourné va être 3.

Udev utilise d'autres caractères de substitution et vous pouvez consulter le manuel de Udev pour obtenir plus d'informations. Enfin, le %k peut s'écrire aussi $kernel et %n peut s'écrire aussi $number. L'utilisation de $kernel et $number est utile quand vous devez construire une règle qui va déjà utiliser le caractère %, donc c'est un moyen simple de se sortir du pétrain.

Enfin, si vous rechercher le caractère %, vous pouvez toujours utiliser %% ou $$ pour utiliser les caractères de substitutions.

    KERNEL=="mice", NAME="input/%k"
    KERNEL=="loop0", NAME="loop/%n", SYMLINK+="%k"

La première règle, va remplacer l'entrée /dev/mice par /dev/input/mice. La deuxième règle, va créer l'entrée /dev/loop/0 en plus de créer un lien symbolique /dev/loop0 pointant sur /dev/loop/0.

L'utilisation de ce genre de règle n'est pas recommandé, par contre ça explique bien le principe de substitution.

Caractères spéciaux

Les 3 caractères suivants sont utilisés pour simplifier l'écriture d'une règle.

• * - Correspond à n'importe lequel des caractères, de 0 occurence à plusieurs occurences.
•  ? - Correspond à n'importe lequel des caractères, mais une une seule occurence.
• [] - Correspond à un caractère contenu dans les crochets et l'utilisation de plage est acceptée.

Here are some examples which incorporate the above patterns. Note the use of the string substitution operators.

    KERNEL=="fd[0-9]*", NAME="floppy/%n", SYMLINK+="%k"
    KERNEL=="hiddev*", NAME="usb/%k"

La première règle permet de créer une ou plusieurs entrées dans le répertoire /dev/floppy/%numéro en plus de créer un lien symbolique /dev/floppy%numéro.

La deuxième règle permet de créer une entrée pour tous les périphériques qui sont identifiés en tant que hiddev et une entrée sera créé dans /dev/usb/nom_donné_par_le_noyau.

C'est la partie la plus compliqué, car il faut chercher manuellement un périphérique dans /sys ou carrément utiliser lshal pour avoir une idée.

udi = '/org/freedesktop/Hal/devices/net_00_22_15_a3_cf_dc'
  info.capabilities = {'net', 'net.80203', 'wake_on_lan'} (string list)
  info.category = 'net.80203'  (string)
  info.interfaces = {'org.freedesktop.Hal.Device.WakeOnLan'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/pci_11ab_4364'  (string)
  info.product = 'Networking Interface'  (string)
  info.subsystem = 'net'  (string)
  info.udi = '/org/freedesktop/Hal/devices/net_00_22_15_a3_cf_dc'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'net'  (string)
  linux.sysfs_path = '/sys/class/net/eth0'  (string)
  net.80203.mac_address = 146391945180  (0x2215a3cfdc)  (uint64)
  net.address = '00:22:15:a3:cf:dc'  (string)
  net.arp_proto_hw_id = 1  (0x1)  (int)
  net.interface = 'eth0'  (string)
  net.linux.ifindex = 4  (0x4)  (int)
  net.originating_device = '/org/freedesktop/Hal/devices/pci_11ab_4364'  (string)
  org.freedesktop.Hal.Device.WakeOnLan.method_argnames = {'', '', 'enable'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_execpaths = {'hal-system-wol-supported', 'hal-system-wol-enabled', 'hal-system-wol-enable'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_names = {'GetSupported', 'GetEnabled', 'SetEnabled'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_signatures = {'', '', 'b'} (string list)

Par exemple, voici ce qui est retourné par lshal au niveau de la carte réseau eth0. On voit le nom de l'interface qui est eth0(net.interface) et on peut voir la MAC adresse(net.address) de celle-ci en plus d'obtenir le répertoire correspondant à ce périphérique(/sys/class/net/eth0).

En ayant le répertoire, on peut lancer udevadm en passant ce répertoire pour obtenir des informations supplémentaires.

# udevadm info --query=all --path=/sys/class/net/eth0
P: /class/net/eth0
E: UDEV_LOG=3
E: DEVPATH=/class/net/eth0
E: PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.5/0000:02:00.0
E: PHYSDEVBUS=pci
E: PHYSDEVDRIVER=sky2
E: INTERFACE=eth0
E: IFINDEX=4

En voyant ceci, on peut maintenant mieux comprendre pourquoi le fichier /etc/udev/rules.d/70-persistent-net.rules contient :

# This file was automatically generated by the /lib64/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x11ab:0x4320 (skge)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:15:a3:da:66", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x11ab:0x4364 (sky2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:15:a3:cf:dc", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

On voit bien que l'adresse MAC de eth0 correspond vraiment à 00:22:15:a3:cf:dc autant dans lshal que dans udevadm.

L'arborescence de SysFs

Pour pouvoir utiliser de manière optimale Udev, vous devez savoir comment retrouver un périphérique dans /sys et plus particulièrement savoir comment utiliser un attribut pour identifier un périphérique.

SysFs utilise une structure très simple. Celle-ci est divisée en plusieurs répertoire et chaque répertoire contient un nombre X de fichiers qui contiennent seulement une valeur. De plus, certains fichiers sont en fait des liens symboliques qui pointent vers d'autre répertoire.

Les répertoire de niveau 1 sont en fait, les répertoires qui sont sous la racine de /sys, on peut les identifier en lançant la commande suivante :

# find /sys -name dev
/sys/devices/pci0000:00/0000:00:1a.0/usb3/dev
/sys/devices/pci0000:00/0000:00:1a.1/usb4/dev
/sys/devices/pci0000:00/0000:00:1a.2/usb5/dev
/sys/devices/pci0000:00/0000:00:1a.7/usb1/dev
/sys/devices/pci0000:00/0000:00:1d.0/usb6/dev
/sys/devices/pci0000:00/0000:00:1d.1/usb7/dev
/sys/devices/pci0000:00/0000:00:1d.2/usb8/8-1/dev
/sys/devices/pci0000:00/0000:00:1d.2/usb8/dev    
/sys/devices/pci0000:00/0000:00:1d.7/usb2/dev    
/sys/dev                                         
... 
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/block/sda/sda3/dev
/sys/block/sda/sda5/dev
/sys/block/sda/sda6/dev
/sys/block/sda/sda7/dev
/sys/block/sda/sda8/dev
/sys/block/sda/sda9/dev
/sys/block/sr0/dev

Par exemple, sur l'ordinateur de test, le répertoire /sys/block/sda est une entrée qui représente le disque dur. Cette entrée est attaché au périphérique SCSI Disk Device à cause du lien symbolique device contenu dans /sys/block/sda/device

/sys/block/sda
gentootux sda # ls -la
total 0
drwxr-xr-x 14 root root    0 nov 15 15:22 .
drwxr-xr-x 28 root root    0 nov 15 15:22 ..
lrwxrwxrwx  1 root root    0 nov 15 15:22 bdi -> ../../class/bdi/8:0
-r--r--r--  1 root root 4096 nov 15 15:22 capability
-r--r--r--  1 root root 4096 nov 15 15:22 dev
lrwxrwxrwx  1 root root    0 nov 15 15:22 device -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
-r--r--r--  1 root root 4096 nov 15 15:22 ext_range
drwxr-xr-x  2 root root    0 nov 15 15:22 holders
drwxr-xr-x  2 root root    0 nov 15 15:22 power
drwxr-xr-x  3 root root    0 nov 15 15:22 queue
-r--r--r--  1 root root 4096 nov 15 15:22 range
-r--r--r--  1 root root 4096 nov 15 15:22 removable
-r--r--r--  1 root root 4096 nov 15 15:22 ro
drwxr-xr-x  4 root root    0 nov 15 15:22 sda1
drwxr-xr-x  4 root root    0 nov 15 15:22 sda2
drwxr-xr-x  4 root root    0 nov 15 15:22 sda3
drwxr-xr-x  4 root root    0 nov 15 15:22 sda5
drwxr-xr-x  4 root root    0 nov 15 15:22 sda6
drwxr-xr-x  4 root root    0 nov 15 15:22 sda7
drwxr-xr-x  4 root root    0 nov 15 15:22 sda8
drwxr-xr-x  4 root root    0 nov 15 15:22 sda9
-r--r--r--  1 root root 4096 nov 15 15:22 size
drwxr-xr-x  2 root root    0 nov 15 15:22 slaves
-r--r--r--  1 root root 4096 nov 15 15:22 stat
lrwxrwxrwx  1 root root    0 nov 15 15:22 subsystem -> ../../block
-rw-r--r--  1 root root 4096 nov 15 15:22 uevent

Quand vous voulez écrire une règle basée sur un attribut dans le système de fichiers virtuel SysFS, vous avez seulement à comparer une valeur avec celle contenu dans l'attribut.

# cat /sys/block/sda/size
 1250263728

Lors de l'écriture de la règle, vous pourriez utiliser ceci pour identifier le disque dur size=="1250263728".

Par exemple, si nous voulons qu'une clé USB de marque OCZ utilise toujours la même entrée dans /dev, nous allons devons procéder de la manière suivante.

La première chose à exécuter c'est de lancer le deamon udev pour qu'il enregistre le plus d'information possible à propos de cette fameuse clé.

# udevadm --property

Ensuite, vous devez brancher la clé USB et attendre le résultat à l'écran.

 UDEV  [1258732140.829454] add      /devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3:1.0/host17/target17:0:0/17:0:0:0/block/sdb (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3:1.0/host17/target17:0:0/17:0:0:0/block/sdb
SUBSYSTEM=block
DEVNAME=/dev/sdb
DEVTYPE=disk
SEQNUM=1902
ID_VENDOR=OCZ
ID_VENDOR_ENC=OCZ\x20\x20\x20\x20\x20
ID_VENDOR_ID=0324
ID_MODEL=RALLY2
ID_MODEL_ENC=RALLY2\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=bc06
ID_REVISION=1100
ID_SERIAL=OCZ_RALLY2_AA04012700035591-0:0
ID_SERIAL_SHORT=AA04012700035591
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usb-storage
ID_PATH=pci-0000:00:1a.7-usb-0:3:1.0-scsi-0:0:0:0
ID_FS_LABEL=RALLY2
ID_FS_LABEL_ENC=RALLY2
ID_FS_UUID=D09D-7419
ID_FS_UUID_ENC=D09D-7419
ID_FS_VERSION=FAT32
ID_FS_TYPE=vfat
ID_FS_USAGE=filesystem
MAJOR=8
MINOR=16
DEVLINKS=/dev/block/8:16 /dev/disk/by-id/usb-OCZ_RALLY2_AA04012700035591-0:0 /dev/disk/by-path/pci-0000:00:1a.7-usb-0:3:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/D09D-7419 /dev/disk/by-label/RALLY2

C'est à partir de ces informations que nous allons créer notre règle.

# nano /etc/udev/rules.d/10-local.rules

SUBSYSTEM=="block" ID_SERIAL=="OCZ_RALLY2_AA04012700035591-0:0" SYMLINK+="ma_cle_ocz"

Enfin, lorsque vous avez terminé, vous devez recharger vos règles de Udev.

# udevadm control --reload-rules

Si tout va bien, vous allez pouvoir lancer ceci :

# mkdir /mnt/cle
# mount /dev/ma_cle_ocz /mnt/cle