doc:it_IT: align Italian documentation in process

This commit updates the Italian translation in `process/` following
these changes:

commit 44abc8fcbf ("Documentation: process: Arbitrarily bump kernel major version number")
commit ba2457109d ("Documentation: process: Also mention Sasha Levin as stable tree maintainer")
commit 5ce70894f6 ("Doc: correct spelling and wording mistakes")
commit 4629837547 ("linux-next: update maintainer info.")
commit 43e9076a00 ("docs: Fix conflicting contributor identity info")
commit b27f9e8079 ("docs: remove Documentation/dontdiff")
commit 9734b3e753 ("docs: 5.Posting: mentioned Suggested-by: tag")
commit 4e6b7141d1 ("docs: clarify rules wrt tagging other people")
commit 944df7a314 ("docs: update the guidance for Link: tags")
commit 0a83293322 ("doc: development-process: add notice on testing")
commit a037699da0 ("docs: Add debugging section to process")
commit 78d979db6c ("docs: add AI Coding Assistants documentation")
commit a66437c279 ("Documentation: Provide guidelines for tool-generated content")
commit a592a36e49 ("Documentation: use a source-read extension for the index link boilerplate")
commit 102606402f ("Documentation: Project continuity")
commit a03ef333fb ("Documentation: security-bugs: explain what is and is not a security bug")
commit d0b343605f ("kernel-docs: Add new section for Rust learning materials")
commit 57937eac1f ("kernel-docs: Add book to process/kernel-docs.rst")
commit d8c949c577 ("docs/licensing: Clarify wording about "GPL" and "Proprietary"")
commit ebf1bafd09 ("LICENSES: Explicitly allow SPDX-FileCopyrightText")
commit 9fa7153c31 ("rust: conclude the Rust experiment")
commit 47cb33cedf ("docs: clarify wording in programming-language.rst")
commit 45a92c0b91 ("docs: maintainers: add SPDX license to the file")
commit 2932ba8d9c ("slab: Introduce kmalloc_obj() and family")
commit e4c8b46b92 ("slab: Introduce kmalloc_flex() and family")
commit d957b4184a ("Documentation: deprecated.rst: kmalloc-family: mark argument as optional")
commit 120a64c802 ("Documentation: process: fix brackets")
commit 079a028d63 ("string: Remove strncpy() from the kernel")
commit e551bd4109 ("Documentation: remove :kyb: tags")
commit 4971ca2007 ("docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension")
commit f44a29784f ("Documentation: update maintainer-pgp-guide for latest best practices")
commit 273aa250f1 ("Documentation: Improve wording on requirements for a free Nitrokey")
commit 6c5c07bc85 ("docs: process: maintainer-pgp-guide: update kernel.org docs link")
commit 54857c5245 ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign")
commit a556bd882b ("docs: align with scripts/syscall.tbl migration")
commit e5b1c0fa4f ("Documentation: Remove :manpage: from non-existing man pages")
commit 78a00cac1e ("docs: fix 're-use' -> 'reuse' in documentation")
commit ec6fd28baf ("docs: remove unneeded maintainer_handbooks_main label")
commit 8eae6da5f5 ("docs: auto-generate maintainer entry profile links")
commit bda185c305 ("docs: maintainers_include: Only show main entry for profiles")
commit 2783096fb1 ("docs: submit-checklist: Expand on build tests against different word sizes")
commit fb12098d8e ("docs: submit-checklist: Allow creating cross-references for ABI README")
commit 5a63f0369b ("docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README")
commit e5880f95a9 ("docs: process: discourage pointless boilerplate kdoc")
commit 2c62e2e874 ("coding-style: fix verb typo")
commit 197bbebd25 ("docs: Update documentation to avoid mentioning of kernel.h")
commit eba6ffd126 ("docs: kdoc: move kernel-doc to tools/docs")
commit 7c6d969d53 ("Documentation: adopt new coding style of type-aware kmalloc-family")
commit 323fa4b960 ("Documentation: Fix syntax of kmalloc_objs example in coding style doc")
commit d49172bbd7 ("Documentation: clarify the expected collaboration with security bugs reporters")
commit 3a68841d1d ("Documentation: smooth the text flow in the security bug reporting process")
commit ceddb2c001 ("Documentation: insist on the plain-text requirement for security reports")
commit f2b1cbef15 ("Documentation: minor updates to the security contacts")
commit a72b832a48 ("Documentation: explain how to find maintainers addresses for security reports")
commit 496fa1befb ("Documentation: clarify the mandatory and desirable info for security reports")
commit f387e2e2b9 ("Documentation: fix two typos in latest update to the security report howto")
commit aed3c33467 ("Documentation: security-bugs: do not systematically Cc the security team")
commit 4bf85afb9f ("Documentation: security-bugs: clarify requirements for AI-assisted reports")
commit 561458db0d ("docs: security-bugs: add a link to the threat-model documentation")
commit 5f5e734432 ("kbuild: generate offset range data for builtin modules")
commit 41047d53bc ("docs:process:changes: fix version command for btrfs-progs")
commit 82a1978d0f ("kheaders: use 'tar' instead of 'cpio' for copying files")
commit d2b239099c ("docs: changes: update Sphinx minimal version to 3.4.3")
commit 5e25b972a2 ("docs: changes: update Python minimal version")
commit 118c40b7b5 ("kbuild: require gcc-8 and binutils-2.30")
commit 28d51df0db ("Documentation: update binutils-2.30 version reference")
commit fc6edeea53 ("docs: Remove reiserfsprogs from dependencies.")
commit bc20c56e98 ("docs: changes: better document Python needs")
commit 20c0989283 ("kbuild: Bump minimum version of LLVM for building the kernel to 15.0.0")
commit 903922cfa0 ("lib/Kconfig.debug: Set the minimum required pahole version to v1.22")
commit 8913632998 ("Documentation: Fix typos and grammatical errors")
commit c99fcb5850 ("docs: Fix an erroneous reference to sphinx.rst")
commit d8a224f519 ("docs: changes/ver_linux: fix entries and add several tools")
commit ece7e57afd ("docs: changes.rst and ver_linux: sort the lists")
commit f32fb9c58a ("rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)")
commit c3a00a3f31 ("rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)")
commit ce3267a39a ("kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1")
commit 2c1ccd9a1d ("docs: changes.rst: restore pahole 1.26 minimum (regressed by sort)")
commit 3f997cbf67 ("docs: process: submitting-patches: split canonical patch format section")
commit 6356f18f09 ("Align git commit ID abbreviation guidelines and checks")
commit cd9123eeb2 ("docs: submitting-patches: clarify Acked-by and introduce "# Suffix"")
commit 25fb101385 ("docs: submitting-patches: clarify difference between Acked-by and Reviewed-by")
commit 08c035da54 ("docs: submitting-patches: clarify that signers may use their discretion on tags")
commit 95767a592d ("docs: submitting-patches: document the format for affiliation")
commit dc896f853e ("docs: submitting-patches: adjust Fixes definition slightly")
commit 22014a2300 ("Documentation/process: submitting-patches: fix typo in "were do"")
commit e36a7b1e17 ("docs: submitting-patches: Clarify that removal of Acks needs explanation too")
commit 8a12e3fbf2 ("docs: submitting-patches: suggest adding previous version links")
commit 6252e5c1c2 ("docs: add an Assisted-by mention to submitting-patches.rst")
commit 48c3876a6a ("docs: submitting-patches: Clarify that "reviewer" is a person")
commit 83f71fbc66 ("docs: submitting-patches: Fix section structure around DCO")

Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260816193906.68808-1-federico.vaga@vaga.pv.it>

Documentation/translations/it_IT/process/1.Intro.rst

@@ -279,13 +279,13 @@ una versione 3 della licenza GPL nel prossimo futuro.
 
 È imperativo che tutto il codice che contribuisce al kernel sia legittimamente
 software libero.  Per questa ragione, un codice proveniente da un contributore
-anonimo (o sotto pseudonimo) non verrà accettato.  È richiesto a tutti i
-contributori di firmare il proprio codice, attestando così che quest'ultimo
-può essere distribuito insieme al kernel sotto la licenza GPL.  Il codice che
-non è stato licenziato come software libero dal proprio creatore, o che
-potrebbe creare problemi di copyright per il kernel (come il codice derivante
-da processi di ingegneria inversa senza le opportune tutele), non può essere
-diffuso.
+la cui identità non è nota, o da un contributore anonimo, non verrà accettato.
+È richiesto a tutti i contributori di firmare il proprio codice, attestando
+così che quest'ultimo può essere distribuito insieme al kernel sotto la licenza
+GPL.  Il codice che non è stato licenziato come software libero dal proprio
+creatore, o che potrebbe creare problemi di copyright per il kernel (come il
+codice derivante da processi di ingegneria inversa senza le opportune tutele),
+non può essere diffuso.
 
 Domande relative a questioni legate al copyright sono frequenti nelle liste
 di discussione dedicate allo sviluppo di Linux.  Tali quesiti, normalmente,

Documentation/translations/it_IT/process/2.Process.rst

@@ -18,25 +18,22 @@ processo si svolge per poter esserne parte attiva.
 Il quadro d'insieme
 -------------------
 
-Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
-ogni due o tre mesi viene effettuata un rilascio importante del kernel.
-I rilasci più recenti sono stati:
+Il kernel Linux utilizza un modello di sviluppo a rilascio continuo,
+vagamente basato sul tempo.  Un nuovo rilascio principale del kernel (che
+chiameremo, come esempio, 9.x) [1]_ avviene ogni due o tre mesi, e porta
+con sé nuove funzionalità, modifiche interne alle API e molto altro. Un
+tipico rilascio può contenere circa 13.000 gruppi di modifiche che toccano
+diverse centinaia di migliaia di righe di codice. I rilasci più recenti,
+assieme alle rispettive date, si possono trovare su `Wikipedia
+<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.
 
-	======  =================
-	5.0     3 marzo, 2019
-	5.1     5 maggio, 2019
-	5.2     7 luglio, 2019
-	5.3     15 settembre, 2019
-	5.4     24 novembre, 2019
-	5.5     6 gennaio, 2020
-	======  =================
-
-Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
-funzionalità, modifiche interne dell'API, e molto altro.  Un tipico
-rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori
-modifiche a parecchie migliaia di linee di codice.  La 5.x. è pertanto la
-linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
-di sviluppo continuo che integra costantemente nuove importanti modifiche.
+.. [1] A rigor di termini, il kernel Linux non utilizza uno schema di
+       numerazione semantica delle versioni (semantic versioning), bensì
+       la coppia 9.x identifica la versione del rilascio principale come
+       numero intero. Per ogni rilascio, x viene incrementato, mentre
+       9 viene incrementato solo quando x è ritenuto sufficientemente
+       grande (per esempio, Linux 5.0 è stato rilasciato dopo Linux
+       4.20).
 
 Viene seguita una disciplina abbastanza lineare per l'inclusione delle
 patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
@@ -55,8 +52,8 @@ verrà descritto dettagliatamente più avanti).
 La finestra di inclusione resta attiva approssimativamente per due settimane.
 Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
 chiusa e rilascerà il primo degli "rc" del kernel.
-Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio
-che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
+Per il kernel che è destinato ad essere 9.x, per esempio, il rilascio
+che emerge al termine della finestra d'inclusione si chiamerà 9.x-rc1.
 Questo rilascio indica che il momento di aggiungere nuovi componenti è
 passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
 
@@ -109,17 +106,19 @@ tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili
 in un progetto di questa portata.  Arriva un punto dove ritardare il rilascio
 finale peggiora la situazione; la quantità di modifiche in attesa della
 prossima finestra di inclusione crescerà enormemente, creando ancor più
-regressioni al giro successivo.  Quindi molti kernel 5.x escono con una
+regressioni al giro successivo.  Quindi molti kernel escono con una
 manciata di regressioni delle quali, si spera, nessuna è grave.
 
 Una volta che un rilascio stabile è fatto, il suo costante mantenimento è
-affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
-Questa squadra rilascia occasionalmente degli aggiornamenti relativi al
-rilascio stabile usando la numerazione 5.x.y.  Per essere presa in
-considerazione per un rilascio d'aggiornamento, una modifica deve:
-(1) correggere un baco importante (2) essere già inserita nel ramo principale
-per il prossimo sviluppo del kernel.  Solitamente, passato il loro rilascio
-iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
+affidato alla "squadra stabilità", attualmente composta da Greg Kroah-Hartman
+e Sasha Levin. Questa squadra rilascia occasionalmente degli aggiornamenti
+relativi al rilascio stabile usando la numerazione 9.x.y.
+
+Per essere presa in considerazione per un rilascio d'aggiornamento, una
+modifica deve: (1) correggere un baco importante (2) essere già inserita nel
+ramo principale per il prossimo sviluppo del kernel.  Solitamente, passato il
+loro rilascio iniziale, i kernel ricevono aggiornamenti per più di un ciclo di
+sviluppo.
 Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
 
 	==============  ===============================
@@ -314,7 +313,7 @@ the moment) all'indirizzo:
 frustrante; ci sono buone probabilità che non compili nemmeno.
 
 I sorgenti principali per il prossimo ciclo d'integrazione delle patch
-è linux-next, gestito da Stephen Rothwell.  I sorgenti linux-next sono, per
+è linux-next, gestito da Mark Brown.  I sorgenti linux-next sono, per
 definizione, un'istantanea di come dovrà apparire il ramo principale dopo che
 la prossima finestra di inclusione si chiuderà.  I linux-next sono annunciati
 sulla lista di discussione linux-kernel e linux-next nel momento in cui

Documentation/translations/it_IT/process/5.Posting.rst

@@ -48,7 +48,14 @@ l'invio delle patch alla comunità di sviluppo.  Queste cose includono:
  - Verificare il codice fino al massimo che vi è consentito. Usate gli
    strumenti di debug del kernel, assicuratevi che il kernel compili con
    tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori
-   per compilare il codice per differenti architetture, eccetera.
+   per compilare il codice per differenti architetture, eccetera. Aggiungete
+   dei test, preferibilmente usando un framework di test già esistente come
+   KUnit, e includeteli come un elemento separato della vostra serie (per
+   maggiori informazioni sulle serie di patch, vedere la sezione successiva).
+   Da notare che questo può essere obbligatorio quando si toccano alcuni
+   sottosistemi. Per esempio, le funzioni di libreria (che risiedono in
+   lib/) sono usate estensivamente quasi ovunque, e ci si aspetta che siano
+   testate adeguatamente.
 
  - Assicuratevi che il vostro codice sia conforme alla linee guida del
    kernel sullo stile del codice.
@@ -224,10 +231,9 @@ implementate dalla patch::
 
        Link: https://example.com/somewhere.html  optional-other-stuff
 
-Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
-alla più recente discussione pubblica. A volte questo è fatto automaticamente da
-alcuni strumenti come b4 or un *hook* git come quello descritto qui
-'Documentation/translations/it_IT/maintainer/configure-git.rst'
+Come indicato dal "Chief Penguin" (soprannome di Linus Torvalds), un'etichetta
+Link: dovrebbe essere aggiunta ad un commit solo se conduce a informazioni
+utili che non si trovano già nel commit stesso.
 
 
 Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
@@ -284,13 +290,23 @@ Le etichette in uso più comuni sono:
    Se esiste un rapporto disponibile sul web, allora
    L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto.
 
+ - Suggested-by: indica che l'idea della patch è stata suggerita dalla persona
+   menzionata, ed assicura che le venga dato credito per l'idea.  Questo, si
+   spera, la inviterà ad aiutarci ancora in futuro.
+
  - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
    l'opportunità di commentarla.
 
-State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:" può
-essere aggiunta senza il permesso esplicito della persona menzionata. Il più
-delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente
-se il baco è stato riportato in una comunicazione privata.
+State attenti ad aggiungere le suddette etichette alla vostra patch: tutte,
+tranne Cc:, Reported-by: e Suggested-by:, richiedono il permesso esplicito
+della persona menzionata.  Per queste tre è sufficiente un permesso implicito,
+se la persona ha contribuito al kernel Linux usando quel nome e quell'indirizzo
+email secondo gli archivi di lore o la cronologia dei commit -- e, nel caso di
+Reported-by: e Suggested-by:, se la segnalazione o il suggerimento sono
+avvenuti pubblicamente.  Da notare che bugzilla.kernel.org è, in questo senso,
+un luogo pubblico, ma gli indirizzi email usati lì sono privati; quindi non
+esponeteli nelle etichette, a meno che la persona non li abbia già usati in
+contributi precedenti.
 
 Inviare la modifica
 -------------------

Documentation/translations/it_IT/process/7.AdvancedTopics.rst

@@ -60,7 +60,7 @@ Quando sarete in grado di creare rami git che siano guardabili da altri,
 vi servirà, ovviamente, un server dal quale sia possibile attingere le vostre
 modifiche.  Se avete un server accessibile da Internet, configurarlo per
 eseguire git-daemon è relativamente semplice .  Altrimenti, iniziano a
-svilupparsi piattaforme che offrono spazi pubblici, e gratuiti (Github,
+svilupparsi piattaforme che offrono spazi pubblici, e gratuiti (GitHub,
 per esempio).  Gli sviluppatori permanenti possono ottenere un account
 su kernel.org, ma non è proprio facile da ottenere; per maggiori informazioni
 consultate la pagina web https://kernel.org/faq/.

Documentation/translations/it_IT/process/adding-syscalls.rst

@@ -278,6 +278,56 @@ Per riassumere, vi serve un *commit* che includa:
  - *stub* di ripiego in ``kernel/sys_ni.c``
 
 
+.. _it_syscall_generic_6_11:
+
+Dalla versione 6.11
+~~~~~~~~~~~~~~~~~~~~
+
+A partire dalla versione 6.11 del kernel, l'implementazione generica delle
+chiamate di sistema per le seguenti architetture non richiede più modifiche
+a ``include/uapi/asm-generic/unistd.h``:
+
+ - arc
+ - arm64
+ - csky
+ - hexagon
+ - loongarch
+ - nios2
+ - openrisc
+ - riscv
+
+Al suo posto, dovete aggiornare ``scripts/syscall.tbl`` e, se necessario,
+modificare ``arch/*/kernel/Makefile.syscalls``.
+
+Dato che ``scripts/syscall.tbl`` funge da tabella comune delle chiamate di
+sistema condivisa fra più architetture, in questa tabella è richiesto un
+nuovo elemento::
+
+    468   common   xyzzy     sys_xyzzy
+
+Da notare che l'aggiunta di un elemento a ``scripts/syscall.tbl`` con l'ABI
+"common" influisce anche su tutte le architetture che condividono questa
+tabella. Per modifiche più limitate o specifiche di un'architettura,
+considerate l'uso di un'ABI specifica per l'architettura, o la definizione
+di una nuova.
+
+Se viene introdotta una nuova ABI, per esempio ``xyz``, andranno fatti i
+corrispondenti aggiornamenti anche in ``arch/*/kernel/Makefile.syscalls``::
+
+    syscall_abis_{32,64} += xyz (...)
+
+Per riassumere, vi serve un *commit* che includa:
+
+ - un'opzione ``CONFIG`` per la nuova funzione, normalmente in
+   ``init/Kconfig``
+ - ``SYSCALL_DEFINEn(xyzzy, ...)`` per il punto d'accesso
+ - il corrispondente prototipo in ``include/linux/syscalls.h``
+ - un nuovo elemento in ``scripts/syscall.tbl``
+ - (se necessario) aggiornamenti al Makefile in
+   ``arch/*/kernel/Makefile.syscalls``
+ - *stub* di ripiego in ``kernel/sys_ni.c``
+
+
 Implementazione delle chiamate di sistema x86
 ---------------------------------------------
 
@@ -396,6 +446,47 @@ Riassumendo, vi serve:
  - una voce ``__SC_COMP``, e non ``__SYSCALL``, in
    ``include/uapi/asm-generic/unistd.h``
 
+
+Dalla versione 6.11
+~~~~~~~~~~~~~~~~~~~~
+
+Questo si applica a tutte le architetture elencate in
+:ref:`Dalla versione 6.11<it_syscall_generic_6_11>` sotto "Implementazione
+di chiamate di sistema generiche", eccetto arm64. Vedere
+:ref:`Chiamate di sistema compatibili (arm64)<it_compat_arm64>` per maggiori
+informazioni.
+
+Dovete estendere la voce in ``scripts/syscall.tbl`` con una colonna
+aggiuntiva per indicare che un programma in spazio utente a 32-bit in
+esecuzione su un kernel a 64-bit deve invocare il punto d'accesso
+*compatibile*::
+
+    468   common     xyzzy     sys_xyzzy    compat_sys_xyzzy
+
+Riassumendo, vi serve:
+
+ - un ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` per il punto d'accesso
+   *compatibile*
+ - il corrispondente prototipo in ``include/linux/compat.h``
+ - la modifica della voce in ``scripts/syscall.tbl`` per includere una
+   colonna "compat" aggiuntiva
+ - (se necessario) una struttura di mappatura a 32-bit in
+   ``include/linux/compat.h``
+
+
+.. _it_compat_arm64:
+
+Chiamate di sistema compatibili (arm64)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Su arm64 esiste una tabella delle chiamate di sistema dedicata per le
+chiamate di sistema compatibili rivolte allo spazio utente a 32-bit
+(AArch32): ``arch/arm64/tools/syscall_32.tbl``. Dovete aggiungere una riga
+aggiuntiva a questa tabella specificando il punto d'accesso *compatibile*::
+
+    468   common     xyzzy     sys_xyzzy    compat_sys_xyzzy
+
+
 Compatibilità delle chiamate di sistema (x86)
 ---------------------------------------------
 
@@ -641,3 +732,6 @@ Riferimenti e fonti
  - Raccomandazioni da Linus Torvalds che le chiamate di sistema x32 dovrebbero
    favorire la compatibilità con le versioni a 64-bit piuttosto che quelle a 32-bit:
    https://lore.kernel.org/r/CA+55aFxfmwfB7jbbrXxa=K7VBYPfAvmu3XOkGrLbB1UFjX1+Ew@mail.gmail.com
+ - Serie di patch che revisiona l'infrastruttura della tabella delle chiamate
+   di sistema per usare scripts/syscall.tbl su più architetture:
+   https://lore.kernel.org/lkml/20240704143611.2979589-1-arnd@kernel.org

Documentation/translations/it_IT/process/coding-style.rst

@@ -604,8 +604,11 @@ il PERCHÉ.
 
 Per favore, quando commentate una funzione dell'API del kernel usate il
 formato kernel-doc.  Per maggiori dettagli, leggete i file in
-:ref::ref:`Documentation/translations/it_IT/doc-guide/ <it_doc_guide>` e in
-``script/kernel-doc``.
+:ref:`Documentation/translations/it_IT/doc-guide/ <it_doc_guide>` e in
+``tools/docs/kernel-doc``. Da notare che il pericolo di commentare troppo
+si applica anche ai commenti kernel-doc. Non aggiungete kernel-doc
+superfluo che si limita a ripetere quanto già ovvio dalla firma della
+funzione.
 
 Lo stile preferito per i commenti più lunghi (multi-riga) è:
 
@@ -935,7 +938,7 @@ racchiusa in #ifdef, potete usare printk(KERN_DEBUG ...).
 ---------------------
 
 Il kernel fornisce i seguenti assegnatori ad uso generico:
-kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), e vzalloc().
+kmalloc(), kzalloc(), kmalloc_objs(), kzalloc_objs(), vmalloc(), e vzalloc().
 Per maggiori informazioni, consultate la documentazione dell'API:
 :ref:`Documentation/translations/it_IT/core-api/memory-allocation.rst <it_memory_allocation>`
 
