7.4. Gestion des périphériques et modules d'un système LFS

Au Chapitre 6, nous avons installé le paquet Udev. Avant d'entrer dans les détails concernant son fonctionnement, un bref historique des méthodes précédentes de gestion des périphériques est nécessaire.

Traditionnellement, les systèmes Linux utilisent une méthode de création de périphériques statiques avec laquelle un grand nombre de nœuds de périphériques sont créés sous /dev (quelque fois des milliers de nœuds), que le matériel correspondant existe ou pas. Ceci est fait typiquement avec un script MAKEDEV, qui contient des appels au programme mknod avec les numéros de périphériques majeurs et mineurs pour chaque périphérique possible qui pourrait exister dans le monde.

En utilisant la méthode udev, seuls les nœuds pour le périphériques détectés par le noyau sont créés. Comme ces nœuds de périphériques seront créés à chaque lancement du système, ils seront stockés dans un système de fichiers devtmpfs (un système de fichiers virtuel qui réside entièrement dans la mémoire du système). Les nœuds de périphériques ne requièrent pas beaucoup d'espace, donc la mémoire utilisée est négligeable.

7.4.1. Historique

En février 2000, un nouveau système de fichiers appelé devfs a été intégré au noyau 2.3.46 et rendu disponible pour la série 2.4 des noyaux stables. Bien qu'il soit présent dans les sources du noyau, cette méthode de création dynamique des périphériques n'a jamais reçu un support inconditionnel des développeurs du noyau.

Le principal problème de l'approche adopté par devfs était la façon dont il gérait la détection, la création et le nommage des périphériques. Ce dernier problème, le nommage des périphériques, était peut-être le plus critique. Il est généralement accepté que s'il est possible de configurer les noms des périphériques, alors la politique de nommage des périphériques revient à l'administrateur du système, et du coup n'est imposée par aucun développeur en particulier. Le système de fichiers devfs souffre aussi de restrictions particulières inhérentes à sa conception et qui ne peuvent être corrigées sans une revue importante du noyau. Il a aussi été marqué comme obsolète pendant une longue période — à cause d'un manque de maintenance — et a finalement été supprimé du noyau en juin 2006.

Avec le développement de la branche instable 2.5 du noyau, sortie ensuite avec la série 2.6 des noyaux stables, un nouveau système de fichiers virtuel appelé sysfs est arrivé. Le rôle de sysfs est d'exporter une vue de la configuration matérielle du système pour les processus en espace utilisateur. Avec cette représentation visible en espace utilisateur, la possibilité de voir un remplacement de l'espace utilisateur pour devfs est devenu beaucoup plus réaliste.

7.4.2. Implémentation d'Udev

7.4.2.1. Sysfs

Le système de fichier sysfs a été brièvement mentionné ci-dessus. On pourrait se demander comment sysfs connaît les périphériques présents sur un système et quels numéros de périphériques devraient être utilisés. Les pilotes qui ont été compilés directement dans le noyau enregistrent leurs objets avec sysfs (en interne, devtmpfs) quand ils sont détectés par le noyau. Pour les pilotes compilés en tant que modules, cet enregistrement surviendra quand le module sera chargé. Une fois que le système de fichier sysfs est monté (sur /sys), les données enregistrées par les pilotes internes avec sysfs sont disponibles pour les processus en espace utilisateur ainsi que pour udevd pour continuer (et faire même des modifications aux nœuds de périphériques).

7.4.2.2. Création de nœuds de périphérique

Les fichiers de périphérique sont créés par le noyau avec le système de fichiers devtmpfs. Tout pilote souhaitant enregistrer un nœud de périphérique ira dans devtmpfs (par le cœur du pilote) pour le faire. Quand une instance devtmpfs est montée sur /dev, le nœud de périphérique sera créé dès le départ avec un nom, des droits et un propriétaire figés.

Peu de temps après, le noyau enverra un uevent à udevd. À partir des règles indiquées dans les fichiers contenus dans les répertoires /etc/udev/rules.d, /lib/udev/rules.d et /run/udev/rules.d, udevd créera les liens symboliques supplémentaires vers le nœud de périphérique, ou bien il modifiera ses droits, son propriétaire ou son groupe, ou l'entrée dans la base de données interne d'udevd concernant cet objet.

Les règles de ces trois répertoires sont numérotées de la même façon que dans le paquet LFS-Bootscripts et les trois répertoires sont mis à jour ensemble. Si udevd ne peut pas trouver de règles pour le périphérique qu'il crée, il en donnera la propriété et les droits à n'importe quel devtmpfs utilisé au départ.

7.4.2.3. Les scripts de démarrage d'Udev

