Newsletter Developpez.com

Inscrivez-vous gratuitement au Club pour recevoir
la newsletter hebdomadaire des développeurs et IT pro

Guide d'installation et de configuration de Linux


précédentsommairesuivant

8. Configuration du matériel et des périphériques

Ce chapitre présente les concepts nécessaires à l'installation de cartes filles additionnelles et à la configuration des périphériques complémentaires sous Linux. La procédure d'installation des disques durs, graveurs, cartes son, cartes graphiques, cartes vidéo et cartes réseau sera donc décrite, ainsi que la manière de les configurer pour obtenir un fonctionnement correct sous Linux.

8-1. Généralités sur le support matériel sous Linux

Comme il l'a déjà été expliqué dans les chapitres précédents, Linux gère la plupart des périphériques comme des fichiers spéciaux. De plus, la plupart des gestionnaires de périphériques peuvent être chargés dynamiquement, sous la forme de modules du noyau. Cette section présentera donc les notions de base concernant les modules du noyau, les fichiers spéciaux de périphériques, ainsi que leurs rôles respectifs dans la configuration d'un nouveau matériel. La syntaxe utilisée pour fournir des options au noyau lors de son amorçage et les mécanismes de détection du matériel et de chargement automatique des gestionnaires de périphériques seront également présentés.

8-1-1. Modules du noyau

Les modules du noyau sont des bibliothèques que l'on peut charger dans le noyau lorsque celui-ci a besoin d'une certaine fonctionnalité. Une fois chargés, les modules font partie intégrante du noyau et ajoutent leurs fonctions à celles existantes. Ces bibliothèques sont normalement stockées dans le répertoire /lib/modules/version/, où version est le numéro de version du noyau pour lequel ces modules ont été créés.

Beaucoup de fonctionnalités du noyau peuvent être configurées pour être utilisées sous la forme de modules. Dans le cas des pilotes de périphériques, les modules permettent de réaliser un noyau générique et de prendre en charge dynamiquement les différents périphériques de l'ordinateur. Certains pilotes ne fonctionnent d'ailleurs que sous la forme de modules, aussi faut-il savoir les manipuler. Les modules sont également fortement utilisés pour la configuration automatique des périphériques connectables à chaud.

8-1-1-1. Chargement et déchargement des modules

Les modules peuvent être chargés manuellement à l'aide des commandes insmod et modprobe. modprobe est un peu plus évoluée, car elle gère les dépendances entre les modules et est capable de charger les modules utilisés par le module demandé. Leur utilisation est des plus simple :

 
Sélectionnez
insmod module

ou :

 
Sélectionnez
modprobe module

module est le nom du module à charger.

En réalité, la commande modprobe appelle la commande insmod pour chaque module qui doit être chargé, dans l'ordre des dépendances des modules. De cette manière, chaque module peut être chargé sans problèmes, car toutes les fonctionnalités qu'il utilise sont déjà présentes dans le noyau lors de son chargement. La commande modprobe va chercher les informations de dépendances dans le fichier modules.dep, situé dans le répertoire /lib/module/version/. Ce fichier utilise une syntaxe très simple, et spécifie pour chaque module les modules dont il dépend. Bien qu'il puisse parfaitement être écrit à la main, cela nécessiterait d'avoir une connaissance approfondie des modules du noyau. C'est donc pour cela que l'outil depmod a été écrit. Cet outil permet de générer le fichier modules.dep automatiquement, pourvu qu'on l'appelle avec l'option -a en ligne de commande :

 
Sélectionnez
depmod -a

Il faudra donc appeler cette commande après chaque installation ou suppression de modules dans le système.

La liste de modules qui ont été chargés peut être obtenue aisément avec la commande lsmod :

 
Sélectionnez
lsmod

Enfin, la commande rmmod permet de décharger un module, avec la ligne de commande suivante :

 
Sélectionnez
rmmod module

On préférera cependant l'utilisation de la commande modprobe avec l'option -r pour décharger les modules, car cette commande est capable de décharger récursivement les modules dont dépendait le module à décharger lorsqu'ils ne sont eux-même plus utilisés. La syntaxe est alors la suivante :

 
Sélectionnez
modprobe -r module
Note : En réalité, il n'est généralement pas nécessaire de charger les modules du noyau manuellement pour les pilotes de périphériques. En effet, comme nous allons le voir dans les sections suivantes, Linux dispose de mécanismes permettant de réaliser le chargement des modules de pilotes de périphériques automatiquement, lorsque ces pilotes sont détectés. Toutefois, il est possible que certains périphériques ne soient pas pris en charge par ces mécanismes (notamment les vieux périphériques ISA non Plug and Play).

8-1-1-2. Options des modules

La plupart des modules peuvent prendre un certain nombre d'options lors de leur chargement. Ces options permettent de fixer certains paramètres, et dans le cas des pilotes de périphériques, de préciser la configuration matérielle utilisée.

Les options des modules peuvent être spécifiées en ligne de commande lors de l'appel de insmod ou de modprobe. Toutefois, il est possible d'enregistrer ces options de manière permanente à l'aide du fichier de configuration /etc/modprobe.conf. Lors du chargement d'un module modprobe consulte en effet ce fichier et passe les paramètres indiqués au module à charger.

Afin de faciliter la maintenance du système, modprobe consulte également les fichiers de configuration situés dans le répertoire /etc/modprobe.d/. Ainsi, les options spécifiques à chaque module peuvent être placées dans un fichier de configuration dédié dans ce répertoire.

Le format de ces fichiers de configuration est assez simple, les options de chaque module se définissant sur une ligne commençantpar le mot clé options. Ce mot clé doit être suivi du nom du module pour lequel ces options sont définies, lui-même suivi des paramètres de chargement du module. La syntaxe est donc la suivante :

 
Sélectionnez
options module paramètres

La liste des paramètres que l'on peut passer à un module dépend bien évidemment du module. Vous pouvez obtenir la liste des options supportées par un module à l'aide de l'option -p de la commande modinfo :

 
Sélectionnez
modinfo -p module

Nous verrons par la suite des exemples de passage de paramètres pour les modules les plus courants.

Les fichiers de configuration de modprobe permettent également de définir la manière dont le chargement et le déchargement des modules doit être faite. Pour cela, il permet de spécifier une ligne de commande complète pour ces opérations. Ces lignes de commandes sont introduites via les mots-clefs install et remove. La syntaxe de ces mots-clés est la suivante :

 
Sélectionnez
install module commande
remove module commande

module est le nom du module à charger ou à décharger, et commande est la ligne de commande de l'opération à effectuer pour cela.

Par exemple, si le port parallèle est utilisé pour accéder à un périphérique nécessitant une opération d'initialisation quelconque, celle-ci peut être exécutée lors du chargement du module à l'aide du mot clé install :

 
Sélectionnez
install parport_pc modprobe parport_pc --ignore-install && initperiph

