Chapitre 2 : Building and Running Modules partie 4

[Michaël]

Discussion réservée à la traduction de la partie 4 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] XML Français rajouté, nécessite relecture technique + orthographique !

[Arnaud F.]

Loading and Unloading Modules

After the module is built, the next step is loading it into the kernel. As we?ve already pointed out, insmod does the job for you. The program loads the module code and data into the kernel, which, in turn, performs a function similar to that of ld, in that it links any unresolved symbol in the module to the symbol table of the kernel. Unlike the linker, however, the kernel doesn?t modify the module?s disk file, but rather an in-memory copy. insmod accepts a number of command-line options (for details, see the manpage), and it can assign values to parameters in your module before linking it to the current kernel. Thus, if a module is correctly designed, it can be configured at load time; load-time configuration gives the user more flexibility than compile-time configuration, which is still used sometimes. Load-time configuration is explained in the section "Module Parameters," later in this chapter.

Chargement et déchargement de modules
Après que le module soit construit, la prochaine étape est de le charger dans le noyau. Comme nous l’avons précisé, <i>insmod</i> fait le travail pour vous. Le programme charge le code du module et les données dans le noyau, qui, en fait, exécute une fonction similaire à celle du <i>ld</i>, car il lie tous les symboles non définis du module à la table des symboles du noyau. À la différence de l’éditeur de lien, cependant, le noyau ne modifie pas le fichier des disques du module, mais plutôt une copie dans la mémoire interne. <i>insmod</i> accepte un certain nombre d’options en ligne de commande (pour les détails, référez-vous aux pages <b>man</b>) et il peut assigner des valeurs aux paramètres dans votre module avant de le lier au noyau actuel. Ceci, si un module est correctement créé, peut être configuré durant le temps de chargement. La configuration du temps de chargement donne à l’utilisateur plus de souplesse par rapport à la configuration du temps de compilation, qui est encore utilisée quelques fois. La configuration du temps de chargement est expliquée dans la section « Paramètres du module », plus tard dans ce chapitre.

________________________________________________________

Interested readers may want to look at how the kernel supports insmod: it relies on a system call defined in kernel/module.c. The function sys_init_module allocates kernel memory to hold a module (this memory is allocated with vmalloc ; see the section ?vmalloc and Friends? in Chapter 8); it then copies the module text into that memory region, resolves kernel references in the module via the kernel symbol table, and calls the module?s initialization function to get everything going.

Les lecteurs intéressés peuvent jeter un œil sur la manière dont le noyau supporte <i>insmod</i>: il relie à un appel système défini dans kernel/module.c. La fonction <i>sys_init_module</i> alloue la mémoire du noyau pour garder un module en mémoire (cette mémoire est allouée avec <i>vmalloc</i>. Referez-vous à la section « vmalloc et amis » dans le chapitre 8 pour plus de détails). Il copie ensuite le texte du module dans cette région mémoire, résout des références du noyau dans le module grâce à la table des symboles du noyau et appelle la fonction d’initialisation du module pour obtenir tout qui va.

________________________________________________________

If you actually look in the kernel source, you'll find that the names of the system calls are prefixed with sys_. This is true for all system calls and no other functions; it's useful to keep this in mind when grepping for the system calls in the sources.

Si vous regardez actuellement dans les sources du noyau, vous allez trouver que le nom des appels systèmes sont préfixés par <i>sys_</i>. Ceci est vrai pour les appels systèmes et pour rien d’autre. C’est utile pour garder ça en mémoire quand vous reverrez les appels système dans les sources.

________________________________________________________

The modprobe utility is worth a quick mention. modprobe, like insmod, loads a module into the kernel. It differs in that it will look at the module to be loaded to see whether it references any symbols that are not currently defined in the kernel. If any such references are found, modprobe looks for other modules in the current module search path that define the relevant symbols. When modprobe finds those modules (which are needed by the module being loaded), it loads them into the kernel as well. If you use insmod in this situation instead, the command fails with an "unresolved symbols" message left in the system logfile.

