In Test di integrazione continui per il kernel Linux , ho scritto del progetto Continuous Kernel Integration (CKI) e della sua missione di cambiare il modo in cui funzionano gli sviluppatori e i manutentori del kernel. Questo articolo è un'analisi approfondita di alcuni degli aspetti più tecnici del progetto e di come tutti i pezzi si incastrano.
Tutto inizia con un cambiamento
Ogni caratteristica interessante, miglioramento e bug nel kernel inizia con una modifica proposta da uno sviluppatore. Queste modifiche appaiono su una miriade di mailing list per diversi repository del kernel. Alcuni repository si concentrano su determinati sottosistemi nel kernel, come l'archiviazione o il networking, mentre altri si concentrano su ampi aspetti del kernel. Il progetto CKI entra in azione quando gli sviluppatori propongono una modifica, o un set di patch, al kernel o quando un manutentore apporta modifiche al repository stesso.
Il progetto CKI mantiene trigger che monitorano questi patchset e agiscono. Progetti software come Patchwork rendono questo processo molto più semplice raccogliendo contributi multi-patch in un'unica serie di patch. Questa serie viaggia come un'unità attraverso il sistema CKI e consente di pubblicare un singolo rapporto sulla serie.
Altri trigger controllano il repository per le modifiche. Ciò si verifica quando i manutentori del kernel uniscono patchset, ripristinano patch o creano nuovi tag. Il test di queste modifiche critiche garantisce che gli sviluppatori abbiano sempre una solida base di riferimento da utilizzare come base per la scrittura di nuove patch.
Tutte queste modifiche entrano in una pipeline GitLab e passano attraverso più fasi e più sistemi.
Prepara la build
Tutto inizia con la preparazione del sorgente per la compilazione. Ciò richiede la clonazione del repository, l'applicazione del patchset proposto dallo sviluppatore e la generazione di un file di configurazione del kernel. Questi file di configurazione hanno migliaia di opzioni che attivano o disattivano le funzionalità e i file di configurazione differiscono incredibilmente tra le diverse architetture di sistema. Ad esempio, un sistema x86_64 abbastanza standard può avere un sacco di opzioni disponibili nel suo file di configurazione, ma un sistema s390x (mainframe IBM zSeries) ha probabilmente molte meno opzioni. Alcune opzioni potrebbero avere senso su quel mainframe ma non hanno alcuno scopo su un laptop consumer.
Il kernel va avanti e si trasforma in un artefatto sorgente. L'artefatto contiene l'intero repository, con le patch applicate, e tutti i file di configurazione del kernel necessari per la compilazione. I kernel upstream si spostano come tarball, mentre i kernel Red Hat diventano un RPM sorgente per il passaggio successivo.
Pile di compilazioni
La compilazione del kernel trasforma il codice sorgente in qualcosa che un computer può avviare e utilizzare. Il file di configurazione descrive cosa compilare, gli script nel kernel descrivono come compilarlo e gli strumenti sul sistema (come GCC e glibc) eseguono la compilazione. Questo processo richiede un po' di tempo per essere completato, ma il progetto CKI deve essere eseguito rapidamente per quattro architetture:aarch64 (ARM a 64 bit), ppc64le (POWER), s390x (IBM zSeries) e x86_64. È importante compilare rapidamente i kernel in modo da mantenere il nostro backlog gestibile e gli sviluppatori ricevano un feedback tempestivo.
L'aggiunta di più CPU offre molti miglioramenti di velocità, ma ogni sistema ha i suoi limiti. Il progetto CKI compila kernel all'interno di contenitori in una distribuzione OpenShift; sebbene OpenShift consenta tonnellate di scalabilità, la distribuzione ha ancora un numero limitato di CPU disponibili. Il team CKI alloca 20 CPU virtuali per la compilazione di ogni kernel. Con quattro architetture coinvolte, questo sale a 80 CPU!
Un altro aumento di velocità deriva da uno strumento chiamato ccache. Lo sviluppo del kernel procede rapidamente, ma gran parte del kernel rimane invariato anche tra più rilasci. Lo strumento ccache memorizza nella cache gli oggetti compilati (piccoli pezzi del kernel generale) durante la compilazione su un disco. Quando un'altra compilazione del kernel arriva più tardi, ccache cerca i pezzi invariati del kernel che ha visto prima. Ccache estrae l'oggetto memorizzato nella cache dal disco e lo riutilizza. Ciò consente compilazioni più rapide e un utilizzo complessivo della CPU inferiore. I kernel che hanno impiegato 20 minuti per essere compilati ora corrono verso il traguardo in meno di pochi minuti.
Tempo di test
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Il kernel passa all'ultimo passaggio:il test su hardware reale. Ogni kernel si avvia sulla sua architettura nativa usando Beaker e una miriade di test iniziano a cercarlo per trovare problemi. Alcuni test cercano problemi semplici, come problemi con i contenitori o messaggi di errore all'avvio. Altri test approfondiscono vari sottosistemi del kernel per trovare regressioni nelle chiamate di sistema, nell'allocazione della memoria e nel threading.
Grandi framework di test, come Linux Test Project (LTP), contengono tonnellate di test che cercano regressioni problematiche nel kernel. Alcune di queste regressioni potrebbero ripristinare le correzioni di sicurezza critiche e ci sono test per garantire che tali miglioramenti rimangano nel kernel.
Al termine dei test rimane un passaggio critico:il reporting. Gli sviluppatori e i manutentori del kernel hanno bisogno di un rapporto conciso che dica loro esattamente cosa ha funzionato, cosa non ha funzionato e come ottenere maggiori informazioni. Ciascun report CKI contiene dettagli sul codice sorgente utilizzato, i parametri di compilazione e l'output di test. Tali informazioni aiutano gli sviluppatori a sapere da dove iniziare a cercare di risolvere un problema. Inoltre, aiuta i manutentori a sapere quando un set di patch deve essere conservato per un'altra occhiata prima che un bug si faccia strada nel loro repository del kernel.
Riepilogo
Il team del progetto CKI si sforza di impedire che i bug entrino nel kernel Linux fornendo un feedback tempestivo e automatizzato agli sviluppatori e ai manutentori del kernel. Questo lavoro semplifica il loro lavoro trovando i frutti a basso impatto che portano a bug del kernel, problemi di sicurezza e problemi di prestazioni.
Per saperne di più, puoi partecipare al CKI Hackfest dal 12 al 13 settembre dopo la conferenza degli idraulici Linux dal 9 all'11 settembre a Lisbona, in Portogallo.