Miguel Ojeda, författare till Rust-for-Linux-projektet, har föreslagit ett tredje komponentalternativ för att utveckla drivrutiner i Rust-språket för Linux-kärnutvecklare att överväga. Roststöd anses vara experimentellt, men har redan kommit överens om att inkluderas i linux-next-grenen. Utvecklingen finansieras av Google och ISRG (Internet Security Research Group), som är grundare av Let's Encrypt-projektet och främjar HTTPS och utvecklingen av tekniker för att förbättra Internetsäkerheten.
Kom ihåg att de föreslagna ändringarna gör det möjligt att använda Rust som ett andra språk för att utveckla drivrutiner och kärnmoduler. Ruststöd presenteras som ett alternativ som inte är aktiverat som standard och resulterar inte i att Rust ingår som ett obligatoriskt byggberoende för kärnan. Genom att använda Rust för drivrutinsutveckling kan du skapa säkrare och bättre drivrutiner med minimal ansträngning, utan problem som minnesåtkomst efter frigöring, nollpekarereferenser och buffertöverskridanden.
Minnessäkerhet tillhandahålls i Rust vid kompileringstillfället genom referenskontroll, hålla reda på objektägande och objektlivslängd (scope), samt genom utvärdering av korrektheten av minnesåtkomst under kodexekvering. Rust ger också skydd mot heltalsspill, kräver obligatorisk initiering av variabelvärden innan användning, hanterar fel bättre i standardbiblioteket, tillämpar konceptet med oföränderliga referenser och variabler som standard, erbjuder stark statisk typning för att minimera logiska fel.
Den nya versionen av patcharna fortsätter att eliminera kommentarerna under diskussionen om den första och andra versionen av patcharna. De mest märkbara förändringarna:
- En övergång har gjorts till att använda den stabila versionen av Rust 1.57 som referenskompilator och en länk till den stabiliserade utgåvan av språket Rust 2021 har tillhandahållits. Tidigare var patchar knutna till betagrenen av Rust och använde några språkfunktioner som klassificerades som instabila. Övergången till Rust 2021-specifikationen gjorde det möjligt för oss att initiera arbete för att undvika användningen av sådana instabila funktioner i patchar som const_fn_transmute, const_panic, const_unavailable_unchecked och core_panic och try_reserve.
- Utvecklingen av allocversionen av Rust-biblioteket som ingår i patcharna har fortsatt, modifierad för att befria minnesallokeringsfunktionerna från möjlig generering av "panik"-tillståndet när fel uppstår, till exempel slut på minne. Den nya versionen implementerar alternativen "no_rc" och "no_sync" för att inaktivera funktionalitet som inte används i kärnans Rust-kod, vilket gör biblioteket mer modulärt. Arbetet fortsätter med de viktigaste alloc-utvecklarna, som syftar till att överföra de ändringar som behövs för kärnan till huvudbiblioteket. Alternativet "no_fp_fmt_parse", som krävs för att biblioteket ska fungera på kärnnivå, har flyttats till Rust-basbiblioteket (kärna).
- Koden har rensats för att bli av med möjliga kompilatorvarningar när kärnan byggs i CONFIG_WERROR-läge. När du bygger kod i Rust aktiveras ytterligare kompilatordiagnostiklägen och Clippy linter-varningar.
- Abstraktioner föreslås för användning i Rustkod för seqlocks (sekvenslås), callback-anrop för energihantering, I/O-minne (readX/writeX), avbrotts- och trådhanterare, GPIO, åtkomst till enheter, drivrutiner och referenser.
- Verktygen för utveckling av drivrutiner har utökats till att inkludera flyttbara mutexer, bititeratorer, förenklade pekarbindningar, förbättrad feldiagnostik och databussoberoende infrastruktur.
- Förbättrat arbete med länkar med en förenklad Ref-typ, baserad på refcount_t-backend, som använder kärn-API:et med samma namn för att räkna referenser. Stöd för Arc- och Rc-typerna som tillhandahålls i standardalloc-biblioteket har tagits bort och är inte tillgängligt i kod som körs på kärnnivå (alternativ har förberetts för själva biblioteket som inaktiverar dessa typer).
- Patcharna inkluderar en version av PL061 GPIO-drivrutinen, omskriven i Rust. En speciell egenskap hos drivrutinen är att dess implementering nästan rad för rad upprepar den befintliga GPIO-drivrutinen i C-språket. För utvecklare som vill bekanta sig med att skapa drivrutiner i Rust har en rad-för-rad-jämförelse utarbetats som gör att de kan förstå vilka konstruktioner i Rust som C-koden konverteras till.
- Den huvudsakliga Rust-kodbasen har antagit rustc_codegen_gcc, en rustc-backend för GCC som implementerar AOT-kompilering (ahead-of-time) med libgccjit-biblioteket. Med korrekt utveckling av backend kommer det att tillåta dig att samla in Rust-koden som är involverad i kärnan med hjälp av GCC.
- Förutom ARM, Google och Microsoft har Red Hat uttryckt intresse för att använda Rust-språket i Linux-kärnan. Låt oss komma ihåg att Google ger direkt stöd för Rust for Linux-projektet, utvecklar en ny implementering av Binders interprocess-kommunikationsmekanism i Rust och överväger möjligheten att omarbeta olika drivrutiner i Rust. Microsoft har börjat implementera drivrutiner för Hyper-V i Rust. ARM arbetar för att förbättra Rust-stödet för ARM-baserade system. IBM har implementerat Rust-stöd i kärnan för PowerPC-system.
Källa: opennet.ru