Christoph Hellwig, mainteneur des sous-systèmes DMA, KVM, Slab Allocator et de l'architecture PowerPC dans le noyau Linux, ancien membre du comité technique de la Linux Foundation et plaignant dans un litige lié à la GPL contre VMware, a refusé de valider les correctifs relatifs au support du développement de pilotes en langage Rust. Les correctifs proposés ajoutaient des wrappers autour de plusieurs fonctions du sous-système DMA, permettant d'utiliser DMA dans les pilotes écrits en Rust.
Comme raison de son refus, il a été mentionné 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é d'accéder directement à l'API C d'origine du DMA dans chaque pilote écrit en Rust, afin de ne pas créer d'abstractions supplémentaires dont la maintenance du noyau serait contrainte.
Les développeurs des correctifs ont déclaré qu'ils prendraient en charge tout le travail de maintenance du code en Rust, qu'ils étaient prêts à maintenir ces correctifs eux-mêmes et qu'ils avaient déplacé les wrappers dans un sous-répertoire séparé (rust/kernel/dma.rs). En réponse, Christoph a mis son veto (« Nacked-by ») à l'acceptation des correctifs liés à Rust et a déclaré qu'il ne souhaitait pas d'un autre collaborateur. Christoph a affirmé que si les développeurs de wrappers veulent rendre impossible la maintenance de Linux en mélangeant plusieurs langages dans une même base de code, ils devraient le faire dans leur propre pilote, et non pas étendre cette tumeur sur les sous-systèmes principaux du noyau.
Christoph a précisé qu'il n'a rien contre le langage Rust et le considère comme l'un des meilleurs nouveaux langages, mais qu'il est opposé au mélange de code écrit dans différents langages. Selon Christoph, il soutient la création de nouveaux projets en Rust, mais s'oppose à l'incorporation de Rust dans de grandes bases de code en C, car ce mélange réduit considérablement la facilité de maintenance du noyau en tant que projet intégré.
La nature des problèmes de support réside dans le fait que les interfaces en Rust rendent les développeurs dépendants du code écrit en Rust. À première vue, il semble que ces interfaces ne soient que des couches supplémentaires sur les structures et fonctions en C, n'impactant en rien le développement et le support du code en C. Cependant, ce n'est pas le cas. Lorsque de telles interfaces existent, les développeurs des sous-systèmes écrits en C doivent prendre en compte l'impact des modifications sur la continuité du fonctionnement de ces interfaces. Toute modification des structures de données ou des fonctions internes en C peut entraîner la nécessité d'adapter le code des interfaces, donc les changements affectant les interfaces dans le code C doivent être surveillés et synchronisés avec le code en Rust. Beaucoup de développeurs ne sont pas prêts à assumer la responsabilité supplémentaire de résoudre les problèmes qui surgissent dans le code en Rust et ne souhaitent pas investir leur temps à suivre l'état des interfaces en Rust.
La situation liée à la complexification du support n'est pas théorique. Jason Gunthorpe, mainteneur de TPM, VFIO et Infiniband chez NVIDIA, a rejoint la discussion et a évoqué le rejet par Linus Torvalds d'une demande de tirage comportant des modifications dans le sous-système de gestion de la mémoire, car cette modification provoquait un échec lors de la tentative de compilations du noyau avec le support de Rust activé. L'échec est survenu parce que les développeurs du code en Rust n'avaient pas inclus les modifications nécessaires dans le générateur d'interfaces (bindgen). Ainsi, les développeurs du sous-système de gestion de la mémoire, en avançant cette modification qui était par ailleurs parfaitement correcte du point de vue du code en C et du noyau en général, se sont retrouvés dépendants d'un code optionnel tiers dans le noyau, dont d'autres personnes sont responsables.
Le refus d'accepter le code des interfaces sur les appels DMA a mis les développeurs du projet Rust for Linux dans une impasse, car sans ces interfaces, le développement de pilotes complets en Rust sera difficile. Hector Martin, mainteneur du code pour le support des puces ARM d'Apple et leader du projet Asahi Linux, a proposé comme solution de faire accepter l'interface directement par Linus Torvalds, contournant le mainteneur du sous-système DMA. Si Linus accepte une telle violation de la hiérarchie et des pratiques établies, cela pourrait conduire à une crise dans la gestion du développement du noyau, et s'il refuse, cela mettra un frein à l'avancement de Rust dans le noyau.
En guise de suggestion, Hector a mentionné la tenue pour responsable de Christoph pour violation du code de conduite en raison d'un commentaire dans lequel Christoph a comparé Rust à une tumeur cancéreuse. En outre, Hector a écrit qu'il en avait marre de toute cette bureaucratie, qu'il n'était pas prêt à faire confiance aux processus établis et a laissé entendre une implication des réseaux sociaux. Dave Airlie, le mainteneur de la sous-système DRM, a conseillé de ne pas amplifier le conflit et de comprendre que le comportement toxique est inacceptable des deux côtés, que le participant à la discussion ait raison ou non.
Linus Torvalds a rejoint la discussion, soulignant que le problème pourrait venir de Hector lui-même et de sa confiance excessive dans le fait qu'il sait quelque chose de mieux que les autres, plutôt que dans le processus de développement du noyau actuel qui fonctionne. Le processus de développement du noyau a des problèmes, mais c'est la réalité de la vie - rien n'est parfait. Les tentatives de persécution via les réseaux sociaux découragent Linus de vouloir avoir quoi que ce soit à voir avec l'approche de Hector. Ce qui importe pour Linus, ce sont les discussions techniques et les patchs, pas la pression exercée via les réseaux sociaux.
En réponse, Hector a demandé à être retiré des mainteneurs de la plateforme ARM/APPLE, car il a perdu foi dans le processus de développement appliqué dans le noyau et l'approche de gestion de la communauté. Il a également déclaré que le développement de la plateforme ARM/Apple se poursuivra en dehors du noyau principal de Linux. La plateforme ARM/Apple dans le noyau a encore un mainteneur - Sven Peter, qui a l'intention de poursuivre le soutien de la plateforme dans le noyau.
Source : opennet.ru