(en supposant que la commande initperiph permet d'initialiser le périphérique en question). Évidemment, ce type d'opération dépend du matériel connecté sur le port parallèle, mais le principe est là. Vous noterez que pour éviter que la commande modprobe ne boucle sur elle-même dans la commande indiquée par la directive install, l'option --ignore-install lui a été fournie. Dans le cas d'une directive remove, il faudrait utiliser l'option --ignore-remove.

Dans la plupart des cas, la définition de ces commandes de chargement et de déchargement sont facultatives, car les modules utilisent généralement un jeu de paramètres implicites qui permettent de les utiliser même si le fichier de configuration modprobe.conf est absent. Vous pouvez visualiser ces options en renommant le fichier de configuration modprobe.conf et en tapant la commande suivante :

 
Sélectionnez
modprobe -c

Cette commande vous permettra également de recréer un nouveau fichier de configuration si d'aventure vous perdiez celui fourni avec votre distribution.

8-1-1-3. Options des périphériques intégrés au noyau

La plupart des fonctionnalités disponibles sous la forme de modules peuvent également être intégrées directement dans le noyau, lors de la compilation de celui-ci. Il est évident qu'il n'est alors pas possible d'utiliser les fichiers de configuration de modprobe pour fixer les valeurs des différentes options que ces fonctionnalités peuvent utiliser. En effet, ces paramètres doivent dans ce cas être définis dès le démarrage du système, et il est nécessaire de les fournir dès le chargement du noyau en mémoire.

Cela se fait, comme nous l'avons vu dans la Section 3.4.7, en fournissant au noyau les paramètres en question sur sa ligne de commande. Nous avons déjà vu comment la quantité de mémoire de l'ordinateur pouvait être passée au noyau à l'aide de l'option mem si elle n'était pas détectée correctement. Il est possible de spécifier de la même manière de nombreuses autres options, en particulier pour activer ou désactiver certains gestionnaires de périphériques ou pour leur indiquer les paramètres du matériel.

Les options fournies au noyau sur sa ligne de commande par le gestionnaire d'amorçage sont lues par le noyau dès son démarrage, afin de fixer les paramètres qu'elles décrivent jusqu'au redémarrage suivant. Pour certaines fonctionnalités, ces paramètres peuvent toutefois être modifiées dynamiquement après le démarrage, via le système de fichiers virtuel /proc/.

Il existe un grand nombre d'options, et leur syntaxe varie en fonction du sous-système qui les utilise. Le fichier de documentation kernel-parameters.txt du répertoire Documentation/ des sources du noyau vous donnera la liste complète de ces options. Nous verrons quelques-unes de ces options spécifiquement dans la suite du chapitre, lorsque nous décrirons les paramètres des gestionnaires de périphériques.

En revanche, les options des modules intégrés au noyau suivent toujours la même syntaxe. Cette syntaxe est la suivante :

 
Sélectionnez
module.paramètre=valeur

module est le nom du module du noyau qui implémente la fonctionnalité lorsqu'elle est utilisée sous la forme de module, paramètre est le nom de l'option de ce module du noyau telle qu'elle est donnée par la commande modinfo, et valeur est sa valeur. Ainsi, si vous voulez intégrer une fonctionnalité d'un module dans le noyau, il suffit simplement d'ajouter les paramètres complémentaires dans la ligne de commande de celui-ci en fonction des options définies dans les fichiers de configuration de modprobe. Nous verrons la manière de procéder plus loin dans ce chapitre.

Note : Intégrer un pilote de périphérique directement dans le noyau peut être intéressant si ce périphérique est inamovible et que l'on ne veut pas avoir à prendre en charge les modules. Toutefois, ce n'est pas une bonne idée lorsqu'on installe ce périphérique et qu'on cherche à le configurer, ou si l'on désire se réserver la possibilité de faire une mise à jour de ce périphérique sans redémarrer l'ordinateur. En effet, il est souvent nécessaire de redémarrer pour prendre en compte de nouveaux paramètres lorsque le pilote de périphérique est intégré au noyau, alors que lorsqu'il est sous la forme d'un module, un simple déchargement et rechargement suffit.

Par contre, lorsque votre configuration sera finie, vous pourrez parfaitement vous passez des modules et supprimer les modules des pilotes de périphériques dont vous ne disposez pas. Vous gagnerez ainsi de la place disque et potentiellement plusieurs dizaines de secondes au démarrage de votre ordinateur si votre distribution recherche les nouveaux périphériques à chaque démarrage.

8-1-2. Les fichiers spéciaux de périphériques

8-1-2-1. Généralités

La notion de fichier spécial de périphérique simplifie énormément l'utilisation du matériel par les programmes d'application, puisque la plupart des opérations sur un périphérique reviennent simplement à réaliser une écriture ou une lecture. Évidemment, l'écriture sur un fichier spécial de disque permet d'enregistrer les données sur ce disque, et la lecture permet de les récupérer. Mais cela ne s'arrête pas là ! Par exemple, la communication avec le modem se fait simplement en écrivant et en lisant les données sur le fichier spécial du port série sur lequel le modem est connecté. De même, jouer un fichier son revient simplement à l'écrire dans le fichier spécial qui gère la carte son. Il est même possible d'accéder à la mémoire vidéo par l'intermédiaire d'un fichier spécial de périphérique…

Bien entendu, certaines fonctionnalités avancées des périphériques ne peuvent pas être accédées simplement par une écriture ou une lecture dans un fichier spécial. Le système fournit donc aux applications d'autres moyens d'accéder à ces fonctionnalités, par l'intermédiaire d'appels systèmes spécifiques (pour ceux qui sont intéressés par la programmation système, cet appel système est réalisé par la fonction ioctl, dont le nom provient de l'abréviation de l'anglais « Input / Output ConTroL »). Évidemment, cette méthode n'est utilisée que par les programmes qui connaissent bien le fonctionnement du gestionnaire du périphériques, car ils doivent spécifier une requête que seul ce gestionnaire comprend en général. Quoi qu'il en soit, les requêtes de ce type utilisent elles aussi un descripteur de fichier spécial de périphérique, ce qui fait que tous les accès au matériel ont lieu par l'intermédiaire de ces fichiers.

Il existe deux principaux types de fichiers spéciaux de périphériques. Le premier type correspond aux périphériques de type bloc, dont les données ne peuvent être lues que par blocs (c'est le cas des disques durs, des lecteurs de CD et de disquettes en particulier). Le deuxième type correspond aux périphériques de type caractère, dont les données peuvent être lues caractère par caractère (cartes son, ports série, etc.).

En plus de son type, chaque fichier spécial de périphérique est caractérisé par deux codes permettant d'identifier le type et le modèle du périphérique auquel il donne accès. Ces deux codes portent le nom de code majeur et de code mineur. C'est par l'intermédiaire de ces codes que le noyau est capable de retrouver le gestionnaire de périphériques à utiliser pour satisfaire aux requêtes des clients qui accèdent à un fichier spécial de périphérique. Il y a donc, en général, une association unique entre ces codes et les gestionnaires de périphériques.

Les fichiers spéciaux de périphériques sont tous stockés dans le répertoire /dev/. Selon votre distribution, ce répertoire peut être géré de manière totalement dynamique en fonction du matériel effectivement installé sur votre machine, ou être prérempli statiquement avec les fichiers spéciaux de la plupart des périphériques rencontrés sur le marché (y compris donc pour des périphériques inexistants sur votre machine). Nous allons voir dans les sections suivantes comment ces fichiers sont créés et utilisés par le système en relation avec les pilotes de périphériques.

8-1-2-2. Le système de fichiers virtuel udev

8-1-2-2-1. Présentation

Depuis la version 2.6 du noyau, Linux dispose d'une fonctionnalité permettant aux applications de détecter l'apparition et la suppression des périphériques, que ceux-ci soient détectés au démarrage du système ou qu'ils soient branchés à chaud une fois l'ordinateur allumé.

Cette fonctionnalité est principalement utilisée par le sous-système udev (abréviation de « Userspace /dev »). Comme son nom l'indique, udev a pour principale fonction de prendre en charge la gestion du répertoire /dev/, mais en réalité il est capable de faire beaucoup mieux que cela.

En particulier, udev peut réaliser les opérations suivantes lorsque le noyau signale la présence d'un nouveau périphérique :

  • chargement du module du pilote de périphérique si nécessaire ;
  • si le périphérique requiert un firmware, chargement de celui-ci ;
  • création du fichier spécial de périphérique et de ses alias nécessaires à l'utilisation du périphérique ;
  • exécution des opérations d'initialisation complémentaires ou lancement des applications utilitaires associées au périphérique ;
  • notification de la présence du périphérique à l'ensemble des autres programmes qui s'intéressent à la gestion du matériel (par exemple le gestionnaire de bureau).

udev peut également effectuer les opérations nécessaires à la suppression d'un périphérique, ce qui est utile pour les périphériques amovibles. Ainsi, la détection, la configuration et la notification dynamique de la présence des périphériques Plug and Play est totalement automatisée.

Note : Le noyau, et donc udev, ne sont en réalité capables de détecter que les périphériques connectés au bus IDE, USB, PCMCIA, FireWire ou PCI. En effet, ces bus utilisent des technologies suffisamment récentes et permettent la détection, la configuration automatique et l'identification précise des périphériques. De ce fait, seuls les pilotes de périphériques de ce type peuvent être chargés automatiquement par udev. Les pilotes des périphériques plus anciens (périphériques ISA par exemple) ne peuvent être chargés automatiquement, car ces périphériques ne sont détectés que si leur pilote est déjà chargé dans le noyau. Aussi est-il nécessaire de précharger ces pilotes au démarrage de l'ordinateur, ou de les intégrer directement dans le noyau, pour qu'ils soient reconnus automatiquement par le système.

udev permet de résoudre plusieurs problèmes concernant les fichiers spéciaux de périphériques. Le plus évident pour l'utilisateur est que seuls les fichiers spéciaux des périphériques effectivement présents et pris en charge par un gestionnaire de périphérique apparaissent dans le répertoire /dev/.

Le répertoire /dev/ n'a donc plus à contenir les fichiers spéciaux de périphériques pour tous les périphériques pris en charge par Linux. Il en est d'autant réduit, ce qui permet de le placer dans un système de fichiers virtuel (c'est-à-dire un système de fichiers géré par le noyau en mémoire). La plupart des distributions basées sur udev utilisent cette technique afin d'accélérer la phase de chargement du système et les accès aux fichiers spéciaux de périphériques par les applications, et d'éviter de consommer inutilement de l'espace disque pour stocker des fichiers spéciaux qui sont de toutes manières recréés dynamiquement à chaque démarrage.

Un autre avantage d'udev est que les codes majeurs et mineurs des fichiers spéciaux de périphériques peuvent à présent être attribuées dynamiquement par le noyau lorsque les gestionnaires de périphériques s'initialisent. Cela a plusieurs conséquences :

  • il n'y a plus besoin d'avoir recours à une autorité centrale pour obtenir les valeurs de codes mineurs et majeurs, ceux-ci pouvant être déterminés dynamiquement par le noyau ;
  • il n'y a plus de risque de conflit entre deux périphériques, le noyau s'assurant de l'unicité des codes utilisés ;
  • la limitation du nombre de périphériques due au nombre limité de codes majeurs et mineurs n'existe plus (il suffit de consulter la liste du fichier /usr/src/linux/Documentation/devices.txt pour constater qu'il reste peu de codes libres pour les périphériques à venir).

Enfin, udev permet de simplifier considérablement la configuration et l'utilisation du système. Par exemple, il est possible de fixer de manière permanente le nom des fichiers spéciaux des périphériques amovibles, et les environnements utilisateurs graphiques peuvent réagir à l'apparition et à la suppression des périphériques afin de permettre leur utilisation par l'utilisateur.

8-1-2-2-2. Principe de fonctionnements de udev

Le principe de fonctionnement de udev est le suivant. Lorsque le noyau détecte un changement dans la configuration matérielle, il signale ce changement via un canal de communication « NetLink » aux applications qui s'y intéressent. udev utilise le démon udevd pour écouter sur ce canal de communication, et il met chacun de ces événements dans une file pour les traiter dans leur ordre d'apparition.

Les événements envoyés par le noyau contiennent toutes les informations relatives au périphérique pour lequel le noyau a généré un événement. Ces paramètres comprennent, entre autres, la nature de l'événement (apparition ou disparition d'un périphérique inconnu sur un bus, demande de chargement de firmware, notification de chargement ou de déchargement d'un pilote de périphérique, etc.). udevd utilise ces informations, ainsi que les informations sur le périphérique fournies par le noyau au travers du système de fichiers /sys/, pour effectuer les opérations de chargement des modules de pilotes de périphérique, de chargement des firmware, et de création des fichiers spéciaux de périphériques.

Note : Le démon udevd exécute les commandes udev selon l'ordre indiqué par le noyau via un numéro de séquence. Cette sérialisation est nécessaire parce que le noyau est capable de générer plusieurs événements simultanément pour les périphériques complexes, et qu'il faut s'assurer que les pilotes de périphériques parents sont bien initialisés avant de charger les pilotes des sous-périphériques. Ce cas peut se produire par exemple pour les cartes d'extension ou pour les hub USB.

Les anciennes versions de udev n'écoutaient pas directement les événements générés par le noyau. Le mécanisme utilisé était légèrement plus complexe et passait par un programme utilitaire nommé hotplug. Le noyau appelait ce programme à chaque fois qu'un événement se produisait au niveau de la configuration matérielle. Ce programme déterminait les modules de pilotes de périphériques à charger, effectuait le chargement de ces modules, et initialisait les périphériques avec leur firmware si nécessaire. Puis, il envoyait les événements au démon udevd pour que celui-ci mette à jour le répertoire /dev/. Ce mécanisme a été abandonné au profit d'une gestion totalement intégrée dans udevd en raison des mauvaises performances dues à l'exécution de l'utilitaire hotplug pour chaque événement matériel.

Le comportement que udev doit adopter dépend bien évidemment de chacun des périphériques, ou du moins de la classe du périphérique pour lequel l'événement se produit. Ce comportement est donc paramétrable à l'aide des fichiers de configuration situés dans le répertoire /etc/udev/ et /etc/udev/rules.d/. Ce dernier répertoire contient en particulier les règles qui permettent de définir les fichiers spéciaux de périphériques qui doivent être créés, les alias permettant de les nommer de manière constante, et les permissions que l'on doit leur affecter.

Le répertoire /etc/udev/ ne contient généralement que le fichier de configuration principal d'udev, à savoir le fichier udev.conf. Ce fichier permet d'indiquer le répertoire cible dans lequel les fichiers spéciaux de périphérique seront créés (paramètre udev_root, dont la valeur doit obligatoirement être /dev/), le répertoire contenant les fichiers de définition des actions prises par udev en fonction des différents événements (paramètre udev_rules, dont la valeur est normalement /etc/udev/rules.d/), et le niveau d'erreur à partir duquel les traces d'udev seront enregistrés dans le journal du système syslog (paramètre udev_log).

L'essentiel de la configuration réside toutefois dans les fichiers du répertoire /etc/udev/rules.d/. Ces fichiers expriment, sous la forme de règles permettant de sélectionner les différents événements provenant du noyau en fonction des informations de cet événement, les actions à entreprendre. Ce mécanisme est suffisamment générique pour permettre d'identifier de manière unique les périphériques et de réaliser les actions dont udev a la charge.

Les règles sont décrites à raison d'une ligne par règle dans les fichiers de configuration. L'action identifiée par chaque règle n'est exécutée que si l'événement généré par le noyau correspond aux critères de sélection de la règle. Certains mots clés permettent d'obtenir les informations sur l'événement produit par le noyau, et d'autres mots clés permettent de décrire les actions à effectuer lorsque les critères de sélection de l'événement sont satisfaits.

Par exemple, le mot clé ACTION identifie la nature de l'événement. Le mot clé KERNEL donne le nom que le noyau donne au périphérique qui a généré l'événement, et DEVPATH le chemin du périphérique dans le système de fichiers virtuel /sys/. Inversement, le mot clé NAME permet de paramétrer l'action de création du fichier spécial de périphérique en définissant le nom de ce fichier, et OWNER, GROUP et MODE permettent de définir respectivement l'utilisateur propriétaire, le groupe, et les droits d'accès à ce fichier. Ainsi, les simples règles suivantes :

 
Sélectionnez
KERNEL=="mem", NAME="%k", GROUP="kmem", MODE="0640"
KERNEL=="kmem", NAME="%k", GROUP="kmem", MODE="0640"

permettent de créer les fichiers spéciaux de périphériques /dev/mem et /dev/kmem (qui donnent respectivement accès à la totalité de la mémoire physique de l'ordinateur et à la mémoire du noyau). Bien entendu, ces fichiers spéciaux ne doivent être accessibles que par l'administrateur, mais il est également autorisé que les utilisateurs du groupe kmem puissent y accéder en lecture.

Note : Notez bien que dans les définitions de règle, le signe '==' est utilisé pour indiquer une contrainte d'égalité, alors que le signe '=' est utilisé pour réaliser une affectation, et constitue donc une partie de l'action de la règle.

D'autres mots clés sont disponibles. Ainsi, SYMLINK permet de définir des liens symboliques supplémentaires (par exemple /dev/modem ou /dev/mouse) référençant les fichiers spéciaux de périphériques réels. Le mot clé PROGRAM permet d'exécuter un programme avant que le fichier spécial de périphérique ne soit créé (généralement pour déterminer le nom du fichier à créer, justement), et le mot clé RUN permet d'exécuter une commande après que le fichier spécial de périphérique a été créé (généralement pour configurer le périphérique ou signaler sa présence à l'utilisateur). Vous trouverez de plus amples renseignements sur toutes ces règles dans la page de manuel de udev, ainsi que dans la documentation fournie avec udev pour la rédaction de règles personalisées.

Les fichiers du répertoire /etc/udev/rules.d/ doivent tous avoir l'extension .rules. De plus, ces fichiers sont interprétés dans l'ordre lexicographique de leur nom. Ainsi, il est d'usage de préfixer le nom du fichier par un numéro indiquant l'ordre de priorité des règles de ce fichier par rapport aux autres. Par exemple, les règles du fichier 50-udev.rules (fichier de définition des règles principales de udev) sont toujours lues avant les règles du fichier 90-hal.rules (fichier de définition des règles permettant d'envoyer les événements concernant le matériel au démon d'abstraction du matériel hald), car 50 est plus petit que 90 dans l'ordre lexicographique.

Comme vous pouvez le constater, les fichiers de configuration de udev permettent de paramétrer de manière très souple et très précise les actions à effectuer lorsqu'un périphérique apparaît ou disparaît. Nous verrons dans les sections suivantes comment les principales actions sont réalisées. La contrepartie de ce système est tout de même une certaine complexité dans la définition des règles des fichiers de configuration d'udev, mais vous n'aurez généralement pas à vous en préoccuper, car les distributions fournissent des fichiers de configuration adaptés à la plupart des usages.

8-1-2-2-3. Identification et chargement des pilotes de périphérique

Généralement, les périphériques modernes disposent d'identifiants qui leur sont propres et qui peuvent être récupérés par des mécanismes standards des bus modernes. Ces identifiants sont généralement au nombre de deux, le premier étant un code spécifique au fabricant du périphérique, et le deuxième étant un identifiant de ce périphérique. Par exemple, vous pouvez visualiser les différents périphériques connectés au bus PCI de votre ordinateur avec la simple commande lspci -nn. La commande lsusb vous donnera des identifiants similaires pour les périphériques USB.

udev peut déterminer, à l'aide des identifiants du matériel, déterminer quels sont les pilotes de périphériques capable de gérer ce matériel. En effet, les fichiers sources de chaque module de pilote de périphérique contiennent une liste des identifiants des périphériques qu'ils prennent en charge. Lors de l'installation du module, la command depmod extrait ces informations et les place dans un des fichiers situés dans le répertoire d'installation des modules du noyau (à savoir /lib/module/version/, où version est le numéro de version du noyau). depmod crée un fichier pour chaque type de périphérique. Ces fichiers ont tous un nom de la forme :

 
Sélectionnez
module.typemap

type est le type de périphérique.

Par exemple, le fichier module.usbmap contient, pour chaque périphérique USB pris en charge par les modules installés, une ligne indiquant le nom du module et l'ensemble des identifiants du périphérique USB en question.

Ainsi, lorsque le noyau indique à udev l'apparition d'un nouveau périphérique, celui-ci consulte les fichiers d'association des modules aux périphériques pour déterminer quel module est capable de gérer ce périphérique. Ce module est chargé si nécessaire, et le gestionnaire de périphérique peut s'initialiser.

Image non disponible
Chargement des modules de pilotes de périphérique

Note : La table des périphériques pris en charge par certains modules peut ne pas être complète ou à jour. C'est généralement le cas pour les nouveaux périphériques vendus par un fabricant qui utilisent une nouvelle révision d'une puce électronique que des anciens périphériques supportés par un pilote utilisait déjà. Ainsi, lorsqu'un périphérique n'est pas reconnu immédiatement par les pilotes existants, vous pouvez tenter une recherche sur Internet avec les identifiants de périphériques tels qu'ils sont donnés par lspci ou lsusb et identifier le pilote nécessaire pour ce périphérique. S'il en existe un, vous pouvez essayer d'ajouter les identifiants de votre périphérique dans les sources du pilote, le recompiler et l'installer à nouveau. Si ce pilote vous permet d'utiliser effectivement ce périphérique de manière stable, vous pouvez alors demander au mainteneur du pilote d'ajouter les identifiants du périphérique dans la liste des périphériques supportés.

8-1-2-2-4. Chargement des firmwares

Certains périphériques nécessitent un firmware (c'est-à-dire un micro logiciel pour les périphériques évolués) pour fonctionner correctement. Ce firmware peut être stocké de manière permanente dans le périphérique dans une mémoire non volatile, ou devoir être rechargé à chaque initialisation du périphérique. Dans ce cas, cette opération de chargement doit être faite par le pilote de périphérique.

Grâce à udev, il est possible de faire en sorte que cette opération se fasse automatiquement. Lorsqu'un pilote désire charger le firmware dans le périphérique, il appelle une fonction du noyau qui génère un événement udev. udev prend alors en charge les opérations et localise le firmware, puis le fournit au noyau. Le pilote de périphérique peut alors effectuer le chargement effectif du firmware dans le périphérique. Pour cela, udev copie le fichier de firmware demandé par le pilote de périphérique dans un fichier dédié à cet effet dans l'entrée du périphérique du système de fichiers virtuel /sys/. Bien entendu, le chemin permettant de trouver les informations du périphérique dans le système de fichiers virtuel /sys/ est fourni aux scripts de configuration d'udev via le mot clé DEVPATH.

Image non disponible
Chargement des firmwares

En général, les fichiers de firmware sont fournis avec les pilotes de périphériques ou sont disponibles sur le site Web indiqué dans leur documentation. Ils doivent être installés dans le répertoire /lib/firmware/. Il est également nécessaire d''activer l'option « Hotplug firmware loading support » du sous-menu « Generic Driver Options » du menu « Device Drivers » pour que cette fonctionnalité soit disponible.

8-1-2-2-5. Création des fichiers spéciaux de périphériques

À chaque périphérique détecté par un pilote de périphérique, le noyau génère un événement à destination d'udev. Ces événements indiquent le nom du périphérique tel qu'il est connu par le gestionnaire de périphérique, ainsi que les informations sur le périphérique dans le système de fichiers /sys/. udev utilise ces informations pour déterminer les règles qui indiquent quels sont les fichiers spéciaux de périphériques à utiliser.

Si aucune règle ne correspond, udev crée le fichier spécial de périphérique avec le nom utilisé par le pilote de périphérique pour l'identifier. Dans le cas contraire, c'est le nom fourni dans les fichiers de configuration qui est utilisé. De même, les fichiers sont créés par défaut au nom de l'utilisateur root, et seul cet utilisateur dispose des droits de lecture et d'écriture sur ces fichiers. Enfin, si des liens symboliques sont définis dans les règles appliquées, ceux-ci sont créés. Par exemple, il est classique d'avoir un lien symbolique cdrom pointant vers le périphérique de type bloc gérant le lecteur de CD.

Image non disponible
Création des fichiers spéciaux de périphériques

Les règles d'udev sont généralement fournies par les distributions et permettent de créer les fichiers spéciaux de périphériques de manière générique, ainsi que les liens symboliques standards. De même, bien que les interfaces réseau ne sont pas accédées par l'intermédiaire de fichiers spéciaux de périphériques, les règles udev sont également appliquées afin de les renommer sous un nom spécifique.

8-1-2-2-6. Persistance des fichiers spéciaux de périphériques

L'un des princpaux avantages d'udev est de permettre un nommage fixe des différents périphériques. Par exemple, si vous disposez de deux imprimantes, chaque imprimante se verra affecter un fichier spécial de périphérique dédié. Toutefois, il est possible qu'une de ces imprimantes ne soit pas disponible, ou pas allumée. Dans ce cas, un décallage des fichiers spéciaux de périphériques peut se produire, ce qui peut être génant si une configuration spécifique doit être faite pour la deuxième imprimante. De même, vous pouvez disposer de plusieurs disques amovibles ou clefs USB, et il peut être utile que les fichiers spéciaux de ces périphériques aient un nom constant.

udev permet tout cela, en faisant en sorte que les règles des fichiers de configuration sélectionnent les périphériques sur une de leur caractéristiques principale (par exemple, le nom de modèle du périphérique).

Pour fixer les idées et donner un exemple, supposons que l'on ait deux clefs mémoire USB de modèles différents et que l'on désire affecter de manière permanente des fichiers de périphériques à chacune d'elle. Il suffit pour cela simplement de trouver un paramètre unique dans les identifiants de ces périphériques afin de les distinguer.

La manière la plus simple pour obtenir la liste des paramètres d'un périphérique est d'utiliser la commande udevinfo. Pour obtenir la liste des attributs utilisables dans les règles de udev, il faut utiliser l'option --attribute-walk. Le périphérique dont les attributs doivent être récupérés peut être spécifié soit grâce au nom de son fichier spécial de périphérique utilisé par le noyau (avec l'option --name), ou avec son chemin dans le système de fichiers /sys/.

Note : La commande udevmonitor peut vous permettre de déterminer le chemin du périphérique dans le système de fichiers /sys/.

Par exemple, la commande suivante permet d'obtenir les informations sur un disque amovible connecté sur le port USB et apparaissant sous le nom /dev/sdb :

 
Sélectionnez
udevinfo --name=/dev/sdb --attribute-walk

Supposons que cette commande donne le résultat suivant :

 
Sélectionnez
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/block/sdb':
    KERNEL=="sdb"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{capability}=="12"
    ATTR{stat}=="      52      127      556      486        0        0        0        0        0      426      486"
    ATTR{size}=="156301488"
    ATTR{removable}=="0"
    ATTR{range}=="16"
    ATTR{dev}=="8:16"

  looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-2/1-2:1.0/host5/target5:0:0/5:0:0:0':
    KERNELS=="5:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{modalias}=="scsi:t-0x00"
    ATTRS{ioerr_cnt}=="0x0"
    ATTRS{iodone_cnt}=="0x3b"
    ATTRS{iorequest_cnt}=="0x3b"
    ATTRS{iocounterbits}=="32"
    ATTRS{timeout}=="30"
    ATTRS{state}=="running"
    ATTRS{rev}=="09.0"
    ATTRS{model}=="WD800VE-00HDT0  "
    ATTRS{vendor}=="WDC     "
    ATTRS{scsi_level}=="3"
    ATTRS{type}=="0"
    ATTRS{queue_type}=="none"
    ATTRS{queue_depth}=="1"
    ATTRS{device_blocked}=="0"
    ATTRS{max_sectors}=="240"

…

Comme on peut le voir, les informations du périphérique /dev/sdb sont d'abord affichées. Viennent ensuite les informations des périphériques parents, donc en particulier les informations sur le disque physique (ici, un Western Digital WD800VE-00HDT0), et ainsi de suite (seules les deux premiers bloc d'information ont été recopiés dans cet exemple, les suivants identifiant l'adaptateur USB et les composants du bus USB eux-mêmes).

Ainsi, les informations spécifique au matériel connecté que l'on doit utiliser pour définir un fichier spécial de périphérique unique sont données dans le deuxième groupe d'information (relative au disque physique). Il est donc possible de définir la règle udev suivante pour créer un fichier spécial de périphérique /dev/hd_externe dédié à ce disque :

 
Sélectionnez
SUBSYSTEMS=="scsi", ATTRS{model}=="WD800VE-00HDT0", NAME="hd_externe"

Notez cependant que l'on ne peut pas, dans une même règle udev mélanger des critères de sélection utilisant des informations des différents groupes d'informations renvoyés par udevinfo, parce que chaque groupe identifie un périphérique logique et un seul dans le noyau.

Une fois vos règles définies, vous pouvez les tester avec la commande udevtest. Cette commande prend en paramètre le nom du périphérique de plus haut niveau renvoyé par udevinfo. Dans notre exemple, il s'agit de /block/sdb :

 
Sélectionnez
udevtest /sys/block/sdb

Cette commande affichera l'ensemble des opérations que udev effectuerait si ce périphérique était connecté. Attention toutefois, les informations affichées proviennent d'une simulation, et peuvent être incorrectes si des règles udev utilisent des commandes externes, puisque en simulation ces commandes ne sont pas exécutés.

En pratique, les distributions font en sorte que les règles de nommage des périphériques soient écrites ou mises à jour dynamiquement lors de la première détection du périphérique. Elles s'appuient pour cela sur des programmes utilitaires, généralement situés dans le répertoire /lib/udev/. Par exemple, le script /lib/udev/cdrom-symlinks.sh a pour but de créer le fichier de configuration /etc/udev/rules.d/75-optical-devices.rules, qui contient les définitions des liens symboliques sur les lecteurs de disque optique (CDROM et graveurs de CD par exemple).

Note : Les scripts de génération de règles peuvent ne pas nommer les périphériques comme vous le désirez (par exemple, le fichier spécial /dev/cdrom peut référencer votre graveur de CD, alors que le fichier spécial /dev/cdwriter un simple lecteur de CD. Dans ce cas, vous pourrez modifier directement le fichier de configuration 75-optical-devices.rules pour remettre les choses dans l'ordre. Si vous vous trompez, supprimez simplement ce fichier, il sera recréé automatiquement au prochain redémarrage d'udev.

8-1-2-2-7. Notification des applications utilisateurs

udev est également livré avec un fichier de configuration contenant une règle permettant de notifier les applications de haut niveau des apparitions et disparition des périphériques.

Le mécanisme utilisé se base ici sur le sous-système HAL (« Hardware Abstraction Layer Daemon »). Ce sous-système a pour principal but de fournir une interface unifiée pour que l'ensemble des applications de haut niveau (par exemple les gestionnaires de bureau KDE et Gnome) puisse obtenir des informations sur les périphériques et être notifiées de toutes modification de la configuration matérielle.

Toutes ces opérations sont implémentées au niveau du démon hald. Ce démon reçoit les informations concernant les périphériques directement de udev, grâce à la règle mentionnée ci-dessus. Grâce à ces informations, il maintient une base de données des périphériques présents et de leurs principales caractéristiques.

De plus, hald fournit une interface de programmation standard pour toutes les applications utilisateurs. Cette interface se base sur un protocole de communication standard, le protocole D-BUS. Ce protocole a été développé de manière commune avec les deux principaux environnements de bureau de Linux, à savoir KDE et Gnome. Ainsi, les applications de ces environnements sont capables de gérer les modificiations intervenant sur le matériel. Par exemple, le fait de brancher une clef USB ou un disque externe permet de demander à l'utilisateur s'il veut le monter ou non.

Note : Le protocole de communication DBUS a été conçu de manière générique est n'a pas pour vocation de n'être utilisé que par HAL. En réalité, c'est tout un système de communication inter processus de haut niveau et d'utilisation simplifiée (par rapport aux systèmes de composants lourds tels que CORBA par exemple).

DBUS permet les communications entre les applications utilisateurs d'un même utilisateur, ainsi que les communications transverses entre les applications système. En pratique, ces communications sont gérées par un démon, dont une instance est lancée pour le système, et potentiellement une instance supplémentaire est exécutée pour chaque utilisateur. Les mécanismes de DBUS et de HAL ne sont d'intérêt que pour les programmeurs et ne seront donc pas détaillés plus dans ce document.

8-1-2-2-8. Initialisation du système

Pour terminer cette description des mécanismes d'udev, signalons que le démon udevd ne peut évidemment pas écouter les événements du noyau avant qu'il ne soit lancé. Par conséquent, les périphériques détectés par le noyau avant le démarrage du démon udevd ne sont pas être détéctés automatiquement.

Ce problème est géré au niveau des scripts de démarrage des distributions, en rejouant les événements matériels des périphériques déjà détectés par le noyau. Cela se fait en appelant la commande udevtrigger. Cette opération est totalement prise en charge par les distributions, et vous n'avez normalement pas à utiliser cette commande.

8-1-2-3. Gestion statique des fichiers spéciaux de périphériques

La gestion des périphériques et du répertoire /dev/ par udev est utilisée par la plupart des distributions récentes. Toutefois, les anciennes distributions sont encore susceptibles d'utiliser un répertoire /dev/ complètement statique, c'est-à-dire rempli à l'avance avec les fichiers spéciaux des périphériques les plus courants.

Normalement, votre distribution fournit un répertoire /dev/ relativement complet. Vous n'avez donc pas à toucher au répertoire /dev/. Cependant, si vous devez créer un fichier spécial de périphérique vous-même, par exemple pour un gestionnaire de périphérique exotique non pris en charge par votre distribution ou non reconnu par le système, vous devrez utiliser la commande mknod. Sa syntaxe est relativement simple :

 
Sélectionnez
mknod fichier type majeur mineur

fichier est le nom du fichier spécial de périphérique à créer, type est une lettre indiquant le type du fichier spécial ('c' pour les fichiers de type caractère et 'b' pour les fichiers de type bloc), et majeur et mineur sont les codes majeur et mineur du périphérique. Je vous invite à consulter la page de manuel de la commande mknod pour plus d'informations.

Note : La liste des codes majeurs et mineurs déjà affectés à des périphériques est donnée dans le fichier /usr/src/linux/Documentation/devices.txt. Comme vous pouvez le constater, l'utilisation d'un répertoire /dev/ statique impose donc de disposer d'une autorité centrale régissant l'affectation des codes majeurs et mineurs aux gestionnaire de périphériques. De plus, la plupart des codes sont déjà affectés, ce qui est une des raisons pour laquelle le système udev a été développé.

Lorsqu'une application tente d'accéder à un fichier spécial de périphérique, trois cas peuvent se présenter :

  • soit un pilote de périphérique capable de gérer le périphérique est déjà chargé ;
  • soit il n'existe aucun pilote capable de gérer le périphérique, mais le noyau peut en trouver un ;
  • soit le noyau est incapable de trouver un pilote pour ce périphérique.

Dans les deux premiers cas, la requête de l'application est satisfaite, éventuellement après le chargement automatique du pilote de périphérique sous la forme de module. Dans le troisième cas, évidemment, la requête est refusée.

Ainsi, lors de l'ouverture d'un fichier spécial de périphérique par une application, le noyau vérifie s'il dispose d'un pilote de périphérique capable de gérer ce périphérique, en s'appuyant sur les codes majeur et mineur du fichier spécial de périphérique. Si ce n'est pas le cas, il effectue un appel à modprobe pour charger le module contenant ce pilote de périphérique.

Le nom du module dont le noyau demande le chargement à modprobe dépend du pilote et ne correspond pas forcément à un nom de module existant. Par exemple, le module de gestion des ports parallèles se nomme, sur les ordinateurs de type PC, parport_pc. Toutefois, lorsque le noyau désire accéder au port parallèle, il n'utilise pas ce nom, mais plutôt un nom générique, qui est le même pour toutes les architectures matérielles supportées par Linux. Ce nom est parport_lowlevel. Ainsi, le noyau utilise la commande suivante pour charger le module de prise en charge du port parallèle :

 
Sélectionnez
modprobe -k parport_lowlevel

L'option -k permet d'indiquer à modprobe qu'il est appelé par le noyau, donc dans le contexte de chargement automatique des modules.

modprobe doit donc faire la correspondance entre le nom de module demandé par le noyau et le nom d'un module réel. C'est donc dans les fichiers de configuration de modprobe que cette correspondance est définie. Pour cela, un certain nombre d'alias peuvent être définis pour identifier les modules réels. Chaque alias est introduit par le mot clé alias, dont la syntaxe est donnée ci-dessous :

 
Sélectionnez
alias nom module

nom est le nom de l'alias, et module est le nom du module réel. Lorsque la commande modprobe est appelée avec le nom d'un alias en paramètre, elle commence par rechercher le nom du module réel dans ses fichiers de configuration, puis elle le charge en mémoire.

Par exemple, pour charger le module parport_pc automatiquement lorsque le noyau a besoin d'accéder au port parallèle, on pourra ajouter la définition d'alias suivante dans le fichier modprobe.conf :

 
Sélectionnez
alias parport_lowlevel parport_pc
Image non disponible
Chargement automatique des modules du noyau

Vous pouvez constater que le mécanisme d'alias permet de rendre le noyau indépendant des modules utilisés, puisque l'association entre le nom du module utilisé par le noyau et le module réel et ses paramètres est maintenu dans des fichiers de configuration. L'inconvénient de cette méthode est en revanche qu'il faut connaître les noms de modules utilisés par le noyau pour chaque pilote et pour leurs fonctionnalités. Ces noms sont assez variables et dépendent de la fonctionnalité demandée. En général, ce nom apparaît dans les messages de traces du noyau lorsqu'il ne parvient pas à localiser un module lors de son chargement automatique. Ces messages de traces peuvent être affichés à l'aide de la commande dmesg. Il est donc possible de déterminer la liste des modules que le noyau a tenté de charger relativement facilement. Toutefois, cela n'indique pas forcément la fonctionnalité implémentée par le module en question, et encore moins l'application qui a tenté d'utiliser cette fonctionnalité.

Il est heureusement beaucoup plus facile de savoir quelle est la fonctionnalité demandée lorsque celle-ci a trait à un périphérique de l'ordinateur. En effet, le nom de module utilisé par le noyau pour chaque gestionnaire de périphérique est construit à partir du type de fichier spécial de périphérique et de ses codes majeur et mineur. Ainsi, le noyau utilise un nom de module de la forme « char-major-xxxx » pour les périphériques de type caractère, et un nom de la forme « block-major-xxxx » pour les périphériques de type bloc. Les caractères xxxx identifient le code majeur de ce périphérique, plus rarement son code mineur. Il est donc facile de déduire le gestionnaire de périphérique nécessaire à la gestion de ce fichier spécial de périphérique, et de définir l'alias permettant de faire la correspondance entre le nom du module utilisé par le noyau et le module réel à charger.

Par exemple, pour les cartes son, le nom de module char-major-14 est utilisé pour demander le chargement du module de gestion du son, parce que les cartes son utilisent toutes le code majeur 14. Il faut donc définir un alias sur ce nom de module vers le module du gestionnaire de cartes son. Comme on le verra dans la section traitant de la configuration des cartes son, ce module pourra lui-même demander le chargement de modules complémentaires, en fonction de la carte son réellement utilisée et des fonctionnalités demandées. Le numéro de code mineur sera indiqué lors de ces opérations.

Si vous devez modifier les fichiers de configuration de modprobe, sachez qu'il s'agit d'une opération délicate, car elle nécessite de bien connaître les mécanismes de nommage utilisés par le noyau, les noms des modules réels et leurs paramètres de configuration. En général, vous trouverez les informations sur les entrées à ajouter ou à modifier dans le fichier d'aide du module correspondant, que vous pourrez trouver dans les sources du noyau (dans le répertoire /usr/src/linux/Documentation/). Quoi qu'il en soit, la modification des fichiers de configuration de modprobe peut générer de nouvelles dépendances entre les modules. Il est donc nécessaire d'exécuter la commande depmod -a après chaque modification de ce fichier.

8-2. Configuration des périphériques de masse

Les périphériques de masse sont les périphériques permettant de manipuler de grandes quantité de données. Il s'agit généralement des périphériques connectés sur bus SCSI, des disques durs et lecteurs de CD/DVD, des graveurs et des scanners.

8-2-1. Configuration des périphériques SCSI

Les périphériques de qualité sont généralement connectés sur bus SCSI, en raison des capacités de celui-ci en termes de débit et de performances. En particulier, les disques durs SCSI restent privilégiés sur les systèmes haut de gamme comme les serveurs par exemple, parce que le bus SCSI permet d'utiliser plusieurs périphériques simultanément.

Sous Linux, les périphériques SCSI sont accédés par l'intermédiaire des fichiers spéciaux de périphériques /dev/sdx pour les disques durs ou /dev/scdn pour les lecteurs ou les graveurs de CD-ROM, où x est la lettre définissant le disque dur et n est le numéro du lecteur ou du graveur de CD-ROM. Les autres périphériques SCSI sont accédés par l'intermédiaire des fichiers spéciaux de périphériques SCSI génériques, à savoir les fichiers /dev/sgn. Notez que certains périphériques pourront être utilisés par l'un ou l'autre de ces fichiers spéciaux, selon la fonctionnalité à laquelle on cherche à accéder. Par exemple, les programmes de gravage utilisent les fichiers spéciaux de périphériques /dev/sgn pendant le gravage, alors que la simple lecture d'un CD avec un graveur se fait via le fichier spécial de périphérique /dev/scdn correspondant.

La prise en charge des périphériques SCSI se fait au niveau du noyau pour les fonctionnalités de base. En réalité, la configuration des périphériques SCSI se restreint à celle de la carte SCSI utilisée. Les fonctionnalités de plus haut niveau sont reléguées au niveau applicatif. Par exemple, la prise en charge des différents graveurs SCSI du marché est réalisée par les logiciels de gravage eux-mêmes, de même que la prise en charge des différents scanners l'est par les logiciels d'acquisition d'image.

La gestion des contrôleurs SCSI au niveau du noyau se fait par l'intermédiaire des options du menu « SCSI support » du programme de configuration du noyau. Outre l'option « SCSI support » que l'on activera bien évidemment, ce menu comprend les options suivantes, que l'on choisira en fonction du type des périphériques SCSI à utiliser :

  • « SCSI disk support », pour les disques durs SCSI, ainsi que pour certains périphériques de masse qui apparaissent comme des disques durs SCSI (c'est en particulier le cas pour les clefs USB et un grand nombre d'appareils photo numériques) ;
  • « SCSI tape support », pour les lecteurs de cartouches SCSI. Les possesseurs de lecteurs de cartouches OnStream SC-x0 devront plutôt utiliser l'option « SCSI OnStream SC-x0 tape support », car le gestionnaire de périphériques standard n'est pas capable de les prendre en charge ;
  • « SCSI CD-ROM support », pour les lecteurs de CD-ROM SCSI et pour les graveurs de CD-ROM IDE, si l'on décide d'utiliser l'émulation SCSI avec certains logiciels de gravage (voir plus loin pour plus de détails à ce sujet) ;
  • « SCSI generic support », pour les autres périphériques dont l'utilisation requiert l'utilisation d'un programme applicatif spécifique. Il s'agit ici des graveurs de CD, des scanners et autres périphériques spéciaux.

Certains périphériques SCSI disposent de plusieurs numéros d'unités logiques sur leur bus. Il peut donc être nécessaire, pour ces périphériques, d'activer l'option « Probe all LUNs on each SCSI device » afin de pouvoir les utiliser correctement. Les autres options ne sont pas essentielles, consultez leur aide pour plus de détails à leur sujet.

En plus des options générales de la prise en charge du SCSI, il est impératif de sélectionner le gestionnaire de périphériques capable de piloter votre contrôleur SCSI. Cela peut être fait dans le sous-menu « SCSI low-level drivers ». Vous devrez y activer la prise en charge pour votre matériel, aucune règle ne peut donc être définie à ce niveau. Consultez la documentation de votre matériel pour déterminer le gestionnaire de périphériques adéquat à utiliser.

Une fois la configuration du noyau effectuée, vous n'avez plus qu'à le compiler et à l'installer pour pouvoir utiliser vos périphériques. La manière de procéder a été décrite en détail dans la Section 7.3.

8-2-2. Configuration des disques durs IDE

Les disques durs IDE ont longtemps souffert d'un gros défaut par rapport aux disques SCSI : celui de ne pas pouvoir effectuer des opérations sans l'intervention du processeur. En effet, l'envoi des données aux disques se faisaient classiquement par de nombreuses écritures dans les ports d'entrée/sortie des contrôleurs de disques, obligeant ainsi le système à consacrer une part importante des ressources processeur uniquement pour les accès disque. Ce défaut a été corrigé avec la montée en puissance du mode DMA (abréviation de l'anglais « Direct Memory Access »). Le mode DMA des périphériques IDE existe depuis les tous débuts de l'architecture PC, mais les premiers contrôleurs DMA n'étaient pas capables de suivre la cadence des disques dur, même des plus anciens. Il n'a donc malheureusement pas été utilisé pendant longtemps, jusqu'à ce qu'une nouvelle technologie soit mise au point : l'Ultra DMA. La plupart des jeux de composants des cartes mères modernes sont à présent capables de gérer l'Ultra DMA, dont les fréquences de bus les plus courantes sont 33, 66 et 100MHz.

Note : Même si les interfaces IDE ont à présent réduit l'écart avec les interfaces SCSI au niveau du taux de transfert des données, elles ont toujours un train de retard par rapport à elles. En effet, les périphériques SCSI sont d'une part capables de communiquer entre eux sur leur bus, déchargeant ainsi totalement le processeur de ce travail de transfert des données, et d'autre part capables de traiter plusieurs requêtes d'affilée sans l'intervention du processeur. Ces fonctionnalités déchargent le bus système, mais sont également extrêmement utiles pour les systèmes d'exploitation multitâches. Ceux-ci peuvent en effet envoyer plusieurs commandes aux périphériques et effectuer d'autres traitements pendant qu'elles s'exécutent en asynchrone. Les disques SCSI ont donc un taux d'occupation du processeur et du bus système nettement moindre, et permettent aux systèmes tels que Linux d'atteindre un degré de réactivité inégalé avec les disques IDE classiques. Cela dit, les périphériques IDE coûtent nettement moins cher que les périphériques SCSI, et c'est sans doute là la clef de leur succès.

En général, Linux configure les contrôleurs des disques durs de manière quasi optimale, et il n'est généralement pas nécessaire de modifier leur paramétrage. Cependant, les contrôleurs IDE peuvent être configurés ou optimisés manuellement grâce à l'utilitaire hdparm. Comme son nom l'indique, cet utilitaire permet de modifier les paramètres des disques durs et des contrôleurs IDE. Il permet également de tester les performances de votre configuration, et peut donc servir d'outil de diagnostic très utile. La mesure du débit de votre sous-système disque (sans les mécanismes de cache du système) peut être en effet réalisée facilement avec la commande suivante :

 
Sélectionnez
hdparm -t périphérique

périphérique est le fichier spécial de périphérique de votre disque dur.

Note : Si vous obtenez des valeurs inférieures ou égales à 6 Mo/s, vous avez réellement un problème de configuration. Les premiers disques UltraDMA 33 peuvent atteindre facilement 8 à 10 Mo/s, les disques UltraDMA 66 atteignent facilement 17 à 22 Mo/s, et les disques les plus récents en UltraDMA 100 peuvent aller encore bien au delà.

Faites bien attention à ne pas utiliser l'option -T à la place de l'option -t. En effet, vous mesureriez le débit dans le sous-système disque complet de Linux, avec ses mécanismes de cache. Vous obtiendriez alors des taux de transfert nettement plus grands (dix fois plus au moins), qui ne représenteraient pas le taux de transfert réel de votre interface IDE.

L'utilitaire hdparm permet également de fixer un certain nombre de paramètres des disques durs. Par exemple, l'activation ou la désactivation de l'UltraDMA se fait simplement avec l'option -d. Cette option prend en paramètre un entier pouvant valoir 1 ou 0, selon que l'UltraDMA doit être activé ou non. Cette option peut être complétée d'autres options d'optimisation pour les disques modernes, pour lesquels on peut également préciser le mode de transfert à utiliser. Ce mode peut être indiqué à l'aide de l'option -X, qui prend en paramètre un nombre dont la valeur est le numéro du mode plus une constante identifiant le type de transfert utilisé. Les transferts de type PIO (c'est-à-dire le mode dans lequel le processeur effectue lui-même les transferts par l'intermédiaire des ports d'entrée / sortie) utilisent la constante 8, les transferts de type DMA simple utilisent la constante 32, et les transferts en UltraDMA utilisent la constante 64. Ainsi, la sélection du mode UltraDMA mode 2 pour le disque maître du premier contrôleur IDE se fait avec la commande suivante :

 
Sélectionnez
hdparm -d1 -X66 /dev/hda

La valeur 66 utilisée ici signifie donc que les transfers se font en UltraDMA (constante 64), mode 2 (valeur 2).

Note : Pour que l'UltraDMA soit utilisable, il faut bien entendu que les pilotes IDE de votre noyau Linux le gèrent. Généralement, les noyaux des distributions en sont capables, mais si d'aventure ce n'était pas le cas, vous devriez recompiler votre noyau. Les options à activer dans le programme de configuration du noyau sont les options suivantes du menu « ATA/IDE/MFM/RLL support » :

  • « Generic PCI IDE chipset support » du menu « IDE, ATA and ATAPI Block devices » ;
  • « Generic PCI bus-master DMA support » ;
  • « Use PCI DMA by default when available ».

Vous devrez également activer le support pour les jeux de composants utilisés par votre carte mère.

L'utilitaire hdparm permet également d'activer et de désactiver le mode 32 bits de ces contrôleurs à l'aide de l'option -c. Comme pour l'option -d, l'option -c prend en paramètre un indicateur pouvant valoir 1 ou 0 et permettant d'activer ou de désactiver le mode 32 bits du contrôleur. Notez que certains contrôleurs ne supportent pas correctement le mode de fonctionnement 32 bits et peuvent perdre des données si vous l'activez.

Note : Prenez garde lorsque vous utilisez la commande hdparm. Si vous spécifiez des paramètres incorrects ou non pris en charge par votre matériel, vous pouvez fort bien bloquer complètement vos contrôleurs IDE, et planter ainsi le système en un temps très court. Si d'aventure cela se produisait, il faudrait attendre un peu de temps, jusqu'à ce que le système s'aperçoive de la mauvaise configuration des contrôleurs et les réinitialisent avec leurs paramètres initiaux. Vous pouvez détecter ce genre de réinitialisation dans les messages du noyau, que vous pouvez à tout moment afficher avec la commande dmesg. Sachez toutefois que le risque de corruption du système de fichiers en cas de mauvaise configuration reste bien réel, et qu'il vaut mieux un système légèrement plus lent qu'un système qui détruit vos données en un temps record.

Lorsque vous aurez trouvé les paramètres optimaux de vos contrôleurs de disque, vous pourrez demander au système de conserver ces paramètres par défaut en ajoutant l'option -k1 dans la ligne de commande de hdparm. Par exemple, pour configurer de manière permanente le premier disque IDE en UltraDMA mode 2 et en accès 32 bits, il faut utiliser la commande suivante :

 
Sélectionnez
hdparm -c1 -d1 -X66 -k1 /dev/hda
Note : Prenez garde toutefois au fait que les réinitialisations du contrôleur en cas d'erreur reprendront systématiquement les mêmes paramètres, ce qui peut réellement bloquer complètement votre sous-système disque (et planter irrémédiablement votre système). Dans ce cas, il ne vous restera plus que le redémarrage brutal, avec les risques de pertes de données qui en découlent.

La configuration des disques durs et des contrôleurs IDE pourra également être ajoutée dans le script de démarrage de votre système. Ce script est généralement placé dans le répertoire /etc/rc.d/ ou dans le répertoire /sbin/init.d/ selon votre distribution. Bien entendu, il faut réellement être sûr de la commande de configuration utilisée, car elle sera exécutée systématiquement à chaque démarrage.

8-2-3. Installation d'un graveur de CD/DVD

Linux dispose de tous les logiciels permettant de graver des CD ou des DVD, et ce avec la plupart des graveurs disponibles sur le marché. Il permet de copier des CD et de créer des images disques. Cependant, il n'est pas encore possible d'utiliser le gravage par paquet, qui permettrait d'utiliser les graveurs de CD comme des périphériques de sauvegarde amovibles. Cette fonctionnalité est en effet encore à l'étude, elle sera sans doute disponible sous peu.

8-2-3-1. Notions de base sur le gravage sous Linux

Originellement, tous les graveurs de CD/DVD utilisaient l'interface SCSI. Ce n'est que plus tard que les graveurs sur port parallèle et les graveurs IDE ATAPI sont apparus. Actuellement, les graveurs externes connectés sur port parallèle sont de moins en moins vendus. Les graveurs IDE on fait une belle percée et sont les plus courants actuellement. Les logiciels de gravage doivent donc toutefois être capable d'utiliser n'importe quel type de graveur, ce qui n'est pas simple. Heureusement, le protocole de communication ATAPI n'est rien d'autre qu'un mode de transport de commandes SCSI pour les périphériques IDE, ce qui fait que les logiciels de gravage peuvent utiliser les deux types de périphériques de manière relativement générique.

Les anciennes versions des logiciels de gravage ne permettaient d'utiliser que l'interface SCSI pour graver des CD. Il n'était donc pas possible d'utiliser les graveurs IDE de manière native. Une couche d'émulation SCSI a donc été développée dans Linux afin de simuler une interface SCSI pour les périphériques IDE, et de traduire à la volée les commandes SCSI en commandes ATAPI. À présent, les logiciels de gravage sont tous capables d'utiliser nativement les graveurs IDE, et cette couche d'émulation n'est plus que très rarement nécessaire. Elle ne sera donc pas décrite plus en détail ici.

8-2-3-2. Configuration du noyau

L'utilisation des graveurs de CD/DVD ne requiert généralement pas d'option particulière au niveau de la configuration. Autrement dit, si vous pouvez utiliser votre graveur comme un simple lecteur, alors vous pouvez également l'utiliser pour graver. Cependant, il peut-être intéressant d'activer le support de certains systèmes de fichiers pour utiliser correctement les lecteurs et les graveurs.

Les principales options de configuration du noyau ayant trait aux lecteurs et aux graveurs de CD/DVD sont récapitulées ci-dessous :

« Loopback device support »

Cette option permet d'activer une fonctionnalité permettant d'utiliser un fichier comme un périphérique normal. Elle est très utile pour tester les images de CD, car il suffit simplement de monter le fichier image comme un périphérique « loopback ». Il est donc recommandé d'activer cette fonctionnalité, que l'on dispose d'un graveur SCSI ou IDE. Cette fonctionnalité peut être activée sous la forme de module ou non, la réponse recommandée est 'Y'.

« Include IDE/ATA-2 CDROM support »

Cette option permet d'activer la gestion des lecteurs de CD IDE ATAPI. Vous devez répondre à cette question par 'Y' si vous disposez d'un graveur ou d'un lecteur IDE, ce qui est généralement le cas. La réponse recommandé est 'Y'.

« SCSI support »

Cette option permet d'activer la gestion des périphériques SCSI dans votre noyau. Il va de soi qu'il faut l'activer si vous disposez d'un graveur SCSI. Cette fonctionnalité peut être activée sous forme de module ou non. La réponse recommandée est 'N'.

« SCSI CD-ROM support »

Cette option permet d'activer la gestion des lecteurs de CD SCSI. Il faut l'activer si l'on dispose d'un graveur SCSI. La réponse recommandée est 'Y' si vous disposez d'un lecteur ou d'un graveur SCSI, et 'N' dans le cas contraire.

« Enable vendor-specific extensions (for SCSI CDROM) »

Cette option permet d'autoriser l'emploi d'extensions au protocole SCSI définies par les fabricants de matériels. Certains graveurs utilisent de telles extensions, c'est en particulier le cas des graveurs de CD HP. Toutefois, si vous ne disposez pas d'un tel graveur, il est peu probable que vous ayez à activer cette fonctionnalité. La réponse recommandée est donc 'N'.

« SCSI generic support »

Cette option permet d'utiliser les périphériques SCSI avec des commandes non standards, ce qui requiert l'emploi de programmes capables de communiquer directement avec les périphériques SCSI. C'est le cas pour les graveurs, qui seront pilotés directement par les logiciels de gravage. Il faut généralement activer cette fonctionnalité si l'on dispose de périphérique SCSI, aussi la réponse recommandée est-elle 'Y' si l'on se trouve dans cette situation.

« Probe all LUNs on each SCSI device »

Cette option permet, lorsqu'on dispose de périphériques SCSI capables de gérer plusieurs numéros d'unité logiques, de leur demander tous ces numéros. Ce type de périphérique est assez rare, et en général chaque périphérique n'utilise qu'un et un seul numéro d'unité logique. Il ne faut donc pas, en général, activer cette fonctionnalité. La réponse recommandée pour cette question est donc 'N'.

« ISO 9660 CDROM file system support »

Cette option permet de prendre en charge les systèmes de fichiers des CD-ROMs. Il est impératif d'activer cette fonctionnalité, aussi la réponse recommandée pour cette question est-elle 'Y'.

« Microsoft Joliet CDROM extensions »

Cette option permet de prendre en charge les extensions Microsoft au système de fichiers ISO 9660 (pour la gestion des noms longs du DOS). Étant donné le nombre de CDs qui utilisent ces extensions, il est impératif d'activer cette fonctionnalité. La réponse recommandée pour cette question est donc 'Y'.

« UDF file system support »

Cette option permet de prendre en charge les systèmes de fichiers UDF, utilisé par certains CD-ROMs gravés par paquets et par tous les DVDs. Il est impératif d'activer cette fonctionnalité, aussi la réponse recommandée pour cette question est-elle 'Y'.

Enfin, il faut choisir le pilote bas niveau permettant de gérer son graveur de CD. Pour les graveurs IDE ATAPI il n'y a pas de pilote bas niveau à inclure. Pour les graveurs SCSI, il faut choisir le pilote approprié de votre carte ou de votre contrôleur SCSI.

Une fois cette configuration effectuée, il ne reste plus qu'à compiler le noyau et les modules et à les installer. La manière de procéder a été décrite dans la section traitant de la compilation du noyau.

8-2-3-3. Configuration des modules du noyau

Vous aurez sans doute à modifier le fichier de configuration /etc/modprobe.conf si vous avez activé certaines fonctionnalités SCSI sous la forme de modules, afin de charger les modules nécessaires lorsqu'une commande sera effectuée sur l'un des fichiers spéciaux de périphériques SCSI. Si toutes les fonctionnalités SCSI sont intégrées au noyau, cette étape est bien entendue facultative. Les fichiers spéciaux utiles pour les périphériques blocs SCSI sont les fichiers scdx et sgx, où x est le numéro du périphérique. Les fichiers spéciaux du premier groupe sont de type bloc, et permettent d'accéder aux lecteurs de CD SCSI. Les fichiers du deuxième groupe en revanche sont de type caractère, et permettent d'accéder aux périphériques SCSI de manière générique. Les codes majeurs pour ces deux groupes de fichiers spéciaux sont respectivement 11 et 21, il faut donc ajouter les entrées du fichier modprobe.conf pour les modules nommés block-major-11 et char-major-21. Normalement, ces entrées sont déjà présentes dans le fichier fourni par votre distribution.

8-2-3-4. Installation des logiciels de gravage

Lorsque le noyau aura été correctement configuré et installé, il ne vous restera plus qu'à installer les logiciels de gravage. Les logiciels indispensables sont les suivants :

  • cdrecord, qui permet de piloter le graveur de CD et d'effectuer les tâches nécessaires pour le gravage ;
  • mkisofs, qui permet de créer des images disques ISO 9660, éventuellement avec les extensions Joliet (CD Windows 95), Rock Ridge (CD Unix) ou HFS (CD Macintosh) ;
  • cdda2wav, qui permet d'extraire les données numériques des CD audio ;
  • cdrdao, qui permet de réaliser des gravages bas niveau et en mode « Disk At Once ».

Vous pourrez vérifier que votre configuration fonctionne correctement si vous disposez d'un périphérique SCSI ou si vous utilisez l'émulation SCSI avec la commande suivante :

 
Sélectionnez
cdrecord -scanbus

Cette commande recherche tous les périphériques SCSI du système. Vous devrez normalement y trouver, en plus de vos autres périphériques SCSI, votre graveur de CD. Cette commande ne fonctionne pas si vous utilisez un graveur IDE.

8-2-3-5. Utilisation des logiciels de gravage

Nous allons à présent voir les commandes permettant de faire les principales opérations ayant trait au gravage des CDs. Bien que ce document soit consacré à l'installation de Linux et non à son utilisation, elles vous permettront de tester si tout fonctionne correctement.

La copie directe d'un CD peut se faire avec la commande suivante :

 
Sélectionnez
cdrecord -dummy -v dev=graveur speed=n -isosize /dev/source

L'option dev permet de spécifier le périphérique du graveur à utiliser. Cette option peut prendre en paramètre soit le fichier spécial de périphérique du graveur (par exemple /dev/hdc), soit un triplet de valeur permettant d'identifier un périphérique sur le bus SCSI (par exemple 0,1,0). La première valeur représente le bus SCSI sur lequel le graveur est branché, la deuxième le numéro de périphérique du graveur sur ce bus SCSI et la troisième son numéro d'unité logique (« Logical Unit Number »). Le numéro du bus SCSI et le numéro de périphérique peuvent être obtenus avec la commande cdrecord -scanbus présentée ci-dessus si vous utilisez un graveur SCSI. Le numéro d'unité logique est, dans la majorité des cas, 0.

Le nombre n donné dans la ligne de commande précédente doit valoir le facteur multiplicateur de la vitesse de gravage. Vous pouvez essayer avec des valeurs faibles pour commencer, afin d'être sûr que tout se passe bien. Le fichier de périphérique /dev/source quant à lui représente le fichier spécial de périphérique du lecteur de CD utilisé pour lire le CD-ROM. L'option -isosize permet de demander à cdrecord de lire la taille de la piste à graver dans le système de fichiers ISO9660 du CD source. Enfin, l'option -dummy permet de faire toutes les opérations en conservant le laser du graveur éteint, ce qui revient à faire un test. Si vous voulez réellement graver votre CD, il suffit de supprimer cette option.

Il va de soi que si vous ne disposez pas d'un lecteur de CD en plus de votre graveur, vous ne pouvez pas utiliser la commande précédente. Dans ce cas, vous devrez faire une image disque en extrayant toutes les données du CD source. Cela peut être réalisé avec la commande suivante :

 
Sélectionnez
dd if=/dev/source of=image

/dev/source est le fichier spécial de périphérique du lecteur utilisé pour faire l'image, et image est le fichier image qui doit être créé.

Le gravage d'une image disque peut être réalisé avec la commande suivante :

 
Sélectionnez
cdrecord -dummy -v dev=graveur speed=n -data image

où les options sont les mêmes que dans les commandes précédentes.

Si vous désirez créer une image disque à partir des fichiers de votre disque dur, vous pouvez utiliser mkisofs. Ce programme permet de créer une image disque ISO9660, avec les extensions Rock Ridge pour activer les fonctionnalités des systèmes de fichiers Unix (noms de fichiers plus longs, liens symboliques, droits d'accès…), et éventuellement les extensions Joliet utilisées par les systèmes Windows 95, Windows NT, Windows 2000 et XP (noms de fichiers longs Microsoft). Le prix à payer pour cette amélioration est la perte de quelques centaines de kilo octets, ce qui est dérisoire étant donné le gain en portabilité. La ligne de commande à utiliser pour créer une image disque est la suivante :

 
Sélectionnez
mkisofs  [-J][-r | -R][-hfs | -apple] [-C début,fin [-M disque]] \
     [-V "nom"] -o image répertoires

Les options -r ou -R, -J et -hfs ou -apple permettent respectivement d'utiliser les extensions Rock Ridge, Joliet ou HFS (pour les disques devant être lus sur les Macintosh). Il est possible de faire des images disque hybrides, qui pourront être lues sur plusieurs systèmes d'exploitation différents. La seule contrepartie est la perte de quelques dizaines de kilo-octets, ce qui est dérisoire. La distinction entre l'option -r et l'option -R est que -r modifie les attributs des fichiers Unix afin que le CD puisse être utilisé sur un autre ordinateur que celui sur lequel le CD a été créé. En particulier, le propriétaire et le groupe des fichiers voient leurs valeurs fixées à 0. L'option -V permet de fixer le nom du volume dans l'image. Il est possible de placer ce nom entre guillemets. Cette fonctionnalité est intéressante si ce nom comprend des espaces.

Il est possible de créer des CD multisessions à condition de spécifier l'emplacement de cette session lors de la création de l'image disque. Cela se fait avec l'option -C de mkisofs. Cette option prend en paramètre le numéro du secteur de début et le numéro du secteur de fin de la session à la suite de laquelle la nouvelle session doit être écrite, séparés par des virgules. Si l'on veut également importer la session précédente (c'est-à-dire permettre l'accès aux données des sessions précédentes comme si elles étaient également présentes dans la session à écrire), il faut utiliser l'option -M, à laquelle il faut indiquer le fichier spécial de périphérique du lecteur contenant le disque dont la session doit être importée.

La détermination des secteurs de début et de fin de la session précédente peut être difficile, mais cdrecord est capable d'obtenir cette information avec la commande suivante :

 
Sélectionnez
cdrecord dev=graveur -msinfo

Appelé ainsi, cdrecord affiche les secteurs de début et de fin de la dernière session du disque du lecteur spécifié par son option dev, directement dans le format attendu par mkisofs.

L'option -o de mkisofs permet de spécifier le nom du fichier image qui doit être créé. Les paramètres suivant l'option -o constituent la liste des répertoires et des fichiers qui doivent être insérés dans le CD-ROM. Par défaut, chaque répertoire ou fichier indiqué en paramètre est placé dans le répertoire racine du CD-ROM, et l'arborescence des sous-répertoires est respectée. Cependant, il est possible de placer un des répertoires ou fichiers indiqués en paramètre dans un autre répertoire du CD-ROM, à l'aide de la syntaxe suivante :

 
Sélectionnez
destination=source

destination est le répertoire destination du CD-ROM, et source le répertoire ou le fichier source à ajouter à l'image disque. De même, il est possible d'exclure certains sous-répertoires de l'image disque à l'aide de l'option -x :

 
Sélectionnez
-x répertoire

Les sous-répertoires du répertoire indiqué seront également supprimés de l'image disque.

Vous pouvez tester votre image disque en la montant par l'intermédiaire du périphérique virtuel du noyau loopback. Il faut pour cela que vous ayez activé la gestion de ce périphérique dans la configuration du noyau. La commande à utiliser est la suivante :

 
Sélectionnez
mount -t iso9660 -o ro,loop=/dev/loop0 image /cdrom

image est le nom de votre fichier image à tester. Cette commande monte le système de fichiers de cette image dans le répertoire /cdrom. La commande umount peut être utilisée pour démonter ce système de fichiers de la manière habituelle.

Lorsque votre image disque est satisfaisante, vous pouvez la graver avec la première ligne de commande suivante :

 
Sélectionnez
cdrecord -v dev=graveur speed=n -multi -data image

Vous noterez la présence de l'option -multi, qui permet de demander à cdrecord de créer un disque multisession. Bien entendu, vous pouvez vous passer de cette option si votre disque n'est pas multisession.

La création d'une image disque nécessite d'avoir une place disque égale à la taille de la session à ajouter, ce qui peut être contraignant. Sur les systèmes suffisamment puissants, il est possible de créer l'image disque et de la graver à la volée en créant un tube entre mkisofs et cdrecord. Dans ce cas, il ne faut pas donner de nom à l'image disque dans la ligne de commande de mkisofs, et utiliser l'option - dans la ligne de commande de cdrecord pour lui demander de prendre les données sur son entrée standard. Malheureusement, cette technique n'est pas utilisable facilement pour les disques multisessions, parce que la lecture des informations de la session précédente peut se faire en même temps que le début du gravage. Pour résoudre ce problème, il faut utiliser l'option -waiti de cdrecord, qui lui demande d'attendre l'arrivée des premières données dans le tube avant d'ouvrir le fichier spécial de périphérique du graveur. La ligne de commande complète devient alors assez complexe, comme vous pouvez en juger :

 
Sélectionnez
mkisofs -r -M périphérique -C `cdrecord dev=graveur -msinfo` \
  fichiers |  cdrecord -v dev=graveur speed=vitesse -multi -waiti -

Les commandes présentées ci-dessus ne permettent pas de travailler avec des CD audio. Pour extraire les données audio d'un CD, vous devrez utiliser le programme cdda2wav» :

 
Sélectionnez
cdda2wav [-H] -B nom [-tdébut[+fin]] -O wav dev=graveur

L'option -H permet d'éviter la création des fichiers d'information .inf sur les pistes extraites par cdda2wav. L'option -B permet d'utiliser le nom nom complété d'un numéro pour les fichiers son créés. Les pistes seront donc stockées dans des fichiers portant les noms nom_01, nom_02, etc. L'option -t permet d'indiquer la piste début et la piste fin afin de sélectionner les pistes dont les données audio doivent être extraites. Si la piste de fin n'est pas précisée, toutes les pistes depuis la piste de début jusqu'à la dernière piste du CD seront extraites. De même, si la piste de début n'est pas précisée, l'extraction commencera à partir de la première piste. L'option -O permet d'indiquer le type de fichier de sortie, wav indique ici que les fichiers créés seront au format WAV des fichiers son de Windows. Il est également possible d'utiliser le type de fichier raw, avec lequel les fichiers seront prêts à être gravés tels quels. Enfin, l'option dev permet de spécifier le périphérique à utiliser pour lire les données audio. La syntaxe de cette option est la même que celle utilisée par cdrecord.

Le gravage des pistes audio peut être réalisé avec la commande suivante :

 
Sélectionnez
cdrecord -dummy -v dev=graveur speed=n -nofix -audio  piste1.wav \
    piste2.wav …

L'option -nofix permet ici d'éviter de fermer la session. Elle doit être utilisée si l'on désire rajouter des pistes audio sur le CD-ROM ultérieurement. Si, en revanche, elle est omise, cdrecord fermera automatiquement la session après l'écriture de la dernière piste, et plus aucune donnée ne pourra être ajoutée. La commande suivante vous permettra de fixer le disque a posteriori :

 
Sélectionnez
cdrecord -dummy -v dev=graveur speed=n -fix

Enfin, si vous disposez d'un graveur de CD réinscriptible, vous pourrez utiliser la commande suivante pour effacer un CDRW :

 
Sélectionnez
cdrecord -dummy -v dev=graveur -blank=fast

graveur représente toujours le périphérique du graveur.

Il est peu probable que vous ayiez à utiliser ces commandes directement, car il existe de nombreux programmes graphique capable de les piloter de manière conviviale (k3b, gcombust, xcdroast, etc.). Il est vivement recommandé d'en installer un et de l'utiliser. Ils sont relativement simples d'emploi et leur utilisation ne devrait pas poser de problème particulier.

8-3. Configuration des cartes filles

Il existe un grand nombre de cartes filles sur le marché, dont les plus courantes sont sans doute les cartes graphique, les cartes son et les cartes réseau. Toutes ces cartes permettent d'ajouter des fonctionnalités de manière modulaire à une machine, en les enfichant dans les emplacements prévus à cet effet sur la carte mère.

Les cartes les plus vielles que l'on peut encore rencontrer sont les cartes ISA. La configuration de ces cartes a toujours été extrêmement difficile, en raison des nombreux conflits matériels qu'elles provoquaient entre elles et avec les ressources de la carte mère. Le standard Plug and Play a été introduit pour limiter ces problèmes par la suite, mais ce n'est qu'avec l'arrivée des cartes PCI que l'on a enfin pu commencer à brancher n'importe quoi n'importe comment dans un ordinateur (cela dit, ce n'est pas encore la panacée parce que l'on est toujours obligé d'éteindre l'ordinateur…). Enfin, les cartes graphiques ne se connectent plus de nos jours ni sur les ports PCI, ni sur les ports ISA, pour des raisons de performances et de débit de données. Elles utilisent un port spécial, le port AGP. Cela ne pose cependant pas de problème de configuration spécial (du moins si l'on se contente d'une seule carte graphique).

Ce chapitre traite de la manière de configurer les cartes ISA et PCI en général, et donne des informations plus détaillées pour chacun des types courants de cartes filles.

8-3-1. Généralités sur les cartes ISA, Plug And Play et PCI

L'architecture initiale des PC a très mal vieilli et souffre actuellement de défauts majeurs qui nuisent à leur développement. Sans parler des goulots d'étranglement sur les différents bus systèmes qui ne suivent plus les vitesses des processeurs actuels, la plupart des périphériques sont obligés de se restreindre à des protocoles de communication obsolètes pour conserver une compatibilité ascendante. L'une des limitations majeurs de cette architecture est le nombre incroyablement restreint de lignes d'interruption permettant à un périphérique de signaler au processeur qu'il a besoin de l'intervention de son gestionnaire pour poursuivre son travail, et la quasi absence des possibilités d'accès directs à la mémoire, qui impose l'utilisation du processeur pour réaliser de simples transferts de données entre les périphériques et la mémoire.

Ces ressources limitées, en plus de pénaliser les performances, posent des problèmes évidents d'extensibilité. En effet, qui dit ressource limité dit qu'il est impossible de connecter plus de périphériques « intelligents » que ce que l'architecture matérielle autorise. L'installation de plusieurs cartes ISA gérant chacune une interruption ou un canal DMA était réellement un casse-tête il y a encore peu de temps. C'est pour résoudre ces problèmes de configuration du matériel que le standard Plug and Play a été développé. Ce standard établit un protocole de communication matériel permettant au BIOS de configurer automatiquement les périphériques ISA en évitant les conflits sur les ressources partagées (le plus souvent, les lignes d'interruption).

Ce protocole a soulagé bien des gens, mais suppose un support spécifique de la part du système d'exploitation, puisque les paramètres matériels de chaque carte Plug and Play ne sont pas fixés d'un démarrage à l'autre de la machine. Il faut donc que le système soit ou capable de récupérer ces paramètres, ou de refaire la configuration du matériel. Cette deuxième solution est souvent imposée par le fait que bon nombre de BIOS sont bogués et effectuent une mauvaise configuration des cartes Plug and Play.

Le Plug and Play a été une amélioration sensible, mais n'a pas résolu les problèmes concernant les ressources limitées des PC. Heureusement, depuis l'avènement du bus PCI, ces limitations se sont estompées. En effet, le bus PCI permet non seulement aux périphériques de s'autoconfigurer et de se déclarer dans le système PCI, mais également de partager une même ligne d'interruption et de prendre le contrôle du bus mémoire. Ainsi, il n'y a virtuellement plus aucune difficulté pour installer une carte PCI dans un ordinateur. De nos jour, on ne trouve quasiment plus de cartes ISA, et la plupart des cartes mères n'acceptent même plus ces cartes.

Mais ne croyez pas pour autant que le bus PCI soit idéal, c'est loin d'être le cas. En effet, il ne permet pas encore l'ajout et la suppression de cartes à chaud (c'est-à-dire lorsque le système est allumé), et fonctionne désormais à une vitesse bien trop faible compte tenu de la vitesse des processeurs, cartes graphiques et circuits mémoire. Il est donc encore appelé à évoluer.

Le sous-système PCI de Linux permet d'utiliser directement les cartes PCI, sans configuration particulière. Les périphériques ISA, en revanche, peuvent être plus difficiles à configurer. S'ils ne sont pas Plug and Play, il n'y a pas d'autre choix que de spécifier leurs paramètres matériels directement, soit lors de la compilation du noyau, soit à l'aide d'options de boot lorsque le système démarre, soit à l'aide d'options dans le fichier /etc/modprobe.conf si leur gestionnaire est compilé sous forme de module. La première solution est la plus technique, puisqu'elle nécessite de reconfigurer et de recompiler le noyau, les deux autres relèvent de la configuration simple.

Les cartes ISA Plug and Play constituent un cas à part car, comme il l'a été dit ci-dessus, la plupart des BIOS Plug and Play sont bogués et les initialisent mal. Il est donc nécessaire que le système les initialise lui-même, et détermine par la même occasion leur configuration matérielle. En pratique, il existe deux possibilités pour effectuer ces deux opérations. La première possibilité est de laisser le noyau faire tout le travail de configuration des cartes et d'allocation des ressources. La deuxième possibilité est d'effectuer la configuration des cartes ISA Plug and Play au niveau applicatif dans les scripts de démarrage du système. Cette solution est relativement technique, et ne doit être utilisée que lorsqu'on désire contrôler finement les ressources allouées par les périphériques dans le système.

Si l'on désire utiliser les fonctionnalités Plug and Play du noyau, il n'y a strictement rien à faire. Linux se charge simplement d'initialiser automatiquement les cartes ISA Plug and Play lors du démarrage du système, de leur attribuer les paramètres matériels adéquats, et de communiquer ces paramètres aux gestionnaires de périphériques. Il prendra également en charge la gestion des conflits avec les autres périphériques, qu'ils soient ISA non Plug and Play ou PCI. Par conséquent, vous n'aurez aucune configuration spécifique à effectuer.

Mais Linux fournit également la possibilité de contrôler soi-même les ressources allouées à chaque périphérique, pour ceux qui veulent avoir la maîtrise totale de leur matériel ou ceux qui ont une configuration tellement spécifique qu'elle nécessite un paramétrage manuel. Dans ce cas, l'initialisation des cartes ISA Plug and Play ne se fera pas lors du démarrage du noyau, mais plutôt ultérieurement. En général, on effectue cette tâche dans les scripts d'initialisation du système, mais ce n'est pas une obligation. Quoi qu'il en soit, comme l'attribution des ressources aux cartes est différée, les gestionnaires de périphériques ne peuvent pas être inclus dans le noyau. Il est donc nécessaire d'utiliser les modules du noyau pour ces gestionnaires. Les paramètres matériels pourront alors être communiqués simplement à ces gestionnaires lors du chargement des modules, à l'aide d'options dans le fichier de configuration /etc/modprobe.conf.

La configuration manuelle des cartes ISA Plug and Play se fait classiquement à l'aide des outils « isapnp ». Parmi ces outils se trouve le programme isapnp, que l'on utilise pour initialiser les cartes ISA Plug and Play. Cet utilitaire utilise les informations qui se trouvent écrite dans le fichier de configuration /etc/isapnp.conf pour déterminer les plages d'entrée/sortie, les canaux DMA et les lignes d'interruption à utiliser pour chaque carte.

La rédaction manuelle du fichier isapnp.conf n'est pas une tâche aisée. Heureusement, cela peut être réalisé automatiquement, à l'aide d'un autre utilitaire nommé pnpdump. Celui-ci affiche la liste des différentes possibilités de configuration pour chaque périphérique ISA Plug and Play. Cette liste est affichée exactement sous une forme exploitable par isapnp, ce qui fait qu'il est très simple de créer un fichier de configuration correct en faisant une redirection de sa sortie standard dans un fichier :

 
Sélectionnez
pnpdump > /etc/isapnp.conf

Le fichier de configuration ainsi créé contient les différentes configurations possibles. Cependant, elles sont toutes commentées, et aucun périphérique ISA ne sera configuré sans intervention supplémentaire. Il va donc falloir éditer ce fichier et retirer les commentaires devant les options de configuration qui vous intéressent. Les lignes de commentaires commencent toutes par un caractère dièse ('#'). Il suffit donc d'effacer ce caractère pour les décommenter. Vous devez choisir les options à décommenter de telle manière qu'aucun conflit d'adresse, d'interruption ou de canal DMA n'existe dans votre système. Pour chaque périphérique, plusieurs possibilités sont offertes, mais vous ne devez retirer les commentaires que devant les lignes d'une seule de ces possibilités. Les zones à décommenter sont clairement identifiées dans le fichier isapnp.conf généré par pnpdump, il vous suffit donc d'effectuer le choix de la configuration à utiliser. Enfin, il ne faut pas oublier de retirer le commentaire devant la ligne suivante :

 
Sélectionnez
(ACT Y)

à la fin des différentes options de configuration pour chaque carte correctement configurée, faute de quoi elle ne sera pas activée lors de l'appel à isapnp.

En général, il est souhaitable d'appeler la commande isapnp à chaque démarrage du système, dans un des scripts de démarrage. Vous devrez donc inclure une ligne telle que celle-ci :

 
Sélectionnez
/sbin/isapnp /etc/isapnp.conf

dans le fichier de démarrage principal de votre système. Ce fichier peut se trouver dans le répertoire /etc/rc.d/ (ou dans /sbin/init.d/ selon la distribution que vous utilisez). La plupart des distributions permettent de paramétrer l'appel à cette commande à l'aide d'une option de configuration modifiable à l'aide de leur programme de configuration. Consultez la documentation de votre distribution pour plus de détails à ce sujet.

Une fois que vous aurez déterminé la configuration correcte pour vos périphériques dans le fichier /etc/isapnp.conf, vous pourrez charger les modules du noyau gérant ces périphériques. Cela peut nécessiter la modification du fichier /etc/modprobe.conf. Afin de limiter les risques d'erreur, vous devriez procéder comme suit :

  • déterminer le fichier spécial de périphérique utilisé par les applications pour accéder à votre périphérique ;
  • déterminer le nom du module que le noyau tentera de charger lorsqu'un programme tentera d'utiliser ce fichier spécial de périphérique ;
  • rechercher la ligne définissant l'alias pour ce nom de module, afin de savoir quel est le module qui sera effectivement chargé par modprobe. Vous pouvez également trouver ce nom dans la documentation de la configuration du noyau pour le gestionnaire du périphériques que vous configurez, ou en regardant directement dans le répertoire d'installation des modules /lib/modules/ ;
  • ajouter éventuellement la ligne « options module paramètres » permettant de spécifier les paramètres de chargement paramètres pour le module module ;
  • ajouter éventuellement les lignes « install » et « remove », permettant d'effectuer des actions complémentaires lors du chargement et du déchargement du module.

Comme il l'a été indiqué dans la Section 8.1.1, la détermination des noms de modules utilisés par le noyau pour les requêtes de chargement automatique n'est pas facile. Vous aurez sans doute à vous servir du type, du code majeur et du code mineur de ce fichier spécial de périphérique. Vous pourrez obtenir ces informations à l'aide de la commande ls -l fichier, où fichier est le nom du fichier spécial de périphérique. Le type de ce fichier est indiqué dans le premier caractère des droits du fichiers. Le caractère 'c' indique que le périphérique est un périphérique de type caractère, et le caractère 'b' indique qu'il s'agit d'un périphérique de type bloc. Les numéros de codes majeur et mineur quant à eux sont indiqués juste après les informations concernant le propriétaire et le groupe du fichier, généralement égaux à « root ».

Quoi qu'il en soit, il est fortement recommandé de lire la documentation du module gérant votre périphérique Plug and Play. Cette documentation est en général située dans le répertoire /usr/src/linux/Documentation/.

Pour tester si les modifications que vous avez effectuées sont correctes, vous pouvez essayer de charger le module avec la commande suivante :

 
Sélectionnez
modprobe module

module est le nom du module à charger. Vous pouvez également vérifier que ce module se charge bien lorsqu'une requête sur le fichier spécial de périphérique correspondant est effectuée, avec par exemple la commande suivante :

 
Sélectionnez
echo Coucou > /dev/périphérique

périphérique est le fichier spécial de périphérique à tester. Vous pouvez voir si le module s'est correctement chargé en demandant la liste des modules chargés à l'aide de la commande lsmod. Cette commande vous indique également l'état de chaque module, ainsi que le nombre de fois qu'il est utilisé et par qui. Si un module est marqué « uninitialized », vous avez de fortes chances de devoir redémarrer l'ordinateur et de revoir votre configuration, car un module qui se trouve dans cet état est inutilisable et peut parfois même refuser de se décharger.

8-3-2. Configuration des cartes son

8-3-2-1. Fonctionnalités du matériel

Les fonctionnalités fournies par les gestionnaires de son de Linux varient dans de larges proportions, selon le matériel utilisé. La quasi totalité des cartes son gèrent bien entendu l'essentiel : la restitution de fichiers audio numériques. Les fonctionnalités des cartes son sont à ce niveau relativement disparates : les différences vont du taux d'échantillonage utilisé jusqu'à la possibilité de les faire fonctionner en full duplex (enregistrement et lecture simultanée) ou non. Cette dernière fonctionnalité est essentielle pour les applications de téléphonie sur Internet par exemple.

De plus, très peu de cartes son sont capables de gérer la restitution des fichiers MIDI correctement (les fichiers MIDI sont des fichiers musicaux permettant de stocker les séquences de notes à jouer pour restituer le morceau, au lieu de stocker le son lui-même sous forme numérique). La plupart des cartes son ne fournissent aucun support matériel pour cela, et la restitution des notes des fichiers MIDI se fait généralement à l'aide d'un synthétiseur logiciel. C'est en particulier le cas pour toutes les cartes son intégrées sur les cartes mères des ordinateurs récents. Les gestionnaires de périphériques de Linux ne fournissent pas de synthétiseur logiciel, en revanche il existe plusieurs programmes permettant de lire les fichiers MIDI, moyennant une consommation plus ou moins importante des ressources de calcul de l'ordinateur.

La plupart des cartes son bas de gamme disposent toutefois d'un synthétiseur en modulation de fréquence (synthétiseur dit « FM »), qui permet de simuler des notes d'instrument de musique, généralement avec une qualité très médiocre. Certains pilotes de cartes son de Linux permettent d'utiliser ces synthétiseurs, mais ce n'est toujours pas la panacée. En réalité, si l'on veut restituer correctement les notes des fichiers MIDI, il faut utiliser une carte son disposant de ce que l'on appelle une table d'échantillons. Ces tables permettent de stocker dans la mémoire de la carte son des échantillons de sons d'instruments de musique enregistrés en qualité numérique. La carte son peut ainsi reconstituer le son de toutes les notes de musique fidèlement, avec une très grande ressemblance avec l'instrument réel. Ces cartes sont bien entendu plus coûteuses, mais la qualité sonore est incomparable à ce niveau (les cartes SoundBlaster AWE et Live en particulier disposent de tables d'échantillons). Linux permet parfaitement d'utiliser ces cartes, et même de charger de nouveaux jeux d'échantillons dans la mémoire de la carte pour changer la sonorité des instruments.

Je ne saurais donc que trop vous conseiller de bien vous renseigner avant l'achat d'une carte son, car ce sujet n'est pas très souvent pris en considération lors de l'achat. Bien entendu, si vous ne désirez pas utiliser votre carte son dans ses derniers retranchements, vous pouvez vous contenter des cartes intégrées sur les cartes mères. Dans les autres cas, renseignez-vous.

8-3-2-2. Configuration du noyau

La plupart des cartes son vendues actuellement sont des cartes PCI, qui se configurent relativement aisément. Cependant, il existe encore un bon nombre de cartes son ISA, dont la configuration peut être plus technique, surtout si elles ne sont pas Plug and Play.

La première étape lors de la configuration de votre carte son sera la sélection du gestionnaire de périphériques à utiliser dans le programme de configuration du noyau. En ce qui concerne les cartes son, les options de configuration se trouvent dans le menu « Sound ». Vous y trouverez deux jeux de pilotes : les pilotes ALSA (« Advanced Sound Linux Architecture ») et les pilotes OSS (« Open Sound System »). Les pilotes ALSA sont les plus modernes, et devront être utilisés en priorité, car ils fournissent le plus de fonctionnalités. Les pilotes OSS sont des pilotes plus anciens, qui sont toutefois maintenus à titre de compatibilité d'une part et, d'autre part, parce que certaines cartes son ne sont pas encore totalement prises en charge par les pilotes ALSA. Les pilotes OSS sont eux-mêmes classés en deux catégories : les pilotes classiques (première partie des options du menu) et les pilotes OSS purs. Ces derniers utilisent une spécification d'interface de programmation commune permettant l'accès aux cartes son, mais il n'y a pas de différence au niveau des applications pour l'utilisation de ces pilotes. Vous devez choisir le gestionnaire de périphériques ALSA ou OSS qui convient le mieux à votre matériel.

L'erreur la plus classique que l'on peut faire au niveau du choix du pilote est de supposer que l'on possède une carte compatible Sound Blaster alors que ce n'en est pas une. Je tiens à préciser que quasiment aucune carte dite « compatible » sous Windows ne l'est sous Linux. La compatibilité sous Linux, c'est le fait d'avoir quasiment la même électronique ou du moins les mêmes interfaces au niveau matériel. Sous Windows, la compatibilité n'existe qu'au niveau des interfaces fournies par le pilote de la carte son. Par conséquent, il vous faut savoir exactement de quel nature est votre carte son, et non ce que vous avez retenu des arguments commerciaux du fabricant. Notez en particulier que certaines cartes Sound Blaster ne sont pas compatibles Sound Blaster (Creative Labs est renommé en ce qui concerne les incompatibilités entre les différents modèles de cartes son). C'est notamment le cas pour les cartes sons SB64 PCI et SB128 PCI, qui sont en réalité des cartes son ESS1370 ou ESS1371, et dont l'électronique est fabriquée par la société Ensoniq (cette société a été rachetée par Creative Labs, qui vend ces cartes en s'appuyant sur son image de marque et qui sème ainsi la confusion sur le marché). En conclusion, si vous ne voulez pas essayer plusieurs pilotes et recompiler le noyau jusqu'à ce que vous trouviez le bon, renseignez-vous bien sur la nature de votre carte son (si possible avant de l'acheter, au moins afin de savoir exactement ce que vous aurez). Vous pouvez également taper la commande lspci afin de voir les périphériques réellement présents sur le bus PCI. La commande système dmesg peut également vous être utile. Elle permet de réafficher la liste des messages de traces générés par le noyau, et vous y trouverez donc les messages relatif à la phase de détection des périphériques.

