Chapitre 2 : Building and Running Modules partie 2

[Michaël]

Discussion réservée à la traduction de la partie 2 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.

[Michaël]

je prends cette partie

[Michaël]

Before we go further, it's worth underlining the various differences between a kernel module and an application.

Avant de continuer, il est important de souligner les différences entre un module du noyau et une application.

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

While most small and medium-sized applications perform a single task from beginning to end, every kernel module just registers itself in order to serve future requests, and its initialization function terminates immediately. In other words, the task of the module's initialization function is to prepare for later invocation of the module's functions; it's as though the module were saying, "Here I am, and this is what I can do." The module's exit function (hello_exit in the example) gets invoked just before the module is unloaded. It should tell the kernel, "I'm not there anymore; don't ask me to do anything else." This kind of approach to programming is similar to event-driven programming, but while not all applications are event-driven, each and every kernel module is. Another major difference between event-driven applications and kernel code is in the exit function: whereas an application that terminates can be lazy in releasing resources or avoids clean up altogether, the exit function of a module must carefully undo everything the init function built up, or the pieces remain around until the system is rebooted.

Tandis que la plupart des petites et moyennes applications réalisent une tâche unique du début à la fin, chaque module du noyau se déclare lui-même dans le but d'exécuter des requêtes futures, et sa fonction d'initialisation se finit immédiatement. En d'autres termes, la tâche de la fonction d'initialisation du module est de le préparer à une utilisation ultérieure des fonctions du module; c'est comme si le module disait : "Je suis présent, voici ce que je peux faire". La fonction de fin du module (hello_exit dans l'exemple) est appelée juste avant que le module soit déchargé. Il pourrait dire au noyau : "Je ne suis plus là, ce n'est plus la peine de me demander quoi que ce soit". Cette approche de programmation est similaire à la programmation événementielle, mais tandis que toutes les applications ne sont pas événementielles, chaque module du noyau l'est. Une autre différence majeure entre les application événementielles et du code noyau se trouve dans la fonction de fin : alors qu'une application qui se termine peut ne pas libérer les ressources ou ne nettoie pas tout à fait, la fonction de fin d'un module doit soigneusement défaire tout ce que la fonction d'initialisation a fait, sinon des morceaux resteront jusqu'à ce que le système soit redémarré.

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

Incidentally, the ability to unload a module is one of the features of modularization that you'll most appreciate, because it helps cut down development time; you can test successive versions of your new driver without going through the lengthy shutdown/reboot cycle each time.

Par ailleurs, la possibilité de décharger un module est une des fonctionnalités de la modularisation que vous allez le plus apprécier parce qu'elle aide à réduire les temps de développement; vous pouvez tester des versions successives de votre nouveau pilote sans avoir à passer par un cycle d'arrêt/redémarrage lent à chaque fois.

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

As a programmer, you know that an application can call functions it doesn?t define: the linking stage resolves external references using the appropriate library of functions. printf is one of those callable functions and is defined in libc. A module, on the other hand, is linked only to the kernel, and the only functions it can call are the ones exported by the kernel; there are no libraries to link to. The printk function used in hello.c earlier, for example, is the version of printf defined within the kernel and exported to modules. It behaves similarly to the original function, with a few minor differences, the main one being lack of floating-point support.

En tant que programmeur, vous savez qu'une application peut appeler des fonctions qu'elle ne définit pas : l'étape d'édition des liens résoud les appels externes en utilisant la bibliothèque de fonctions appropriée. printf est une des fonctions appelable et déclarée dans la libc. D'un autre côté, un module est uniquement lié avec le noyau, et les seules fonctions qu'il peut appeler sont celles exportées par le noyau; il n'y a aucune bibliothèque à lier. La fonction printk utilisée précédemment dans hello.c, par exemple, est la version de printf définie dans le noyau et exportée aux modules. Elle se comporte comme la fonction d'origine mais avec quelques différences mineures, la principale étant le manque du support des nombres à virgule flottante.

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

Figure 2-1 shows how function calls and function pointers are used in a module to add new functionality to a running kernel.

