Come viene testato il kernel Linux?

In che modo gli sviluppatori del kernel Linux testano il loro codice localmente e dopo averlo impegnato? Usano una sorta di test unitario, costruiscono l'automazione? piani di test?

Il kernel di Linux ha una forte enfasi sui test della comunità.

In genere, qualsiasi sviluppatore testerà il proprio codice prima di inviarlo e molto spesso utilizzerà una versione di sviluppo del kernel di Linus o uno degli altri alberi instabili / di sviluppo per un progetto rilevante per il proprio lavoro. Ciò significa che spesso stanno testando sia i loro cambiamenti che quelli degli altri.

I piani di test formali tendono a non essere molto, ma è possibile richiedere ulteriori test prima che le caratteristiche vengano unite in alberi a monte.

Come ha sottolineato Dean, ci sono anche alcuni test automatizzati, il progetto di test di Linux e l' autotest del kernel ( buona panoramica ).

Gli sviluppatori spesso scriveranno anche test automatici mirati a testare le loro modifiche, ma non sono sicuro che esista un meccanismo (spesso usato) per raccogliere centralmente questi test ad hoc.

Dipende molto da quale area del kernel viene cambiata ovviamente: i test che faresti per un nuovo driver di rete sono abbastanza diversi dai test che faresti quando sostituisci l'algoritmo di pianificazione di base.

Naturalmente, il kernel stesso e le sue parti sono testati prima del rilascio, ma questi test coprono solo le funzionalità di base. Esistono alcuni sistemi di test che eseguono test del kernel Linux:

Il Linux Test Project (LTP) offre suite di test alla comunità open source che convalida l'affidabilità e la stabilità di Linux. La suite di test LTP contiene una raccolta di strumenti per testare il kernel Linux e le funzionalità correlate. https://github.com/linux-test-project/ltp

Autotest : un framework per test completamente automatizzati. È progettato principalmente per testare il kernel Linux, anche se è utile per molti altri scopi come qualificare il nuovo hardware, test di virtualizzazione e altri test del programma dello spazio utente generale su piattaforme Linux. È un progetto open source nell'ambito della GPL ed è utilizzato e sviluppato da numerose organizzazioni, tra cui Google, IBM, Red Hat e molte altre.http://autotest.github.io/

Inoltre ci sono sistemi di certificazione sviluppati da alcune delle principali società di distribuzione GNU / Linux. Questi sistemi di solito controllano la completa distribuzione di GNU / Linux per la compatibilità con l'hardware. Esistono sistemi di certificazione sviluppati da Novell, Red Hat, Oracle, Canonical, Google .

Esistono anche sistemi per l'analisi dinamica del kernel Linux:

Kmemleak è un rilevatore di perdite di memoria incluso nel kernel Linux. Fornisce un modo per rilevare possibili perdite di memoria del kernel in un modo simile a un garbage collector di traccia con la differenza che gli oggetti orfani non vengono liberati ma riportati solo tramite / sys / kernel / debug / kmemleak.

Kmemcheck ogni lettura e scrittura nella memoria allocata in modo dinamico (ovvero con kmalloc ()). Se viene letto un indirizzo di memoria che non è stato precedentemente scritto, un messaggio viene stampato nel registro del kernel. Inoltre fa parte del kernel Linux

Fault Injection Framework (incluso nel kernel Linux) consente di infondere errori ed eccezioni nella logica di un'applicazione per ottenere una maggiore copertura e tolleranza d'errore del sistema.

In che modo gli sviluppatori del kernel Linux testano il loro codice localmente e dopo averlo impegnato?

Usano una sorta di test unitario, costruiscono l'automazione?

Nel classico senso delle parole, no.

Per esempio. Ingo Molnar esegue il seguente carico di lavoro: 1. crea un nuovo kernel con un set casuale di opzioni di configurazione 2. avvialo 3. vai a 1

Ogni errore di compilazione, avvio non riuscito, BUG o avviso di runtime viene gestito. 24/7. Moltiplicare per diverse caselle e si possono scoprire molti problemi.

piani di test?

No.

Potrebbe esserci un malinteso sul fatto che esiste una struttura di test centrale, non esiste. Ognuno fa quello che vuole.