Le premier script de démarrage de LFS, /etc/init.d/mountvirtfs, va copier les périphériques de /lib/udev/devices vers /dev. C'est nécessaire car certains périphériques, certains répertoires et certains liens symboliques sont requis avant que les processus de gestion dynamique des périphériques ne soient disponibles au tout début du démarrage d'un système ou car ils sont exigés par udevd lui-même. La création de nœuds de périphériques statiques dans /lib/udev/devices offre aussi un contournement facile pour les périphériques qui ne sont pas supportés par l'infrastructure de gestion dynamique des périphériques.

Le script de démarrage /etc/rc.d/init.d/udev démarre udevd, récupère tous les périphériques "montés à froid" ayant déjà été créés par le noyau et attend les règles pour se terminer. Le script défait aussi le gestionnaire d'uevent de son paramétrage par défaut /sbin/hotplug . Cela se fait car le noyau n'a plus besoin d'appeler de binaires externes. À la place, udevd listera sur une socket netlink les uevents que le noyau détecte.

Le script de démarrage /etc/rc.d/init.d/udev_retry prend soin de ratraper les événements pour les sous-systèmes dont les règles peuvent s'appuyer sur des systèmes de fichiers non montés jusqu'à ce que le script mountfs ne s'exécute (en particulier, /usr et /var peut causer cela). Ce script se lance après le script mountfs, afin que les règles (si récupérées), réussissent la deuxième fois. Il est configuré à partir du fichier /etc/sysconfig/udev_retry ; tous les mots de ce fichier différents de commentaires sont considérés comme des noms de sous-systèmes pour les récupérer lors de la nouvelle tentative. Pour trouver le sous-système d'un périphérique, utilisez udevadm info --attribute-walk <périphérique> où <périphérique> est un chemin absolu dans /dev ou /sys tel que /dev/sr0 ou /sys/class/rtc.

7.4.2.4. Chargement d'un module

Il se peut que les pilotes des périphériques compilés en module aient aussi des alias compilés. Les alias sont visibles dans la sortie du programme modinfo et sont souvent liés aux identifiants spécifiques du bus des périphériques supportés par un module. Par exemple, le pilote snd-fm801 supporte les périphériques PCI ayant l'ID fabricant 0x1319 et l'ID de périphérique 0x0801 a aussi un alias « pci:v00001319d00000801sv*sd*bc04sc01i* ». Pour la plupart des périphériques, le pilote du bus définit l'alias du pilote qui gérerait le périphérique via sysfs. Par exemple, le fichier /sys/bus/pci/devices/0000:00:0d.0/modalias pourrait contenir la chaîne « pci:v00001319d00000801sv00001319sd00001319bc04sc01i00 ». Il résultera des règles fournies par défaut qu'udevd fera appel à /sbin/modprobe avec le contenu de la variable d'environnement de l'uevent MODALIAS (qui devrait être la même que le contenu du fichier modalias dans sysfs), donc chargera tous les modules dont les alias correspondent à cette chaîne après les expansions génériques.

Dans cet exemple, cela signifie que, outre snd-fm801, le pilote obsolète (et non désiré) forte sera chargé s'il est disponible. Voir ci-dessous les moyens d'empêcher le chargement des modules indésirables.

Le noyau lui-même est aussi capable de charger des modules de protocole réseau, de support pour des systèmes de fichiers et des NLS sur demande.

7.4.2.5. Gestion des périphériques dynamiques ou montables à chaud

Quand vous connectez un périphérique, comme un lecteur MP3 USB, le noyau reconnaît que le périphérique est maintenant connecté et génère un uevent. Cet uevent est alors géré par udevd comme décrit ci-dessus.

7.4.3. Problèmes avec le chargement des modules et la création des périphériques

Il existe quelques problèmes connus pour la création automatique des nœuds de périphériques :

7.4.3.1. Un module noyau n'est pas chargé automatiquement

Udev ne chargera un module que s'il a un alias spécifique au bus et que le pilote du bus envoie correctement les alias nécessaires vers sysfs. Sinon, il faut organiser le chargement des modules par d'autres moyens. Avec Linux-3.13.3, Udev est connu pour charger les pilotes correctement écrits pour les périphériques INPUT, IDE, PCI, USB, SCSI, SERIO et FireWire.

Pour déterminer si le pilote du périphérique dont vous avez besoin a le support nécessaire pour Udev, lancez modinfo avec le nom du module en argument. Puis, essayez de localiser le répertoire du périphérique sous /sys/bus et vérifiez s'il y a un fichier modalias.

Si le fichier modalias existe dans sysfs, alors le pilote supporte le périphérique et peut lui parler directement, mais s'il n'a pas d'alias, c'est un bogue dans le pilote. Chargez le pilote sans l'aide d'Udev et attendez que le problème soit corrigé plus tard.