Lorsque vous aurez choisi le gestionnaire de périphériques adéquat, vous aurez le choix entre le compiler à l'intérieur du noyau (en choisissant l'option 'Y') ou le compiler sous forme de module (en choisissant l'option 'M'). Il est possible soit de charger ces pilotes en tant que module, soit de les intégrer au noyau. En général, il est préférable d'utiliser les modules, car les programmes de configuration audio peuvent ainsi détecter automatiquement les cartes son utilisées. De plus, certaines fonctionnalités non essentielles sont souvent désactivées par défaut par les pilotes, et doivent être activées explicitement à l'aide d'une option lors du chargement du module ou d'un paramètre à fournir au noyau lors de son amorçage. Les modules sont donc là aussi plus faciles à utiliser, car ils éviteront de redémarrer le système à chaque essai. Cependant, pour la plupart des paramètres matériels (en particulier les lignes d'interruptions, les ports d'entrée/sortie et les canaux d'accès direct à la mémoire), Linux déterminera automatiquement les valeurs correctes. Cette configuration n'est donc pas à faire, et votre carte son fonctionnera généralement immédiatement.

Les vielles cartes son ISA qui ne sont pas Plug and Play devront généralement également être intégrées au noyau. En effet, pour ces cartes sons, la configuration logicielle est très simple, puisqu'on ne peut pas les configurer du tout, et l'on n'a donc pas besoin de modules du tout. Bien entendu, il faut que vous ayez résolu manuellement les conflits possibles de matériel de votre ordinateur en fixant les switchs adéquats sur vos cartes filles, mais cela ne concerne pas Linux. Pour ces cartes, il faut généralement indiquer au noyau les paramètres matériels (IRQ, DMA et ports d'entrée/sortie) lors de la configuration.