L'illustration 2-1 montre comment les appels de fonction et les pointeurs de fonction sont utilisés dans un module afin d'ajouter des nouvelles fonctionnalités au noyau

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

Because no library is linked to modules, source files should never include the usual header files, <stdarg.h> and very special situations being the only exceptions. Only functions that are actually part of the kernel itself may be used in kernel modules. Anything related to the kernel is declared in headers found in the kernel source tree you have set up and configured; most of the relevant headers live in include/linux and include/asm, but other subdirectories of include have been added to host material associated to specific kernel subsystems.

Étant donné qu'aucune bibliothèque est liée aux modules, les fichiers sources ne devraient jamais inclure les entêtes courant, <stdarg.h> et certaines situations spécifiques sont les seules exceptions. Seules les fonctions faisant réellement partie du noyau lui-même peuvent être utilisées dans les modules. Tout ce qui est relatif au noyau est déclaré dans les entêtes que l'on peut trouver dans l'arborescence des sources du noyau que vous avez installée et configurée; la plupart des entêtes courants sont situés dans include/linux et include/asm, but other subdirectories of include have been added to host material associated to specific kernel subsystems.

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

The role of individual kernel headers is introduced throughout the book as each of them is needed.

Le rôle de chaque entête du noyau est expliqué à travers le livre quand on a besoin d'une entête en particulier.

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

Another important difference between kernel programming and application programming is in how each environment handles faults: whereas a segmentation fault is harmless during application development and a debugger can always be used to trace the error to the problem in the source code, a kernel fault kills the current process at least, if not the whole system. We see how to trace kernel errors in Chapter 4.

Une autre différence importante entre la programmation du noyau et la programmation des applications réside sur comment chaque environnement gère les erreurs : alors qu'une erreur de segmentation est inoffensive dans le développement d'applications et un débugger peut toujours être utilisé pour tracer l'erreur jusqu'au problème dans le code source, une erreur du noyau tue le processus courant si ce n'est pas le système entier. Nous verrons comment tracer les erreurs du noyau dans le chapitre 4.

[Michaël]

A module runs in kernel space, whereas applications run in user space. This concept is at the base of operating systems theory.

Un module est lancé dans l'espace noyau alors qu'une application est exécutée dans l'espace utilisateur. Ce concept est à la base de la théorie des systèmes d'exploitation.

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

The role of the operating system, in practice, is to provide programs with a consistent view of the computer's hardware. In addition, the operating system must account for independent operation of programs and protection against unauthorized access to resources. This nontrivial task is possible only if the CPU enforces protection of system software from the applications.

Dans la pratique, le rôle des systèmes d'exploitation est de fournir des programmes avec une vue conforme du matériel de l'ordinateur. En outre, le système d'exploitation doit exécuter les programmes indépendamment et protéger les ressources contre des accès non autorisés. Cet tâche difficile est possible uniquement si le processeur impose la protection des logiciels systèmes vis à vis des applications.

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

Every modern processor is able to enforce this behavior. The chosen approach is to implement different operating modalities (or levels) in the CPU itself. The levels have different roles, and some operations are disallowed at the lower levels; program code can switch from one level to another only through a limited number of gates. Unix systems are designed to take advantage of this hardware feature, using two such levels. All current processors have at least two protection levels, and some, like the x86 family, have more levels; when several levels exist, the highest and lowest levels are used. Under Unix, the kernel executes in the highest level (also called supervisor mode), where everything is allowed, whereas applications execute in the lowest level (the so-called user mode), where the processor regulates direct access to hardware and unauthorized access to memory.

Chaque processeur moderne is capable d'imposer ce comportement. L'approche choisie est d'implémenter différentes modalités fonctionnelles (ou niveaux) dans le processeur lui-même. Les niveaux ont différents rôles, et quelques opérations sont interdites aux niveaux inférieurs; le code d'un programme peut passer d'un niveau à un autre seulement à travers un nombre limité de portes. Les systèmes UNIX sont conçus pour tirer partie de cette fonctionnalité du matériel en utilisant deux de ces niveaux. Tous les processeurs actuels ont au moins deux niveaux de protection, et quelques uns, comme la famille des x86, ont plus de niveaux; quand plusieurs niveaux existent, les plus haut et bas niveaux sont utilisés. Sous Unix, le noyau s'exécute dans le niveau le plus haut (aussi appelé mode superviseur), où tout est autorisé, alors que les applications s'exécutent dans le niveau le plus bas (aussi appelé mode utilisateur), où le processeur régule les accès directs au matériel et les accès non autorisés à la mémoire.

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

