À propos des périphériques

Bien que la plupart des périphériques dont ont besoin les paquets de BLFS ont été correctement paramétrés par udev en utilisant les règles par défaut installées par LFS dans /etc/udev/rules.d, il y a des cas où il faut modifier ou ajouter des règles.

Notes utilisateur : http://wiki.linuxfromscratch.org/blfs/wiki/aboutdevices

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 existe 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 noeud de périphérique USB "direct", une application peut echangé arbitrairement des paquets USB avec le périphérique, c'est à dire, court-circuité 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 succes 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 direct sont propriétés de l'utilisateur root et du groupe usb, et ont la permission 0664 (l'acces en lecture est nécéssaire, e.g., pour que lsusb puisse travailler et pour les programmes d'access aux concentrateurs USB). Des paquets (comme SANE et libgphoto2) contenant un driver de périphérique USR dans l'espace utilisateur utilisent aussi les regles udev pour changer les permissions des périphériques USB controllé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 controle d'acces fin avec des règles udev prégénérée ne marche pas. Nomé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 necessaires pour que cela fonctionne dans les point de montage obsolete /proc/bus/usb décris précédement). 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 ecrire des règles udev séparés pour tous les périphériques USB nécéssaire vous même, ou utiliser les règles par défaut du groupe "usb", les membres de celui-çi peuvent envoyé des commandes arbitraires pour tous périphériques USB.

Avant Linux-2.6.15, l'acces 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 dépréciée 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 acces complet à tous les périphériques USB. Pour créer l'entrée fstab pour le fichier système obsolete usbfs:

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

Note

Ajouter les utilisateurs dans le groupe "usb" est par nature insécurisé, car cela court-circuite les restrictions d'acces imposés par les drivers spécifiques des noeuds de périphérique USB. Par nature, ils peuvent lire des données sensibles des disques USB sans être dans le group "disque". Evité d'ajouter des utilisateurs dans ce groupe si vous le pouvez.

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"
[Note]

Note

On n'utilise la ligne ci-dessus qu'à des fins descriptives. Les règles d'analyse d'udev sont mises en place lors de l'installation de SANE-1.0.19.

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 vadministrateur 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/rcsysinit.d/S10udev monte une partition tmpfs dans le répertoire /dev. Ce problème peut être résolu en montant temporairement la partition racine :

[Avertissement]

Avertissement

Si vous ne suivez pas rigoureusement les instructions ci-dessous, votre système pourrait ne plus pouvoir démarrer.

mount --bind / /mnt
cp -a /dev/* /mnt/dev
rm /etc/rc.d/rcsysinit.d/{S10udev,S45udev_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/rcsysinit.d/{S10udev,S45udev_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 partitcon tmpfs. L'utilisation du disque par des périphériques est négligible (environ 20–30 octets par entrée.)

Last updated on 2011-11-16 00:41:27 +0100