Discussion :

[Micha�l]

Discussion r�serv�e � la traduction de la partie 5 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.



[edit] Relecture technique demand�e

[Arnaud F.]

Livraison express

The Kernel Symbol Table

La table des symboles du noyau

---

We've seen how insmod resolves undefined symbols against the table of public kernel symbols. The table contains the addresses of global kernel items - functions and variables - that are needed to implement modularized drivers. When a module is loaded, any symbol exported by the module becomes part of the kernel symbol table. In the usual case, a module implements its own functionality without the need to export any symbols at all. You need to export symbols, however, whenever other modules may benefit from using them.

Nous avons vu comment <i>insmod</i> r�soud les symboles non d�finis contrairement � la table des symboles publics du noyau. La table contient les adresses des points globaux du noyau - fonctions et variables - qui sont n�cessaires pour impl�menter des pilotes modulaires. Quand un module est charg�, n'importe quel symbole export� par le module devient partie int�grante de la table des symboles du noyau. Dans les cas inhabituels, un module impl�mente ses propres fonctionnalit�s sans avoir besoin d'exporter aucun symbole � tous. Cependant, vous avez besoin d'exporter les symboles toutes les fois que les autres modules peuvent b�n�ficier de leurs utilisations.

---

New modules can use symbols exported by your module, and you can stack new modules on top of other modules. Module stacking is implemented in the mainstream kernel sources as well : the msdos filesystem relies on symbols exported by the fat module, and each input USB device module stacks on the usbcore and input modules.

Les nouveaux modules peuvent utiliser export�s par votre modules et vous pouvez empiler les nouveaux modules en amont d'autres modules. L'empilement de modules est d�j� impl�ment� dans la branche principale des sources du noyau : le syst�me de fichier <i>msdos</i> compte sur les symboles export�s par le module <i>fat</i> et chaque p�riph�rique d'entr�e USB empile sur l'usbcore et les modules d'entr�s.

---

Module stacking is useful in complex projects. If a new abstraction is implemented in the form of a device driver, it might offer a plug for hardware-specific implementations. For example, the video-for-linux set of drivers is split into a generic module that exports symbols used by lower-level device drivers for specific hardware. According to your setup, you load the generic video module and the specific module for your installed hardware. Support for parallel ports and the wide variety of attachable devices is handled in the same way, as is the USB kernel subsystem. Stacking in the parallel port subsystem is shown in Figure 2-2; the arrows show the communications between the modules and with the kernel programming interface.

L'empilement de module est utile dans des projets complexes. Si une nouvelle abstraction est impl�ment�e dans le corps d'un nouveau module de p�riph�rique, il peut offrir un branchement pour des impl�mentations de mat�riel sp�cifique. Par exemple, le jeu de modules <i>video-for-linux</i> est s�par� dans un module g�n�rique qui exporte les symboles utilis�s par les pilotes de p�riph�riques bas-niveau pour du mat�riel sp�cifique. Selon votre installation, vous chargez le module vid�o g�n�rique et le module sp�cifique � votre mat�riel install�. Le support pour le port parall�le et la vari�t� �tendue de p�riph�riques connectable est trait� de la m�me mani�re que dans le sous-syst�me USB du noyau. L'empilement dans le sous-syt�me du port parall�le est montr� sur la figure 2-2. Les fl�ches montrent les communications entre les modules et l'interface de programmation du noyau.

---

When using stacked modules, it is helpful to be aware of the modprobe utility. As we described earlier, modprobe functions in much the same way as insmod, but it also loads any other modules that are required by the module you want to load. Thus, one modprobe command can sometimes replace several invocations of insmod (although you?ll still need insmod when loading your own modules from the current directory, because modprobe looks only in the standard installed module directories).