@@ -957,13 +960,13 @@ Il modo preferito per assegnare un vettore è il seguente:
 
 .. code-block:: c
 
-	p = kmalloc_array(n, sizeof(...), ...);
+	p = kmalloc_objs(*p, n, ...);
 
 Il modo preferito per assegnare un vettore a zero è il seguente:
 
 .. code-block:: c
 
-	p = kcalloc(n, sizeof(...), ...);
+	p = kzalloc_objs(*p, n, ...);
 
 Entrambe verificano la condizione di overflow per la dimensione
 d'assegnamento n * sizeof(...), se accade ritorneranno NULL.
@@ -1068,15 +1071,17 @@ può migliorare la leggibilità.
 18) Non reinventate le macro del kernel
 ---------------------------------------
 
-Il file di intestazione include/linux/kernel.h contiene un certo numero
-di macro che dovreste usare piuttosto che implementarne una qualche variante.
-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
-macro:
+Ci sono molti file d'intestazione in include/linux/ che contengono un certo
+numero di macro che dovreste usare piuttosto che implementarne una qualche
+variante. Per esempio, se dovete calcolare la lunghezza di un vettore,
+sfruttate la macro:
 
 .. code-block:: c
 
 	#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
+che è definita in array_size.h.
+
 Analogamente, se dovete calcolare la dimensione di un qualche campo di una
 struttura, usate
 
