Linux 7.4-rc1 rende più visibili i test mancanti
Un rapporto facoltativo per suite distingue il successo del comando dai test effettivamente preparati.
Linux 7.4 è arrivato alla prima release candidate con un miglioramento poco appariscente, ma importante per chi verifica il kernel: a una compilazione riuscita si può affiancare un resoconto delle suite di test effettivamente compilate. Il successo del comando principale, infatti, non ha mai garantito da solo che tutti i test richiesti fossero pronti per essere eseguiti.
Il tag 7.4-rc1 apre la fase di stabilizzazione: non identifica una versione definitiva da installare come normale aggiornamento. Fra le novità integrate in questo ciclo, la documentazione kselftest della stessa versione descrive un nuovo rapporto leggibile dagli strumenti automatici. Serve a rendere visibili le lacune prima che vengano scambiate per copertura.
Un comando riuscito può nascondere test mancanti
Kselftest raccoglie test che esercitano interfacce e comportamenti del kernel. Prepararli ed eseguirli sono operazioni distinte. Un test che non è stato compilato non potrà segnalare un errore durante l'esecuzione: semplicemente, non arriverà alla macchina incaricata di lanciarlo.
Il sistema ammette intenzionalmente compilazioni parziali. Se non si richiede una modalità più rigorosa, il comando generale può riuscire quando almeno un obiettivo viene compilato. È una scelta utile in presenza di architetture e dipendenze differenti: un requisito mancante per una suite non deve necessariamente impedire di usare tutte le altre.
Il problema nasce quando un processo automatico interpreta quel risultato positivo come prova che esista l'intero insieme previsto. Immaginiamo un lavoro che debba preparare due suite: una viene compilata, all'altra manca una dipendenza. Il lavoro complessivo può apparire regolare mentre la copertura effettiva si è ridotta. È un esempio del comportamento documentato, non la ricostruzione di un incidente specifico.
Un elenco verificabile al posto di un solo codice
La variabile KSFT_BUILD_REPORT indica il file al quale le operazioni di compilazione e installazione aggiungono i propri risultati. Ogni record contiene fase, nome dell'obiettivo e codice di uscita. Il formato separato da tabulazioni permette a un sistema di integrazione continua di confrontare quanto ottenuto con quanto previsto, senza dover interpretare un lungo resoconto del terminale.
La lettura richiede alcune attenzioni. Lo stesso obiettivo può comparire più volte, perché l'installazione può avviare un'altra compilazione; alcune suite comprendono inoltre sottocartelle con record propri. Secondo la documentazione, un obiettivo è riuscito soltanto se tutti i record associati hanno codice zero. Un record assente non dimostra un successo. Chi avvia il lavoro deve anche creare o svuotare il file: mescolare esecuzioni diverse renderebbe il confronto poco affidabile.
Il rapporto documenta la preparazione dei test. Non certifica che siano stati successivamente eseguiti, che verifichino ogni comportamento importante o che il kernel sia privo di regressioni. Questa distinzione ne delimita l'utilità senza diminuirla.
Registrare ed esigere sono scelte diverse
Il Makefile della versione 7.4-rc1 conserva una separazione chiara. FORCE_TARGETS=1 richiede di interrompere la compilazione quando un obiettivo fallisce. Attivare il rapporto, da solo, non modifica questa politica né il codice di uscita del comando.
Una macchina configurata per un insieme preciso di verifiche può esigere che siano disponibili tutte. Un'infrastruttura più eterogenea può accettare risultati parziali, registrando però quali combinazioni restano scoperte. La novità rende il secondo approccio più trasparente, senza costringerlo a esprimersi attraverso un unico segnale ambiguo.
Per chi segue Linux, conta anche il momento del ciclo di sviluppo. La documentazione del progetto identifica il periodo successivo alla finestra di integrazione come fase di stabilizzazione, con particolare attenzione alle regressioni. Un rapporto migliore aiuta a controllare una parte di questo lavoro. Il risultato utile non è una schermata con più indicatori verdi: è sapere quali verifiche sostengono davvero quegli indicatori.
