Le développement est hiérarchique : chaque sous-système a son dépôt, exemples : le réseau ou le son (ALSA). À vrai dire, il existe des dizaines et des dizaines de dépôts. Tu peux avoir un petit aperçu par ici : http://git.kernel.org/
Disons qu'il y a deux types de commits : patchs pour améliorer un sous-système dans un dépôt (autre que celui de Linus), et acceptation (merge) des modifications depuis un dépôt tiers dans le dépôt de Linus. Je dis que le développement est hiérarchique car tu peux avoir plusieurs "couches" de dépôts (ex: dépôt d'une personne qui contient un patch spécifique => dépôt du sous-système => dépôt de Linus).
Beaucoup de code est écrit sous forme de patchs soumis sur des listes de diffusion, comme par exemple la "LKML", mais ça peut aussi être sur la liste de diffusion d'un sous-système. Ces patchs sont relus par tous les abonnés à la liste de diffusion qui sont intéressés par la fonctionnalité. Vu le nombre de messages quotidiens sur la LKML, je pense qu'il y a pas mal de monde qui relit les patchs (mais toutes les personnes postant sur la LKML ne sont pas capable de relire tous les patchs bien sûr).
Si le patch ne respecte pas le style de code imposé par le noyau, utilise une ancienne API, n'est pas assez générique, etc. : un nouveau patch sera exigé. Si la fonctionnalité est critique, il peut avoir plus d'une dizaine de versions d'un patch avant qu'il soit appliqué. Le patch "eventfd" (noyau 2.6.22) a par exemple exigé 26 versions avant d'être commité :-)
y'a t-il des tests unitaires ou à défaut des tests plus larges de non régression ?
Les phases de RC visent à dégrossir les régressions. Le site Kernel Oops liste les régressions : http://www.kerneloops.org/
(on y trouve des stat' intéressantes)
Il y a beaucoup d'outils d'analyse statique du code : kmemcheck, kmemleak, Sparse, etc. (développés spécifiquement pour le noyau Linux) J'ai même vu des motivés qui ont portés Valgrind pour tester le noyau Linux (un truc avec QEMU, je me souviens mal).
Pour les tests automatiques, je n'en connais pas, mais il en existe peut-être. Je pense que les bugs sur les composants critiques (ex: gestion de la mémoire ou ordonnanceur de processus) sont détectés très rapidement, un bug sur un pilote d'un matériel désuet sera détecté beaucoup plus difficile car qu'un testeur ait ce matériel.
Comme le code source de Linux est ouvert, il y a énormément de monde qui le relit pour apprendre à programmer, pour valider le code d'un pilote, ou encore pour traquer des failles de sécurité. Il existe aussi des logiciels de fuzzing spécifiques au noyau.
y'a t-il des relectures de code, si oui sur tous les commits ? qui relit ?
Comme dit, les patchs soumis sur les listes de diffusion sont relus par plusieurs personnes différentes. Je doute qu'une ligne de code ne soit commité sans avoir été relue par plusieurs personnes. D'ailleurs, depuis que git est utilisé, un commit peut être signé par plusieurs personnes (peut-être que c'était déjà possible avec BitKeeper, je sais pas). Exemple sur l'avant dernier commit du dépôt de Linus : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
Le commit a été signé par Julia Lawall (auteure du patch) et Ralf Baechle (qui a commité le patch). Tiens, ce patch corrige un bug trouvé par un autre outil d'analyse de code automatique : http://coccinelle.lip6.fr/
--
Je ne suis pas développeur noyau, juste spectateur, je peux donc raconter des conneries. Mais j'espère t'avoir éclairé un peu ;-) Sinon il existe des nombreux documents qui expliquent comment le noyau Linux est développé (y'a même des analyses sociologiques ;-)).
[^] # Re: Tests automatiques ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 10.
Le développement est hiérarchique : chaque sous-système a son dépôt, exemples : le réseau ou le son (ALSA). À vrai dire, il existe des dizaines et des dizaines de dépôts. Tu peux avoir un petit aperçu par ici : http://git.kernel.org/
Par contre, pour le tarball du noyau Linux saveur vanille, c'est le dépôt Linus qui est utilisé :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
Disons qu'il y a deux types de commits : patchs pour améliorer un sous-système dans un dépôt (autre que celui de Linus), et acceptation (merge) des modifications depuis un dépôt tiers dans le dépôt de Linus. Je dis que le développement est hiérarchique car tu peux avoir plusieurs "couches" de dépôts (ex: dépôt d'une personne qui contient un patch spécifique => dépôt du sous-système => dépôt de Linus).
Beaucoup de code est écrit sous forme de patchs soumis sur des listes de diffusion, comme par exemple la "LKML", mais ça peut aussi être sur la liste de diffusion d'un sous-système. Ces patchs sont relus par tous les abonnés à la liste de diffusion qui sont intéressés par la fonctionnalité. Vu le nombre de messages quotidiens sur la LKML, je pense qu'il y a pas mal de monde qui relit les patchs (mais toutes les personnes postant sur la LKML ne sont pas capable de relire tous les patchs bien sûr).
Si le patch ne respecte pas le style de code imposé par le noyau, utilise une ancienne API, n'est pas assez générique, etc. : un nouveau patch sera exigé. Si la fonctionnalité est critique, il peut avoir plus d'une dizaine de versions d'un patch avant qu'il soit appliqué. Le patch "eventfd" (noyau 2.6.22) a par exemple exigé 26 versions avant d'être commité :-)
y'a t-il des tests unitaires ou à défaut des tests plus larges de non régression ?
Les phases de RC visent à dégrossir les régressions. Le site Kernel Oops liste les régressions :
http://www.kerneloops.org/
(on y trouve des stat' intéressantes)
Il y a beaucoup d'outils d'analyse statique du code : kmemcheck, kmemleak, Sparse, etc. (développés spécifiquement pour le noyau Linux) J'ai même vu des motivés qui ont portés Valgrind pour tester le noyau Linux (un truc avec QEMU, je me souviens mal).
Pour les tests automatiques, je n'en connais pas, mais il en existe peut-être. Je pense que les bugs sur les composants critiques (ex: gestion de la mémoire ou ordonnanceur de processus) sont détectés très rapidement, un bug sur un pilote d'un matériel désuet sera détecté beaucoup plus difficile car qu'un testeur ait ce matériel.
Comme le code source de Linux est ouvert, il y a énormément de monde qui le relit pour apprendre à programmer, pour valider le code d'un pilote, ou encore pour traquer des failles de sécurité. Il existe aussi des logiciels de fuzzing spécifiques au noyau.
y'a t-il des relectures de code, si oui sur tous les commits ? qui relit ?
Comme dit, les patchs soumis sur les listes de diffusion sont relus par plusieurs personnes différentes. Je doute qu'une ligne de code ne soit commité sans avoir été relue par plusieurs personnes. D'ailleurs, depuis que git est utilisé, un commit peut être signé par plusieurs personnes (peut-être que c'était déjà possible avec BitKeeper, je sais pas). Exemple sur l'avant dernier commit du dépôt de Linus :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
Le commit a été signé par Julia Lawall (auteure du patch) et Ralf Baechle (qui a commité le patch). Tiens, ce patch corrige un bug trouvé par un autre outil d'analyse de code automatique : http://coccinelle.lip6.fr/
--
Je ne suis pas développeur noyau, juste spectateur, je peux donc raconter des conneries. Mais j'espère t'avoir éclairé un peu ;-) Sinon il existe des nombreux documents qui expliquent comment le noyau Linux est développé (y'a même des analyses sociologiques ;-)).