Strumenti nell'albero

Un buon modo per trovare strumenti di test nel kernel è:

• make help e leggi tutti gli obiettivi
• guarda sotto strumenti / test

In v4.0, questo mi porta a:

• kselftest in strumenti / test / autotest . Corri con make kselftest. Deve essere già in esecuzione kernel compilato. Vedi anche: Documentazione / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest in strumenti / testing / ktest . Vedi anche: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• Sezione degli analizzatori statici di make help, che contiene obiettivi come:

  • checkstack: Perl: cosa fa checkstack.pl nel sorgente linux?
  • coccicheckper Coccinelle (menzionato da askb )

Kernel CI

https://kernelci.org/ è un progetto che mira a rendere i test del kernel più automatizzati e visibili.

Sembra che esegua solo test di build e boot (TODO come testare automaticamente il boot funzionato. Source dovrebbe essere su https://github.com/kernelci/ ).

Linaro sembra essere il principale manutentore del progetto, con il contributo di molte grandi aziende: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiatives/lava/ sembra un sistema CI con focus sul programma di sviluppo della scheda di sviluppo e sul kernel Linux.

ARM LISA

https://github.com/ARM-software/lisa

Non sono sicuro di cosa faccia in dettaglio, ma è concesso su licenza ARM e Apache, quindi probabilmente vale la pena dare un'occhiata.

Demo: https://www.youtube.com/watch?v=yXZzzUEngiU

Step debugger

Non proprio test unitari, ma può essere utile quando i test iniziano a fallire:

• QEMU + GDB: https://stackoverflow.com/a/42316607/895245
• KGDB: https://stackoverflow.com/a/44226360/895245

La mia configurazione QEMU + Buildroot + Python

Ho anche avviato una configurazione incentrata sulla facilità di sviluppo, ma alla fine ho aggiunto anche alcune semplici funzionalità di test: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

Non ho analizzato tutte le altre impostazioni in modo molto dettagliato e probabilmente fanno molto di più delle mie, tuttavia credo che la mia configurazione sia molto facile da iniziare rapidamente perché ha molta documentazione e automazione.

Non è molto semplice automatizzare i test del kernel. La maggior parte degli sviluppatori Linux fa i test da soli, proprio come ha detto adobriyan.

Tuttavia, ci sono alcune cose che aiutano con il debug del kernel Linux:

• kexec: una chiamata di sistema che ti consente di mettere un altro kernel in memoria e riavviare senza tornare al BIOS e, se fallisce, riavviare.
• dmesg: Sicuramente il posto dove cercare informazioni su ciò che è accaduto durante l'avvio del kernel e se funziona / non funziona.
• Strumentazione del kernel: Oltre a printk (e un'opzione chiamata 'CONFIG_PRINTK_TIME' che ti permette di vedere (con precisione dei microsecondi) quando il kernel emette cosa), la configurazione del kernel ti consente di attivare MOLTI traccianti che consentono loro di eseguire il debug di ciò che sta succedendo.

Quindi, gli sviluppatori di solito hanno altri che esaminano le loro patch. Una volta che le patch sono state riviste localmente e viste per non interferire con nient'altro, e le patch sono testate per funzionare con l'ultimo kernel di Linus senza interrompere nulla, le patch sono spinte a monte.

Modifica: ecco un bel video che descrive in dettaglio il processo che passa una patch prima che sia integrata nel kernel.

Oltre ai punti sopra / sotto, che enfatizzano maggiormente i test di funzionalità, test di certificazione hardware e test delle prestazioni del kernel Linux.

In realtà molti test avvengono attraverso, in realtà script, strumenti di analisi del codice statico, recensioni di codice ecc., Che è molto efficace nel rilevare i bug, che altrimenti rompono qualcosa nell'applicazione.

Sparse - Uno strumento open source progettato per trovare guasti nel kernel di Linux.

Coccinelle è un altro programma che fa motore di abbinamento e trasformazione che fornisce il linguaggio SmPL (Semantic Patch Language) per specificare le corrispondenze e le trasformazioni desiderate nel codice C.

checkpatch.pl e altri script - problemi di stile di codifica possono essere trovati nel file Documentation / CodingStyle nell'albero dei sorgenti del kernel. La cosa importante da ricordare durante la lettura non è che questo stile sia in qualche modo migliore di qualsiasi altro stile, solo che sia coerente. questo aiuta gli sviluppatori a trovare e risolvere facilmente problemi di stile di codifica, sono stati sviluppati gli script script / checkpatch.pl nell'albero dei sorgenti del kernel. Questo script può evidenziare facilmente i problemi e dovrebbe sempre essere eseguito da uno sviluppatore sulle loro modifiche, invece di far perdere tempo a un revisore sottolineando i problemi in seguito.

Immagino che usino la virtualizzazione per eseguire test rapidi, qualcosa come QEMU, VirtualBox o Xen e alcuni script per eseguire configurazioni e test automatici.

Il test automatizzato viene probabilmente eseguito provando molte configurazioni casuali o alcune specifiche (se funzionano con un problema specifico). Linux ha molti strumenti di basso livello (come dmesg) per monitorare e registrare i dati di debug dal kernel, quindi immagino che venga usato anche questo.

Ci sono anche:

MMTest che è una raccolta di benchmark e script per analizzare i risultati

https://github.com/gormanm/mmtests

Trinity, che è un sistema Linux chiamato fuzz tester

http://codemonkey.org.uk/projects/trinity/

Anche le pagine LTP su sourceforge sono piuttosto obsolete e il progetto è passato a GitHub https://github.com/linux-test-project/ltp

Per quanto ne so, esiste uno strumento di controllo della regressione delle prestazioni automaticamente (chiamato lkp / 0 day) in esecuzione / finanziamento da parte di Intel, testerà ogni patch valida inviata alla mailing list e controllerà i punteggi modificati da diversi microbench come hackbench , fio, unixbench, netperf, ecc., quando si verifica una regressione / miglioramento delle prestazioni, un report corrispondente verrà inviato direttamente all'autore della patch e ai manutentori correlati a Cc.

LTP e Memtest sono generalmente strumenti preferiti.

adobriyan ha menzionato il ciclo Ingo di test di configurazione di configurazione casuale. Questo è praticamente ora coperto dal bot di test di 0 giorni (aka bot di test kbuild). Un bell'articolo sull'infrastruttura è presentato qui: Kernel Build / boot testing

L'idea alla base di questa configurazione è di avvisare gli sviluppatori al più presto in modo che possano correggere gli errori abbastanza presto. (prima che le patch entrassero nell'albero di Linus in alcuni casi poiché l'infrastruttura kbuild verifica anche l'albero del sottosistema del manutentore)

Avevo fatto la compilazione del kernel di Linux e apportato alcune modifiche per Android (Marshmallow e Nougat) in cui utilizzo Linux versione 3. L'ho compilato in modo incrociato nel sistema Linux, eseguo il debug degli errori manualmente e quindi eseguo il suo file immagine di avvio in Android e controlla se stava andando in buca o no. Se funziona perfettamente, significa che è compilato perfettamente in base ai requisiti di sistema.
Per la compilazione del kernel MotoG

NOTA: - Il kernel Linux cambierà in base ai requisiti che dipendono dall'hardware del sistema

Una volta che i contributori inviano i loro file di patch e dopo aver effettuato la richiesta di unione, i gatekeeper Linux stanno controllando la patch integrandola ed esaminandola. Una volta che ha successo, uniranno la patch nel ramo pertinente e rilasceranno una nuova versione. Linux Test Project ( https://github.com/linux-test-project/ltp ) è la fonte principale che fornisce scenari di test (Test Cases) da eseguire contro il kernel dopo aver applicato le patch. Questo può richiedere circa 2 ~ 4 ore e dipende. Si prega di notare che il file system del kernel selezionato verrà testato. Es: Ext4 genera risultati diversi rispetto a EXT3 e così via.

Procedura di test del kernel.

1. Ottieni l'ultima fonte del kernel dal repository. ( Https://www.kernel.org/ o Github.com)
2. Applica file patch (utilizzando lo strumento Diff)
3. Crea un nuovo kernel.
4. Test rispetto alle procedure di test in LTP ( https://github.com/linux-test-project/ltp )