Linus Torvalds critica il codice dello scheduler Linux: "questo è disgustoso"

Lo scheduler rappresenta uno dei componenti più delicati del kernel Linux: decide quale processo eseguire, su quale CPU e per quanto tempo. Errori o inefficienze in questa area possono influire direttamente sulla latenza, sulla reattività del sistema e sul consumo energetico.

Con l’introduzione di sched_ext, gli sviluppatori possono implementare politiche di scheduling personalizzate sfruttando l’infrastruttura eBPF, senza modificare direttamente il codice centrale dello scheduler: si crea una sorta di laboratorio controllato dove testare nuove logiche prima di valutarne una possibile integrazione permanente.

Tuttavia, Linus Torvalds è nuovamente andato su tutte le furie esaminando una parte delle recenti modifiche destinate a sched_ext: “per favore, smettetela di fare questa cosa disgustosa“. Il fondatore di Linux non ha contestato le nuove funzionalità né la direzione tecnica del progetto: a farlo andare in escandescenza è stata invece l’organizzazione del codice sorgente.

Le motivazioni della critica di Linus Torvalds

Durante il merge delle modifiche destinate a Linux 7.2, Torvalds ha notato la comparsa di diversi file con prefisso ext_ direttamente all’interno della directory kernel/sched. Tra questi figuravano file come ext_arena.c, ext_cid.c ed ext_types.h. La scelta adottata dagli sviluppatori consisteva nell’utilizzare prefissi nei nomi per distinguere i componenti appartenenti a sched_ext.

La reazione del fondatore di Linux è stata immediata. Pur approvando il contenuto tecnico delle modifiche, ha criticato duramente l’organizzazione dei sorgenti, sostenendo che la presenza di numerosi file accomunati dallo stesso prefisso avrebbe dovuto portare alla creazione di una sottodirectory dedicata invece di affollare la cartella principale dello scheduler.

Per Torvalds, l’utilizzo di prefissi per simulare una gerarchia rappresenta una soluzione superata quando il sistema operativo mette già a disposizione strumenti migliori per organizzare il codice. Da qui l’ironico riferimento ai filesystem gerarchici disponibili “dal 1965”.

Il commento del “re pinguino”, pubblicato durante il processo di integrazione del codice, non lascia spazio a interpretazioni: “c’è un motivo se esistono le sottodirectory: servono per raggruppare i file e separarli dal resto. Usare prefissi nei nomi invece delle directory è disgustoso e sbagliato“.

Organizzazione del codice e manutenzione: una questione centrale

Chi osserva il kernel Linux dall’esterno potrebbe considerare la vicenda come una disputa superficiale e davvero di poco conto. In realtà il tema è concreto.

Il codice del kernel supera ormai decine di milioni di linee distribuite tra migliaia di directory e sottosistemi. Quando un progetto cresce, la struttura dei file diventa un elemento tecnico a tutti gli effetti: una cattiva organizzazione aumenta il tempo necessario per individuare bug, comprendere dipendenze e introdurre nuove funzionalità.

Linux ha sempre attribuito enorme importanza alla chiarezza architetturale: gli aspetti che Torvalds porta sul tavolo riguardano spesso proprio quegli aspetti capaci di influenzare la qualità del codice nel lungo periodo. Nel caso di specie, la scelta tra prefissi nei nomi dei file e directory dedicate determina come gli sviluppatori percepiscono i confini di un sottosistema e quanto facilmente riescono a individuarne i componenti.

L’episodio assume un significato ulteriore perché arriva mentre sched_ext continua ad ampliarsi. Le modifiche integrate in Linux 7.2 includono ulteriori lavori sul supporto ai sub-scheduler, una funzionalità che permette di gestire politiche di pianificazione più articolate e specializzate.

La risposta a Linus Torvalds è arrivata in tempi record

La discussione non si è trascinata per settimane. Nel giro di poche ore, gli sviluppatori “apostrofati” da Torvalds hanno preparato una nuova pull request destinata esclusivamente alla riorganizzazione dei file.

La modifica ha introdotto una nuova directory kernel/sched/ext/, spostando al suo interno i componenti collegati a sched_ext. Torvalds, dal canto suo, ha integrato rapidamente la revisione, chiudendo la questione quasi immediatamente.

Dal punto di vista funzionale non cambia nulla: il comportamento del codice resta identico. Cambia però la leggibilità dell’albero sorgente e la facilità con cui un manutentore può orientarsi tra i vari moduli nel corso degli anni.

L’immagine in anteprima non è una rappresentazione reale di Linus Torvalds: trattasi di una rielaborazione creativa, frutto di fantasia.