A Linux második számú "parancsnoka", Greg Kroah-Hartman szintén nagy támogatója a Rust kernelkódnak. Ma újabb LKML levelet írt, amelyben felvázolja a Rust előnyeit, és arra ösztönöz, hogy az új kernelkódok/illesztőprogramok C helyett Rust nyelven legyenek:
Mivel olyasvalaki vagyok, aki látott szinte MINDEN kernelhiba-javítást és biztonsági problémát az elmúlt 15+ évben (nos, remélhetőleg mindegyik bekerült a stabil ágakba, bár néha kihagyunk néhányat, amikor a karbantartók vagy fejlesztők elfelejtik megjelölni őket hibajavításként), és mint aki látja az összes kiadott kernel CVE-t, úgy gondolom, hogy tudok beszélni erről a témáról.
A legtöbb hiba (mennyiségben, nem minőségben vagy súlyosságban), amivel találkozunk, a C-ben lévő apró, bosszantó, speciális esetek miatt keletkeznek – ezek a Rustban teljesen eltűnnek. Olyan dolgokról van szó, mint az egyszerű memóriafelülírások (nem mintha a Rust mindet képes lenne elkapni), a hibakezelési takarítások, az error értékek ellenőrzésének elmulasztása és a use-after-free hibák. Ezért szeretném, ha a Rust bekerülne a kernelbe, mert ezek a problémák egyszerűen megszűnnek, így a fejlesztők és karbantartók több időt fordíthatnak a VALÓDI hibákra (például logikai hibákra, versenyhelyzetekre stb.).
Teljes mértékben támogatom, hogy a C kódbázisunkat olyan irányba mozdítsuk, amely lehetetlenné teszi ezeknek a problémáknak a felmerülését. Az, amit Kees, Gustavo és mások ezen a téren végeznek, csodálatos és teljesen szükséges munka. 30 millió sor C kódunk van, amely a közeljövőben nem fog eltűnni. Ez egy értékes erőfeszítés, amely nem fog leállni, és nem is szabad, hogy leálljon.
De az új kódok és driverek esetében, ha Rustban írjuk őket, ahol ezek a hibák egyszerűen nem fordulhatnak elő (vagy sokkal ritkábban), az mindenki számára előnyös – miért ne tennénk ezt? A C++ ebből semmit sem ad nekünk a következő évtizedben sem, és a C++ nyelvi bizottság problémái arra utalnak, hogy aki fenntartható kódbázist akar hosszú távon, az jobban teszi, ha minél hamarabb elhagyja ezt a nyelvet.
A Rust lehetőséget ad arra is, hogy az in-kernel API-jainkat úgy definiáljuk, hogy szinte lehetetlen legyen rosszul használni őket. Túl sok bonyolult és trükkös API-nk van, amelyek túl sok karbantartói átvizsgálást igényelnek csak azért, hogy „biztosak lehessünk benne, hogy jól használtad”. Ez részben abból fakad, ahogy az API-jaink az évek során fejlődtek (hány különböző módon lehet egy struct cdev-et biztonságosan használni?), és abból, hogy a C nem teszi lehetővé az API-k olyan formában történő kifejezését, amely biztonságosabbá és könnyebben használhatóvá teszi őket. Az, hogy minket, ezen API-k karbantartóit újragondolásra kényszerít, JÓ dolog, mert ezáltal mindenki számára – már a C felhasználók számára is – tisztábbá és jobbá tesszük őket, így a Linux összességében is jobb lesz.
És igen, a Rust kötései varázslatnak tűnnek számomra egyes helyeken, mivel nagyon kevés Rust-tapasztalatom van, de hajlandó vagyok tanulni és együtt dolgozni azokkal a fejlesztőkkel, akik hajlandóak segíteni ebben. Nem tanulni és nem változtatni az új bizonyítékok alapján (lásd a megjegyzésemet arról, hogy minden kernelhibát elolvasok) egyszerűen ostobaság lenne.
A Rust nem „ezüstgolyó”, amely minden problémánkat megoldja, de rengeteg helyen hatalmas segítség lesz, így ha új dolgokról van szó, miért ne akarnánk ezt?
A Linux egy eszköz, amelyet mindenki más használ a saját problémáinak megoldására, és itt vannak fejlesztők, akik azt mondják: „Hé, a mi problémánk az, hogy olyan kódot akarunk írni a hardverünkhöz, amelyben ezek a hibák automatikusan nem fordulhatnak elő.”
Miért hagynánk ezt figyelmen kívül?
Igen, tisztában vagyok a túlterhelt karbantartói problémával (mivel én is egy vagyok közülük), de itt vannak emberek, akik valóban elvégzik a munkát!
Igen, a kevert nyelvű kódbázisok nehezen kezelhetők és fenntarthatók, de mi kernelfejlesztők vagyunk, az isten szerelmére! Már régóta fenntartjuk és erősítjük a Linuxot, sokkal hosszabban, mint bárki valaha is gondolta volna, hogy lehetséges lesz. A fejlesztési modellünket egy jól működő mérnöki csodává alakítottuk, olyasmivé, amit senki más nem tudott elérni. Egy új nyelv hozzáadása igazán nem kellene, hogy problémát jelentsen – ennél sokkal rosszabb dolgokat is kezeltünk már, és most sem szabad feladnunk, ha a projektünk sikerét akarjuk biztosítani a következő 20+ évre. Amikor új, jó ötletekkel találkozunk, előre kell lépnünk, és támogatnunk kell azokat az embereket, akik ténylegesen elvégzik a munkát annak érdekében, hogy mindannyian együtt sikerrel járjunk.
Köszönettel,
Greg K-H