@@ -1084,10 +1089,12 @@ struttura, usate
 
 	#define sizeof_field(t, f) (sizeof(((t*)0)->f))
 
-Ci sono anche le macro min() e max() che, se vi serve, effettuano un controllo
-rigido sui tipi.  Sentitevi liberi di leggere attentamente questo file
-d'intestazione per scoprire cos'altro è stato definito che non dovreste
-reinventare nel vostro codice.
+che è definita in stddef.h.
+
+Ci sono anche le macro min() e max(), definite in minmax.h, che, se vi
+serve, effettuano un controllo rigido sui tipi. Sentitevi liberi di
+leggere attentamente questi file d'intestazione per scoprire cos'altro è
+stato definito che non dovreste reinventare nel vostro codice.
 
 19) Linee di configurazione degli editor e altre schifezze
 -----------------------------------------------------------

Documentation/translations/it_IT/process/deprecated.rst

@@ -141,26 +141,37 @@ ritorno di strcpy().  La funzione strscpy() non ritorna un puntatore
 alla destinazione, ma un contatore dei byte non NUL copiati (oppure
 un errno negativo se la stringa è stata troncata).
 
-strncpy() su stringe terminate con NUL
---------------------------------------
-L'utilizzo di strncpy() non fornisce alcuna garanzia sul fatto che
-il buffer di destinazione verrà terminato con il carattere NUL. Questo
-potrebbe portare a diversi overflow di lettura o altri malfunzionamenti
-causati, appunto, dalla mancanza del terminatore. Questa estende la
-terminazione nel buffer di destinazione quando la stringa d'origine è più
-corta; questo potrebbe portare ad una penalizzazione delle prestazioni per
-chi usa solo stringe terminate. La versione sicura da usare è
-strscpy(), tuttavia va prestata attenzione a tutti quei casi dove
-viene usato il valore di ritorno di strncpy().  La funzione strscpy()
-non ritorna un puntatore alla destinazione, ma un contatore dei byte
-non NUL copiati (oppure un errno negativo se la stringa è stata
-troncata). Tutti i casi che necessitano di estendere la
-terminazione con NUL dovrebbero usare strscpy_pad().
+strncpy()
+---------
+La funzione strncpy() è stata rimossa dal kernel. Tutti i chiamanti che
+la usavano sono stati migrati verso alternative più sicure.
 
