Page suivante - Page précédente - Table des matières

8. Comment kerneld sait-il quel module charger ?

Bien que kerneld connaisse déjà les types les plus communs de modules, il y a des situations dans lesquelles kerneld ne sera pas comment satisfaire une requête venant du noyau. C'est le cas avec les pilotes de CD-ROM ou de cartes réseau, où il existe plus d'un module possible susceptible d'être chargé.

Les requêtes que le démon de kerneld reçoit du noyau viennent d'un des éléments suivants :

  • un pilote de périphérique bloc ;
  • un pilote de périphérique caractère ;
  • un format binaire ;
  • une discipline de ligne tty ;
  • un système de fichier ;
  • un périphérique réseau ;
  • un service réseau (par exemple rarp) ;
  • un protocole réseau (par exemple IPX).

kerneld détermine quel module doit être chargé regardant le fichier de configuration /etc/conf.modules. Il y a deux types d'entrée dans ce fichier : les chemins (où les fichiers des modules sont stockés) et les alias (quel module doit être chargé). Si vous n'avez pas déjà ce fichier, vous devrez le créer en lançant /sbin/modprobe -c | grep -v '^path'> /etc/conf.modules

Si vous voulez ajouter encore une autre directive ``path'' aux chemins par défaut, vous devez inclure aussi tous les chemins par défaut étant donné qu'une directive path dans /etc/conf.modules remplacera toutes celles que modprobe connaît par défaut.

Normalement, vous ne voudrez pas ajouter de path par vous-même étant donné que l'ensemble des chemins par défaut prend en compte toutes les configurations normales, je vous le promets !

D'un autre côté, si vous voulez juste ajouter un alias ou une directive d'option, vos nouvelles entrées dans /etc/conf.modules seront ajoutées à celles que modprobe connaît déjà. Si vous deviez redéfinir un alias ou une option, vos nouvelles entrées dans /etc/conf.modules remplaceront celles déjà présentes.

8.1 Les périphériques bloc

Si vous lancez /sbin/modprobe -c, vous aurez la liste des modules connus par kerneld et à quelles requêtes ils correspondent. Par exemple, la requête qui termine le chargement du gestionnaire de disquettes correspond au périphérique bloc dont le numéro majeur est 2 :

 osiris:~ $ /sbin/modprobe -c | grep floppy
 alias block-major-2 floppy

Pourquoi block-major-2 ? Parce que les lecteurs de disquettes /dev/fd* utilisent un numéro majeur égal à 2 et sont de type bloc :

 osiris:~ $ ls -l /dev/fd0 /dev/fd1
 brw-rw-rw-   1 root     root       2,   0 Mar  3  1995 /dev/fd0
 brw-r--r--   1 root     root       2,   1 Mar  3  1995 /dev/fd1

8.2 Les périphériques caractères

Les périphériques de type caractère sont utilisés de la même manière. Par exemple, le lecteur de bande correspond au numéro majeur 27 :

 osiris:~ $ ls -lL /dev/ftape
 crw-rw----   1 root     disk      27,   0 Jul 18  1994 /dev/ftape

Toutefois, kerneld ne le connaît pas par défaut : il n'est pas listé dans le résultat de /sbin/modprobe -c.

Donc, pour configurer kerneld de manière à charger le gestionnaire ftape, je dois ajouter une ligne au fichier de configuration /etc/conf.modules :

 alias char-major-27 ftape

8.3 Les périphériques réseau

Vous pouvez aussi utiliser le nom du périphérique à la place de char-major-xxx ou block-major-yyy. Ceci est particulièrement utilisé pour les gestionnaires réseaux. Par exemple, un pilote pour une carte réseau ne2000 utilisée comme eth0 pourrait être chargé avec :

 alias eth0 ne

Si vous devez passer des options au gestionnaire (comme de dire au module quelle IRQ la carte réseau utilise), vous ajoutez une ligne options :

 options ne irq=5

Ainsi kerneld lancera le gestionnaire NE2000 avec la commande :

 /sbin/modprobe ne irq=5

Bien sûr, les options disponibles sont spécifiques aux modules que vous chargez.

8.4 Les formats binaires

Les formats binaires sont gérés de la même façon. A chaque fois que vous essayez de lancer un programme que le noyau ne sait pas comment exécuter, kerneld lance une requête pour binfmt-xxx, ou xxx est le nombre déterminé à partir des tous premiers octets de l'exécutable. Donc la configuration de kerneld pour la gestion du chargement du module binfmt_aout pour les exécutable ZMAGIC (a.out) est :

 alias binfmt-267 binfmt_aout
vu que le nombre magique pour les fichiers ZMAGIC est 267 (voir /etc/magic). Si vous regardez /etc/magic, vous verrez le nombre 0413, ceci parce que ce fichier utilise des nombres octaux alors que kerneld utilise des décimaux ( 413 en octal correspond à 267 en décimal ). Il y a en réalité trois variantes des exécutables a.out peu différentes (NMAGIC, QMAGIC et ZMAGIC). Pour un support total du format a.out, vous devez avoir :
 alias binfmt-264 binfmt_aout  # pure executable (NMAGIC)
 alias binfmt-267 binfmt_aout  # demand-paged executable (ZMAGIC)
 alias binfmt-204 binfmt_aout  # demand-paged executable (QMAGIC)

Les formats binaires a.out, Jave et iBCS sont reconnus automatiquement par kerneld sans la moindre configuration.

8.5 Les disciplines de ligne (slip, cslip et ppp)

Les disciplines de lignes sont demandées avec tyy-ldisc-xx est généralement 1 (pour SLIP) ou 3 (pour PPP). Ces deux sont reconnus automatiquement par kerneld.

Concernant PPP, si vous voulez que kerneld charge le module de compression de données pour PPP bsd_comp, vous devez ajouter les deux lignes suivantes au fichier /etc/conf.modules :

 alias tty-ldisc-3 bsd_comp
 alias ppp0 bsd_comp

8.6 Les familles de protocoles réseau (IPX, AppleTalk, AX.25)

Certains protocoles réseau peuvent être aussi chargés sous la forme de modules. Le noyau demande à kerneld une famille de protocole (par exemple IPX) avec une requête pour net-pf-XX est un nombre indiquant la famille voulue. Par exemple, netpf-3 correspond à AX.25, net-pf-4 à IPX et net-pf-5 à AppleTalk. (Ces nombres sont déterminés par les macros AF_AX25, AF_IPX etc., que l'on trouve dans le fichier source include/linux/socket.h. Donc, pour charger automatiquement le module IPX, vous devrez ajouter une entrée dans /etc/conf.modules :

 alias net-pf-4 ipx

Consultez également la section traitant des problèmes courants pour éviter des messages d'avertissment lors de l'amorçage relatifs à des familles de protocoles indéfinies.

8.7 Les systèmes de fichiers

Les requêtes soumises à kerneld pour les systèmes de fichiers sont simplement constituées par le type du système de fichiers. Un usage courant est de charger le module isofs pour les systèmes de fichiers des CD-ROM, c'est-à-dire les systèmes de fichiers de type iso9660 :

 alias iso9660 isofs


Page suivante - Page précédente - Table des matières