We usually refer to the execution modes as kernel space and user space. These terms encompass not only the different privilege levels inherent in the two modes, but also the fact that each mode can have its own memory mapping - its own address space - as well.

Nous nous référons habituellement aux modes d'exécution comme l'espace noyau et l'espace utilisateur. Ces limites n'englobent pas seulement les différents niveaux de privilèges inhérents aux deux modes, mais aussi le fait que chaque mode peut avoir sa propre gestion de mémoire et aussi bien ses propres adresses

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

Unix transfers execution from user space to kernel space whenever an application issues a system call or is suspended by a hardware interrupt. Kernel code executing a system call is working in the context of a process - it operates on behalf of the calling process and is able to access data in the process's address space. Code that handles interrupts, on the other hand, is asynchronous with respect to processes and is not related to any particular process.

Unix transfère l'exécution de l'espace utilisateur vers l'espace noyau à chaque fois qu'une application fait un appel système ou elle est suspendue par une interruption matérielle. Le code du noyau exécutant un appel système travaille dans le contexte d'un processus - il fonctionne au nom du processus appelant et il est capable d'accéder aux données de l'espace d'adresses du processus. Le code qui gère les interruptions, d'un autre côté, est asynchrone en ce qui concerne les processus et n'est pas lié à un processus particulier.

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

The role of a module is to extend kernel functionality; modularized code runs in kernel space. Usually a driver performs both the tasks outlined previously: some functions in the module are executed as part of system calls, and some are in charge of interrupt handling.

Le rôle d'un module est d'étendre les fonctionnalités du noyau; le code modularisé s'exécute dans l'espace du noyau. Habituellement, un pilote réalise les deux tâches présentées précédemment : quelques fonctions dans le module sont exécutées en tant qu'appels système, et quelques unes ont la charge de la gestion des interruptions.

[Michaël]

Concurrency in the Kernel : concurrence dans le noyau

One way in which kernel programming differs greatly from conventional application programming is the issue of concurrency. Most applications, with the notable exception of multithreading applications, typically run sequentially, from the beginning to the end, without any need to worry about what else might be happening to change their environment. Kernel code does not run in such a simple world, and even the simplest kernel modules must be written with the idea that many things can be happening at once.

Une voie dans laquelle la programmation noyau est grandement différente de la programmation d'applications conventionnelles est le problème de la concurrence. La plupart des applications, avec l'exception notable des applications multi-threadées, s"exécutant typiquement de manière séquentielle, du début à la fin, sans aucun besoin de se soucier de quoi que ce soit pouvant changer leur environnement. Le code du noayu ne s'exécute pas dans un monde si simple,et même les modules noyaux les plus simples doivent être écrit avec l'idée que beaucoup de choses peuvent arriver à la fois.

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

There are a few sources of concurrency in kernel programming. Naturally, Linux systems run multiple processes, more than one of which can be trying to use your driver at the same time. Most devices are capable of interrupting the processor; interrupt handlers run asynchronously and can be invoked at the same time that your driver is trying to do something else. Several software abstractions (such as kernel timers, introduced in Chapter 7) run asynchronously as well. Moreover, of course, Linux can run on symmetric multiprocessor (SMP) systems, with the result that your driver could be executing concurrently on more than one CPU. Finally, in 2.6, kernel code has been made preemptible; this change causes even uniprocessor systems to have many of the same concurrency issues as multiprocessor systems.

