Przez cały luty byliśmy dzielenie się różnymi wiadomościami na przypadek problemów i nieporozumień które zostały wygenerowane w społeczności programistów jądra Linux do rozwoju w Rust.
nawet Niektórzy potentaci w społeczności wyrazili swoje stanowisko i co gorsza, niektórzy zrezygnowali ze swoich stanowisk jako opiekunowie niektórych podsystemów jądra Linux.
Biorąc pod uwagę tę falę dyskusji, która wydaje się wymykać spod kontroli, Linus Torvalds wziął sprawy w swoje ręce. y dołączył do dyskusji na temat na opór niektórych opiekunów przed wprowadzeniem języka Rust do jądra Linux.
Według Linusa żaden konserwator nie jest zmuszony uczyć się, używać lub nawet rozważyć kod napisany w Rdza, jeśli nie chcesz, ponieważ mogą nadal pracować wyłącznie w języku C.
W środę 19 lutego 2025 r. o 22:42 Christoph Hellwig napisał:
>
W dokumencie stwierdzono, że do korzystania z Rust nie jest wymagany żaden podsystem. To jest udowodnione.
> mylić się co do Linusa. I choć może nie wiedziałeś tego, kiedy
> Kiedy pisałeś dokument, zrobiłeś to poprzez zamieszczenie go na liście.Miałem nadzieję i spróbowałem, żeby zobaczyć, czy ten długi wątek przyniesie jakieś rezultaty.
w coś konstruktywnego, ale wydaje się, że to idzie wstecz (albo przynajmniej
przynajmniej nie do przodu).Faktem jest, że żądanie ściągnięcia, któremu się sprzeciwiłeś, NIE DOTYCZYŁO DMA
WARSTWA W OGÓLE.Był dosłownie po prostu kolejnym użytkownikiem, w całkowicie odrębnej sytuacji.
podkatalog, który w żaden sposób nie zmienił kodu, który utrzymujesz,
kształt lub forma.
Jednakjeśli konserwator zdecyduje się nie angażować, nie będzie miał również możliwości wywierania wpływu w sposób, w jaki jest rozwijany, ani w jaki sposób jego zewnętrzne linki są integrowane z kodem jego własnego podsystemu.
Torvalds wyjaśnił, że tych konserwatorów, którzy są zainteresowani kontynuowaniem prac z rdzą będzie mógł uczestniczyć w jego rozwoju, wpływać na budowę łączy i pomagać w utrzymaniu odpowiednich interfejsów. Z kolei osoby, które nie zdecydują się na pracę z Rustem, będą chronione przed problemami, które mogą pojawić się podczas jego użytkowania, ale jednocześnie nie będą mogły wpływać na jego rozwój. Takie podejście tworzy pewnego rodzaju barierę, która chroniąc użytkowników zajmujących się wyłącznie językiem C, jednocześnie uniemożliwia im wkład w udoskonalanie integracji z Rust.
Tak więc ten e-mail nie dotyczy żadnej „polityki Rust”. Ta wiadomość e-mail dotyczy
Znacznie poważniejszy problem: jako osoba odpowiedzialna za utrzymanie kodu jesteś odpowiedzialny za swój kod,
Jasne, ale nie masz wpływu na to, kto i w jaki sposób wykorzysta efekt końcowy.Nie musisz lubić Rust. Nie musisz się o niego martwić. To jest…
Od samego początku było jasne, że nikt nie jest
zmuszony nagle nauczyć się nowego języka, a ludzie, którzy
Jeśli chcesz pracować wyłącznie po stronie C, możesz to nadal robić.
Taka sytuacja tworzy pewnego rodzaju barierę ochronną.dla tych, którzy pracują tylko z C, izolując je od złożoności i potencjalnych wad z tym związanych do kodu Rust. Jednocześnie jednak ta sama izolacja uniemożliwia im wpływanie na rozwój Rusta, co oznacza, że dewiza „nikt nie musi zajmować się Rustem” nie pozwala każdemu opiekunowi zablokować jakiegokolwiek kodu napisanego w tym języku.
La podział odpowiedzialności jest zorganizowany więc osoby zainteresowane Rustem będą mogły pracować nad jego aspektami, podczas gdy ci, którzy nie zdecydują się na zaangażowanie, nie będą zmuszeni do zmiany swojego sposobu pracy, choć nie będą mogli modyfikować rozwoju komponentów napisanych w Ruście.
Kontrowersje nasiliły się, gdy pojawił się problem zatwierdzania łącza Rust poprzez podsystem DMA. W tym przypadku zignorowano sprzeciw opiekuna, który próbował zablokować akceptację takich linków, i Linus otwarcie skrytykował działania Christopha Hellwiga.
Według Torvaldsa Hellwig przekroczył swoje uprawnienia. próbując wpłynąć na kod, który będąc zaimplementowany w oddzielnym podkatalogu, nie miał wpływu na podsystem DMA, za który był odpowiedzialny. Jak twierdzi Torvalds, podejście Hellwiga można porównać do próby wyłączenia DMA w kontrolerze, ponieważ po prostu mu się to nie podoba, co jest niedopuszczalne.
Ostatecznie, chociaż każdy opiekun odpowiada za własny kod, nie można od niego wymagać kontrolowania sposobu, w jaki ten kod jest wykorzystywany, ani decydowania o jego integracji z większymi projektami.