J'ai récemment installé un Linux intégré fourni par le fournisseur sur un périphérique matériel. Lorsque j'ai exécuté lsmod
sur la ligne de commande du périphérique, la réponse était vide. J'ai été amené à croire que cela signifiait que les pilotes du matériel s'exécutant sur le périphérique avaient été intégrés au noyau plutôt que sous forme de fichiers .ko. Ma question est la suivante: comment se déroule ce processus?
La prise en charge du matériel courant est-elle progressivement intégrée au noyau dans les versions ultérieures, remplaçant ainsi les fichiers .ko? Le fichier .ko est-il simplement utilisé pour prendre en charge un nouveau matériel ne prenant pas en charge les pilotes intégrés au noyau au moment de la publication? Dans ma connaissance limitée, je pensais que tous les pilotes de matériel avaient la forme de fichiers .ko, mais il est clair que c'est faux.
Je suis un peu déconcerté par tout le processus et souhaiterais des éclaircissements, car j’ai le sentiment que j’ai peut-être mal regardé la situation.
Les pilotes principaux considérés comme critiques pour le chargement du noyau sont généralement intégrés au noyau, tandis que les autres pilotes matériels, etc., sont construits sous forme de modules ou de fichiers . Ko.
Les modules . Ko sont généralement stockés dans le répertoire /lib
de votre partition racine. Pour utiliser l'un de ces éléments, le noyau doit d'abord pouvoir détecter et accéder au périphérique de stockage sous-jacent, puis à son système de fichiers. Il est donc prudent de supposer qu'un noyau sans support SATA/SCSI et ext2/3/4 intégré ne démarrera pas vraiment;)
Vous pouvez choisir de basculer la plupart des pilotes de noyau intégrés sous forme de module. L’équipe de noyau Ubuntu décide de modifier la configuration par défaut de l’équipe de noyau Linux et d’inclure/exclure des pilotes intégrés supplémentaires pour les images de noyau stockées que vous téléchargez.
Si vous construisez votre propre noyau, vous pouvez faire la même chose:
*
indique un pilote intégré, tandis que M
indique un module.Lors de la compilation d'un noya , vous obtenez configurer les composants installés. Non seulement cela, mais vous devez choisir s'ils sont construits ou non dans le noyau ou s'il s'agit d'un module .
Par exemple, de nombreuses personnes utilisent le système de fichiers ext2 sur leur partition /boot . Pour cette raison, le noyau doit pouvoir lire les systèmes de fichiers ext2 au démarrage. Pour ce faire, le module ext2 est intégré au noyau lui-même.
Maintenant, imaginez la quantité de modules disponibles. Cela n'aurait aucun sens de les avoir tous intégrés dans votre noyau, n'est-ce pas? C'est pourquoi vous pouvez les construire en tant que modules distincts . Ko et les charger à volonté.
Cela dépend de la manière dont vous avez configuré votre compilation du noyau Linux.
Dans un processus de compilation, vous pouvez généralement:
pour comprendre à quoi sert un fichier .ko https://stackoverflow.com/questions/10476990/difference-between-o-and-ko-file
La raison pour laquelle vous avez une sortie vide sur lsmod
est parce que vous avez un noyau monolithique.
Un moyen rapide de lister tous vos modules (s’ils sont présents) consiste à exécuter cette commande
find /lib/modules/*/ -type f -iname '*.ko' | less
remarquez l'utilisation de less
, vous pouvez utiliser tous les pageurs de votre choix ou rediriger la sortie vers l'endroit souhaité.
ls /sys/module
semble contenir tous les modules intégrés et externes.
Mais il semble également contenir des entrées qui ne sont pas réellement des modules: https://unix.stackexchange.com/questions/225706/are-modules-listed-under-sys-module-all-the-loaded- modules
TODO: lisez la source et comprenez plus précisément ce qui y est mis.
L'avantage de cette méthode est que vous ne pouvez pas rechercher la configuration du noyau sous /boot
ou /proc/config.gz
.
Voir le contenu du fichier / lib/modules/$ (uname -r) /modules.builtin
par exemple. rechercher un module spécifique
grep <module> /lib/modules/$(uname -r)/modules.builtin
Documentation/kbuild/kbuild.txt
modules.builtin
--------------------------------------------------
This file lists all modules that are built into the kernel. This is used
by modprobe to not fail when trying to load something builtin.