Processus de développement de Linux - Définition

Introduction

Linux a 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 pour la fourniture 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 configuration (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 Linux dont le principal rôle est d'apporter la stabilité en fournissant des versions de 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 le processus de développement de 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 lancent un outil appelé '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 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'oeil à 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. A 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 fichier individuels ou de pilotes savent à qui adresser leurs modifications.

Les mainteneurs de sous-système envoient ensuite les patchs qu'ils ont approuvés à 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 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.