Chapitre 2 : Building and Running Modules partie 3

[Michaël]

Discussion réservée à la traduction de la partie 3 du chapitre 2 "Building and Running Modules"

Le pdf en anglais

Pour travailler, vous devez télécharger les xml en pièce jointe et joindre le xml une fois que vous avez fini. Vous ne devez en aucun cas toucher aux balises ni à l'indentation sinon ça va mettre la pagaille dans le xml final. J'ai utilisé kwrite comme éditeur de texte avec les paramètres par défaut.

[koopajah]

Je prends cette partie !!
Mais je commence a traduire cet aprem histoire d'être sur que personne d'autre n'a commencé !

[koopajah]

A Few Other Details

Quelques autres détails

--------------------------------------

Kernel programming differs from user-space programming in many ways. We?ll point things out as we get to them over the course of the book, but there are a few fundamental issues which, while not warranting a section of their own, are worth a mention. So, as you dig into the kernel, the following issues should be kept in mind.

La programmation du noyau diffère beaucoup de la programmation en espace utilisateur. Nous préciserons certaines choses quand nous les rencontrerons au cours de ce livre, mais il y a quelques notions fondamentales qui, bien que ne meritant pas une section particulière, doivent être mentionnées. Ainsi, quand vous creuserez dans le noyau, les notions suivantes doivent être gardées à l'esprit.

--------------------------------------

Applications are laid out in virtual memory with a very large stack area. The stack, of course, is used to hold the function call history and all automatic variables created by currently active functions. The kernel, instead, has a very small stack; it can be as small as a single, 4096-byte page. Your functions must share that stack with the entire kernel-space call chain. Thus, it is never a good idea to declare large automatic variables; if you need larger structures, you should allocate them dynamically at call time.

Les applications sont disposées en mémoire virtuelle avec une zone de pile très importante. La pile, bien sûr, est utilisée pour conserver l'historique de l'appel de la fonction et les variables automatiques créées par les fonctions actuellement actives. Le noyau, par contre, a une pile très petite; elle peut-être aussi petit qu'une unique page de 4096 octets. Vos fonctions doivent partager cette pile avec la totalité des appels en espace noyau. Ainsi, ce n'est jamais une bonne idée de déclarer de grandes variables automatiques; si vous avez besoin de structures plus grandes, vous devez les allouer dynamiquement au moment de l'appel.

--------------------------------------

Often, as you look at the kernel API, you will encounter function names starting with a double underscore (_ _). Functions so marked are generally a low-level component of the interface and should be used with caution. Essentially, the double underscore says to the programmer: "If you call this function, be sure you know what you are doing."

Souvent, quand vous regarderez l'API du noyau, vous rencontrerez des noms de fonctions commençant par un double underscore (_ _). Les fonctions marquées ainsi sont généralement des composants de bas niveau de l'interface et doivent être utilisés avec précaution. Le double underscore dit à l'utilisateur : "Si vous appelez cette fonction, soyez sûr de savoir ce que vous faîtes."

--------------------------------------

Kernel code cannot do floating point arithmetic. Enabling floating point would require that the kernel save and restore the floating point processor?s state on each entry to, and exit from, kernel space?at least, on some architectures. Given that there really is no need for floating point in kernel code, the extra overhead is not worthwhile.

Le code du noyau ne peut pas faire d'arithmétique en virgule flottante. Activer la vigule flottante nécessiterait, sur certaines architectures, que le noyau sauvegarde et reconstitue l'état du processeur à virgule flottante pour chaque entrée et chaque sortie de l'espace noyau au moins. Il n'y a donc aucun intérêt à utiliser la virgule flottante dans du code noyau, la charge supplémentaire n'en vaut pas la peine.

[koopajah]

Compiling and Loading

Compiler et charger

--------------------

The "hello world" example at the beginning of this chapter included a brief demonstration of building a module and loading it into the system. There is, of course, a lot more to that whole process than we have seen so far. This section provides more detail on how a module author turns source code into an executing subsystem within the kernel.

L'exemple "hello world" présenté au début de ce chapitre contient une démonstration rapide de la compilation d'un module et de son chargement dans le système. Il y a, bien sûr, beaucoup plus de choses que ce que nous avons vu jusqu'ici. Cette section donne plus de détails sur comment un module transforme du code source en un sous-système exécuté à l'intérieur du noyau.

----------------------

Compiling Modules

