Język programowania Rust zawsze miał na celu zastąpienie C w rozwoju jądra Linuksa I to dlatego, że w miarę dojrzewania Rust kilku programistów wyraziło rosnące zainteresowanie jego wykorzystaniem w jądrze Linuksa.
Podczas wirtualnej konferencji Linux Plumbers 2020, przepływ mikrokonferencji przez LLVM zorganizował sesję dotyczącą pytań otwartych i bariery do akceptacji Rust w jądrze Linuksa.
Widoczne jest zainteresowanie tym tematem, bo ta sesja była najbardziej ruchliwym wydarzeniem w 2020 roku.
Czy powinniśmy więc teraz przepisać całe jądro Linuksa na język Rust? Ta dyskusja nie pochodzi z dnia dzisiejszego i została zaakcentowana od czasu pojawienia się pierwszej stabilnej wersji Rusta w 2015 roku.
Ze względu na możliwości, jakie oferuje Rust, niektórzy sugerują to. W tym roku na sierpniowej konferencji Linux Plumbers prelegenci mieli czas ponownie, aby to przedyskutować.
Zaskakujące jest to, że wydają się zgadzać jednogłośnie nie nie po to, aby przepisać istniejący kod w Rust, ale aby programowanie jądra nadal używało Rusta. Oznacza to, że wyobrażają sobie świat, w którym nowe fragmenty kodu można by pisać w Rust.
Ta sesja była oparta na wcześniejszych pracach wielu programistów, w tym na wykładzie wygłoszonym w zeszłym roku przez Alexa Gaynora i Geoffreya Thomasa na Linux Security Summit.
Na konferencji zaprezentowali swoją pracę nad prototypowaniem modułów jądra Rusta i opowiedzieli się za przyjęciem Rusta do jądra.
Zacytowali prace pokazujące, że około dwie trzecie luk w zabezpieczeniach jądra przypisanych do CVE w systemie Android i Ubuntu jest związanych z problemami z bezpieczeństwem pamięci.
W końcu to wyjaśnili Rust może całkowicie uniknąć tego rodzaju błędów dzięki bezpieczniejszym interfejsom API włączane przez typ systemu i weryfikatora pożyczki.
To badanie zdołało już przekonać kilku opiekunów Linus Torvalds, który poparł wprowadzenie Rusta do jądra. Thomas i Gaynor, Josh Triplett, współprzewodniczący zespołu językowego Rust i wieloletni programista jądra Linuksa, a także inni zainteresowani programiści uczestniczyli w dyskusji na ten temat.
Krótko poruszyli jego dotychczasową pracę oraz niektóre z jego pierwszych przemyśleń i pytań, zanim otworzyli większość czasu na dyskusję.
Są to użycie istniejących API w jądrze, obsługa architektury i pytanie o zgodność ABI między Rust i C.
W rzeczywistości początkowo w to wierzą wprowadzenie Rusta do struktury drzewa musi uwzględniać istniejące C API.
Jednak każdy czuje, że diabeł tkwi w szczegółach, a zarówno dotychczasowa praca, jak i rozmowa podczas sesji ujawniły otwarte wyzwania.
Na przykład Linux w dużym stopniu wykorzystuje makra preprocesora i funkcje wbudowane, które nie są tak łatwo obsługiwane przez narzędzie bindgen i interfejs funkcji zewnętrznych Rusta.
Według nich, obecnie jedyną dojrzałą implementacją Rusta jest kompilator rustc, który wydaje kod za pośrednictwem LLVM.
Jądro Linuksa obsługuje wiele różnych architektur, z których wiele nie ma dostępnego zaplecza LLVM.
Ze swojej strony Triplett zasugerował, że dodanie Rusta do jądra pomogłoby zwiększyć wsparcie architektoniczne dla Rusta, powołując się na jego doświadczenie z projektem Debian. Wspomniał, że wprowadzenie oprogramowania Rust w Debianie pomogło zmotywować entuzjastów i użytkowników niszowych architektur do ulepszenia obsługi Rusta, i ma nadzieję, że dodanie obsługi jądra będzie miało podobny efekt.
W szczególności był przekonany, że każda architektura z zapleczem LLVM będzie szybko kompatybilna z Rust. Dyskusja skupiła się również na alternatywnych implementacjach Rusta jako ścieżce do szerszego wsparcia architektury.
Sesja zakończyła się bez dalszych konkretnych kamieni milowych, ale wydaje się, że istnieje ogólny entuzjazm dla wspierania modów Rusta i rosnąca zgoda co do ogólnych wymagań tego wsparcia.
Wydaje się, że to początek nowej ery, pojawia się nieruchoma C.
Cześć Rust, Cześć Linus Torvalds!