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

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 struture du système des 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.

Le système de fichiers sysfs a été brièvement mentionné ci-dessus. On pourrait se demander comment sysfs connait 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, ceci 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/udev comme gestionnaire d'événements de montage à chaud. Ces événements (discutés plus bas) ne devraient pas être 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 droits de chaque périphérique que udevstart crée sont initialisés en utilisant les fichiers du répertoire /etc/udev.d/permissions.d/. Ils sont numérotés de la même façon que les scripts de démarrage LFS. Si udev ne trouve pas un fichier de droits pour le périphérique en cours de création, il utilise les droits par défaut, 600, et donne l'appartenance du périphérique à root:root. Les noms des nœuds créés sous le répertoire /dev sont configurés en respectant les règles spécifiées dans les fichiers à l'intérieur du répertoire /etc/udev/rules.d/.

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. Qu'en est-il des 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é udev 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.

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é, alors connecter le périphérique au système fera que le pilote du bus du noyau génèrera un événement de montage à chaque notifiant l'espace utilisateur de la connexion du nouveau périphérique et le fait qu'il n'est pas rattaché à un pilote. En fait, rien ne se passe et le périphérique lui-même n'est pas encore utilisable.

Si vous avez construit un système qui comprend beaucoup de pilotes compilés en tant que modules plutôt que directement intégrés au noyau, utiliser S05modules pourrait ne pas être pratique. Le paquet Hotplug (voir http://linux-hotplug.sourceforge.net/) peut être bénéfique dans ces cas. Lorsque le paquet Hotplug package est installé, il répondra aux événements de montage à chaud du pilote du bus du noyau. Le paquet Hotplug chargera le module approprié et rendra ce périphérique disponible en créant le(s) nœud(s) pour lui.

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. Ces pilotes n'auront pas leur nœuds créés. Utilisez le fichier de configuration /etc/sysconfig/createfiles pour créer manuellement les périphériques. Consultez le fichier devices.txt à l'intérieur de la documentation du noyau ou la documentation venant avec ce pilote pour trouver les bons nombres majeurs et mineurs.

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 :

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