Christoph Hellwig, maintainer van de DMA-subsystemen, KVM, Slab Allocator en de PowerPC-architectuur in de Linux-kernel, die ooit deel uitmaakte van het technisch bestuurscomit\u00e9 van de Linux Foundation en als eiser optrad in een rechtszaak met VMware gerelateerd aan de GPL, weigerde patches te bevestigen die verband hielden met de ontwikkeling van stuurprogramma's in de Rust-taal. De voorgestelde patches voegden wrappers toe rond verschillende functies van het DMA-subsysteem, waardoor DMA kon worden gebruikt in stuurprogramma's geschreven in Rust. <\/p>\n
Als reden voor de weigering werd de complexiteit van het onderhouden van de code genoemd bij het gebruik van wrappers in andere talen en de wens om de programmeerinterfaces naar DMA in een leesbare C-vorm te behouden, zonder deze te verwateren door onduidelijke wrappers. Christoph stelde voor om rechtstreeks naar de oorspronkelijke C API van DMA in elk stuurprogramma voor Rust te verwijzen, om extra abstracties te voorkomen waar de kernel-ondersteuners afhankelijk van zouden worden. <\/p>\n
De patch-ontwikkelaars hebben aangegeven dat zij de volledige verantwoordelijkheid voor het onderhoud van de code in Rust op zich zullen nemen, bereid zijn om deze patches zelfstandig te onderhouden en de wrappers in een aparte subdirectory hebben geplaatst (rust\/kernel\/dma.rs). Als reactie heeft Christoph een veto uitgesproken (\"Nacked-by\") tegen het aannemen van gerelateerde Rust-patches en aangegeven dat hij geen extra onderhoudspersoon nodig heeft. Christoph verklaarde dat als de ontwikkelaars van de wrappers de onmogelijkheid van het onderhouden van Linux door menging van meerdere talen in \u00e9\u00e9n codebase willen veroorzaken, ze dit in hun eigen driver moeten doen en deze kwaadaardige tumor niet op de kernsystemen mogen uitbreiden. <\/p>\n
Tegelijkertijd verduidelijkte Christoph dat hij niets tegen de Rust-taal heeft en deze beschouwt als een van de beste nieuwe talen, maar hij is tegen het mengen van code in verschillende talen. Volgens Christoph is hij voor de creatie van nieuwe projecten in Rust, maar tegen het mengen van Rust met grote codebases in C, omdat zo'n mengeling het onderhoudsgemak van de kernel, als ge\u00efntegreerd project, sterk vermindert. <\/p>\n
De kern van de problemen met de ondersteuning is dat Rust-wraps de ondersteuners afhankelijk maken van de code in de Rust-taal. Op het eerste gezicht lijkt het alsof de wraps slechts bovenop C-structuren en functies zijn gebouwd, die geen invloed hebben op de ontwikkeling en ondersteuning van de code in C. Maar dat is niet het geval. Bij het bestaan van dergelijke wraps moeten ontwikkelaars van subsystemen die in C zijn geschreven rekening houden met de impact van hun wijzigingen op de voortzetting van de functionaliteit van de wraps. Elke wijziging in datatypes of interne functies in C kan leiden tot de noodzaak om de code van de wraps te wijzigen, daarom moeten wijzigingen die invloed hebben op de wraps in de C-code worden gevolgd en gesynchroniseerd met de code in Rust. Veel ondersteuners zijn niet bereid om extra verantwoordelijkheid te nemen voor het oplossen van problemen die zich in de Rust-code voordoen en zijn niet van plan hun tijd te besteden aan het bijhouden van de status van Rust-wraps. <\/p>\n
De situatie met de complexiteit van de ondersteuning is niet hypothetisch. Jason Gunthorpe, de maintainer van TPM, VFIO en Infiniband bij NVIDIA, voegde zich bij de discussie en gaf een voorbeeld van het afwijzen door Linus Torvalds van een pull-verzoek met wijzigingen in de geheugensubsysteem, omdat deze wijziging leidde tot een crash bij het proberen om de kernel met ondersteuning voor Rust te compileren. De crash trad op omdat de ondersteuners van de Rust-code de nodige wijzigingen in de bindgen-generator niet hadden toegevoegd. Hierdoor waren de ondersteuners van het geheugensubsysteem bij het doorvoeren van een wijziging die volledig correct was vanuit het perspectief van de C-code en de kernel in het algemeen, afhankelijk van optionele externe code in de kernel waarvoor andere mensen verantwoordelijk zijn. <\/p>\n
De weigering om de wrapper-code voor DMA-aanroepen te accepteren heeft de ontwikkelaars van het Rust for Linux-project in een impasse gebracht, omdat zonder dergelijke wrappers het ontwikkelen van volledige drivers in Rust bemoeilijkt zal worden. Hector Martin, maintainer van de ARM-chipondersteuning voor Apple en leider van het Ashai Linux-project, heeft als mogelijke oplossing voor het conflict voorgesteld om de acceptatie van de wrapper rechtstreeks via Linus Torvalds te verkrijgen, om de maintainer van de DMA-subsystem te omzeilen. Als Linus akkoord gaat met deze schending van de hi\u00ebrarchie en de bestaande praktijk, kan dit leiden tot een crisis in de ontwikkeling van de kernel; als hij het weigert, zal dit de voortgang van Rust in de kernel stoppen. <\/p>\n
Als een optie noemde Hector de aansprakelijkheid van Christoph voor het schenden van de gedragscode vanwege een opmerking waarin Christoph Rust vergeleek met een kankertumor. Bovendien schreef Hector dat hij moe was van alle bureaucratische rompslomp, niet bereid was om simpelweg te vertrouwen op bestaande processen en suggeerde hij een betrokkenheid van sociale media. Dave Airlie, de maintainer van de DRM-subsystemen, adviseerde om het conflict niet op te blazen en te begrijpen dat giftig gedrag aan beide kanten onacceptabel is, ongeacht wie er gelijk heeft in de discussie. <\/p>\n
Linus Torvalds heeft zich bij de discussie aangesloten en aangegeven dat het probleem mogelijk in Hector zelf ligt en zijn zelfvertrouwen dat hij iets beter weet dan anderen, en niet in het huidige ontwikkelproces van de kernel, dat functioneert. Het ontwikkelproces van de kernel heeft zijn problemen, maar dat is de werkelijkheid \u2014 er is niets perfect in het leven. Pogingen tot intimidatie via sociale media ontmoedigen Linus om enige betrokkenheid bij Hectors aanpak te hebben. Voor Linus zijn technische discussies en patches belangrijk, niet druk uitoefenen via sociale media. <\/p>\n