-Se il chiamate no usa stringhe terminate con NUL, allore strncpy()
-può continuare ad essere usata, ma i buffer di destinazione devono essere
-marchiati con l'attributo `__nonstring <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
-per evitare avvisi durante la compilazione.
+strncpy() non garantiva che il buffer di destinazione venisse terminato
+con il carattere NUL, causando overflow di lettura lineari e altri
+malfunzionamenti. Inoltre estendeva incondizionatamente la terminazione
+NUL nel buffer di destinazione, il che era una penalizzazione delle
+prestazioni superflua per i chiamanti che usavano solo stringhe
+terminate con NUL. A causa dei suoi vari comportamenti, si trattava di
+un'API ambigua per determinare quale fosse la reale intenzione
+dell'autore per la copia.
+
+I sostituti di strncpy() sono:
+
+- strscpy(), quando la destinazione deve essere terminata con NUL.
+- strscpy_pad(), quando la destinazione deve essere terminata con NUL
+  ed estesa con zeri (per esempio, strutture che attraversano i confini
+  dei privilegi).
+- memtostr(), per destinazioni terminate con NUL a partire da sorgenti
+  a larghezza fissa non terminate con NUL (con l'attributo
+  `__nonstring` sulla sorgente).
+- memtostr_pad(), per lo stesso caso, ma con estensione tramite zeri.
+- strtomem(), per destinazioni a larghezza fissa non terminate con NUL,
+  con l'attributo `__nonstring` sulla destinazione.
+- strtomem_pad(), per destinazioni non terminate con NUL che
+  necessitano anche di estensione tramite zeri.
+- memcpy_and_pad(), per copie limitate da sorgenti potenzialmente non
+  terminate, quando la dimensione della destinazione è un valore
+  determinato a runtime.
 
 strlcpy()
 ---------
@@ -407,3 +418,37 @@ La macro di supporto dev'essere usata::
             DECLARE_FLEX_ARRAY(struct type2, two);
         };
     };
+
+Assegnazioni kmalloc con codice esplicito per oggetti struct
+--------------------------------------------------------------
+Eseguire assegnazioni con codice esplicito per le allocazioni della
+famiglia kmalloc() impedisce al kernel (e al compilatore) di poter
+esaminare il tipo della variabile a cui viene fatta l'assegnazione, il
+che limita ogni possibile introspezione utile per l'allineamento, per
+l'overflow, o per un ulteriore irrobustimento. Le macro della famiglia
+kmalloc_obj() forniscono questa introspezione, e possono essere usate
+per i più comuni schemi di codice per l'allocazione di un singolo
+oggetto, di un vettore di oggetti, o di un oggetto con un array
+flessibile. Per esempio, queste assegnazioni con codice esplicito::
+
+	ptr = kmalloc(sizeof(*ptr), gfp);
+	ptr = kzalloc(sizeof(*ptr), gfp);
+	ptr = kmalloc_array(count, sizeof(*ptr), gfp);
+	ptr = kcalloc(count, sizeof(*ptr), gfp);
+	ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
+	ptr = kmalloc(sizeof(struct foo), gfp);
+
+diventano, rispettivamente::
+
+	ptr = kmalloc_obj(*ptr [, gfp] );
+	ptr = kzalloc_obj(*ptr [, gfp] );
+	ptr = kmalloc_objs(*ptr, count [, gfp] );
+	ptr = kzalloc_objs(*ptr, count [, gfp] );
+	ptr = kmalloc_flex(*ptr, flex_member, count [, gfp] );
+	__auto_type ptr = kmalloc_obj(struct foo [, gfp] );
+
+L'argomento gfp è opzionale, e il suo valore predefinito è GFP_KERNEL.
+Se `ptr->flex_member` è annotato con __counted_by(), l'allocazione
+fallirà automaticamente se `count` è più grande del valore massimo
+rappresentabile che può essere memorizzato nel membro contatore
+associato a `flex_member`.

Documentation/translations/it_IT/process/email-clients.rst

@@ -335,7 +335,14 @@ Per rendere l'editor interno un po' più sensato, fate così:
 
   - impostate ``mailnews.send_plaintext_flowed`` a ``false``
 
-  - impostate ``mailnews.wraplength`` da ``72`` a ``0``
+  - impostate ``mailnews.wraplength`` da ``72`` a ``0`` **oppure** installate
+    l'estensione "Toggle Line Wrap"
+
+    https://github.com/jan-kiszka/togglelinewrap
+
+    https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
+
+    per controllare questo registro al volo.
 
 - Non scrivete messaggi HTML! Andate sulla finestra principale ed aprite la
   schermata :menuselection:`Menu principale-->Impostazioni account-->nome@unserver.ovunque-->Composizioni e indirizzi`.

Documentation/translations/it_IT/process/index.rst

@@ -63,6 +63,7 @@ della comunità del kernel (e oltre).
 .. toctree::
    :maxdepth: 1
 
+   license-rules
    code-of-conduct
    kernel-enforcement-statement
    kernel-driver-statement
@@ -78,6 +79,11 @@ con riguardo. I documenti che seguono descrivono le nostre politiche riguardo al
 trattamento di alcune classi particolari di bachi: le regressioni e i problemi
 di sicurezza.
 
+.. toctree::
+   :maxdepth: 1
+
+   security-bugs
+
 Informazioni per i manutentori
 ------------------------------
 
@@ -86,6 +92,7 @@ Come trovare le persone che accetteranno le vostre modifiche.
 .. toctree::
    :maxdepth: 1
 
+   maintainer-handbooks
    maintainers
 
 Altri documenti
@@ -98,6 +105,7 @@ degli sviluppatori:
    :maxdepth: 1
 
    kernel-docs
+   deprecated
 
 .. only::  subproject and html
 

Documentation/translations/it_IT/process/license-rules.rst

@@ -75,7 +75,10 @@ Sintassi degli identificatori di licenza
    possibile di un file che possa contenere commenti.  Per la maggior parte
    dei file questa è la prima riga, fanno eccezione gli script che richiedono
    come prima riga '#!PATH_TO_INTERPRETER'.  Per questi script l'identificativo
-   SPDX finisce nella seconda riga.
+   di licenza SPDX finisce nella seconda riga.
+
+   Alla riga dell'identificativo di licenza possono seguire, se lo si
+   desidera, una o più righe SPDX-FileCopyrightText.
 
 |
 
@@ -486,10 +489,13 @@ _`MODULE_LICENSE`
 				  file sorgenti.
 
     "Proprietary"		  Questo modulo è rilasciato con licenza
-				  proprietaria. Questa stringa è solo per i
-				  moduli proprietari di terze parti e non può
-				  essere usata per quelli che risiedono nei
-				  sorgenti del kernel. I moduli etichettati in
+				  proprietaria. "Proprietary" va inteso
+				  unicamente come "la licenza non è compatibile
+				  con la GPLv2". Questa stringa è solo per i
+				  moduli di terze parti non compatibili con la
+				  GPLv2 e non può essere usata per quelli che
+				  risiedono nei sorgenti del kernel. I moduli
+				  etichettati in
 				  questo modo stanno contaminando il kernel e
 				  gli viene assegnato un flag 'P'; quando
 				  vengono caricati, il caricatore di moduli del

Documentation/translations/it_IT/process/maintainer-handbooks.rst

@@ -5,8 +5,6 @@
 :Original: Documentation/process/maintainer-handbooks.rst
 :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
 
-.. _it_maintainer_handbooks_main:
-
 Note sul processo di sviluppo dei sottosistemi e dei sorgenti dei manutentori
 =============================================================================
 
@@ -15,10 +13,13 @@ sviluppo dedicate ai sottosistemi che vanno ad integrare quelle più generali
 descritte in :ref:`Documentation/translations/it_IT/process
 <it_development_process_main>`.
 
