Greg Kroah-Hartman a publié une nouvelle règle sur la liste de diffusion du noyau le 4 août : drivers/staging n'acceptera plus les patchs générés par des grands modèles de langage. Le motif n'est pas que ces patchs seraient mauvais. C'est que le staging existe avant tout pour que les nouveaux contributeurs apprennent comment fonctionne le développement noyau, que les nettoyages faciles constituent le programme, et que les outils automatiques consomment ce programme plus vite que les humains ne l'atteignent. Une exception étroite subsiste, assortie d'une exigence difficile à simuler.
The short answer
Kroah-Hartman a annoncé que drivers/staging rejettera les patchs générés par des modèles de langage. Le motif tient à la vocation plutôt qu'à la qualité : le staging existe avant tout pour que les nouveaux développeurs apprennent le processus de contribution, et les nettoyages faciles sont leur matériau d'apprentissage. Une exception subsiste pour les patchs corrigeant un défaut réel, à condition d'avoir testé sur le matériel et de décrire comment. L'usage non déclaré est traité directement dans le message : cela se voit, et le taire n'apporte rien.
Il existe une version de cette histoire qui parle de machines qui écrivent du code, et c'est la version la moins intéressante. La règle publiée par Greg Kroah-Hartman le 4 août parle en réalité de ce à quoi sert un sous-système, et c'est l'une des formulations les plus claires que quiconque dans le monde du noyau ait données sur ce point.
La règle elle-même est courte. Les patchs générés par des grands modèles de langage ne seront pas acceptés dans drivers/staging. Non parce qu'ils seraient faux, même si une partie l'est, mais à cause de ce qu'est le staging.
Le staging est une salle de classe, et le désordre est la leçon
drivers/staging accueille des pilotes qui ne sont pas encore assez bons pour l'arbre principal du noyau. C'est toute sa définition. Le code a des violations de style, utilise des interfaces obsolètes, gère mal les erreurs, et la distance entre son état actuel et les attentes de mainline n'est pas un accident à résorber le plus vite possible.
Cette distance est une réserve de tâches petites, bien définies et réellement utiles. Corriger l'indentation. Faire migrer ce pilote depuis une API dépréciée il y a trois versions. Faire en sorte que ce chemin d'erreur libère vraiment ce qu'il avait alloué. Kroah-Hartman parle de fruits à portée de main, et c'est ainsi qu'une grande partie des développeurs noyau d'aujourd'hui ont appris le processus : trouver quelque chose de petit, écrire le patch, l'envoyer, se faire dire ce qui ne va pas, le renvoyer, le voir fusionné.
Un outil automatique peut cueillir tous ces fruits en un après-midi. S'il le fait, le nouveau venu qui arrive le mois suivant trouve un sous-système où plus rien n'est à sa portée, et la rampe d'accès qui en aurait fait un développeur noyau a disparu. C'est la perte que la règle protège, et elle est curieuse à expliquer à qui voit une file de patchs comme un arriéré à minimiser.
L'exception a du mordant
Une catégorie passe encore : les patchs qui corrigent un défaut réel. La condition est que le contributeur ait testé le correctif sur le matériel effectivement visé par le pilote, et qu'il décrive comment.
Cette condition fait le vrai travail, et elle est bien choisie. Produire un patch qui a l'air correct pour un pilote qu'on n'a jamais exécuté est facile et le devient de plus en plus. Produire un récit crédible de l'avoir éprouvé sur l'appareil ne l'est pas, car cela suppose de posséder ou d'atteindre du matériel souvent obscur dans le staging. L'exigence transforme une affirmation en quelque chose de vérifiable.
Kroah-Hartman a aussi chiffré la raison pour laquelle la barre se situe là plutôt qu'à la vraisemblance : environ un tiers des problèmes identifiés par machine dans ce domaine se révèlent incorrects ou franchement nuisibles. Quand le taux de faux positifs est à ce niveau, la relecture n'est plus un filtre bon marché. Le test, si.
Sur le fait de ne pas le dire
Le message ferme la porte au contournement évident. Kroah-Hartman écrit qu'il est très évident de repérer un patch généré par un modèle, et que personne ne devrait croire que le simple fait de ne pas le déclarer lui permettra de passer entre les mailles.
Venant d'un mainteneur qui a traité un volume extraordinaire de patchs noyau en deux décennies, l'affirmation mérite d'être crue. Les soumissions générées par machine portent des signatures reconnaissables : la formulation des messages de commit, la forme du changelog, les nettoyages qui se retrouvent groupés et ceux qui ne le sont jamais. Le marché proposé à qui serait tenté est mauvais, puisque la récompense est le crédit d'un patch de faible valeur par construction et le risque est l'opinion d'un mainteneur à votre sujet.
Ce que cela signifie, et ce que cela ne signifie pas
Gardez la portée en tête, car c'est là que l'histoire va se déformer.
La règle couvre drivers/staging. Elle ne couvre pas le reste du noyau, où la conversation plus large sur la déclaration et la documentation des contributions assistées par outil se poursuit sans avoir conclu. Il s'agit d'un mainteneur qui applique une règle adaptée à la vocation particulière d'un sous-système, pas d'une position à l'échelle du noyau.
Il vaut aussi la peine de remarquer quel type d'argument l'a emporté. La thèse retenue n'était pas que la production est peu fiable, ce qui aurait appelé une réplique sur des modèles meilleurs. C'était que ce sous-système fabrique autre chose que du code, et que cette autre chose est rare. Cet argument ne faiblit pas à mesure que les outils progressent. Il se renforce.
Sources et pour aller plus loin
- Linux's staging area to now reject LLM generated patches, except for real security fixes, Phoronix, 4 août 2026
- Toward a policy for machine learning tools in kernel development, LWN.net
- Documentation du noyau : soumettre des patchs
- A new kernel tree: linux-staging, LWN.net, sur la vocation initiale du sous-système
Questions fréquentes
Est-ce que cela interdit l'aide de l'IA dans tout le noyau Linux ?
Non, et cette limite de portée est la partie la plus mal rapportée. La règle s'applique à drivers/staging et à rien d'autre. En dehors de ce sous-système, la politique du noyau sur les contributions générées par machine reste ce qu'elle était, et la discussion plus large sur la façon de documenter et de déclarer l'assistance par outil est toujours en cours plutôt que tranchée. Ce que Kroah-Hartman a fait, c'est isoler un sous-système à la vocation particulière et lui appliquer une règle adaptée à cette vocation. Y lire une interdiction à l'échelle du noyau se trompe sur la lettre comme sur l'intention.
Pourquoi viser le staging plutôt qu'un autre sous-système ?
Parce que le staging est la seule partie de l'arbre dont les problèmes de qualité sont délibérés. drivers/staging accueille des pilotes qui ne sont pas encore assez bons pour l'arbre principal, et l'écart entre leur état actuel et les standards de mainline est justement le sujet. Cet écart constitue une réserve de tâches petites, abordables et réellement utiles : corrections de style, migrations d'API obsolètes, nettoyage de la gestion d'erreurs. Ces tâches sont la façon dont une grande partie des développeurs noyau ont appris le processus, du premier patch à la fusion en passant par la relecture. Un outil automatique peut vider cette réserve rapidement, et s'il le fait, l'échelle que gravissent les débutants disparaît. Kroah-Hartman le dit sans détour : le staging existe avant tout comme endroit où les nouveaux développeurs apprennent à s'impliquer.
En quoi consiste exactement l'exception ?
Les patchs qui corrigent un vrai défaut peuvent encore être acceptés, mais le contributeur doit avoir testé le correctif sur le matériel réellement visé par le pilote, et doit décrire comment il l'a fait dans sa soumission. Cette exigence fait l'essentiel du travail. Un outil peut produire un patch d'apparence plausible pour un pilote dont personne n'a le matériel ; il ne peut pas produire un récit crédible de l'avoir exécuté sur l'appareil. Kroah-Hartman a relevé qu'une part importante des problèmes identifiés par machine dans ce domaine, environ un tiers, se révèlent faux ou franchement nuisibles, ce qui explique que la barre soit le test plutôt que l'argumentation.
Puis-je simplement ne pas mentionner que j'ai utilisé un outil ?
Kroah-Hartman a traité cette hypothèse dans son message et n'a laissé aucune ambiguïté : il est très évident de reconnaître un patch généré par un modèle, et personne ne devrait imaginer qu'omettre la mention lui apporte quoi que ce soit. Cela mérite d'être pris au sérieux de la part de quelqu'un qui a traité un volume énorme de patchs noyau. Les soumissions générées par machine ont des signatures reconnaissables : la formulation, la structure des messages de commit, la façon dont certains nettoyages sont regroupés. La conséquence pratique, c'est qu'un usage non déclaré est un risque de réputation auprès d'un mainteneur que vous préféreriez avoir de votre côté, en échange d'un patch de faible valeur par définition.
Que faire si je voulais contribuer au staging ?
Faites-le lentement, parce que dans ce sous-système la lenteur est précisément le produit. Choisissez un pilote, lisez-le vraiment, passez checkpatch dessus, trouvez quelque chose de réellement fautif et écrivez le correctif vous-même. Si vous possédez le matériel visé par le pilote, c'est un avantage considérable et il faut le dire. Ce que vous optimisez n'est pas le patch, c'est l'apprentissage de la boucle soumission et relecture auprès d'un mainteneur particulièrement disposé à l'enseigner. Utiliser un outil pour sauter cette étape revient à dépenser l'occasion sans en garder le bénéfice.