Quand vous utilisez des modules empil�s, il est utile d'�tre conscient de l'utilit� de <i>modprobe</i>. Comme nous avons d�crit pr�c�demment, la fonction <i>modprobe</i> fonctionne presque de la m�me mani�re que <i>insmod</i>, mais il charge �galement tout les autres modules qui sont requis par le module que vous voulez charger. De cette mani�re, un seul appel de la commande <i>modprobe</i> peut parfois remplacer plusieurs appels � <i>insmod</i> (bien que vous ayez toujours besoin de <i>insmod</i> quand vous chargez vos propres modules du r�pertoire courant car <i>modprobe</i> ne cherche les modules que dans les r�pertoires o� ils sont install�s � la base).

---

Using stacking to split modules into multiple layers can help reduce development time by simplifying each layer. This is similar to the separation between mechanism and policy that we discussed in Chapter 1.

Utiliser l'empilement pour s�parer les modules en de multiples couches peut aider � r�duire le temps de d�veloppement par simplification de chaque couche. Ceci est similaire � la s�paration entre le m�canisme et la politique dont nous avons d�battu dans le chapitre 1.

---

The Linux kernel header files provide a convenient way to manage the visibility of your symbols, thus reducing namespace pollution (filling the namespace with names that may conflict with those defined elsewhere in the kernel)and promoting proper information hiding. If your module needs to export symbols for other modules to use, the following macros should be used.

Les fichiers d'en-t�te du noyau fournissent un chemin pratique pour g�rer la visibilit� de vos symboles, r�duisant ainsi namespace pollution

---

Either of the above macros makes the given symbol available outside the module. The _GPL version makes the symbol available to GPL-licensed modules only. Symbols must be exported in the global part of the module's file, outside of any function, because the macros expand to the declaration of a special-purpose variable that is expected to be accessible globally. This variable is stored in a special part of the module executible (an "ELF section")that is used by the kernel at load time to find the variables exported by the module. (Interested readers can look at &lt;linux/module.h&gt; for the details, even though the details are not needed to make things work.)

L'une ou l'autre des macros ci-dessus rend les symboles donn�s disponible � l'ext�rieur du module. La version <b>_GPL</b> rend les symboles disponibles pour les modules sous licence GPL seulement. Les symboles doivent �tre import�s dans la partie globale du fichier du module, � l'ext�rieur de toute fonction, car les macros s'�tendent � la d�claration [b]of a special-purpose variable that is expected[b] � �tre accessible globalement. Cette variable est stock�e dans une partie sp�ciale du module ex�cutable ( une "ELF section") qui est utilis�e par le noyau lors du chargement pour trouver les variables export�es par le module. (Les lecteurs int�ress�s peuvent regarder &lt;linux/module.h&gt; pour les d�tails, m�me si les d�tails ne sont pas n�cessaires pour faire fonctionner les choses.)

---

Preliminaries

Pr�liminaires

---

We are getting closer to looking at some actual module code. But first, we need to look at some other things that need to appear in your module source files. The kernel is a unique environment, and it imposes its own requirements on code that would interface with it.

Nous allons regarder de plus pr�s certaines parties du code du module ci-pr�sent. Mais d'abord, nous devons regarder certaines autres choses qui n�cessite d'appara�tre dans votre fichier source du module. Le noyau est un environnement unique et il impose ces propres exigences de code qu'il interface avec �a.

---

Most kernel code ends up including a fairly large number of header files to get definitions of functions, data types, and variables. We'll examine these files as we come to them, but there are a few that are specific to modules, and must appear in every loadable module. Thus, just about all module code has the following :

La plupart du code du noyau termine d'inclure un assez grand nombre de fichiers d'en-t�tes pour recevoir les d�finitions des fonctions, des types de donn�es et des variables. Nous examinerons ces fichiers quand nous y arriverons, mais il y a quelques-uns qui sont sp�cifiques aux modules et doivent appara�tre dans chaque module chargeable. Ainsi, � peu pr�s tous le code du module � la chose suivante :

---

module.h contains a great many definitions of symbols and functions needed by loadable modules. You need init.h to specify your initialization and cleanup functions, as we saw in the "hello world" example above, and which we revisit in the next section. Most modules also include moduleparam.h to enable the passing of parameters to the module at load time; we will get to that shortly.