Il y a quelques sources de concurrences dans la programmation noyau. Naturellement, les systèmes Linux lancent plusieurs processus, plus d'un pouvant essayer d'utiliser votre pilote au même moment. La plupart des périphériques sont capables d'interrompre le processeur; les gestionnaires d'interruption s'exécutent de façon asynchrone et peuvent être invoqués au même moment que votre pilote essaie de faire quelque chose d'autre. Beaucoup d'abstractions logicielles (comme les timers du noyau, introduits dans le chapitre 7) sont lancés de manière asynchrone également. Bien entendu, Linux fonctionne sur les systèmes symétriques multi-processeurs (SMP), avec pour conséquence l'exécution de votre pilote sur plus d'un processeur. Finallement, dans la branche 2.6, le code noyau a été fait de manière pré-emptive; ce changement impose les systèmes mono-processeur à avoir beaucoup de problèmes de concurrence comme les systèmes à processeurs multiples.

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

As a result, Linux kernel code, including driver code, must be reentrant - it must be capable of running in more than one context at the same time. Data structures must be carefully designed to keep multiple threads of execution separate, and the code must take care to access shared data in ways that prevent corruption of the data. Writing code that handles concurrency and avoids race conditions (situations in which an unfortunate order of execution causes undesirable behavior) requires thought and can be tricky. Proper management of concurrency is required to write correct kernel code; for that reason, every sample driver in this book has been written with concurrency in mind. The techniques used are explained as we come to them; Chapter 5 has also been dedicated to this issue and the kernel primitives available for concurrency management.

En conséquence, le code du noyau Linux, incluant le code des pilotes, doit être reentrant - il doit être capable de s'exécuter dans plusieurs contextes à la fois. Les structures de données doivent être soigneusement créées pour conserver la séparation des threads multiples d'exécution, et le code doit faire attention d'accéder à des données partagées avec des méthodes qui préviennent la corruption des données. Ecrire du code qui gère la concurence et évite des race conditions (situations dans lesquelles un ordre d'exécution inopportun ammène à un comportement indésirable) demande de la réflexion et peut être malin. La gestion appropriée de la concurrence est requise pour écrire du code noyau correct; pour cette raison, chaque extrait de code dans ce livre a été écrit avec la concurrence dans l'esprit. Les techniques utilisées sont expliquées quand nous en avons besoin; le chapitre 5 est dédié à ce problème et les primitives du noyau sont disponibles pour la gestion de la concurrence.

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

A common mistake made by driver programmers is to assume that concurrency is not a problem as long as a particular segment of code does not go to sleep (or ?block?). Even in previous kernels (which were not preemptive), this assumption was not valid on multiprocessor systems. In 2.6, kernel code can (almost)never assume that it can hold the processor over a given stretch of code. If you do not write your code with concurrency in mind, it will be subject to catastrophic failures that can be exceedingly difficult to debug.

Une erreur commune faite par les programmeurs de pilotes est de considérer que la concurrence n'est pas un problème dans la mesure où un morceau de code particulier ne va pas dormir (ou bloquer). Même si dans les noyaux précédents (qui n'étaient pas pré-emptifs), cette considération n'était pas correcte sur les systèmes multi-processeurs. Dans les séries 2.6, le code noyau ne peut (presque) jamais supposer qu'il peut tenir le processeur au-dessus d'un morceau de code donné. Si vous n'écrivez pas votre code avec la concurrence dans l'esprit, il sera sujet à des échecs catastrophiques qui seront excessivement difficiles à débugger.

[Michaël]

The Current Process : le processus actuel

Although kernel modules don't execute sequentially as applications do, most actions performed by the kernel are done on behalf of a specific process. Kernel code can refer to the current process by accessing the global item current, defined in <asm/ current.h>, which yields a pointer to struct task_struct, defined by <linux/sched.h>. The current pointer refers to the process that is currently executing. During the execution of a system call, such as open or read, the current process is the one that invoked the call. Kernel code can use process-specific information by using current, if it needs to do so. An example of this technique is presented in Chapter 6.

