Under hela februari månad var vi dela olika nyheter om vid problem och meningsskiljaktigheter som har genererats i Linux Kernel-utvecklargemenskapen för utveckling i Rust.
även, Några av tungviktarna i samhället har gjort sin position känd och ännu värre, några har sagt upp sig från sina befattningar som underhållare inom några av Linux-kärnundersystemen.
Med tanke på denna våg av diskussioner som verkar komma utom kontroll, Linus Torvalds har tagit saken i egna händer. y har anslutit sig till diskussionen kring mot vissa underhållares motstånd mot introduktionen av Rust i Linux-kärnan.
Enligt Linus är ingen underhållare tvungen att lära sig, använda eller till och med överväga koden som är inskriven Rosta om du inte vill ha det, eftersom de kan fortsätta arbeta uteslutande med C.
Onsdagen den 19 februari 2025 klockan 22:42, Christoph Hellwig skrev:
>
Dokumentet anger att inget delsystem krävs för att använda Rust. Det är bevisat.
> har fel för Linus. Och även om du kanske inte visste det när
> När du skrev dokumentet gjorde du det absolut genom att lägga upp det på listan.Jag var hoppfull och provade det för att se om den här långa tråden skulle ge resultat.
till något konstruktivt, men det här verkar gå bakåt (eller åtminstone
åtminstone inte framåt).Faktum är att pull-begäran du motsatte dig INTE RÖRDE DMA
LAGER ALLS.Han var bokstavligen bara en annan användare, i en helt separat situation.
underkatalog, som inte ändrade koden du underhåller på något sätt,
form eller form.
Men, om en underhållare bestämmer sig för att inte engagera sig har han eller hon inte heller möjlighet att påverka på sättet det utvecklas, och inte heller påverka hur dess externa länkar integreras i koden för det egna delsystemet.
Torvalds förklarade det de underhållare som är intresserade av att gå vidare med Rust kommer att kunna delta i dess utveckling, påverka konstruktionen av länkar och hjälpa till med underhållet av motsvarande gränssnitt. Omvänt kommer de som väljer att inte arbeta med Rust skyddas från de problem som kan uppstå när de använder det, men de kommer också att uteslutas från att påverka dess utveckling. Detta tillvägagångssätt skapar en sorts barriär som, samtidigt som det skyddar dem som är dedikerade uteslutande till C, samtidigt hindrar dem från att bidra till förbättringen av Rust-integration.
Så det här e-postmeddelandet handlar inte om någon "rostpolicy". Det här mejlet handlar om en
Ett mycket större problem: som underhållare är du ansvarig för din kod,
Visst, men du är inte ansvarig för vem som använder slutresultatet och hur.Du behöver inte gilla Rust. Du behöver inte oroa dig för honom. Som är…
Det har gjorts ganska tydligt från början att ingen är det
tvingas plötsligt behöva lära sig ett nytt språk, och att människor som
Vill du enbart arbeta på C-sidan kan du fortsätta med det.
Denna situation skapar på sätt och vis en skyddande barriär.för de som bara arbetar med C, isolera dem från komplexiteten och potentiella nackdelar som är förknippade med det till rostkoden. Men samtidigt hindrar samma isolering dem från att påverka Rusts framsteg, vilket innebär att mottot "ingen har att göra med Rust" inte tillåter varje underhållare att låsa ner någon kod skriven på detta språk.
La ansvarsfördelningen är organiserad så de som är intresserade av Rust kan arbeta med dess aspekter, medan de som väljer att inte engagera sig inte kommer att tvingas ändra sitt arbetsflöde, även om de inte kommer att kunna modifiera utvecklingen av komponenter skrivna i Rust.
Kontroversen intensifierades när frågan om Rust-länkgodkännande via DMA-delsystemet uppstod. I det här fallet ignorerades motståndet från en underhållare som försökte blockera acceptansen av sådana länkar, och Linus kritiserade öppet Christoph Hellwigs agerande.
Enligt Torvalds hade Hellwig överskridit sin auktoritet. genom att försöka påverka kod som, implementerad i en separat underkatalog, inte påverkade DMA-undersystemet som han var ansvarig för. Med Torvalds ord liknar Hellwigs attityd som att försöka inaktivera DMA i en kontroller helt enkelt för att han inte gillade det, vilket är oacceptabelt.
I slutändan, även om varje underhållare är ansvarig för sin egen kod, kan de inte krävas för att kontrollera hur den koden används eller besluta om dess integration i större projekt.