Il se peut toutefois que vous ne puissiez pas spécifier ces paramètres matériels dans les menus de configuration de Linux. Bien qu'en théorie il soit possible de modifier les fichiers sources de Linux directement pour indiquer ces paramètres, ce n'est pas à la portée du commun des mortels. Par conséquent, on utilisera malgré tout dans ce cas les modules du noyau, et les options matérielles seront indiquées dans le fichier de configuration /etc/modprobe.conf. Notez que c'est également de cette manière que vous devrez procéder si vous désirez configurer vous-même l'allocation des ressources pour les cartes son ISA Plug and Play, ou, autrement dit, si vous préférez utiliser l'outil isapnp au lieu des fonctionnalités Plug and Play du noyau.

8-3-2-3. Configuration des modules du noyau

Si vous compilez les gestionnaires de son sous la forme de modules, vous devrez ajouter les alias et les options nécessaires à leur chargement dans le fichier /etc/modprobe.conf.

Les fichiers spéciaux de périphériques utilisés ne sont pas les mêmes pour les pilotes OSS et les pilotes ALSA. Les premiers utilisent les fichiers spéciaux /dev/audio?, /dev/dsp? et /dev/mixer?, dont le numéro de code majeur est 14, alors que les seconds utilisent les fichiers spéciaux de périphériques /dev/aloadCn et /dev/aloadSEQ, ainsi que tous les fichiers spéciaux de périphérique du répertoire /dev/snd/, tous de numéro de code majeur 116. Les pilotes ALSA étant également capables de simuler le comportement des pilotes OSS par compatibilité, ils utilisent le numéro de code majeur 14 également.