Bien que les modules du noyau ne s'exécutent pas séquentiellement comme les applications le font, la plupart des actions exécutées par le noyau sont réalisées au nom d'un processus spécifique. Le code noyau peut se référer au processus actuel en accédant à l'élément global current, défini dans <asm/current.h>, qui rapporte un pointeur à struct task_struct, défini dans <linux/sched.h>. Le pointeur actuel rapporte au processus s'exécutant actuellement. Pendant l'exécution d'un appel système, tel que open ou read, le processus actuel est celui qui a invoqué l'appel. Le code noyau peut utiliser des informations spécifiques au processus en utilisant current, s'il en a besoin. Un exemple de cette technique est présenté dans le chapitre 6.

Actually, current is not truly a global variable. The need to support SMP systems forced the kernel developers to develop a mechanism that finds the current process on the relevant CPU. This mechanism must also be fast, since references to current happen frequently. The result is an architecture-dependent mechanism that, usually, hides a pointer to the task_struct structure on the kernel stack. The details of the implementation remain hidden to other kernel subsystems though, and a device driver can just include <linux/sched.h> and refer to the current process. For example, the following statement prints the process ID and the command name of the current process by accessing certain fields in struct task_struct :

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

En fait, current n'est pas une vraie variable globale. Le besoin de supporter les systèmes SMP a forcé les développeurs du noyau à développer un mécanisme qui trouve le processus current sur le bon processeur. Ce mécanisme doit aussi être rapide puisque les références vers current arrivent fréquemment. Le résultat est un mécanisme dépendant de l'architecture qui, habituellement, cache un pointeur vers la structure task_struct sur la pile du noyau. Les détails de cette implémentation restent cachés aux autres sous-systèmes du noyau et un pilote de périhphérique peut juste inclure <linux/sched.h> et se rapporte au processus current. Par exemple, le code suivant affiche l'identifiant (ID) du processus et le nom de commande du processus current en accédant à certains champs de la structure task_struct :

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

The command name stored in current->comm is the base name of the program file (trimmed to 15 characters if need be) that is being executed by the current process.

Le nom de commande stocké dans current->comm est le nom de base du programme (coupé à 15 caractères si besoin) qui est exécuté par le processus current.

[Michaël]

il ne reste plus que la relecture orthographique

[MaliciaR]

Allons-y pour la relecture

*

Tandis que la plupart des petites et moyennes applications réalisent une tâche unique du début à la fin, chaque module du noyau se déclare lui-même dans le but d'exécuter des requêtes futures, et sa fonction d'initialisation se finit immédiatement. En d'autres termes, la tâche de la fonction d'initialisation du module est de le préparer à une utilisation ultérieure des fonctions du module; c'est comme si le module disait : "Je suis présent, voici ce que je peux faire". La fonction de fin du module (hello_exit dans l'exemple) est appelée juste avant que le module soit déchargé. Il pourrait dire au noyau : "Je ne suis plus là, ce n'est plus la peine de me demander quoi que ce soit". Cette approche de programmation est similaire à la programmation événementielle, mais tandis que toutes les applications ne sont pas événementielles, chaque module du noyau l'est. Une autre différence majeure entre les application événementielles et du code noyau se trouve dans la fonction de fin : alors qu'une application qui se termine peut ne pas libérer les ressources ou ne nettoie pas tout à fait, la fonction de fin d'un module doit soigneusement défaire tout ce que la fonction d'initialisation a fait, sinon des morceaux resteront jusqu'à ce que le système soit redémarré.

Parfois je suis en apné

