Linux Kernel Devs Keep Removing Ancient Drivers

SYNTHÈSE STRUCTURÉE

Le noyau Linux n’est pas anti-IA, mais il a des règles

L’auteur rappelle qu’en juillet, Linus Torvalds a clarifié que le noyau n’est pas un projet anti-IA. Cependant, cela ne signifie pas que tout est permis. Les processus de revue et les bonnes pratiques restent fondamentaux. L’intervenant cite Torvalds : « Le noyau Linux n’est pas un projet anti-IA. Mais ce n’est pas non plus un projet où tous les processus ont été jetés par la fenêtre. » Autrement dit, l’IA peut aider, mais elle ne remplace ni la relecture humaine ni la validation technique.

La politique de Greg Kroah-Hartman pour drivers/staging

Greg Kroah-Hartman, considéré comme le « second » du noyau, a publié une politique claire concernant les correctifs générés par LLM dans drivers/staging. Cette partie du noyau est volontairement laissée « brute » pour servir de terrain d’apprentissage aux nouveaux développeurs. L’intervenant explique : « Nous ne prenons pas les correctifs de type “corrige tous les problèmes de style dans ce fichier” générés par des outils, car cela détruirait tout l’intérêt de drivers/staging. » L’objectif est de laisser des problèmes simples à corriger pour que les débutants puissent apprendre le processus.

Les LLM sont détectables et souvent faux

L’intervenant souligne que les mainteneurs peuvent repérer les patchs générés par IA, notamment par une documentation excessive et artificielle. Il cite Kroah-Hartman : « Les LLM sont très bons pour trouver des problèmes de sécurité suspects, mais même avec les meilleurs outils actuels, au moins un tiers des résultats sont complètement faux ou nuisibles. » Il insiste sur l’importance de tester sur du matériel réel avant de soumettre un correctif, et de pouvoir défendre sa proposition.

Le problème des correctifs en masse sur les anciens drivers

La vidéo met en lumière un phénomène récent : les LLM génèrent des correctifs en très grand nombre, notamment pour des drivers réseau très anciens, souvent plus maintenus et sans utilisateurs connus. L’intervenant donne l’exemple de 347 CVE publiées en une journée, et cite un mainteneur réseau : « 37 % des patchs postés sont des correctifs, c’est assez fou. » Cette avalanche submerge les mainteneurs et les force à trier en permanence.

Le cas de SyzBot et des agents IA

Un mainteneur du sous-système wireless a pris une position ferme contre les patchs générés par SyzBot, un outil de fuzzing automatisé. Il refuse de discuter avec un LLM et exige qu’un humain prenne la responsabilité des correctifs. L’intervenant cite ce mainteneur : « Je vais utiliser judicieusement ma capacité à ignorer les patchs et l’appliquer à presque tous les patchs générés par SyzBot, sauf si une revue de trois secondes montre que c’est évidemment correct. » Le problème n’est pas l’outil, mais l’absence de relecture humaine sérieuse.

La suppression des drivers obsolètes

Face à l’afflux de rapports sur des drivers que personne n’utilise, les mainteneurs choisissent de les supprimer. L’intervenant cite un exemple concret : « Le driver Moxa est très ancien, aucun matériel connu n’existe plus, et l’entreprise dit ne plus en avoir besoin. Supprimons-le. » Il précise que ces suppressions se font un patch à la fois, pour permettre un éventuel retour si un utilisateur se manifeste.

L’importance de prouver l’usage réel

L’intervenant insiste sur le fait que les mainteneurs ne suppriment pas les drivers par méchanceté, mais par manque de preuves d’utilisation. Il cite un mainteneur : « Si quelqu’un a vraiment besoin de ce driver, qu’il se manifeste, qu’il montre qu’il l’utilise avec un noyau moderne, et on le gardera. » Il donne l’exemple du driver PlayStation 3, qui a été conservé après qu’un utilisateur a témoigné de son usage.

Les drivers GPU comme exemple positif

Contrairement aux vieux drivers réseau, certains drivers GPU bénéficient réellement de l’IA. L’intervenant cite l’exemple des GPU AMD HD 7000, où des améliorations ont été apportées grâce à des correctifs générés par IA, car des utilisateurs existent et peuvent tester. Cela montre que l’IA peut être utile quand elle est encadrée par des humains compétents et du matériel disponible.

La nostalgie ne suffit pas

L’intervenant critique ceux qui s’opposent à la suppression de drivers sans les utiliser réellement. Il déclare : « Si vous voulez qu’un driver reste, venez sur la liste de diffusion, dites “j’ai ce matériel, je l’utilise, ne le supprimez pas”. Sinon, taisez-vous. » Il rappelle que les drivers peuvent être compilés hors arbre, donc la suppression du noyau n’est pas une perte définitive.

CONCEPTS CLÉS

• drivers/staging : sous-système du noyau Linux volontairement maintenu avec des imperfections, servant de zone d’apprentissage pour les nouveaux contributeurs.
• SyzBot : outil de fuzzing automatisé qui génère des rapports de bugs et des correctifs, souvent utilisés par des LLM pour produire des patchs en masse.
• Patchset : ensemble de correctifs soumis pour révision, souvent tagué avec PatchNet ou PatchNet Next pour indiquer la branche cible.
• BKL era code : code datant de l’époque du Big Kernel Lock, un verrou global du noyau, considéré comme obsolète et difficile à maintenir.
• Out-of-tree build : compilation d’un module ou driver en dehors de l’arborescence du noyau, permettant de l’utiliser sans l’intégrer officiellement.

CONCLUSION

La vidéo montre que le noyau Linux n’est pas hostile à l’IA, mais qu’il refuse de laisser les outils générer des correctifs sans supervision humaine sérieuse. Les mainteneurs exigent des preuves de test matériel, une relecture attentive et une responsabilité claire de la part des contributeurs. Les drivers obsolètes sont supprimés non par idéologie, mais parce qu’ils deviennent une charge de maintenance insoutenable face à l’afflux de rapports automatisés. Si vous utilisez réellement un vieux driver, manifestez-vous ; sinon, laissez la place aux projets qui avancent.