Lorsque le noyau désire accéder aux fonctionnalités d'ALSA ou d'OSS, il cherche donc à charger, selon les fichiers spéciaux de périphériques utilisés, les modules char-major-116 ou char-major-14. Le premier doit être associé au module snd d'ALSA, alors que le second doit être associé au module soundcore. Ces modules prennent en charge respectivement les systèmes de son d'ALSA et d'OSS. Le fichier /etc/modprobe.conf devra donc définir ces alias comme suit :

 
Sélectionnez
# Permet le chargement des pilotes ALSA :
alias char-major-116 snd

# Permet le chargement des pilotes OSS ou l'émulation des pilotes OSS par ALSA :
alias char-major-14 soundcore

Les systèmes de son gérés par ces modules permettent de prendre en charge plusieurs cartes son. Chaque carte son est bien entendu référencée par le numéro de code mineur du fichier spécial de périphérique utilisé. Il faut donc définir, pour chaque carte son, le module du gestionnaire de périphérique de cette carte son. Cela se fait en définissant les alias pour les noms de modules génériques snd-card-n pour ALSA et sound-slot-n pour OSS, où 'n' est le numéro de la carte son.

Par exemple, si l'on dispose d'une carte son SoundBlaster 128 avec les pilotes ALSA, le module à utiliser est snd-ens1370 ou snd-ens1371 selon le modèle (parce que ces cartes son sont en réalité des cartes Ensoniq). Le fichier de configuration /etc/modprobe.conf devra donc contenir les alias suivants :

 
Sélectionnez
# La première carte son est gérée par le module snd-ens1371 :
alias snd-card-0 snd-ens1371
alias sound-slot-0 snd-card-0

Si vous désirez utiliser les pilotes OSS, le module à utiliser pour ce type de carte se nomme es1371, ce qui fait que le fichier de configuration /etc/modprobe.conf se réduit dans ce cas à :

 
Sélectionnez
# La première carte son est gérée par le module es1371 :
alias sound-slot-0 es1371

Les modules des gestionnaires de périphériques peuvent prendre des options permettant de contrôler les ressources matérielles et les fonctionnalités prises en charge. Vous pourrez trouver la liste des différents modules de pilotes de périphériques disponibles, ainsi que leurs options, dans la documentation fournie dans le répertoire Documentation/sound/ des sources du noyau.

Enfin, les pilotes de périphériques OSS n'implémentent pas forcément l'ensemble des fonctionnalités classiques des cartes son. Lorsqu'une de ces fonctionnalité est demandée, le pilote peut donc demander le chargement d'un module complémentaire. Le nom utilisé par le noyau pour ce module est « sound-service-n-m », où 'n' est le code majeur du fichier spécial de périphérique de la carte son et m le code de la fonctionnalité utilisée. Ces codes correspondent aux numéros de codes mineurs des fichiers spéciaux de périphériques permettant d'accéder à ces fonctionnalités. Ainsi, la valeur 0 correspond au mixeur (fichier spécial de périphérique /dev/mixer), la valeur 2 correspond au port MIDI (fichier spécial de périphérique /dev/midi), et les codes 3 et 4 au canal de la carte son (fichiers spéciaux de périphériques /dev/dsp et /dev/audio). La liste des fichiers spéciaux de périphériques utilisés par OSS peut être consultée dans le fichier Documentation/devices.txt.

Si vous utilisez les pilotes ALSA, vous devrez ajouter les alias suivants dans le fichier /etc/modprobe.conf afin de charger à la demande les modules d'émulation des services OSS :

 
Sélectionnez
# Charge les modules ALSA des services OSS :
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

8-3-2-4. Ajustage des paramètres audio avec ALSA

