Je travaille sur une carte avec un processeur ARM embedded. Pour l'amorcer, je dois append un bootloader, un kernel linux et une image disque contenant le système de files racine. Cette image disque est disponible sur Internet pour la carte cible (ZedBoard).
Après avoir compilé le kernel avec tous les pilotes nécessaires activés, j'ai découvert que de nombreux pilotes sont disponibles dans / lib / modules / kernel_number.
Je suis un peu confus quant à la façon dont tout cela fonctionne. Les pilotes sont-ils chargés par le kernel? si oui, pourquoi sont-ils déjà une partie des rootfs? ou le kernel les écrase-t-il avec ceux compilés dedans?
C'est assez simple, même si nous devrions faire la distinction entre "driver" et "module". Un pilote peut ou ne peut pas être un module. Si ce n'est pas le cas, il est embedded au kernel chargé par le bootloader.
S'il s'agit d'un module, il se trouve dans une hiérarchie de filesystems qui se trouve dans /lib/modules/[kernel-release]
. 1 Notez qu'il est possible de démarrer un kernel avec un petit système de files racine préliminaire (un «initramfs») qui peut aussi contenir un tel référentiel. Ceci est normal avec les kernelx generics afin qu'ils puissent décider quels pilotes modulaires ils doivent charger pour accéder au système de files réel, car s'ils ne peuvent pas le faire, ils ne peuvent y accéder.
Les pilotes sont-ils chargés par le kernel?
Oui.
si oui, pourquoi sont-ils déjà une partie des rootfs?
Où d'autre devraient-ils être stockés avant d'être chargés? Le kernel ne contient pas les rootfs en lui-même (sauf WRT certaines forms d'initramfs), c'est juste le gatekeeper.
le kernel les écrase-t-il avec ceux compilés dedans?
Non. Si vous comstackz un pilote, le kernel ne prendra pas la peine de vérifier /lib/modules
pour cela. Je ne suis pas sûr de ce qui se passe si vous lui requestz explicitement de charger un tel conducteur de toute façon, probablement il dira simplement non.
1. Comme Celada fait allusion à $(uname -r)
, cette string de version n'est pas nécessairement juste le numéro de version. Vous pouvez avoir plusieurs kernelx avec la même version et différentes strings de versions, donc des magasins de modules séparés. De même, vous pouvez avoir plusieurs kernelx avec la même string de version, donc le même magasin de modules.
Sous Linux, la plupart des pilotes peuvent être construits statiquement dans le kernel, ou construits en tant que modules. C'est un choix que vous pouvez faire lorsque le kernel est en cours de compilation. Ils n'apparaîtront que dans /lib/modules/$(uname -r)
s'ils sont construits en tant que modules chargeables.
En règle générale, pour les systèmes à usage général, en particulier pour les kernelx pré-compilés disponibles dans le cadre des dissortingbutions Linux, l'set minimal de pilotes sera construit statiquement et, autant que possible, sera construit en modules. Cela permet au système de chaque user de ne charger que les modules nécessaires, sans savoir à l'avance ce qu'ils sont.
Les kernelx pour les systèmes embarqués sont souvent construits avec beaucoup plus de pilotes car le kernel est construit pour un système avec un set très spécifique de matériel inchangé et l'intégrateur système sait à l'avance ce qu'il est. Néanless, de nombreux pilotes sont souvent chargés en tant que modules, en particulier pour du matériel «supplémentaire» qui peut ou non être présent comme les périphériques USB.