Italian

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:

Documentation/process/submit-checklist.rst

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.

Revisiona il tuo codice

  1. 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.

  2. Controllate lo stile del codice della vostra patch secondo le direttive scritte in Documentation/translations/it_IT/process/coding-style.rst.

  3. 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é.

Revisionate i cambiamenti a Kconfig

  1. 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 in Documentation/kbuild/kconfig-language.rst alla punto “Voci di menu: valori predefiniti”.

  2. Tutte le nuove opzioni Kconfig hanno un messaggio di aiuto.

  3. La patch è stata accuratamente revisionata rispetto alle più importanti configurazioni Kconfig. Questo è molto difficile da fare correttamente - un buono lavoro di testa sarà utile.

Fornite documentazione

  1. Includete kernel-doc per documentare API globali del kernel.

  2. Tutti i nuovi elementi in /proc sono documentati in Documentation/.

  3. Tutti i nuovi parametri d’avvio del kernel sono documentati in

    Documentation/admin-guide/kernel-parameters.rst.

  4. Tutti i nuovi parametri dei moduli sono documentati con MODULE_PARM_DESC().

  5. Tutte le nuove interfacce verso lo spazio utente sono documentate in

    Documentation/ABI/. Leggete Documentation/ABI/README per maggiori informazioni. Le patch che modificano le interfacce utente dovrebbero essere inviate in copia anche a linux-api@vger.kernel.org.

  6. Se la patch aggiunge nuove chiamate ioctl, allora aggiornate

    Documentation/userspace-api/ioctl/ioctl-number.rst.

Verificate il vostro codice con gli strumenti

  1. 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.

  2. Verificare il codice con sparse.

  3. Usare make checkstack e correggere tutti i problemi rilevati. Da notare che checkstack non evidenzia esplicitamente i problemi, ma una funzione che usa più di 512 byte sullo stack è una buona candidata per una correzione.

Compilare il codice

  1. Compilazione pulita:

  1. con le opzioni CONFIG negli stati =y, =m e =n. Nessun avviso/errore di gcc e nessun avviso/errore dal linker.

  2. con allnoconfig, allmodconfig

  3. quando si usa O=builddir

  4. Qualsiasi modifica in Documentation/ deve compilare con successo senza avvisi o errori. Usare make htmldocs o make pdfdocs per verificare e correggere i problemi

  1. 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.

  2. Il nuovo codice è stato compilato con gcc -W (usate

    make KCFLAGS=-W). Questo genererà molti avvisi, ma è ottimo per scovare bachi come “warning: comparison between signed and unsigned”.

  3. 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 con CONFIG_NET=y).

Verificate il vostro codice

  1. 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 e CONFIG_DEBUG_OBJECTS_RCU_HEAD.

  2. La patch è stata compilata e verificata in esecuzione con, e senza, le opzioni CONFIG_SMP e CONFIG_PREEMPT.

  3. Tutti i percorsi del codice sono stati verificati con tutte le funzionalità di lockdep abilitate.

  4. 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.

  5. La patch è stata verificata sul tag più recente di linux-next per assicurarsi che funzioni assieme a tutte le altre patch in coda, assieme ai vari cambiamenti nei sottosistemi VM, VFS e altri.