Ces opérations vous permettront de faire fonctionner votre carte son pour toutes les opérations de base, à savoir la lecture et l'enregistrement de fichiers son, le réglage du volume sonore et éventuellement la lecture des CD audio par l'intermédiaire de votre carte son (si, bien entendu, vous avez relié la sortie audio de votre lecteur de CD à l'entrée auxiliaire de votre carte son).

Le réglage des paramètres de votre carte son peut être réalisé très simplement si vous utilisez les pilotes ALSA. En effet, il existe une application en mode texte permettant de réaliser ces réglages. Cette application se lance simplement avec la commande alsamixer

Comme vous pouvez le constater, cette application présente une interface très simple, dans laquelle chaque canal de la carte son peut être réglé indépendamment. Pour passer d'un canal à l'autre, il suffit d'utiliser les flèches droite et gauche, et pour régler les volumes, d'utiliser les flèches haut et bas du clavier. Vous pouvez également rendre un canal complètement muet en appuyant sur la touche 'M'. Cette touche permet également d'activer ou de désactiver certaines fonctionnalités de votre carte son. Lorsque les réglages vous conviendront, vous pouvez simplement quitter alsamixer en appuyant sur la touche 'Échap'.

Les réglages réalisés de cette manière ne sont pas permanents. Cela signifie que d'un redémarrage à l'autre de la machine, les valeurs par défaut seront reprises. ALSA fournit donc également l'outil alsactl, qui permet d'enregistrer les paramètres des cartes son dans le fichier de configuration /etc/asound.conf. Pour cela, il suffit simplement d'appeler cette commande avec l'option store :

 
Sélectionnez
alsactl store

alsactl permet également de restaurer les paramètres sauvegardés, à l'aide de son option restore. On aura donc tout intérêt à placer une ligne telle que celle-ci dans les fichiers d'initialisation de sa distribution, si ce n'est déjà fait :

 
Sélectionnez
alsactl restore

Par ailleurs, pour les cartes son qui disposent d'un synthétiseur FM, il peut être intéressant d'activer cette fonctionnalité. Généralement, les pilotes ALSA désactivent cette fonctionnalité. Elle peut toutefois être réactivée en spécifiant le port d'entrée / sortie du synthétiseur FM de la carte son à l'aide de l'option fm_port. du module prenant en charge votre carte son. De même, vous pourrez activer la gestion des pilotes MIDI en ajoutant l'option mpu_port et en indiquant le numéro de port pour le port MIDI. Vous pouvez consulter le fichier de documentation Documentation/sound/alsa/ALSA-Configuration.txt des sources du noyau Linux pour plus d'informations à ce sujet. En général, le numéro de port utilisé pour les synthétiseurs FM est le numéro 0x388, et le numéro du port MIDI est le 0x300. Par exemple, pour une carte son CMI, la ligne suivante pourra être ajoutée dans le ficher de configuration modprobe.conf :

 
Sélectionnez
options snd-cmipci fm_port=0x388 mpu_port=0x300

Si vous désirez compiler en dur le pilote de votre carte son, vous devrez fournir ces informations en ligne de commande à l'amorçage du noyau. Vous devez donc ajouter, pour chacun de ces paramètres, une option à la ligne de commande du noyau. Par exemple, pour une carte son CMI, il faudrait ajouter les options suivantes dans le fichier de configuration du GRUB ou dans le fichier lilo.conf :

 
Sélectionnez
snd-cmipci.index=0 snd-cmipci.fm_port=0x388 snd-cmipci.mpu_port=0x300

La première option permet d'indiquer que cette carte son est la première carte son du système. Elle peut être nécessaire si vous avez intégré dans le noyau des pilotes pour d'autres cartes son, réelles ou virtuelles. Les autres options sont directement déduites de celles spécifiées dans le fichier modprobe.conf.

Enfin, vous aurez sans doute à charger une banque de sons dans le pilote, que vous utilisiez une synthèse FM ou une table d'échantillons. La manière de procéder est toutefois différente selon la carte son utilisée. Pour les cartes sons qui ne disposent que d'une émulation FM, il faut utiliser le programme sbiload. Ce programme est fourni avec les outils complémentaires d'ALSA, et disponible sur le site web du projet ALSA. Ce programme permet de charger dans le pilote les définitions des notes en modulation de fréquence. La syntaxe est la suivante :

 
Sélectionnez
sbiload -p65:0 --opl3 std.o3 drums.o3

Cette commande permet de charger dans le périphérique MIDI ALSA 65:0 les fichiers de définition de notes std.o3 et drums.o3. Ces fichiers sont fournis avec sbiload (pas dans toutes les versions toutefois). L'option --opl3 permet d'indiquer le format de ces fichiers. Quant à l'option -p, elle permet d'indiquer le port MIDI dans le pilote ALSA. Les numéros de ports disponibles peuvent être obtenus avec la commande suivante :

 
Sélectionnez
sbiload -l
Note : La commande sbiload ne fonctionne qu'avec les ports MIDI FM.

Si le périphérique MIDI FM ne s'affiche pas, c'est que soit votre carte son n'en dispose pas, soit il n'a pas été activé dans le pilote et qu'il faut fournir l'option fm_port au module ou au noyau lors de son démarrage, soit que le module snd-synth-opl3 n'a pas été chargé.

Pour les cartes son qui disposent d'une table d'échantillons, le programme à utiliser est différent. Pour les cartes Sound Blaster AWE et Sound Blaster Live, ce programme se nomme sfxload. Ce programme peut être trouvé sur le site http://mitglied.lycos.de/iwai/awedrv.html. Vous trouverez également les fichiers de patches utilisables avec les cartes son AWE sur ce site. Vous pouvez utiliser le fichier de définition des patches de Creative, que vous trouverez normalement soit sur une installation de Windows avec une carte son AWE, soit sur vos CD d'installation, soit sur Internet. Le fichier fourni par Creative se nomme synthgm.sbk.

Pour charger les patches dans la mémoire de la carte, il suffit d'utiliser la commande suivante :

 
Sélectionnez
sfxload /usr/lib/synthgm.sbk

(en supposant que le fichier de patches soit placé dans le répertoire /usr/lib/). Vous pourrez placer cette commande dans les scripts de démarrage de votre système ou dans une option de chargement du module de prise en charge de votre carte son.

8-3-2-5. Fichiers MIDI et synthétiseurs logiciels

Comme indiqué en introduction, la plupart des cartes son ne permettent pas de lire les fichiers MIDI au niveau matériel. Les fichiers MIDI sont des fichiers ne contenant que les « partitions » des morceaux enregistrés. Ils ne contiennent pas les données audio numériques comme c'est le cas pour les fichiers son classiques ou les pistes de CD audio. Cela explique leur taille réduite, mais pose un problème pour leur restitution. En effet, la lecture d'un fichier MIDI suppose que votre carte son dispose d'un jeu de sons numérisés dans sa mémoire afin de pouvoir reconstituer le signal sonore à partir des informations du fichier MIDI. Ces sons sont couramment appelés des « échantillons » (« patches » en Anglais), et ils peuvent être enregistrés soit en dur dans la mémoire de la carte son, soit chargés lors de son initialisation. Il va de soi que certaines cartes son ne disposent pas des fonctionnalités nécessaires à la lecture des fichiers MIDI. Dans ce cas, il faut utiliser un programme externe capable de synthétiser le son à partir d'échantillons enregistrés sur le disque dur et d'envoyer les données audio ainsi créées à la carte son pour la lecture.

Pour les cartes son ne disposant pas de la possibilité de lire les fichiers MIDI, il ne reste que la solution de l'émulation logicielle. Le meilleur synthétiseur logiciel sous Linux est incontestablement le logiciel Timidity. Timidity est un programme de lecture de fichiers MIDI très complet, paramétrable et capable d'utiliser des banques de sons externes variées. De plus, le moteur de Timidity est utilisé par de nombreux autres programmes, en particulier par le lecteur KMidi de KDE.

L'auteur originel de Timidity ne le maintient plus. Cependant, d'autres programmeurs ont pris le relais et l'ont amélioré pour en faire la version Timidity++. Cette dernière version peut être trouvée sur Internet sur le site de Timidity. L'archive que vous récupérerez ne contient pas forcément le programme : il peut ne s'agir que des fichiers sources permettant de le générer. Les notions de fichiers sources et de compilation de programmes exécutables seront expliquées en détail dans le chapitre suivant. En attendant, si vous récupérez les sources, vous pourrez suivre les indications données ci-dessous pour compiler et installer Timidity.

Timidity peut utiliser différentes interfaces utilisateur, accessibles via différentes bibliothèques. De plus, il est capable d'utiliser différentes interfaces pour lire et jouer les morceaux. En particulier, il peut être utilisé comme un serveur MIDI via ALSA afin que tous les programmes MIDI puissent y accéder via les interfaces standard d'ALSA. De même, il est capable de partager le canal audio de sortie de la carte son via le serveur de son aRts de KDE. Pour utiliser ces fonctionnalités, il faut configurer les sources avec la ligne de commande suivante :

 
Sélectionnez
./configure --prefix=/usr --enable-dynamic --enable-server \
         --enable-interface=gtk,ncurse --enable-audio=arts,alsa,oss --enable-alsaseq

Une fois cela fait, vous pourrez générer l'exécutable avec la commande suivante :

 
Sélectionnez
make

et l'installer avec la commande :

 
Sélectionnez
make install

Cela installera Timidity dans le répertoire /usr/bin/.

La deuxième étape est bien entendu d'installer les fichiers de patches. Timidity utilise des patches pour les cartes son Gravis Ultrasound. Vous pourrez trouver des archives contenant de tels patches sur Internet très facilement. En particulier, la collection de patches EAWPATS réalisée par Eric A. Welsh est très complète. Cette collection a de plus l'avantage d'être préconfigurée pour l'emploi avec Timidity.

Lorsque vous aurez installé les fichiers de patches, vous devrez indiquer à Timidity leur emplacement dans le système de fichiers. Cette information doit être stockée dans le fichier de configuration timidity.cfg du répertoire /usr/share/timidity/. Vous pourrez vous inspirer du fichier fourni avec la collection de patches EAWPATS. Cependant, vous aurez à modifier les chemins indiqués dans ce fichier, car il a été écrit pour la version Windows de Timidity. Le premier répertoire à indiquer est celui des bibliothèques. Il faut ici simplement remplacer la ligne « dir c:\timidity » par la ligne « dir /usr/lib/timidity ». Notez que cette ligne est facultative et peut être commentée si vous n'avez pas déplacé ce répertoire. Le deuxième répertoire est plus important, puisque c'est le répertoire d'installation des patches. Il s'agit cette fois de remplacer la ligne « dir c:\eawpats » par la ligne « dir répertoire », où répertoire est le répertoire où vous avez extrait les fichiers patches.

Une fois que vous aurez terminé ces modifications, vous pourrez lire un fichier MIDI simplement en utilisant la ligne de commande suivante :

 
Sélectionnez
timidity fichier

fichier est le nom du fichier MIDI à lire. Si vous désirez utiliser l'interface graphique de Timidity, vous n'avez qu'à ajouter l'option -ig à la ligne de commande précédente. Enfin, si vous désirez utiliser Timidity en tant que séquenceur système ALSA et permettre le mixage du flux audio qu'il produit avec les flux des autres applications par l'intermédiaire du serveur de son aRts de l'environnement de développement de KDE, vous devrez utiliser les options -iA -OR -B2,8 -EFreverb=0. Les programmes MIDI devront ensuite se connecter sur le port MIDI 128:0 d'ALSA.

L'installation de KMidi ne pose pas de problème particulier, puisqu'il est fourni avec KDE et que KDE est normalement inclus dans toute bonne distribution. La seule opération que vous ayez à faire est simplement de modifier le fichier de configuration de KMidi pour lui indiquer l'emplacement des fichiers de patches. Or comme KMidi est basé sur les sources de Timidity, il utilise le même fichier de configuration timidity.cfg que Timidity. Ce fichier est normalement situé dans le répertoire /base/kde/share/apps/kmidi/config/, où base représente le répertoire de base d'installation de KDE. Vous n'aurez donc qu'à répéter les opérations faites sur le fichier de configuration de Timidity avec le fichier de configuration de KMidi.

8-3-3. Installation d'une carte graphique 3D

De nos jours, toutes les cartes graphiques disposent d'une accélération matérielle non seulement pour les opérations graphiques en 2D, mais également pour le calcul de scènes en 3D. Ce développement des cartes 3D a été principalement poussé pour les jeux, mais ces fonctionnalités sont également très utiles pour les applications de modélisation et de conception.

La manière dont les opérations graphiques en 3D sont réalisées dépend évidemment du modèle de carte graphique utilisée, car il n'existe pas de standard au niveau matériel. Comme il est impensable que les applications qui désirent utiliser les fonctionnalités 3D des ordinateurs modernes aient à prendre en compte le type de carte utilisée, des interface logicielles standards ont été définies.

De toutes ces interfaces, Linux n'en gère qu'une seule : OpenGL. Cette interface a été définie par Silicon Graphics pour ses stations de travail haut-de-gamme et s'est imposée comme étant la norme en la matière pour ce qui est de la 3D. Cette interface a l'avantage d'être ouverte et disponible sur la plupart des systèmes, qu'ils soient de type Unix ou non.

La prise en charge de l'interface OpenGL est réalisée à deux niveaux sous Linux. La partie principale réside dans le serveur X qui, comme nous l'avons déjà signalé, n'est rien d'autre que le programme fournissant les services graphiques aux autres applications sous Unix. Cette partie est implémentée par une extension de l'interface de programmation XWindow, que l'on nomme tout simplement GLX. Cependant, le serveur X ne peut pas tout faire à lui tout seul car, pour des raisons de performances, il lui faut accéder directement au matériel lors du rendu de scènes 3D. Il s'appuie donc pour cela sur un module du noyau, dont le but est de contrôler les accès au ressources matérielles et de garantir ainsi la stabilité globale du système.

La configuration des fonctionnalités 3D des cartes graphiques sous Linux nécessite donc d'intervenir à la fois dans le noyau et au niveau du serveur X. Pour ce qui est du noyau, il faut tout d'abord s'assurer que les fonctionnalités d'accès direct au matériel sont bien supportées. Ces fonctionnalités sont couramment appelées « DRI », ce qui est l'abréviation de l'anglais « Direct Rendering Infrastructure ». Pour activer les fonctionnalités DRI, vous devrez, dans la configuration du noyau, valider l'option « Direct Rendering Manager » du menu « Character devices », ainsi que le type de carte graphique utilisée (3Dfx, 3dlabs, ATI Rage 128 ou ATI Radeon, chipset i810 ou Matrox G200/G400).

Note : Les fonctionnalités 3D des cartes graphiques basées sur les puces NVidia ne sont pas supportées directement par X.org et par le noyau. En revanche, NVidia fournit un pilote pour Linux pour ces cartes, qui, bien qu'il n'utilise pas DRI, dispose également d'un module du noyau et d'un module pour X.org.

Quelle que soit votre carte graphique, vous aurez également sans doute intérêt à activer le support du bus AGP dans le noyau, si bien sûr votre carte graphique est une carte AGP. Pour cela, il suffit d'activer l'option « /dev/agpgart (AGP support) » dans le menu « Character devices » de la configuration du noyau, ainsi que le type de chipset utilisé par votre carte mère.

Une fois la configuration du noyau faite, vous pourrez le recompiler et l'installer. La manière de procéder a été décrite en détail dans la Section 7.3.

Vous devrez également vous assurer que le fichier spécial de périphérique /dev/agpgart est bien présent dans le répertoire /dev/. Son code majeur est 10, et son code mineur est 175. De même, si vous avez compilé les options précédentes sous la forme de modules du noyau, assurez-vous qu'ils sont bien référencés dans le fichier modprobe.conf.

La suite des opérations se passe alors au niveau de la configuration du serveur X de X.org. L'activation du support de l'AGP et d'OpenGL se fait simplement en rajoutant deux options dans le fichier de configuration /etc/X11/xorg.conf. Vous devez trouver la section « Modules » et lui ajouter les deux lignes suivantes :

 
Sélectionnez
Section "Module"
     .
     .
     .
     Load "dri"
     Load "glx"
     .
     .
     .
EndSection

Vous trouverez de plus amples renseignements sur la manière de procéder dans le Chapitre 10.

Note : Pour le pilote fourni par NVidia pour X.org, il n'est pas nécessaire de demander le chargement du module DRI, car il ne l'utilise pas.

Il est supposé ici que le serveur X utilisé correspond bien à la carte graphique et dispose des fonctionnalités 3D. Si ce n'est pas le cas, vous devrez sans doute réinstaller X.org.

Les programmes utilisant OpenGL utilisent souvent une bibliothèque complémentaire nommée GLUT. Cette bibliothèque est fournie avec la couche d'émulation logicielle d'OpenGL MESA. Toutefois, la bibliothèque GLUT n'est disponible que dans les programmes d'exemples de MESA. Vous devrez donc réinstaller MESA complètement si votre distribution ne fournit pas la bibliothèque GLUT.

8-3-4. Installation d'une carte d'acquisition vidéo

Linux fournit toutes les fonctionnalités nécessaires à la manipulation des flux de données vidéo par l'intermédiaire d'une interface de programmation nommée video4linux (ce qui se lit « Video for Linux »). Linux est capable de gérer la plupart des cartes d'acquisition TV du marché et quelques-unes des cartes d'acquisition vidéo. Comme d'habitude, seuls les constructeurs de matériel qui ont accepté de jouer le jeu de fournir les informations nécessaires à la programmation de gestionnaires de périphériques libres voient leur matériel supporté sous Linux. Par conséquent, il est encore une fois nécessaire de bien se renseigner sur la nature du produit et la politique du fabricant lorsqu'on achète une carte d'acquisition TV.

En pratique, quasiment toutes les cartes d'acquisition TV utilisent les circuits intégrés Bt848 ou un de leurs dérivés, et Linux sait les gérer sans problèmes. Les cartes d'acquisition et de montage vidéo utilisent d'autres circuits plus puissants, dont les spécifications ne sont généralement pas disponibles. Seule la configuration des cartes TV sera donc décrite ci-dessous.

Les applications, pour accéder aux périphériques vidéo, utilisent l'un des fichiers spéciaux de périphérique /dev/video*. Ces fichiers sont des fichiers de type caractère, dont le code majeur vaut 81. Le code mineur est utilisé pour différencier les différents périphériques installés sur votre système. En général, il existe un lien symbolique /dev/video sur l'un de ces fichiers spéciaux, qui sera utilisé pour accéder au périphérique vidéo par défaut. Normalement, tous ces fichiers sont installés d'office dans le répertoire /dev/ soit par les distributions, soit par udev au démarrage du système, et vous n'aurez donc généralement pas à les créer vous-même.

Le support de la vidéo sous Linux passe bien entendu par la configuration du noyau. Cette fois, il n'est pas certain du tout que le noyau fourni avec votre distribution supporte les cartes d'acquisition TV, aussi aurez-vous peut-être à recompiler vous-même votre noyau. La manière de procéder a été décrite en détail dans la Section 7.3.

Sachez toutefois que les options à valider dans la configuration du noyau se trouvent dans le menu « Multimedia devices ». Vous devrez activer l'option « Video For Linux ». Si vous compilez cette fonctionnalité sous la forme de module, celui-ci sera nommé videodev. Ce pilote se chargera de répondre aux requêtes du client sur les fichiers spéciaux de périphérique /dev/video*. Lorsque vous aurez activé la fonctionnalité de vidéo pour Linux, vous aurez le choix des pilotes de cartes vidéo dans le sous-menu « Video adapters ». Il est recommandé de compiler ces gestionnaires de périphériques sous la forme de modules, car il vous faudra sans doute spécifier des options afin d'adapter ces gestionnaires à votre matériel.

Note : La configuration des cartes basées sur la puce Bt848 (option de menu « BT848 Video For Linux ») n'est accessible que si vous avez également activé l'option « I2C bit-banging interfaces » du menu « I2C support » (lui-même situé dans le menu « Character devices »).

De plus, le pilote prenant en charge les puces du type Bt848 ne prend pas en charge la gestion du son. Ces puces n'intègrent en effet pas de gestion du son, et nécessitent de brancher la sortie audio de la carte TV sur l'entrée ligne d'une carte son. Toutefois, un mixeur est disponible. Celui-ci est pris en charge automatiquement pour les pilotes de son ALSA. Pour les pilotes OSS en revanche, un gestionnaire spécifique devra être activé. L'option correspondante est l'option « TV card (bt848) mixer support ». Pour les puces Bt878, qui sont plus récentes, une carte son intégrée est fournie, et il existe un pilote complet ALSA et OSS, que l'on devra également activer.

Une fois le noyau recompilé et installé, il faut modifier les paramètres adaptés à votre matériel. En effet, bien que Linux soit parfaitement capable de déterminer les ressources requises par les cartes vidéo, il est rare que le matériel soit correctement identifié par les gestionnaires de périphériques. Cela est dû au fait que les gestionnaires se basent plus sur les composants courants permettant de faire l'acquisition vidéo que sur les modèles de cartes de chaque fabricant. La palme revient sans doute au gestionnaire pour les cartes basées sur les puces Bt848 et ses dérivées, puisqu'il est capable de faire fonctionner toutes les cartes vidéo de tous les fabricants qui utilisent cette puce. Par conséquent, il faut indiquer le modèle de la carte au gestionnaire, et bien souvent le modèle de tuner doit également être spécifié.

Si vous avez compilé les gestionnaires de périphériques sous forme de module, vous pourrez spécifier le type de carte et le type de tuner simplement dans le fichier de configuration /etc/modprobe.conf, à l'aide des options du module du gestionnaire de périphérique adéquat. Pour les cartes basées sur la puce Bt848, le gestionnaire de périphérique est pris en charge par le module bttv. Le type de carte peut lui être communiqué à l'aide de l'option card. Cette option peut prendre comme valeur un numéro identifiant le modèle de la carte. Les valeurs actuellement supportées sont indiquées dans le fichier CARDLIST.bttv du répertoire /usr/src/linux/Documentation/video4linux/bttv/. Le type de tuner quant à lui doit être spécifié à l'aide de l'option tuner. Cette option prend, elle aussi, une valeur numérique indiquant la nature du tuner utilisé. Les valeurs supportées sont données dans le fichier CARDLIST.tuner. En pratique, il est fort probable que vous utilisiez le type de tuner 3, qui correspond au tuner Philips SECAM, car la France utilise le standard SECAM pour les émissions TV.

Ainsi, si vous disposez d'une carte MIRO PCTV (carte de type 1) basée sur le tuner Philips SECAM, vous devriez avoir les lignes suivantes dans votre fichier modprobe.conf :

 
Sélectionnez
# Nom du module de gestion de Video For Linux :
alias char-major-81 videodev

# Nom du module à utiliser pour le premier périphérique vidéo :
alias char-major-81-0 bttv

# Options du module de gestion du Bt848 :
options bttv card=1 tuner=3

Vous devrez bien entendu adapter ces lignes selon votre propre configuration.

Si vous ne désirez pas utiliser les modules du noyau, vous devrez fournir ces paramètres au gestionnaire de périphérique via la ligne de commande du noyau. Les options à utiliser peuvent alors être déduites des options du module, comme on l'a expliqué dans la Section 8.1.1.3. Pour notre exemple, ces paramètres seraient les suivants :

 
Sélectionnez
bttv.card=1 bttv.tuner=3

Si vous avez compilé les fonctionnalités de l'interface I2C sous forme de module (option de menu « I2C bit-banging interfaces »), vous aurez également à ajouter ces lignes dans votre fichier de configuration modprobe.conf :

 
Sélectionnez
# Nom du module de gestion des fonctionnalités I2C :
alias char-major-89 i2c-dev

# Activation de l'agorithme bit-banging :
options i2c-algo-bit bit_test=1

Pour information, I2C est un protocole de communication entre micro-contrôleurs, que la plupart des cartes mères sont capables de gérer. Cette fonctionnalité n'est nécessaire que pour les cartes basées sur la puce Bt848.

Enfin, si vous utilisez les pilotes OSS pour la gestion du mixer de votre carte d'acquisition vidéo (ce qui est nécessaire pour les cartes vidéo basées sur les puces Bt848, parce qu'ALSA ne fournit pas de pilote pour ces cartes à l'heure actuelle), vous devrez définir les alias nécessaires au chargement des modules de cette carte lors de l'accès aux périphériques audio. Par exemple, pour une carte basée sur la puce Bt848, les alias suivants doivent être ajoutés dans le fichier de configuration modprobe.conf :

 
Sélectionnez
# Charge le pilote de la carte vidéo en tant que deuxième carte son :
alias sound-slot-1 bttv

# Charge le mixer de la carte son de cette carte :
alias sound-service-1-0 tvmixer
Note : Vous pouvez rencontrer quelques problèmes lors de la configuration de votre carte TV. Généralement, si vous n'obtenez aucune image, c'est que vous vous êtes trompé de tuner. Revoyez dans ce cas l'option type du module tuner. Si vous obtenez bien une image, mais pas de son, c'est sans doute que vous vous êtes trompé dans le type de carte, ou que vous avez oublié d'inclure le support du son pour les cartes à base de Bt848. On notera que, comme pour les cartes son, seule la compatibilité matérielle importe. Par exemple, les cartes Studio PCTV de Pinacle vendues en France sont en réalité des cartes Miro PCTV et ne sont pas reconnues comme des cartes Studio PCTV par Linux… Si vous avez des problèmes de son, vous devrez donc revoir la configuration du noyau ou modifier la valeur passée à l'option card du module bttv. Dans tous les cas, n'hésitez pas à utiliser la commande lspci, qui permet de visualiser les informations du bus PCI, et la commande dmesg, qui permet de voir la liste des messages du noyau.

Vous pouvez également avoir quelques problèmes de droits sur les fichiers spéciaux de périphériques /dev/videoX. Le symptôme classique est dans ce cas que tout fonctionne parfaitement sous le compte root, mais pas sous les comptes utilisateurs. Dans ce cas, on pourra résoudre ces problèmes en créant un groupe d'utilisateurs video, auquel appartiendront tous les utilisateurs ayant le droit d'utiliser la carte d'acquisition TV, et de changer le groupe des fichiers spéciaux de périphériques /dev/videoX.

Enfin, l'utilisation des cartes d'acquisition TV nécessite d'activer les fonctionnalités DGA ou Xv du serveur X. Ces fonctionnalités permettent aux programmes d'accéder directement à la mémoire vidéo, et donc de faire l'incrustation de l'image décodée par la carte TV dans la surface d'affichage d'un écran. La manière d'activer les fonctionnalités DGA et Xv sera précisée dans le chapitre traitant de la configuration du serveur X.

8-3-5. Configuration des cartes réseau

Le support des cartes réseau est très complet sous Linux et la prise en charge d'une nouvelle carte revient souvent simplement à ajouter le gestionnaire de périphériques de cette carte dans la configuration du noyau. La plupart des cartes réseau sont des cartes Ethernet compatibles soit avec les cartes NE2000, soit avec les cartes 3COM, aussi suffit-il en général d'activer le gestionnaire de périphériques pour l'une de ces cartes pour qu'elle soit utilisable.

La configuration des gestionnaires de périphériques se fait dans le menu « Networking support » de la configuration du noyau. Il faut activer l'option « Network device support » en premier lieu, puis sélectionner le gestionnaire de périphériques approprié dans le sous-menu « Ethernet (10 or 100Mbit) ». Ce menu présente en premier lieu les gestionnaires de périphériques pour les cartes ISA, et regroupe les gestionnaires de toutes les autres cartes dans les sous-options de l'option « EISA, VLB, PCI and on board controllers ». Vous aurez donc certainement à activer cette option et la sous-option correspondante au gestionnaire de périphériques de votre carte réseau. Vous pouvez activer ces options sous la forme de module du noyau ou non, le plus simple étant ici de ne pas utiliser les modules afin d'avoir à éviter de compléter le fichier de configuration /etc/modprobe.conf.

La compilation du noyau elle-même est décrite en détail dans la Section 7.3 et ne sera donc pas reprise plus en détail ici. Remarquez également que la prise en charge de la carte réseau par un gestionnaire de périphériques ne suffit en aucun cas à l'utilisation de l'ordinateur en réseau. En effet, il faut également configurer l'ensemble des paramètres réseau du système, ce qui sera décrit dans le Chapitre 9. Le nombre des fonctionnalités réseau de Linux interdit de les décrire toutes ici, veuillez vous référer à ce chapitre pour plus de détails.

8-3-6. Configuration des adaptateurs Wifi

Le Wifi (abréviation de l'anglais « Wireless Fidelity » est une technologie permettant de mettre plusieurs ordinateurs en réseau par ondes radio. La plage de fréquences utilisée est située dans la gamme des micro-ondes (2.44 GHz) et est soumise à une réglementation stricte dans de nombreux pays, car elle est en partie réservée aux applications militaires. En pratique, seuls certains canaux sont donc utilisables, et des dérogations peuvent être nécessaires pour une utilisation en extérieur. De plus, cette plage de fréquences est la même que celle utilisée par de nombreux autres appareils sans fil, comme les téléphones portables. Les communications sont donc fortement perturbables par ces appareils, ainsi bien sûr que par les fours à micro-ondes. Enfin, du fait même que ce sont des ondes radio, la confidentialité et la sécurité des communications peuvent être compromises.

Note : Comme pour toute onde proche des 2.4 GHz, l'influence des ondes radio Wifi sur les corps organiques humides n'est pas neutre (la problématique se pose bien entendu également pour les téléphones portables). En effet, les effets sont strictement les mêmes que ceux des ondes des fours à micro-ondes : ces ondes sont à la fréquence propre des molécules d'eau, qui entrent donc en résonnance en leur présence (cette interaction est due à la polarité de la molécule H2O, elle même due à son asymétrie - les atomes d'hydrogène et d'oxygène ne sont pas en ligne - et à la différence d'eléctronégativité entre les atomes d'hydrogène et d'oxygène qui la constituent). Les molécules d'eau restituent ensuite l'énergie de l'onde par diffusion de leur agitation moléculaire dans les molécules avoisinantes, ce qui provoque une augmentation de température. On est donc en droit de se poser la question du danger de l'utilisation de ces ondes pour l'organisme. En général, les puissances émises restent très faibles, et leur influence décroit de manière inversement proporionnelle au carré de la distance à l'émetteur, ce qui fait que le danger est relativement réduit. Toutefois, à titre personnel, et sans prétendre avoir fait la moindre étude sur le sujet, je vous invite à la prudence lors de l'utilisation d'ordinateurs ou de téléphones portables, en raison même de leur proximité (note : je n'ai pas de téléphone portable). Notez également que la chaleur directe dégagée par ces appareils par effet Joule est certainement la plus nocive, de même que leur utilisation prolongée pour l'équilibre mental…

Plusieurs normes de transmission ont été définies pour spécifier les interactions entre les appareils Wifi, ainsi que les technologies de chiffrement utilisées. La norme la plus répandue est la norme 802.11b, qui permet d'atteindre un débit de 11 Mbits/s théorique sur des distances allant jusqu'à 300 mètres en extérieur (quelques dizaines de mètres en intérieur). Toutefois, la plupart des adaptateurs Wifi implémentent également la norme 802.11g à présent. Cette norme permet en effet une compatibilité ascendante avec les équipements 802.11b d'une part (elle utilise la même plage de fréquences), et en constitue une amélioration conséquente puisque le débit théorique est relevé à 54 Mbits/s d'autre part (30 Mbits/s rééls). Notez qu'une autre norme concurrente du 802.11g a été définie, mais, n'étant pas compatible avec les équipements existants, elle n'a pas eu autant de succès. Il s'agit de la norme 802.11a, qui utilise une plage de fréquence à 5 GHz. Les problèmes d'interférences sont donc moindres, mais la portée est également réduite (plus la fréquence d'une onde radio est élevée, plus sa portée est réduite et plus elle est susceptible d'être bloquée par des objets).

Ces normes Wifi définissaient également un mécanisme de sécurité primitif, qui peut être considéré comme absolument inefficace de nos jours (il s'agit du WEP). En particulier, les algorithmes utilisés n'étaient pas fiables du tout et peuvent être cassés simplement par écoute du traffic pendant une période de temps relativement courte. De ce fait, de nouveaux mécanismes de sécurités ont été définis (notamment le WPA et le WPA2). Enfin, la norme 802.11i, encore peu répandue, a pour but d'améliorer la sécurité des communication en utilisant un véritable procédé cryptographique. Cette norme peut être transposée pour les appareils 802.11g et 802.11a.

Comme vous pouvez le constater, le terme Wifi cache bien des choses complexes, et le choix d'une technologie sur une autre peut être assez difficile.

Malgré tous ces inconvénients, la technologie Wifi est très pratique, car elle permet de connecter simplement des machines sans s'emmêler les pattes dans les câbles réseau. La plupart des ordinateurs portables vendus disposent maintenant d'un adaptateur réseau sans fil Wifi, et il est très facile d'en connecter un à un ordinateur de bureau, soit avec une carte fille, soit grâce à un adaptateur USB (il existe même des clefs USB dont l'encombrement est réduit à celui d'une gomme). Il est donc certain que ces technologies sont appelées à se développer et à se généraliser.

Certains matériels Wifi ne sont pas supportés nativement par Linux, soit parce que les constructeurs ne désirent pas fournir les informations permettant aux développeurs de faire un gestionnaire de périphérique libre, soit parce que les constructeurs n'ont eux-mêmes pas le droit de divulguer la technologie utilisée dans leurs appareils ou parce que les réglementation locales sur les émissions radio leur impose de tenir secret les caractéristiques de leurs appareils. Le choix d'un périphérique Wifi doit donc se faire avec précaution. Vous pourrez consulter le site Web de Jean Tourrilhes pour savoir le matériel supporté par les différents pilotes disponibles.

La prise en charge des périphériques Wifi nécessite d'activer le support du Wifi dans le noyau lui-même. Cela peut être fait en activant l'option « Wireless LAN drivers (non-hamradio) & Wireless Extensions » du menu « Network device support » du noyau. Cette option vous donnera également accès aux options de configuration des pilotes de périphériques Wifi (sauf pour certains périphériques USB, qui sont accessibles dans les options de configuration des périphériques USB). Certains pilotes ne sont pas encore intégrés au noyau, et vous devrez peut-être chercher sur Internet le pilote correspondant à votre matériel. Plusieurs projets ont en effet été créés afin de prendre en charge le Wifi sous Linux. Vous trouverez également sur le site de Jean Tourrilhes des liens vers les projets des pilotes pour les autres puces Wifi.

Si aucun pilote Linux n'est disponible pour votre matériel, vous pourrez vous rabattre sur le projet NDISWrapper (http://ndiswrapper.sourceforge.net). Ce projet a pour but de simuler la couche réseau NDIS de Windows XP afin de pouvoir charger les gestionnaires de périphériques pour Windows fournis par les fabricants, et les duper en leur faisant croire qu'ils s'exécutent bien sous Windows. Cette technique reste toutefois une magouille et ne résout bien entendu pas le problème de la disponibilité de pilotes libres.

L'installation des pilotes ne sera pas détaillée plus ici, car la manière de procéder est spécifique à chaque matériel. Dans le cas de NDISWrapper, l'installation se fait simplement en installant NDISWrapper lui-même et en exécutant la commande suivante :

 
Sélectionnez
ndiswrapper -i driver.inf

driver.inf est le fichier .inf du gestionnaire de périphérique pour Windows de votre matériel. Cette commande copie les fichiers nécessaires de ce gestionnaire de périphérique dans le répertoire /etc/ndiswrapper/ et définit la configuration pour l'utilisation de ce périphérique. Une fois cela fait, le chargement du module ndiswrapper suffit pour charger le gestionnaire de périphérique :

 
Sélectionnez
modprobe ndiswrapper

Pour les autres gestionnaires de périphériques, il suffit généralement également de charger le module du noyau du pilote, et éventuellement de charger un firmware.

Lorsque le pilote est chargé, une nouvelle interface réseau « wlanX » apparaît dans le système, où X est le numéro de l'interface réseau sans fil. Cette interface peut ensuite être utilisée comme n'importe quelle interface réseau, à ceci près qu'il faut au préalable configurer les paramètres du réseau sans fil. En particulier, il est nécessaire de spécifier le mode de fonctionnement, le canal à utiliser et l'identifiant du réseau sans fil. Une clef de chiffrement des communications peut également être donnée (cela ne garantit toutefois pas une sécurité absolue, sauf en 802.11i).

Les réseaux Wifi peuvent être établis de plusieurs manières. S'il s'agit de relier deux machines par Wifi, le mode de fonctionnement utilisé le plus simple est le mode « ad hoc ». Dans ce mode, les deux machines peuvent communiquer directement, sans avoir recours à une infrastructure quelconque. Inversement, si plusieurs machines doivent être reliées à un réseau existant (ou simplement entre elles), il est nécessaire d'installer ce qu'on appelle un « point d'accès », qui synchronisera les communications entre toutes ces machines. Dans ce cas, le mode de fonctionnement utilisé est le mode « managé ».

Le canal permet de spécifier la fréquence utilisée par les périphériques sans fil. Bien entendu, toutes les machines devant participer à la communication doivent utiliser le même canal. Le canal est donc un des paramètres essentiel du réseau. Il existe plusieurs canaux, mais en pratique, seuls quelques-uns peuvent être utilisés librement en France. Il s'agit des canaux 10 (2457 MHz), 11 (2462 MHz), 12 (2467 MHz) et 13 (2472 MHz).

Comme on peut être amené à créer plusieurs réseaux Wifi utilisant un même canal, il est nécessaire de pouvoir les distinguer afin d'éviter de mélanger les transmissions. Deux possibilités s'offrent alors à l'utilisateur : soit on utilise ce qu'on appelle un numéro de réseau virtuel (« Network ID »), soit on utilise un nom de réseau. La première solution ne permet de définir qu'une cellule du réseau, alors que la deuxième permet de regrouper plusieurs de ces cellules et autorise un utilisateur à passer d'une de ces cellules à l'autre (une cellule est une zone géographique prise en charge par un point d'accès).

Tous ces paramètres peuvent être spécifiés avec la commande iwconfig, sauf pour certains pilotes de périphériques non standards qui nécessitent des commandes spécifiques. La syntaxe générale de cette commande est la suivante :

 
Sélectionnez
iwconfig interface options

interface est le nom de l'interface réseau sans fil (par exemple wlan0), et options est la liste des options permettant de définir les paramètres du réseau sans fil. Les principales options sont récapitulées dans le tableau suivant :

Option Signification
channel Numéro du canal.
mode Mode de fonctionnement.
essid Nom de réseau.
nwid Numéro de réseau.
key Clef de chiffrement WEP du réseau.

Les modes de fonctionnement les plus courants sont le mode « ad hoc » pour le mode ad hoc, et le mode « managed » pour l'utilisation d'un point d'accès. La page de manuel de iwconfig vous donnera la liste des autres modes utilisables.

Par exemple, pour configurer une interface sans fil sur le canal 11, en mode managé et avec un nom de réseau "MonWLAN", il faudra utiliser la commande suivante :

 
Sélectionnez
iwconfig wlan0 mode managed essid MonWLAN channel 11

À la suite de cette commande, l'interface wlan0 sera utilisable comme n'importe quelle interface réseau.

Si vous désirez définir une clef de chiffrement pour votre réseau sans fil, vous devrez utiliser l'option key. L'utilisation du chiffrement peut être facultative en Wifi, sauf si l'interface est configurée pour n'accepter que les communications chiffrées. L'option key peut donc accepter, en plus de la clef de chiffrement (dont la taille est de 64 ou 104 bits, soit 8 ou 13 octets), un paramètre indiquant si le chiffrement est obligatoire ou non. Ce paramètre peut prendre la valeur open si le chiffrement est facultatif, restricted s'il est obligatoire, ou tout simplement off si le chiffrement doit être désactivé.

Par exemple, pour imposer l'utilisation d'une clef de chiffrement sur l'interface wlan0, la commande suivante devra être utilisée :

 
Sélectionnez
iwconfig wlan0 key restricted 74151B6DCD98D808

Comme vous pouvez le constater, la clef est fournie en hexadécimal (c'est-à-dire en base 16, les chiffres au dessus de 9 étant représentés par les lettres A à F). Pour sortir du mode chiffré, la commande suivante pourra être utilisée :

 
Sélectionnez
iwconfig wlan0 key off

Sachez toutefois que le chiffrement WEP n'est pas fiable du tout, et qu'il ne faut pas se reposer dessus. Le chiffrement WPA, bien que n'étant pas encore supporté par tous les adaptateurs et tous les pilotes, est donc à privilégier. Outre l'utilisation d'algorithmes de chiffrement plus évolués, le chiffrement WPA permet de renégocier régulièrement les clefs de chiffrement utilisées par les interlocuteurs.

Sous Linux, cette négociation périodique est à la charge du démon wpa_supplicant. Ce démon prend en charge tous les aspects de la liaison Wifi, et rend par conséquent obsolète l'utilisation de la commande iwconfig pour la configuration du réseau sans fil. En effet, cette configuration doit se faire dans le fichier de configuration /etc/wpa_supplicant.conf, dont vous trouverez un exemple ci-dessous :

 
Sélectionnez
ctrl_interface=/var/run/wpa_supplicant
network={
    ssid="MonRezo"
    key_mgmt=WPA-PSK
    psk=1cc5a2db98bfd1387de265397772b9ea36e4d049e17fd1d660c014576d5e71a4
    proto=WPA
}

L'option ctrl_interface permet de spécifier un répertoire dans lequel wpa_supplicant placera des fichiers servant de canaux de communication avec des programes complémentaires permettant de le contrôler et d'obtenir des informations sur l'état de la liaison Wifi. La définition des paramètres des réseaux sans fil se fait ensuite dans une section network, comme vous pouvez le constater.

Le nom du réseau est obligatoire. Il doit être défini avec l'option ssid. Le protocole de gestion de clef utilisé peut ensuite être spécifié avec l'option key_mgmt. Dans cet exemple, il a été choisi d'utiliser une clef secrète partagée (« PSK », abréviation de « Private Shared Key ») par toutes les machines connectées au réseau sans fil. Cette configuration est très classique, et convient en particulier pour tous les modems routeurs sans fil que l'on peut trouver dans le commerce.

La clef elle-même doit être spécifiée avec l'option psk. Cette option peut prendre une chaîne de caractères ASCII entre guillemets (exactement comme on a donné le nom du réseau à l'option ssid), ou une valeur hexadécimale. La commande wpa_password permettra de créer une telle valeur à partir d'une chaîne de caractère et du nom du réseau.

Enfin, l'option proto permet d'indiquer le protocole de chiffrement utilisé. Dans le cas présent, nous avons utilisé le protocole WPA, qui renégocie les clefs régulièrement. Le protocole WPA2, intrinsèquement plus sûr, aurait pu être utilisé, mais n'a pas été choisi parce que les points d'accès les plus anciens ne savent pas gérer ce protocole.

Note : Il est possible de définir plusieurs réseaux sans fil dans le fichier de configuration, dans ce cas, wpa_supplicant utilisera le premier réseau défini dans le fichier, en privilégiant les réseaux utilisant les protocoles de chiffrement les plus sûrs.

Cet exemple de fichier de configuration ne présente que le cas d'un réseau sans fil classique, dont les différentes machines partagent une même clef secrète de chiffrement. Sachez toutefois que wpa_supplicatn sait gérer des configurations plus complètes, dans lesquels des mécanismes de chiffrement plus évolués et des serveurs d'authentification peuvent être utilisés par exemple. Ces configurations ne seront pas abordées ici.

Une fois le fichier de configuration des réseaux sans fil mis en place, il ne reste plus qu'à lancer le démon wpa_supplicant. Typiquement, la commande à utiliser est la suivante :

 
Sélectionnez
wpa_supplicant -Bw -c/etc/wpa_supplicant.conf -Dwext -iwlan0

Les options B et w permettent respectivement de faire passer le processus ainsi lancé en arrière plan, et de lui demander d'attendre que l'interface réseau à utiliser soit créée, si elle ne l'est pas encore lors de son lancement. Le nom de cette interface est spécifié avec l'option i, et l'interface de programmation à utilisée est spécifiée avec l'option D. Dans le cas présent, l'interface de programmation utilisée est l'interface des extensions sans fil classique de Linux (« wext », abréviation de « Wireless Extentions »). Enfin, l'option c permet de spécifier le fichier de configuration à utiliser. Il s'agit ici du fichier que l'on vient de décrire dans les paragraphes précédents.

Sachez enfin que la liste des réseaux sans fils disponibles peut être récupérée avec l'option scan de la commande iwlist. Par exemple, la commande suivante vous affichera tous les réseaux sans fils disponibles via l'interface réseau wlan0, ainsi que leurs caractéristiques :

 
Sélectionnez
iwlist wlan0 scan

La commande iwlist accepte d'autres options, dont vous trouverez la liste et la description dans sa page de manuel.

Pour finir, la commande iwconfig, utilisée sans option, affiche la configuration des interfaces sans fil du système. En particulier, vous y trouverez le mode de fonctionnement, le numéro de canal et les identifiants du réseau, éventuellement la clef de chiffrement utilisée, ainsi que la qualité du signal radio. La page de manuel de iwconfig vous donnera de plus amples informations sur la manière dont ces informations peuvent être interprétées.

8-4. Configuration des ports de communication

Les ports de communication sont les seuls moyens de communication de l'ordinateur avec d'autres appareils, et sont donc essentiels au même titre que les réseaux.

Historiquement, le plus vieux type de port de communication utilisé est sans doute le port série, qui permet de connecter une multitude de périphériques en raison de sa grande simplicité. Les ports parallèles sont également courants, et sont encore souvent utilisés pour connecter les imprimantes. Cependant, ces ports souffrent de défauts indéniables, dont l'un des principaux est sans doute le faible débit de données qu'ils autorisent. Ils ne peuvent donc pas être utilisés pour les applications les plus exigeantes. C'est pour cela que les ports USB (abréviation de l'anglais « Universal Serial Bus ») et IEEE1394 (alias « FireWire ») ont été inventés.

Cette section présente la manière de configurer les différents ports de communication actuellement utilisés, à savoir le port parallèle, les ports série standards, et enfin les ports USB et IEEE1394.

8-4-1. Prise en charge des périphériques ISA standards

La plupart des PC disposent encore de périphériques d'entrée/sortie standards ISA intégrés aux cartes mères, comme les ports série et les ports parallèles, même s'ils ne permettent plus de brancher des cartes filles ISA. Il est donc encore nécessaire de prendre en charge ces fonctionnalités au niveau du noyau, même si vous ne disposez d'aucun périphérique ISA.

Pour cela, il suffit d'activer les options « Plug and Play support » et « Plug and Play BIOS support » du menu « Plug and Play support » de la configuration du noyau. Ces options permettent de prendre en charge les ressources Plug and Play des cartes mères, et donc de réaliser la configuration automatique des ports parallèles et série de l'ordinateur.

8-4-1-1. Configuration du port parallèle

La configuration du port parallèle sous Linux est relativement automatique. Il suffit en effet, dans le programme de configuration du noyau, d'activer les options « Parallel port support », « PC-style hardware », « Use FIFO/DMA if available » et « IEEE 1284 transfer modes » du menu « Parallel port support ». Si vous désirez connecter une imprimante sur votre port parallèle, ce qui est généralement le cas, il vous faudra également activer l'option « Parallel printer support » du menu « Character devices ». De même, si vous désirez connecter un disque dur, un lecteur de CD-ROM ou un lecteur de bande sur votre port parallèle, vous devrez activer l'option « Parallel port IDE device support » du menu « Block devices », ainsi qu'au moins une des sous-options pour le type de périphérique à utiliser et un des modules de prise en charge des protocole de communication sur port parallèle.

Pour des raisons de compatibilité, le gestionnaire de ports parallèles utilise par défaut une interrogation périodique pour déterminer l'état des ports. Cela consomme généralement des ressources de calcul, mais c'est une technique fiable. Toutefois, si votre matériel le permet, il est possible de le configurer pour utiliser une interruption matérielle, et soulager ainsi le processeur de cette tâche. Nous allons donc voir comment configurer le port parallèle ci-dessous.

Afin d'utiliser une interruption matérielle pour le port parallèle, il est nécessaire de spécifier explicitement la ligne de cette interruption. Cela peut se faire avec l'option irq du module prenant en charge le port parallèle. Sur les ordinateurs de type PC, le nom de ce module est « parport_pc », mais, comme on l'a vu dans la Section 8.1.1, le noyau demande toujours le chargement du module « parport_lowlevel » pour des raisons de portabilité. Il faut donc définir un alias dans le fichier de configuration /etc/modprobe.conf.

Outre la ligne d'interruption à utiliser, le module parport_pc peut prendre en paramètre une autre option permettant d'indiquer le port d'entrée / sortie qu'il doit utiliser pour accéder au port parallèle. Cette option est l'option io. En général, le port utilisé est le port numéro 378h et la ligne d'interruption est souvent la 7. Les options suivantes doivent donc être définies dans le ficher modprobe.conf pour obtenir un fonctionnement optimal du port parallèle sous Linux :

 
Sélectionnez
alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=7

D'autre options pourront être définies dans le fichier de configuration modprobe.conf pour prendre en charge les périphériques de type bloc connectés sur port parallèle. Cela est inutile pour les imprimantes connectées sur le port parallèle.

Si l'on désire intégrer le gestionnaire de périphérique du port parallèle dans le noyau et faire en sorte qu'il utilise les paramètres détectés automatiquement pour ce port, la solution la plus simple est de fournir l'option parport du noyau et de lui affecter la valeur auto :

 
Sélectionnez
parport=auto

Cela activera automatiquement l'utilisation de la ligne d'interruption du port parallèle. Les autres paramètres du port parallèle peuvent être trouvés dans le fichier kernel-parameters.txt de la documentation du noyau.

8-4-1-2. Configuration des ports série

Les ports série fournis en standard sur les cartes mères sont détectés et configurés automatiquement par le noyau lorsque l'ordinateur démarre. Pour que cela fonctionne, il suffit que l'option « Standard/generic (8250/16550 and compatible UARTs) serial support » du menu « Character devices » soit activée.

Cela dit, il se peut que votre ordinateur contienne un port série non standard, ou que vous ayez à sélectionner des options spécifiques pour votre matériel. Il vous faudra, dans ce cas, activer les options complémentaires relatives aux ports série dans le menu « Character devices ».

Le noyau n'est, en général, capable d'initialiser que les ports série standards intégrés dans les cartes mères (c'est-à-dire les ports COM1 à COM4), auxquels on accède, sous Linux, par l'intermédiaire des fichiers spéciaux de périphériques /dev/ttyS0 à /dev/ttyS3. Pour les autres ports série, il peut être nécessaire de les initialiser manuellement, par exemple dans un fichier de configuration lancé au démarrage du système.

Cette initialisation se fait à l'aide de la commande setserial, dont la syntaxe simplifiée est la suivante :

 
Sélectionnez
setserial fichier [uart type] [port adresse] [irq ligne]

fichier est le fichier spécial de périphérique permettant d'accéder au port série à initialiser, type est le type de port série utilisé, adresse est son adresse d'entrée / sortie et ligne est la ligne d'interruption qu'il utilise. La commande setserial dispose de nombreuses autres options. Je vous invite à en lire la page de manuel pour les découvrir.

Une fois le port série correctement initialisé, il est possible de fixer les paramètres de la ligne de communication avec la commande stty. Comme on l'a déjà vu précédemment, cette commande permet de fixer tous les paramètres des lignes de communication des terminaux et non seulement les paramètres des lignes série, et elle dispose donc d'un grand nombre d'options. Nous n'allons nous intéresser ici qu'aux options utilisés pour les lignes série. La page de manuel de stty pourra être consultée pour plus de détails.

La syntaxe à utiliser pour lire les paramètres de communication d'une ligne série est la suivante :

 
Sélectionnez
stty -a -F périphérique

périphérique est le fichier spécial de périphérique de la ligne. Si vous exécutez cette commande, vous constaterez qu'un grand nombre d'information est donné. Les informations les plus utiles sont sans doute speed, qui donne la vitesse de la ligne série, csN, qui donne le nombre N de bits de données par caractère, [-]parenb, qui indique si un bit de parité est utilisé ou non (auquel cas le caractère '-' est présent), [-]parodd, qui indique le type de parité utilisée (paire ou impaire selon la présence ou l'absence du caractère '-'), et [-]cstopb, qui indique le nombre de bits de stop utilisés (un ou deux selon la présence ou l'absence du caractère '-'). L'option [-]crtscts indique si le contrôle de flux matériel est utilisé ou non. À titre d'exemple, voici une sortie typique de la commande stty sur le premier port série :

 
Sélectionnez
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <indéfini>;
eol2 = <indéfini>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl
onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

Les mêmes options peuvent être utilsées pour fixer les paramètres de la ligne de communication. La ligne de commande à utiliser est alors la suivante :

 
Sélectionnez
stty -F périphérique options

Il existe une différence cependant : le paramètre permettant de fixer la vitesse de la ligne est décomposé en deux options ispeed pour le flux de données entrant et ospeed pour le flux de données sortant. On peut fixer la vitesse de la ligne avec l'option ispeed. Par exemple, pour faire passer la ligne de communication du deuxième port série à 115200 bauds, 7 bits de données, un bit de stop et une parité paire, il faut utiliser la ligne de commande suivante :

 
Sélectionnez
stty -F /dev/ttyS1 ispeed 115200 cs7 -cstopb parenb -parodd

Il est important de bien configurer les ports série avec les mêmes paramètres de ligne que ceux utilisés par les périphériques qui y sont connectés pour que la communication se fasse correctement.

8-4-2. Installation des périphériques USB

Bien qu'ayant eu quelques difficultés à ses débuts, le port USB est désormais en pleine expansion. Il s'agit d'une extension des ports série classiques, qui offre les avantages suivants :

  • possibilité de connecter jusqu'à 127 périphériques sur un même port, selon une structure arborescente ;
  • bande passante accrue jusqu'à 12 Mbits/s théoriques pour l'USB 1.1, et de 480 Mbits/s pour l'USB 2.0 ;
  • capacité de connexion des périphériques « à chaud » et détection automatique par le système d'exploitation ;
  • possibilité d'alimentation des périphériques par le bus lui-même, évitant ainsi d'avoir des câbles supplémentaires pour les périphériques consommant peu d'électricité.

Tous ces avantages font que le bus USB est appelé à remplacer les ports série que l'on connaît, et que l'on n'utilise plus désormais que pour les modems, les vieilles souris série et quelques appareils extérieurs. Notez que la simplicité du port série fera qu'il restera encore présents sur bon nombre d'appareils pour plusieurs années encore, mais les périphériques informatiques risquent de s'en détourner de plus en plus.

La gestion de l'USB sous Linux se base profondément sur les mécanismes de détection dynamique des périphériques connectables à chaud. Les gestionnaires de périphériques sont donc généralement des modules du noyau chargés automatiquement lorsque ces périphériques sont détectés. Il est toutefois également possible d'intégrér ces gestionnaires au sein du noyau, et de laisser les opérations de configuration des périphériques (chargement du firmware, création des fichiers spéciaux de périphériques par udev et configuration du matériel) se faire via les mécanismes de gestion des périphériques amovibles. Linux est capable d'utiliser la plupart des périphériques USB existant actuellement sur le marché.

Au niveau du noyau, la configuration des périphériques USB se fait dans le menu « USB support ». Il faut simplement activer l'option « Support for USB », sélectionner un gestionnaire pour le port USB et choisir les gestionnaires des différents types de périphériques que l'on voudra connecter sur la machine.

Il est impératif d'activer l'option « USB device filesystem » afin de permettres à certains outils d'accéder, via le répertoire /proc/bus/usb/ du système de fichiers virtuel /proc/, aux périphériques USB connectés à l'ordinateur. Ce système de fichiers doit être monté à l'aide de la commande suivante :

 
Sélectionnez
mount -t usbfs none /proc/bus/usb

pour pouvoir être utilisé. Il est également possible de le monter automatiquement dans le fichier /dev/fstab.

En fait, il existe trois types d'interfaces USB sur le marché : les interfaces EHCI (abréviation ed l'anglais « Enhanced Host Controler Interface »), qui prennent en charge l'USB 2.0, les interfaces UHCI (abréviation de l'anglais « Universal Host Controller Interface »), spécifiées par Intel et que les contrôleurs de la plupart des cartes mères utilisent (chipsets Intel et VIA), et les interfaces OHCI (« Open Host Controller Interface »), spécifiées par Compaq, et qui sont utilisées par les chipsets Compaq et ALi principalement. Les ports USB 2.0 comprennent également un port USB 1.1 UHCI ou OHCI, qui permet donc de connecter les anciens périphériques USB. La configuration de l'USB se restreint donc simplement à la sélection des pilotes nécessaires pour votre matériel (option « EHCI HCD (USB 2.0) support » si vous disposez d'un port USB 2.0, et le pilote UHCI « UHCI HCD (most Intel and VIA) support » ou le pilote OHCI « OHCI HCD support »). Notez que le pilote EHCI ne gère que la partie USB 2.0 de votre contrôleur USB, et que vous devez également inclure le support UHCI ou OHCI pour pouvoir utiliser les périphériques USB 1.1.

