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``).
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.