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/admin-guide/abi.rst 62 (o ``Documentation/ABI/README``) per maggiori informazioni. 63 Le patch che modificano le interfacce utente dovrebbero essere inviate 64 in copia anche a linux-api@vger.kernel.org. 65 666) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate 67 ``Documentation/userspace-api/ioctl/ioctl-number.rst``. 68 69Verificate il vostro codice con gli strumenti 70============================================= 71 721) Prima dell'invio della patch, usate il verificatore di stile 73 (``script/checkpatch.pl``) per scovare le violazioni più semplici. 74 Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella 75 vostra patch. 76 772) Verificare il codice con sparse. 78 79 803) Usare ``make checkstack`` e correggere tutti i problemi rilevati. Da notare 81 che ``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione 82 che usa più di 512 byte sullo stack è una buona candidata per una correzione. 83 84Compilare il codice 85=================== 86 871) Compilazione pulita: 88 89 a) con le opzioni ``CONFIG`` negli stati ``=y``, ``=m`` e ``=n``. Nessun 90 avviso/errore di ``gcc`` e nessun avviso/errore dal linker. 91 92 b) con ``allnoconfig``, ``allmodconfig`` 93 94 c) quando si usa ``O=builddir`` 95 96 d) Qualsiasi modifica in Documentation/ deve compilare con successo senza 97 avvisi o errori. Usare ``make htmldocs`` o ``make pdfdocs`` per verificare 98 e correggere i problemi 99 1002) Compilare per diverse architetture di processore usando strumenti per la 101 cross-compilazione o altri. Una buona architettura per la verifica della 102 cross-compilazione è la ppc64 perché tende ad usare ``unsigned long`` per le 103 quantità a 64-bit. 104 1053) Il nuovo codice è stato compilato con ``gcc -W`` (usate 106 ``make KCFLAGS=-W``). Questo genererà molti avvisi, ma è ottimo 107 per scovare bachi come "warning: comparison between signed and unsigned". 108 1094) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o 110 funzionalità del kernel che è associata a uno dei seguenti simboli 111 ``Kconfig``, allora verificate che il kernel compili con diverse 112 configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la 113 possibilità) [non tutti contemporaneamente, solo diverse combinazioni 114 casuali]: 115 116 ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, 117 ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, 118 ``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``). 119 120Verificate il vostro codice 121=========================== 122 1231) La patch è stata verificata con le seguenti opzioni abilitate 124 contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, 125 ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, 126 ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, 127 ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``. 128 1292) La patch è stata compilata e verificata in esecuzione con, e senza, 130 le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``. 131 1323) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità 133 di lockdep abilitate. 134 1354) La patch è stata verificata con l'iniezione di fallimenti in slab e 136 nell'allocazione di pagine. Vedere ``Documentation/fault-injection/``. 137 Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere 138 l'iniezione di fallimenti specifici per il sottosistema. 139 1405) La patch è stata verificata sul tag più recente di linux-next per assicurarsi 141 che funzioni assieme a tutte le altre patch in coda, assieme ai vari 142 cambiamenti nei sottosistemi VM, VFS e altri. 143