Linux cerca più sviluppatori Rust: l'appello di Greg Kroah-Hartman

Una delle figure indicate come più “papabili” per raccogliere l’eredità tecnica di Linus Torvalds è Greg Kroah-Hartman. È maintainer del ramo stabile del kernel Linux, supervisiona numerosi sottosistemi e gestisce una parte enorme del lavoro di integrazione e stabilizzazione. In pratica è già il numero due operativo del progetto tanto che quando emergono regressioni critiche o problemi che richiedono backport rapidi sulle release supportate, spesso è lui a coordinare il lavoro.

Durante la Rust Week 2026, Kroah-Hartman ha parlato di manutenzione del codice, sostenibilità dei driver e riduzione dei bug che continuano a colpire il kernel scritto in linguaggio C. Il dettaglio interessante è che a parlarne non è un “fan” del linguaggio Rust, ma uno dei manutentori più influenti dell’intero progetto Linux.

Rust: più divertente per i maintainer e più sicuro per gli utenti Linux

Negli ultimi anni l’integrazione di Rust nel kernel Linux ha generato tensioni piuttosto forti: diversi sviluppatori storici hanno criticato apertamente l’introduzione di una seconda toolchain, l’aumento della complessità nella manutenzione e il rischio di frammentare ulteriormente il lavoro di revisione del codice.

In mailing list non sono mancati scontri accesi: alcuni maintainer ritenevano che il C restasse più che sufficiente, soprattutto considerando decenni di strumenti, debugging e competenze accumulate. Altri contestavano l’idea di affidarsi a un linguaggio più moderno senza avere ancora API complete per componenti delicati come DMA, interrupt e gestione avanzata della memoria. Alla fine Linus Torvalds ha battuto i pugni sul tavolo concludendo che il codice Rust si merita assolutamente spazio nel kernel. E poco dopo, a fine dicembre 2025, Rust è stato dichiarato un progetto non più “sperimentale”.

Quando una figura come Kroah-Hartman sostiene pubblicamente che Rust renda la manutenzione “più divertente” e il kernel “più sicuro“, il messaggio difficilmente può essere liquidato come semplice entusiasmo tecnologico.

Il “braccio destro” di Torvalds osserva il problema dalla prospettiva di chi deve gestire milioni di linee di codice nel lungo periodo. Vede direttamente quanto tempo venga assorbito ancora oggi da bug di memoria, race condition e crash provocati da errori tipici del C.

Il kernel Linux non diventerà un progetto Rust

Una delle interpretazioni più superficiali della vicenda consiste nel descrivere Rust come il successore del C dentro il kernel Linux. In realtà nessuno, tanto meno Torvalds e Kroah-Hartman, sostiene un’idea del genere. Il kernel resta e resterà prevalentemente scritto in C.

Le dimensioni del codice esistente rendono impraticabile qualsiasi riscrittura massiva: parliamo di milioni di righe sviluppate in oltre 30 anni, con interazioni hardware estremamente delicate.

Rust entra soprattutto nei nuovi driver e nei nuovi componenti, specialmente dove la sicurezza della memoria pesa di più. Dal punto di vista tecnico, il supporto Rust nel kernel richiede una toolchain dedicata: le release recenti utilizzano versioni moderne del compilatore rustc, oltre a binding specifici per le API kernel.

Perché i manutentori Linux guardano Rust con crescente interesse

La parte più significativa dell’intervento di Kroah-Hartman nel corso della Rust Week 2026 riguarda probabilmente la manutenzione del codice nel lungo periodo. Il kernel Linux non soffre solo di vulnerabilità, che periodicamente vengono a galla, ma lamenta la complessità accumulata in decenni di sviluppo C.

Chi sviluppa driver o componenti del kernel deve gestire la memoria in modo manuale, sincronizzare l’accesso alle risorse condivise tramite meccanismi di locking, controllare con attenzione il conteggio dei riferimenti agli oggetti in memoria e affrontare percorsi di errore spesso complessi. In C è sufficiente dimenticare una free, cioè il rilascio della memoria allocata, utilizzare un puntatore non più valido oppure gestire in modo errato una race condition, una situazione in cui più processi o thread accedono contemporaneamente agli stessi dati, per introdurre bug molto difficili da individuare e correggere.

Rust prova a spostare una parte enorme di quel lavoro direttamente nel compilatore che impedisce, salvo uso esplicito di blocchi unsafe, l’accesso concorrente non sincronizzato ai dati e l’utilizzo di memoria non valida. Va detto però che il kernel Linux non può usare Rust “puro” come farebbe un’applicazione in esecuzione in userspace: serve comunque codice unsafe per interagire con hardware, DMA, interrupt e strutture interne del kernel.

Rust non elimina automaticamente ogni vulnerabilità: riduce però enormemente la superficie di errore nel codice ordinario, confinando le operazioni realmente rischiose in sezioni molto più isolate e verificabili. Ed è proprio su questo che insiste Kroah-Hartman: un driver con meno bug di memoria significa meno patch urgenti, meno regressioni nei rami stable e meno ore spese a fare debugging su crash riproducibili solo con determinate configurazioni hardware.

Rust Week 2026 segna un passaggio simbolico importante

La presenza di  Kroah-Hartman alla Rust Week 2026 assume un valore che va oltre la singola conferenza. Non capita spesso che uno dei responsabili principali della stabilità del kernel Linux partecipi come relatore a un evento interamente dedicato a un linguaggio nato fuori dal mondo Unix classico.

Il messaggio finale del suo intervento è diretto: servono più sviluppatori Rust interessati al kernel Linux. Non soltanto per scrivere codice, ma anche per mantenere binding, documentazione, condurre review e abilitare l’integrazione con i sottosistemi esistenti.

Linux sta entrando in una fase ibrida: il C resta dominante, ma Rust inizia a occupare posizioni considerate troppo delicate per continuare a tollerare certe categorie di errori storici.