Commit | Line | Data |
---|---|---|
edba5eec FV |
1 | .. include:: ../disclaimer-ita.rst |
2 | ||
3 | :Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>` | |
0c5e1949 | 4 | :Translator: Federico Vaga <federico.vaga@vaga.pv.it> |
edba5eec FV |
5 | |
6 | .. _it_submitchecklist: | |
7 | ||
0c5e1949 FV |
8 | Lista delle verifiche da fare prima di inviare una patch per il kernel Linux |
9 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
edba5eec | 10 | |
0c5e1949 FV |
11 | Qui troverete una lista di cose che uno sviluppatore dovrebbe fare per |
12 | vedere le proprie patch accettate più rapidamente. | |
edba5eec | 13 | |
0c5e1949 FV |
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 | 3) Compilare per diverse architetture di processore usando strumenti per | |
32 | la cross-compilazione o altri. | |
33 | ||
34 | 4) 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 | ||
37 | 5) 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 | ||
44 | 6) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu | |
45 | di configurazione e sono preimpostate come disabilitate a meno che non | |
cd238eff | 46 | soddisfino i criteri descritti in ``Documentation/kbuild/kconfig-language.rst`` |
0c5e1949 FV |
47 | alla punto "Voci di menu: valori predefiniti". |
48 | ||
49 | 7) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto. | |
50 | ||
51 | 8) 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 | ||
55 | 9) Verificare con sparse. | |
56 | ||
57 | 10) 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 | ||
66 | 11) 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 | ||
71 | 12) 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 | ||
77 | 13) La patch è stata compilata e verificata in esecuzione con, e senza, | |
78 | le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``. | |
79 | ||
80 | 14) Se la patch ha effetti sull'IO dei dischi, eccetera: allora dev'essere | |
81 | verificata con, e senza, l'opzione ``CONFIG_LBDAF``. | |
82 | ||
83 | 15) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità | |
84 | di lockdep abilitate. | |
85 | ||
86 | 16) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``. | |
87 | ||
88 | 17) Tutti i nuovi parametri d'avvio del kernel sono documentati in | |
89 | ``Documentation/admin-guide/kernel-parameters.rst``. | |
90 | ||
91 | 18) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. | |
92 | ||
93 | 19) 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 | ||
98 | 20) Verifica che il kernel passi con successo ``make headers_check`` | |
99 | ||
100 | 21) 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 | ||
106 | 22) 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 | ||
110 | 23) 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 | ||
115 | 24) 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 | ||
119 | 25) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate | |
120 | ``Documentation/ioctl/ioctl-number.txt``. | |
121 | ||
122 | 26) 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``). |