Warning
In caso di dubbi sulla correttezza del contenuto di questa traduzione, l’unico riferimento valido è la documentazione ufficiale in inglese. Per maggiori informazioni consultate le avvertenze.
- Original:
- Translator:
Federico Vaga <federico.vaga@vaga.pv.it>
Lista delle verifiche da fare prima di inviare una patch per il kernel Linux¶
Qui troverete una lista di cose che uno sviluppatore dovrebbe fare per vedere le proprie patch accettate più rapidamente.
Tutti questi punti integrano la documentazione fornita riguardo alla sottomissione delle patch, in particolare Documentation/translations/it_IT/process/submitting-patches.rst.
Se state usando delle funzionalità del kernel allora includete (#include) i file che le dichiarano/definiscono. Non dipendente dal fatto che un file d’intestazione include anche quelli usati da voi.
Compilazione pulita:
con le opzioni
CONFIG
negli stati=y
,=m
e=n
. Nessun avviso/errore digcc
e nessun avviso/errore dal linker.con
allnoconfig
,allmodconfig
quando si usa
O=builddir
Qualsiasi modifica in Documentation/ deve compilare con successo senza avvisi o errori. Usare
make htmldocs
omake pdfdocs
per verificare e correggere i problemi
Compilare per diverse architetture di processore usando strumenti per la cross-compilazione o altri.
Una buona architettura per la verifica della cross-compilazione è la ppc64 perché tende ad usare
unsigned long
per le quantità a 64-bit.Controllate lo stile del codice della vostra patch secondo le direttive scritte in Documentation/translations/it_IT/process/coding-style.rst. Prima dell’invio della patch, usate il verificatore di stile (
script/checkpatch.pl
) per scovare le violazioni più semplici. Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella vostra patch.Le opzioni
CONFIG
, nuove o modificate, non scombussolano il menu di configurazione e sono preimpostate come disabilitate a meno che non soddisfino i criteri descritti inDocumentation/kbuild/kconfig-language.rst
alla punto “Voci di menu: valori predefiniti”.Tutte le nuove opzioni
Kconfig
hanno un messaggio di aiuto.La patch è stata accuratamente revisionata rispetto alle più importanti configurazioni
Kconfig
. Questo è molto difficile da fare correttamente - un buono lavoro di testa sarà utile.Verificare con sparse.
Usare
make checkstack
e correggere tutti i problemi rilevati.Note
checkstack
non evidenzia esplicitamente i problemi, ma una funzione che usa più di 512 byte sullo stack è una buona candidata per una correzione.Includete commenti kernel-doc per documentare API globali del kernel. Usate
make htmldocs
omake pdfdocs
per verificare i commenti kernel-doc ed eventualmente correggerli.La patch è stata verificata con le seguenti opzioni abilitate contemporaneamente:
CONFIG_PREEMPT
,CONFIG_DEBUG_PREEMPT
,CONFIG_DEBUG_SLAB
,CONFIG_DEBUG_PAGEALLOC
,CONFIG_DEBUG_MUTEXES
,CONFIG_DEBUG_SPINLOCK
,CONFIG_DEBUG_ATOMIC_SLEEP
,CONFIG_PROVE_RCU
eCONFIG_DEBUG_OBJECTS_RCU_HEAD
.La patch è stata compilata e verificata in esecuzione con, e senza, le opzioni
CONFIG_SMP
eCONFIG_PREEMPT
.Se la patch ha effetti sull’IO dei dischi, eccetera: allora dev’essere verificata con, e senza, l’opzione
CONFIG_LBDAF
.Tutti i percorsi del codice sono stati verificati con tutte le funzionalità di lockdep abilitate.
Tutti i nuovi elementi in
/proc
sono documentati inDocumentation/
.Tutti i nuovi parametri d’avvio del kernel sono documentati in
Documentation/admin-guide/kernel-parameters.rst
.Tutti i nuovi parametri dei moduli sono documentati con
MODULE_PARM_DESC()
.Tutte le nuove interfacce verso lo spazio utente sono documentate in
Documentation/ABI/
. LeggeteDocumentation/ABI/README
per maggiori informazioni. Le patch che modificano le interfacce utente dovrebbero essere inviate in copia anche a linux-api@vger.kernel.org.La patch è stata verificata con l’iniezione di fallimenti in slab e nell’allocazione di pagine. Vedere
Documentation/fault-injection/
.Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere l’iniezione di fallimenti specifici per il sottosistema.
Il nuovo codice è stato compilato con
gcc -W
(usatemake KCFLAGS=-W
). Questo genererà molti avvisi, ma è ottimo per scovare bachi come “warning: comparison between signed and unsigned”.La patch è stata verificata dopo essere stata inclusa nella serie di patch -mm; questo al fine di assicurarsi che continui a funzionare assieme a tutte le altre patch in coda e i vari cambiamenti nei sottosistemi VM, VFS e altri.
Tutte le barriere di sincronizzazione {per esempio,
barrier()
,rmb()
,wmb()
} devono essere accompagnate da un commento nei sorgenti che ne spieghi la logica: cosa fanno e perché.Se la patch aggiunge nuove chiamate ioctl, allora aggiornate
Documentation/userspace-api/ioctl/ioctl-number.rst
.Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o funzionalità del kernel che è associata a uno dei seguenti simboli
Kconfig
, allora verificate che il kernel compili con diverse configurazioni dove i simboli sono disabilitati e/o=m
(se c’è la possibilità) [non tutti contemporaneamente, solo diverse combinazioni casuali]:CONFIG_SMP
,CONFIG_SYSFS
,CONFIG_PROC_FS
,CONFIG_INPUT
,CONFIG_PCI
,CONFIG_BLOCK
,CONFIG_PM
,CONFIG_MAGIC_SYSRQ
,CONFIG_NET
,CONFIG_INET=n
(ma l’ultimo conCONFIG_NET=y
).