Linus Torvalds spiega perché gli aggiornamenti del kernel Linux diventano più pesanti

L’intelligenza artificiale sta producendo un effetto piuttosto curioso sullo sviluppo del kernel Linux: la dimensione delle correzioni per le varie release continua ad aumentare.

Linux nasce nel 1991 e da oltre trent’anni cresce attraverso un processo distribuito nel quale sviluppatori e maintainer controllano patch, regressioni e problemi prima dei rilasci in versione stabile. Oggi una parte rilevante di quel lavoro di analisi può sfruttare strumenti basati su modelli generativi, analizzatori automatici e agenti capaci di scandagliare enormi quantità di codice. Linus Torvalds parla ormai di una sorta di una “nuova normalità“: più strumenti trovano difetti, più fix arrivano nelle fasi finali del ciclo di sviluppo. Con Linux 7.2 il fenomeno è diventato sempre più evidente.

Linux 7.2: le release candidate sono molto più grandi del previsto

La prima avvisaglia significativa è arrivata con Linux 7.2-rc6, pubblicata il 2 agosto 2026. Torvalds ha osservato che si trattava probabilmente della rc6 con il maggior numero di commit vista da anni. Le statistiche non mostravano però interventi concentrati su di un singolo sottosistema: poco meno del 60% delle modifiche riguardava i driver, circa il 20% il networking e il resto architetture, filesystem, strumenti e altre parti del kernel.

Nessuna correzione gigantesca ma tantissimi interventi relativamente piccoli: tra i driver comparivano modifiche a GPU, rete, audio, SPI e ATA; sul versante networking pesava inoltre un arretrato che Torvalds ha ricollegato almeno in parte ai tempi delle conferenze e alla conseguente organizzazione del lavoro dei maintainer.

Il dato numerico rende bene l’idea: tra rc5 e rc6 sono entrati 537 commit. Un volume di patch tale che dovrebbe portare a ridimensionare le modifiche previste per le uscite successive.

Invece, la rc7 di Linux 7.2, pubblicata il 9 agosto, non ha invertito chiaramente la tendenza: Torvalds ha ammesso di non essere particolarmente soddisfatto delle dimensioni complessive, aggiungendo però un passaggio importante: molti fix derivano dal lavoro di revisione effettuato tramite vari strumenti AI.

La nuova politica Linux per gli assistenti AI è molto precisa

L’affermazione di Torvalds non implica che Linux 7.2 sia improvvisamente pieno di codice generato automaticamente. Gli strumenti di intelligenza artificiale possono intervenire in varie fasi: analizzare sorgenti, individuare pattern sospetti, confrontare percorsi di esecuzione, suggerire condizioni limite e aiutare a localizzare errori che successivamente un essere umano verifica e corregge.

La comunità del kernel non ha scelto di vietare questi strumenti. Anzi, la documentazione ufficiale include ormai una sezione specifica dedicata agli AI Coding Assistants, con regole piuttosto severe per chi li utilizza.

Un agente AI, ad esempio, non può arrogarsi il diritto di presentare una modifica e di assumersene la responsabilità perché sono prerogative di un essere umano con lo specifico ruolo di maintainer. Il responsabile deve quindi controllare il codice prodotto, verificarne la compatibilità con GPL-2.0-only e con le regole di licensing, aggiungere personalmente l’indicazione Signed-off-by e assumersi la responsabilità della patch. La documentazione propone inoltre il tag Assisted-by per indicare esplicitamente l’utilizzo di un agente AI e, quando possibile, il modello impiegato.

Ancora più interessante è la procedura suggerita per la ricerca dei bug. La documentazione richiede di tentare la creazione di un reproducer per i problemi non banali, preparare una correzione, compilare il kernel, ripetere l’analisi e verificare che la patch risolva davvero il difetto. Se non fosse possibile testare qualcosa, bisogna dichiararlo. Non basta quindi chiedere a un LLM “trova una vulnerabilità in questo file” e inviare la risposta sulla mailing list del kernel Linux.

Linus Torvalds: le preoccupazioni residue

Nel modello di sviluppo Linux, ogni versione stabile nasce dopo una merge window iniziale durante la quale arrivano le nuove funzionalità. Seguono normalmente diverse release candidate settimanali: rc1, rc2, rc3 e così via. Come osservato in precedenza, man mano che ci si avvicina alla release definitiva, il numero e soprattutto la portata delle modifiche dovrebbero diminuire.

Una rc7 con molti commit non è quindi ideale: ogni fix modifica codice che deve essere nuovamente compilato, testato e controllato; una correzione può a sua volta introdurre una regressione. Per questa ragione Torvalds guarda con attenzione non soltanto al numero di patch ma anche alla loro natura.

Nel caso di Linux 7.2-rc7, però, il “re pinguino” ha fatto presente di non aver rilevato nulla di particolarmente allarmante. La maggioranza delle modifiche risultava di dimensioni ridotte e distribuita tra driver GPU, audio e networking, filesystem, codice architetturale e stack di rete.

Tre gruppi di interventi risultano più consistenti degli altri. Il primo riguarda s390/zcrypt, cioè il sottosistema usato sui mainframe IBM Z per gestire l’accelerazione crittografica hardware e l’accesso agli adattatori dedicati alle operazioni di cifratura. Un secondo blocco interessava Btrfs: nel kernel è tornata parte dell’infrastruttura dei cosiddetti fixup worker, thread di lavoro impiegati dal filesystem per completare in modo differito alcune operazioni di correzione e aggiornamento interno.

Infine, Torvalds ha citato alcune modifiche a Netfilter ipset, il componente che permette al firewall Linux di gestire insiemi di indirizzi IP, reti, porte o altri elementi e di applicare regole in modo più efficiente rispetto a lunghe sequenze di corrispondenze individuali.

Al di fuori di questi interventi relativamente più estesi, la rc7 raccoglie soprattutto molte correzioni piccole e distribuite: una release candidate grande, quindi, ma senza un singolo problema dominante tale da rendere inevitabile un rinvio della versione stabile.