Quelle est la séquence de chargement du module du noyau Linux au démarrage? Quelle est leur priorité?

J'ai un module de noyau Linux que j'ai compilé dynamiquement. Comment est-il ajouté au démarrage? Il y a beaucoup de .kofichiers dedans /lib/modules. Comment la priorité est-elle définie pour le chargement de ces modules?

Ils ne sont pas chargés automatiquement au démarrage ou à tout autre moment, bien que beaucoup d'entre eux finissent par être chargés au démarrage. Il existe trois mécanismes différents par lesquels cela se produit:

• Demande d'espace utilisateur: qui couvre tout, des services init à udev en passant par la ligne de commande. Init ou udev sont probablement les moyens les plus simples si vous souhaitez charger un module spécifique au démarrage.

• Périphérique connecté à chaud: lorsque vous connectez quelque chose à, par exemple, USB ou PCI, le noyau le détecte et demande un module approprié en fonction de la façon dont le périphérique s'identifie.

• Protocole nécessaire ou autre implémentation : Lorsque le noyau doit faire quelque chose, comme lire un système de fichiers, et découvre qu'il n'a pas les connaissances nécessaires pour le faire, il demandera un module.

Notez que pour les deux derniers, j'ai utilisé l'expression "demander un module" - c'est parce que le noyau se charge en fait via un démon de l'espace utilisateur, kmodqui s'exécute /sbin/modprobe. Selon Wolfgang Mauerer dans Linux Kernel Architecture , il n'y a que ~ 100 points différents dans le noyau 2.6 où il appelle une request_module()fonction interne .

modprobeutilise une base de données des MODULE_ALIAS installés. Celles-ci sont spécifiées dans le code source du module de manière explicite, ou dérivées de son MODULE_DEVICE_TABLE, qui est une liste d'ID de périphérique OEM que le module dessert.

De nombreux systèmes sont configurés pour utiliser un initrd ou des initramfs . Ce sont des images de système de fichiers qui sont chargées par le chargeur de démarrage et mises à la disposition du noyau avant qu'il ne monte la partition racine. Cela permet aux pilotes nécessaires au montage de la partition racine (pilotes de disque, pilotes de système de fichiers, mappeur de périphériques ou pilotes de volume logique,…) d'être compilés en modules et chargés depuis initrd / initramfs.

Les scripts de démarrage sur initrd ( /linuxrc) ou initramfs ( /init) chargent généralement certains modules et localisent le système de fichiers racine. Chaque distribution a sa propre configuration. Ubuntu utilise un initramfs qui est assemblé à partir des composants du initramfs-toolspackage et régénéré pour chaque noyau en fonction des pilotes nécessaires pour monter le système de fichiers racine.

Une fois le système de fichiers racine monté, lors du démarrage du système, les modules répertoriés dans /etc/modules(Debian,…) ou /etc/modules.conf(Red Hat, Arch,…) sont chargés. Ce fichier répertorie généralement peu de modules, le cas échéant. La plupart des modules sont chargés à la demande.

Lorsque le noyau détecte du matériel pour lequel il manque un pilote, ou certains autres composants tels que des protocoles réseau ou des algorithmes cryptographiques, il appelle /sbin/modprobepour charger le module. Pour les pilotes matériels, le noyau transmet des noms qui codent l'ID PCI, l'ID USB ou toute autre désignation systématique du matériel. Il y a un tableau /lib/modules/$VERSION/modules.aliasqui mappe ces désignations systématiques aux noms de modules. Ce tableau est généré par depmodet lu par modprobe.

Si vous avez un module de noyau supplémentaire que vous avez compilé manuellement pour un périphérique matériel, déposez-le dans /lib/modules/$VERSION/local(créez le localsous-répertoire s'il n'existe pas) et exécutez depmod -apour régénérer la base de données d'alias. Si le module concerne une fonctionnalité inhabituelle que le noyau n'est pas en mesure de détecter automatiquement, déposez-le /lib/modules/$VERSION/local, exécutez-le depmod -apour analyser ses dépendances et ajoutez le nom du module à /etc/modules.