Documentation/translations/it_IT/process/submit-checklist.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/it_IT/process/submit-checklist.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/it_IT/process/submit-checklist.rst
Extension
.rst
Size
6154 bytes
Lines
143
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_submitchecklist:

============================================================================
Lista delle verifiche da fare prima di inviare una patch per il kernel Linux
============================================================================

Qui troverete una lista di cose che uno sviluppatore dovrebbe fare per
vedere le proprie patch accettate più rapidamente.

Tutti questi punti integrano la documentazione fornita riguardo alla
sottomissione delle patch, in particolare
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.

Revisiona il tuo codice
=======================

1) Se state usando delle funzionalità del kernel allora includete (#include)
   i file che le dichiarano/definiscono.  Non dipendente dal fatto che un file
   d'intestazione include anche quelli usati da voi.

2) Controllate lo stile del codice della vostra patch secondo le direttive
   scritte in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`.

3) Tutte le barriere di sincronizzazione {per esempio, ``barrier()``,
   ``rmb()``, ``wmb()``} devono essere accompagnate da un commento nei
   sorgenti che ne spieghi la logica: cosa fanno e perché.

Revisionate i cambiamenti a Kconfig
===================================

1) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu
   di configurazione e sono preimpostate come disabilitate a meno che non
   soddisfino i criteri descritti in ``Documentation/kbuild/kconfig-language.rst``
   alla punto "Voci di menu: valori predefiniti".

2) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto.

3) La patch è stata accuratamente revisionata rispetto alle più importanti
   configurazioni ``Kconfig``.  Questo è molto difficile da fare
   correttamente - un buono lavoro di testa sarà utile.

Fornite documentazione
======================

1) Includete :ref:`kernel-doc <kernel_doc>` per documentare API globali del
   kernel.

2) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``.

3) Tutti i nuovi parametri d'avvio del kernel sono documentati in
    ``Documentation/admin-guide/kernel-parameters.rst``.

4) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``.

5) Tutte le nuove interfacce verso lo spazio utente sono documentate in
    ``Documentation/ABI/``.  Leggete Documentation/admin-guide/abi.rst
    (o ``Documentation/ABI/README``) per maggiori informazioni.
    Le patch che modificano le interfacce utente dovrebbero essere inviate
    in copia anche a linux-api@vger.kernel.org.

6) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate
    ``Documentation/userspace-api/ioctl/ioctl-number.rst``.

Verificate il vostro codice con gli strumenti
=============================================

Annotation

Implementation Notes