Processus de développement de Linux

Le logiciel libre et les distributions GNU/Linux ont apporté un changement radical dans la façon dont les systèmes d'exploitation sont développés, en construisant une communauté de développement autour d'Internet.

Ce développement en communauté sur Internet possède les caractéristiques suivantes qui sont détaillées dans la suite de cet article :

Le processus de développement est public sur Internet : le code source est librement accessible ; les modifications des sources sont publiées sur Internet et revues par la communauté avant d'être incluses dans la branche principale.
Le cycle de développement est rapide et incrémental : le cycle de parution de nouvelles versions est de l'ordre de deux mois aujourd'hui contre plusieurs années pour les systèmes d'exploitation propriétaires concurrents. Ce cycle incrémental rapide permet d'obtenir plus rapidement des retours des utilisateurs et ainsi de mieux maîtriser la complexité inhérente au développement d'un système d'exploitation moderne.
Cette méthode de développement a généré son propre outil de gestion de versions (Git) adapté à un développement décentralisé.

Ce cycle rapide n'est pas adapté à la majorité des usages industriels ou personnels. Interviennent alors les distributions GNU/Linux dont le principal rôle est d'apporter la stabilité en fournissant des versions du noyau Linux à un rythme plus lent et en maintenant ces versions sur plusieurs années.

Un processus de développement public sur Internet

Greg Kroah-Hartman a expliqué pour Groklaw^[1] le processus de développement du noyau Linux. Greg Kroah-Hartman écrit des pilotes Linux depuis 1999, et est actuellement le mainteneur de certains sous-systèmes du noyau (USB, driver core, sysfs, linux-hotplug, udev, etc.).

Le concept de patch

Pour comprendre comment ce processus fonctionne, il faut d'abord comprendre ce qu'est un patch (ou rustine en français). Pour faire accepter une modification dans le noyau, les développeurs doivent produire un patch et l'envoyer au mainteneur du code qu'ils souhaitent modifier. Pour cela, ils effectuent leurs changements dans le code source du noyau, puis utilisent l’outil diff. Cet outil génère un fichier en format texte (le fichier patch) qui liste les lignes modifiées dans leur état d'avant et après modification, comme le montre l'exemple ci-dessous :

--- a/drivers/usb/image/microtek.c
+++ b/drivers/usb/image/microtek.c
@@ -335,7 +335,7 @@ static int mts_scsi_abort (Scsi_Cmnd *sr
        mts_urb_abort(desc);
-       return FAILURE;
+       return FAILED;
 }
static int mts_scsi_host_reset (Scsi_Cmnd *srb)

L'exemple montre que le fichier 'drivers/usb/image/microtek.c' a une ligne qui était avant changement :

return FAILURE;

et est maintenant après changement :

return FAILED;

Ce fichier texte peut être envoyé par courriel à d'autres personnes, qui peuvent voir immédiatement les lignes de code qui ont été changées et donner leur avis sur cette modification. Pour appliquer le patch, il suffit ensuite de lancer un autre programme appelé patch en lui passant en paramètre le fichier de patch.

La totalité du développement du noyau Linux est effectuée en envoyant publiquement des patchs par courrier électronique. En jetant un coup d'œil à la liste de diffusion principale du développement du noyau (par exemple à http://marc.theaimsgroup.com/?l=linux-kernel), on peut voir des centaines de ces patchs envoyés à la ronde, discutés, critiqués.

La chaîne de production et de traitement des patchs

L'équipe de développement du noyau est un groupe de personnes qui se sont structurés en une pseudo-pyramide. À la base de la pyramide se trouvent les centaines de développeurs qui écrivent entre 1 et quelques milliers de patchs. Ces développeurs envoient leurs patchs au mainteneur du fichier ou groupe de fichiers qu'ils ont modifiés. La liste des mainteneurs est conservée dans le fichier MAINTAINERS qui se trouve dans les sources de la branche de développement principale du noyau. Il y a actuellement environ 300 mainteneurs différents.

Si le mainteneur estime que la modification est justifiée et l'approuve, il l'envoie alors au mainteneur du sous-système du noyau concerné. Il y a des mainteneurs pour presque tous les sous-systèmes du noyau (réseau, pilotes USB, Virtual File System, module core, driver core, pilotes Firewire, pilotes réseau, etc.) Ces personnes sont également listées dans le fichier MAINTAINERS et tous les mainteneurs de fichiers individuels ou de pilotes savent à qui adresser leurs modifications.