Compiler des modules

----------------------

As the first step, we need to look a bit at how modules must be built. The build process for modules differs significantly from that used for user-space applications; the kernel is a large, standalone program with detailed and explicit requirements on how its pieces are put together. The build process also differs from how things were done with previous versions of the kernel; the new build system is simpler to use and produces more correct results, but it looks very different from what came before. The kernel build system is a complex beast, and we just look at a tiny piece of it. The files found in the Documentation/kbuild directory in the kernel source are required reading for anybody wanting to understand all that is really going on beneath the surface.

Comme première étape, nous avons besoin de regarder un peu la manière dont les modules sont compilés. Le processus de compilation pour des modules diffère de manière significative de celui utilisé pour des applications en espace utilisateur; le noyau est un vaste programme autonome avec des conditions détaillées et explicites sur la manière dont les pièces sont assemblées. Le processus de compilation diffère aussi de la manière dont les choses étaient faites dans les versions précédentes du noyau. Le nouveau système de compilation est plus simple à utiliser et produit plus de résultats corrects mais il a l'air très différent de ce qui existait auparavant. Le système de compilation du noyau est une bête complexe et nous en avons juste regardé une toute petite pièce. Les fichiers trouvés dans le répertoire Documentation/kbuild dans le code source du noyau nécessitent une lecture de quiconque souhaitant comprendre tout ce qui se passe sous la surface.

---------------------

There are some prerequisites that you must get out of the way before you can build kernel modules. The first is to ensure that you have sufficiently current versions of the compiler, module utilities, and other necessary tools. The file Documentation/Changes in the kernel documentation directory always lists the required tool versions; you should consult it before going any further. Trying to build a kernel (and its modules) with the wrong tool versions can lead to no end of subtle, difficult problems. Note that, occasionally, a version of the compiler that is too new can be just as problematic as one that is too old; the kernel source makes a great many assumptions about the compiler, and new releases can sometimes break things for a while.

Il y a des prérequis que vous devez respecter avant de pouvoir compiler des modules pour le noyau. Le premier est de vous assurer que vous avez des versions actualisées du compilateur, des utilitaires pour les modules et de tous les autres outils nécessaires. Le fichier Documentation/Changes dans le répertoire de la documentation du noyau liste toujours les versions nécessaires des outils; vous devriez la consulter avant d'aller plus loin. Essayer de compiler un noyau (et ses modules) avec les mauvaises versions des outils peut conduire à une suite sans fin de problèmes subtiles et difficiles. Notez que, occasionnellement, une version du compilateur trop récente peut être aussi problématique qu'une version trop ancienne; le code source du noyau fait un grand nombre d'hypothèses à propos du compilateur et des versions récentes peuvent parfois casser certaines choses pendant quelques temps.

[koopajah]

If you still do not have a kernel tree handy, or have not yet configured and built that kernel, now is the time to go do it. You cannot build loadable modules for a 2.6 kernel without this tree on your filesystem. It is also helpful (though not required)to be actually running the kernel that you are building for.

Si vous n'avez pas encore une arborescence du noyau utilisable ou que vous n'avez pas encore configuré et compilé ce noyau, le moment est venu de le faire. Vous ne pouvez pas compiler des modules chargeables pour un noyau 2.6 sans avoir cette arborescence dans votre système de fichiers. Il est utile aussi (bien que pas indispensable) de faire tourner le noyau pour lequel vous compilez.

-----------------------------------

Once you have everything set up, creating a makefile for your module is straightforward. In fact, for the "hello world" example shown earlier in this chapter, a single line will suffice :

Une fois que tout est configuré, créer un fichier de compilation est assez simple. En fait, pour l'exemple "hello world" présenté plus tôt dans ce chapitre, une simple ligne suffira :

-----------------------------------

Readers who are familiar with make, but not with the 2.6 kernel build system, are likely to be wondering how this makefile works. The above line is not how a traditional makefile looks, after all. The answer, of course, is that the kernel build system handles the rest. The assignment above (which takes advantage of the extended syntax provided by GNU make)states that there is one module to be built from the object file hello.o. The resulting module is named hello.ko after being built from the object file.