-Indice:
+Per gli sviluppatori, qui di seguito sono elencate tutte le guide specifiche
+per i sottosistemi conosciute. Se il sottosistema al quale state contribuendo
+non ha una guida elencata qui, è lecito chiedere chiarimenti sulle domande
+sollevate in Documentation/maintainer/maintainer-entry-profile.rst.
 
-.. toctree::
-   :numbered:
-   :maxdepth: 2
+Per i manutentori, si consiglia di documentare ulteriori requisiti ed
+aspettative se le sottomissioni trascurano sistematicamente specifici criteri
+di sottomissione. Vedere Documentation/maintainer/maintainer-entry-profile.rst.
 
-   maintainer-tip
+.. maintainers-profile-toc::

Documentation/translations/it_IT/process/maintainer-pgp-guide.rst

@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/maintainer-pgp-guide.rst <pgpguide>`
@@ -57,7 +59,7 @@ pratiche di sicurezza messe in atto.
 
 Il principio sopra indicato è la ragione per la quale è necessaria questa
 guida. Vogliamo essere sicuri che il riporre la fiducia negli sviluppatori
-non sia fatto semplicemente per incolpare qualcun'altro per future falle di
+non sia fatto unicamente per incolpare qualcun'altro per future falle di
 sicurezza. L'obiettivo è quello di fornire una serie di linee guida che gli
 sviluppatori possano seguire per creare un ambiente di lavoro sicuro e
 salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
@@ -68,7 +70,7 @@ stesso.
 Strumenti PGP
 =============
 
-Usare GnuPG 2.2 o successivo
+Usare GnuPG 2.4 o successivo
 ----------------------------
 
 La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo
@@ -77,9 +79,10 @@ usate::
 
     $ gpg --version | head -n1
 
-Se state utilizzando la version 2.2 o successiva, allora siete pronti a partire.
-Se invece state usando una versione precedente, allora alcuni comandi elencati
-in questa guida potrebbero non funzionare.
+Se state utilizzando la versione 2.4 o successiva, allora siete pronti a
+partire. Se invece state usando una versione precedente, allora si tratta
+di una versione di GnuPG non più mantenuta, e alcuni comandi elencati in
+questa guida potrebbero non funzionare.
 
 Configurare le opzioni di gpg-agent
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -214,12 +217,6 @@ possano ricevere la vostra nuova sottochiave::
 
     $ gpg --send-key [fpr]
 
-.. note:: Supporto ECC in GnuPG
-
-   Tenete presente che se avete intenzione di usare un dispositivo che non
-   supporta chiavi ED25519 ECC, allora dovreste usare "nistp256" al posto di
-   "ed25519". Più avanti ci sono alcune raccomandazioni per i dispositivi.
-
 Copia di riserva della chiave primaria per gestire il recupero da disastro
 --------------------------------------------------------------------------
 
@@ -227,7 +224,7 @@ Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra,
 maggiori saranno i motivi per avere una copia di riserva che non sia digitale,
 al fine di effettuare un recupero da disastro.
 
-Il modo migliore per creare una copia fisica della vostra chiave privata è
+Un buon modo per creare una copia fisica della vostra chiave privata è
 l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori
 dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre
 soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte
@@ -238,11 +235,11 @@ vostra chiave privata::
 
     $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
 
-Stampate il file (o fate un pipe direttamente verso lpr), poi prendete
-una penna e scrivete la passphare sul margine del foglio.  **Questo è
-caldamente consigliato** perché la copia cartacea è comunque criptata con
-la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al
-momento della creazione di quella copia -- *garantito*.
+Stampate il file, poi prendete una penna e scrivete la passphare sul
+margine del foglio.  **Questo è caldamente consigliato** perché la copia
+cartacea è comunque criptata con la passphrase, e se mai doveste
+cambiarla non vi ricorderete qual'era al momento della creazione di
+quella copia -- *garantito*.
 
 Mettete la copia cartacea e la passphrase scritta a mano in una busta e
 mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa,
@@ -250,10 +247,9 @@ magari in una cassetta di sicurezza in banca.
 
 .. note::
 
-    Probabilmente la vostra stampante non è più quello stupido dispositivo
-    connesso alla porta parallela, ma dato che il suo output è comunque
-    criptato con la passphrase, eseguire la stampa in un sistema "cloud"
-    moderno dovrebbe essere comunque relativamente sicuro.
+    La chiave è comunque criptata con la vostra passphrase, quindi
+    stampare anche con stampanti moderne "integrate nel cloud" dovrebbe
+    rimanere un'operazione relativamente sicura.
 
 Copia di riserva di tutta la cartella GnuPG
 -------------------------------------------
@@ -269,17 +265,17 @@ prontezza rispetto al recupero da disastro che abbiamo risolto con
 vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o
 firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro.
 
-Incominciate con una piccola chiavetta di memoria USB (preferibilmente due)
-che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate
-riferimento alla documentazione della vostra distribuzione per capire come
-fare.
+Incominciate con un supporto di memoria esterno (preferibilmente due) che
+userete per le copie di riserva. Dovrete creare su questo dispositivo una
+partizione criptata usando LUKS -- fate riferimento alla documentazione
+della vostra distribuzione per capire come fare.
 
 Per la passphrase di criptazione, potete usare la stessa della vostra chiave
 primaria.
 
-Una volta che il processo di criptazione è finito, reinserite il disco USB ed
-assicurativi che venga montato correttamente. Copiate interamente la cartella
-``.gnugp`` nel disco criptato::
+Una volta che il processo di criptazione è finito, reinserite il vostro
+dispositivo ed assicurativi che venga montato correttamente. Copiate
+interamente la cartella ``.gnugp`` nel disco criptato::
 
     $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
 
@@ -288,11 +284,11 @@ Ora dovreste verificare che tutto continui a funzionare::
     $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
 
 Se non vedete errori, allora dovreste avere fatto tutto con successo.
-Smontate il disco USB, etichettatelo per bene di modo da evitare di
-distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed
-infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirà
-di tanto in tanto per modificare le identità, aggiungere o revocare
-sottochiavi, o firmare le chiavi di altre persone.
+Smontate il dispositivo, etichettatelo per bene di modo da evitare di
+sovrascriverlo per errore, ed infine mettetelo in un posto sicuro -- ma non
+troppo lontano, perché vi servirà di tanto in tanto per modificare le
+identità, aggiungere o revocare sottochiavi, o firmare le chiavi di altre
+persone.
 
 Togliete la chiave primaria dalla vostra home
 ---------------------------------------------
@@ -321,7 +317,7 @@ cartella home e la si archivia su un dispositivo disconnesso.
     che stiamo per fare renderà la vostra chiave inutile se non avete delle
     copie di riserva utilizzabili!
 
-Per prima cosa, identificate il keygrip della vostra chiave primaria::
+Per prima cosa, identificate il "keygrip" della vostra chiave primaria::
 
     $ gpg --with-keygrip --list-key [fpr]
 
@@ -346,7 +342,7 @@ ad un file nella cartella ``~/.gnupg``::
     2222000000000000000000000000000000000000.key
     3333000000000000000000000000000000000000.key
 
-Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip
+È sufficiente rimuovere il file .key che corrisponde al keygrip
 della chiave primaria::
 
     $ cd ~/.gnupg/private-keys-v1.d
@@ -391,8 +387,9 @@ Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono
 caricate nella memoria di sistema e potrebbero essere rubate con l'uso di
 malware sofisticati (pensate a Meltdown e a Spectre).
 
-Il miglior modo per proteggere le proprie chiave è di spostarle su un
-dispositivo specializzato in grado di effettuare operazioni smartcard.
+Un buon modo per proteggere completamente le vostre chiavi è di spostarle
+su un dispositivo specializzato in grado di effettuare operazioni
+smartcard.
 
 I benefici di una smartcard
 ---------------------------
@@ -401,12 +398,13 @@ Una smartcard contiene un chip crittografico che è capace di immagazzinare
 le chiavi private ed effettuare operazioni crittografiche direttamente sulla
 carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema
 operativo usato sul computer non sarà in grado di accedere alle chiavi.
-Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di
-avere una copia di riserva sicura -- quando il dispositivo USB è connesso e
-montato, il sistema operativo potrà accedere al contenuto delle chiavi private.
+Questo è molto diverso dal dispositivo di memoria criptato che abbiamo usato
+allo scopo di avere una copia di riserva sicura -- quando quel dispositivo
+è connesso e montato, il sistema operativo potrà accedere al contenuto
+delle chiavi private.
 
-L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo
-capace di operazioni di tipo smartcard.
+L'uso di un dispositivo di memoria esterno criptato non può sostituire le
+funzioni di un dispositivo capace di operazioni di tipo smartcard.
 
 Dispositivi smartcard disponibili
 ---------------------------------
@@ -417,28 +415,27 @@ implementi le funzionalità delle smartcard.  Sul mercato ci sono diverse
 soluzioni disponibili:
 
 - `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