Les mainteneurs de sous-système envoient ensuite les patchs pour qu'ils soient approuvés par Linus Torvalds ou Andrew Morton et c'est alors que le patch est inclus dans la branche de développement principale du noyau.

Il faut noter que chaque personne qui touche un patch le long de cette chaîne de transmission ajoute au code une ligne "Signed-off-by:" qui montre exactement qui est à l'origine de la modification et par qui elle a été approuvée. En cas de bogue, les personnes à blâmer sont immédiatement identifiables.

La publication des patchs sur les listes de diffusion

Tous les développements sont faits par courrier électronique. Les développeurs envoient les patchs par courriel aux autres développeurs sur les différentes listes de diffusion. Il existe une liste principale linux-kernel. Cette liste reçoit environ 200 à 300 messages par jour et presque tous les aspects du noyau y sont discutés. En raison de son fort trafic, toutes les sous-sections du noyau ont établi leurs propres listes de diffusion, pour travailler ensemble dans un domaine spécifique.

Les messages postés sur ces listes de diffusion sont archivés sur des sites spécialisés, par exemple « http://marc.theaimsgroup.com/ »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)} et http://www.gmane.org, qui permettent la consultation et la recherche des messages diffusés dans le passé.

Ainsi un patch est posté sur une liste de diffusion. D'autres développeurs en font la revue, offrent des suggestions avec copie sur la liste pour informer tout le monde. Finalement un consensus est trouvé et le patch est accepté par le mainteneur pour le transmettre plus haut dans la chaîne.

Pour illustrer ce fonctionnement, prenons l'exemple d'Arjan Van de Ven, un développeur du noyau Linux, et son projet Fastboot de réduire le temps de démarrage d'un système GNU/Linux.

Ayant réfléchi à tout ce qui pouvait être facteur de ralentissement au démarrage du noyau, Arjan a proposé une solution sous forme d'un ensemble de 3 patchs. Ces patchs peuvent être vus ici :

 patch 0/3: fastboot patches series 1
 patch 1/3: fastboot: Create a "asynchronous" initlevel
 patch 2/3: fastboot: turn the USB hostcontroller initcalls into async initcalls
 patch 3/3: fastboot: convert a few non-critical ACPI drivers to async initcalls

Un certain nombre de développeurs sont intervenus, le fil de discussion peut être suivi ici :

   http://thread.gmane.org/gmane.linux.kernel/709026/focus=709139

Et puis Linus Torvalds est intervenu et a estimé que la solution n'était pas satisfaisante car pas au bon niveau de granularité :

   http://article.gmane.org/gmane.linux.kernel/743021/

L'auteur original a pris en compte les remarques de Linus et fait une nouvelle proposition avec la série de patchs suivants :

   http://article.gmane.org/gmane.linux.acpi.devel/36513

qui ont été de nouveau commentés, et le développement a continué.

Comme le montre l'exemple ci-dessus, tout le développement du noyau est public, visible par tous, archivé en public de nouveau pour tous. Cette revue publique des modifications de code du noyau Linux par de multiples paires d'yeux est un élément essentiel car elle permet d'inscrire la qualité dans le processus de développement.

Un cycle de développement rapide et incrémental

Publier tôt, publier souvent est une règle fondamentale pour le développement des logiciels libres.

Au début du développement du noyau Linux (vers 1991), il n'était pas rare que Linus Torvalds publie une nouvelle version du noyau Linux plusieurs fois par jour. Avec ce modèle de développement, Linus impliquait ses utilisateurs dans le processus de développement d'une façon très efficace. Et cette manière de cultiver sa communauté de codéveloppeurs et d'utiliser Internet comme outil de collaboration comme personne d'autre ne l'a fait avant lui ont été des facteurs-clés dans le succès du noyau Linux.

Cycle de développement du noyau Linux

Article détaillé : noyau Linux.

Depuis ce tout début, ce cycle de développement s'est un peu ralenti, cependant le noyau Linux continue à évoluer à un rythme très rapide comparé aux logiciels à source fermé (Windows XP en 2001, Windows Vista en 2007) : une version 2.6.x toutes les 8 à 12 semaines comme indiqué dans le tableau ci-dessous :