Les lecteurs familiers de make mais pas du système de compilation du noyau 2.6 doivent se demander comment ce fichier de compilation fonctionne. La ligne ci-dessus ne ressemble pas à un fichier de compilation traditionnel après tout. La réponse, bien sûr, est que le système de compilation du noyau gère le reste. L'instruction ci-dessus (qui prend avantage de la syntaxe étendue fournie par GNU make) indique qu'il y a un module à construire du fichier objet hello.o. Le module résultant est nommé hello.ko après avoir été compilé à partir fichier objet.

-----------------------------------

If, instead, you have a module called module.ko that is generated from two source files (called, say, file1.c and file2.c), the correct incantation would be :

Si, à la place, vous avez un module appelé module.ko qui est généré à partir de deux fichiers sources (appelés, disons, fichier1.c et fichier2.c) l'instruction correcte serait :

-----------------------------------

For a makefile like those shown above to work, it must be invoked within the context of the larger kernel build system. If your kernel source tree is located in, say, your ~/kernel-2.6 directory, the make command required to build your module (typed in the directory containing the module source and makefile) would be :

Pour qu'un fichier de compilation comme ceux montrés ci-dessus fonctionne, il doit être appelé dans le contexte, plus grand, du système de compilation du noyau. Si votre arborescence du noyau est située dans, disons, votre répertoire ~/kernel-2.6, la commande make nécessaire pour compiler votre module (tapée dans le répertoire contenant le code source du module et le fichier de compilation) serait :

[koopajah]

This command starts by changing its directory to the one provided with the -C option (that is, your kernel source directory). There it finds the kernel's top-level makefile. The M= option causes that makefile to move back into your module source directory before trying to build the modules target. This target, in turn, refers to the list of modules found in the obj-m variable, which we've set to module.o in our examples.

Cette commande commence par changer de répertoire pour celui fourni grâce à l'option -C (c'est à dire votre répertoire contenant le code source du noyau). Il y trouve alors le fichier de compilation de plus haut-niveau du noyau. L'option M= force le fichier de compilation à revenir dans le répertoire du code source du module avant d'essayer de compiler les modules cibles. Cette cible, à son turn, fait référence à la liste des modules trouvés dans la variable obj-m, que nous avons affectée à module.o dans nos exemples.

-------------------------

Typing the previous make command can get tiresome after a while, so the kernel developers have developed a sort of makefile idiom, which makes life easier for those building modules outside of the kernel tree. The trick is to write your makefile as follows :

Taper la commande make vue ci-dessus peut être fatiguant au bout d'un certain. Les développeurs du noyau ont donc développé une sorte de langage de fichier de compilation, qui rend la vie plus facile à ceux qui compilent des modules en dehors de l'arborescence du noyau. L'astuce est d'écrire ses fichiers de compilation comme suit :

--------------------------

# If KERNELRELEASE is defined, we've been invoked from the
# kernel build system and can use its language. ifneq ($(KERNELRELEASE),)
obj-m := hello.o
# Otherwise we were called directly from the command
# line; invoke the kernel build system.
else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
endif

# Si KERNELRELEASE est défini, nous avons été appelé depuis
# le système de compilation du noyau et nous pouvons utiliser
# son langage.
ifneq ($(KERNELRELEASE),)
obj-m := hello.o

# Sinon nous avons été appelé directement depuis la ligne
# de commande; nous invoquons le système de compilation
else

KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

endif

-----------------------------

Once again, we are seeing the extended GNU make syntax in action. This makefile is read twice on a typical build. When the makefile is invoked from the command line, it notices that the KERNELRELEASE variable has not been set. It locates the kernel source directory by taking advantage of the fact that the symbolic link build in the installed modules directory points back at the kernel build tree. If you are not actually running the kernel that you are building for, you can supply a KERNELDIR= option on the command line, set the KERNELDIR environment variable, or rewrite the line that sets KERNELDIR in the makefile. Once the kernel source tree has been found, the makefile invokes the default: target, which runs a second make command (parameterized in the makefile as $(MAKE)) to invoke the kernel build system as described previously.

Une fois encore, nous voyons la syntaxe étendue de GNU make en action. Ce fichier de compilation est lu deux fois pour une compilation normale. Quand le fichier de compilation est appelé depuis la ligne de commande, il se rend compte que la variable KERNELRELEASE n'est pas initialisée. Il localise le répertoire du code source du noyau en prenant avantage du fait qu'un lien symbolique construit dans le répertoire des modules installés renvoie vers l'arborescence du noyau. Si vous n'êtes pas en train de faire tourner le noyau pour lequel vous compilez, vous pouvez fourni une option KERNELDIR= dans la ligne de commande, affecter la variable d'environnement KERNELDIR ou réécrire les lignes qui affectent la valeur à KERNELDIR dans le fichier de compilation. Une fois que l'arborescence du noyau a été trouvée, le fichier de compilation appelle la cible default: qui lance une seconde commande make (paramétrée dans le fichier de compilation par $(MAKE)) pour appeler le système de compilation du noyau comme décrit précédemment.

