* [PATCH] doc:it_IT: align Italian documentation in process
@ 2026-08-16 19:39 Federico Vaga
2026-08-16 22:22 ` Jonathan Corbet
0 siblings, 1 reply; 2+ messages in thread
From: Federico Vaga @ 2026-08-16 19:39 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel, Federico Vaga
This commit updates the Italian translation in `process/` following
these changes:
commit 44abc8fcbff2 ("Documentation: process: Arbitrarily bump kernel major version number")
commit ba2457109d5b ("Documentation: process: Also mention Sasha Levin as stable tree maintainer")
commit 5ce70894f6ca ("Doc: correct spelling and wording mistakes")
commit 46298375477b ("linux-next: update maintainer info.")
commit 43e9076a00b1 ("docs: Fix conflicting contributor identity info")
commit b27f9e8079bf ("docs: remove Documentation/dontdiff")
commit 9734b3e753ad ("docs: 5.Posting: mentioned Suggested-by: tag")
commit 4e6b7141d169 ("docs: clarify rules wrt tagging other people")
commit 944df7a31452 ("docs: update the guidance for Link: tags")
commit 0a83293322fd ("doc: development-process: add notice on testing")
commit a037699da0a1 ("docs: Add debugging section to process")
commit 78d979db6cef ("docs: add AI Coding Assistants documentation")
commit a66437c27979 ("Documentation: Provide guidelines for tool-generated content")
commit a592a36e4937 ("Documentation: use a source-read extension for the index link boilerplate")
commit 102606402f4f ("Documentation: Project continuity")
commit a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug")
commit d0b343605f1b ("kernel-docs: Add new section for Rust learning materials")
commit 57937eac1f78 ("kernel-docs: Add book to process/kernel-docs.rst")
commit d8c949c577b5 ("docs/licensing: Clarify wording about "GPL" and "Proprietary"")
commit ebf1bafd0907 ("LICENSES: Explicitly allow SPDX-FileCopyrightText")
commit 9fa7153c31a3 ("rust: conclude the Rust experiment")
commit 47cb33cedf47 ("docs: clarify wording in programming-language.rst")
commit 45a92c0b91d7 ("docs: maintainers: add SPDX license to the file")
commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family")
commit e4c8b46b924e ("slab: Introduce kmalloc_flex() and family")
commit d957b4184aee ("Documentation: deprecated.rst: kmalloc-family: mark argument as optional")
commit 120a64c8021d ("Documentation: process: fix brackets")
commit 079a028d6327 ("string: Remove strncpy() from the kernel")
commit e551bd4109d2 ("Documentation: remove :kyb: tags")
commit 4971ca2007e3 ("docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension")
commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices")
commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey")
commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link")
commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign")
commit a556bd882b94 ("docs: align with scripts/syscall.tbl migration")
commit e5b1c0fa4ff2 ("Documentation: Remove :manpage: from non-existing man pages")
commit 78a00cac1e96 ("docs: fix 're-use' -> 'reuse' in documentation")
commit ec6fd28baf61 ("docs: remove unneeded maintainer_handbooks_main label")
commit 8eae6da5f56c ("docs: auto-generate maintainer entry profile links")
commit bda185c30593 ("docs: maintainers_include: Only show main entry for profiles")
commit 2783096fb1dd ("docs: submit-checklist: Expand on build tests against different word sizes")
commit fb12098d8ee4 ("docs: submit-checklist: Allow creating cross-references for ABI README")
commit 5a63f0369bda ("docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README")
commit e5880f95a979 ("docs: process: discourage pointless boilerplate kdoc")
commit 2c62e2e874d1 ("coding-style: fix verb typo")
commit 197bbebd2581 ("docs: Update documentation to avoid mentioning of kernel.h")
commit eba6ffd126cd ("docs: kdoc: move kernel-doc to tools/docs")
commit 7c6d969d5349 ("Documentation: adopt new coding style of type-aware kmalloc-family")
commit 323fa4b9608b ("Documentation: Fix syntax of kmalloc_objs example in coding style doc")
commit d49172bbd7eb ("Documentation: clarify the expected collaboration with security bugs reporters")
commit 3a68841d1d9b ("Documentation: smooth the text flow in the security bug reporting process")
commit ceddb2c001d9 ("Documentation: insist on the plain-text requirement for security reports")
commit f2b1cbef1536 ("Documentation: minor updates to the security contacts")
commit a72b832a4823 ("Documentation: explain how to find maintainers addresses for security reports")
commit 496fa1befba1 ("Documentation: clarify the mandatory and desirable info for security reports")
commit f387e2e2b9d3 ("Documentation: fix two typos in latest update to the security report howto")
commit aed3c3346765 ("Documentation: security-bugs: do not systematically Cc the security team")
commit 4bf85afb9f3e ("Documentation: security-bugs: clarify requirements for AI-assisted reports")
commit 561458db0d6b ("docs: security-bugs: add a link to the threat-model documentation")
commit 5f5e7344322f ("kbuild: generate offset range data for builtin modules")
commit 41047d53bcff ("docs:process:changes: fix version command for btrfs-progs")
commit 82a1978d0fdc ("kheaders: use 'tar' instead of 'cpio' for copying files")
commit d2b239099cf0 ("docs: changes: update Sphinx minimal version to 3.4.3")
commit 5e25b972a22b ("docs: changes: update Python minimal version")
commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30")
commit 28d51df0dbaa ("Documentation: update binutils-2.30 version reference")
commit fc6edeea53f4 ("docs: Remove reiserfsprogs from dependencies.")
commit bc20c56e98e0 ("docs: changes: better document Python needs")
commit 20c098928356 ("kbuild: Bump minimum version of LLVM for building the kernel to 15.0.0")
commit 903922cfa0e6 ("lib/Kconfig.debug: Set the minimum required pahole version to v1.22")
commit 8913632998fc ("Documentation: Fix typos and grammatical errors")
commit c99fcb58501e ("docs: Fix an erroneous reference to sphinx.rst")
commit d8a224f519c6 ("docs: changes/ver_linux: fix entries and add several tools")
commit ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists")
commit f32fb9c58a5b ("rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)")
commit c3a00a3f31ff ("rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)")
commit ce3267a39a92 ("kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1")
commit 2c1ccd9a1d78 ("docs: changes.rst: restore pahole 1.26 minimum (regressed by sort)")
commit 3f997cbf676b ("docs: process: submitting-patches: split canonical patch format section")
commit 6356f18f09dc ("Align git commit ID abbreviation guidelines and checks")
commit cd9123eeb224 ("docs: submitting-patches: clarify Acked-by and introduce "# Suffix"")
commit 25fb101385f7 ("docs: submitting-patches: clarify difference between Acked-by and Reviewed-by")
commit 08c035da54a3 ("docs: submitting-patches: clarify that signers may use their discretion on tags")
commit 95767a592dc9 ("docs: submitting-patches: document the format for affiliation")
commit dc896f853e1a ("docs: submitting-patches: adjust Fixes definition slightly")
commit 22014a230093 ("Documentation/process: submitting-patches: fix typo in "were do"")
commit e36a7b1e1734 ("docs: submitting-patches: Clarify that removal of Acks needs explanation too")
commit 8a12e3fbf2c3 ("docs: submitting-patches: suggest adding previous version links")
commit 6252e5c1c20e ("docs: add an Assisted-by mention to submitting-patches.rst")
commit 48c3876a6a6f ("docs: submitting-patches: Clarify that "reviewer" is a person")
commit 83f71fbc66fb ("docs: submitting-patches: Fix section structure around DCO")
Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
---
.../translations/it_IT/process/1.Intro.rst | 14 +-
.../translations/it_IT/process/2.Process.rst | 59 +++--
.../translations/it_IT/process/5.Posting.rst | 34 ++-
.../it_IT/process/7.AdvancedTopics.rst | 2 +-
.../it_IT/process/adding-syscalls.rst | 94 ++++++++
.../it_IT/process/coding-style.rst | 33 +--
.../translations/it_IT/process/deprecated.rst | 85 +++++--
.../it_IT/process/email-clients.rst | 9 +-
.../translations/it_IT/process/index.rst | 8 +
.../it_IT/process/license-rules.rst | 16 +-
.../it_IT/process/maintainer-handbooks.rst | 15 +-
.../it_IT/process/maintainer-pgp-guide.rst | 172 +++++++-------
.../it_IT/process/maintainers.rst | 2 +
.../it_IT/process/programming-language.rst | 6 +-
.../it_IT/process/submit-checklist.rst | 9 +-
.../it_IT/process/submitting-patches.rst | 214 ++++++++++++------
16 files changed, 523 insertions(+), 249 deletions(-)
diff --git a/Documentation/translations/it_IT/process/1.Intro.rst b/Documentation/translations/it_IT/process/1.Intro.rst
index c1be6dc398a7..03b61ccf5882 100644
--- a/Documentation/translations/it_IT/process/1.Intro.rst
+++ b/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,
diff --git a/Documentation/translations/it_IT/process/2.Process.rst b/Documentation/translations/it_IT/process/2.Process.rst
index 6262c3908665..5da70c6f39a7 100644
--- a/Documentation/translations/it_IT/process/2.Process.rst
+++ b/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:
-
- ====== =================
- 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.
+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>`_.
+
+.. [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
diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Documentation/translations/it_IT/process/5.Posting.rst
index 3b9b4db6fb9a..c4cf311e09b9 100644
--- a/Documentation/translations/it_IT/process/5.Posting.rst
+++ b/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
-------------------
diff --git a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst
index b3d8b62f3b57..592de7de4d99 100644
--- a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst
+++ b/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/.
diff --git a/Documentation/translations/it_IT/process/adding-syscalls.rst b/Documentation/translations/it_IT/process/adding-syscalls.rst
index c4ed6dbf5f05..a21c9af1e2cb 100644
--- a/Documentation/translations/it_IT/process/adding-syscalls.rst
+++ b/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
diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst
index 2a499412a2e3..b0cf138249c2 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/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
-----------------------------------------------------------
diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst
index d4ab76e9be49..64b7bf40057f 100644
--- a/Documentation/translations/it_IT/process/deprecated.rst
+++ b/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().
-
-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()
+---------
+La funzione strncpy() è stata rimossa dal kernel. Tutti i chiamanti che
+la usavano sono stati migrati verso alternative più sicure.
+
+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`.
diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst
index 9f8fe8abab4a..677b6715b8b1 100644
--- a/Documentation/translations/it_IT/process/email-clients.rst
+++ b/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`.
diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst
index 5a5214f5fd72..dd88c1140cf2 100644
--- a/Documentation/translations/it_IT/process/index.rst
+++ b/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
diff --git a/Documentation/translations/it_IT/process/license-rules.rst b/Documentation/translations/it_IT/process/license-rules.rst
index 4cd87a3a7bf9..50e49146d66c 100644
--- a/Documentation/translations/it_IT/process/license-rules.rst
+++ b/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
diff --git a/Documentation/translations/it_IT/process/maintainer-handbooks.rst b/Documentation/translations/it_IT/process/maintainer-handbooks.rst
index d840145bcceb..cc901809bbfa 100644
--- a/Documentation/translations/it_IT/process/maintainer-handbooks.rst
+++ b/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::
diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
index cdc43c4a9b0b..8a9c8bd8a62d 100644
--- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst
+++ b/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.
-
-Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
+È 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.
+
+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
---------------------------------------------------
diff --git a/Documentation/translations/it_IT/process/maintainers.rst b/Documentation/translations/it_IT/process/maintainers.rst
index 3225f7c89fda..95916bc8e346 100644
--- a/Documentation/translations/it_IT/process/maintainers.rst
+++ b/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
diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst
index 5bc5b9d42f31..623675f3b623 100644
--- a/Documentation/translations/it_IT/process/programming-language.rst
+++ b/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
diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst
index c58d773fd297..229e219a6f9a 100644
--- a/Documentation/translations/it_IT/process/submit-checklist.rst
+++ b/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
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
index 1cc4808139ce..a742610cb070 100644
--- a/Documentation/translations/it_IT/process/submitting-patches.rst
+++ b/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.
-
-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`
+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 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
--
2.47.3
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-16 22:22 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-16 19:39 [PATCH] doc:it_IT: align Italian documentation in process Federico Vaga
2026-08-16 22:22 ` Jonathan Corbet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox