submit-checklist.rst

  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.