À propos des périphériques

Cartes sons multiples

S'il y a plusieurs cartes sons sur un système, la carte son « default » (par défaut) devient aléatoire. La méthode pour établir un ordre dans les cartes sons dépend du fait que les pilotes soient en modules ou pas. Si les pilotes de la carte son sont compilés dans le noyau, leur contrôle s'effectue via des paramètres de la ligne de commande du noyau. dans /boot/grub/grub.cfg. Par exemple, si un système contient une carte FM801 et une carte PCI SoundBlaster, ce qui suit peut être envoyé sur la ligne de commande :

snd-fm801.index=0 snd-ens1371.index=1

Si les pilotes de la carte son sont construits en modules, on peut établir l'ordre dans le fichier /etc/modprobe.conf avec :

options snd-fm801 index=0
options snd-ens1371 index=1

Problèmes sur les périphériques USB

Les périphériques USB ont habituellement deux types de noeuds de périphériques associés avec eux.

Le premier type est créé par le driver du périphérique spécifique (usb_storage/sd_mod ou usblp) dans le noyau. Par exemple, un périphérique de stockage USB peut être /dev/sdb, et une imprimpante USB peut être /dev/usb/lp0. Ces noeuds de périphériques existent seulement quand le driver du périphérique spécifique est chargé.

Le second type de noeud de périphériques (/dev/bus/usb/BBB/DDD, ou BBB est le numéro du bus et DDD est le numéro du périphérique) est créé chaque fois que le périphérique n'a pas de driver dans le noyau. En utilisant ces noeuds de périphérique USB "directs", une application peut échanger arbitrairement des paquets USB avec le périphérique, c'est à dire, court-circuiter le possible driver du noyau existant.

Accéder aux noeuds périphérique USB directement est nécessaire quand un programme de l'espace utilisateur est considéré comme un driver de périphérique. Sinon, pour le programme qui ouvre avec succès le périphérique les permissions sont initialisées correctement. Par défaut, pour des considérations de sécurité, tous les périphériques USB directs sont propriétés de l'utilisateur root et du groupe usb, et ont la permission 0664 (l'accès en lecture est nécessaire, e.g., pour que lsusb puisse travailler et pour les programmes d'accès aux concentrateurs USB). Des paquets (comme SANE et libgphoto2) contenant un driver de périphérique USR dans l'espace utilisateur utilisent aussi les règles udev pour changer les permissions des périphériques USB contrôlés. Ce qui fait que, les règles installées par SANE changent les permissions pour les scanners reconnus, mais pas pour les imprimantes. Si le mainteneur du paquet oublie d'écrire une règle pour votre périphérique, signaler le bug à BLFS (si le paquet est ici) et upstream, et vous aurez besoin d'écrire votre propre règle.

Il y a une situation ou un contrôle d'accès fin avec des règles udev prégénérées ne marche pas. Nommément, les émulateurs de PC comme KVM, QEMU et VirtualBox utilisent des noeuds de périphérique USB direct pour les périphériques USB arbitrairement présent dans le système d'exploitation invité (note> : des correctifs sont nécessaires pour que cela fonctionne dans les point de montage obsolete /proc/bus/usb décris précédemment). Naturellement, les mainteneurs de ces paquets ne peuvent pas connaître quels périphériques USB seront connectés sur le système d'exploitation invité. Vous pouvez bien écrire des règles udev séparés pour tous les périphériques USB nécessaire vous même, ou utiliser les règles par défaut du groupe "usb", les membres de celui-ci peuvent envoyé des commandes arbitraires pour tous périphériques USB.

Avant Linux-2.6.15, l'accès direct aux périphériques USB n'était pas géré avec les noeuds de périphériques /dev/bus/usb/BBB/DDD, mais avec des pseudo-fichiers /proc/bus/usb/BBB/DDD. Quelques applications (e.g., VMware Workstation) semblent utiliser seulement cette technique obsolète et ne peuvent pas utiliser les nouveaux noeuds de périphériques. Pour qu'elles puissent fonctionner, utiliser le groupe "usb", mais rappelez vous que les membres ont un accès complet à tous les périphériques USB. Pour créer l'entrée fstab pour le fichier système obsolète usbfs:

usbfs  /proc/bus/usb  usbfs  devgid=14,devmode=0660  0  0

Attributs de périphériques d'Udev

Le peaufinement des attributs de périphériques tels que le nom du groupe et les droits est possible en créant des règles udev supplémentaires, correspondant à quelque chose de ce genre. On peut trouver le fabricant et le produit en cherchant les entrées du répertoire /sys/devices ou en utilisant udevinfo après avoir attaché le périphérique. Voir la documentation dans le répertoire d'udev actuel /usr/share/doc pour des détails.

SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002", \
  GROUP:="scanner", MODE:="0660"

Périphériques pour les serveurs

Dans certains cas, il est utile de désactiver udev complètement et de créer des périphériques statiques. Les serveurs sont un exemple de cette situation. Est-ce qu'un serveur a besoin de la possibilité de gérer des périphériques dynamiques ? Seul l'administrateur système peut répondre à cette question, mais dans de nombreux cas, la réponse est non.

Si vous ne désirez pas de périphériques dynamiques, vous devez créer des périphériques statiques sur le système. Dans la configuration par défaut, le script de démarrage /etc/rc.d/rcS.d/S10udev monte une partition tmpfs dans le répertoire /dev. Ce problème peut être résolu en montant temporairement la partition racine :

mount --bind / /mnt
cp -a /dev/* /mnt/dev
rm /etc/rc.d/rcS.d/{S10udev,S50udev_retry}
umount /mnt

Dès lors, le système utilisera des périphériques statiques lors du prochain redémarrage. Créez les périphériques supplémentaires désirés en utilisant mknod.

Si vous voulez restaurer les périphériques dynamiques, recréez les liens symboliques /etc/rc.d/rcS.d/{S10udev,S50udev_retry} et redémarrez de nouveau. Il n'est pas nécessaire de supprimer les périphériques statiques (console et null sont toujours nécessaires) car ils sont recouverts par la partition tmpfs. L'utilisation du disque par des périphériques est négligeable (environ 20–30 octets par entrée.)