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 8Lista delle verifiche da fare prima di inviare una patch per il kernel Linux 9~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10 11Qui troverete una lista di cose che uno sviluppatore dovrebbe fare per 12vedere le proprie patch accettate più rapidamente. 13 14Tutti questi punti integrano la documentazione fornita riguardo alla 15sottomissione delle patch, in particolare 16:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`. 17 181) Se state usando delle funzionalità del kernel allora includete (#include) 19 i file che le dichiarano/definiscono. Non dipendente dal fatto che un file 20 d'intestazione include anche quelli usati da voi. 21 222) Compilazione pulita: 23 24 a) con le opzioni ``CONFIG`` negli stati ``=y``, ``=m`` e ``=n``. Nessun 25 avviso/errore di ``gcc`` e nessun avviso/errore dal linker. 26 27 b) con ``allnoconfig``, ``allmodconfig`` 28 29 c) quando si usa ``O=builddir`` 30 313) Compilare per diverse architetture di processore usando strumenti per 32 la cross-compilazione o altri. 33 344) Una buona architettura per la verifica della cross-compilazione è la ppc64 35 perché tende ad usare ``unsigned long`` per le quantità a 64-bit. 36 375) Controllate lo stile del codice della vostra patch secondo le direttive 38 scritte in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`. 39 Prima dell'invio della patch, usate il verificatore di stile 40 (``script/checkpatch.pl``) per scovare le violazioni più semplici. 41 Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella 42 vostra patch. 43 446) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu 45 di configurazione e sono preimpostate come disabilitate a meno che non 46 soddisfino i criteri descritti in ``Documentation/kbuild/kconfig-language.rst`` 47 alla punto "Voci di menu: valori predefiniti". 48 497) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto. 50 518) La patch è stata accuratamente revisionata rispetto alle più importanti 52 configurazioni ``Kconfig``. Questo è molto difficile da fare 53 correttamente - un buono lavoro di testa sarà utile. 54 559) Verificare con sparse. 56 5710) Usare ``make checkstack`` e ``make namespacecheck`` e correggere tutti i 58 problemi rilevati. 59 60 .. note:: 61 62 ``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione 63 che usa più di 512 byte sullo stack è una buona candidata per una 64 correzione. 65 6611) Includete commenti :ref:`kernel-doc <kernel_doc>` per documentare API 67 globali del kernel. Usate ``make htmldocs`` o ``make pdfdocs`` per 68 verificare i commenti :ref:`kernel-doc <kernel_doc>` ed eventualmente 69 correggerli. 70 7112) La patch è stata verificata con le seguenti opzioni abilitate 72 contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, 73 ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, 74 ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, 75 ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``. 76 7713) La patch è stata compilata e verificata in esecuzione con, e senza, 78 le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``. 79 8014) Se la patch ha effetti sull'IO dei dischi, eccetera: allora dev'essere 81 verificata con, e senza, l'opzione ``CONFIG_LBDAF``. 82 8315) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità 84 di lockdep abilitate. 85 8616) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``. 87 8817) Tutti i nuovi parametri d'avvio del kernel sono documentati in 89 ``Documentation/admin-guide/kernel-parameters.rst``. 90 9118) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. 92 9319) Tutte le nuove interfacce verso lo spazio utente sono documentate in 94 ``Documentation/ABI/``. Leggete ``Documentation/ABI/README`` per maggiori 95 informazioni. Le patch che modificano le interfacce utente dovrebbero 96 essere inviate in copia anche a linux-api@vger.kernel.org. 97 9820) Verifica che il kernel passi con successo ``make headers_check`` 99 10021) La patch è stata verificata con l'iniezione di fallimenti in slab e 101 nell'allocazione di pagine. Vedere ``Documentation/fault-injection/``. 102 103 Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere 104 l'iniezione di fallimenti specifici per il sottosistema. 105 10622) Il nuovo codice è stato compilato con ``gcc -W`` (usate 107 ``make EXTRA_CFLAGS=-W``). Questo genererà molti avvisi, ma è ottimo 108 per scovare bachi come "warning: comparison between signed and unsigned". 109 11023) La patch è stata verificata dopo essere stata inclusa nella serie di patch 111 -mm; questo al fine di assicurarsi che continui a funzionare assieme a 112 tutte le altre patch in coda e i vari cambiamenti nei sottosistemi VM, VFS 113 e altri. 114 11524) Tutte le barriere di sincronizzazione {per esempio, ``barrier()``, 116 ``rmb()``, ``wmb()``} devono essere accompagnate da un commento nei 117 sorgenti che ne spieghi la logica: cosa fanno e perché. 118 11925) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate 120 ``Documentation/userspace-api/ioctl/ioctl-number.rst``. 121 12226) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o 123 funzionalità del kernel che è associata a uno dei seguenti simboli 124 ``Kconfig``, allora verificate che il kernel compili con diverse 125 configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la 126 possibilità) [non tutti contemporaneamente, solo diverse combinazioni 127 casuali]: 128 129 ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, 130 ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, 131 ``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``). 132