mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-12-29 17:25:38 +00:00
doc:it_IT: update documents in process/
Update Italian translation following these changes under Documentation/process commiteb5ed2fae1("docs: submitting-patches: Advertise b4") commit413e775efa("Documentation: fix links to mailing list services") commit47c67ec1e8("docs: submit-checklist: use subheadings") commit5969fbf302("docs: submit-checklist: structure by category") commit5f99665ee8("kbuild: raise the minimum GNU Make requirement to 4.0") commit627395716c("docs: document python version used for compilation") commit7a23b027ec("arm64: boot: Support Flat Image Tree") commit56f64b3706("rust: upgrade to Rust 1.78.0") commit82b8000c28("net: drop special comment style") commit6813216bbd("Documentation: coding-style: ask function-like macros to evaluate parameters") commit91031ca349("docs: improve comment consistency in .muttrc example configuration") commit7fe7de7be8("Docs/process/email-clients: Document HacKerMaiL") commit9c03bc90c0("Documentation: process: Revert "Document suitability of Proton Mail for kernel development"") commitf9a4f4a0e1("Docs: Move magic-number from process to staging") commit7400d25a0a("Docs/process/index: Remove riscv/patch-acceptance from 'Other materi al' section") Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241009224518.15585-1-federico.vaga@vaga.pv.it
This commit is contained in:
Federico Vaga
Jonathan Corbet
parent
fbdeb12af1
commit
443165227d
17
Documentation/translations/it_IT/dev-tools/index.rst
Normal file
17
Documentation/translations/it_IT/dev-tools/index.rst
Normal file
@ -0,0 +1,17 @@
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/dev-tools/index.rst
|
||||
|
||||
===================================
|
||||
Strumenti di sviluppo per il kernel
|
||||
===================================
|
||||
|
||||
Qui raccogliamo i vari documenti riguardanti gli strumenti di sviluppo che
|
||||
possono essere usati per lavorare col kernel . Per ora, questa è una raccolta
|
||||
senza un particolare struttura; si accettano patch!
|
||||
|
||||
.. toctree::
|
||||
:caption: Tabella dei contenuti
|
||||
:maxdepth: 2
|
||||
|
||||
clang-format
|
||||
@ -103,9 +103,11 @@ sviluppatori del kernel.
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
process/license-rules
|
||||
doc-guide/index
|
||||
kernel-hacking/index
|
||||
Regole sulle licenze <process/license-rules>
|
||||
Scrivere la documentazione <doc-guide/index>
|
||||
Strumenti di sviluppo <dev-tools/index>
|
||||
La guida all'*hacking*<kernel-hacking/index>
|
||||
|
||||
|
||||
Documentazione per gli utenti
|
||||
=============================
|
||||
|
||||
@ -424,10 +424,10 @@ o entrambi.
|
||||
Molte delle liste di discussione del Kernel girano su vger.kernel.org;
|
||||
l'elenco principale lo si trova sul sito:
|
||||
|
||||
http://vger.kernel.org/vger-lists.html
|
||||
https://subspace.kernel.org
|
||||
|
||||
Esistono liste gestite altrove; un certo numero di queste sono in
|
||||
redhat.com/mailman/listinfo.
|
||||
Tuttavia, esistono liste gestite altrove; controllare il file MAINTAINERS per
|
||||
trovare la lista relativa ad un sottosistema specifico.
|
||||
|
||||
La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
|
||||
linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
|
||||
|
||||
@ -69,7 +69,7 @@ e per revisionare interi file per individuare errori nello stile di codifica,
|
||||
refusi e possibili miglioramenti. Inoltre è utile anche per classificare gli
|
||||
``#includes``, per allineare variabili/macro, per testi derivati ed altri
|
||||
compiti del genere. Consultate il file
|
||||
:ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>`
|
||||
:ref:`Documentation/translations/it_IT/dev-tools/clang-format.rst <clangformat>`
|
||||
per maggiori dettagli
|
||||
|
||||
Se utilizzate un programma compatibile con EditorConfig, allora alcune
|
||||
|
||||
@ -34,9 +34,9 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
|
||||
====================== ================= ========================================
|
||||
GNU C 5.1 gcc --version
|
||||
Clang/LLVM (optional) 13.0.0 clang --version
|
||||
Rust (opzionale) 1.76.0 rustc --version
|
||||
Rust (opzionale) 1.78.0 rustc --version
|
||||
bindgen (opzionale) 0.65.1 bindgen --version
|
||||
GNU make 3.81 make --version
|
||||
GNU make 4.0 make --version
|
||||
bash 4.2 bash --version
|
||||
binutils 2.25 ld -v
|
||||
flex 2.5.35 flex --version
|
||||
@ -65,6 +65,8 @@ Sphinx\ [#f1]_ 2.4.4 sphinx-build --version
|
||||
cpio any cpio --version
|
||||
GNU tar 1.28 tar --version
|
||||
gtags (opzionale) 6.6.5 gtags --version
|
||||
mkimage (opzionale) 2017.01 mkimage --version
|
||||
Python (opzionale) 3.5.x python3 --version
|
||||
====================== ================= ========================================
|
||||
|
||||
.. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel
|
||||
@ -88,10 +90,25 @@ potremmo rimuovere gli espedienti che abbiamo implementato per farli
|
||||
funzionare. Per maggiori informazioni
|
||||
:ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
|
||||
|
||||
Rust (opzionale)
|
||||
----------------
|
||||
|
||||
È necessaria una versione recente del compilatore Rust.
|
||||
|
||||
Verificate le istruzioni Documentation/rust/quick-start.rst su come soddisfare i
|
||||
requisiti per compilare code Rust. In particolare, la regola ``rustavailable``
|
||||
nel ``Makefile`` è utile per verificare perché gli strumenti di compilazione non
|
||||
vengono trovati.
|
||||
|
||||
bindgen (opzionale)
|
||||
-------------------
|
||||
|
||||
``bindgen`` viene usato per generare il collegamento (binding) da Rust al lato C del kernel. Dipende da ``libclang``.
|
||||
|
||||
Make
|
||||
----
|
||||
|
||||
Per compilare il kernel vi servirà GNU make 3.81 o successivo.
|
||||
Per compilare il kernel vi servirà GNU make 4.0 o successivo.
|
||||
|
||||
Bash
|
||||
----
|
||||
@ -168,6 +185,16 @@ Il programma GNU GLOBAL versione 6.6.5, o successiva, è necessario quando si
|
||||
vuole eseguire ``make gtags`` e generare i relativi indici. Internamente si fa
|
||||
uso del parametro gtags ``-C (--directory)`` che compare in questa versione.
|
||||
|
||||
mkimage
|
||||
-------
|
||||
|
||||
Questo strumento viene usato per produrre un *Flat Image Tree* (FIT),
|
||||
tipicamente usato su sistemi ARM. Questo strumento è disponibile tramite il
|
||||
pacchetto ``u-boot-tools`` oppure può essere compilato dal codice sorgente di
|
||||
U-Boot. Consultate le istruzioni
|
||||
https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
|
||||
|
||||
|
||||
Strumenti di sistema
|
||||
********************
|
||||
|
||||
|
||||
@ -620,18 +620,6 @@ Lo stile preferito per i commenti più lunghi (multi-riga) è:
|
||||
* with beginning and ending almost-blank lines.
|
||||
*/
|
||||
|
||||
Per i file in net/ e in drivers/net/ lo stile preferito per i commenti
|
||||
più lunghi (multi-riga) è leggermente diverso.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* The preferred comment style for files in net/ and drivers/net
|
||||
* looks like this.
|
||||
*
|
||||
* It is nearly the same as the generally preferred comment style,
|
||||
* but there is no initial almost-blank line.
|
||||
*/
|
||||
|
||||
È anche importante commentare i dati, sia per i tipi base che per tipi
|
||||
derivati. A questo scopo, dichiarate un dato per riga (niente virgole
|
||||
per una dichiarazione multipla). Questo vi lascerà spazio per un piccolo
|
||||
@ -726,7 +714,7 @@ di stile, refusi e possibilmente anche delle migliorie. È anche utile per
|
||||
ordinare gli ``#include``, per allineare variabili/macro, per ridistribuire
|
||||
il testo e altre cose simili.
|
||||
Per maggiori dettagli, consultate il file
|
||||
:ref:`Documentation/translations/it_IT/process/clang-format.rst <it_clangformat>`.
|
||||
:ref:`Documentation/translations/it_IT/dev-tools/clang-format.rst <it_clangformat>`.
|
||||
|
||||
Se utilizzate un programma compatibile con EditorConfig, allora alcune
|
||||
configurazioni basilari come l'indentazione e la fine delle righe verranno
|
||||
@ -827,6 +815,29 @@ blocco do - while:
|
||||
do_this(b, c); \
|
||||
} while (0)
|
||||
|
||||
Le macro che sembrano funzioni con parametri non usati dovrebbero essere
|
||||
sostituite da funzioni inline per evitare il problema.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
static inline void fun(struct foo *foo)
|
||||
{
|
||||
}
|
||||
|
||||
Per motivi storici, molti file usano ancora l'approccio "cast a (void)" per
|
||||
valutare i parametri. Tuttavia, non è raccomandato. Le funzioni inline risolvono
|
||||
i problemi di "espressioni con effetti avversi valutate più di una volta",
|
||||
variabili non utilizzate, e in genere per qualche motivo sono documentate
|
||||
meglio.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/*
|
||||
* Avoid doing this whenever possible and instead opt for static
|
||||
* inline functions
|
||||
*/
|
||||
#define macrofun(foo) do { (void) (foo); } while (0)
|
||||
|
||||
Cose da evitare quando si usano le macro:
|
||||
|
||||
1) le macro che hanno effetti sul flusso del codice:
|
||||
|
||||
@ -228,7 +228,7 @@ Mutt è molto personalizzabile. Qui di seguito trovate la configurazione minima
|
||||
per iniziare ad usare Mutt per inviare patch usando Gmail::
|
||||
|
||||
# .muttrc
|
||||
# ================ IMAP ====================
|
||||
# ================ IMAP ====================
|
||||
set imap_user = 'yourusername@gmail.com'
|
||||
set imap_pass = 'yourpassword'
|
||||
set spoolfile = imaps://imap.gmail.com/INBOX
|
||||
@ -365,27 +365,12 @@ un editor esterno.
|
||||
Un altro problema è che Gmail usa la codifica base64 per tutti quei messaggi
|
||||
che contengono caratteri non ASCII. Questo include cose tipo i nomi europei.
|
||||
|
||||
Proton Mail
|
||||
***********
|
||||
HacKerMaiL (TUI)
|
||||
****************
|
||||
|
||||
Il servizio Proton Mail ha una funzionalità che cripta tutti i messaggi verso
|
||||
ogni destinatario per cui è possibile trovare una chiave usando il *Web Key
|
||||
Directory* (WKD). Il servizio kernel.org pubblica il WKD per ogni sviluppatore
|
||||
in possesso di un conto kernel.org. Di conseguenza, tutti i messaggi inviati
|
||||
usando Proton Mail verso indirizzi kernel.org verranno criptati.
|
||||
|
||||
Proton Mail non fornisce alcun meccanismo per disabilitare questa funzionalità
|
||||
perché verrebbe considerato un problema per la riservatezza. Questa funzionalità
|
||||
è attiva anche quando si inviano messaggi usando il Proton Mail Bridge. Dunque
|
||||
tutta la posta in uscita verrà criptata, incluse le patch inviate con ``git
|
||||
send-email``.
|
||||
|
||||
I messaggi criptati sono una fonte di problemi; altri sviluppatori potrebbero
|
||||
non aver configurato i loro programmi, o strumenti, per gestire messaggi
|
||||
criptati; inoltre, alcuni programmi di posta elettronica potrebbero criptare le
|
||||
risposte a messaggi criptati per tutti i partecipanti alla discussione, inclusa
|
||||
la lista di discussione stessa.
|
||||
|
||||
A meno che non venga introdotta una maniera per disabilitare questa
|
||||
funzionalità, non è consigliato usare Proton Mail per contribuire allo sviluppo
|
||||
del kernel.
|
||||
HacKerMaiL (hkml) è una semplice casella pubblica per la gestione dei messaggi
|
||||
di posta che non richiede alcuna sottoscrizione ad una lista di discussione.
|
||||
Viene sviluppato e mantenuto dal manutentore di DAMON e si pone come obiettivo
|
||||
quello di gestire il processo di sviluppo semplice come quello di DAMON e più in
|
||||
generale i sottosistemi del kernel. Per maggiori dettagli, fate riferimento al
|
||||
documento README (https://github.com/sjp38/hackermail/blob/master/README.md).
|
||||
|
||||
@ -344,7 +344,7 @@ principale 4.x, sarà necessario un test d'integrazione.
|
||||
A tale scopo, esiste un repositorio speciale di test nel quale virtualmente
|
||||
tutti i rami dei sottosistemi vengono inclusi su base quotidiana:
|
||||
|
||||
https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
|
||||
|
||||
In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che
|
||||
ci si aspetterà essere nel kernel principale nel successivo periodo
|
||||
@ -389,12 +389,12 @@ sviluppatori del kernel partecipano alla lista di discussione Linux Kernel.
|
||||
I dettagli su come iscriversi e disiscriversi dalla lista possono essere
|
||||
trovati al sito:
|
||||
|
||||
http://vger.kernel.org/vger-lists.html#linux-kernel
|
||||
https://subspace.kernel.org/subscribing.html
|
||||
|
||||
Ci sono diversi archivi della lista di discussione. Usate un qualsiasi motore
|
||||
di ricerca per trovarli. Per esempio:
|
||||
|
||||
https://lore.kernel.org/lkml/
|
||||
https://lore.kernel.org/linux-kernel/
|
||||
|
||||
É caldamente consigliata una ricerca in questi archivi sul tema che volete
|
||||
sollevare, prima di pubblicarlo sulla lista. Molte cose sono già state
|
||||
@ -407,13 +407,13 @@ discussione e il loro uso.
|
||||
Molte di queste liste sono gestite su kernel.org. Per informazioni consultate
|
||||
la seguente pagina:
|
||||
|
||||
http://vger.kernel.org/vger-lists.html
|
||||
https://subspace.kernel.org
|
||||
|
||||
Per favore ricordatevi della buona educazione quando utilizzate queste liste.
|
||||
Sebbene sia un pò dozzinale, il seguente URL contiene alcune semplici linee
|
||||
guida per interagire con la lista (o con qualsiasi altra lista):
|
||||
|
||||
http://www.albion.com/netiquette/
|
||||
https://subspace.kernel.org/etiquette.html
|
||||
|
||||
Se diverse persone rispondo alla vostra mail, la lista dei riceventi (copia
|
||||
conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla
|
||||
|
||||
@ -99,16 +99,6 @@ degli sviluppatori:
|
||||
|
||||
kernel-docs
|
||||
|
||||
Ed infine, qui ci sono alcune guide più tecniche che son state messe qua solo
|
||||
perché non si è trovato un posto migliore.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
magic-number
|
||||
clang-format
|
||||
../arch/riscv/patch-acceptance
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
Indices
|
||||
|
||||
@ -5,8 +5,9 @@
|
||||
|
||||
.. _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.
|
||||
@ -15,11 +16,74 @@ 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) Compilazione pulita:
|
||||
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/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
|
||||
=============================================
|
||||
|
||||
1) Prima dell'invio della patch, usate il verificatore di stile
|
||||
(``script/checkpatch.pl``) per scovare le violazioni più semplici.
|
||||
Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella
|
||||
vostra patch.
|
||||
|
||||
2) Verificare il codice con sparse.
|
||||
|
||||
|
||||
3) Usare ``make checkstack`` e correggere tutti i problemi rilevati. Da notare
|
||||
che ``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione
|
||||
che usa più di 512 byte sullo stack è una buona candidata per una correzione.
|
||||
|
||||
Compilare il codice
|
||||
===================
|
||||
|
||||
1) Compilazione pulita:
|
||||
|
||||
a) con le opzioni ``CONFIG`` negli stati ``=y``, ``=m`` e ``=n``. Nessun
|
||||
avviso/errore di ``gcc`` e nessun avviso/errore dal linker.
|
||||
@ -32,101 +96,46 @@ sottomissione delle patch, in particolare
|
||||
avvisi o errori. Usare ``make htmldocs`` o ``make pdfdocs`` per verificare
|
||||
e correggere i problemi
|
||||
|
||||
3) Compilare per diverse architetture di processore usando strumenti per
|
||||
la cross-compilazione o altri.
|
||||
2) Compilare per diverse architetture di processore usando strumenti per la
|
||||
cross-compilazione o altri. Una buona architettura per la verifica della
|
||||
cross-compilazione è la ppc64 perché tende ad usare ``unsigned long`` per le
|
||||
quantità a 64-bit.
|
||||
|
||||
4) Una buona architettura per la verifica della cross-compilazione è la ppc64
|
||||
perché tende ad usare ``unsigned long`` per le quantità a 64-bit.
|
||||
|
||||
5) Controllate lo stile del codice della vostra patch secondo le direttive
|
||||
scritte in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`.
|
||||
Prima dell'invio della patch, usate il verificatore di stile
|
||||
(``script/checkpatch.pl``) per scovare le violazioni più semplici.
|
||||
Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella
|
||||
vostra patch.
|
||||
|
||||
6) 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".
|
||||
|
||||
7) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto.
|
||||
|
||||
8) La patch è stata accuratamente revisionata rispetto alle più importanti
|
||||
configurazioni ``Kconfig``. Questo è molto difficile da fare
|
||||
correttamente - un buono lavoro di testa sarà utile.
|
||||
|
||||
9) Verificare con sparse.
|
||||
|
||||
10) Usare ``make checkstack`` e correggere tutti i problemi rilevati.
|
||||
|
||||
.. note::
|
||||
|
||||
``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione
|
||||
che usa più di 512 byte sullo stack è una buona candidata per una
|
||||
correzione.
|
||||
|
||||
11) Includete commenti :ref:`kernel-doc <kernel_doc>` per documentare API
|
||||
globali del kernel. Usate ``make htmldocs`` o ``make pdfdocs`` per
|
||||
verificare i commenti :ref:`kernel-doc <kernel_doc>` ed eventualmente
|
||||
correggerli.
|
||||
|
||||
12) La patch è stata verificata con le seguenti opzioni abilitate
|
||||
contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
|
||||
``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
|
||||
``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
|
||||
``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``.
|
||||
|
||||
13) La patch è stata compilata e verificata in esecuzione con, e senza,
|
||||
le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``.
|
||||
|
||||
14) Se la patch ha effetti sull'IO dei dischi, eccetera: allora dev'essere
|
||||
verificata con, e senza, l'opzione ``CONFIG_LBDAF``.
|
||||
|
||||
15) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità
|
||||
di lockdep abilitate.
|
||||
|
||||
16) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``.
|
||||
|
||||
17) Tutti i nuovi parametri d'avvio del kernel sono documentati in
|
||||
``Documentation/admin-guide/kernel-parameters.rst``.
|
||||
|
||||
18) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``.
|
||||
|
||||
19) Tutte le nuove interfacce verso lo spazio utente sono documentate in
|
||||
``Documentation/ABI/``. Leggete ``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.
|
||||
|
||||
20) La patch è stata verificata con l'iniezione di fallimenti in slab e
|
||||
nell'allocazione di pagine. Vedere ``Documentation/fault-injection/``.
|
||||
|
||||
Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere
|
||||
l'iniezione di fallimenti specifici per il sottosistema.
|
||||
|
||||
21) Il nuovo codice è stato compilato con ``gcc -W`` (usate
|
||||
3) Il nuovo codice è stato compilato con ``gcc -W`` (usate
|
||||
``make KCFLAGS=-W``). Questo genererà molti avvisi, ma è ottimo
|
||||
per scovare bachi come "warning: comparison between signed and unsigned".
|
||||
|
||||
22) La patch è stata verificata dopo essere stata inclusa nella serie di patch
|
||||
-mm; questo al fine di assicurarsi che continui a funzionare assieme a
|
||||
tutte le altre patch in coda e i vari cambiamenti nei sottosistemi VM, VFS
|
||||
e altri.
|
||||
4) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o
|
||||
funzionalità del kernel che è associata a uno dei seguenti simboli
|
||||
``Kconfig``, allora verificate che il kernel compili con diverse
|
||||
configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la
|
||||
possibilità) [non tutti contemporaneamente, solo diverse combinazioni
|
||||
casuali]:
|
||||
|
||||
23) 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é.
|
||||
``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
|
||||
``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
|
||||
``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``).
|
||||
|
||||
24) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate
|
||||
``Documentation/userspace-api/ioctl/ioctl-number.rst``.
|
||||
Verificate il vostro codice
|
||||
===========================
|
||||
|
||||
25) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o
|
||||
funzionalità del kernel che è associata a uno dei seguenti simboli
|
||||
``Kconfig``, allora verificate che il kernel compili con diverse
|
||||
configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la
|
||||
possibilità) [non tutti contemporaneamente, solo diverse combinazioni
|
||||
casuali]:
|
||||
1) La patch è stata verificata con le seguenti opzioni abilitate
|
||||
contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
|
||||
``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
|
||||
``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
|
||||
``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``.
|
||||
|
||||
``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
|
||||
``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
|
||||
``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``).
|
||||
2) La patch è stata compilata e verificata in esecuzione con, e senza,
|
||||
le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``.
|
||||
|
||||
3) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità
|
||||
di lockdep abilitate.
|
||||
|
||||
4) La patch è stata verificata con l'iniezione di fallimenti in slab e
|
||||
nell'allocazione di pagine. Vedere ``Documentation/fault-injection/``.
|
||||
Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere
|
||||
l'iniezione di fallimenti specifici per il sottosistema.
|
||||
|
||||
5) La patch è stata verificata sul tag più recente di linux-next per assicurarsi
|
||||
che funzioni assieme a tutte le altre patch in coda, assieme ai vari
|
||||
cambiamenti nei sottosistemi VM, VFS e altri.
|
||||
|
||||
@ -137,10 +137,10 @@ questione.
|
||||
|
||||
Quando volete fare riferimento ad una lista di discussione, preferite il
|
||||
servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
|
||||
sufficiente usare il campo ``Message-Id``, presente nell'intestazione del
|
||||
sufficiente usare il campo ``Message-ID``, presente nell'intestazione del
|
||||
messaggio, senza parentesi angolari. Per esempio::
|
||||
|
||||
Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
|
||||
Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI
|
||||
|
||||
Prima d'inviare il messaggio ricordatevi di verificare che il collegamento così
|
||||
creato funzioni e che indirizzi verso il messaggio desiderato.
|
||||
@ -275,11 +275,9 @@ patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le lis
|
||||
di discussione che non sono interessate al vostro lavoro.
|
||||
|
||||
Molte delle liste di discussione relative al kernel vengono ospitate su
|
||||
vger.kernel.org; potete trovare un loro elenco alla pagina
|
||||
http://vger.kernel.org/vger-lists.html. Tuttavia, ci sono altre liste di
|
||||
discussione ospitate altrove.
|
||||
|
||||
Non inviate più di 15 patch alla volta sulle liste di discussione vger!!!
|
||||
kernel.org; potete trovare un loro elenco alla pagina
|
||||
https://subspace.kernel.org. Tuttavia, ci sono altre liste di discussione
|
||||
ospitate altrove.
|
||||
|
||||
L'ultimo giudizio sull'integrazione delle modifiche accettate spetta a
|
||||
Linux Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>.
|
||||
@ -891,6 +889,14 @@ Assicuratevi che il commit si basi su sorgenti ufficiali del
|
||||
manutentore/mainline e non su sorgenti interni, accessibile solo a voi,
|
||||
altrimenti sarebbe inutile.
|
||||
|
||||
Strumenti
|
||||
---------
|
||||
|
||||
Molti degli aspetti più tecnici di questo processo possono essere automatizzati
|
||||
usando b4, la cui documentazione è disponibile all'indirizzo
|
||||
<https://b4.docs.kernel.org/en/latest/>. Può aiutare a tracciare la dipendenze,
|
||||
eseguire checkpatch e con la formattazione e l'invio di messaggi di posta.
|
||||
|
||||
Riferimenti
|
||||
-----------
|
||||
|
||||
@ -913,9 +919,6 @@ Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"
|
||||
|
||||
<http://www.kroah.com/log/linux/maintainer-06.html>
|
||||
|
||||
No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org!
|
||||
<https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net>
|
||||
|
||||
Kernel Documentation/translations/it_IT/process/coding-style.rst.
|
||||
|
||||
E-mail di Linus Torvalds sul formato canonico di una patch:
|
||||
|
||||
13
Documentation/translations/it_IT/staging/index.rst
Normal file
13
Documentation/translations/it_IT/staging/index.rst
Normal file
@ -0,0 +1,13 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: :ref:`Documentation/staging/index.rst <process_index>`
|
||||
|
||||
Documenti in ordine sparso
|
||||
==========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
magic-number
|
||||
Loading…
Reference in New Issue
Block a user