---------------------------------

On the second reading, the makefile sets obj-m, and the kernel makefiles take care of actually building the module. This mechanism for building modules may strike you as a bit unwieldy and obscure. Once you get used to it, however, you will likely appreciate the capabilities that have been programmed into the kernel build system. Do note that the above is not a complete makefile; a real makefile includes the usual sort of targets for cleaning up unneeded files, installing modules, etc. See the makefiles in the example source directory for a complete example.

A la seconde lecture, le fichier de compilation définit obj-m et les fichiers de compilation du noyau s'occuppend de compiler le module. Ce mécanisme de compilation des modules peut vous sembler obscur et difficile à utiliser. Une fois que vous y êtes habitué, cependant, vous apprécierez fortement les possibilités qui ont été programmées dans le système de compilation du noyau. Notez que le fichier de compilation présenté ci-dessus n'est pas complet; un vrai fichier de compilation inclut les cibles habituelles pour nettoyer les fichiers non utilisés, installer les modules, etc. Voyez les fichiers de compilation dans le répertoire d'exemples des sources du noyau pour un exemple complet.

[koopajah]

Le fichier XML correspondant à la traduction actuelle

[Michaël]

il ne reste plus que la relecture orthographique

[MaliciaR]

Envoyé par Michaël

il ne reste plus que la relecture orthographique

Bouh, ca fait un moment

Je reprends les choses a partir de la semaine prochaine (quand les exams seront termines )

[Arnaud F.]

Envoyé par MaliciaR

Bouh, ca fait un moment

Je reprends les choses a partir de la semaine prochaine (quand les exams seront termines )

[MaliciaR]

Bon, Pinailleuse est de retour du pays des mechants profs de genetique


*

La programmation du noyau diffère beaucoup de la programmation en espace utilisateur. Nous préciserons certaines choses quand nous les rencontrerons au cours de ce livre, mais il y a quelques notions fondamentales qui, bien que ne meritant pas une section particulière, doivent être mentionnées. Ainsi, quand vous creuserez dans le noyau, les notions suivantes doivent être gardées à l'esprit.

deviendrait :

La programmation du noyau diffère beaucoup de la programmation en espace utilisateur. Nous préciserons les notions nécessaires lorsque nous les rencontrerons au cours de ce livre.
Néanmoins, il y a quelques points fondamentaux qui ne méritent pas une section particulière, mais doivent être mentionnés. Ainsi, vous les garderez à l'esprit quand vous creuserez dans le noyau.

*

(...); elle peut-être aussi petit qu'une unique page de 4096 octets.

Et sans les fautes de frappe :

(...); elle peut être aussi petite qu'une unique page de 4096 octets.

*

"Si vous appelez cette fonction, soyez sûr de savoir ce que vous faîtes."

Grrrr, vous vous plaignez apres qu'il n'y a pas beaucoup de filles en info Vous les ignorez...

"Si vous appelez cette fonction, soyez sûr(e) de savoir ce que vous faites."

* Dans la section IV-4-1, enlever le titre anglais :

Compiler des modules Compiling Modules

->

Compiler des modules

*

Comme première étape, nous avons besoin de regarder un peu la manière dont les modules sont compilés. Le processus de compilation pour des modules diffère de manière significative de celui utilisé pour des applications en espace utilisateur; le noyau est un vaste programme autonome avec des conditions détaillées et explicites sur la manière dont les pièces sont assemblées. Le processus de compilation diffère aussi de la manière dont les choses étaient faites dans les versions précédentes du noyau. Le nouveau système de compilation est plus simple à utiliser et produit plus de résultats corrects mais il a l'air très différent de ce qui existait auparavant. Le système de compilation du noyau est une bête complexe et nous en avons juste regardé une toute petite pièce. Les fichiers trouvés dans le répertoire Documentation/kbuild dans le code source du noyau nécessitent une lecture de quiconque souhaitant comprendre tout ce qui se passe sous la surface.

Avec quelques bebetes en moins :

