Con 14.000 changeset per release di oltre 1.700 sviluppatori diversi, è chiaro che il kernel Linux si muove rapidamente e porta molta complessità. I bug del kernel vanno da piccoli fastidi a problemi più grandi, come arresti anomali del sistema e perdita di dati.
Mentre cresce la richiesta di integrazione continua (CI) per un numero sempre maggiore di progetti, il team di Continuous Kernel Integration (CKI) procede con un'unica missione:impedire che i bug vengano fusi in il kernel.
Problemi di test di Linux
Molte distribuzioni Linux testano il kernel Linux quando necessario. Questo test si verifica spesso durante il rilascio o quando gli utenti trovano un bug.
A volte compaiono problemi non correlati ei manutentori si affannano per trovare quale patch in un changeset pieno di decine di migliaia di patch ha causato il nuovo bug non correlato. La diagnosi del bug potrebbe richiedere hardware specializzato, una serie di trigger e una conoscenza specializzata di quella parte del kernel.
CI e Linux
La maggior parte dei moderni repository di software ha una sorta di test CI automatizzato che verifica i commit prima che trovino la loro strada nel repository. Questo test automatizzato consente ai manutentori di trovare problemi di qualità del software, insieme alla maggior parte dei bug, esaminando il rapporto CI. I progetti più semplici, come una libreria Python, sono dotati di moltissimi strumenti per semplificare questo processo.
Linux deve essere configurato e compilato prima di qualsiasi test. Ciò richiede tempo e risorse di calcolo. Inoltre, quel kernel deve essere avviato in una macchina virtuale o su una macchina bare metal per il test. L'accesso a determinate architetture di sistema richiede spese aggiuntive o un'emulazione molto lenta. Da lì, qualcuno deve identificare una serie di test che attivano il bug o verificano la correzione.
Come lavora il team CKI
Il team CKI di Red Hat segue attualmente le modifiche da diversi kernel interni, così come i kernel a monte come l'albero del kernel stabile. Osserviamo due eventi critici in ogni repository:
Quando i manutentori uniscono richieste pull o patch e i commit risultanti nel repository cambiano.
Quando gli sviluppatori propongono modifiche per l'unione tramite patchwork o la coda di patch stabile.
Quando si verificano questi eventi, l'automazione entra in azione e le pipeline CI di GitLab iniziano il processo di test. Una volta che la pipeline esegue gli script di linting, unisce le patch e compila il kernel per più architetture, inizia il vero test. Compiliamo i kernel in meno di sei minuti per quattro architetture e inviamo feedback alla mailing list stabile di solito in due ore o meno. Ogni mese vengono eseguiti oltre 100.000 test del kernel e sono state completate oltre 11.000 pipeline GitLab (da gennaio 2019).
Ogni kernel viene avviato sulla sua architettura nativa, che include:
● aarch64:ARM a 64 bit, come Cavium (ora Marvell) ThunderX.
● ppc64/ppc64le:sistemi IBM POWER big e little endian.
● s390x:mainframe IBM Zseries.
● x86_64:workstation, laptop e server Intel e AMD.
Più test vengono eseguiti su questi kernel, incluso Linux Test Project (LTP), che contiene una miriade di test che utilizzano un cablaggio di test comune. Il mio team CKI ha reso open source oltre 44 test con altri in arrivo.
Partecipa
Lo sforzo di test del kernel a monte aumenta di giorno in giorno. Molte aziende forniscono risultati di test per vari kernel, inclusi Google, Intel, Linaro e Sony. Ogni sforzo è focalizzato sul portare valore al kernel a monte e alla base di clienti di ciascuna azienda.
Se tu o la tua azienda volete unirvi allo sforzo, partecipate alla Linux Plumbers Conference 2019 a Lisbona, in Portogallo. Unisciti a noi all'hackfest Kernel CI durante i due giorni successivi alla conferenza e guida il futuro dei test rapidi del kernel.
Per maggiori dettagli, rivedi le diapositive del mio intervento al Texas Linux Fest 2019.