Version du noyau	2.6.0	2.6.1	2.6.2	2.6.3	2.6.4	2.6.5
Date de sortie	18 décembre 2003	9 janvier 2004	4 février 2004	18 février 2004	11 mars 2004	4 avril 2004
Version du noyau	2.6.6	2.6.7	2.6.8	2.6.9	2.6.10	2.6.11
Date de sortie	10 mai 2004	16 juin 2004	14 août 2004	18 octobre 2004	24 décembre 2004	2 mars 2005
Version du noyau	2.6.12	2.6.13	2.6.14	2.6.15	2.6.16	2.6.17
Date de sortie	17 juin 2005	29 août 2005	28 octobre 2005	3 janvier 2006	20 mars 2006	18 juin 2006
Version du noyau	2.6.18	2.6.19	2.6.20	2.6.21	2.6.22	2.6.23
Date de sortie	20 septembre 2006	29 novembre 2006	4 février 2007	25 avril 2007	8 juillet 2007	9 octobre 2007
Version du noyau	2.6.24	2.6.25	2.6.26	2.6.27	2.6.28	2.6.29
Date de sortie	24 janvier 2008	17 avril 2008	13 juillet 2008	9 octobre 2008	24 décembre 2008	23 mars 2009
Version du noyau	2.6.30	2.6.31	2.6.32	2.6.33	2.6.34	2.6.35
Date de sortie	9 juin 2009	9 septembre 2009	3 décembre 2009	24 février 2010	16 mai 2010	3 août 2010

Les différentes branches de développement

Aujourd'hui le développement du noyau Linux est effectué dans plusieurs branches :

la branche principale (nommée aussi "2.6.x kernel tree" ou "Linus tree")
la branche stable (appelée aussi "2.6.x.y stable tree")
les versions quotidiennes ("git daily snapshots")
les patchs expérimentaux d'Andrew Morton
les patchs et versions spécifiques de sous-systèmes du noyau

La gestion de versions du noyau

Jusqu'en avril 2005, l'équipe de développement du noyau utilisait un logiciel commercial BitKeeper pour la gestion des versions des sources du noyau. Le 5 avril 2005, la société BitMover annonça qu'elle se concentrait exclusivement sur son offre commerciale BitKeeper et qu'elle retirait le client gratuit (mais non libre) utilisé par un certain nombre de développeurs libres.

Cet événement a conduit les développeurs du noyau Linux à inventer leur propre outil de gestion de versions qui a été appelé Git.

Les distributions GNU/Linux

Pour appréhender le rôle des distributions GNU/Linux il est important d'avoir quelques notions sur le périmètre du noyau Linux et sa modularité.

Périmètre du noyau Linux : le noyau, la branche du noyau et les distributions GNU/Linux

Le périmètre du noyau Linux est souvent mal compris car le même terme Linux est utilisé pour le noyau Linux (le kernel lui-même), la branche du noyau (kernel tree) et les distributions GNU/Linux, qui ont chacun un périmètre de plus en plus grand comme le montre la figure ci-dessous. Une distribution GNU/Linux est un assemblage de milliers de paquets logiciels et de la branche du noyau, comprenant elle-même le noyau, les pilotes et les composants réseau et systèmes de fichier.

Modularité du noyau Linux

Si la philosophie Unix, qui sous-tend également celle du noyau Linux, devait être résumée en un seul mot, ce mot serait probablement celui de modularité. Unix a été développé à l'origine avec l'objectif d'être hautement modulaire pour être plus flexible et convivial que les systèmes d'exploitation monolithiques et complexes de l'époque. Cette modularité a perduré et a été constamment retravaillée au cours des quelque 35 ans d'existence de systèmes d'exploitation de type Unix ; elle a constitué un facteur majeur de leur remarquable durée de vie et constante popularité malgré leur âge (qui est important suivant les standards de l'informatique).

GNU/Linux est un système d'exploitation très modulaire. L'utilisateur peut installer seulement les parties qui lui conviennent. Dans la plupart des cas il choisira les installations par défaut proposées dans les menus d'installation, mais il n'y est pas obligé. S'il installe par exemple un serveur, il est possible de désactiver l'interface graphique de façon à libérer la mémoire et le processeur pour d'autres tâches.

