Chapitre 1 : An Introduction to Device Drivers partie 2

[Michaël]

Discussion réservée à la traduction de la partie 2 du chapitre 1 "An Introduction to Device Drivers"

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.

[buchs]

Splitting the Kernel

In a Unix system, several concurrent processes attend to different tasks. Each process asks for system resources, be it computing power, memory, network connectivity, or some other resource. The kernel is the big chunk of executable code in charge of handling all such requests. Although the distinction between the different kernel tasks isn't always clearly marked, the kernel's role can be split (as shown in Figure 1-1) into the following parts:

Décomposition du Noyau

Dans un système Unix, plusieurs processus concurrents s'occupent de différentes tâches. Chaque processus demande des ressources systèmes, que ce soit processeur, mémoire, connexion au réseau ou d’autres ressources. Le noyau est la grosse boule de code exécutable en charge de manipuler de telles requêtes. Bien que la distinction entre les différentes tâches du noyau ne soit pas toujours clairement définie, le rôle du noyau peut être séparé (figure 1-1) en ces différentes parties:

[buchs]

<u>Process management :</u> The kernel is in charge of creating and destroying processes and handling their connection to the outside world (input and output). Communication among different processes (through signals, pipes, or interprocess communication primitives) is basic to the overall system functionality and is also handled by the kernel. In addition, the scheduler, which controls how processes share the CPU, is part of process management. More generally, the kernel's process management activity implements the abstraction of several processes on top of a single CPU or a few of them.

<u>Gestion de processus</u>: le noyau est en charge de la création et de la destruction des processus ainsi que de la gestion de leur connexion au monde extérieur (entrée et sortie). La communication entre les différents processus (au travers de signaux, des tubes nommés ou des primitives <i>Inter Process Communication</i>) est commune à l'ensemble des fonctionnalités du système et est aussi géré par le noyau. De plus, le programmateur, qui contrôle la façon dont les processus partagent le CPU, fait partie de la gestion de processus. Plus généralement, l'activité de gestion des processus par le noyau implémente l'abstraction de plusieurs processus au dessus d'un simple CPU ou quelques-uns d'entre eux.

[buchs]

<u>Memory management :</u> The computer's memory is a major resource, and the policy used to deal with it is a critical one for system performance. The kernel builds up a virtual addressing space for any and all processes on top of the limited available resources. The different parts of the kernel interact with the memory-management subsystem through a set of function calls, ranging from the simple malloc/free pair to much more complex functionalities.

<u>Gestion de mémoire</u> : la mémoire est une ressource majeure et la règle à appliquer est critique pour la performance du système. Le noyau met en place un espace d'adressage virtuel pour n'importe quel et tous les processus au dessus de la limite des ressources disponibles. Les différentes parties du noyau interagissent avec le sous-système de gestion de mémoire au travers d'un ensemble d'appels de fonctions, allant de la simple paire malloc/free à des fonctionnalités plus complexes.

[buchs]

<u>Filesystems :</u> Unix is heavily based on the filesystem concept; almost everything in Unix can be treated as a file. The kernel builds a structured filesystem on top of unstructured hardware, and the resulting file abstraction is heavily used throughout the whole system. In addition, Linux supports multiple filesystem types, that is, different ways of organizing data on the physical medium. For example, disks may be formatted with the Linux-standard ext3 filesystem, the commonly used FAT filesystem or several others.

<u>Système de fichiers</u>: Unix est fortement basé sur le concept de système de fichiers. Presque tout dans Unix peut être traité comme un fichier. Le noyau fabrique une structure au dessus du matériel non structuré et l'abstraction de fichier résultante est fortement utilisée d’un bout à l’autre du système. De plus, Linux supporte plusieurs types de systèmes de fichiers, qui correspondent, à des façons différentes d'organiser les données sur le support physique. Par exemple, les disques peuvent être formatés avec le système de fichiers standard de Linux ext3, le système de fichier FAT utilisé communément, ou plusieurs autres.

[buchs]

<u>Device control :</u> Almost every system operation eventually maps to a physical device. With the exception of the processor, memory, and a very few other entities, any and all device control operations are performed by code that is specific to the device being addressed. That code is called a device driver. The kernel must have embedded in it a device driver for every peripheral present on a system, from the hard drive to the keyboard and the tape drive. This aspect of the kernel's functions is our primary interest in this book.

<u>Contrôle de périphérique</u>: chaque opération système ou presque est liée à un périphérique physique. A l'exception du processeur, de la mémoire et de très peu d'autres entités, toutes les opérations de contrôle de périphérique sont réalisées par du code qui est spécifique au périphérique auquel on s’adresse. Ce code est appelé «un pilote de périphérique». Le noyau doit comprendre un pilote de périphérique pour chaque périphérique présent sur un système, du disque dur au clavier et au système d’enregistrement sur bande. Cet aspect des fonctions du noyau est notre principal intérêt dans ce livre.

