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