Guide udev pour GentooLes personnes qui ne connaissent pas du tout Linux seraient certainement étonnées d'entendre des Linuxiens dire « slash dev slash bidule » pour désigner un périphérique. Par contre, pour des Linuxiens comme nous, /dev/hda1 représente simplement la première partition du disque maître connecté sur l'interface IDE primaire. Nous savons ce qu'est un fichier de périphérique, certains savent même que les fichiers de périphériques ont des numéros que l'on peut voir en faisant ls -l dans /dev. Cependant, nous considérons que /dev/hda correspondra toujours au premier disque IDE. Cela vous étonnera sans doute, mais c'est une erreur de conception. Pensez aux périphériques qui peuvent être connectés à chaud (c-à-d. quand la machine est déjà allumée) comme les périphériques USB, IEEE1394 (Firewire) ou certaines cartes PCI. Quel est le premier périphérique dans ce cas ? Les autres périphériques doivent-ils être renommés quand un périphérique est déconnecté ? Quel sera l'impact sur les processus en cours ? Imaginez que votre document envoyé à votre nouvelle imprimante laser arrive sur votre vieille imprimante matricielle parce vous avez oublié de l'allumer. Voilà pourquoi udev a été créé. Les objectifs du projet udev sont intéressants et surtout nécessaires :
Pour atteindre ces objectifs, udev a été développé en trois sous-projets : namedev, libsysfs et, bien sûr, udev. Namedev permet de nommer les périphériques indépendamment de udev. Ceci permet d'utiliser des règles de nommage souples définies par des entités différentes. Ce sous-système de nommage fournit une interface standard utilisée par udev. Actuellement, le seul sous-système de nommage est fournit par LANANA et est utilisé par la plupart des systèmes Linux actuels. La majorité des utilisateurs de Linux l'utiliseront. Namedev utilise une procédure à cinq étapes pour attribuer un nom à un périphérique. Dès qu'un nom peut être attribué, la procédure s'arrête et le nom est attribué. Ces étapes sont :
La première étape consiste à détecter un « label » ou un numéro de série qui pourrait identifier le périphérique. Par exemple, un appareil USB possède un numéro de série unique ; un périphérique SCSI a un code UUID unique. Si namedev trouve une correspondance entre un tel identifiant et un fichier de configuration, le nom indiqué dans ce fichier sera utilisé. Ensuite, namedev essaie d'identifier le périphérique en fonction du numéro du bus sur lequel il est branché. Dans le cas de périphériques qui ne sont jamais déconnectés, ceci suffit généralement. Par exemple, le numéro de bus d'une carte PCI change très rarement. Si namedev trouve un fichier de configuration qui correspond à ce numéro de bus, le nom indiqué dans ce fichier sera utilisé. De façon similaire, l'attribution d'un nom selon la topologie du bus permet une définition statique des périphériques pour autant que l'utilisateur ne permute pas les périphériques. Quand la position d'un appareil sur le bus sur lequel il est connecté correspond à un fichier de configuration défini par l'utilisateur, le nom qui y est indiqué est utilisé. La quatrième étape consiste à attribuer un nom de façon statique en fonction d'une chaîne de caractères. Si le nom par défaut du périphérique tel qu'il est connu par le noyau correspond à une chaîne de caractères donnée, le nom associé à celle-ci est utilisé. Finalement, c'est le nom attribué par le noyau qui sera utilisé par défaut. Dans la majorité des cas, ceci permet de conserver les noms utilisés actuellement. Le dialogue entre udev et le noyau passe par le pseudo-système de fichiers sysfs. Le projet libsysfs offre une interface de programmation standard et générique avec le système de fichiers sysfs. Ceci permet d'interroger toutes sortes de périphériques sans devoir en connaître le type. Chaque fois que le noyau reçoit un évènement relatif aux périphériques, comme un nouvel appareil que l'utilisateur connecte, il demande à udev de s'en occuper. udev suit les règles qui se trouvent dans le répertoire /etc/udev/rules.d/ en conjonction avec les informations apportées par le noyau pour déterminer quelles actions doivent être exécutées sur la structure de fichiers /dev (créer ou supprimer des fichiers de périphériques). Pour utiliser udev, vous devez installer un noyau 2.6.x comme gentoo-sources avec un profil 2007.0. Vous devez aussi utiliser une version récente de sys-apps/baselayout.
À propos du noyau, veuillez vérifier que les options suivantes ont été sélectionnées :
Si vous utilisez genkernel, n'oubliez pas l'option --udev. Cette option suffit pour sélectionner toutes les options du noyau requises pour udev. Si vous voulez utiliser les fignolages apportés par les développeurs Gentoo pour vous faciliter la vie, n'allez pas plus loin. Gentoo utilisera udev mais gardera un /dev statique afin qu'il ne vous manque pas de périphérique. Les scripts d'initialisation de Gentoo ne lanceront pas le démon devfsd et désactiveront devfs au démarrage. Cependant, si vous êtes un acharné qui veut un système 100% udev tel qu'il a été voulu par ses développeurs, y compris avec les difficultés causées par les périphériques absents par faute de support, alors lisez ce qui suit :) Commençons par désactiver le système de sauvegarde des définitions des fichiers de périphériques. Initialisez la variable RC_DEVICE_TARBALL à no dans le fichier /etc/conf.d/rc :
Si le support de devfs a été compilé dans votre noyau, vous pouvez le désactiver dans la configuration de votre chargeur de démarrage en passant l'option gentoo=nodevfs au noyau. Si vous voulez utiliser devfs et désactiver udev, passez l'option gentoo=noudev. Fichiers de périphériques absents Si votre système ne démarre pas correctement parce que /dev/null n'existe pas ou que la console n'est pas définie, le problème est que des fichiers de périphériques devraient exister dans /dev avant que udev ne monte /dev. Ce problème est fréquent sur des anciennes installations de Gentoo. Si vous utiliser sys-apps/baselayout-1.8.12 ou une version plus récente, votre système démarrera, mais affichera des messages d'avertissement. Pour les faire disparaître, il suffit de créer les fichiers de périphériques qui manquent. Pour voir quels fichiers de périphériques existent dans /dev avant que le système de fichiers dev ne soit monté, utilisez les commandes suivantes :
Les fichiers de périphériques nécessaires lors du démarrage sont /dev/null et /dev/console. Si le test effectué ci-dessus révèle qu'ils manquent, vous devez les ajouter. Exécutez les commandes ci-dessous dans le répertoire test/dev/ :
N'oubliez pas ensuite de démonter le répertoire test/.
Si vous utilisez les pilotes propriétaires de nVidia et que le serveur X ne démarre pas sur un système qui n'utilise que udev, veuillez vérifier les éléments suivants :
Les noms des périphériques sont différents entre DevFS et udev Bien que nous nous efforcions de conserver des noms de périphériques identiques entre DevFS et udev, des différences sont parfois inévitables. Un exemple connu est la carte RAID Smart Array 5i de HP, plus précisément, le module cciss. Avec udev, les périphériques sont nommés /dev/cciss/cXdYpZ où X, Y et Z sont des nombres. Avec DevFS, ils s'appellent /dev/hostX/targetY/partZ ou sont liés depuis /dev/cciss/cXdY. Si vous êtes confrontés à un tel cas, n'oubliez pas de mettre à jour votre fichier /etc/fstab et la configuration de votre chargeur de démarrage. Des problèmes similaires peuvent se produire à cause des liens symboliques qui existaient dans /dev (/dev/mouse par exemple) et que udev ne crée pas. Veuillez vérifier que votre configuration de X utilise un périphérique défini. Un autre problème possible est dû aux noms attribués aux terminaux. Ceux créés par devfs sont nommés tty, mais udev les nomme vc et tty. Cela peut causer un problème si vous restreignez l'accès à root sur les consoles en utilisant le fichier /etc/securetty. Vous devez vérifier que tty1 et vc/1 figurent dans ce fichier pour permettre à root de se connecter via la console. Les versions récentes d'udev (104 et supérieures) avec les nouvelles versions du noyau (2.6.19 et supérieures) permettent de renommer vos périphériques, grâce à un changement dans l'implémentation de la bibliothèque libata du noyau. Un périphérique CD-RW en /dev/hdc peut être changé en /dev/sr0. Si ce n'est normalement pas un souci, cela peut causer des problèmes à certaines applications codées en dur pour chercher les périphériques aux autres emplacements. Par exemple, media-sound/rip s'attend à trouver les disques dans /dev/cdrom, ce qui devient un problème si vous utilisez un nouveau noyau et que udev renomme votre périphérique en /dev/cdrom1. Pour contourner ces problèmes, vous devez éditer le fichier /etc/udev/rules.d/70-persistent-cd.rules et assigner au périphérique le nom correct. Pour plus d'informations sur l'écriture des règles udev, reportez-vous au guide de Daniel Drake. udev charge les modules dans un ordre aléatoire Il arrive qu'udev charge les modules dans un ordre indésiré, imprévisible ou qui semble aléatoire. Cela apparaît surtout sur les systèmes qui possèdent plusieurs périphériques de même type, tels que les périphériques multimédia. Cela peut affecter les numéros assignés aux périphériques ; par exemple, les cartes son échangent parfois leur numéro. Il existe plusieurs solutions pour fixer les numéros de périphériques et/ou l'ordre de chargement des modules. Dans le meilleur des cas, vous pouvez simplement utiliser les paramètres du module pour spécifier le numéro désiré au périphérique. Certains modules, tels qu'ALSA, incluent le paramètre « index ». Les modules qui utilisent ce paramètre peuvent être ajustés comme indiqué. Cet exemple concerne un système avec deux cartes son. La carte avec l'indice 0 est désignée comme la première carte. Une fois que les paramètres sont changés, les fichiers de configuration des modules doivent être mis à jour.
La solution dans l'exemple ci-dessus est celle qui est préférée mais tous les modules ne possèdent pas un paramètre tel que l'indice. Pour ceux-là, vous devrez forcer l'ordre correct de chargement des modules. Tout d'abord, vous devez empêcher udev de charger automatiquement les modules en les mettant sur la liste noire. Assurez-vous d'utiliser le nom exact du module qui est chargé. Pour les périphériques PCI, vous devrez utiliser les noms des modules obtenus sur la sortie de la commande pcimodules, disponible dans le paquet pciutils. L'exemple suivant illustre le cas des modules DVB.
Ensuite, chargez les modules dans l'ordre correct. Ajoutez-les au fichier /etc/modules.autoload.d/kernel-2.6 dans l'ordre exact où vous voulez qu'ils soient chargés.
Si un fichier de périphérique n'est pas créé quand un module est chargé via /etc/modules.autoload.d/kernel-2.6, mais qu'il est bien créé quand vous chargez le module avec modprobe, vous devez installer sys-apps/baselayout-1.8.12 ou une version plus récente. Le support du framebuffer (fichiers de périphériques /dev/fb/*) est disponible à partir de la version 2.6.6-rc2 du noyau. Avec des noyaux avant la version 2.6.4, vous devez inclure explicitement le support du système de fichiers /dev/pts.
L'exposé de Greg Kroah-Hartman (IBM Corporation) au Linux Symposium (Ottawa, Ontario Canada - 2003) a permis une bonne compréhension du système udev. L'article de Decibel (en anglais) traite en profondeur de udev sur systèmes Gentoo. L'article de Daniel Drake (en anglais) est un excellent document sur la configuration de udev. Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5. |
|
