Wygląda na to, że ten rok nie będzie rokiem Linuksa. Chociaż pod koniec ubiegłego roku wszystko wskazywało na to, że Linux i komputery stacjonarne zyskają popularność w 2025 r., to jednak nie zawsze sprawy wyglądają tak, jak się wydają.
A to tylko kilka dni Christoph Hellwig, wybitna postać w utrzymaniu krytycznych podsystemów, takich jak DMA, KVM, Slab Allocator i PowerPC w jądrze Linux, jasno wyraziło swoją odmowę wsparcia dla poprawek które ułatwiają rozwój kontrolerów w Rust.
Christoph Hellwig wspomina, że omawiane poprawki Zaproponowali dołączenie wrapperów wokół funkcji podsystemu DMA, aby umożliwić sterownikom napisanym w języku Rust ich wykorzystanie. Twierdzi jednak, że ta strategiakomplikuje to utrzymanie kodu, a przejrzystość interfejsów C musi zostać zachowana, zapobiegając rozszerzaniu abstrakcji, które mogłoby utrudnić integrację z resztą jądra.
Problemy mieszania języków w projekcie
Według Hellwiga, Głównym problemem jest integracja kodu Rust generuje zależności, które zmuszają programistów podsystemów C do rozważenia wpływu swoich modyfikacji na kod wiążący Rust. Ten Oznacza to, że wszelkie zmiany w strukturach lub funkcji wewnętrznych w C może wymagać równoległych zmian w kodzie Rust, co tworzy scenariusz, który trudno utrzymać na dłuższą metę.
Aby uniknąć tej sytuacji, Hellwig zaleca się, aby kontrolery w Rust miały bezpośredni dostęp do natywnego interfejsu API DMA w języku C, zamiast uciekać się do dodatkowych opakowań, które ich zdaniem mogłyby ograniczyć łatwość obsługi jądra.
Ze swojej strony Twórcy, którzy zaproponowali poprawki, argumentowali, że zajmą się konserwacją kodu Rust i w tym celu zorganizowaliśmy linki w specjalnym podkatalogu (rust/kernel/dma.rs). Jednakże, Hellwig zawetował te propozycje, ostrzegając, że nie musi brać na siebie odpowiedzialności. zintegrować kod z innych języków z podstawowymi podsystemami.
Dodatkowo stanowczo stwierdził, że jeśli chcemy przekształcić jądro w mozaikę wielu języków, powinniśmy zacząć od sterowników Rust, zamiast narzucać tę złożoność w podstawowych obszarach.
Kontrowersje nasiliły się gdy takie postacie jak Jason Gunthorpe, opiekun TPM, VFIO i Infiniband w firmie NVIDIA, dzielili się przykładami zmian w podsystemach pamięci, które były poprawne z perspektywy kodu C, generowało problemy podczas próby kompilacji jądra z obsługą Rust. Incydenty te wyraźnie pokazały, że powiązania między językami C i Rust mogą wprowadzać dodatkowe zależności, które utrudniają skoordynowany rozwój.
Warto zaznaczyć, że Dyskusja nie ograniczała się do aspektów technicznych. Hector Martin zasugerował, że rozwiązaniem może być bezpośrednie nawiązanie połączenia za pośrednictwem Linusa Torvaldsa, co pozwoliłoby uniknąć interwencji osoby odpowiedzialnej za utrzymanie podsystemu DMA. Jednak takie podejście może zakłócić tradycyjną hierarchiczną strukturę rozwoju jądra.
Hector wskazał również na zachowania, które uważał za toksyczne, wspominając nawet, że krytyka Hellwiga, który porównał Rusta do „nowotworu”, przyczyniła się do jego frustracji i ostatecznie do decyzji o rezygnacji z roli opiekuna platformy ARM/Apple nad głównym kernelem. Mimo swojej rezygnacji, platformę nadal będzie wspierać Sven Peter, który zobowiązał się do jej dalszego utrzymywania.
Ze swojej strony, Linus Torvalds dołączył do rozmowy, podkreślając, że proces rozwoju jądra, choć niedoskonałego, działa i że dyskusje techniczne powinny koncentrować się na poprawkach, bez ulegania zewnętrznym naciskom i nękaniu w mediach społecznościowych. Torvalds uważa, że podejście powinno być czysto techniczne, a nie personalne.
Odrzucenie przez Christopha Hellwiga idei włączenia wrapperów Rust do podsystemu DMA uwypukla napięcia wśród programistów jądra Linuksa. Podczas gdy niektórzy widzą w Ruście potężne narzędzie do tworzenia nowych projektów, inni obawiają się, że integrowanie wielu języków może mieć negatywny wpływ na łatwość obsługi i spójność bazy kodu.
Sytuacja ta pozostaje przedmiotem debaty i może mieć istotne implikacje dla przyszłości obsługi Rust w jądrze. W każdym razie jasne jest, że społeczność programistów Linuksa nadal mierzy się ze złożonymi wyzwaniami, w których decyzje techniczne muszą być ostrożnie podejmowane, aby zapewnić trwałość projektu w długiej perspektywie.