Chapitre 1 : An Introduction to Device Drivers partie 2 [Résolu]

[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.

[Arnaud F.]

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:

[Arnaud F.]

<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.

[Arnaud F.]

<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.

[Arnaud F.]

<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.

[Arnaud F.]

<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.

[Arnaud F.]

<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.

[Arnaud F.]

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.

[Arnaud F.]

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>.

[Arnaud F.]

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.

[Arnaud F.]

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.

[Arnaud F.]

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>.

[Arnaud F.]

<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.

[Arnaud F.]

<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/>

[Arnaud F.]

Not being a stream-oriented device, a network interface isn't easily mapped to a node in the filesystem, as /dev/tty1 is. The Unix way to provide access to interfaces is still by assigning a unique name to them (such as eth0), but that name doesn't have a corresponding entry in the filesystem. Communication between the kernel and a network device driver is completely different from that used with char and block drivers. Instead of read and write, the kernel calls functions related to packet transmission.

N'étant pas un périphérique orienté flux, une interface réseau n'est pas facilement liée à un noeud du système de fichier, comme /dev/tty1 l'est. La méthode Unix pour procurer un accès aux interfaces est encore en leur assignant un nom unique (comme <b>eth0</b>), mais ce nom n'as pas d'entrée correspondante dans le système de fichiers. La communication entre le noyau et un pilote de périphérique réseau est totalement différente de celle utilisée avec les pilotes caractère et bloc. Au lieu de <i>read</i> et <i>write</i> le noyau fait appel à des fonctions relatives à la transmission de paquets.

[Arnaud F.]

There are other ways of classifying driver modules that are orthogonal to the above device types. In general, some types of drivers work with additional layers of kernel support functions for a given type of device. For example, one can talk of universal serial bus (USB) modules, serial modules, SCSI modules, and so on. Every USB device is driven by a USB module that works with the USB subsystem, but the device itself shows up in the system as a char device (a USB serial port, say), a block device (a USB memory card reader), or a network device (a USB Ethernet interface).

Il y a d’autres moyens de classifier les modules qui sont orthogonaux aux types de périphérique ci-dessus. En général, quelques types de pilotes fonctionnent avec des couches additionnelles qui font parties des fonctions du support noyaux pour un type donné de périphérique. Par exemple, si on parle des modules du bus série universel (Universal Serial Bus), les modules serial, les modules SCSI et ainsi de suite. Tout périphérique USB est piloté par un module USB qui fonctionne avec le sous-systèmeUSB, mais le périphérique lui-même apparaît dans le système comme un périphérique caractère (dit à port série USB), un périphérique bloc (un lecteur de cartes mémoires USB), ou une interface réseau (une interface Ethernet USB).

[Arnaud F.]

Other classes of device drivers have been added to the kernel in recent times, including FireWire drivers and I2O drivers. In the same way that they handled USB and SCSI drivers, kernel developers collected class-wide features and exported them to driver implementers to avoid duplicating work and bugs, thus simplifying and strengthening the process of writing such drivers.

Les autres classes de pilotes de périphériques ont été récemment ajoutées au noyau, incluant les pilotes FireWire et les pilotes I2O. En même temps qu'ils manipulaient les pilotes USB et SCSI, les développeurs de noyau ont recueillit des propriétés de large classe et les ont exportées aux fournisseurs de modules afin d'éviter le travail en double et les bugs, et aussi simplifier et renforcer le processus pour écrire de tel pilotes.

[Arnaud F.]

In addition to device drivers, other functionalities, both hardware and software, are modularized in the kernel. One common example is filesystems. A filesystem type determines how information is organized on a block device in order to represent a tree of directories and files. Such an entity is not a device driver, in that there's no explicit device associated with the way the information is laid down; the filesystem type is instead a software driver, because it maps the low-level data structures to high-level data structures. It is the filesystem that determines how long a filename can be and what information about each file is stored in a directory entry. The filesystem module must implement the lowest level of the system calls that access directories and files, by mapping filenames and paths (as well as other information, such as access modes) to data structures stored in data blocks. Such an interface is completely independent of the actual data transfer to and from the disk (or other medium), which is accomplished by a block device driver.

En plus des pilotes de périphériques, d'autres fonctions, tant matérielles que logicielles, sont modularisées dans le noyau. Un exemple commun est le système de fichiers. Le type de système de fichiers détermine comment l'information est organisée sur un périphérique bloc afin de représenter un arborescence de répertoires et fichiers. Une telle entité n'est pas un pilote de périphériques, par le fait qu'il n'y a pas de périphérique explicite associé à la manière dont l'information y est redirigée, c'est plutôt le type de système de fichiers plutôt que le pilote logiciel, car il fait correspondre les structures de données bas-niveau à des structures de données de haut niveau. C'est le système de fichiers qui détermine de quelle longueur peut être un nom de fichier et quelles informations sur chaque fichier sont stockées dans un répertoire. Le module du système de fichiers doit implémenter le plus bas niveau d'appels système qui accède aux répertoires et fichiers en cartographiant les noms de fichiers et les chemins (aussi bien que d'autres informations comme les droits d'accès) aux structures de données contenues dans les blocs de données. Une telle interface est totalement indépendante du transfert de données en cours vers et du disque (ou autre medium), qui est accompli par un pilote de périphériques en mode bloc.

[Arnaud F.]

If you think of how strongly a Unix system depends on the underlying filesystem, you'll realize that such a software concept is vital to system operation. The ability to decode filesystem information stays at the lowest level of the kernel hierarchy and is of utmost importance; even if you write a block driver for your new CD-ROM, it is useless if you are not able to run ls or cp on the data it hosts. Linux supports the concept of a filesystem module, whose software interface declares the different operations that can be performed on a filesystem inode, directory, file, and superblock. It's quite unusual for a programmer to actually need to write a filesystem module, because the official kernel already includes code for the most important filesystem types.

Si vous vous demandez à quel point un système Unix dépend du système de fichiers sous-jacent, vous vous rendrez compte qu'un tel concept logiciel est vital pour les opérations systèmes. La capacité de décoder les informations du système de fichiers est ancrée au plus bas niveau de la hiérarchie du noyau est d'une importance majeure. Même si vous écrivez un pilote en mode bloc pour votre nouveau lecteur de CD-ROM, il est inutile si vous n'êtes pas capable de lancer les commandes <i>ls</i> ou <i>cp</i> sur les données qu'il contient. Linux supporte le concept d'un module système de fichiers, dont l'interface logicielle déclare les différentes opérations qui peuvent être exécutées sur l'inode, le répertoire, le fichier et le superbloc du système de fichiers. Il est très peu courant actuellement qu'un programmeur ai besoin d'écrire un module système de fichiers, car le noyau officiel inclut déjà le code pour les types de systèmes de fichiers les plus importants.

++

P.S : Pour ceux qui voudraient directement mettre le XML à jour quand ils corrigent, je le mets en PJ

[Michaël]

il y a une image dans ce document. la voici