salut !
j'aimerais comprendre se qui fait que les headers soit nécessaire a la compilation d'un module pour chaque version du noyau.
j'ai donc installer les headers et regarder le contenu mais c'est qu'il y a du monde ...
tout ce que je voit c'est une une liste de .h contenant des structures et des constantes.
cela change si souvent que cela?
les modules sont susceptible d'utiliser n'importe quel fichiers de tout cela?
j'ai entendu parler de symboles ... c'est quoi?
a la compilation cela influe sur quoi?
cela fait beaucoup de questions mais je suis curieux et si vous souhaiter me renvoyer a une doc, je n'ai rien contre car j'ai beaucoup de mal a en trouver.
merci et a bientôt!
Forum Linux.noyau comprendre le lien entre les headers du noyau et les modules
16
oct.
2008
# Un noyal
Posté par peck (site web personnel) . Évalué à 6.
Le noyau linux étant monolithique, oui, un module peut utiliser n'importe quoi dans ces en-têtes. Même si en pratique, il n'utilise en général que peu de fonctions.
Les symboles ce sont les noms de ce qu'on trouve dans un binaire. Cela inclue des noms de variable et des noms de fonction. La table des symboles permet de savoir où on peut les trouver. Elle est générée lors de la compilation.
Pour la compilation, je te conseille même si la lecture en est ardue la description du format elf. Ca t'amènera à celle sur l'éditeur de lien ld, sur la liaison dynamique ld-linux.so, sur le format de données de debug dwarf et enfin sur gcc.
[^] # Des noyaux
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Un noyal
Posté par ded . Évalué à 1.
merci de tes conseils!
# comprendre le lien entre les headers du noyau et les modules
Posté par castorpilot . Évalué à 6.
Les headers sont en effet nombreux, et, c'est leur fonctions principale en C, contiennent des constantes, des structures, des prototypes de fonctions.
Les choses ne changent pas si souvent (bien que les dev noyaux se reservent le droit de modifier ces constantes, prototypes, structures ...). Par contre, il y a des ajouts (cf les depeches de patrick_g), plus frequents.
Il faut savoir egalement que le moindre changement peut avoir des consequences assez graves : un module inséré dans le noyau, et qui "planterait" à cause d'une mauvaise constante, d'un prototype de fonction mal defini, etc, c'est un kernel panic.
Apres, un module a lui seul ne va pas tout utiliser (de meme qu'un programme C n'utilise pas tous les .h de ton /usr/include !). Par contre, un module est susceptible d'utiliser au choix (en fait, selon pourquoi il est ecrit) chacun de ces en-tete.
Pour ce qui est des symboles, c'est une fonctionnalité de la programmation C, qui permet de "lier" des objets entre eux. Cela permet à un programme d'utiliser des fonctions ou des variables définies dans un autre programme. C'est le cas lorqu'on compile plusieurs fichiers .o en un seul fichier binaire, ou dans une autre mesure, lorqu'on utilise les fonctions d'une bibliotheque (par exemple, printf, dans la libC). Sous Linux, le programme qui s'occupe de faire le "lien" entre les symboles est ld, le "linker". La plupart du temps il est appelé par gcc à la fin de la compilation. On peut utilisr le programme nm pour avoir la liste des symboles presents dans un binaire.
L'idée derriere les symboles est la suivante. Lorsqu'on ecrit un programme en C, on utilise des noms pour faciliter la programmation. Par exemple, on va definir un fonction et l'appeler toto. Ces noms, bien sur, n'ont de sens que pour le programmeur. Une fois compilé vers le langage machine, notre fonction toto n'est plus qu'une serie d'octets située à une certaine adresse memoire. Pour "appeler" la fonction toto, il suffit de "sauter" à cette adresse memoire. Or pour appeler cette fonction toto depuis un autre programme, il est pratique d'utiliser le nom toto, plutot que de devoir ecrire l'adresse (que de toute façon on ne connait pas, et qui peut changer à la prochaine compilation). Quelque part dans notre programme, on stocke donc une table des symbole, qui associe à chaque nom son adresse. Lorsqu'un autre programme appele la fonction toto, le linker lit notre table des symbole, recupere l'adresse associée à toto, et remplace cet appel par un saut vers cette adresse.
Dans le noyau, les choses sont un peu differente puisqu'on se branche "à chaud". A savoir, lorsqu'on insere notre module, le noyau est deja en train de tourner. La phase de resolution des symbole ne se fait donc pas en statique (comme evoqu' plus haut), mais en "dynamique". Il n'empeche, le mecanisme est similaire. Chaque partie du noyau, chaque module est en droit de remplir la table des symboles du noyau avec les symboles de ses propres fonctions ou variables, grace à la macro EXPORT_SYMBOL .
Par exemple, la fonction printk, utilisée par tout les modules ou presque, est definie dans linux/kernel.h . Le code correspondant est ecrit dans kernel/printk.c . On remarque dans ce fichier la ligne EXPORT_SYMBOL(printk). Il y a donc dans la table des symboles du noyau une entrée contenant printk et son adresse. Lorsqu'on insere un module faisant des appels à printk, la phase de link dynamique associe ces appels à cette adresse.
Pour plus d'infos (mieux structurée !) sur la programmation noyau :
http://lwn.net/Kernel/LDD3/
[^] # Re: comprendre le lien entre les headers du noyau et les modules
Posté par ded . Évalué à 1.
donc en théorie un modules qui serais compilé pour la version précédente aurais peu de chance de posé probleme.
mais dans le doute qu'il serais possible qu'un symbole ou fonction ai pu être modifier,on préfère tout recompiler a chaque noyau.
[^] # Re: comprendre le lien entre les headers du noyau et les modules
Posté par ded . Évalué à 1.
donc en théorie un modules qui serais compilé pour la version précédente aurais peu de chance de posé probleme.
mais dans le doute qu'il serais possible qu'un symbole ou fonction ai pu être modifier,on préfère tout recompiler a chaque noyau.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.