Gestion des périphériques et modules sur un système LFS

Dans Chapitre 6, nous avons installé le paquet Udev. Avant d'aller 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.

Les systèmes Linux en général utilisent traditionnellement une méthode de création de périphériques statiques avec laquelle un grand nombre de n½uds périphériques est créé sous /dev (quelque fois des milliers de n½uds ), quel le matériel correspondant existe ou pas. Ceci se 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 périphériques détectés par le noyau obtiennent des n½uds périphériques créés pour eux. Comme ces n½uds périphériques seront créés à chaque lancement du système, ils seront stockés dans un tmpfs (un système de fichiers qui réside entièrement en mémoire). Les n½uds périphériques ne requièrent pas beaucoup d'espace disque, donc la mémoire utilisée est négligeable.

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 le source du noyau, cette méthode de création dynamique de périphérique 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 pas imposée par un développeur particulier. Le système de fichiers devfs souffre aussi de conditions particulières inhérentes à son concept et ne peut pas être corrigé sans une revue importante du noyau. Il a aussi été marqué comme obsolète à cause d'un manque de maintenance.

Avec le développement du noyau instable 2.5, sorti ensuite en tant que la série 2.6 des noyaux stables, un nouveau système de fichiers virtuel appelé sysfs est arrivé. Le travail 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 de l'espace utilisateur, la possibilité de voir une remplacement de l'espace utilisateur pour devfs est devenu beaucoup plus réaliste.

Implémentation d'Udev

Le système de fichiers 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 leur objet avec sysfs 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 fichiers 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 qu'à udev pour la création des n½uds périphériques.

Le script de démarrage S10udev fait attention à créer les n½uds périphériques au lancement de Linux. Ce script commence en enregistrant /sbin/udevsend comme gestionnaire d'événements de montage à chaud. Ces événements (discutés plus bas) ne sont généralement pas générés lors de cette étape mais udev est enregistré juste au cas où cela se passerait quand même. Le programme udevstart parcourt le système de fichiers /sys et crée les périphériques sous /dev correspondant à ces descriptions. Par exemple, /sys/class/tty/vcs/dev contient la chaîne « 7:0 ». Cette chaîne est utilisée par udevstart pour créer /dev/vcs avec le nombre majeur 7 et le nombre mineur 0. Les noms et droits des n½uds créés sous le répertoire /dev sont configurés suivant les règles spécifiées dans les fichiers du répertoire /etc/udev/rules.d/. Ils sont numérotés d'une façon similaire au paquetage LFS-Bootscripts. Si udev ne peut as trouver une règle pour le périphérique en cours de création, celui-ci aura les droits par défaut (660) et son propriétaire sera root:root.

Une fois l'étape ci-dessus terminée, tous les périphériques qui étaient déjà présents et ont des pilotes intégrés au noyau seront disponibles pour utilisation. Ceci nous amène aux périphériques qui ont des pilotes sous forme de modules.

Plus tôt, nous avons mentionné le concept d'un « gestionnaire d'événements de montage à chaud ». Quand la connexion d'un nouveau périphérique est détectée par le noyau, le noyau générera un événement de montage à chaud et regardera dans le fichier /proc/sys/kernel/hotplug pour trouver le programme en espace utilisateur qui gère la connexion du périphérique. Le script de démarrage udev a enregistré udevsend comme gestionnaire. Quand ces événements sont générés, le noyau indiquera à udev de vérifier le système de fichiers /sys pour des informations sur le nouveau périphérique et pour créer son entrée /dev.

Ceci nous amène au problème d'udev, mais aussi avec devfs. Il est habituellement référencé comme le « problème de l'oelig;uf et de la poule ». La plupart des distributions Linux gère le chargement des modules via des entrées dans /etc/modules.conf. L'accès à un n½ud périphérique implique le chargement du module du noyau. Avec udev, cette méthode ne fonctionnera pas car le n½ud périphérique n'existe pas tant que le module n'est pas chargé. Pour résoudre ceci, le script de démarrage S05modules a été ajouté au paquet lfs-bootscripts, avec le fichier /etc/sysconfig/modules. En ajoutant les noms de modules au fichier modules, ces modules seront chargés lorsque l'ordinateur démarrera. Ceci permet à udev de détecter les périphériques et de créer les n½uds périphériques appropriés.

Notez que sur les machines lentes ou pour les pilotes qui créent un grand nombre de n½uds périphériques, le processus de création des périphériques pourrait prendre quelques secondes pour se terminer. Ceci signifie que certains n½uds périphériques pourraient ne pas être accessibles immédiatement.

Gestion des périphériques dynamiques/montables à chaud

Lorsque 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 événement de montage à chaud. Si le pilote a déjà été chargé (soit parce qu'il était compilé dans le noyau soit parce qu'il a été chargé via le script de démarrage S05modules), udev sera appelé pour créer le(s) n½ud(s) périphérique correspondant suivant les données de sysfs disponibles dans /sys.

Si le pilote du périphérique tout juste connecté est disponible comme module mais actuellement non chargé, le paquetage Hotplug chargera les modules appropriés et rendra ce périphérique disponible en créant le(s) n½ud(s) périphérique(s) qui le concernent.

Problèmes avec la création des périphériques

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

1) Un pilote du noyau pourrait ne pas exporter ses données dans sysfs.

Ceci est plus fréquent avec les pilotes de tierces parties, à l'extérieur du noyau. Udev ne sera pas capable de créer automatiquement les n½uds périphériques pour de tels pilotes. Utilisez le fichier de configuration /etc/sysconfig/createfiles pour créer manuellement les périphériques. Consultez le fichier devices.txt dans la documentation du noyau ou la documentation pour trouver les bons numéros majeurs et mineurs pour ce périphérique.

2) Un périphérique non matériel est requis. Ceci est plus fréquent avec le module de compatibilité OSS (acronyme de Open Sound System) du projet ALSA (Advanced Linux Sound Architecture). Ces types de périphériques peuvent être gérés de deux façons différentes :

  • Ajouter les noms des modules à /etc/sysconfig/modules

  • Utiliser une ligne « install » dans /etc/modprobe.conf. Ceci indique à la commande modprobe « au chargement du module, de charger aussi cet autre module, au même moment. » Par exemple :

    install snd-pcm modprobe -i snd-pcm ; modprobe \
        snd-pcm-oss ; true

    Ceci fera que le système charge à la fois les modules snd-pcm et snd-pcm-oss quand toute requête est faite pour charger le pilote snd-pcm.

Lecture utile

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