[buchs]

<u>Networking :</u> Networking must be managed by the operating system, because most network operations are not specific to a process: incoming packets are asynchronous events. The packets must be collected, identified, and dispatched before a process takes care of them. The system is in charge of delivering data packets across program and network interfaces, and it must control the execution of programs according to their network activity. Additionally, all the routing and address resolution issues are implemented within the kernel.

<u>Réseau</u>: le réseau doit être pris en charge par le système d'exploitation, car la plupart des opérations réseau ne sont pas spécifique à un processus: les paquets entrants sont des évènements asynchrones. Les paquets doivent être collectés, identifiés, et dispatchés avant qu'un processus ne puisse y prêter attention. Le système est en charge de la livraison des paquets de données aux programmes, aux interfaces réseau et il doit contrôler l'exécution des programmes en fonction de l'activité réseau. De plus, toutes les opérations de routage et de résolution d'adresses sont implémentées à l'intérieur du noyau.

[buchs]

Loadable Modules

One of the good features of Linux is the ability to extend at runtime the set of features offered by the kernel. This means that you can add functionality to the kernel (and remove functionality as well) while the system is up and running.

Modules chargeables

L'un des avantages de Linux est la possibilité d'étendre pendant l'exécution, le choix de caractéristiques offertes par le noyau. Cela signifie que vous pouvez ajouter des fonctionnalités au noyau (et aussi les enlever) pendant que le système est démarré et actif.

[buchs]

Each piece of code that can be added to the kernel at runtime is called a module. The Linux kernel offers support for quite a few different types (or classes) of modules, including, but not limited to, device drivers. Each module is made up of object code (not linked into a complete executable) that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.

Toute partie de code qui peut être ajoutée au noyau pendant son fonctionnement s'appelle un <i>module</i>. Le noyau Linux offre des supports pour peu de types (ou classes) de modules différents, incluant, mais sans se limiter, les pilotes de périphériques. Chaque module est constitué d’un code objet (non lié en tant qu'exécutable final) qui peut être dynamiquement lié au noyau actif par le programme <i>insmod</i> et peut être délié par le programme <i>rmmod</i>.

[buchs]

Figure 1-1 identifies different classes of modules in charge of specific tasks - a module is said to belong to a specific class according to the functionality it offers. The placement of modules in Figure 1-1 covers the most important classes, but is far from complete because more and more functionality in Linux is being modularized.

La figure 1.1 identifie différentes classes de modules en charge de fonctions spécifiques, on dit d'un module qu'il appartient à une classe spécifique en fonction de la fonctionnalité qu'il procure. La représentation des modules dans la figure 1.1 couvre les classes les plus importantes, mais est loin d'être complète car de plus en plus de fonctionnalités sont modularisées dans Linux.

[buchs]

Classes of Devices and Modules

The Linux way of looking at devices distinguishes between three fundamental device types. Each module usually implements one of these types, and thus is classifiable as a char module, a block module, or a network module. This division of modules into different types, or classes, is not a rigid one; the programmer can choose to build huge modules implementing different drivers in a single chunk of code. Good programmers, nonetheless, usually create a different module for each new functionality they implement, because decomposition is a key element of scalability and extendability.

Classes de périphériques et modules

La façon dont Linux reconnaît les périphériques se décompose en trois types fondamentaux. Chaque module implémente normalement l'un des ces types, ainsi classifiable comme, un module en mode caractère, un en mode bloc ou un module réseau. Cette division de modules en différents types, ou classes, n'est pas stricte. Le programmeur peut choisir de faire de très gros modules implémentant plusieurs pilotes dans un seul bloc de code. Les bons programmeurs, néanmoins, créés habituellement un module différent pour chaque nouvelle fonctionnalité qu'ils implémentent, car la décomposition est un élément clé pour l'optimisation et l'évolution.

[buchs]

The three classes are :

<u>Character devices :</u> A character (char) device is one that can be accessed as a stream of bytes (like a file); a char driver is in charge of implementing this behavior. Such a driver usually implements at least the open, close, read, and write system calls. The text console (/dev/console) and the serial ports (/dev/ttyS0 and friends) are examples of char devices, as they are well represented by the stream abstraction. Char devices are accessed by means of filesystem nodes, such as /dev/tty1 and /dev/lp0. The only relevant difference between a char device and a regular file is that you can always move back and forth in the regular file, whereas most char devices are just data channels, which you can only access sequentially. There exist, nonetheless, char devices that look like data areas, and you can move back and forth in them; for instance, this usually applies to frame grabbers, where the applications can access the whole acquired image using mmap or lseek.

