Guide d'installation et de configuration de Linux Précédent Chapitre 6. Configuration du système de base Suivant 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. Certains drivers ne fonctionnent que sous la forme de modules, aussi faut-il savoir les manipuler.
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 :
insmod moduleou :modprobe moduleoù 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ème, 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 ces informations de dépendance 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.def automatiquement, pourvu qu'on l'appelle avec l'option -a en ligne de commande :
Il faudra donc appeler cette commande après chaque installation ou suppression de module dans le système.La liste de modules qui ont été chargés peut être obtenue aisément avec la commande lsmod :
Enfin, la commande rmmod permet de décharger un module, avec la ligne de commande suivante :
La plupart des modules penvent prendre un certain nombre d'options lors de leur chargement. Ces options sont en quelque sorte l'équivalent des options que l'on communique au noyau lors du boot, pour préciser par exemple la configuration matérielle utilisée. Toutes ces options sont définies dans le fichier de configuration/etc/modules.conf. Lors du chargement d'un module, modprobe consulte ce fichier et passe les paramètres indiqués au module à charger.
Les options des modules sont spécifiées dans le fichier module.conf à l'aide du mot-clé option, 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 :
option module paramètresPar exemple, il est probable que le driver du port parallèle soit fourni sous la forme de module avec votre distribution. Cela permet de le charger à la demande, et de le configurer pour les différentes utilisations possibles d'un port parallèle : communication avec une imprimante parallèle, ou avec un lecteur ZIP, ou encore avec un lecteur de CD IDE, etc. Sur les ordinateurs de type PC, le nom du module gérant le port parallèle est « parport_pc ». Ce module peut prendre des paramètres de chargement permettant d'indiquer le port d'entrée/sortie à utiliser et la ligne d'interruption à utiliser. 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 module.conf :
Le fichier module.conf permet également de définir des opérations complémentaires qui doivent être effectuées lors du chargement et du déchargement d'un module. Ces opérations sont introduites par les mots-clés pre-install, post-install, pre-remove ou post-remove. Selon le mot-clé utilisé, elles sont exécutées respectivement avant et après le chargement du module, et avant et après son déchargement. Ces quatre mots-clés utilisent tous la même syntaxe :
xxx-install module opérationoù xxx-install est le mot-clé indiquant les conditions d'application de l'opération, module est le nom du module pour lequel une opération complémentaire doit être effectuée, et opération est la ligne de commande de l'opération en question.Ainsi, 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 après le chargement du module à l'aide du mot-clé post-install :
(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à.Dans la plupart des cas, ces options sont facultatives, car modprobe utilise un jeu de valeurs par défaut qui permettent d'utiliser les modules même si le fichier de configuration modules.conf est absent. Vous pouvez visualiser ces options en renommant le fichier de configuration modules.conf et en tapant la commande suivante :
Cette commande vous permettra également de recréer un nouveau fichier de configuration si d'aventure vous perdiez celui fourni avec votre distribution. Notez cependant qu'il est recommandé d'adapter le fichier de configuration modules.conf afin d'obtenir des performances optimales. Les modifications que nous avons données en exemple ci-dessus pour le port parallèle permettent par exemple d'éviter que le noyau consulte en permanence le port pour savoir s'il est prêt à recevoir ou à fournir de nouvelles données pendant les impressions. Le gain de performance peut ainsi atteindre 10% quelle que soit la vitesse du processeur, ce qui est très loin d'être négligeable.
Il n'est normalement pas nécessaire d'utiliser ces commandes pour charger les modules. En effet, il est possible de faire en sorte que les modules soient chargés à la demande, lorsqu'une de leurs fonctionnalités est demandée au niveau du noyau. Pour cela, le noyau utilise lui-même la commande modprobe pour charger les modules, ce qui assure la gestion correcte des dépendances entre les modules. À chaque fois que le noyau a besoin d'une fonctionnalité qui n'est pas encore chargée, il effectue une requête à modprobe en lui demandant de charger le module manquant.
Le nom du module dont le noyau demande le chargement à modprobe dépend évidemment de la fonctionnalité demandée et ne correspond pas forcément à un nom de module existant. 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 encore une fois dans le fichier de configuration /etc/modules.conf que cette correspondance est stockée. Par exemple, lorsque le noyau désire accéder au port parallèle, il utilise la commande suivante :
où parport_lowlevel est le nom que le noyau utilise pour référencer le port parallèle. Ce nom est identique quelle que soit la plate-forme sur laquelle le noyau fonctionne, qu'il s'agisse d'un PC, d'un Mac ou d'une station de travail Sun. Sur les ordinateurs dont l'architecture est de type PC, le véritable module à utiliser est, comme on l'a vu, parport_pc. Il faut donc donner indiquer l'association entre les noms parport_lowlevel et parport_pc dans le fichier modules.conf.Cette association est réalisée par la définition d'un certain nombre d'alias de modules réels. Chaque alias est introduit par le mot-clé alias, dont la syntaxe est donnée ci-dessous :
alias nom moduleoù 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 le fichier modules.conf, puis elle le charge en mémoire. Pour le port parallèle, on aura donc la définition suivante dans le fichier modules.conf :L'option -k passée en paramètre à modprobe par le noyau n'est quant à elle utilisée que par le noyau. Elle permet de marquer le module comme étant automatiquement déchargeable, lorsque plus personne n'utilisera ses fonctionnalités. Cette technique permet de minimiser la consommation mémoire du noyau, sur les machines dont les ressources sont très limitées. Les modules qui sont chargés automatiquement par le noyau sont en effet marqués comme étant automatiquement déchargeables, et on peut effectivement les supprimer à l'aide de la commande suivante :
Cette commande décharge les modules inutilisés automatiquement, dans l'ordre inverse de leur chargement. Cette commande respecte donc les dépendances entre modules, et seuls les modules inutilisés sont réellement déchargés. Il est recommandé de placer cette commande dans le fichier /etc/crontab de votre système, afin que les modules inutilisés soient déchargés à intervalle de temps régulier. Vous aurez donc sans doute à placer une ligne telle que celle-ci : dans votre fichier /etc/crontab. Le déchargement des modules inutilisés aura lieu toutes les deux minutes.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 le fichier de configuration modules.conf. L'inconvénient de cette méthode est en revanche qu'il faut connaître les noms de modules utilisés par le noyau. Ces noms sont assez variables et dépendent de la fonctionnalité demandée. Toutefois, les noms utilisés par le noyau peuvent facilement être déterminés pour les modules gérant les fichiers spéciaux de périphériques. En effet, il est possible de construire un nom unique pour chaque fichier spécial de périphérique, qui pourra être utilisé par le noyau pour spécifier le module capable de gérer les fonctionnalités de ce fichier. La manière de construire ces noms varie selon que le fichier spécial de périphérique accédé, et selon qu'il s'agit d'un fichier réel ou d'un fichier du système de fichiers virtuel /dev/ du noyau.
S'il s'agit d'un vrai fichier spécial de périphérique, il est parfaitement identifié par sa nature (disque, périphérique de type caractère, interface réseau...) et ses deux codes majeur et mineur. Le noyau peut donc construire un nom à partir de ces informations. Ainsi, pour un fichier spécial de périphérique de type caractère, le nom généré par le noyau est en général de la forme « char-major-xxxx ». Pour les périphériques de type bloc, il est de la forme « block-major-xxxx ». Les caractères xxxx identifient le code majeur de ce périphérique, plus rarement son code mineur. Par exemple, pour les cartes son, le nom de module char-major-14 sera utilisé, parce que les cartes sons utilisent toutes le code majeur 14. Le code mineur n'est actuellement pas utilisé pour les cartes son.
Même si les noms de modules sont toujours construit plus ou moins selon ce schéma pour les fichiers spéciaux de périphériques réels, il reste difficile de déterminer le nom exact du module associé à un fichier spécial de périphérique. Par exemple, nous avons vu que le nom de module utilisé pour le port parallèle (accessible via le fichier spécial de périphérique /dev/lp0) est parport_lowlevel. De même, le nom utilisé pour les interfaces réseau de type Ethernet est eth0, eth1, etc. Il n'est donc pas toujours évident de savoir quel est le nom que le noyau utilisera. Le plus simple dans ce cas est encore de regarder dans la configuration utilisée par modprobe à l'aide de son option -c.
En revanche, si le fichier spécial de périphérique est un fichier virtuel, le mécanisme de nommage est complètement différent. En effet, le système de fichiers virtuel /dev/ crée les fichiers spéciaux de périphériques à la demande, lorsque les gestionnaires de périphériques s'enregistrent au niveau du noyau. Il n'est donc pas possible de déterminer les codes majeurs et mineurs des fichiers spéciaux de périphériques si les modules qui les gèrent ne sont pas chargés, parce que ces fichiers n'existent pas encore d'une part, et parce que ces codes sont déterminés dynamiquement et ne sont donc jamais fixes d'autre part.
Le chargement des modules à la demande est en fait réalisé par le démon devfsd, que nous avons déjà décrit dans la la section intitulée Notion de fichiers spéciaux de périphériques. Outre la création des liens symboliques permettant d'accéder aux fichiers spéciaux de périphériques sous leur nom classique, ce démon est capable d'effectuer des actions diverses lorsqu'un événement se produit dans le système de fichiers virtuel /dev/. Toutes ces actions sont décrites dans le fichier de configuration /etc/devfsd.conf. En particulier, il est possible d'effectuer une action lorsqu'un programme recherche un fichier spécial de périphérique dans le système de fichiers, chose que tous les programmes qui utilisent les fichiers spéciaux de périphériques font, ne serait-ce que pour pouvoir les ouvrir. C'est lors de cette recherche que le démon devfsd va demander le chargement du module correspondant au fichier spécial de périphérique demandé.
Pour que ce mécanisme fonctionne, il faut avant tout l'activer. Cela se fait simplement en ajoutant la ligne suivante dans le fichier devfsd.conf :
qui signifie que le chargement dynamique de module (action « MODLOAD ») doit être effectuée lorsqu'une recherche (événement « LOOKUP ») a lieu dans le système de fichiers virtuel /dev/, et ce pour n'importe quel nom de fichiers spécial de périphérique (expression réguière « .* », qui représente n'importe quelle séquence de caractères).Bien entendu, les noms de modules utilisés par le démon devfsd ne peuvent pas se baser sur les codes majeurs et mineurs du fichier spécial de périphérique pour les raisons que l'on a indiqué ci-dessus. Mais pourquoi faire compliqué quand on peut faire simple ? Le démon devfsd ne s'embarrasse pas de détails, et demande tout simplement le chargement du module dont le nom est exactement le chemin du fichier spécial de périphérique recherché ! Il suffit donc tout simplement de définir les alias correspondant dans le fichier modules.conf pour éventuellement trouver le bon nom de module à charger.
En fait, le démon devfsd utilise un autre fichier de configuration, le fichier /etc/modules.devfs, afin de simplifier l'écriture du fichier modules.conf. Ce fichier lui permet d'associer un ensemble de noms de fichiers spéciaux de périphériques à un seul module. Par exemple, tous les ports série d'une machine utilisent, en général, le même gestionnaire, bien qu'ils soient accessibles par l'intermédiaire des fichiers spéciaux de périphériques /dev/ttySn, où n est le numéro du port série (0 pour le port COM1, 1 pour le port COM2, etc.). Le fichier modules.devfs regroupe donc tous les noms de modules /dev/ttyS* en un seul nom de module, à savoir serial. C'est donc ce nom là qui sera communiqué à modprobe pour le chargement du module de gestion des ports série.
De manière générale, vous n'aurez pas à modifier les fichiers devfsd.conf et modules.devfs, car ceux généralement fournis avec les distributions conviennent parfaitement. En revanche, vous modifierez certainement le fichier modules.conf. Il s'agit là d'un 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 de modules.conf 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.
Précédent Sommaire Suivant Configuration de la console Niveau supérieur Configuration des périphériques additionnels