8.1.2.2.1. Présentation

Depuis la version 2.6 du noyau, Linux dispose d'une fonctionnalité permettant aux applications de détecter l'apparition et la suppression des périphériques, que ceux-ci soient détectés au démarrage du système ou qu'ils soient branchés à chaud une fois l'ordinateur allumé.

Cette fonctionnalité est principalement utilisée par le sous-système udev (abréviation de « Userspace /dev »). Comme son nom l'indique, udev a pour principale fonction de prendre en charge la gestion du répertoire /dev/, mais en réalité il est capable de faire beaucoup mieux que cela.

En particulier, udev peut réaliser les opérations suivantes lorsque le noyau signale la présence d'un nouveau périphérique :

• chargement du module du pilote de périphérique si nécessaire ;

• si le périphérique requiert un firmware, chargement de celui-ci ;

• création du fichier spécial de périphérique et de ses alias nécessaires à l'utilisation du périphérique ;

• exécution des opérations d'initialisation complémentaires ou lancement des applications utilitaires associées au périphérique ;

• notification de la présence du périphérique à l'ensemble des autres programmes qui s'intéressent à la gestion du matériel (par exemple le gestionnaire de bureau).

udev peut également effectuer les opérations nécessaires à la suppression d'un périphérique, ce qui est utile pour les périphériques amovibles. Ainsi, la détection, la configuration et la notification dynamique de la présence des périphériques Plug and Play est totalement automatisée.

udev permet de résoudre plusieurs problèmes concernant les fichiers spéciaux de périphériques. Le plus évident pour l'utilisateur est que seuls les fichiers spéciaux des périphériques effectivement présents et pris en charge par un gestionnaire de périphérique apparaissent dans le répertoire /dev/.

Le répertoire /dev/ n'a donc plus à contenir les fichiers spéciaux de périphériques pour tous les périphériques pris en charge par Linux. Il en est d'autant réduit, ce qui permet de le placer dans un système de fichiers virtuel (c'est-à-dire un système de fichiers géré par le noyau en mémoire). La plupart des distributions basées sur udev utilisent cette technique afin d'accélérer la phase de chargement du système et les accès aux fichiers spéciaux de périphériques par les applications, et d'éviter de consommer inutilement de l'espace disque pour stocker des fichiers spéciaux qui sont de toutes manières recréés dynamiquement à chaque démarrage.

Un autre avantage d'udev est que les codes majeurs et mineurs des fichiers spéciaux de périphériques peuvent à présent être attribuées dynamiquement par le noyau lorsque les gestionnaires de périphériques s'initialisent. Cela a plusieurs conséquences :

• il n'y a plus besoin d'avoir recours à une autorité centrale pour obtenir les valeurs de codes mineurs et majeurs, ceux-ci pouvant être déterminés dynamiquement par le noyau ;

• il n'y a plus de risque de conflit entre deux périphériques, le noyau s'assurant de l'unicité des codes utilisés ;

• la limitation du nombre de périphériques due au nombre limité de codes majeurs et mineurs n'existe plus (il suffit de consulter la liste du fichier /usr/src/linux/Documentation/devices.txt pour constater qu'il reste peu de codes libres pour les périphériques à venir).

Enfin, udev permet de simplifier considérablement la configuration et l'utilisation du système. Par exemple, il est possible de fixer de manière permanente le nom des fichiers spéciaux des périphériques amovibles, et les environnements utilisateurs graphiques peuvent réagir à l'apparition et à la suppression des périphériques afin de permettre leur utilisation par l'utilisateur.

8.1.2.2.2. Principe de fonctionnements de udev

Le principe de fonctionnement de udev est le suivant. Lorsque le noyau détecte un changement dans la configuration matérielle, il signale ce changement via un canal de communication « NetLink » aux applications qui s'y intéressent. udev utilise le démon udevd pour écouter sur ce canal de communication, et il met chacun de ces événements dans une file pour les traiter dans leur ordre d'apparition.