La modularité commence avec le noyau. Même quand les utilisateurs ne compilent pas leur propre noyau, la présence de l'amorceur système (qui peut être lui-même GRUB ou LILO) est un rappel qu'ils ne sont pas limités à un seul noyau installé. Quand les utilisateurs compilent leur propre noyau, ils apprennent que son contenu est configurable et que de nombreux pilotes peuvent être chargés comme modules par le système quand ils sont requis plutôt que d'être compilés dans le noyau.

La même modularité se retrouve au niveau des sous-systèmes. Le noyau fonctionne avec plus de 30 systèmes différents de gestion de fichiers. La gestion de paquets logiciels a deux principaux formats, RPM et Debian, ainsi que plusieurs plus récents tels que Portage de la distribution Gentoo. D'autres systèmes alternatifs sont encore en développement.

Les sous-systèmes continuent à évoluer. Prenons l'exemple de lpd, le système d'impression d'origine, venant de l'Unix de Berkeley. Il a été étendu au fil des années par LPRng, puis remplacé par CUPS (Common UNIX Printing System). De façon identique, quand il y a quelques années XFree86 est devenu inacceptable à cause d'un changement dans sa licence qui le rendait non libre, X.org un fork d'une version précédente de XFree86 l'a remplacé. Plus récemment ALSA est venu se substituer à OSS (Open Sound System) dans de nombreuses distributions.

L'histoire se répète dans l'interface utilisateur. Le shell par défaut dans la plupart des distributions est GNU bash, qui a évolué au fil des ans. Cependant il existe plus d'une demi-douzaine de substituts possibles, citons tcsh, csh, pdksh, zsh et BusyBox.

Il existe la même diversité pour l'environnement de bureau. KDE et GNOME sont les environnements les plus communs, mais certains utilisateurs qui privilégient la performance sur la simplicité d'utilisation adopteront par exemple IceWM en lieu et place de KDE ou GNOME. En ce qui concerne le gestionnaire de fenêtres, KDE a choisi KWM alors que GNOME a choisi Metacity mais ces gestionnaires par défaut peuvent être remplacés par des douzaines d'alternatives.

Cette modularité permet aussi de mettre à jour certaines parties du système sans affecter le reste du système. Par exemple, il est possible d'installer la dernière version de GNOME ou KDE sans changer de version du noyau.

Rôle des distributions GNU/Linux

Cette liberté de choix n'est pas forcément adaptée à tous les utilisateurs. C'est là qu'entrent en jeu les distributions GNU/Linux.

Comme le notait Ian Murdock, le fondateur de la distribution Debian, dans un manifeste en 1993 :

Les distributions sont essentielles pour le futur de Linux. Elles dispensent l'utilisateur d'avoir à localiser, télécharger, compiler et installer et elles intègrent un nombre tout à fait considérable d'outils essentiels pour assembler un système Linux qui fonctionne. La charge de construction du système est placée sur les épaules du créateur de la distribution et son travail peut être partagé avec des milliers d'autres utilisateurs. Presque tous les utilisateurs de Linux vont faire leurs premières armes avec une distribution et la plupart d'entre eux vont continuer à utiliser une distribution par souci de facilité même après s'être familiarisés avec le système.

Les distributions GNU/Linux ont effectivement un rôle important dans l'éco-système construit autour du noyau Linux.

Elles rassemblent les meilleurs paquets logiciels (par exemple la distribution Debian inclut plus de 10 000 paquets logiciels) dans une offre intégrée et adaptée à leurs utilisateurs ou clients.

De plus, peu de personnes et encore moins de sociétés peuvent se permettre de suivre le cycle rapide de 8-12 semaines de sortie des versions du noyau. Les distributions fournissent un cycle plus adapté à leurs besoins. La fréquence de sortie de nouvelles versions est laissé à l'appréciation de chaque distribution et peut aller de six mois pour les plus à la pointe comme Fedora ou Ubuntu, de 12 à 18 mois pour les distributions plus commerciales comme Red Hat, SuSE et jusqu’à deux ans pour Debian.

Cycle de développement de quelques distributions GNU/Linux

Le cycle de développement de la distribution Red Hat

Le cycle de développement de la distribution Debian

Notes et références

↑ « Groklaw - How The Kernel Development Process Works, by Greg Kroah-Hartman », sur groklaw.net (consulté le 22 avril 2021).

Voir aussi

Liens internes

[1] « Groklaw - How The Kernel Development Process Works, by Greg Kroah-Hartman », sur groklaw.net (consulté le 22 avril 2021).

[1]