9. Gestionnaires de périphériques demandant une configuration particulière

Contenu de cette section

Certains gestionnaires de périphériques demandent un peu plus de configuration dépassant le simple alias d'un périphérique et d'un module :

9.1 char-major-10 : Souris, watchdogs et random

Les gestionnaires de périphériques sont généralement identifiés par leur nombrer majeur, par exemple pour ftape, il s'agit du numéro 27, en mode caractères. Toutefois, si vous consultez les entrées du répertoire /dev pour le nombre majeur 10 en mode caractère, vous verrez qu'il y a un certain nombre de périphériques très différents, dont :

D'une manière évidente, chacun de ces périphériques est contrôlé par différents modules. Donc, kerneld utilise alors le nombre majeur et le nombre mineur pour utiliser ces modules :

        alias char-major-10-1 psaux     # Pour la souris PS/2 
        alias char-major-10-130 wdt     # WatchDog WDT 

Vous avez besoin d'une version du noyau 1.3.82 ou supérieur pour l'utiliser. Les versions précédentes ne passaient pas le nombre mineur à kerneld, ce qui ne lui permettait donc pas de savoir quel module il devait charger.

9.2 Charger des gestionnaires SCSI: l'entrée scsi_hostadapter

Les gestionnaires pour les périphériques SCSI sont consitués d'un adaptateur pour la carte SCSI (par exemple pour une Adaptec 1542), et d'un gestionnaire pour le type de périphériques SCSI que vous utilisez, comme un disque dur, un lecteur de CD-ROM ou un lecteur de cartouches. Tous peuvent être chargés sous la forme de modules. Toutefois, lorsque vous voulez accéder au lecteur de CD-ROM connecté à la carte Adaptec, alors le noyau et kerneld savent uniquement qu'il est nécessaire de charger le module sr_mod pour gérer le CD-ROM SCSI : il ne sait pas à quel contrôleur le CD-ROM est connecté. Par conséquent, il ne sait pas charger le module de la carte SCSI.

Pour résoudre le problème, vous pouvez ajouter une entrée pour le module du contrôleur SCSI dans votre fichier /etc/conf.modules qui indique à kerneld quel module contrôleur SCSI il doit charger :

        alias scd0 sr_mod               # sr_mod pour SCSI CD-ROM's ...
        alias scsi_hostadapter aha1542  # ... doit utiliser le gestionnaire
                                        # de peripherique Adaptec 1542

Cela ne fonctionne qu'avec une version du noyau 1.3.82 ou supérieur.

Si vous possédez plus d'une carte SCSI, vous n'avez pour le moment pas de chance : il n'existe aucun moyen d'indiquer à kerneld que le lecteur de CD-ROM a besoin du gestionnaire Adaptec, et que le lecteur de cartouches a besoin du gestionnaire BusLogic.

9.3 Charger un module est parfois insuffisant : l'entrée post-install

Parfois, charger un module n'est pas suffisant pour faire le fonctionner correctement. Par exemple, si vous avez compilé votre carte son sous la forme d'un module, il est souvent pratique de fixer un certain volume sonore. Le seul problème, c'est que cette initialisation disparaît lors du prochain chargement du module. Voici un truc pour résoudre le problème, réalisé par Ben Galliart (bgallia@luc.edu) :

Cela demande à installer le paquetage setmix-0.1 (ftp://sunsite.unc.edu/pub/Linux/apps/sound/mixers/setmix-0.1.tar.gz)

Et ensuite à ajouter les lignes suivantes dans le fichier /etc/conf.modules :

post-install sound /usr/local/bin/setmix -f /etc/volume.conf

Une fois que le module est chargé, kerneld exécute la commande spécifiée après l'entrée post-install sound. De cette manière, le module sonore est configuré avec la commande /usr/local/bin/setmix -f /etc/volume.conf.

Cela peut être très utile également pour d'autre modules, par exemple, le module lp peut être configuré en utilisant le programme tunelp en ajoutant :

        post-install lp tunelp <options>

Pour que kerneld reconnaisse ces options, vous devez posséder une version 1.3.69f ou supérieur.

Note : une version précédente de ce mini-Howto définie une option pre-remove qui peut éventuellement être utilisée pour exécuter une commande juste avant que kerneld décharge un module. Toutefois, cela n'a jamais fonctionné et son utilisation est déconseillé. Heureusement, cette option devrait disparaître dans les prochaines versions. L'ensemble des opérations d'initialisation des modules est en cours de modification en ce moment, et peut être légèrement différent sur votre système au moment où vous lisez ces lignes.

9.4 Espionner kerneld

Si vous avez tout essayé, et que vous ne comprenez pas ce que le noyau demande à kerneld, il existe une manière de voir les requêtes que kerneld reçoit, et ainsi de comprendre ce qu'il faut mettre dans le fichier /etc/conf.modules. Pour cela, il faut utiliser le programme kdstat.

Ce petit programme est livré avec le paquetage modules-1.3.57 (et plus récent) mais il n'est pas compilé et installé par défaut. Pour le compiler :

  cd /usr/src/modules-1.3.57/kerneld
  make kdstat

Ensuite, pour faire en sorte que kerneld affiche les informations sur ce qu'il est en train de faire, lancez :

  kdstat debug

et kerneld commencera à envoyer des messages sur la console sur son activité. Si vous essayez ensuite la commande activant un module, vous verrez les requêtes kerneld. Elles peuvent être insérées dans /etc/conf.modules et mises en alias pour le module qui en a besoin.

Pour désactiver le débogage, lancez /sbin/kdstat nodebug.


Chapitre suivant, Chapitre Précédent

Table des matières de ce chapitre, Table des matières générale

Début du document, Début de ce chapitre