-  `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi
-  ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza
-  alla manomissione o alcuni attacchi ad un canale laterale).
-- `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla
-  manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la
-  crittografia ECC (NISTP).
+  `GnuK`_ della FSIJ. È una delle opzioni più economiche, ma offre meno
+  funzionalità di sicurezza (come la resistenza alla manomissione o alcuni
+  attacchi ad un canale laterale).
+- `Nitrokey 3`_: è simile alla Nitrokey Start, ma è più resistente alla
+  manomissione, offre più funzionalità di sicurezza e diverse forme USB.
+  Supporta la crittografia ECC (ED25519 e NISTP).
 - `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica
-  della  Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
-  computer portatili più recenti. In aggiunta, offre altre funzionalità di
-  sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP)
+  della Nitrokey a parità di funzionalità. Supporta la crittografia ECC
+  (ED25519 e NISTP).
 
 La vostra scelta dipenderà dal costo, la disponibilità nella vostra regione, e
 sulla scelta fra dispositivi aperti e proprietari.
 
 .. note::
 
-    Se siete nella lista MAINTAINERS o avete un profilo su kernel.org, allora
-    `potrete avere gratuitamente una Nitrokey Start`_ grazie alla fondazione
-    Linux.
+    Se siete elencati in una voce `M:` nel file MAINTAINERS o avete un
+    profilo su kernel.org, allora `potrete avere gratuitamente una
+    Nitrokey Start`_ grazie alla fondazione Linux.
 
-.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
-.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
+.. _`Nitrokey Start`: https://www.nitrokey.com/products/nitrokeys
+.. _`Nitrokey 3`: https://www.nitrokey.com/products/nitrokeys
 .. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/
 .. _Gnuk: https://www.fsij.org/doc-gnuk/
 .. _`potrete avere gratuitamente una Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
@@ -474,7 +471,7 @@ dell'amministratore viene usato così raramente che è inevitabile dimenticarsel
 se non lo si annota.
 
 Tornando al nostro menu, potete impostare anche altri valori (come il nome,
-il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
+il genere, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
 altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento.
 
 .. note::
@@ -636,7 +633,7 @@ eseguite::
 Se per voi è più facile da memorizzare, potete anche utilizzare una data
 specifica (per esempio, il vostro compleanno o capodanno)::
 
-    $ gpg --quick-set-expire [fpr] 2025-07-01
+    $ gpg --quick-set-expire [fpr] 2038-07-01
 
 Ricordatevi di inviare l'aggiornamento ai keyserver::
 
@@ -676,8 +673,8 @@ storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia,
 con i centinaia di repositori clonati che ci sono in giro, come si fa a
 verificare che la loro copia di linux.git non è stata manomessa da qualcuno?
 
-Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga
-"Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
+Oppure, cosa succede se viene scoperto del codice malevolo nel kernel e la
+riga "Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
 `non averci niente a che fare`_?
 
 Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP.
@@ -732,9 +729,9 @@ Il merge conterrà qualcosa di simile::
     # gpg: Signature made [...]
     # gpg: Good signature from [...]
 
-Se state verificando il tag di qualcun altro, allora dovrete importare
-la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`"
-che troverete più avanti.
+Se state verificando il tag di qualcun altro, allora dovrete prima
+importare la loro chiave PGP. Fate riferimento alla sezione
+":ref:`it_verify_identities`" che troverete più avanti.
 
 Configurare git per firmare sempre i tag con annotazione
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -748,16 +745,17 @@ dovete impostare la seguente opzione globale::
 Come usare commit firmati
 -------------------------
 
-Creare dei commit firmati è facile, ma è molto più difficile utilizzarli
-nello sviluppo del kernel linux per via del fatto che ci si affida alle
-liste di discussione e questo modo di procedere non mantiene le firme PGP
-nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio
-locale per allinearsi al kernel anche le proprie firme PGP verranno scartate.
-Per questo motivo, la maggior parte degli sviluppatori del kernel non si
-preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati
-che si trovano in altri repositori usati per il proprio lavoro.
+È anche possibile creare dei commit firmati, ma la loro utilità nello
+sviluppo del kernel Linux è limitata. Il flusso di lavoro per contribuire
+al kernel si basa sull'invio di patch, e la conversione dei commit in
+patch non preserva le firme PGP dei commit. Inoltre, quando si esegue il
+*rebase* del proprio repositorio su un ramo principale più recente, le
+firme PGP dei commit verranno scartate. Per questo motivo, la maggior
+parte degli sviluppatori del kernel non si preoccupano troppo di firmare
+i propri commit ed ignoreranno quelli firmati che si trovano in altri
+repositori usati per il proprio lavoro.
 
-Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
+Detto ciò, se avete il vostro repositorio di lavoro disponibile al pubblico
 su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org,
 o altri), allora la raccomandazione è di firmare tutti i vostri commit
 anche se gli sviluppatori non ne beneficeranno direttamente.
@@ -769,17 +767,18 @@ Vi raccomandiamo di farlo per i seguenti motivi:
    esternamente che hanno firme PGP sui commit avranno un certo valore a
    questo scopo.
 2. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per
-   esempio dopo un danneggiamento del disco), la firma vi permetterà di
-   verificare l'integrità del repositorio prima di riprendere il lavoro.
+   esempio dopo aver reinstallato il vostro sistema), la firma vi
+   permetterà di verificare l'integrità del repositorio prima di
+   riprendere il lavoro.
 3. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma
    permetterà di verificare l'integrità dei commit prima di applicarli.
 
 Creare commit firmati
 ~~~~~~~~~~~~~~~~~~~~~
 
-Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S``
-al comando ``git commit`` (si usa la lettera maiuscola per evitare
-conflitti con un'altra opzione)::
+Per creare un commit firmato, aggiungete l'opzione ``-S`` al comando
+``git commit`` (si usa la lettera maiuscola per evitare conflitti con
+un'altra opzione)::
 
     $ git commit -S
 
@@ -814,6 +813,11 @@ un'attestazione delle firme crittografiche (tipo DKIM):
 Installare e configurate patatt
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. note::
+
+    Se usate B4 per inviare le vostre patch, patatt è già installato ed
+    integrato nel vostro flusso di lavoro.
+
 Lo strumento patatt è disponibile per diverse distribuzioni, dunque cercatelo
 prima lì. Oppure potete installarlo usano pypi "``pip install patatt``"
 
@@ -855,7 +859,7 @@ esempio::
 Come verificare l'identità degli sviluppatori del kernel
 ========================================================
 
-Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave
+Firmare tag e commit è semplice, ma come si fa a verificare che la chiave
 usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un
 impostore?
 
@@ -892,7 +896,7 @@ Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD
 da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra
 chiave lo UID di kernel.org`_.
 
-.. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
+.. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key
 
 Web of Trust (WOT) o Trust on First Use (TOFU)
 ----------------------------------------------
@@ -905,7 +909,7 @@ essere le entità di certificazione di cui dovreste fidarvi, PGP lascia
 la responsabilità ad ogni singolo utente.
 
 Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia.
-Nonostante sia un importante aspetto della specifica OpenPGP, recentemente
+Nonostante sia tuttora una parte importante della specifica OpenPGP, recentemente
 le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco
 alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come
 "ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi
@@ -915,8 +919,8 @@ SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una
 decisione circa la fiducia che riponete nella nuova chiave. In modo simile,
 la prima volta che importate la chiave PGP di qualcuno, si assume sia valida.
 Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità,
-entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete
-verificare manualmente quale tenere.
+entrambe, la vecchia e la nuova, verranno segnate per la verifica e dovrete
+controllare manualmente quale tenere.
 
 Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione
 di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
@@ -924,6 +928,8 @@ di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
 
     trust-model tofu+pgp
 
+.. _it_kernel_org_trust_repository:
+
 Usare il repositorio kernel.org per il web of trust
 ---------------------------------------------------
 

Documentation/translations/it_IT/process/maintainers.rst

@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
 :Original: Documentation/process/maintainers.rst
 
 Lista dei manutentori e come inviare modifiche al kernel

Documentation/translations/it_IT/process/programming-language.rst

@@ -8,8 +8,8 @@
 Linguaggio di programmazione
 ============================
 
-Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_.
-Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando
+Il kernel Linux è scritto nel linguaggio di programmazione C [it-c-language]_.
+Più precisamente, viene compilato con ``gcc`` [it-gcc]_ usando
 l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU
 dello standard ISO C11.
 Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione
@@ -42,7 +42,7 @@ Per maggiori informazioni consultate il file d'intestazione
 Rust
 ----
 
-Il kernel supporta sperimentalmente il linguaggio di programmazione Rust
+Il kernel supporta il linguaggio di programmazione Rust
 [it-rust-language]_ abilitando l'opzione di configurazione ``CONFIG_RUST``. Il
 codice verrà compilato usando ``rustc`` [it-rustc]_ con l'opzione
 ``--edition=2021`` [it-rust-editions]_. Le edizioni Rust sono un modo per

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

@@ -98,9 +98,12 @@ Compilare il codice
      e correggere i problemi
 
 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.
+   cross-compilazione o altri.
+   Da notare che testare su architetture con diverse dimensioni delle parole
+   (32 e 64 bit) e diverso ordinamento dei byte (*big-* e *little-endian*) è
+   efficace nell'individuare vari problemi di portabilità dovuti ad
+   assunzioni errate sull'intervallo di valori rappresentabili, l'allineamento
+   dei dati, o l'ordinamento dei byte, fra le altre cose.
 
 3) Il nuovo codice è stato compilato con ``gcc -W`` (usate
     ``make KCFLAGS=-W``).  Questo genererà molti avvisi, ma è ottimo