Comme première étape nous avons besoin de regarder un peu la manière dont les modules sont compilés. Le processus de compilation pour des modules diffère de manière significative de celui utilisé pour des applications en espace utilisateur. En effet, le noyau est un vaste programme autonome avec des conditions détaillées et explicites sur la manière dont les pièces sont assemblées. Le processus de compilation diffère aussi des versions précédentes du noyau. Le nouveau système de compilation est plus simple à utiliser et produit plus de résultats corrects mais il a l'air très différent de ce qui existait auparavant. Le système de compilation du noyau est une bête complexe et nous en avons juste regardé une toute petite partie. Les fichiers trouvés dans le répertoire Documentation/kbuild dans le code source du noyau nécessitent une lecture de quiconque souhaitant comprendre tout ce qui se passe sous la surface.

*

Il est utile aussi (bien que pas indispensable) de faire tourner le noyau pour lequel vous compilez.

Ca conviendrait de mettre "dispensable" a la place de "pas indispensable"?


*

Le module résultant est nommé hello.ko après avoir été compilé à partir fichier objet.

-> à partir du fichier


*

Cette commande commence par changer de répertoire pour celui fourni grâce à l'option -C (c'est à dire votre répertoire contenant le code source du noyau). Il y trouve alors le fichier de compilation de plus haut-niveau du noyau. L'option M= force le fichier de compilation à revenir dans le répertoire du code source du module avant d'essayer de compiler les modules cibles. Cette cible, à son turn, fait référence à la liste des modules trouvés dans la variable obj-m, que nous avons affectée à module.o dans nos exemples.

Un peu de cosmetique :

Cette commande commence par changer de répertoire pour celui fourni grâce à l'option -C (c'est-à-dire votre répertoire contenant le code source du noyau). Il y trouve alors le fichier de compilation de plus haut niveau du noyau. L'option M= force le fichier de compilation à revenir dans le répertoire du code source du module avant d'essayer de compiler les modules cibles. Cette cible, à son tour, fait référence à la liste des modules trouvés dans la variable obj-m, que nous avons affectée à module.o dans nos exemples.

*

Taper la commande make vue ci-dessus peut être fatiguant au bout d'un certain.

-> au bout d'un certain temps


*

nous avons été appelé

(dans les commentaires du code) -> nous avons été appelés


*

Si vous n'êtes pas en train de faire tourner le noyau pour lequel vous compilez, vous pouvez fourni une option KERNELDIR= dans la ligne de commande, affecter la variable d'environnement KERNELDIR ou réécrire les lignes qui affectent la valeur à KERNELDIR dans le fichier de compilation. Une fois que l'arborescence du noyau a été trouvée, le fichier de compilation appelle la cible default: qui lance une seconde commande make (paramétrée dans le fichier de compilation par $(MAKE)) pour appeler le système de compilation du noyau comme décrit précédemment.

deviendrait :

Si vous n'êtes pas en train de faire tourner le noyau pour lequel vous compilez, vous pouvez fournir une option KERNELDIR= dans la ligne de commande, affecter la variable d'environnement KERNELDIR ou réécrire les lignes qui affectent la valeur à KERNELDIR dans le fichier de compilation. Une fois l'arborescence du noyau trouvée, le fichier de compilation appelle la cible default: qui lance une seconde commande make (paramétrée dans le fichier de compilation par $(MAKE)) pour appeler le système de compilation du noyau comme décrit précédemment.

*

Une fois que vous y êtes habitué, cependant, vous apprécierez fortement les possibilités qui ont été programmées dans le système de compilation du noyau. Notez que le fichier de compilation présenté ci-dessus n'est pas complet; un vrai fichier de compilation inclut les cibles habituelles pour nettoyer les fichiers non utilisés, installer les modules, etc. Voyez les fichiers de compilation dans le répertoire d'exemples des sources du noyau pour un exemple complet.

deviendrait :

Cependant, une fois que vous y êtes habitué(e), vous apprécierez fortement les possibilités qui ont été programmées dans le système de compilation du noyau. Notez que le fichier de compilation présenté ci-dessus n'est pas complet : un vrai fichier de compilation inclut les cibles habituelles pour nettoyer les fichiers non utilisés, installer les modules, etc. Vous pouvez voir les fichiers de compilation dans le répertoire d'exemples des sources du noyau pour avoir une vision complète.

A bientot pour la suite