Les événements envoyés par le noyau contiennent toutes les informations relatives au périphérique pour lequel le noyau a généré un événement. Ces paramètres comprennent, entre autres, la nature de l'événement (apparition ou disparition d'un périphérique inconnu sur un bus, demande de chargement de firmware, notification de chargement ou de déchargement d'un pilote de périphérique, etc.). udevd utilise ces informations, ainsi que les informations sur le périphérique fournies par le noyau au travers du système de fichiers /sys/, pour effectuer les opérations de chargement des modules de pilotes de périphérique, de chargement des firmware, et de création des fichiers spéciaux de périphériques.

Le comportement que udev doit adopter dépend bien évidemment de chacun des périphériques, ou du moins de la classe du périphérique pour lequel l'événement se produit. Ce comportement est donc paramétrable à l'aide des fichiers de configuration situés dans le répertoire /etc/udev/ et /etc/udev/rules.d/. Ce dernier répertoire contient en particulier les règles qui permettent de définir les fichiers spéciaux de périphériques qui doivent être créés, les alias permettant de les nommer de manière constante, et les permissions que l'on doit leur affecter.

Le répertoire /etc/udev/ ne contient généralement que le fichier de configuration principal d'udev, à savoir le fichier udev.conf. Ce fichier permet d'indiquer le répertoire cible dans lequel les fichiers spéciaux de périphérique seront créés (paramètre udev_root, dont la valeur doit obligatoirement être /dev/), le répertoire contenant les fichiers de définition des actions prises par udev en fonction des différents événements (paramètre udev_rules, dont la valeur est normalement /etc/udev/rules.d/), et le niveau d'erreur à partir duquel les traces d'udev seront enregistrés dans le journal du système syslog (paramètre udev_log).

L'essentiel de la configuration réside toutefois dans les fichiers du répertoire /etc/udev/rules.d/. Ces fichiers expriment, sous la forme de règles permettant de sélectionner les différents événements provenant du noyau en fonction des informations de cet événement, les actions à entreprendre. Ce mécanisme est suffisamment générique pour permettre d'identifier de manière unique les périphériques et de réaliser les actions dont udev a la charge.

Les règles sont décrites à raison d'une ligne par règle dans les fichiers de configuration. L'action identifiée par chaque règle n'est exécutée que si l'événement généré par le noyau correspond aux critères de sélection de la règle. Certains mots clés permettent d'obtenir les informations sur l'événement produit par le noyau, et d'autres mots clés permettent de décrire les actions à effectuer lorsque les critères de sélection de l'événement sont satisfaits.

Par exemple, le mot clé ACTION identifie la nature de l'événement. Le mot clé KERNEL donne le nom que le noyau donne au périphérique qui a généré l'événement, et DEVPATH le chemin du périphérique dans le système de fichiers virtuel /sys/. Inversement, le mot clé NAME permet de paramétrer l'action de création du fichier spécial de périphérique en définissant le nom de ce fichier, et OWNER, GROUP et MODE permettent de définir respectivement l'utilisateur propriétaire, le groupe, et les droits d'accès à ce fichier. Ainsi, les simples règles suivantes :

KERNEL=="mem", NAME="%k", GROUP="kmem", MODE="0640"
KERNEL=="kmem", NAME="%k", GROUP="kmem", MODE="0640"

D'autres mots clés sont disponibles. Ainsi, SYMLINK permet de définir des liens symboliques supplémentaires (par exemple /dev/modem ou /dev/mouse) référençant les fichiers spéciaux de périphériques réels. Le mot clé PROGRAM permet d'exécuter un programme avant que le fichier spécial de périphérique ne soit créé (généralement pour déterminer le nom du fichier à créer, justement), et le mot clé RUN permet d'exécuter une commande après que le fichier spécial de périphérique a été créé (généralement pour configurer le périphérique ou signaler sa présence à l'utilisateur). Vous trouverez de plus amples renseignements sur toutes ces règles dans la page de manuel de udev, ainsi que dans la documentation fournie avec udev pour la rédaction de règles personalisées.

