1.. include:: ../disclaimer-ita.rst 2 3:Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>` 4:Translator: Federico Vaga <federico.vaga@vaga.pv.it> 5 6.. _it_submitchecklist: 7 8============================================================================ 9Lista delle verifiche da fare prima di inviare una patch per il kernel Linux 10============================================================================ 11 12Qui troverete una lista di cose che uno sviluppatore dovrebbe fare per 13vedere le proprie patch accettate più rapidamente. 14 15Tutti questi punti integrano la documentazione fornita riguardo alla 16sottomissione delle patch, in particolare 17:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`. 18 19Revisiona il tuo codice 20======================= 21 221) Se state usando delle funzionalità del kernel allora includete (#include) 23 i file che le dichiarano/definiscono. Non dipendente dal fatto che un file 24 d'intestazione include anche quelli usati da voi. 25 262) Controllate lo stile del codice della vostra patch secondo le direttive 27 scritte in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`. 28 293) Tutte le barriere di sincronizzazione {per esempio, ``barrier()``, 30 ``rmb()``, ``wmb()``} devono essere accompagnate da un commento nei 31 sorgenti che ne spieghi la logica: cosa fanno e perché. 32 33Revisionate i cambiamenti a Kconfig 34=================================== 35 361) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu 37 di configurazione e sono preimpostate come disabilitate a meno che non 38 soddisfino i criteri descritti in ``Documentation/kbuild/kconfig-language.rst`` 39 alla punto "Voci di menu: valori predefiniti". 40 412) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto. 42 433) La patch è stata accuratamente revisionata rispetto alle più importanti 44 configurazioni ``Kconfig``. Questo è molto difficile da fare 45 correttamente - un buono lavoro di testa sarà utile. 46 47Fornite documentazione 48====================== 49 501) Includete :ref:`kernel-doc <kernel_doc>` per documentare API globali del 51 kernel. 52 532) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``. 54 553) Tutti i nuovi parametri d'avvio del kernel sono documentati in 56 ``Documentation/admin-guide/kernel-parameters.rst``. 57 584) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. 59 605) Tutte le nuove interfacce verso lo spazio utente sono documentate in 61 ``Documentation/ABI/``. Leggete ``Documentation/ABI/README`` per maggiori 62 informazioni. Le patch che modificano le interfacce utente dovrebbero 63 essere inviate in copia anche a linux-api@vger.kernel.org. 64 656) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate 66 ``Documentation/userspace-api/ioctl/ioctl-number.rst``. 67 68Verificate il vostro codice con gli strumenti 69============================================= 70 711) Prima dell'invio della patch, usate il verificatore di stile 72 (``script/checkpatch.pl``) per scovare le violazioni più semplici. 73 Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella 74 vostra patch. 75 762) Verificare il codice con sparse. 77 78 793) Usare ``make checkstack`` e correggere tutti i problemi rilevati. Da notare 80 che ``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione 81 che usa più di 512 byte sullo stack è una buona candidata per una correzione. 82 83Compilare il codice 84=================== 85 861) Compilazione pulita: 87 88 a) con le opzioni ``CONFIG`` negli stati ``=y``, ``=m`` e ``=n``. Nessun 89 avviso/errore di ``gcc`` e nessun avviso/errore dal linker. 90 91 b) con ``allnoconfig``, ``allmodconfig`` 92 93 c) quando si usa ``O=builddir`` 94 95 d) Qualsiasi modifica in Documentation/ deve compilare con successo senza 96 avvisi o errori. Usare ``make htmldocs`` o ``make pdfdocs`` per verificare 97 e correggere i problemi 98 992) Compilare per diverse architetture di processore usando strumenti per la 100 cross-compilazione o altri. Una buona architettura per la verifica della 101 cross-compilazione è la ppc64 perché tende ad usare ``unsigned long`` per le 102 quantità a 64-bit. 103 1043) Il nuovo codice è stato compilato con ``gcc -W`` (usate 105 ``make KCFLAGS=-W``). Questo genererà molti avvisi, ma è ottimo 106 per scovare bachi come "warning: comparison between signed and unsigned". 107 1084) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o 109 funzionalità del kernel che è associata a uno dei seguenti simboli 110 ``Kconfig``, allora verificate che il kernel compili con diverse 111 configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la 112 possibilità) [non tutti contemporaneamente, solo diverse combinazioni 113 casuali]: 114 115 ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, 116 ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, 117 ``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``). 118 119Verificate il vostro codice 120=========================== 121 1221) La patch è stata verificata con le seguenti opzioni abilitate 123 contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, 124 ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, 125 ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, 126 ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``. 127 1282) La patch è stata compilata e verificata in esecuzione con, e senza, 129 le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``. 130 1313) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità 132 di lockdep abilitate. 133 1344) La patch è stata verificata con l'iniezione di fallimenti in slab e 135 nell'allocazione di pagine. Vedere ``Documentation/fault-injection/``. 136 Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere 137 l'iniezione di fallimenti specifici per il sottosistema. 138 1395) La patch è stata verificata sul tag più recente di linux-next per assicurarsi 140 che funzioni assieme a tutte le altre patch in coda, assieme ai vari 141 cambiamenti nei sottosistemi VM, VFS e altri. 142