Nous avons vu dans l’épisode 1 l’architecture générale de l’environnement du noyau Linux, ainsi que ce que celui-ci réalise en matière de gestion de processus, et dans l’épisode 2 ce qu’il réalise en termes de gestion mémoire.

Pour continuer notre exploration des fonctionnalités du noyau, nous allons, dans cet épisode, aborder la gestion des périphériques.

Sur un PC les périphériques sont nombreux : clavier, souris, écran, carte graphique, carte réseau, clé USB, disque dur, SSD, etc.

Dans le monde Windows, les périphériques ont été historiquement livrés par leur constructeur accompagnés par le pilote de périphérique adapté à Windows. Pendant des décennies les constructeurs n’ont pas daigné fournir les pilotes de périphériques (drivers) adaptés à Linux. Les programmeurs du noyau Linux ont donc dû s’adapter en les développant eux-mêmes.

Une technique qui a beaucoup été utilisée est la retro-ingénierie, qui consiste à décortiquer le driver pour Windows jusqu’à ce qu’on ait compris ce qu’il fait et comment il fonctionne.

Dans les années 90, lorsque les programmeurs du noyau étaient encore peu nombreux (l’époque où le contributeur numéro deux après Linus Torvalds était le légendaire Alan Cox), il n’y avait généralement presqu’une seule personne derrière chaque famille de drivers.

A cette époque, les drivers pour les cartes réseau Ethernet étaient par exemple pratiquement tous codés par un programmeur de la NASA (dont j’ai oublié le nom, on pourrait le retrouver en allant farfouiller dans le code source Linux de ces drivers).

Le monde Linux a donc appris au fil des décennies à coder seul ses drivers. Le noyau est donc devenu de facto très bon pour auto-détecter le matériel.

Jusqu’à la version 0.99.14 du noyau Linux, les drivers étaient en dur dans le noyau. C’était une époque où les utilisateurs de Linux compilaient eux-mêmes un noyau aux petits oignons pour leur machine. Lors de la configuration pré-compilation, on indiquait quels drivers on voulait, et le noyau était ensuite compilé avec ces drivers. Quand on bootait dessus, on avait le support des périphériques dont on avait retenu le driver dans le noyau. Cette action était assez sportive car le driver n’était pas lié à un modèle commercial de périphérique, mais généralement à la puce électronique située au cœur de ce périphérique. Il n’était donc pas rare de devoir consulter Windows pour savoir quelle puce Windows disait détecter.

A partir de la version 0.99.15 du noyau Linux en 1994, celui-ci s’est vu ajouter la fonction de modules chargeables. On pouvait désormais monter ou démonter dynamiquement un driver dans le noyau, ce qui fut une avancée notable.

Au cours des années 2000, des distributions comme Ubuntu ont poussé très loin les mécanismes d’auto-détection du matériel, ces mécanismes se terminant par la montée dynamique du bon driver dans le noyau.

Entre temps, pour la petite histoire, Windows s’est inspiré de Linux en ayant de moins en moins la nécessité d’utiliser des drivers externes fournis par les constructeurs. Les drivers sont intégrés dans le code du noyau Windows.

La gestion des périphériques dans le noyau Linux

Les périphériques étant du matériel, seul le noyau a les droits pour y accéder. Ces accès se font par des pilotes de périphériques en dur dans le noyau ou montés sous forme de modules comme nous l’avons vu (commande lsmod pour voir quels modules sont montés, insmod pour monter un module, rmmod pour descendre un module).

Nous avons vu dans l’épisode 1 l’architecture générale de l’environnement du noyau Linux, ainsi que ce qu’il réalise en matière de gestion de processus.

Dans l’épisode 2 nous allons voir comment le noyau gère la mémoire.

La mémoire dont nous parlons ici est la mémoire RAM physique installée sur l’ordinateur.

Nous avons vu dans l’épisode 1 que, lors du boot de l’ordinateur, le noyau est le premier programme monté en mémoire, et qu’il se verrouille dans une zone de haut privilège.

Le reste de la mémoire physique présente sur la machine est donc disponible pour que le noyau y fasse tourner des processus et y conserve des caches.

Pour faire tourner ces processus, la mémoire physique sera utilisée sous forme de mémoire virtuelle à base de pages.

Une page fait 4 Ko car c’est la taille standard pour la majorité des micro-processeurs, un bon compromis entre la gestion de la mémoire et les performances.

Pages physiques et pages virtuelles

La figure ci-dessus montre ce qui se passe réellement dans la machine.

Fonctionnalités du noyau Linux (Episode 1)

La tâche la plus difficile qu’on puisse concevoir en informatique est d’écrire un noyau de système d’exploitation. Seuls les développeurs les plus talentueux peuvent se lancer dans une telle tâche. Nous allons découvrir pourquoi en étudiant de plus près les fonctionnalités assurées par le noyau Linux, qui assure les fonctions d’un noyau Unix classique.

Le noyau Linux a été développé depuis 1991, initialement par un jeune informaticien finlandais nommé Linus Torvalds, puis au fil des années qui ont suivi avec la contribution de dizaines de milliers de développeurs dans le monde. Au fil des années, le noyau Linux est devenu ni plus ni moins que le plus grand projet collaboratif de l’histoire de l’humanité. La taille du code source du noyau Linux est réputée dépasser aujourd’hui plus de 40 millions de lignes de code : principalement du C, un peu d’assembleur, et une dynamique naissante pour y introduire du Rust.

Pour comprendre les fonctions qu’assure ce noyau, commençons par les aspects architecturaux de base.

La figure ci-dessus présente ce qui se passe sur une machine Linux allumée. La partie basse représente le matériel physique de la machine (clés USB, disques durs, cartes réseaux, clavier, souris, écran, etc.).

La partie milieu représente le noyau Linux. Seul ce noyau peut accéder au matériel, que ce soit en lecture ou en écriture.

La partie haute représente les applications qui tournent sur la machine (Firefox, etc.). Les applications ne peuvent en aucun cas accéder directement au matériel, elles ne peuvent que demander au noyau de le faire. Pour recueillir ces demandes, le noyau met à disposition des applications des appels systèmes, qui peuvent être appelés par les applications.

Parmi les applications, une a une importance particulière : le gestionnaire d’interface graphique. Historiquement les systèmes Unix, dont Linux, fonctionnaient avec un gestionnaire d’interface graphique appelé X-Window. X-Window avait des qualités : il était notamment nativement réseau, c’est-à-dire qu’une application lancée sur une machine A pouvait demander à apparaitre à l’écran d’une machine B. Pour cela il y avait une simple variable d’environnement à changer pour que le routage des fenêtres soit différent (on tapait par exemple export DISPLAY=machine_B :0 et l’application tournait sur la machine A mais ses fenêtres apparaissaient sur la machine B. C’était une époque très cool, on pouvait faire des plaisanteries envoyées sur les machines des copains). Mais X-Window avait aussi des défauts (parait-il), notamment de sécurité.

Sur les systèmes Linux modernes, Xfree86 (l’implémentation libre de X-Window) a donc été remplacé par Wayland, qui a les qualités et défauts inverses. Il n’a plus de problème de sécurité, il est probablement plus performant, mais il n’est plus réseau comme l’était X-Window.

Bref, quoi qu’il en soit, que l’on utilise X-Window ou Wayland, il y a toujours besoin de cette application un peu spéciale qu’est le gestionnaire d’interface graphique. Cette application gère les fenêtres graphiques et donc propose des primitives appelables par des environnements de bureau comme Gnome ou KDE, ou directement par vos applications graphiques si vous en programmez vous-même.