Les fichiers du répertoire /etc/udev/rules.d/ doivent tous avoir l'extension .rules. De plus, ces fichiers sont interprétés dans l'ordre lexicographique de leur nom. Ainsi, il est d'usage de préfixer le nom du fichier par un numéro indiquant l'ordre de priorité des règles de ce fichier par rapport aux autres. Par exemple, les règles du fichier 50-udev.rules (fichier de définition des règles principales de udev) sont toujours lues avant les règles du fichier 90-hal.rules (fichier de définition des règles permettant d'envoyer les événements concernant le matériel au démon d'abstraction du matériel hald), car 50 est plus petit que 90 dans l'ordre lexicographique.

Comme vous pouvez le constater, les fichiers de configuration de udev permettent de paramétrer de manière très souple et très précise les actions à effectuer lorsqu'un périphérique apparaît ou disparaît. Nous verrons dans les sections suivantes comment les principales actions sont réalisées. La contrepartie de ce système est tout de même une certaine complexité dans la définition des règles des fichiers de configuration d'udev, mais vous n'aurez généralement pas à vous en préoccuper, car les distributions fournissent des fichiers de configuration adaptés à la plupart des usages.

8.1.2.2.3. Identification et chargement des pilotes de périphérique

Généralement, les périphériques modernes disposent d'identifiants qui leur sont propres et qui peuvent être récupérés par des mécanismes standards des bus modernes. Ces identifiants sont généralement au nombre de deux, le premier étant un code spécifique au fabricant du périphérique, et le deuxième étant un identifiant de ce périphérique. Par exemple, vous pouvez visualiser les différents périphériques connectés au bus PCI de votre ordinateur avec la simple commande lspci -nn. La commande lsusb vous donnera des identifiants similaires pour les périphériques USB.

udev peut déterminer, à l'aide des identifiants du matériel, déterminer quels sont les pilotes de périphériques capable de gérer ce matériel. En effet, les fichiers sources de chaque module de pilote de périphérique contiennent une liste des identifiants des périphériques qu'ils prennent en charge. Lors de l'installation du module, la command depmod extrait ces informations et les place dans un des fichiers situés dans le répertoire d'installation des modules du noyau (à savoir /lib/module/version/, où version est le numéro de version du noyau). depmod crée un fichier pour chaque type de périphérique. Ces fichiers ont tous un nom de la forme :

module.typemap

Par exemple, le fichier module.usbmap contient, pour chaque périphérique USB pris en charge par les modules installés, une ligne indiquant le nom du module et l'ensemble des identifiants du périphérique USB en question.

Ainsi, lorsque le noyau indique à udev l'apparition d'un nouveau périphérique, celui-ci consulte les fichiers d'association des modules aux périphériques pour déterminer quel module est capable de gérer ce périphérique. Ce module est chargé si nécessaire, et le gestionnaire de périphérique peut s'initialiser.

8.1.2.2.4. Chargement des firmwares