Documentation/translations/it_IT/process/submitting-patches.rst

@@ -28,7 +28,7 @@ renderà la vostra vita di sviluppatore del kernel molto più semplice.
 
 I sorgenti di alcuni sottosistemi e manutentori contengono più informazioni
 riguardo al loro modo di lavorare ed aspettative. Consultate
-:ref:`Documentation/translations/it_IT/process/maintainer-handbooks.rst <it_maintainer_handbooks_main>`
+Documentation/translations/it_IT/process/maintainer-handbooks.rst
 
 Ottenere i sorgenti attuali
 ---------------------------
@@ -162,8 +162,8 @@ proibiti.
 
 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
 trovato un problema usando ``git bisect``, per favore usate l'etichetta
-'Fixes:' indicando i primi 12 caratteri dell'identificativo SHA-1 seguiti
-dalla riga riassuntiva.  Per esempio::
+'Fixes:' indicando almeno i primi 12 caratteri dell'identificativo SHA-1
+seguiti dalla riga riassuntiva.  Per esempio::
 
 	Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
 
@@ -444,12 +444,11 @@ delle patch che vengono inviate per e-mail.
 La firma è una semplice riga alla fine della descrizione della patch che
 certifica che l'avete scritta voi o che avete il diritto di pubblicarla
 come patch open-source.  Le regole sono abbastanza semplici: se potete
-certificare quanto segue:
+certificare quanto segue::
 
-Il certificato d'origine dello sviluppatore 1.1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+        Il certificato d'origine dello sviluppatore 1.1
 
-Contribuendo a questo progetto, io certifico che:
+        Contribuendo a questo progetto, io certifico che:
 
         (a) Il contributo è stato creato interamente, o in parte, da me e che
             ho il diritto di inviarlo in accordo con la licenza open-source
@@ -505,27 +504,48 @@ della patch ma desidera firmare e mettere agli atti la loro approvazione,
 allora queste persone possono chiedere di aggiungere al changelog della patch
 una riga Acked-by:.
 
-Acked-by: viene spesso utilizzato dai manutentori del sottosistema in oggetto
-quando quello stesso manutentore non ha contribuito né trasmesso la patch.
+Acked-by: è pensata per essere usata da coloro che sono responsabili, o
+comunque coinvolti, con il codice interessato in un modo o nell'altro. Più
+comunemente, dal manutentore, quando quello stesso manutentore non ha
+contribuito né trasmesso la patch.
+
+Acked-by: può anche essere usata da altre parti interessate, come persone con
+conoscenza specifica dell'argomento (per esempio l'autore originale del
+codice modificato), revisori lato spazio-utente per una patch che tocca la
+uAPI del kernel, o utenti chiave di una funzionalità.  Opzionalmente, in
+questi casi, può essere utile aggiungere un "# Suffisso" per chiarirne il
+significato::
+
+	Acked-by: The Stakeholder <stakeholder@example.org> # Come utente primario
 
 Acked-by: non è formale come Signed-off-by:.  Questo indica che la persona ha
 revisionato la patch e l'ha trovata accettabile.  Per cui, a volte, chi
 integra le patch convertirà un "sì, mi sembra che vada bene" in un Acked-by:
 (ma tenete presente che solitamente è meglio chiedere esplicitamente).
 
+Acked-by: è anche meno formale di Reviewed-by:.  Per esempio, un manutentore
+potrebbe usarla per indicare che è d'accordo con l'integrazione della patch,
+pur non avendola revisionata con lo stesso livello d'approfondimento che
+avrebbe richiesto un Reviewed-by:.  Allo stesso modo, un utente chiave
+potrebbe non aver effettuato una revisione tecnica della patch, ma potrebbe
+comunque essere soddisfatto dell'approccio generale, della funzionalità o
+dell'interfaccia rivolta all'utente.
+
 Acked-by: non indica l'accettazione di un'intera patch.  Per esempio, quando
 una patch ha effetti su diversi sottosistemi e ha un Acked-by: da un
 manutentore di uno di questi, significa che il manutentore accetta quella
 parte di codice relativa al sottosistema che mantiene.  Qui dovremmo essere
 giudiziosi.  Quando si hanno dei dubbi si dovrebbe far riferimento alla
-discussione originale negli archivi della lista di discussione.
+discussione originale negli archivi della lista di discussione.  Anche in
+questo caso si può usare un "# Suffisso" per chiarire.
 
 Se una persona ha avuto l'opportunità di commentare la patch, ma non lo ha
