Egy rövid visszapillantás: hogyan jutottunk el idáig

A Rust for Linux projekt évek óta fut Miguel Ojeda és csapata vezetésével, de az igazi mérföldkő 2022 decemberében jött el: a Linux 6.1-es kernelbe bekerült az első, kísérleti Rust-infrastruktúra. Ez önmagában még nem jelentett éles Rust drivereket, hanem azt, hogy a kernel build rendszere (Kbuild) képes lett Rust forrásfájlokat is lefordítani, és bekerültek az alapvető absztrakciók (kernel crate), amelyekre a jövőbeli modulok építhetnek.

A CONFIG_RUST kapcsoló bekapcsolásával ma is csak kísérleti (EXPERIMENTAL) funkcióról beszélünk – ez nem egy "most már minden driver Rustban készül" pillanat volt, hanem inkább egy alapkő lerakása. 2023. február 19-én megjelent a Linux 6.2 is, amely tovább csiszolta ezt az infrastruktúrát: pontosabb absztrakciókat kaptunk a Result, a String, és a memóriakezelés köré, illetve javult a bindgen-alapú C-header generálás megbízhatósága.

ℹ
Megjegyzés

A kernelbeli Rust-támogatás célja NEM az, hogy lecserélje a C-t, hanem hogy egy második, memóriabiztos nyelvet adjon az új driverek és modulok írásához – a meglévő C kódbázis természetesen érintetlen marad.

Milyen driverek és modulok készülnek Rust nyelven

A jelenlegi upstream kernelfában elsősorban minta- (samples/rust/) és teszt-modulokat találunk, amelyek azt demonstrálják, hogyan néz ki egy minimális Rust kernel modul. Egy ilyen minta nagyjából így fest:

// SPDX-License-Identifier: GPL-2.0

//! Rust minimal sample.

use kernel::prelude::*;

module! {
    type: RustMinimal,
    name: "rust_minimal",
    author: "Rust for Linux Contributors",
    description: "Rust minimal sample",
    license: "GPL",
}

struct RustMinimal {
    message: String,
}

impl kernel::Module for RustMinimal {
    fn init(_module: &'static ThisModule) -> Result<Self> {
        pr_info!("Rust minimal sample (init)\n");
        Ok(RustMinimal {
            message: "on the heap!".try_to_owned()?,
        })
    }
}

impl Drop for RustMinimal {
    fn drop(&mut self) {
        pr_info!("My message is {}\n", self.message);
        pr_info!("Rust minimal sample (exit)\n");
    }
}

Ez persze még messze van egy éles driverstől, de jól mutatja a module! makrót és a hibakezelést Result-tal, allokáció nélküli panic-mentes stílusban.

A valódi, izgalmasabb munka a fán kívül zajlik. Az Asahi Linux projekt – amely az Apple Silicon (M1/M2) Mac gépeken futtat Linuxot – Asahi Lina vezetésével Rust nyelven írja az Apple GPU-khoz tartozó driver jelentős részét. Ez az egyik legkomolyabb bizonyíték arra, hogy Rust drivert lehet írni bonyolult, valós hardverhez, még ha egyelőre nem is upstream.

Emellett Andreas Hindborg (Samsung) egy NVMe driver Rust proof-of-concept-jén dolgozik, amit több konferencián is bemutatott – ez a blokkeszköz-réteg Rust-absztrakcióit hivatott tesztelni. Az Android csapatnál is folynak kísérletek a Binder IPC driver Rust-implementációjával kapcsolatban, bár ez még korai fázisban van.

✦
Tipp

Ha kíváncsi vagy a legfrissebb patch-ekre, érdemes követni a rust-for-linux mailing listát és a projekt GitHub tükrét – a legtöbb driver-kísérlet egyelőre ott, nem az upstream fában él.

Fejlesztői visszhang: lelkesedés és szkepticizmus

A kernel közösség reakciói vegyesek. Linus Torvalds végig támogató volt a kísérlettel kapcsolatban, és több alkalommal is hangsúlyozta, hogy ez egy tanulási folyamat mindkét oldalnak. Ugyanakkor több régi motoros maintainer, köztük Christoph Hellwig is nyíltan szkeptikus volt: a fő aggály az, hogy egy második nyelv bevezetése megduplázza a karbantartási terhet, két toolchaint kell szinkronban tartani, és a C ABI-hoz való Rust-oldali kötések (bindings) törékenyek lehetnek a kernel API-k gyakori változása miatt.