Comme vous pouvez le constater dans le menu de configuration du noyau, un grand nombre de périphériques USB sont gérés par Linux. Vous devez bien entendu activer les options permettant de prendre en charge votre matériel. Il est conseillé d'inclure ces fonctionnalités sous forme de modules afin de permettre le chargement dynamique des gestionnaires de périphériques. Cela est nécessaire pour la configuration des périphériques connectés à chaud dans le système. Les options les plus importantes sont sans doute « USB Audio support », pour la prise en charge des périphériques USB audio, « USB Printer support », pour toutes les imprimantes USB et « USB Mass Storage support », pour la prise en charge des clefs USB et de la majorité des appareils photos numériques. Les scanners USB sont pris en charge automatiquement par les logiciels et ne requièrent pas de configuration particulière au niveau du noyau.

Les périphériques d'entrée tels que le clavier et la souris devront, si possible, être inclus directement au sein du noyau afin d'éviter de se retrouver sans clavier et sans souris au démarrage, en cas de problème dans la configuration du système. Notez qu'il existe deux types de pilotes pour les périphériques d'entrée : un pilote général (option « USB Human Interface Device (full HID) support ), qui fonctionne avec tous les périphériques d'entrée du menu « Input core support », et des pilotes simplifiés (options du sous-menu « USB HID Boot Protocol drivers »), que l'on utilisera pour réaliser des systèmes embarqués ou des noyaux légers. Il est évidemment recommandé d'utiliser le premier pilote, si réellement le support du clavier USB est nécessaire (normalement, les claviers USB sont pris en charge par le BIOS de l'ordinateur et apparaissent exactement comme des claviers classiques pour le système d'exploitation).

