Les modules de pilotes sont-ils chargés et déchargés automatiquement?


15

Sur Ubuntu 14.04, j'ai constaté que lorsque je ne branche pas mon adaptateur sans fil externe, son module rt2800usbest toujours affiché dans lsmod.

  1. Quand le chargement automatique d'un module de pilote se produit-il? Est-ce lorsque l'appareil est connecté à l'ordinateur ou lorsque le système d'exploitation démarre?

  2. quand le déchargement automatique d'un module pilote a-t-il lieu? Est-ce lorsque l'appareil est déconnecté de l'ordinateur ou lorsque le système d'exploitation s'arrête?

Réponses:


13

Lorsque le noyau détecte un nouveau périphérique, il exécute le programme modprobeet lui transmet un nom qui identifie le périphérique. La plupart des appareils sont identifiés par des numéros enregistrés pour un fournisseur et un modèle, par exemple des identifiants PCI ou USB . Le modprobeprogramme consulte la table d'alias de module pour trouver le nom du fichier qui contient le pilote pour ce périphérique particulier. Un principe similaire s'applique aux pilotes pour les éléments qui ne sont pas des périphériques matériels, tels que les systèmes de fichiers et les algorithmes cryptographiques. Pour plus de détails, voir Debian ne détecte pas la carte PCI série après le redémarrage/lib/modules/VERSION/modules.alias

Une fois que modprobe a identifié le fichier de module ( .ko) qui contient le pilote demandé, il charge le fichier de module dans le noyau: le code du module est chargé dynamiquement dans le noyau. Si le module est correctement chargé, il apparaîtra alors dans la liste de lsmod.

Le chargement automatique des modules se produit lorsque le noyau détecte un nouveau matériel enfichable à chaud, par exemple lorsque vous connectez un périphérique USB. Le système d'exploitation procède également à une énumération de tout le matériel présent sur le système au début du démarrage, afin de charger les pilotes pour les périphériques présents au démarrage.

Il est également possible de demander manuellement le chargement d'un module avec la commande modprobeou insmod. La plupart des distributions incluent un script de démarrage qui charge les modules répertoriés dans /etc/modules. Une autre façon de charger des modules est s'ils sont une dépendance d'un module: si le module A dépend du module B, alors modprobe Acharge B avant de charger A.