L’utilité de <i>modprobe</i> vaut la peine d’un rapide détour. <i>modprobe</i>, comme <i>insmod</i>, charge un module dans le noyau. Il diffère dans le fait qu’il va surveiller le module à qui va être chargé pour voir s’il fait référence tous les symboles qui ne sont pas actuellement définis dans le noyau. Si de telles références sont trouvées, <i>modprobe</i> va cherche d’autres modules qui définissent les symboles appropriés dans le chemin de recherche des modules. Quand <i>modprobe</i> trouve ces modules (qui sont nécessaires au module qui vient d’être chargé), il les charge dans le noyau. Si vous utilisez <i>insmod</i> à la place dans cette situation, la commande va échouer avec le message « symbole non défini » laissé dans le système de log.

________________________________________________________

As mentioned before, modules may be removed from the kernel with the rmmod utility. Note that module removal fails if the kernel believes that the module is still in use (e.g., a program still has an open file for a device exported by the modules), or if the kernel has been configured to disallow module removal. It is possible to configure the kernel to allow "forced" removal of modules, even when they appear to be busy. If you reach a point where you are considering using this option, however, things are likely to have gone wrong badly enough that a reboot may well be the better course of action.

Comme dit précédemment, les modules peuvent être ôté du noyau avec l’utilitaire <i>rmmod</i>. Notez que le déchargement de module va échouer si le noyau croit que le module est toujours en cours d’utilisation (par exemple, un programme a encore un fichier ouvert pour un périphérique exporté par les modules), ou si le noyau a été configuré pour interdire le déchargement de module. Il est possible de configurer le noyau à autoriser le « forcing » pour le déchargement des modules, même s’ils semblent occupés. Si vous êtes sur le point ou envisagez d’utiliser cette option, cependant, les choses vont rapidement mal tournées au point qu’un redémarrage peut être la meilleure solution d’action.

________________________________________________________

The lsmod program produces a list of the modules currently loaded in the kernel. Some other information, such as any other modules making use of a specific module, is also provided. lsmod works by reading the /proc/modules virtual file. Information on currently loaded modules can also be found in the sysfs virtual filesystem under /sys/module.

Le programme <i>lsmod</i> produit une liste de modules actuellement chargée dans le noyau. Quelques autres informations sont fournies aussi, comme les autres modules qui ont besoin d’un module spécifique pour être actif. <i>lsmod</i> fonctionne en lisant le fichier virtuel <i>/proc/modules</i>. Les informations sur les modules actuellement chargés peuvent ainsi être trouvées dans le système de fichiers virtuel <i>sysfs</i> sous <i>/sys/module</i>.

[Arnaud F.]

Version Dependency

Bear in mind that your module's code has to be recompiled for each version of the kernel that it is linked to - at least, in the absence of modversions, not covered here as they are more for distribution makers than developers. Modules are strongly tied to the data structures and function prototypes defined in a particular kernel version; the interface seen by a module can change significantly from one kernel version to the next. This is especially true of development kernels, of course.

Dépendances entre les versions

Tenez compte que le code de votre module doit être recompilé pour chaque version du noyau auquel il est lié. Au moins, dans le cas d’absences de modversions, non couvert ici comme ils sont plus pour les créateurs de distributions que les développeurs. Les modules sont fortement liés aux structures de données et aux prototypes de fonctions définis dans une version de noyau particulière. L'interface vue par un module peut changer significativement d'une version de noyau à la suivante. Cela est particulièrement vrai pour le développement du noyau, bien sûr.

________________________________________________________

The kernel does not just assume that a given module has been built against the proper kernel version. One of the steps in the build process is to link your module against a file (called vermagic.o)from the current kernel tree; this object contains a fair amount of information about the kernel the module was built for, including the target kernel version, compiler version, and the settings of a number of important configuration variables. When an attempt is made to load a module, this information can be tested for compatibility with the running kernel. If things don't match, the module is not loaded; instead, you see something like :
<code langage="linux"><![CDATA[
# insmod hello.ko
Error inserting './hello.ko': -1 Invalid module format
]]>
</code>

Le noyau ne suppose pas juste qu’un module donné a été conçu contre une version appropriée du noyau. Un des grand pas dans le processus de conception est de lier le module contre un fichier (nommé <i>vermagic.o</i>) de l’arborescence actuelle du noyau. Cet objet contient une quantité exacte d’informations à propos du noyau pour lequel le module a été conçu, incluant la version du noyau, la version du compilateur et l’instauration d’un nombre important de variables de configurations. Quand une tentative de charger un module est réalisée, cette information peut être testée pour la compatibilité avec le noyau actuel. Si les choses ne correspondent pas, le module n’est pas chargé. À la place, vous voyez quelque chose du genre :
<code langage="linux"><![CDATA[
insmod hello.ko
Error inserting './hello.ko': -1 Invalid module format
]]></code>

