Christoph Hellwig, mainteneur des sous-syst\u00e8mes DMA, KVM, Slab Allocator et de l'architecture PowerPC dans le noyau Linux, ancien membre du comit\u00e9 technique de la Linux Foundation et plaignant dans un litige li\u00e9 \u00e0 la GPL contre VMware, a refus\u00e9 de valider les correctifs relatifs au support du d\u00e9veloppement de pilotes en langage Rust. Les correctifs propos\u00e9s ajoutaient des wrappers autour de plusieurs fonctions du sous-syst\u00e8me DMA, permettant d'utiliser DMA dans les pilotes \u00e9crits en Rust. <\/p>\n
Comme raison de son refus, il a \u00e9t\u00e9 mentionn\u00e9 que cela compliquerait la maintenance du code avec des wrappers pour d'autres langages et que l'on souhaitait conserver les interfaces logicielles du DMA sous une forme lisible en C, sans les diluer dans des wrappers obscurs. Christoph a propos\u00e9 d'acc\u00e9der directement \u00e0 l'API C d'origine du DMA dans chaque pilote \u00e9crit en Rust, afin de ne pas cr\u00e9er d'abstractions suppl\u00e9mentaires dont la maintenance du noyau serait contrainte. <\/p>\n
Les d\u00e9veloppeurs des patchs ont d\u00e9clar\u00e9 qu'ils prendraient en charge tout le travail de maintenance du code en Rust, qu'ils \u00e9taient pr\u00eats \u00e0 g\u00e9rer ces patchs eux-m\u00eames et qu'ils ont d\u00e9plac\u00e9 les wrappers dans un sous-r\u00e9pertoire s\u00e9par\u00e9 (rust\/kernel\/dma.rs). En r\u00e9ponse, Christoph a mis son veto (\u00ab Nacked-by \u00bb) \u00e0 l'acceptation des patchs li\u00e9s \u00e0 Rust et a indiqu\u00e9 qu'il ne voulait pas d'un autre mainteneur. Christoph a affirm\u00e9 que si les d\u00e9veloppeurs de wrappers veulent rendre la maintenance de Linux impossible en raison du m\u00e9lange de plusieurs langages dans une m\u00eame base de code, ils devraient le faire dans leur pilote, et non \u00e9tendre cette tumeur sur les sous-syst\u00e8mes principaux du noyau. <\/p>\n
Christoph a pr\u00e9cis\u00e9 qu'il n'a rien contre le langage Rust et le consid\u00e8re comme l'un des meilleurs nouveaux langages, mais qu'il est oppos\u00e9 au m\u00e9lange de code \u00e9crit dans diff\u00e9rents langages. Selon Christoph, il soutient la cr\u00e9ation de nouveaux projets en Rust, mais s'oppose \u00e0 l'incorporation de Rust dans de grandes bases de code en C, car ce m\u00e9lange r\u00e9duit consid\u00e9rablement la facilit\u00e9 de maintenance du noyau en tant que projet int\u00e9gr\u00e9. <\/p>\n
La nature des probl\u00e8mes de support r\u00e9side dans le fait que les interfaces en Rust rendent les d\u00e9veloppeurs d\u00e9pendants du code \u00e9crit en Rust. \u00c0 premi\u00e8re vue, il semble que ces interfaces ne soient que des couches suppl\u00e9mentaires sur les structures et fonctions en C, n'impactant en rien le d\u00e9veloppement et le support du code en C. Cependant, ce n'est pas le cas. Lorsque de telles interfaces existent, les d\u00e9veloppeurs des sous-syst\u00e8mes \u00e9crits en C doivent prendre en compte l'impact des modifications sur la continuit\u00e9 du fonctionnement de ces interfaces. Toute modification des structures de donn\u00e9es ou des fonctions internes en C peut entra\u00eener la n\u00e9cessit\u00e9 d'adapter le code des interfaces, donc les changements affectant les interfaces dans le code C doivent \u00eatre surveill\u00e9s et synchronis\u00e9s avec le code en Rust. Beaucoup de d\u00e9veloppeurs ne sont pas pr\u00eats \u00e0 assumer la responsabilit\u00e9 suppl\u00e9mentaire de r\u00e9soudre les probl\u00e8mes qui surgissent dans le code en Rust et ne souhaitent pas investir leur temps \u00e0 suivre l'\u00e9tat des interfaces en Rust. <\/p>\n
La situation li\u00e9e \u00e0 la complexification du support n'est pas th\u00e9orique. Jason Gunthorpe, mainteneur de TPM, VFIO et Infiniband chez NVIDIA, a rejoint la discussion et a \u00e9voqu\u00e9 le rejet par Linus Torvalds d'une demande de tirage comportant des modifications dans le sous-syst\u00e8me de gestion de la m\u00e9moire, car cette modification provoquait un \u00e9chec lors de la tentative de compilations du noyau avec le support de Rust activ\u00e9. L'\u00e9chec est survenu parce que les d\u00e9veloppeurs du code en Rust n'avaient pas inclus les modifications n\u00e9cessaires dans le g\u00e9n\u00e9rateur d'interfaces (bindgen). Ainsi, les d\u00e9veloppeurs du sous-syst\u00e8me de gestion de la m\u00e9moire, en avan\u00e7ant cette modification qui \u00e9tait par ailleurs parfaitement correcte du point de vue du code en C et du noyau en g\u00e9n\u00e9ral, se sont retrouv\u00e9s d\u00e9pendants d'un code optionnel tiers dans le noyau, dont d'autres personnes sont responsables. <\/p>\n
Le refus d'accepter le code des wrappers sur les appels DMA a mis les d\u00e9veloppeurs du projet Rust for Linux dans l'impasse, car sans ces wrappers, le d\u00e9veloppement de pilotes complets en Rust sera entrav\u00e9. Hector Martin, mainteneur du code pour la prise en charge des puces ARM d'Apple et leader du projet Ashai Linux, a propos\u00e9 comme solution au conflit de faire accepter le wrapper directement par Linus Torvalds, contournant ainsi le mainteneur du sous-syst\u00e8me DMA. Si Linus accepte une telle violation de la hi\u00e9rarchie et de la pratique \u00e9tablie, cela pourrait mener \u00e0 une crise de gestion du d\u00e9veloppement du noyau, et s'il refuse, cela stoppent l'avancement de Rust dans le noyau. <\/p>\n
En guise de suggestion, Hector a mentionn\u00e9 la tenue pour responsable de Christoph pour violation du code de conduite en raison d'un commentaire dans lequel Christoph a compar\u00e9 Rust \u00e0 une tumeur canc\u00e9reuse. En outre, Hector a \u00e9crit qu'il en avait marre de toute cette bureaucratie, qu'il n'\u00e9tait pas pr\u00eat \u00e0 faire confiance aux processus \u00e9tablis et a laiss\u00e9 entendre une implication des r\u00e9seaux sociaux. Dave Airlie, le mainteneur de la sous-syst\u00e8me DRM, a conseill\u00e9 de ne pas amplifier le conflit et de comprendre que le comportement toxique est inacceptable des deux c\u00f4t\u00e9s, que le participant \u00e0 la discussion ait raison ou non. <\/p>\n
Linus Torvalds a rejoint la discussion, indiquant que le probl\u00e8me pourrait r\u00e9sider dans Hector lui-m\u00eame et sa confiance en lui, croyant qu'il sait mieux que les autres, plut\u00f4t que dans le processus de d\u00e9veloppement actuel du noyau, qui fonctionne. Le processus de d\u00e9veloppement du noyau a ses probl\u00e8mes, mais c'est une r\u00e9alit\u00e9 de la vie \u2014 rien n'est parfait. Les tentatives de harc\u00e8lement sur les r\u00e9seaux sociaux sont ce qui d\u00e9courage Linus d'avoir quoi que ce soit \u00e0 voir avec l'approche d'Hector. Ce qui compte pour Linus, ce sont les discussions techniques et les patchs, et non pas la pression exerc\u00e9e par les r\u00e9seaux sociaux. <\/p>\n