Il est fortement recommandé, si l'on désire utiliser des périphériques USB, d'activer les fonctionnalités de chargement dynamique des modules, de gestion des périphériques connectables à chaud et de chargement des firmware automatique de Linux.

8-4-3. Installation des périphériques IEEE1394

Le bus IEEE1394 (initialement dénommé bus FireWire) est un bus série à grande vitesse, capable de transférer des données avec un très grand débit (400 mégabits par secondes). Ce bus peut être utilisé pour connecter de nombreux périphériques (disques dur et lecteurs de CDROM externes par exemple), mais sa principale utilisation reste pour les transferts de données vidéo provenant des caméscopes numériques. Certaines cartes mères disposent d'un port IEEE1394 intégré, mais la plupart nécessitent l'ajout d'une carte fille PCI. La plupart de ces cartes sont vendues en tant que cartes de montage vidéo et disposent de deux ports IEEE1394 afin de permettre une entrée et une sortie du flux vidéo.

Le bus IEEE1394 dispose d'avantages indéniables, puisqu'il permet de brancher et de débrancher un périphérique à chaud (c'est-à-dire sans redémarrer l'ordinateur), les données sont transférées en numérique (donc sans perte de qualité pour les séquences vidéo), et de piloter les appareils qui y sont connectés (ce qui permet de contrôler par exemple un caméscope à partir d'un logiciel de montage vidéo). Il est également possible d'utiliser le bus IEEE1394 pour connecter deux ordinateurs en réseau, bien que cette fonctionnalité soit encore expérimentale.

Linux dispose des pilotes permettant d'utiliser les ports IEEE1394 de manière générique. Cependant, il faut bien le reconnaître, les logiciels spécifiques aux différents types d'appareils sont encore très rares ou incomplets. Cet état de fait est particulièrement vrai en ce qui concerne les caméscopes numériques, pour lesquels il n'existe quasiment aucun logiciel de montage vidéo dont la qualité s'approche de celle de ceux qui ont été développés pour Windows. Cela dit, les autres périphériques tels que les disques durs et les lecteurs de CD-ROM externes sont mieux supportés, et la configuration du port IEEE1394 peut être réalisée complètement en attendant que des logiciels plus évolués ne voient le jour. Vous pouvez obtenir les dernières informations concernant le support des périphériques FireWire sous Linux sur le site de linux1394.

8-4-3-1. Configuration du noyau

La prise en charge du bus IEEE1394 au niveau du noyau est réalisable par l'intermédiaire des options du menu « IEEE 1394 (FireWire) support (EXPERIMENTAL) ». Comme le support des périphériques IEEE1394 sous Linux en est encore à ses balbutiements, ce menu ne peut être accédé que si l'on a activé l'option « Prompt for development and/or incomplete code/drivers » du menu « Code maturity level options ». Les principales options utilisables sont les suivantes :

  • l'option « IEEE 1394 (FireWire) support (EXPERIMENTAL) », qui est l'option principale qui active toutes les autres options. Il faut donc impérativement activer cette option et répondre 'Y' ;
  • l'option « Texas Instruments PCILynx support », qui permet de prendre en charge les cartes IEEE1394 basées sur la puce PCILynx de Texas Instrument. Ce ne sont pas les cartes les plus couramment utilisées, aussi la réponse recommandée est-elle 'N'. Si vous activez cette option, vous pourrez configurer des paramètres complémentaires du gestionnaire de périphériques avec les options « Use PCILynx local RAM » (utilisation de la mémoire embarquée sur la carte PCI) et « Support for non-IEEE1394 local ports » (utilisation de fonctionnalités complémentaires non FireWire de ces cartes) ;
  • l'option « OHCI-1394 support », qui active la prise en charge des périphériques IEEE1394 compatible OHCI (abréviation de l'anglais « Open Host Controller Interface ), qui sont les périphériques les plus courants à présent. La réponse recommandée est 'Y' ;
  • l'option « OHCI-1394 Video support », qui permet de prendre en charge les caméras vidéo numériques. Cette option ajoute également une fonctionnalité intéressante qui permet aux programmes de partager les données avec le gestionnaire de périphériques directement. Cela permet d'éviter qu'une copie de ces données ne soit réalisée entre la mémoire du noyau et la mémoire de l'application et d'obtenir ainsi de meilleures performances. La réponse recommandée est bien évidemment 'Y'. Cette option n'est toutefois disponible que pour les périphériques OHCI ;
  • l'option « SBP-2 support (Harddisks, etc.) », qui permet de prendre en charge les disques durs et les lecteurs de DVD connectés sur bus IEEE1394. Ces lecteurs apparaissent alors comme des périphériques SCSI standards et pourront être montés via l'un des périphériques /dev/sdx ;
  • l'option « Raw IEEE1394 I/O support », qui permet aux applications de communiquer directement avec le bus IEEE1394 par l'intermédiaire d'un fichier spécial de périphérique. Cette option est nécessaire au bon fonctionnement de la plupart des applications IEEE1394 et la réponse recommandée est donc 'Y' ;
  • l'option « Excessive debugging output », qui active l'émission de messages de traces pour toutes les données survenant sur le bus IEEE1394. Cette option saturera vos fichiers de traces très vite et n'est réellement utile que pour les développeurs, aussi faut-il répondre 'N'.

Comme pour tous les périphériques sous Linux, les fonctionnalités IEEE1394 du noyau seront accessibles par l'intermédiaire de fichiers spéciaux de périphériques situés dans le répertoire /dev/. Les fonctionnalités vidéo seront accédées par l'intermédiaire d'un fichier spécial de périphérique de type caractère et de code majeur 172. De même, l'interface de données brute activée par l'option « Raw IEEE1394 I/O support » est exposée par l'intermédiaire d'un fichier spécial de périphérique de type caractère et de code majeur 171. Vous devrez donc créer ces fichiers spéciaux à l'aide des deux commandes suivantes :

 
Sélectionnez
mknod /dev/raw1394 c 171 0
mknod -m 666 /dev/video1394 c 172 0

Le numéro de code mineur est utilisé pour distinguer les différents ports IEEE1394 présents dans la machine. Les lignes de commandes précédentes ne montrent que la manière de créer les fichiers spéciaux de périphériques que pour le premier port IEEE1394.

8-4-3-2. Installation des bibliothèques complémentaires

Les fonctionnalités IEEE1394 peuvent être utilisées par les applications directement par l'intermédiaire des fichiers spéciaux de périphériques /dev/raw1394 et /dev/video1394, mais quasiment aucune ne le fait. En effet, des bibliothèques spécifiques ont été écrites afin de fixer les interfaces de programmation de Linux avec ces applications. Il est donc nécessaire d'installer ces bibliothèques pour pouvoir utiliser les périphériques IEEE1394.

Il est encore rare que ces bibliothèques soient installées par les distributions, certainement parce qu'elles sont encore en cours de développement. Leur installation nécessite donc de les compiler soi-même, ce qui est une tâche facile si on sait le faire, mais qui peut effrayer un débutant. Rappelons une fois de plus que le support des périphériques IEEE1394 sous Linux est encore expérimental.

La bibliothèque de programme la plus importante est celle qui permet d'utiliser la fonctionnalité d'accès direct aux périphériques IEEE1394 par l'intermédiaire du fichier spécial de périphérique /dev/raw1394. Les fichiers sources de cette bibliothèque peuvent être trouvées sur le site du projet libraw1394. Une autre bibliothèque utilisée par les programmes vidéo est la bibliothèque libavc1394. Cette bibliothèque permet en effet aux programmes de piloter les caméscopes numériques par l'intermédiaire du bus IEEE1394. Enfin, les programmes d'édition vidéo peuvent avoir besoin de la bibliothèque libdv, qui permet de manipuler les données au format DV (c'est-à-dire le format de données utilisé par la plupart des caméscopes numériques). Cette bibliothèque ne fait pas à proprement parler partie des bibliothèques permettant de communiquer avec les périphériques IEEE1394, mais elle est extrêmement utile.

La compilation de ces bibliothèques se fait classiquement avec les commandes suivantes :

 
Sélectionnez
./configure --prefix=/usr
make

à partir du répertoire des sources. Celui-ci pourra être extrait des archives à l'aide de la commande tar xzf archive, où archive est le nom de l'archive en question. Une fois compilées, les bibliothèques pourront être installées avec la commande :

 
Sélectionnez
make install

Ces opérations ne devraient pas poser de problème particulier. Consultez le Chapitre 7 pour plus de détails sur ces opérations.

Une fois ces bibliothèques installées, vous devriez pouvoir installer et utiliser des applications dédiées aux périphériques IEEE1394, comme dvgrab (outil de capture vidéo), kino ou broadcast2000 (outils d'édition de séquences vidéo). Force est de reconnaître que ces programmes sont très loins d'être finis et réellement difficiles à utiliser.


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2004-2013 Christian Casteyde. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.