Une fois qu'un module est chargé, il reste chargé jusqu'à ce qu'il soit explicitement déchargé, même si tous les périphériques utilisant ce pilote ont été déconnectés. Il y a longtemps, il y avait un mécanisme pour décharger automatiquement les modules inutilisés, mais il a été supprimé, si je me souviens bien, quand udev est entré en scène. Je soupçonne que le déchargement automatique de module n'est pas une caractéristique courante car les systèmes qui auraient tendance à en avoir besoin sont principalement des PC de bureau qui ont quand même beaucoup de mémoire (à l'échelle du code du pilote).


Merci. Je n'ai pas modifié /etc/modules. rt2800usbest en sortie de lsmod, et cela signifie-t-il que j'ai connecté son appareil à mon ordinateur avant le démarrage?
Tim

1
@Tim Si le module est chargé et que vous ne l'avez pas chargé explicitement et qu'il n'est pas répertorié /etc/modules, alors oui, la raison pour laquelle le module est chargé est probablement parce que le périphérique était présent à un moment donné.
Gilles 'SO- arrête d'être méchant'

5

Les modules sont chargés au démarrage du système via le disque RAM initial, alias initrd . La section sur la justification déclare:

De nombreuses distributions Linux livrent une seule image de noyau Linux générique - une image que les développeurs de la distribution créent spécifiquement pour démarrer sur une grande variété de matériel. Les pilotes de périphérique pour cette image de noyau générique sont inclus en tant que modules de noyau chargeables car la compilation statique de nombreux pilotes en un seul noyau fait que l'image du noyau est beaucoup plus grande, peut-être trop grande pour démarrer sur des ordinateurs avec une mémoire limitée. Cela pose alors le problème de détecter et de charger les modules nécessaires pour monter le système de fichiers racine au démarrage, ou d'ailleurs, de déduire où ou quoi est le système de fichiers racine.

Ubuntu, comme de nombreuses autres distributions, choisit de charger chaque pilote de périphérique dans cet initrd, que le pilote soit nécessaire ou non, et également que le périphérique soit présent sur le système ou non. Comme l'a souligné Giles, le tout est chargé dans la RAM, puis les modules utilisés sont détectés au démarrage et ceux inutilisés sont supprimés de la RAM. L'utilisation de cette approche garantit qu'Ubuntu démarrera toujours sur n'importe quel système, quelle que soit la configuration. Ubuntu imite un noyau monolithique en utilisant des constructions de micro-noyau. Voir la raison pour laquelle cela fonctionne


  1. Le module rt2800usbsera toujours chargé au démarrage car le module était inclus dans les initramfs mentionnés par Gilles. L'initramfs est un successeur de l'initrd, donc il sera toujours montré par lsmod. Notez que vous pouvez insérer un module nouvellement compilé dans le noyau en utilisant modprobesuivi du nom du module.

À titre de test, redémarrez votre système avec votre adaptateur sans fil débranché. Si tout se passe bien, le module ne sera pas répertorié dans la lsmodsortie s car pendant le démarrage, le processus de détection lancé par les initramfs et le sstem init n'a pas trouvé le périphérique pendant le sondage, et le module a été supprimé de la RAM.

  1. Pour supprimer un module pendant qu'un système est en cours d'exécution, vous pouvez utiliser des commandes telles que rmmodou modprobe -rsuivies du nom du module. Au prochain démarrage, le module sera rechargé. Voir au dessus. Dans la plupart des cas, un module n'est pas supprimé de manière dynamique, car cela désactiverait le branchement à chaud, c'est-à-dire qu'une fois qu'un module est retiré, le périphérique qui l'utilise ne peut plus être détecté lors de sa réinstallation.

Pour supprimer un module lsmod, vous devez le supprimer de l'image initramfs créée en recompilant le noyau sans le module choisi puis en reconstruisant l'image. Cette opération désactive toute détection dudit module.


3
Vous confondez le chargement d'un fichier dans la RAM dans le cadre d'un disque RAM et le chargement (c'est-à-dire la liaison dynamique) d'un module dans le noyau en cours d'exécution. Les modules sont chargés temporairement dans la mémoire - et non dans le noyau - à partir de l'initrd (techniquement un initramfs de nos jours), mais ils sont ensuite supprimés de la mémoire après le montage de la racine réelle. Les modules ne sont chargés dans le noyau que lorsqu'un périphérique les utilisant est détecté (à quelques exceptions près).
Gilles 'SO- arrête d'être méchant'

Bien que je sois d'accord ici, il parlait de décharger et de charger un module, ce qui ne peut être fait que s'il choisit de reconfigurer le disque RAM d'Ubuntu, ce qui n'est pas recommandé car Ubuntu choisit de charger tous les modules dans la RAM à chaque mise à jour du noyau. Tous les modules sont chargés à chaque fois, ils ne sont tout simplement pas tous utilisés.
eyoung100

2
Non, la question concerne le chargement et le déchargement d'un module dans le noyau. Ni votre réponse originale ni votre réponse révisée ne répondent à cela. Les initramfs ne sont pas pertinents (ou tout au plus périphériques) à cette question.
Gilles 'SO- arrête d'être méchant'

@Gilles Est-ce mieux?
eyoung100

1
@ eyoung100, je suis d'accord avec Gilles. Une discussion sur initramfs n'est pas pertinente pour la question. Les modules sont généralement chargés en énumérant les périphériques /syset en chargeant les pilotes des périphériques qui se trouvent réellement dans le système. Cela se produit que l'appareil soit présent au démarrage ou branché à chaud plus tard. udeva bien plus à voir avec cela que ne le fait initramfs / initrd, et si tous, la plupart ou seulement certains modules sont copiés dans les initramfs (une option de configuration dans /etc/initramfs-tools/initramfs.conf) n'est pas particulièrement pertinent.
Celada
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.