9.4. Gérer les périphériques

9.4.1. Périphériques réseaux

Udev, par défaut, nomme les périphériques réseaux à partir des données du logiciel embarqué/BIOS ou des caractéristiques physiques comme leur bus, leur slot ou leur adresse MAC. Le but de cette convention de nommage est de s'assurer que les périphériques réseaux sont nommés de façon cohérente et non en fonction du moment où la carte réseau a été trouvée. Sur des anciennes versions de Linux—sur des ordinateurs avec deux cartes réseaux Intel et Realtek, par exemple, il se peut que la carte réseau Intel soit nommée eth0 et la Realtek soit nommée eth1. Au redémarrage, les cartes sont parfois numérotées en sens inverse.

Avec la nouvelle règle de nommage, les noms des cartes réseaux ressembleraient en général à quelque chose comme enp5s0 ou wlp3s0. Si cette convention de nommage ne vous convient pas, vous pouvez implémenter la convention de nommage traditionnelle ou une personnalisée.

9.4.2. Liens symboliques vers le CD-ROM

Certains logiciels que vous pourriez vouloir installer ultérieurement (comme divers lecteurs multimédias) s'attendent à ce que les liens symboliques /dev/cdrom et /dev/dvd existent et pointent vers le lecteur CD-ROM ou DVD-ROM. De plus, il peut être pratique d'insérer des références à ces liens symboliques dans /etc/fstab. Udev est fourni avec un script qui génèrera des fichiers de règles pour créer ces liens symboliques à votre place, selon les possibilités de chaque périphérique, mais vous devez décider lequel des deux modes opératoires vous souhaitez que le script utilise.

Tout d'abord, le script peut opérer en mode « chemin » (utilisé par défaut pour les périphériques USB et FireWire), où les règles qu'il crée dépendent du chemin physique vers le lecteur CD ou DVD. Ensuite, il peut opérer en mode « id » (par défaut pour les périphériques IDE et SCSI), où les règles qu'il crée dépendent des chaînes d'identification contenues dans le lecteur CD ou DVD lui-même. Le chemin est déterminé par le script path_id d'Udev, et les chaînes d'identification sont lues à partir du matériel par ses programmes ata_id ou scsi_id, selon le type de périphérique que vous possédez.

Il existe des avantages pour chaque approche ; la bonne approche à utiliser dépend des types de changements de périphérique qui peuvent se produire. Si vous vous attendez à ce que le chemin physique vers le périphérique (c'est-à-dire, les ports ou les fentes par lesquels ils sont branchés) change, par exemple parce que vous envisagez de déplacer le lecteur sur un port IDE différent ou un connecteur USB différent, alors vous devriez utiliser le mode « by-id ». D'un autre côté, si vous vous attendez à ce que l'identification du périphérique change, par exemple parce qu'il ne marche plus, et que vous le remplaciez par un périphérique différent avec les mêmes capacités et qui serait monté sur les mêmes connecteurs, vous devriez utiliser le mode « by-path ».

Si les deux types de changement sont possibles avec votre lecteur, choisissez un mode basé sur le type de changement que vous pensez rencontrer le plus fréquemment.

Si vous souhaitez voir les valeurs que les scripts udev utiliseront, alors, pour celles appropriées au périphérique CD-ROM, trouvez le répertoire correspondant sous /sys (cela peut être par exemple /sys/block/hdd) et lancez une commande ressemblant à ce qui suit :

udevadm test /sys/block/hdd

Regardez les lignes contenant la sortie des divers programmes *_id. Le mode « id » utilisera la valeur ID_SERIAL si elle existe et n'est pas vide, sinon il utilisera une combinaison d'ID_MODEL et d'ID_REVISION. Le mode « chemin » utilisera la valeur d'ID_PATH.

Si le mode par défaut ne convient pas à votre situation, vous pouvez faire la modification suivante du fichier /etc/udev/rules.d/83-cdrom-symlinks.rules, comme suit, (où mode est soit « by-id » soit « by-path ») :

sed -e 's/"write_cd_rules"/"write_cd_rules mode"/' \
    -i /etc/udev/rules.d/83-cdrom-symlinks.rules

Remarquez qu'il n'est pas nécessaire de créer les fichiers de règles ou les liens symboliques à ce moment puisque vous avez monté en bind le répertoire /dev du système hôte dans le système LFS, et nous supposons que les liens symboliques existent sur l'hôte. Les règles et les liens symboliques seront créés la première fois que vous démarrerez votre système LFS.

Cependant, si vous avez plusieurs lecteurs CD-ROM, les liens symboliques générés à ce moment peuvent pointer vers des périphériques différents de ceux vers lesquels ils pointent sur l'hôte, car les périphériques ne sont pas découverts dans un ordre prévisible. Les affectations créées quand vous démarrerez pour la première fois le système LFS seront stables, donc cela n'est un problème que si vous avez besoin que les liens symboliques sur les deux systèmes pointent vers le même périphérique. Si tel est le cas, inspectez (et éditez peut-être) le fichier /etc/udev/rules.d/70-persistent-cd.rules généré après le démarrage pour vous assurer que les liens symboliques affectés correspondent à ce dont vous avez besoin.

9.4.3. Gérer des périphériques dupliqués

Comme expliqué à la Section 9.3, « Manipulation des périphériques et modules », l'ordre dans lequel les périphériques ayant la même fonction apparaissent dans /dev est essentiellement aléatoire. Par exemple, si vous avez une webcam USB et un récepteur TV, parfois /dev/video0 renvoie à la webcam, et /dev/video1 renvoie au récepteur, et parfois après un redémarrage l'ordre d'apparition des périphériques s'inverse. Pour toutes les classes de matériel sauf les cartes son et les cartes réseau, ceci peut se corriger en créant des règles udev pour créer des liens symboliques constants. Le cas des cartes réseau est traité séparément dans Section 9.5, « Configuration générale du réseau », et vous pouvez trouver la configuration des cartes son dans BLFS.

Pour chacun des périphériques susceptibles d'avoir ce problème (même si le problème n'apparaît pas dans votre distribution Linux actuelle), trouvez le répertoire correspondant sous /sys/class ou /sys/block. Pour les périphériques vidéo, cela peut être /sys/class/video4linux/videoX. Calculez les attributs qui identifient de façon unique un périphérique (normalement basé sur l'ID du fabricant et du produit ou les numéros de série) :

udevadm info -a -p /sys/class/video4linux/video0

Puis, écrivez des règles qui créent les liens symboliques, comme :

cat > /etc/udev/rules.d/83-duplicate_devs.rules << "EOF"

# Persistent symlinks for webcam and tuner
KERNEL=="video*", ATTRS{idProduct}=="1910", ATTRS{idVendor}=="0d81", SYMLINK+="webcam"
KERNEL=="video*", ATTRS{device}=="0x036f",  ATTRS{vendor}=="0x109e", SYMLINK+="tvtuner"

EOF

Il en résulte que les périphériques /dev/video0 et /dev/video1 renvoient encore de manière aléatoire au tuner et à la webcam (et donc ne devrait jamais être utilisé directement), mais certains des liens symboliques /dev/tvtuner et /dev/webcam pointent toujours vers le bon périphérique.