La plupart des petites et moyennes applications réalisent une tâche unique du début à la fin, alors que chaque module du noyau se déclare lui-même dans le but d'exécuter des requêtes futures; sa fonction d'initialisation se finit immédiatement. Autrement dit, la tâche de la fonction d'initialisation du module est de le préparer à une utilisation ultérieure des fonctions du module; c'est comme si le module disait : "Je suis présent, voici ce que je peux faire". La fonction de fin du module (hello_exit dans l'exemple) est appelée juste avant que le module soit déchargé. Il pourrait dire au noyau : "Je ne suis plus là, ce n'est plus la peine de me demander quoi que ce soit".
Cette approche de programmation est similaire à la programmation événementielle. Toutes les applications ne sont pas événementielles, tandis que chaque module du noyau l'est. Une autre différence majeure entre les applications événementielles et le code noyau se trouve dans la fonction de fin : une application qui se termine peut ne pas libérer les ressources ou ne nettoie pas complètement contrairement à la fonction de fin d'un module. Cette dernière doit soigneusement défaire tout ce que la fonction d'initialisation a fait, sinon des morceaux resteront jusqu'à ce que le système soit redémarré.

Je me demandais même si ce ne serait pas mieux de tout organiser dans un pitit tableau de comparaison. Le pragraphe est énorme et chaque ligne est super importante, mais je n'arrive pas à trouver un moyen de le rendre facilement digeste


*

Par ailleurs, la possibilité de décharger un module est une des fonctionnalités de la modularisation que vous allez le plus apprécier parce qu'elle aide à réduire les temps de développement; vous pouvez tester des versions successives de votre nouveau pilote sans avoir à passer par un cycle d'arrêt/redémarrage lent à chaque fois.

deviendrait :

Par ailleurs, la possibilité de décharger un module est une des fonctionnalités de la modularisation que vous allez le plus apprécier : elle aide à réduire les temps de développement. Vous pouvez donc tester des versions successives de votre nouveau pilote sans avoir à passer par un cycle d'arrêt/redémarrage lent à chaque fois.

*

printf est une des fonctions appelable et déclarée dans la libc. D'un autre côté, un module est uniquement lié avec le noyau, et les seules fonctions qu'il peut appeler sont celles exportées par le noyau; il n'y a aucune bibliothèque à lier. La fonction printk utilisée précédemment dans hello.c, par exemple, est la version de printf définie dans le noyau et exportée aux modules. Elle se comporte comme la fonction d'origine mais avec quelques différences mineures, la principale étant le manque du support des nombres à virgule flottante.

deviendrait :

printf est une des fonctions appelables et déclarées dans la libc. D'un autre côté, un module est uniquement lié avec le noyau. Les seules fonctions qu'il peut appeler sont celles exportées par le noyau; il n'y a aucune bibliothèque à lier. La fonction printk utilisée précédemment, dans hello.c par exemple, est la version de printf définie dans le noyau et exportée aux modules. Elle se comporte comme la fonction d'origine mais avec quelques différences mineures, la principale étant le manque de support des nombres à virgule flottante.

*

L'illustration 2-1 montre comment les appels de fonction et les pointeurs de fonction sont utilisés dans un module afin d'ajouter des nouvelles fonctionnalités au noyau

deviendrait :

*

L'illustration 2-1 montre comment les appels de fonction et les pointeurs de fonction sont utilisés dans un module afin d'ajouter de nouvelles fonctionnalités au noyau.

*

ATTENTION IL Y A UNE IMAGE ICI A TRADUIRE !!!! CONTACTEZ MICHAEL SI VOUS N'ARRIVEZ PAS A LA CREER. Figure 2-1. Linking a module to the kernel

Ton mail se trouvera en "Annexe Liens Utiles" du livre fini?


*

Étant donné qu'aucune bibliothèque est liée aux modules, les fichiers sources ne devraient jamais inclure les entêtes courants, <stdarg.h> et certaines situations spécifiques sont les seules exceptions. Seules les fonctions faisant réellement partie du noyau lui-même peuvent être utilisées dans les modules. Tout ce qui est relatif au noyau est déclaré dans les entêtes que l'on peut trouver dans l'arborescence des sources du noyau que vous avez installée et configurée. La plupart des entêtes courants sont situés dans include/linux et include/asm, mais d'autres sous-répertoires spécifiques aux matériels peuvent avoir été créés.

deviendrait :

Étant donné qu'aucune bibliothèque n'est liée aux modules, les fichiers sources ne devraient jamais inclure les en-têtes/entête courants. Les seules exceptions sont <stdarg.h> et certaines situations spécifiques. Uniquement les fonctions faisant réellement partie du noyau lui-même peuvent être utilisées dans les modules. Tout ce qui est relatif au noyau est déclaré dans les en-têtes/entête que l'on peut trouver dans l'arborescence des sources du noyau que vous avez installée et configurée. La plupart des en-têtes/entête courants sont situés dans include/linux et include/asm, mais d'autres sous-répertoires spécifiques aux matériels peuvent avoir été créés.

Je sais qu'on peut utiliser "entête" au même titre que "en-tête", mais... Si on utilise le mot en entier, on ne devrait pas mettre de "s" pour le pluriel (s'pas moi, c'est le Littré qui discute de ça); c'est d'ailleurs logique vu la formation de l'expression. Bref


*

Le rôle de chaque entête du noyau est expliqué à travers le livre quand on a besoin d'une entête en particulier.

Je ne comprends pas trop là : le rôle de chaque en-tête est expliqué ou seulement les rôles des particuliers dont on a besoin?


*

Une autre différence importante entre la programmation du noyau et la programmation des applications réside sur comment chaque environnement gère les erreurs : alors qu'une erreur de segmentation est inoffensive dans le développement d'applications et un débugger peut toujours être utilisé pour tracer l'erreur jusqu'au problème dans le code source, une erreur du noyau tue le processus courant si ce n'est pas le système entier. Nous verrons comment tracer les erreurs du noyau dans le chapitre 4.

deviendrait :

Une autre différence importante entre la programmation des applications et la programmation du noyau est la manière dont chaque environnement gère les erreurs. Une erreur de segmentation est inoffensive dans le développement d'applications et un débugger peut toujours être utilisé pour tracer l'erreur jusqu'au problème dans le code source. En revanche, une erreur du noyau tue le processus courant si ce n'est pas le système entier. Nous verrons comment tracer les erreurs du noyau dans le chapitre 4.

J'ai fait des phrases plus courtes en agençant l'ordre des choses abordées. Je sais, je suis c***** avec mes phrases courtes, mais on nous apprend à faire ça en bio "parce que c'est nettement plus clair quand on est concis, n'oubliez pas, s'il vous plaît"


*

Cet tâche difficile est possible uniquement si le processeur impose la protection des logiciels systèmes vis à vis des applications.

C'est vis-à-vis


*

Les niveaux ont différents rôles, et quelques opérations sont interdites aux niveaux inférieurs; le code d'un programme peut passer d'un niveau à un autre seulement à travers un nombre limité de portes. Les systèmes UNIX sont conçus pour tirer partie de cette fonctionnalité du matériel en utilisant deux de ces niveaux. Tous les processeurs actuels ont au moins deux niveaux de protection, et quelques uns, comme la famille des x86, ont plus de niveaux; quand plusieurs niveaux existent, les plus haut et bas niveaux sont utilisés. Sous Unix, le noyau s'exécute dans le niveau le plus haut (aussi appelé mode superviseur), où tout est autorisé, alors que les applications s'exécutent dans le niveau le plus bas (aussi appelé mode utilisateur), où le processeur régule les accès directs au matériel et les accès non autorisés à la mémoire.

deviendrait :

Les niveaux ont différents rôles et quelques opérations sont interdites aux niveaux inférieurs. Le code d'un programme peut passer d'un niveau à un autre seulement à travers un nombre limité de portes. Les systèmes UNIX sont conçus pour tirer partie de cette fonctionnalité du matériel en utilisant deux de ces niveaux. Tous les processeurs actuels ont au moins deux niveaux de protection et quelques-uns, comme la famille des x86, ont plus de niveaux. Quand plusieurs niveaux existent, les plus haut et bas niveaux sont utilisés. Sous Unix, le noyau s'exécute dans le niveau le plus haut (aussi appelé mode superviseur) où tout est autorisé. Au contraire, les applications s'exécutent dans le niveau le plus bas (aussi appelé mode utilisateur) où le processeur régule les accès directs au matériel et les accès non autorisés à la mémoire.

*

Unix transfère l'exécution de l'espace utilisateur vers l'espace noyau à chaque fois qu'une application fait un appel système ou elle est suspendue par une interruption matérielle. Le code du noyau exécutant un appel système travaille dans le contexte d'un processus - il fonctionne au nom du processus appelant et il est capable d'accéder aux données de l'espace d'adresses du processus. Le code qui gère les interruptions, d'un autre côté, est asynchrone en ce qui concerne les processus et n'est pas lié à un processus particulier.

deviendrait :

Unix transfère l'exécution de l'espace utilisateur vers l'espace noyau à chaque fois qu'une application fait un appel système ou est suspendue par une interruption matérielle. Le code du noyau exécutant un appel système travaille dans le contexte d'un processus : il fonctionne au nom du processus appelant et est capable d'accéder aux données de l'espace d'adresses du processus. Par ailleurs, le code qui gère les interruptions, est asynchrone en ce qui concerne les processus et n'est pas lié à un processus particulier.

J'ai remplacé "d'un autre côté" par "par ailleurs" parce que la 1re expression donne l'impression qu'on va introduire une notion complémentaire et qu'on la développera, or je n'ai pas l'impression que ce soit le cas Du coup, avec "par ailleurs" on fait juste un complément presque "en passant".


*

Le rôle d'un module est d'étendre les fonctionnalités du noyau; le code modularisé s'exécute dans l'espace du noyau. Habituellement, un pilote réalise les deux tâches présentées précédemment : quelques fonctions dans le module sont exécutées en tant qu'appels système, et quelques unes ont la charge de la gestion des interruptions.

deviendrait :

Le rôle d'un module est d'étendre les fonctionnalités du noyau; le code modularisé s'exécute dans l'espace du noyau. Habituellement, un pilote réalise les deux tâches présentées précédemment : quelques fonctions dans le module sont exécutées en tant qu'appels système et quelques-unes ont la charge de la gestion des interruptions.

La suite au prochain épisode

[Michaël]

Seules les fonctions faisant réellement partie du noyau lui-même peuvent être utilisées dans les modules

=>

Uniquement les fonctions faisant réellement partie du noyau lui-même peuvent être utilisées dans les modules

pourquoi préférer "uniquement" à "seules" ? je trouve que ça alourdit un peu non ?

Envoyé par MaliciaR

Je ne comprends pas trop là : le rôle de chaque en-tête est expliqué ou seulement les rôles des particuliers dont on a besoin?

=> c'est mieux comme ça ?

Le rôle de chaque en-tête sera expliqué dans le livre quand on en aura besoin.

Envoyé par MaliciaR

J'ai fait des phrases plus courtes en agençant l'ordre des choses abordées. Je sais, je suis c***** avec mes phrases courtes, mais on nous apprend à faire ça en bio "parce que c'est nettement plus clair quand on est concis, n'oubliez pas, s'il vous plaît"

Non au contraire Les phrases courtes c'est bien mieux

le reste est intégré

[MaliciaR]

Envoyé par Michaël

=>pourquoi préférer "uniquement" à "seules" ? je trouve que ça alourdit un peu non ?

Parce qu'il y a un autre "seules" dans la phrases suivant immédiatement après Du coup, ça alourdit légèrement, mais ne fait pas de répétition. Mais je viens d'y penser :

Uniquement les fonctions faisant réellement partie du noyau lui-même peuvent être utilisées dans les modules

On peut virer "réellement" : il est dit dans 'noyau lui-même" (ça fait tautologique :p ).
Ce qui donne le paragraphe :

Étant donné qu'aucune bibliothèque n'est liée aux modules, les fichiers sources ne devraient jamais inclure les en-têtes/entête courants. Les seules exceptions sont <stdarg.h> et certaines situations spécifiques. Uniquement les fonctions faisant partie du noyau lui-même peuvent être utilisées dans les modules. Tout ce qui est relatif au noyau est déclaré dans les en-têtes/entête que l'on peut trouver dans l'arborescence des sources du noyau que vous avez installée et configurée. La plupart des en-têtes/entête courants sont situés dans include/linux et include/asm, mais d'autres sous-répertoires spécifiques aux matériels peuvent avoir été créés.

Envoyé par Michaël

=> c'est mieux comme ça ?

Plutôt :

Le rôle de chaque en-tête sera expliqué lorsque nous nous en servirons.

Envoyé par Michaël

Non au contraire Les phrases courtes c'est bien mieux

le reste est intégré

Je finirai le reste dans la journée.