________________________________________________________

A look in the system log file (/var/log/messages or whatever your system is configured to use) will reveal the specific problem that caused the module to fail to load.

Un regard dans le système de log (<i>/var/log/messages</i> ou indépendamment de votre système est configuré pour utiliser) va révéler le problème qui a causé l’échec du chargement.

________________________________________________________

If you need to compile a module for a specific kernel version, you will need to use the build system and source tree for that particular version. A simple change to the KERNELDIR variable in the example makefile shown previously does the trick.

Si vous avez besoin de compiler un module pour une version du noyau particulière, vous aurez besoin d’utiliser le système de construction et l’arborescence source pour cette version. Un simple changement à la variable KERNELDIR dans le makefile exemple montre l’astuce.

________________________________________________________

Kernel interfaces often change between releases. If you are writing a module that is intended to work with multiple versions of the kernel (especially if it must work across major releases), you likely have to make use of macros and #ifdef constructs to make your code build properly. This edition of this book only concerns itself with one major version of the kernel, so you do not often see version tests in our example code. But the need for them does occasionally arise. In such cases, you want to make use of the definitions found in linux/version.h. This header file, automatically included by linux/module.h, defines the following macros :

L’interface du noyau change souvent entre chaque sorties. Si vous êtes en train d’écrire un module qui est conçu pour fonctionner avec plusieurs versions du noyau (en particulier s’il doit fonctionner entre les sorties majeures), vous préférerez faire une macro et des constructions avec #ifdef pour faire construire votre code proprement. Cette édition du livre s’intéresse seulement a une version majeure du noyau, ainsi vous ne verrez pas souvent de tests de version dans nos exemples de code. Mais les besoins pour ces derniers surgissent de temps à autres. Dans de tels cas, vous vous servirez des définitions trouvées dans <i>linux/version.h</i>. Ce fichier d’entête, automatiquement inclus par <i>linx/module.h</i>, définit les macros suivantes :

________________________________________________________

<u>UTS_RELEASE :</u> This macro expands to a string describing the version of this kernel tree. For example, "2.6.10".
<u>LINUX_VERSION_CODE :</u> This macro expands to the binary representation of the kernel version, one byte for each part of the version release number. For example, the code for 2.6.10 is 132618 (i.e., 0x02060a). This allows up to 256 development versions between stable versions. With this information, you can (almost) easily determine what version of the kernel you are dealing with.
<u>KERNEL_VERSION(major,minor,release) :</u> This is the macro used to build an integer version code from the individual numbers that build up a version number. For example, KERNEL_VERSION(2,6,10) expands to 132618. This macro is very useful when you need to compare the current version and a known checkpoint.

