Les Modules

Les modules

Sur la page de tldp.org qui explique le fonctionnement des modules on peut lire

What exactly is a kernel module? Modules are pieces of code that can be loaded and unloaded into the kernel upon demand. 
They extend the functionality of the kernel without the need to reboot the system. 
For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system.
Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image.
Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality.

Pour les non anglicistes : un module de noyau est un bout de code exécutable que l'on branche en cas de besoin sur le noyau pour lui ajouter une fonctionnalité. Ces fonctionnalités concernent le plus souvent la gestion d'un composant matériel, mais on trouve aussi des fonctionnalités de cryptage, ou d'optimisation, par exemple.

Pourquoi : Historiquement, les modules ont été introduits pour éviter de construire d'énormes noyaux contenant d'énormes parties de code inutilisé le plus souvent. Par ailleurs, une autre contrainte a guidé l'allègement de ce noyau, c'était de faire tenir l'ensemble des éléments minimaux pour démarrer dans une disquette 1.44 Mo. Du coup, les modules nécessaires au boot - et seulement ceux-là - sont regroupés dans un filesystem compressé (on appelle ça un initrd), qui est monté sur /initrd au moment du boot. C'est pour ça que le composant de décompression (cramfs sous debian) est un des seuls qui doive être forcément intégré au noyau, car il doit être disponible AVANT les autres modules critiques, afin de pouvoir décompresser depuis le noyau l'initrd.

Au delà de ces conditions initiales, le détachement de ces bouts de code du noyau a permis de faire une économie de ressources mêmoire. Seuls les modules effectivement utilisés par un périphérique restent chargés, les autres se déchargeant automatiquement quand ils ne trouvent aucun périphérique à gèrer. Par ailleurs, ces modules étant dans des pages mêmoire séparées peuvent donc être swappés, contrairement au noyau qui reste en permanence en mêmoire. Finalement, la multiplication des périphèriques connectables à chaud a donné une justification supplémentaire à cette logique "just in time".

Ou : la configuration (= le .config) qui a servi à compiler le noyau est dans /boot/config-<version> Les modules eux-mêmes sont dans /lib/modules/<version>

Comment : Manipulation des modules :

liste : lsmod
insertion : modprobe <nom de module ou chemin absolu du module>
Déchargement : rmmod <nom de module>

Pour info, si noyau < 2.4 les modules sont des .o, aprés, ce sont des .ko, pour les différencier des .o traditionnels linkables...

Le fichier /lib/modules/<version de noyau>/modules.dep, génèré par la commande "depmod -a", contient la liste des modules, et de comment les uns dépendent des autres. On peut l'ajuster manuellement, pour y déclarer des modules qui ne sont pas dans l'arborescence /lib/modules/<version de noyau>/, Mais attention, les modifications sont facilement écrasées par depmod.

Configuration : Pour tous noyaux, /etc/modules contient la liste des modules que l'on veut charger automatiquement au boot.

Les modules acceptent parfois des arguments que l'on peut connatre avec 'modinfo <nom module> :

• pour les noyaux 2.4, on peut préciser ces éléments dans /etc/modutils. Le fichier modules.conf généré automatiquement par 'update-modules' (du paquet modutils), contient la concatenation du contenu de ce dernier répertoire.
• sous 2.6, /etc/modprobe.d et modprobe.conf, et le paquet module-init-tools jouent le même rôle respectif que les 3 précédents.

Ce document a été écrit par Mattotop sur forum.debian-fr.org

Module-assistant

module-assistant est un programme permettant de construire les modules non fournis avec le noyau (exotiques ou propriétaires). Par exemple, le module pour ndiswrapper, le pilote propriétaire pour les cartes nvidia ou des modules pour la virtualisation (kqemu, virtualbox).

Parfois, le module est fourni sous forme de paquet précompilé, généralement noté nom_du_pilote-module-version_du_noyau. Un module de la sorte est utilisable si vous avez un noyau de même version. Pour connaitre votre version du noyau, tapez :

$ uname -r

Si la version correspond, il vous suffit d'installer le paquet en question. S'il n'existe pas de paquet pour votre version du noyau (ou s'il n'en existe pas du tout). Il vous faudra le compiler à partir des sources. La démarche est sensiblement la même pour tous les paquets.

On commence par installer les sources

# aptitude install nom_du_pilote-sources

On s'assure d'avoir un fichier d'index à jour :

# m-a update

On installe le nécessaire pour compiler :

# m-a prepare

On nettoie les répertoires de construction des paquets :

# m-a clean nom_du_module

On peut enfin construire le paquet :

# m-a build nom_du_module

Un paquet est alors créé dans /usr/src, vous pouvez l'installer avec dpkg ou bien en lançant :

# m-a install nom_du_module

Notes :

• Vous pouvez construire et installer le paquet en une seule commande :

# m-a a-i nom_du_module

• La liste des paquets disponibles pour la construction peut être obtenue par :

# m-a list