Bonjour à tous.
Quelqu’un ayant exprimé sa méconnaissance du fonctionnement des modules, et comme ca ne correspondait plus trop au fil de discussion courant, je me permet de faire profiter un peu tout le monde de ma reponse.
[quote=“http://www.tldp.org/LDP/lkmpg/2.4/html/book1.htm”]
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.[/quote]
Pour les non anglicistes: un module de noyau est un bout de code executable 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 materiel, mais on trouve aussi des fonctionnalités de cryptage, ou d’optimisation, par exemple.
Pourquoi:
Historiquement, les modules ont été introduit pour éviter de construire d’enormes noyaux contenant d’enormes parties de code inutilisé le plus souvent. Par ailleurs, une autre contrainte à guidé l’allègement de ce noyau, c’etait 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 la - sont regroupés dans un filesystem compressé (on appelle ca un initrd), qui est monté sur /initrd au moment du boot: c’est pour ca que le composant de decompression (cramfs sous debian) est un des seuls qui doive etre forcément integré au noyau, car il doit etre disponible AVANT les autres modules critiques, afin de pouvoir décompresser depuis le noyau l’initrd.
Au dela de ces conditions initiales, le détachement de ces bouts de code du noyau à permis de faire une économie de ressources mêmoire: seuls les modules effectivement utilisés par un peripherique 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ée peuvent donc être swappées, contrairement au noyau qui reste en permanence en mêmoire.
Finalement, la multiplication des périphèriques connectables à chaud, à 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-
Les modules eux mêmes sont dans /lib/modules/
Comment:
Manipulation des modules:
liste : lsmod
insertion: modprobe
dechargement: rmmod
pour info, si noyau < 2.4 les modules sont des .o, aprés, ce sont des .ko, pour les différentier des .o traditionnels linkables…
le fichier /lib/modules//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//, mais attention, les modifs 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 connaitre avec 'modinfo :
- 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.
bon, c’est tout pour aujourd’hui. Si vous avez des remarques, si j’ai dit une bitise, ou encore si vous avez des choses à rajouter, n’hesitez pas, je reviendrais affiner de toutes facon…
mais au fait, c’est vrai, il nous faudrait un wiki !!!
)
j’ai donc encore dis une groosse boulette ?