A Linux kernel fejlesztői közösségében hosszabb ideje napirenden volt hogy a Rust támogatása maradjon kísérleti jellegű, vagy inkább véglegesítsék a státuszát. Mostanra egyértelmű döntés született: a fejlesztők hivatalosan is lezárták a Rust kísérleti időszakát. Miguel Ojeda pedig tömören így foglalta össze a helyzetet: „The experiment is done, i.e. Rust is here to stay”, vagyis a kísérlet véget ért, a Rust marad. Ez az álláspont decemberben már ismert volt, most viszont a Linux 7.0 fejlesztési ciklusa elején Linushoz is megérkezett a beolvasztási kérelem egy pull request formájában aki várhatóan elfogadja azt, így a Linux 7.0 kernellel hivatalosan is lekerülhet az „experimental” címke a Rustról.
Tartalomjegyzék
Rust nyelv frissítések is érkeznek a Linux 7.0 kernelhez
Miguel Ojeda a rust-for-linux levelezőlistán közzétett, Linus Torvaldsnak címzett pull requestjében a Rust-támogatás következő frissítési körének beemelését kérte a 7.0-s fejlesztési ciklushoz, és külön jelezte, hogy ez most egy közepes méretű csomag. A leírás szerint a legnagyobb technológiai váltás a procedurális makrók átszervezése: a korábbi, saját megoldások helyett a projekt a már bevezetett syn könyvtárra támaszkodik, ami pontosabb hibajelzéseket és átláthatóbb karbantartást hozhat a Rustos makrórétegben.
Ugyanebben a pull requestben érkezik a __rust_helper annotáció is, amely azt szolgálja, hogy a C-ben megírt Rust-segédfüggvények jobban illeszkedjenek a kernel LTO-s fordításához, főként az inlining és a kódösszefésülés szempontjából. Emellett több kisebb, crate szintű fejlesztés és belső rendbetétel is része a csomagnak, emellett több kisebb fejlesztés is érkezik, köztük új segédmakrók. A fejlesztés fókusza most a háttérben futó feladatokon van: a kódbázis rendezésén, a diagnosztikán és a fordítási lánc illesztésén, nem pedig új funkciók bevezetésén.
Rövid Rust-kritika a kernel szempontjából
A Rust kernelbeli jövője most már elég stabilnak tűnik, ettől még nem célszerű úgy kezelni, mintha ezzel automatikusan minden probléma eltűnne. A legjobban érezhető mellékhatás a bonyolultság növekedése: ugyanazon a kódbázison belül két nyelvhez és két eszközlánchoz kell igazodni, több szabályt kell követni, így a karbantartók terhelése is nő. A felülvizsgálatoknál ez különösen érezhető, mert a kernelben a karbantartók felelnek azért, hogy mi kerülhet be a kódbázisba. Rustos módosításoknál viszont a valóban alapos ellenőrzéshez olyan reviewer kell, aki Rustot is magas szinten ismeri, ebből pedig ma még jóval kevesebb van, mint C-ben jártas fejlesztőből.
További nehézség, hogy a kernelben rengeteg feladat eleve nagyon alacsony szintű és erősen hardverközeli, ráadásul sokszor olyan kényes területeket érint, ahol a teljesen biztonságos absztrakciók nem illeszthetők be kompromisszumok nélkül. Ilyenkor a Rust előnyei kisebbek, mert a munka egy része szükségszerűen olyan kódrészekhez vezet, ahol a helyes működés továbbra is a fejlesztő fegyelmén és körültekintésén múlik.
Ehhez társul, hogy a Rust bevezetését a közösség nem mindenhol fogadja azonos lelkesedéssel, ami időnként irányvitákat hozhat, különösen akkor, ha egy új Rustos megoldás egy régóta bevált C-s megközelítést kíván leváltani (Erre jó példa a Rust coreutils). Összességében a Rust a megfelelő helyeken implementálva akár még kifejezetten hasznos is lehet, de a kernelben nem nevezhető univerzális megoldásnak: a várható előnyökért cserébe nő a koordináció és a karbantartás terhe, amit a projektnek tartósan kezelnie kell.
