mirror of
https://github.com/torvalds/linux.git
synced 2026-09-14 08:01:12 +02:00
A handful of late-arriving fixes, a Japanese translation that was ready
long ago but fell through the cracks, and an update to the Italian translations. -----BEGIN PGP SIGNATURE----- iQFCBAABCgAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAmqPEkcPHGNvcmJldEBs d24ubmV0AAoJEBdDWhNsDH5YnG4H9RbUq6++y8s7b+Hadki0d1O3xn6exEEpI3nt 0x4w3KHGT6fuTe5jLMOlP1QKlV9sN/5XrEDmtuaZObvF0yKyREX05QhsiMTfn9cj E749WfSUQ4zCeI8JZ7LtNT7AQA0zJxQkirUHdkmMNoMPGWcuPZYJGuhQFL+9c83N w8ZWGCi5CZ/kGlO36fXy/apSEngfG4gTiAtBVwG7fB+y9cYhHndy6Rr7Vt70hQQZ 6UwOC5kERlCwh3dIq0RwFhMJzGs6adDUi3lfzw4owqbXxdOA5VRrrVaVFNrAnWTD 0fZwSSkxBVztmlU4nm1uZut6VeUIwugbWT08JiEa8mHq8vgPfg== =rrXi -----END PGP SIGNATURE----- Merge tag 'docs-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux Pull more documentation updates from Jonathan Corbet: "A handful of late-arriving fixes, a Japanese translation that was ready long ago but fell through the cracks, and an update to the Italian translations" * tag 'docs-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux: docs: panic: Disclaimer about console verbosity when using panic_print with pstore docs: kernel-parameters: add CPU_FREQ, CPU_IDLE build options doc:it_IT: align Italian documentation in process docs: threat-model: fix /dev/kmsg reference docs: block: fix dead http link in blk-mq.rst docs/ja_JP: translate submitting-patches.rst (tag usage)
This commit is contained in:
Linus Torvalds
commit
2bdcd6cf2a
|
|
@ -8,6 +8,8 @@
|
|||
ARM64 ARM64 architecture is enabled.
|
||||
CLK Common clock infrastructure is enabled.
|
||||
CMA Contiguous Memory Area support is enabled.
|
||||
CPU_FREQ CPU frequency scaling is enabled.
|
||||
CPU_IDLE CPU idle time management is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||
EARLY Parameter processed too early to be embedded in initrd.
|
||||
|
|
@ -4892,6 +4894,7 @@ Kernel parameters
|
|||
|
||||
panic_print= Bitmask for printing system info when panic happens.
|
||||
User can chose combination of the following bits:
|
||||
|
||||
bit 0: print all tasks info
|
||||
bit 1: print system memory info
|
||||
bit 2: print timer info
|
||||
|
|
@ -4900,10 +4903,16 @@ Kernel parameters
|
|||
bit 5: replay all kernel messages on consoles at the end of panic
|
||||
bit 6: print all CPUs backtrace (if available in the arch)
|
||||
bit 7: print only tasks in uninterruptible (blocked) state
|
||||
*Be aware* that this option may print a _lot_ of lines,
|
||||
so there are risks of losing older messages in the log.
|
||||
Use this option carefully, maybe worth to setup a
|
||||
bigger log buffer with "log_buf_len" along with this.
|
||||
|
||||
*Be aware* that this option may print a _lot_ of lines.
|
||||
|
||||
There is an increased risk of losing older messages in
|
||||
the log. Maybe worth to setup a bigger log buffer with
|
||||
"log_buf_len" along with this.
|
||||
|
||||
Also consider using "printk.console_no_auto_verbose=Y"
|
||||
if using this along with pstore, to avoid extra delays
|
||||
due to increased console verbosity during panic.
|
||||
|
||||
panic_sys_info= A comma separated list of extra information to be dumped
|
||||
on panic.
|
||||
|
|
@ -4918,7 +4927,9 @@ Kernel parameters
|
|||
all_bt: print all CPUs backtrace (if available in the arch)
|
||||
blocked_tasks: print only tasks in uninterruptible (blocked) state
|
||||
|
||||
This is a human readable alternative to the 'panic_print' option.
|
||||
This is a human readable alternative to the 'panic_print'
|
||||
option above. Please be aware of the caveats using this,
|
||||
check the 'panic_print' parameter for more details.
|
||||
|
||||
panic_console_replay
|
||||
When panic happens, replay all kernel messages on
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ completed.
|
|||
Further reading
|
||||
---------------
|
||||
|
||||
- `Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems <http://kernel.dk/blk-mq.pdf>`_
|
||||
- `Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems <https://www.kernel.dk/blk-mq.pdf>`_
|
||||
|
||||
- `NOOP scheduler <https://en.wikipedia.org/wiki/Noop_scheduler>`_
|
||||
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ possibilities of user namespaces are not covered in this document.
|
|||
The kernel also offers a lot of troubleshooting and debugging facilities, which
|
||||
can constitute attack vectors when placed in wrong hands. While some of them
|
||||
are designed to be accessible to regular local users with a low risk (e.g.
|
||||
kernel logs via ``/proc/kmsg``), some would expose enough information to
|
||||
kernel logs via ``/dev/kmsg``), some would expose enough information to
|
||||
represent a risk in most places and the decision to expose them is under the
|
||||
administrator's responsibility (perf events, traces), and others are not
|
||||
designed to be accessed by non-privileged users (e.g. debugfs). Access to these
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-------------------
|
||||
|
|
|
|||
|
|
@ -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/.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-----------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
|
|
|||
|
|
@ -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
|
||||
---------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
:Original: Documentation/process/maintainers.rst
|
||||
|
||||
Lista dei manutentori e come inviare modifiche al kernel
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -479,3 +479,97 @@ revert にも ``Signed-off-by:`` を含める必要があります。
|
|||
関与せず、その取り扱いや転送を行った人によるものです。SoB の連鎖は、
|
||||
パッチがメンテナーを経て最終的に Linus へ届いた実際の経路を反映する
|
||||
必要があります。最初の SoB は、単独の主要作者であることを示します。
|
||||
|
||||
|
||||
Acked-by:、Cc:、Co-developed-by: を使用する場合
|
||||
------------------------------------------------
|
||||
|
||||
``Signed-off-by:`` タグは、署名者がパッチの開発に関与したか、
|
||||
そのパッチの送付経路に関与したことを示します。
|
||||
|
||||
パッチの準備や取り扱いに直接関与していない人が、そのパッチへの
|
||||
承認を表明し、記録に残したい場合は、パッチの変更履歴に
|
||||
``Acked-by:`` 行を追加するよう依頼できます。
|
||||
|
||||
``Acked-by:`` は、何らかの形で影響を受けるコードに責任を持つ人、
|
||||
またはそのコードに関与する人が使用することを意図しています。
|
||||
最も一般的なのは、パッチの作成にも転送にも関与していない
|
||||
メンテナーが使用する場合です。
|
||||
|
||||
``Acked-by:`` は、変更されるコードの元の作者など、その分野の
|
||||
知識を持つ人、カーネル uAPI パッチをユーザー空間側からレビューする人、
|
||||
または機能の主要な利用者など、その他の利害関係者も使用できます。
|
||||
このような場合は、必要に応じて意味を明確にするために
|
||||
``# Suffix`` を追加すると便利です::
|
||||
|
||||
Acked-by: The Stakeholder <stakeholder@example.org> # As primary user
|
||||
|
||||
``Acked-by:`` は ``Signed-off-by:`` ほど正式なものではありません。
|
||||
これは、承認した人が少なくともパッチをレビューし、受け入れる意思を
|
||||
示したことの記録です。そのため、パッチをマージする人が、
|
||||
「はい、問題なさそうです」という返答を手動で ``Acked-by:`` に
|
||||
変換することがあります。ただし、通常は明示的な承認を求める方が
|
||||
適切です。
|
||||
|
||||
``Acked-by:`` は ``Reviewed-by:`` よりも正式なものではありません。
|
||||
たとえば、メンテナーはパッチが取り込まれることに同意していても、
|
||||
``Reviewed-by:`` を付ける場合ほど十分にはレビューしていないことを
|
||||
示すために使用できます。同様に、主要な利用者はパッチの技術的な
|
||||
レビューを行っていなくても、全体的な方針、機能、または
|
||||
ユーザー向けインターフェースに満足している場合があります。
|
||||
|
||||
``Acked-by:`` は、必ずしもパッチ全体への同意を示すものでは
|
||||
ありません。たとえば、パッチが複数のサブシステムに影響し、
|
||||
そのうち一つのサブシステムのメンテナーから ``Acked-by:`` が
|
||||
付けられている場合、通常は、そのメンテナーが担当するコードに
|
||||
影響する部分だけへの同意を示します。ここでは状況に応じた判断が
|
||||
必要です。疑問がある場合は、メーリングリストアーカイブにある
|
||||
元の議論を参照してください。この場合も、意味を明確にするために
|
||||
``# Suffix`` を使用できます。
|
||||
|
||||
ある人がパッチにコメントする機会を得たものの、コメントしなかった
|
||||
場合は、必要に応じてパッチに ``Cc:`` タグを追加できます。このタグは、
|
||||
関心を持つ可能性のある人が議論に含まれていたことを記録します。
|
||||
なお、これは、名前を記載される本人の明示的な許可なしに使用できる
|
||||
可能性のある三つのタグのうちの一つです。詳細については、後述の
|
||||
「人をタグ付けするには許可が必要」を参照してください。
|
||||
|
||||
``Co-developed-by:`` は、パッチが複数の開発者によって共同で作成された
|
||||
ことを示します。複数の人が一つのパッチを共同で作成した場合に、
|
||||
``From:`` タグで示される作者に加えて、共同作者の貢献を明記するために
|
||||
使用します。
|
||||
|
||||
``Co-developed-by:`` は作者であることを示すため、各
|
||||
``Co-developed-by:`` の直後には、対応する共同作者の
|
||||
``Signed-off-by:`` を必ず記載しなければなりません。通常の sign-off
|
||||
手続きが適用されます。つまり、作者が ``From:`` と
|
||||
``Co-developed-by:`` のどちらで示されているかにかかわらず、
|
||||
``Signed-off-by:`` タグの順序は、可能な限りパッチの時系列上の
|
||||
経緯を反映する必要があります。特に、最後の ``Signed-off-by:`` は、
|
||||
必ずパッチを提出する開発者のものでなければなりません。
|
||||
|
||||
なお、``From:`` タグで示される作者が、メールヘッダーの From 行に
|
||||
記載された人物およびメールアドレスと同じ場合、``From:`` タグは
|
||||
省略できます。
|
||||
|
||||
``From:`` の作者自身が提出するパッチの例::
|
||||
|
||||
<changelog>
|
||||
|
||||
Co-developed-by: First Co-Author <first@coauthor.example.org>
|
||||
Signed-off-by: First Co-Author <first@coauthor.example.org>
|
||||
Co-developed-by: Second Co-Author <second@coauthor.example.org>
|
||||
Signed-off-by: Second Co-Author <second@coauthor.example.org>
|
||||
Signed-off-by: From Author <from@author.example.org>
|
||||
|
||||
``Co-developed-by:`` に記載された作者が提出するパッチの例::
|
||||
|
||||
From: From Author <from@author.example.org>
|
||||
|
||||
<changelog>
|
||||
|
||||
Co-developed-by: Random Co-Author <random@coauthor.example.org>
|
||||
Signed-off-by: Random Co-Author <random@coauthor.example.org>
|
||||
Signed-off-by: From Author <from@author.example.org>
|
||||
Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
|
||||
Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user