"module statique" et "où est mon .ko ?" ne vont pas très bien ensemble.
+ Soit tu compiles ton fichier C pour l'incorporer dans la grosse image du noyau (c'est ce que tu fais là). Dans ce cas, il y a un .o (le fichier C compilé avec un gcc -c, tout va bien) et l'image finale du noyau (Image, zImage, bzImage, ...) contient les symboles de ce fichier.
+ Soit tu compiles ton (ou tes) fichier(s) C pour faire un module qui pourra être chargé dynamiquement et dans ce cas tu auras à la fois le .o et le .ko
Maintenant, il reste la question de la configuration de la compilation.
- La variable obj-y contient la liste des objets à lier à la grosse image.
- La variable obj-m contient la liste des modules à compiler
- Les defines CONFIG_XXX contiennent l'information 'y' ou 'm' en fonction de ce que l'on souhaite faire (lier le module à la grosse image ou en faire un objet chargeable dynamiquement (= .ko))
- en général on écrit dans le Makefile :
obj-$(CONFIG_XXX) += mon_module.o
- Le fichier Kconfig permet de déclarer XXX pour qu'un make menuconfig t'affiche l'option
config XXX
tristate "mon super module"
depends on FOO && BAR
help
Poupou !
- un make menuconfig permet de configurer XXX (au choix "ne pas l'inclure" "l'include dans l'image du noyau" "faire un module") et tu dois avoir un CONFIG_XXX dans le fichier .config qui contient la configuration courante de la compilation
- si ce que tu veux faire est un module qui pourra se charger dynamiquement il faut avoir :
linux-2.6$ grep CONFIG_XXX .config
CONFIG_XXX=m
et là tout s'enchaîne, dans le Makefile, obj-$(CONFIG_XXX) devient obj-m += mon_module.o et kbuild sort un .ko
Il reste des petits détails, du genre un make modules_install pour installer les modules fraichement construits là où le noyau pourra les trouver avec un modprobe (INSTALL_MOD_PATH permet d'installer ces modules autre part que le chemin par défault ('/')) ou un depmod -a pour construire les fichiers qui décrivent les dépendances entre les modules.
# Un peu plus sur Kbuild
Posté par Damien Lespiau . En réponse au message compilation d'un module statiquement ds le noyau. Évalué à 3.
+ Soit tu compiles ton fichier C pour l'incorporer dans la grosse image du noyau (c'est ce que tu fais là). Dans ce cas, il y a un .o (le fichier C compilé avec un gcc -c, tout va bien) et l'image finale du noyau (Image, zImage, bzImage, ...) contient les symboles de ce fichier.
+ Soit tu compiles ton (ou tes) fichier(s) C pour faire un module qui pourra être chargé dynamiquement et dans ce cas tu auras à la fois le .o et le .ko
Maintenant, il reste la question de la configuration de la compilation.
- La variable obj-y contient la liste des objets à lier à la grosse image.
- La variable obj-m contient la liste des modules à compiler
- Les defines CONFIG_XXX contiennent l'information 'y' ou 'm' en fonction de ce que l'on souhaite faire (lier le module à la grosse image ou en faire un objet chargeable dynamiquement (= .ko))
- en général on écrit dans le Makefile :
obj-$(CONFIG_XXX) += mon_module.o
- Le fichier Kconfig permet de déclarer XXX pour qu'un make menuconfig t'affiche l'option
config XXX
tristate "mon super module"
depends on FOO && BAR
help
Poupou !
- un make menuconfig permet de configurer XXX (au choix "ne pas l'inclure" "l'include dans l'image du noyau" "faire un module") et tu dois avoir un CONFIG_XXX dans le fichier .config qui contient la configuration courante de la compilation
- si ce que tu veux faire est un module qui pourra se charger dynamiquement il faut avoir :
linux-2.6$ grep CONFIG_XXX .config
CONFIG_XXX=m
et là tout s'enchaîne, dans le Makefile, obj-$(CONFIG_XXX) devient obj-m += mon_module.o et kbuild sort un .ko
Il reste des petits détails, du genre un make modules_install pour installer les modules fraichement construits là où le noyau pourra les trouver avec un modprobe (INSTALL_MOD_PATH permet d'installer ces modules autre part que le chemin par défault ('/')) ou un depmod -a pour construire les fichiers qui décrivent les dépendances entre les modules.