Les trois classes sont :<u>Périphériques en mode caractère</u>: un périphérique caractère (char) est un périphérique qui peut être vu comme flux d’octets (comme un fichier). Un pilote en mode caractère à la charge de mettre en œuvre ce comportement. Un tel pilote implémente habituellement au moins les appels systèmes <i>open</i>, <i>close</i>, <i>read</i> et <i>write</i>. La console (/dev/console) et les ports séries (/dev/ttyS0 et autres) sont des exemples de périphériques en mode caractère, comme ils sont bien représentés par l'abstraction de flux. Les périphériques caractère sont vus par représentations de noeuds du système de fichiers, comme /dev/tty1 et /dev/lp0. La seule différence notoire entre un périphérique caractère et un fichier régulier est que vous pouvez toujours retourner en arrière et ainsi de suite dans le fichier régulier, tandis que la plupart des périphérique orienté caractère sont juste des chaînes de données, lequel est uniquement accessible séquentiellement. Il existe, néanmoins, les périphériques orienté caractère ressemblent à des zones de données ou vous pouvez retourner en arrière et ainsi de suite. Par exemple, ceci s'applique habituellement aux capteurs de trames, ou les applications peuvent accéder à une image complète acquise en utilisant <i>mmap</i> ou <i>lseek</i>.

[buchs]

<u>Block devices :</u> Like char devices, block devices are accessed by filesystem nodes in the /dev directory. A block device is a device (e.g., a disk) that can host a filesystem. In most Unix systems, a block device can only handle I/O operations that transfer one or more whole blocks, which are usually 512 bytes (or a larger power of two) bytes in length. Linux, instead, allows the application to read and write a block device like a char device - it permits the transfer of any number of bytes at a time. As a result, block and char devices differ only in the way data is managed internally by the kernel, and thus in the kernel/driver software interface. Like a char device, each block device is accessed through a filesystem node, and the difference between them is transparent to the user. Block drivers have a completely different interface to the kernel than char drivers.

<u>Périphérique en mode bloc</u>: comme les périphériques orienté caractère, les périphériques en mode bloc sont accessibles par des noeuds sur le système de fichiers dans le répertoire /dev. Un périphérique bloc est un périphérique (par exemple: un disque) qui peut héberger un système de fichiers. Dans la plupart de systèmes Unix, un périphérique en mode bloc ne peut que manipuler des opérations entrées/sorties qui transfèrent un ou plusieurs blocs complets, qui sont habituellement de 512 octets (ou une plus grande puissance de 2) octets de long. Linux, quant à lui, autorise l'application à lire et écrire un périphérique en mode bloc comme un périphérique en mode caractère, il permet le transfert de n'importe quel nombre d'octets en une fois. Par conséquent, les périphériques bloc et caractère ne diffèrent que dans la façon dont les données sont gérées en interne par le noyau, et par la suite, dans l'interface logicielle du noyau/pilote. Comme un périphérique orienté caractère, chaque périphérique en mode bloc est accessible au travers d'un noeud du système de fichiers, et la différence entre eux est transparente pour l'utilisateur. Les pilotes en mode bloc ont une interface complètement différente au noyau que les pilotes en mode caractère.

[buchs]

<u>Network interfaces :</u> Any network transaction is made through an interface, that is, a device that is able to exchange data with other hosts. Usually, an interface is a hardware device, but it might also be a pure software device, like the loopback interface. A network interface is in charge of sending and receiving data packets, driven by the network subsystem of the kernel, without knowing how individual transactions map to the actual packets being transmitted. Many network connections (especially those using TCP) are stream-oriented, but network devices are, usually, designed around the transmission and receipt of packets. A network driver knows nothing about individual connections; it only handles packets.<br/>

<u>Interfaces réseau</u>: toute transmission réseau est faite au travers d'une interface, qui est, un périphérique capable d'échanger des données avec d'autres hôtes. Habituellement, une <i>interface</i> est un périphérique matériel, mais il peut aussi être un périphérique purement logiciel, comme l'interface loopback. Une interface réseau est en charge d'envoyer et recevoir des paquets de données, piloté par le sous-système réseau du noyau, sans avoir connaissance de la manière dont les transmissions individuelles tracent les paquets en cours de transfert. Plusieurs connexions réseau (particulièrement celles utilisant TCP) sont orientées flux, mais les périphériques réseau sont, habituellement, conçus autour de la transmission et réception de paquets. Un pilote réseau ne connaît rien des connexions individuelles, il ne fait que manipuler des paquets.<br/>