A 2023. februári FOSDEM-en (Brüsszel) külön Rust-devroom foglalkozott ezekkel a kérdésekkel – az előadások jó része arról szólt, hogyan lehet a Rust absztrakciós réteget úgy tervezni, hogy ne kelljen minden C API-változásnál újraírni a bindingeket.

Nyitott kérdés marad többek között:

  • Mely alrendszerek nyithatók meg hivatalosan Rust drivereknek (jelenleg PCI, platform driver, és blokkeszköz absztrakciók vannak napirenden)
  • Hogyan kezelendő a minimum támogatott Rust verzió (MSRV) a kernel élettartama alatt
  • Milyen garanciákat vállal a Rust oldal a unsafe blokkok auditálhatóságára

Toolchain-követelmények: melyik Rust kell a kernel buildhez

Itt jön a gyakorlati rész, ami sok fejlesztőt meglep: a kernel NEM a stabil Rust toolchain-t használja. A build egy pontosan rögzített nightly Rust verziót igényel, mert a kernelbeli kód olyan unstable core/alloc funkciókra épít (pl. allocator_api, new_uninit, negative_impls), amelyek 2023 elején még nem stabilizálódtak.

A gyakorlatban ez azt jelenti, hogy rustup-pal kell telepíteni a kernel forrásfájában dokumentált pontos nightly build-et, plusz a rust-src komponenst (mert a core/alloc crate-eket újra kell fordítani a kernel saját allokátorával), valamint egy kompatibilis bindgen verziót (0.56 vagy újabb) és egy hozzáillő libclang-ot a header-generáláshoz.

// Egyszerű illusztráció arra, milyen stabil, 1.67-ig elérhető
// nyelvi elemekre épít a kernel oldali Rust kód – pl. GATs és let-else
// (mindkettő stabil funkció már a jelen kernel build-jeiben is).

trait DeviceBuffer {
    type View<'a>
    where
        Self: 'a;

    fn view(&self) -> Self::View<'_>;
}

fn parse_len(raw: Option<&[u8]>) -> usize {
    let Some(bytes) = raw else {
        return 0;
    };
    bytes.len()
}

A fenti GATs-alapú minta jól mutatja, miért is örülnek a kernel fejlesztők annak, hogy a Generic Associated Types és a let-else már stabil nyelvi elemek – ezekre komoly absztrakciókat lehet építeni a driver-rétegben, anélkül hogy unstable feature flagre kellene támaszkodni ezen a ponton.

⚠
Figyelem

Ha csak kipróbálnád a mintákat, ne a rendszered alapértelmezett stabil Rust-jával próbálkozz – a kernelfa scripts/min-tool-version.sh és a Rust-specifikus dokumentáció (Documentation/rust/quick-start.rst) pontosan megmondja, melyik nightly build kell, és build hiba lesz a vége, ha eltérsz tőle.

Mi várható a következő hónapokban

A roadmap szintjén több irány rajzolódik ki. Egyrészt folytatódik az absztrakciós réteg bővítése: workqueue, timer, és további szinkronizációs primitívek Rust-wrapperei vannak soron, hogy egyre komplexebb drivereket lehessen írni C kód másolgatása nélkül. Másrészt várható, hogy az Asahi GPU driver és az NVMe PoC tapasztalatai alapján konkrét RFC-k érkeznek majd az upstream integrációra vonatkozóan.

A közösség emellett dolgozik azon is, hogy csökkentse a nightly-függőséget – hosszabb távon cél, hogy minél kevesebb unstable feature-re legyen szükség, ahogy a Rust standard könyvtár és a nyelv is stabilizálja a szükséges elemeket. Ez azonban türelemjáték: több, a kernel szempontjából kulcsfontosságú funkció (pl. bővebb alloc API-k) még csak RFC vagy nightly szinten léteznek.

✓
Jó tudni

A projekt jelenlegi állapota szerint még messze vagyunk attól, hogy "Rust driver az alapértelmezett Ubuntu kernelben" híreket olvassunk – de az irány egyértelmű, és a tempó biztató.

Összefoglalás

A Rust a Linux kernelben történet 2023 februárjában még javában a kísérletezés fázisában van: van upstream infrastruktúra, vannak minta-modulok, és több ígéretes, éles hardvert célzó driver-kísérlet fut a fán kívül. A fejlesztői közösség megosztott a hosszú távú karbantarthatóság kérdésében, a toolchain pedig egyelőre szigorúan egy rögzített nightly verzióhoz van kötve. Ha szereted a systems programozást és izgat a memóriabiztonság kérdése alacsony szinten, most van itt az ideje, hogy közelebbről is megnézd ezt a projektet – a következő néhány kernel release minden bizonnyal további izgalmas fejleményeket hoz.