<i>module.h</i> contient un grand nombre de d�finitions de symboles et fonctions n�cessaires par les modules chargeables. Vous avez besoin de <i>init.h</i> pour sp�cifier votre fonction d'initialisation et de nettoyage, comme nous avons vu dans l'exemple "Hello World" ci-dessus, lequel nous revisiterons dans la prochaine section. La plupart des modules incluent ainsi <i>moduleparam.h</i> pour autoriser le passage de param�tres au module lors du temps de chargement. Nous y arriverons bient�t.

---

It is not strictly necessary, but your module really should specify which license applies to its code. Doing so is just a matter of including a MODULE_LICENSE line :

Ce n'est pas n�cessaire, mais votre module devrait r�ellement sp�cifier quelle licence est appliqu�e � son code. Le faire est une juste une question d'inclure une ligne <b>MODULE_LICENSE</b> :

---

The specific licenses recognized by the kernel are "GPL" (for any version of the GNU General Public License), "GPL v2" (for GPL version two only), "GPL and additional rights", "Dual BSD/GPL", "Dual MPL/GPL", and "Proprietary". Unless your module is explicitly marked as being under a free license recognized by the kernel, it is assumed to be proprietary, and the kernel is ?tainted? when the module is loaded. As we mentioned in the section "License Terms" in Chapter 1, kernel developers tend to be unenthusiastic about helping users who experience problems after loading proprietary modules.

Les licences sp�cifiques reconnues par le noyau sont "GPL" (pour n'importe quelle version de GNU General Public License), "GPL v2" (pour GPL version deux uniquement), "GPL and additional rights", "Dual BSD/GPL", "Dual MPL/GPL", et "Proprietary". � moins que votre module soit explicitement estampill� par une licence libre reconnue par le noyau, il est suppos� �tre sous licence propri�taire et votre module est 'infect�' quand le module est charg�. Comme nous l'avons mentionn� dans la section "Termes de licence" dans le chapitre 1, les d�veloppeurs du noyau ne sont pas tr�s enthousiaste envers les utilisateurs qui rencontrent des probl�mes apr�s avoir charg� un module propri�taire.

---

Other descriptive definitions that can be contained within a module include MODULE_AUTHOR (stating who wrote the module), MODULE_DESCRIPTION (a human-readable statement of what the module does), MODULE_VERSION (for a code revision number; see the comments in &lt;linux/module.h&gt; for the conventions to use in creating version strings), MODULE_ALIAS (another name by which this module can be known), and MODULE_DEVICE_TABLE (to tell user space about which devices the module supports). We'll discuss MODULE_ALIAS in Chapter 11 and MODULE_DEVICE_TABLE in Chapter 12.

D'autre d�finitions descriptives peuvent �tre contenues � l'int�rieur du module incluant <b>MODULE_AUTHOR</b> (d�signant le codeur du module), <b>MODULE_DESCRIPTION</b> (une d�claration compr�hensible par l'homme sur ce que le module fait), MODULE_VERSION (pour un num�ro de r�vision, voir les commentaires dans &lt;linux/module.h&gt; pour les conventions � utiliser quant � la cr�ation d'une cha�ne de caract�res pour la version), <b>MODULE_ALIAS</b> (un autre nom sous lequel le module peut �tre connu), et <b>MODULE_DEVICE_TABLE</b> (pour dire � l'espace utilisateur quel p�riph�rique supporte le module). Nous discuterons de <b>MODULE_ALIAS</b> dans le chapitre 11 et de <b>MODULE_DEVICE_TABLE</b> dans le chapitre 12.

---

The various MODULE_ declarations can appear anywhere within your source file outside of a function. A relatively recent convention in kernel code, however, is to put these declarations at the end of the file.

Les diff�rentes d�clarations <b>MODULE_</b> peuvent appara�tre n'import o� � l'int�rieur de votre fichier source � l'ext�rieur d'une fonction. Une convention relativement r�cente dans le code du noyau consiste � mettre ces d�clarations � la fin du fichier.

[Micha�l]

il ne reste plus que la relecture orthographique