S'il n'y a pas de fichier modalias dans le bon répertoire sous /sys/bus, cela signifie que les développeurs du noyau n'ont pas encore ajouté de support modalias à ce type de bus. Avec Linux-3.13.3, c'est le cas pour les bus ISA. Attendez que ce problème soit réparé dans les versions ultérieures du noyau.

Udev n'a pas du tout pour but de charger des pilotes « wrapper » (qui emballent un autre pilote) comme snd-pcm-oss et des pilotes non matériels comme loop.

7.4.3.2. Un module du noyau n'est pas chargé automatiquement et Udev n'est pas prévu pour le charger

Si le module « wrapper » n'améliore que la fonctionnalité fournie par un autre module (comme snd-pcm-oss améliore la fonctionnalité de snd-pcm en rendant les cartes son disponibles pour les applications OSS), configurez modprobe pour charger le wrapper après qu'Udev ait chargé le module emballé. Pour cela, ajoutez une ligne « softdep » dans tous les fichiers /etc/modprobe.d/<filename>.conf. Par exemple :

softdep snd-pcm post: snd-pcm-oss

Remarquez que la commande « softdep » autorise aussi les dépendances pre:, ou un mélange de pre: et de post:. Voir la page de manuel de modprobe.d(5) pour plus d'informations sur la syntaxe et les possibilités de « softdep ».

Si le module en question n'est pas un emballage et s'avère utile en tant que tel, configurez le script de démarrage modules pour charger ce module sur le système de démarrage. Pour cela, ajoutez le nom du module au fichier /etc/sysconfig/modules sur une ligne séparée. Ceci fonctionne aussi pour les modules d'emballage, mais sans être optimal.

7.4.3.3. Udev charge un module indésirable

Ne compilez pas le module, ou mettez-le en liste noire dans un fichier /etc/modprobe.d/blacklist.conf comme nous l'avons fait avec le module forte dans l'exemple ci-dessous :

blacklist forte

Les modules en liste noire peuvent toujours être chargés manuellement avec la commande explicite modprobe.

7.4.3.4. Udev crée mal un périphérique, ou crée un mauvais lien symbolique

Cela se produit habituellement si une règle correspond à un périphérique de façon imprévue. Par exemple, une règle lacunaire peut correspondre à un disque SCSI (comme désiré) et au périphérique SCSI générique du même fabricant (de façon incorrecte). Trouvez la règle défectueuse et affinez-la, à l'aide de la commande udevadm info

7.4.3.5. Une règle Udev fonctionne de manière non fiable

Cela peut être une autre manifestation du problème précédent. Sinon, et si votre règle utilise les attributs de sysfs, il se peut que ce soit un problème de timing du noyau, sur le point d'être corrigé dans les noyaux ultérieurs. Pour le moment, vous pouvez contourner en créant une règle qui attend l'attribut sysfs utilisé et en le mettant dans le fichier /etc/udev/rules.d/10-wait_for_sysfs.rules (créez ce fichier s'il n'existe pas). Merci d'informer la liste de développement de LFS si vous faites ainsi et que cela vous aide.

7.4.3.6. Udev ne crée pas de périphérique

Le texte ci-après suppose que le pilote est compilé de manière statique dans le noyau ou qu'il est déjà chargé comme module, et que vous avez déjà vérifié qu'Udev ne crée pas de périphérique mal nommé.

Udev n'a pas besoin d'information pour créer un nœud de périphérique si le pilote du noyau n'envoie pas ses données vers sysfs. C'est ce qu'il y a de plus courant avec les pilotes tierce partie à l'extérieur de l'arborescence du noyau. Créez un nœud de périphérique statique dans /lib/udev/devices avec les numéros majeurs/mineurs appropriés (voir le fichier devices.txt dans la documentation du noyau ou la documentation fournie par le fabricant du pilote tierce partie). Le nœud du périphérique statique sera copié vers /dev par le script de démarrage udev.

7.4.3.7. L'ordre de nommage des périphériques change de manière aléatoire après le redémarrage

Cela est dû au fait qu'Udev, par nature, gère les uevents et charge les modules en parallèle, donc dans un ordre imprévisible. Cela ne sera jamais « corrigé ». Vous ne devriez pas supposer que les noms des périphériques du noyau sont stables. Créez plutôt vos propres règles qui rendent les liens symboliques stables basés sur des attributs stables du périphérique, comme une série de nombre ou la sortie de divers utilitaires *_id installés par Udev. Voir la Section 7.5, « Création de liens symboliques personnalisés vers les périphériques » et la Section 7.2, « Configuration générale du réseau » pour des exemples.

7.4.4. Lecture utile

Des documentations supplémentaires sont disponibles sur les sites suivants :