-fatto, potete aggiungere l'etichetta ``Cc:`` alla patch.  Questa è l'unica
-etichetta che può essere aggiunta senza che la persona in questione faccia
-alcunché - ma dovrebbe indicare che la persona ha ricevuto una copia della
-patch.  Questa etichetta documenta che terzi potenzialmente interessati sono
-stati inclusi nella discussione.
+fatto, potete aggiungere l'etichetta ``Cc:`` alla patch.  Questa etichetta
+documenta che terzi potenzialmente interessati sono stati inclusi nella
+discussione.  Da notare che questa è una delle sole tre etichette che
+potreste poter usare senza il permesso esplicito della persona nominata (per
+i dettagli, vedere più avanti "Etichettare le persone richiede un
+permesso").
 
 Co-developed-by: indica che la patch è stata cosviluppata da diversi
 sviluppatori; viene usato per assegnare più autori (in aggiunta a quello
@@ -569,13 +589,14 @@ Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
 
 L'etichetta Reported-by da credito alle persone che trovano e riportano i bachi
 e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro.
-Rammentate che se il baco è stato riportato in privato, dovrete chiedere il
-permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va
-usata per i bachi, dunque non usatela per richieste di nuove funzionalità.
-Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al
-rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può
-essere usata in alternativa a Closes: se la patch corregge solo in parte il
-problema riportato nel rapporto.
+Questa etichetta va usata per i bachi, dunque non usatela per richieste di
+nuove funzionalità. Questa etichetta dovrebbe essere seguita da quella Closes:
+con un indirizzo al rapporto, a meno che questo non sia disponibile sul web.
+L'etichetta Link: può essere usata in alternativa a Closes: se la patch
+corregge solo in parte il problema riportato nel rapporto. Da notare che
+l'etichetta Reported-by è una delle sole tre etichette che potreste poter
+usare senza il permesso esplicito della persona nominata (per i dettagli,
+vedere più avanti "Etichettare le persone richiede un permesso").
 
 L'etichetta Tested-by: indica che la patch è stata verificata con successo
 (su un qualche sistema) dalla persona citata.  Questa etichetta informa i
@@ -584,12 +605,11 @@ persone che possano verificare il codice in futuro, e garantisce che queste
 stesse persone ricevano credito per il loro lavoro.
 
 Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
-considerata accettabile in accordo con la dichiarazione dei revisori:
+considerata accettabile in accordo con la dichiarazione dei revisori::
 
-Dichiarazione di svista dei revisori
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+	Dichiarazione di svista dei revisori
 
-Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
+	Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
 
 	 (a) Ho effettuato una revisione tecnica di questa patch per valutarne
 	     l'adeguatezza ai fini dell'inclusione nel ramo principale del
@@ -611,8 +631,9 @@ Offrendo la mia etichetta Reviewed-by, dichiaro quanto segue:
 
 L'etichetta Reviewed-by è la dichiarazione di un parere sulla bontà di
 una modifica che si ritiene appropriata e senza alcun problema tecnico
-importante.  Qualsiasi revisore interessato (quelli che lo hanno fatto)
-possono offrire il proprio Reviewed-by per la patch.  Questa etichetta serve
+importante.  Qualsiasi revisore interessato (che lo abbia fatto e che sia
+una persona dall'identità nota) può offrire il proprio Reviewed-by per la
+patch.  Questa etichetta serve
 a dare credito ai revisori e a informare i manutentori sul livello di revisione
 che è stato fatto sulla patch.  L'etichetta Reviewed-by, quando fornita da
 revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
@@ -623,28 +644,63 @@ Quando si riceve una email sulla lista di discussione da un tester o
 un revisore, le etichette Tested-by o Reviewed-by devono essere
 aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
 la patch è cambiata in modo significativo, queste etichette potrebbero
-non avere più senso e quindi andrebbero rimosse. Solitamente si tiene traccia
-della rimozione nel changelog della patch (subito dopo il separatore '---').
+non avere più senso e quindi andrebbero rimosse. Solitamente si tiene
+traccia della rimozione di un'etichetta Acked-by, Tested-by o Reviewed-by
+nel changelog della patch, con una spiegazione, (subito dopo il
+separatore '---').
 
 L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
-dalla persona nominata e le da credito. Tenete a mente che questa etichetta
-non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
-l'idea non è stata pubblicata in un forum pubblico.  Detto ciò, dando credito
-a chi ci fornisce delle idee, si spera di poterli ispirare ad aiutarci
-nuovamente in futuro.
+dalla persona nominata e le da credito: se diamo diligentemente credito a
+chi ci fornisce delle idee, si spera di poterli ispirare ad aiutarci
+nuovamente in futuro. Da notare che questa è una delle sole tre etichette
+che potreste poter usare senza il permesso esplicito della persona
+nominata (per i dettagli, vedere più avanti "Etichettare le persone
+richiede un permesso").
 
-L'etichetta Fixes: indica che la patch corregge un problema in un commit
-precedente.  Serve a chiarire l'origine di un baco, il che aiuta la revisione
-del baco stesso.  Questa etichetta è di aiuto anche per i manutentori dei
-kernel stabili al fine di capire quale kernel deve ricevere la correzione.
-Questo è il modo suggerito per indicare che un baco è stato corretto nella
-patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
+L'etichetta Fixes: indica che la patch corregge un baco in un commit
+precedente.  Serve a rendere facile determinare dove abbia avuto origine
+un problema, il che può aiutare la revisione di una correzione.  Questa
+etichetta è di aiuto anche per i manutentori dei kernel stabili al fine
+di capire quale kernel deve ricevere la correzione.  Questo è il modo
+suggerito per indicare che un baco è stato corretto nella patch. Per
+maggiori dettagli leggete :ref:`it_describe_changes`
 
 Da notare che aggiungere un tag "Fixes:" non esime dalle regole
 previste per i kernel stabili, e nemmeno dalla necessità di aggiungere
 in copia conoscenza stable@vger.kernel.org su tutte le patch per
 suddetti kernel.
 
+Infine, sebbene fornire le etichette sia gradito e generalmente molto
+apprezzato, tenete presente che i firmatari (cioè chi sottomette e i
+manutentori) potrebbero usare la propria discrezione nell'applicare le
+etichette proposte.
+
+.. _it_tagging_people:
+
+Etichettare le persone richiede un permesso
+--------------------------------------------
+
+State attenti ad aggiungere le suddette etichette alla vostra patch: tutte,
+tranne Cc:, Reported-by: e Suggested-by:, richiedono il permesso esplicito
+della persona nominata.  Per queste tre è sufficiente un permesso implicito,
+se la persona ha contribuito al kernel Linux usando quel nome e quell'indirizzo
+email secondo gli archivi di lore o la cronologia dei commit -- e, nel caso di
+Reported-by: e Suggested-by:, se la segnalazione o il suggerimento sono
+avvenuti pubblicamente.  Da notare che bugzilla.kernel.org è, in questo senso,
+un luogo pubblico, ma gli indirizzi email usati lì sono privati; quindi non
+esponeteli nelle etichette, a meno che la persona non li abbia già usati in
+contributi precedenti.
+
+Usare Assisted-by:
+-------------------
+
+Se avete usato un qualsiasi tipo di strumento di assistenza avanzata alla
+scrittura del codice per la creazione della vostra patch, dovete darne atto
+aggiungendo un'etichetta Assisted-by.  Non farlo può ostacolare
+l'accettazione del vostro lavoro.  Fate riferimento a
+Documentation/process/coding-assistants.rst per i dettagli su come dare
+atto dell'uso di assistenti alla scrittura del codice.
+
 .. _it_the_canonical_patch_format:
 
 Il formato canonico delle patch
@@ -656,6 +712,9 @@ potere usare il comando ``git format-patch`` per ottenere patch nel formato
 appropriato.  Lo strumento non crea il testo necessario, per cui, leggete
 le seguenti istruzioni.
 
+Oggetto
+^^^^^^^
+
 L'oggetto di una patch canonica è la riga::
 
     Subject: [PATCH 001/123] subsystem: summary phrase
@@ -729,6 +788,9 @@ Un paio di esempi di oggetti::
     Subject: [PATCH v2] sub/sys: Condensed patch summary
     Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
 
+Riga From
+^^^^^^^^^
+
 La riga ``from`` dev'essere la prima nel corpo del messaggio ed è nel
 formato:
 
@@ -739,6 +801,15 @@ l'autore della patch.  Se la riga ``from`` è mancante, allora per determinare
 l'autore da inserire nel changelog verrà usata la riga ``From``
 nell'intestazione dell'email.
 
+L'autore può indicare la propria affiliazione o lo sponsor del lavoro
+aggiungendo il nome di un'organizzazione alle righe ``from`` e ``SoB``,
+per esempio:
+
+	From: Patch Author (Azienda) <author@example.com>
+
+Corpo della spiegazione
+^^^^^^^^^^^^^^^^^^^^^^^^
+
 Il corpo della spiegazione verrà incluso nel changelog permanente, per cui
 deve aver senso per un lettore esperto che è ha dimenticato i dettagli della
 discussione che hanno portato alla patch.  L'inclusione di informazioni
@@ -755,6 +826,33 @@ aggiungete solo quello che è necessario per far si che la vostra patch
 venga trovata.  Come nella ``summary phrase``, è importante essere sia
 brevi che descrittivi.
 
+.. _it_backtraces:
+
+Aggiungere i *backtrace* nei messaggi di commit
+""""""""""""""""""""""""""""""""""""""""""""""""
+
+I *backtrace* aiutano a documentare la sequenza di chiamate a funzione
+che portano ad un problema. Tuttavia, non tutti i *backtrace* sono
+davvero utili. Per esempio, le sequenze iniziali di avvio sono uniche
+e ovvie. Copiare integralmente l'output di ``dmesg`` aggiunge tante
+informazioni che distraggono dal vero problema (per esempio, i
+marcatori temporali, la lista dei moduli, la lista dei registri, lo
+stato dello stack).
+
+Quindi, per rendere utile un *backtrace* dovreste eliminare le
+informazioni inutili, cosicché ci si possa focalizzare sul
+problema. Ecco un esempio di un *backtrace* essenziale::
+
+  unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
+  at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
+  Call Trace:
+  mba_wrmsr
+  update_domains
+  rdtgroup_mkdir
+
+Commento
+^^^^^^^^
+
 La linea di demarcazione ``---`` serve essenzialmente a segnare dove finisce
 il messaggio di changelog.
 
@@ -778,7 +876,10 @@ versione di una patch non sono parte del *chagelog* che viene incluso
 in git. Queste sono informazioni utili solo ai revisori. Se venissero
 messe sopra la riga, qualcuno dovrà fare del lavoro manuale per
 rimuoverle; cosa che invece viene fatta automaticamente quando vengono
-messe correttamente oltre la riga.::
+messe correttamente oltre la riga. Se disponibili, si consiglia di
+aggiungere anche i collegamenti alle versioni precedenti della patch
+(per esempio, un collegamento all'archivio di lore.kernel.org) per
+aiutare i revisori::
 
   <commit message>
   ...
@@ -787,35 +888,14 @@ messe correttamente oltre la riga.::
   V2 -> V3: Removed redundant helper function
   V1 -> V2: Cleaned up coding style and addressed review comments
 
+  v2: https://lore.kernel.org/bar
+  v1: https://lore.kernel.org/foo
+
   path/to/file | 5+++--
   ...
 
 Maggiori dettagli sul formato delle patch nei riferimenti qui di seguito.
 
-.. _it_backtraces:
-
-Aggiungere i *backtrace* nei messaggi di commit
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-I *backtrace* aiutano a documentare la sequenza di chiamate a funzione
-che portano ad un problema. Tuttavia, non tutti i *backtrace* sono
-davvero utili. Per esempio, le sequenze iniziali di avvio sono uniche
-e ovvie. Copiare integralmente l'output di ``dmesg`` aggiunge tante
-informazioni che distraggono dal vero problema (per esempio, i
-marcatori temporali, la lista dei moduli, la lista dei registri, lo
-stato dello stack).
-
-Quindi, per rendere utile un *backtrace* dovreste eliminare le
-informazioni inutili, cosicché ci si possa focalizzare sul
-problema. Ecco un esempio di un *backtrace* essenziale::
-
-  unchecked MSR access error: WRMSR to 0xd51 (tried to write 0x0000000000000064)
-  at rIP: 0xffffffffae059994 (native_write_msr+0x4/0x20)
-  Call Trace:
-  mba_wrmsr
-  update_domains
-  rdtgroup_mkdir
-
 .. _it_explicit_in_reply_to:
 
 Usare esplicitamente In-Reply-To nell'intestazione