Certains périphériques nécessitent un firmware (c'est-à-dire un micro logiciel pour les périphériques évolués) pour fonctionner correctement. Ce firmware peut être stocké de manière permanente dans le périphérique dans une mémoire non volatile, ou devoir être rechargé à chaque initialisation du périphérique. Dans ce cas, cette opération de chargement doit être faite par le pilote de périphérique.

Grâce à udev, il est possible de faire en sorte que cette opération se fasse automatiquement. Lorsqu'un pilote désire charger le firmware dans le périphérique, il appelle une fonction du noyau qui génère un événement udev. udev prend alors en charge les opérations et localise le firmware, puis le fournit au noyau. Le pilote de périphérique peut alors effectuer le chargement effectif du firmware dans le périphérique. Pour cela, udev copie le fichier de firmware demandé par le pilote de périphérique dans un fichier dédié à cet effet dans l'entrée du périphérique du système de fichiers virtuel /sys/. Bien entendu, le chemin permettant de trouver les informations du périphérique dans le système de fichiers virtuel /sys/ est fourni aux scripts de configuration d'udev via le mot clé DEVPATH.

En général, les fichiers de firmware sont fournis avec les pilotes de périphériques ou sont disponibles sur le site Web indiqué dans leur documentation. Ils doivent être installés dans le répertoire /lib/firmware/. Il est également nécessaire d''activer l'option « Hotplug firmware loading support » du sous-menu « Generic Driver Options » du menu « Device Drivers » pour que cette fonctionnalité soit disponible.

8.1.2.2.5. Création des fichiers spéciaux de périphériques

À chaque périphérique détecté par un pilote de périphérique, le noyau génère un événement à destination d'udev. Ces événements indiquent le nom du périphérique tel qu'il est connu par le gestionnaire de périphérique, ainsi que les informations sur le périphérique dans le système de fichiers /sys/. udev utilise ces informations pour déterminer les règles qui indiquent quels sont les fichiers spéciaux de périphériques à utiliser.

Si aucune règle ne correspond, udev crée le fichier spécial de périphérique avec le nom utilisé par le pilote de périphérique pour l'identifier. Dans le cas contraire, c'est le nom fourni dans les fichiers de configuration qui est utilisé. De même, les fichiers sont créés par défaut au nom de l'utilisateur root, et seul cet utilisateur dispose des droits de lecture et d'écriture sur ces fichiers. Enfin, si des liens symboliques sont définis dans les règles appliquées, ceux-ci sont créés. Par exemple, il est classique d'avoir un lien symbolique cdrom pointant vers le périphérique de type bloc gérant le lecteur de CD.

Les règles d'udev sont généralement fournies par les distributions et permettent de créer les fichiers spéciaux de périphériques de manière générique, ainsi que les liens symboliques standards. De même, bien que les interfaces réseau ne sont pas accédées par l'intermédiaire de fichiers spéciaux de périphériques, les règles udev sont également appliquées afin de les renommer sous un nom spécifique.

8.1.2.2.6. Persistance des fichiers spéciaux de périphériques

L'un des princpaux avantages d'udev est de permettre un nommage fixe des différents périphériques. Par exemple, si vous disposez de deux imprimantes, chaque imprimante se verra affecter un fichier spécial de périphérique dédié. Toutefois, il est possible qu'une de ces imprimantes ne soit pas disponible, ou pas allumée. Dans ce cas, un décallage des fichiers spéciaux de périphériques peut se produire, ce qui peut être génant si une configuration spécifique doit être faite pour la deuxième imprimante. De même, vous pouvez disposer de plusieurs disques amovibles ou clefs USB, et il peut être utile que les fichiers spéciaux de ces périphériques aient un nom constant.

udev permet tout cela, en faisant en sorte que les règles des fichiers de configuration sélectionnent les périphériques sur une de leur caractéristiques principale (par exemple, le nom de modèle du périphérique).

Pour fixer les idées et donner un exemple, supposons que l'on ait deux clefs mémoire USB de modèles différents et que l'on désire affecter de manière permanente des fichiers de périphériques à chacune d'elle. Il suffit pour cela simplement de trouver un paramètre unique dans les identifiants de ces périphériques afin de les distinguer.

La manière la plus simple pour obtenir la liste des paramètres d'un périphérique est d'utiliser la commande udevinfo. Pour obtenir la liste des attributs utilisables dans les règles de udev, il faut utiliser l'option --attribute-walk. Le périphérique dont les attributs doivent être récupérés peut être spécifié soit grâce au nom de son fichier spécial de périphérique utilisé par le noyau (avec l'option --name), ou avec son chemin dans le système de fichiers /sys/.

Par exemple, la commande suivante permet d'obtenir les informations sur un disque amovible connecté sur le port USB et apparaissant sous le nom /dev/sdb :

udevinfo --name=/dev/sdb --attribute-walk

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/block/sdb':
    KERNEL=="sdb"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{capability}=="12"
    ATTR{stat}=="      52      127      556      486        0        0        0        0        0      426      486"
    ATTR{size}=="156301488"
    ATTR{removable}=="0"
    ATTR{range}=="16"
    ATTR{dev}=="8:16"

  looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-2/1-2:1.0/host5/target5:0:0/5:0:0:0':
    KERNELS=="5:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{modalias}=="scsi:t-0x00"
    ATTRS{ioerr_cnt}=="0x0"
    ATTRS{iodone_cnt}=="0x3b"
    ATTRS{iorequest_cnt}=="0x3b"
    ATTRS{iocounterbits}=="32"
    ATTRS{timeout}=="30"
    ATTRS{state}=="running"
    ATTRS{rev}=="09.0"
    ATTRS{model}=="WD800VE-00HDT0  "
    ATTRS{vendor}=="WDC     "
    ATTRS{scsi_level}=="3"
    ATTRS{type}=="0"
    ATTRS{queue_type}=="none"
    ATTRS{queue_depth}=="1"
    ATTRS{device_blocked}=="0"
    ATTRS{max_sectors}=="240"

