I løpet av hele februar måned var vi dele ulike nyheter om ham ved problemer og uenigheter som har blitt generert i Linux Kernel-utviklerfellesskapet for utbygging i Rust.
selv, Noen av tungvekterne i samfunnet har gjort sin posisjon kjent og enda verre, noen har sagt opp sine stillinger som vedlikeholdere innenfor noen av Linux-kjernens undersystemer.
Gitt denne bølgen av diskusjoner som ser ut til å komme ut av kontroll, Linus Torvalds har tatt saken i egne hender. y har sluttet seg til diskusjonen rundt mot motstanden til enkelte vedlikeholdere mot introduksjonen av Rust i Linux-kjernen.
Ifølge Linus er ingen vedlikeholder tvunget til å lære, bruke eller til og med vurdere koden skrevet inn Rust hvis du ikke vil ha det, siden de kan fortsette å jobbe utelukkende med C.
Onsdag 19. februar 2025 kl. 22:42, Christoph Hellwig skrev:
>
Dokumentet sier at det ikke kreves noe delsystem for å bruke Rust. Det er bevist.
> ta feil for Linus. Og selv om du kanskje ikke visste det når
> Da du skrev dokumentet, gjorde du det absolutt ved å legge det ut på listen.Jeg var håpefull og prøvde det, for å se om denne lange tråden ville gi resultater.
til noe konstruktivt, men dette ser ut til å gå bakover (eller i det minste
i hvert fall ikke fremover).Faktum er at pull-forespørselen du protesterte mot IKKE RØRTE DMA
LAG I OVERHOLDET.Han var bokstavelig talt bare en annen bruker, i en helt egen situasjon.
underkatalog, som ikke endret koden du vedlikeholder på noen måte,
form eller form.
Men, hvis en vedlikeholder bestemmer seg for ikke å involvere seg, vil han eller hun heller ikke ha mulighet til å påvirke i måten den utvikles på, og heller ikke påvirke hvordan dens eksterne lenker integreres i koden til dets eget delsystem.
Torvalds forklarte det de vedlikeholderne som er interessert i å komme videre med Rust vil kunne delta i utviklingen av den, påvirke konstruksjonen av lenker og hjelpe til med vedlikehold av de tilsvarende grensesnittene. Motsatt vil de som velger å ikke jobbe med Rust være beskyttet mot problemene som kan oppstå ved bruk, men de vil også bli ekskludert fra å påvirke utviklingen. Denne tilnærmingen skaper en slags barriere som, samtidig som den beskytter de som utelukkende er dedikert til C, samtidig hindrer dem i å bidra til forbedring av Rust-integrasjon.
Så denne e-posten handler ikke om noen "rustpolitikk." Denne e-posten handler om en
Et mye større problem: som vedlikeholder er du ansvarlig for koden din,
Jada, men du er ikke ansvarlig for hvem som bruker sluttresultatet og hvordan.Du trenger ikke å like Rust. Du trenger ikke bekymre deg for ham. Det vil si...
Det har blitt gjort helt klart fra begynnelsen at ingen er det
tvunget til å plutselig måtte lære et nytt språk, og at folk som
Ønsker du å jobbe utelukkende på C-siden, kan du fortsette med det.
Denne situasjonen skaper på en måte en beskyttende barriere.for de som kun jobber med C, isolere dem fra kompleksiteten og potensielle ulemper forbundet med det til rustkoden. Men på samme tid hindrer den samme isolasjonen dem fra å påvirke fremdriften til Rust, noe som betyr at mottoet "ingen må forholde seg til Rust" ikke tillater enhver vedlikeholder å låse ned noen kode skrevet på dette språket.
La ansvarsfordeling er organisert slik at de som er interessert i Rust kan jobbe med dens aspekter, mens de som velger å ikke engasjere seg ikke vil bli tvunget til å endre arbeidsflyten sin, selv om de ikke vil kunne endre utviklingen av komponenter skrevet i Rust.
Kontroversen forsterket seg da spørsmålet om Rust-koblingsgodkjenning via DMA-undersystemet dukket opp. I dette tilfellet ble motstanden fra en vedlikeholder som prøvde å blokkere aksept av slike koblinger ignorert, og Linus kritiserte åpent Christoph Hellwigs handlinger.
Ifølge Torvalds hadde Hellwig overskredet sin autoritet. ved å prøve å påvirke kode som, implementert i en egen underkatalog, ikke påvirket DMA-undersystemet han var ansvarlig for. Med Torvalds ord ligner Hellwigs holdning på å prøve å deaktivere DMA i en kontroller rett og slett fordi han ikke likte det, noe som er uakseptabelt.
Til syvende og sist, selv om hver vedlikeholder er ansvarlig for sin egen kode, kan de ikke kreves for å kontrollere hvordan den koden brukes eller bestemme om dens integrering i større prosjekter.