<u>UTS_RELEASE :</u> cette macro décrie par une chaîne de caractères la version de l’arborescence de ce noyau. Par exemple, « 2.6.10 ».
<u>LINUX_VERSION_CODE :</u> cette macro s’étend à la représentation binaire de la version du noyau, un octet pour chaque partie de la version de sortie du noyau. Par exemple, le code pour 2.6.10 est 132618 (c'est-à-dire, 0x02060a). Cela permet jusqu'à 256 versions de développement entre les versions stables. Avec cette information, vous pouvez (presque) déterminer facilement quelle version du noyau vous être en train de traiter.
<u>KERNEL_VERSION(major_minor_release):</u> ceci est la macro utilisée pour construire un numéro de version sous forme d’entier à partir du numéro individuel qui désigne une nouvelle version. Par exemple, KERNEL_VERSION(2,6,10) se développe en 132618. Cette macro est très utile quand vous avez besoin de comparer la version actuelle et un point de contrôle défini.

________________________________________________________

Most dependencies based on the kernel version can be worked around with preprocessor conditionals by exploiting KERNEL_VERSION and LINUX_VERSION_CODE. Version dependency should, however, not clutter driver code with hairy #ifdef conditionals; the best way to deal with incompatibilities is by confining them to a specific header file. As a general rule, code which is explicitly version (or platform)dependent should be hidden behind a low-level macro or function. High-level code can then just call those functions without concern for the low-level details. Code written in this way tends to be easier to read and more robust.

Beaucoup de dépendances basées sur la version du noyau peuvent être peaufinées avec les préprocesseurs conditionnels en exploitant KERNEL_VERSION et LINUX_VERSION_CODE. La dépendance des versions ne devrait cependant pas encombrer le code du pilote avec les conditionnelles #ifdef. La meilleure manière pour traiter les incompatibilités est de les confiner dans un fichier d’entête particulier. En règle générale, le code qui est explicitement dépendant d’une version (ou plate-forme) devrait être caché derrière une macro bas-niveau ou une fonction. Du code de haut niveau peut alors juste appelé ces fonctions sans se soucier des détails de bas niveau. Le code écrit dans ce sens tend à être plus simple à lire et à être plus robuste.

[Arnaud F.]

Platform Dependency

Each computer platform has its peculiarities, and kernel designers are free to exploit all the peculiarities to achieve better performance in the target object file.

Dépendances de plate-forme
Chaque plate-forme a ses particularités et les créateurs de noyaux sont libres d’exploiter toutes les particularités pour atteindre de meilleures performances dans le fichier objet cible.

________________________________________________________

Unlike application developers, who must link their code with precompiled libraries and stick to conventions on parameter passing, kernel developers can dedicate some processor registers to specific roles, and they have done so. Moreover, kernel code can be optimized for a specific processor in a CPU family to get the best from the target platform: unlike applications that are often distributed in binary format, a custom compilation of the kernel can be optimized for a specific computer set.

Contrairement aux développeurs d’applications qui doivent lier leur code avec des bibliothèques précompilées et s’accrocher aux conventions de passages de paramètres, les développeurs du noyau peuvent dédier certains registres du processeur à des rôles spécifiques et ils ont fait ainsi. De plus, le code du noyau peut être optimisé pour un processeur spécifique dans une famille de CPU pour obtenir de meilleur de la plate-forme cible : contrairement aux applications qui sont souvent distribuées au format binaire, une compilation personnalisée du noyau peut être optimisée pour un jeu d’ordinateurs spécifiques.

________________________________________________________

For example, the IA32 (x86)architecture has been subdivided into several different processor types. The old 80386 processor is still supported (for now), even though its instruction set is, by modern standards, quite limited. The more modern processors in this architecture have introduced a number of new capabilities, including faster instructions for entering the kernel, interprocessor locking, copying data, etc. Newer processors can also, when operated in the correct mode, employ 36-bit (or larger)physical addresses, allowing them to address more than 4 GB of physical memory. Other processor families have seen similar improvements. The kernel, depending on various configuration options, can be built to make use of these additional features.

Par exemple, l’architecture IA32 (x86) a été sous-divisée entre différents types de processeur. L’ancien processeur 80386 est encore supporté (pour l’instant), bien que son jeu d’instructions soit, par des normes modernes, tout à fait limité. Les processeurs plus modernes dans cette architecture ont introduit un nombre de nouvelles capacités, y compris des instructions plus rapides pour accéder au noyau, le verrouillage d’interprocesseur, la copie de données, etc. Des processeurs plus récents peuvent aussi, quand ils opèrent dans le mode adéquat, employer les adresses physiques sur 36 bits (voire plus), leur autorisant plus de 4Go de mémoire physique. D’autres familles de processeurs ont des améliorations semblables. Le noyau, selon des options de configurations diverses, peut être construit pour se servir de caractéristiques supplémentaires.

________________________________________________________

Clearly, if a module is to work with a given kernel, it must be built with the same understanding of the target processor as that kernel was. Once again, the vermagic.o object comes in to play. When a module is loaded, the kernel checks the processorspecific configuration options for the module and makes sure they match the running kernel. If the module was compiled with different options, it is not loaded.

Clairement, si un module est en train de fonctionner avec un noyau donné, il doit être construit avec les mêmes compréhensions que le processeur cible comme le noyau l’était. Une fois encore, l’objet <i>vermagic.o</i> viens jouer. Quand un module est chargé, le noyau contrôle les options de configuration du processeur pour le module et s’assure qu’ils correspondent avec le noyau actuel. Si le module était compilé avec des options différentes, il n’est pas chargé.

________________________________________________________

If you are planning to write a driver for general distribution, you may well be wondering just how you can possibly support all these different variations. The best answer, of course, is to release your driver under a GPL-compatible license and contribute it to the mainline kernel. Failing that, distributing your driver in source form and a set of scripts to compile it on the user?s system may be the best answer. Some vendors have released tools to make this task easier. If you must distribute your driver in binary form, you need to look at the different kernels provided by your target distributions, and provide a version of the module for each. Be sure to take into account any errata kernels that may have been released since the distribution was produced. Then, there are licensing issues to be considered, as we discussed in the section "License Terms" in Chapter 1. As a general rule, distributing things in source form is an easier way to make your way in the world.

Si vous planifiez d’écrire un pilote pour des distributions générales, vous pouvez bien être stupéfait juste par la manière dont vous pouvez probablement supporter toutes ces différentes variations. La meilleure réponse, bien sûr, est de publié votre pilote sous une licence compatible à la licence GPL et contribuer ainsi aux principales lignes du noyau. À défaut de cela, en distribuant votre pilote sous forme de source et d’un jeu de scripts pour le compiler sur le système utilisateur peut être la meilleure solution. Quelques marchands ont publiés des outils qui rendent cette tâche plus aisée. Si vous devez distribuer votre pilote sous forme binaire, vous avez besoin de jetez un œil aux différents fournisseurs de noyaux par vos distributions souhaitées et fournir une version du module pour chacune d’elles. Soyez assuré de prendre en compte n’importe quel errata du noyau qui a pu être publié depuis que la distribution était produite. Ensuite, il y a des problèmes de licences à considérer, comme stipulé dans la section « Termes de licence » dans le chapitre 1. En règle générale, distribuer les choses sous forme de source est un moyen plus simple de faire votre chemin dans le monde.

Voilà pour cette partie

[Michaël]

il ne reste plus que la relecture orthographique

[MaliciaR]

Hé, les gars, faudrait qu'on s'y remette
Je prends le chapitre 2 pour relecture, ce sera fait d'ici vendredi

[Arnaud F.]

Envoyé par MaliciaR

Hé, les gars, faudrait qu'on s'y remette
Je prends le chapitre 2 pour relecture, ce sera fait d'ici vendredi

Bah alors, ça en est où !?

[MaliciaR]

Sur ma clé USB formatée

J'ai oublié de transférer sur mon portable et vlan. Je le refais de toute façon

[MaliciaR]

Relecture et corrections pour cette partie

*

Après que le module soit construit, la prochaine étape est de le charger dans le noyau. Comme nous l'avons précisé, <i>insmod</i> fait le travail pour vous. Le programme charge le code du module et les données dans le noyau, qui, en fait, exécute une fonction similaire à celle du <i>ld</i>, car il lie tous les symboles non définis du module à la table des symboles du noyau. À la différence de l'éditeur de lien, cependant, le noyau ne modifie pas le fichier du module sur le disque dur, mais plutôt une copie dans la mémoire interne.

deviendrait :

L'étape suivant la construction du module construit est son chargement dans le noyau. Comme nous l'avons précisé, <i>insmod</i> fait le travail pour vous. Le programme charge le code du module et les données dans le noyau. Ce dernier exécute une fonction similaire à celle du <i>ld</i> : il lie tous les symboles non définis du module à la table des symboles du noyau. Cependant, à la différence de l'éditeur de lien, le noyau ne modifie pas le fichier du module sur le disque dur, mais plutôt une copie dans la mémoire interne.

*

Si en réalité vous regardez dans les sources du noyau, vous allez trouver que le nom des appels systèmes sont préfixés par <i>sys_</i>. Ceci est vrai pour les appels systèmes et pour rien d'autre. C'est utile pour garder ça en mémoire quand vous reverrez les appels systèmes dans les sources.

deviendrait :

Vous pouvez remarquer que dans les sources du noyau, les noms des appels système sont préfixés par <i>sys_</i>. Ceci est vrai pour les appels système et pour rien d'autre. C'est utile de garder cette notation en mémoire quand vous recherchez les appels système dans les sources.

On fait un appel système et des appels système (y en a qu'un, de système ).
Sinon, je pense que "grepping" peut être traduit par "rechercher" ici. Splus proche de ce qu'on fait quand on lance un grep.


*

L'utilité de <i>modprobe</i> vaut la peine d'un rapide détour. <i>modprobe</i>, comme <i>insmod</i>, charge un module dans le noyau. Il diffère dans le fait qu'il va regarder si le module fait référence à des symboles qui ne sont pas définis actuellement dans le noyau. Si de telles références sont trouvées, <i>modprobe</i> va cherche d'autres modules qui définissent les symboles appropriés dans le chemin de recherche des modules. Quand <i>modprobe</i> trouve ces modules (qui sont nécessaires au module qui vient d'être chargé), il les charge dans le noyau. Si vous utilisez <i>insmod</i> à la place dans cette situation, la commande va échouer avec le message « symbole non défini » laissé dans le système de log.

deviendrait :

L'utilité de <i>modprobe</i> vaut la peine d'un rapide détour. <i>modprobe</i>, comme <i>insmod</i>, charge un module dans le noyau. Il y a une différence importante entre les deux : <i>modprobe</i> regardera si le module fait référence à des symboles qui ne sont pas définis actuellement dans le noyau. Si de telles références sont trouvées, <i>modprobe</i> cherchera d'autres modules qui définissent les symboles appropriés dans le chemin de recherche des modules. Quand <i>modprobe</i> trouve ces modules (nécessaires au module qui vient d'être chargé), il les charge dans le noyau. Si vous utilisez <i>insmod</i> à la place dans cette situation, la commande va échouer avec le message « symbole non défini » laissé dans le système de log.

*

Le programme <i>lsmod</i> produit une liste de modules actuellement chargés dans le noyau. Quelques autres informations sont fournies aussi, comme les autres modules qui ont besoin d'un module spécifique pour être actif. <i>lsmod</i> fonctionne en lisant le fichier virtuel <i>/proc/modules</i>. Les informations sur les modules actuellement chargés peuvent ainsi être trouvées dans le système de fichiers virtuel <i>sysfs</i> sous <i>/sys/module</i>.

deviendrait :

Le programme <i>lsmod</i> produit une liste de modules actuellement chargés dans le noyau. Quelques autres informations sont également fournies, notamment la liste des autres modules nécessitant un module spécifique pour être actifs. Vu que <i>lsmod</i> fonctionne en lisant le fichier virtuel <i>/proc/modules</i>, les informations sur les modules actuellement chargés peuvent ainsi être trouvées dans le système de fichiers virtuel <i>sysfs</i> sous <i>/sys/module</i>.

*

Tenez compte que le code de votre module doit être recompilé pour chaque version du noyau auquel il est lié, du moins, dans le cas d'absences de modversions, non couvert ici comme ils sont plus réservés pour les créateurs de distributions que les développeurs.

Tenez compte du fait que le code de votre module doit être recompilé pour chaque version du noyau auquel il est lié. Ceci est vrai du moins dans le cas d'absence de <i>modversions</i>. Cette situation n'est pas abordée ici : elles sont plutôt réservées aux créateurs de distributions qu'aux développeurs.

J'ai mis le mot "modversions" en italique (on peut le faire en gras ou whatever) pour distinguer un mot de jargon laissé tel quel. Vu que c'est précisément le cas ici et qu'il s'agit d'une remarque "en passant", je ne pense pas que ça vaille la peine de chercher une traduction appropriée.
Qu'en pensez-vous?


*

Le noyau ne suppose pas juste qu'un module donné a été conçu avec une version appropriée du noyau. Un des grand pas dans le processus de conception est de lier le module avec un fichier nommé <i>vermagic.o</i> de l'arborescence actuelle du noyau. Cet objet contient une quantité exacte d'informations à propos du noyau pour lequel le module a été conçu, incluant la version du noyau, la version du compilateur et l'instauration d'un nombre important de variables de configurations. Quand une tentative de chargement de module est réalisée, cette information peut être testée pour la compatibilité avec le noyau actuel. Si les choses ne correspondent pas, le module n'est pas chargé.

deviendrait :

Le noyau ne suppose pas uniquement qu'un module donné a été conçu avec une version appropriée du noyau. Un des grand pas dans le processus de conception est de lier le module à un fichier nommé <i>vermagic.o</i> de l'arborescence actuelle du noyau. Cet objet contient une quantité exacte d'informations à propos du noyau pour lequel le module a été conçu dont la version du noyau, la version du compilateur et l'instauration d'un nombre important de variables de configurations. Quand une tentative de chargement de module est réalisée, cette information peut être testée pour la compatibilité avec le noyau actuel. Si les choses ne correspondent pas, le module n'est pas chargé.

*

Cette édition du livre s'intéresse seulement a une version majeure du noyau, ainsi vous ne verrez pas souvent de tests de version dans nos exemples de code. Mais les besoins pour ces derniers surgissent de temps à autres.

serait mieux ainsi :

Cette édition du livre s'intéresse seulement à une version majeure du noyau, ainsi vous ne verrez pas souvent de tests de version dans nos exemples de code. Mais les besoins pour ces derniers surgissent de temps à autre.

*

cette macro s'étend à la représentation binaire de la version du noyau, un octet pour chaque partie de la version de sortie du noyau.

serait plus propre ainsi :

cette macro s'étend à la représentation binaire de la version du noyau; un octet est réservé pour chaque partie de la version de sortie du noyau.

*

La meilleure manière pour traiter les incompatibilités est de les confiner dans un fichier d'entête particulier. En règle générale, le code qui est explicitement dépendant d'une version (ou plate-forme) devrait être caché derrière une macro bas-niveau ou une fonction. Du code de haut niveau peut alors juste appelé ces fonctions sans se soucier des détails de bas niveau. Le code écrit dans ce sens tend à être plus simple à lire et à être plus robuste.

deviendrait :

La meilleure manière de traiter les incompatibilités est de les confiner dans un fichier d'entête particulier. En règle générale, le code qui est explicitement dépendant d'une version (ou plate-forme) devrait être caché derrière une macro bas niveau ou une fonction. Du code de haut niveau peut alors juste appeler ces fonctions sans se soucier des détails de bas niveau. Le code écrit dans ce sens tend à être plus simple à lire et plus robuste.

*

Contrairement aux développeurs d'applications qui doivent lier leur code avec des bibliothèques précompilées et s'accrocher aux conventions de passages de paramètres, les développeurs du noyau peuvent dédier certains registres du processeur à des rôles spécifiques et ils ont fait ainsi.

deviendrait :

Contrairement aux développeurs d'applications qui doivent lier leur code à des bibliothèques précompilées et respecter les conventions de passages de paramètres, les développeurs du noyau peuvent dédier certains registres du processeur à des rôles spécifiques. C'est ce qu'ils ont fait.

*

Par exemple, l'architecture IA32 (x86) a été sous-divisée entre différents types de processeur. L'ancien processeur 80386 est encore supporté (pour l'instant), bien que son jeu d'instructions soit, par des normes modernes, tout à fait limité. Les processeurs plus modernes dans cette architecture ont introduit un nombre de nouvelles capacités, y compris des instructions plus rapides pour accéder au noyau, le verrouillage d'interprocesseur, la copie de données, etc.

deviendrait :

Par exemple, l'architecture IA32 (x86) a été sous-divisée en différents types de processeurs. L'ancien processeur 80386 est pour l'instant supporté, bien que son jeu d'instructions soit tout à fait limité selon les normes modernes. Les processeurs plus modernes dans cette architecture ont introduit un nombre de nouvelles capacités, parmi lesquelles des instructions plus rapides pour accéder au noyau, le verrouillage d'interprocesseur, la copie de données.

*

Clairement, si un module doit fonctionner avec un noyau donné, il doit être construit avec les mêmes compréhensions du processeur cible que le noyau le fait. Une fois encore, l'objet <i>vermagic.o</i> vient jouer. Quand un module est chargé, le noyau contrôle les options de configuration du processeur pour le module et s'assure qu'ils correspondent avec le noyau actuel. Si le module était compilé avec des options différentes, il n'est pas chargé.

deviendrait :

Il est évident que, si un module doit fonctionner avec un noyau donné, il doit être construit avec les mêmes compréhensions du processeur cible que le noyau le fait. Une fois encore, l'objet <i>vermagic.o</i> a un rôle essentiel. Quand un module est chargé, le noyau contrôle les options de configuration du processeur pour le module et s'assure qu'ils sont congruents avec le noyau actuel. Si le module était compilé avec des options différentes, il n'est pas chargé.

Je ne trouve pas de mot autre pour remplacer "compréhensions", mais ça viendra


Le dernier paragraphe de ce chapitre contient quelques parties qui ne me plaisent pas vraiment, mais j'ai des trucs à faire là, donc j'y reviendrai plus tard