Gedurende de hele maand februari waren we het delen van verschillende nieuwsberichten op geval van problemen en meningsverschillen die zijn gegenereerd in de Linux Kernel-ontwikkelaarsgemeenschap voor ontwikkeling in Rust.
zelfs Enkele zwaargewichten in de gemeenschap hebben hun standpunt kenbaar gemaakt en erger nog, sommigen hebben hun functie neergelegd als beheerders binnen enkele Linux-kernelsubsystemen.
Gezien deze golf van discussies die uit de hand lijkt te lopen, Linus Torvalds heeft het heft in eigen handen genomen. y heeft zich aangesloten bij de discussie rond vanwege de weerstand van sommige beheerders tegen de introductie van Rust in de Linux-kernel.
Volgens Linus wordt geen enkele beheerder gedwongen om te leren, te gebruiken of denk zelfs aan de code die is geschreven in Roest als je het niet wilt, omdat ze uitsluitend met C kunnen blijven werken.
Op woensdag 19 februari 2025 om 22:42 uur, Christoph Hellwig schreef:
>
In het document staat dat er geen subsysteem nodig is om Rust te gebruiken. Dat is bewezen.
> zou niet kloppen voor Linus. En hoewel je het misschien niet wist toen
> Toen u het document schreef, deed u dat door het op de lijst te plaatsen.Ik had goede hoop en probeerde het, om te zien of deze lange draad resultaat zou opleveren.
in iets constructiefs, maar dit lijkt een stap terug te zijn (of in ieder geval
(in ieder geval niet vooruit).Het feit is dat de pull-aanvraag waartegen u bezwaar heeft gemaakt, NIET DE DMA HEEFT GERAAKT
LAAGJE HELEMAAL NIET.Hij was letterlijk gewoon een gebruiker, in een compleet andere situatie.
subdirectory, die de code die u beheert op geen enkele manier heeft gewijzigd,
vorm of gedaante.
EchterAls een beheerder besluit zich er niet mee te bemoeien, heeft hij of zij ook niet de mogelijkheid om invloed uit te oefenen. in de manier waarop het wordt ontwikkeld, en ook niet in de manier waarop de externe links worden geïntegreerd in de code van het eigen subsysteem.
Torvalds legde uit dat die beheerders die geïnteresseerd zijn in vooruitgang met roest zal in staat zijn om deel te nemen aan de ontwikkeling ervan, invloed uit te oefenen op de bouw van links en helpen bij het onderhoud van de bijbehorende interfaces. Omgekeerd worden degenen die ervoor kiezen om niet met Rust te werken, beschermd tegen de problemen die kunnen ontstaan ​​bij het gebruik ervan. Ze hebben echter ook geen invloed op de ontwikkeling ervan. Deze aanpak creëert een soort barrière die degenen die zich uitsluitend met C bezighouden, beschermt, maar hen er tegelijkertijd van weerhoudt om bij te dragen aan de verbetering van de Rust-integratie.
Deze e-mail gaat dus niet over een 'Rust-beleid'. Deze e-mail gaat over een
Een veel groter probleem: als beheerder bent u verantwoordelijk voor uw code,
Zeker, maar jij bepaalt niet wie het eindresultaat gebruikt en hoe.Je hoeft Rust niet leuk te vinden. Je hoeft je geen zorgen over hem te maken. Dat is…
Het is vanaf het begin duidelijk gemaakt dat niemand
gedwongen worden om plotseling een nieuwe taal te leren, en dat mensen die
Als u uitsluitend aan de C-kant wilt werken, kunt u dat blijven doen.
Deze situatie creëert in zekere zin een beschermende barrière.voor degenen die alleen met C werken, door ze te isoleren van de complexiteit en mogelijke nadelen die ermee gepaard gaan naar de Rust-code. Maar tegelijkertijd voorkomt diezelfde isolatie dat ze de voortgang van Rust beïnvloeden. Dat betekent dat het motto "niemand hoeft met Rust te maken te hebben" niet toestaat dat elke beheerder code die in deze taal is geschreven, kan vergrendelen.
La verdeling van verantwoordelijkheden is georganiseerd zodat geïnteresseerden in Rust aan de aspecten ervan kunnen werken, terwijl degenen die ervoor kiezen om er niet bij betrokken te raken, niet gedwongen worden om hun workflow te veranderen. Ze zullen echter de ontwikkeling van componenten die in Rust zijn geschreven, niet kunnen wijzigen.
De controverse werd groter toen de kwestie van de goedkeuring van Rust-links via het DMA-subsysteem ter sprake kwam. In dit geval werd de tegenstand van een beheerder die de acceptatie van dergelijke links probeerde te blokkeren, genegeerd en Linus bekritiseerde openlijk de acties van Christoph Hellwig.
Volgens Torvalds had Hellwig zijn bevoegdheden overschreden. door te proberen code te beïnvloeden die, omdat deze in een aparte subdirectory was geïmplementeerd, geen invloed had op het DMA-subsysteem waarvoor hij verantwoordelijk was. Volgens Torvalds is Hellwigs houding vergelijkbaar met het proberen om DMA in een controller uit te schakelen, alleen omdat hij het niet leuk vindt. Dat is onacceptabel.
Hoewel elke beheerder uiteindelijk verantwoordelijk is voor zijn eigen code, kan er niet van hem verwacht worden dat hij controle heeft over hoe die code wordt gebruikt of beslissingen neemt over de integratie ervan in grotere projecten.