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