...

Comme on peut le voir, les informations du périphérique /dev/sdb sont d'abord affichées. Viennent ensuite les informations des périphériques parents, donc en particulier les informations sur le disque physique (ici, un Western Digital WD800VE-00HDT0), et ainsi de suite (seules les deux premiers bloc d'information ont été recopiés dans cet exemple, les suivants identifiant l'adaptateur USB et les composants du bus USB eux-mêmes).

Ainsi, les informations spécifique au matériel connecté que l'on doit utiliser pour définir un fichier spécial de périphérique unique sont données dans le deuxième groupe d'information (relative au disque physique). Il est donc possible de définir la règle udev suivante pour créer un fichier spécial de périphérique /dev/hd_externe dédié à ce disque :

SUBSYSTEMS=="scsi", ATTRS{model}=="WD800VE-00HDT0", NAME="hd_externe"

Une fois vos règles définies, vous pouvez les tester avec la commande udevtest. Cette commande prend en paramètre le nom du périphérique de plus haut niveau renvoyé par udevinfo. Dans notre exemple, il s'agit de /block/sdb :

udevtest /sys/block/sdb

En pratique, les distributions font en sorte que les règles de nommage des périphériques soient écrites ou mises à jour dynamiquement lors de la première détection du périphérique. Elles s'appuient pour cela sur des programmes utilitaires, généralement situés dans le répertoire /lib/udev/. Par exemple, le script /lib/udev/cdrom-symlinks.sh a pour but de créer le fichier de configuration /etc/udev/rules.d/75-optical-devices.rules, qui contient les définitions des liens symboliques sur les lecteurs de disque optique (CDROM et graveurs de CD par exemple).

8.1.2.2.7. Notification des applications utilisateurs

udev est également livré avec un fichier de configuration contenant une règle permettant de notifier les applications de haut niveau des apparitions et disparition des périphériques.

Le mécanisme utilisé se base ici sur le sous-système HAL (« Hardware Abstraction Layer Daemon »). Ce sous-système a pour principal but de fournir une interface unifiée pour que l'ensemble des applications de haut niveau (par exemple les gestionnaires de bureau KDE et Gnome) puisse obtenir des informations sur les périphériques et être notifiées de toutes modification de la configuration matérielle.

Toutes ces opérations sont implémentées au niveau du démon hald. Ce démon reçoit les informations concernant les périphériques directement de udev, grâce à la règle mentionnée ci-dessus. Grâce à ces informations, il maintient une base de données des périphériques présents et de leurs principales caractéristiques.

De plus, hald fournit une interface de programmation standard pour toutes les applications utilisateurs. Cette interface se base sur un protocole de communication standard, le protocole D-BUS. Ce protocole a été développé de manière commune avec les deux principaux environnements de bureau de Linux, à savoir KDE et Gnome. Ainsi, les applications de ces environnements sont capables de gérer les modificiations intervenant sur le matériel. Par exemple, le fait de brancher une clef USB ou un disque externe permet de demander à l'utilisateur s'il veut le monter ou non.

8.1.2.2.8. Initialisation du système

Pour terminer cette description des mécanismes d'udev, signalons que le démon udevd ne peut évidemment pas écouter les événements du noyau avant qu'il ne soit lancé. Par conséquent, les périphériques détectés par le noyau avant le démarrage du démon udevd ne sont pas être détéctés automatiquement.

Ce problème est géré au niveau des scripts de démarrage des distributions, en rejouant les événements matériels des périphériques déjà détectés par le noyau. Cela se fait en appelant la commande udevtrigger. Cette opération est totalement prise en charge par les distributions, et vous n'avez normalement pas à utiliser cette commande.