cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

submit-checklist.rst (6042B)


      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
     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
     353) Compilare per diverse architetture di processore usando strumenti per
     36   la cross-compilazione o altri.
     37
     384) 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
     415) 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
     486) 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
     537) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto.
     54
     558) 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
     599) Verificare con sparse.
     60
     6110) 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
     6911) 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
     7412) 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
     8013) La patch è stata compilata e verificata in esecuzione con, e senza,
     81    le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``.
     82
     8314) Se la patch ha effetti sull'IO dei dischi, eccetera: allora dev'essere
     84    verificata con, e senza, l'opzione ``CONFIG_LBDAF``.
     85
     8615) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità
     87    di lockdep abilitate.
     88
     8916) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``.
     90
     9117) Tutti i nuovi parametri d'avvio del kernel sono documentati in
     92    ``Documentation/admin-guide/kernel-parameters.rst``.
     93
     9418) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``.
     95
     9619) 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
    10120) 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
    10721) 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
    11122) 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
    11623) 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
    12024) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate
    121    ``Documentation/userspace-api/ioctl/ioctl-number.rst``.
    122
    12325) 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``).