doc:it_IT: align Italian documentation
Translation for the following patches commitdf05c0e949("Documentation: Raise the minimum supported version of LLVM to 11.0.0") commit333b11e541("Documentation: Add minimum pahole version") commit6d6a8d6a4e("docs: Update Sphinx requirements") commit76ae847497("Documentation: raise minimum supported version of GCC to 5.1") commit59c6a716b1("Documentation/process/maintainer-pgp-guide: Replace broken link to PGP path finder") commit85eafc63d0("docs: update file link location") commit869f496e1a("docs: process: submitting-patches: Clarify the Reported-by usage") commit6c5ccd24ff("Remove mentions of the Trivial Patch Monkey") commitaa9b5e0df2("Documentation/process: fix self reference") commitb96ff02ab2("Documentation/process: fix a cross reference") commit1f57bd42b7("docs: submitting-patches: make section about the Link: tag more explicit") commita9d85efb25("docs: use the lore redirector everywhere") commit31c9d7c829("Documentation/process: Add tip tree handbook") commit604370e106("Documentation/process: Add maintainer handbooks section") commitbf33a9d42d("docs: 5.Posting.rst: describe Fixes: and Link: tags") commitc04639a7d2("coding-style.rst: trivial: fix location of driver model macros") commitd5b421fe02("docs: Explain the desired position of function attributes") commit3577cdb23b("docs: deprecated.rst: Clarify open-coded arithmetic with literals") commitdb67eb748e("docs: discourage use of list tables") commit0e805b1186("docs: address some text issues with css/theme support") commit135707d376("docs: allow to pass extra DOCS_CSS themes via make") commitfe450eeb4e("Documentation: in_irq() cleanup") commit10855b45a4("docs: fix typo in Documentation/kernel-hacking/locking.rst") commitbc67f1c454("docs: futex: Fix kernel-doc references") commitabf36fe0be("docs: kernel-hacking: Remove inappropriate text") commitf35cf1a59e("Documentation: kernel-hacking: minor edits for style") commitf35cf1a59e("Documentation: kernel-hacking: minor edits for style") commit980c3799c5("Documentation: kernel-doc: Promote two chapter headings to page title") commite1be43d9b5("overflow: Implement size_t saturating arithmetic helpers") commit615f3eea0d("Documentation: add note block surrounding security patch note") commit587d39b260("Documentation: add link to stable release candidate tree") commit555d44932c("Documentation: update stable tree link") commit88d99e8701("Documentation: update stable review cycle documentation") commit0c603a5c70("Documentation/process: mention patch changelog in review process") commit6d5aa418b3("docs: submitting-patches: Fix crossref to 'The canonical patch format'") commitf1a693994b("Documentation/process: use scripts/get_maintainer.pl on patches") commit69ef0920bd("Docs: Add cpio requirement to changes.rst") commit5a5866c28b("Docs: Replace version by 'current' in changes.rst") commit9b5a7f4a2a("x86/configs: Add x86 debugging Kconfig fragment plus docs") commitf1a693994b("Documentation/process: use scripts/get_maintainer.pl on patches") commite8c07082a8("Kbuild: move to -std=gnu11") Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Link: https://lore.kernel.org/r/20220702210820.13118-1-federico.vaga@vaga.pv.it Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Federico Vaga
Jonathan Corbet
parent
5a491c9714
commit
da1d9caf95
|
|
@ -0,0 +1,11 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/devicetree/bindings/submitting-patches.rst
|
||||
|
||||
================================================
|
||||
Sottomettere patch per devicetree (DT) *binding*
|
||||
================================================
|
||||
|
||||
.. note:: to be translated
|
||||
|
|
@ -5,6 +5,7 @@
|
|||
|
||||
.. _it_kernel_doc:
|
||||
|
||||
=================================
|
||||
Scrivere i commenti in kernel-doc
|
||||
=================================
|
||||
|
||||
|
|
@ -469,6 +470,7 @@ Il titolo che segue ``DOC:`` funziona da intestazione all'interno del file
|
|||
sorgente, ma anche come identificatore per l'estrazione di questi commenti di
|
||||
documentazione. Quindi, il titolo dev'essere unico all'interno del file.
|
||||
|
||||
=======================================
|
||||
Includere i commenti di tipo kernel-doc
|
||||
=======================================
|
||||
|
||||
|
|
|
|||
|
|
@ -5,8 +5,9 @@
|
|||
|
||||
.. _it_sphinxdoc:
|
||||
|
||||
Introduzione
|
||||
============
|
||||
=============================================
|
||||
Usare Sphinx per la documentazione del kernel
|
||||
=============================================
|
||||
|
||||
Il kernel Linux usa `Sphinx`_ per la generazione della documentazione a partire
|
||||
dai file `reStructuredText`_ che si trovano nella cartella ``Documentation``.
|
||||
|
|
@ -158,6 +159,9 @@ Per poter passare ulteriori opzioni a Sphinx potete utilizzare la variabile
|
|||
make ``SPHINXOPTS``. Per esempio, se volete che Sphinx sia più verboso durante
|
||||
la generazione potete usare il seguente comando ``make SPHINXOPTS=-v htmldocs``.
|
||||
|
||||
Potete anche personalizzare l'ouptut html passando un livello aggiuntivo
|
||||
DOCS_CSS usando la rispettiva variabile d'ambiente ``DOCS_CSS``.
|
||||
|
||||
Potete eliminare la documentazione generata tramite il comando
|
||||
``make cleandocs``.
|
||||
|
||||
|
|
@ -276,11 +280,11 @@ incrociato quando questa ha una voce nell'indice. Se trovate degli usi di
|
|||
Tabelle a liste
|
||||
---------------
|
||||
|
||||
Raccomandiamo l'uso delle tabelle in formato lista (*list table*). Le tabelle
|
||||
in formato lista sono liste di liste. In confronto all'ASCII-art potrebbero
|
||||
non apparire di facile lettura nei file in formato testo. Il loro vantaggio è
|
||||
che sono facili da creare o modificare e che la differenza di una modifica è
|
||||
molto più significativa perché limitata alle modifiche del contenuto.
|
||||
Il formato ``list-table`` può essere utile per tutte quelle tabelle che non
|
||||
possono essere facilmente scritte usando il formato ASCII-art di Sphinx. Però,
|
||||
questo genere di tabelle sono illeggibili per chi legge direttamente i file di
|
||||
testo. Dunque, questo formato dovrebbe essere evitato senza forti argomenti che
|
||||
ne giustifichino l'uso.
|
||||
|
||||
La ``flat-table`` è anch'essa una lista di liste simile alle ``list-table``
|
||||
ma con delle funzionalità aggiuntive:
|
||||
|
|
|
|||
|
|
@ -129,8 +129,7 @@ eseguiti simultaneamente.
|
|||
.. warning::
|
||||
|
||||
Il nome 'tasklet' è ingannevole: non hanno niente a che fare
|
||||
con i 'processi' ('tasks'), e probabilmente hanno più a che vedere
|
||||
con qualche pessima vodka che Alexey Kuznetsov si fece a quel tempo.
|
||||
con i 'processi' ('tasks').
|
||||
|
||||
Potete determinate se siete in un softirq (o tasklet) utilizzando la
|
||||
macro :c:func:`in_softirq()` (``include/linux/preempt.h``).
|
||||
|
|
@ -308,7 +307,7 @@ esse copiano una quantità arbitraria di dati da e verso lo spazio utente.
|
|||
Al contrario di:c:func:`put_user()` e :c:func:`get_user()`, queste
|
||||
funzioni ritornano la quantità di dati copiati (0 è comunque un successo).
|
||||
|
||||
[Sì, questa stupida interfaccia mi imbarazza. La battaglia torna in auge anno
|
||||
[Sì, questa interfaccia mi imbarazza. La battaglia torna in auge anno
|
||||
dopo anno. --RR]
|
||||
|
||||
Le funzioni potrebbero dormire implicitamente. Queste non dovrebbero mai essere
|
||||
|
|
@ -679,9 +678,8 @@ tutti sulle spine: questo riflette cambiamenti fondamentati (eg. la funzione
|
|||
non può più essere chiamata con le funzioni attive, o fa controlli aggiuntivi,
|
||||
o non fa più controlli che venivano fatti in precedenza). Solitamente a questo
|
||||
s'accompagna un'adeguata e completa nota sulla lista di discussone
|
||||
linux-kernel; cercate negli archivi.
|
||||
Solitamente eseguire una semplice sostituzione su tutto un file rendere
|
||||
le cose **peggiori**.
|
||||
più adatta; cercate negli archivi. Solitamente eseguire una semplice
|
||||
sostituzione su tutto un file rendere le cose **peggiori**.
|
||||
|
||||
Inizializzazione dei campi d'una struttura
|
||||
------------------------------------------
|
||||
|
|
@ -759,14 +757,14 @@ Mettere le vostre cose nel kernel
|
|||
Al fine d'avere le vostre cose in ordine per l'inclusione ufficiale, o
|
||||
anche per avere patch pulite, c'è del lavoro amministrativo da fare:
|
||||
|
||||
- Trovare di chi è lo stagno in cui state pisciando. Guardare in cima
|
||||
- Trovare chi è responsabile del codice che state modificando. Guardare in cima
|
||||
ai file sorgenti, all'interno del file ``MAINTAINERS``, ed alla fine
|
||||
di tutti nel file ``CREDITS``. Dovreste coordinarvi con queste persone
|
||||
per evitare di duplicare gli sforzi, o provare qualcosa che è già stato
|
||||
rigettato.
|
||||
|
||||
Assicuratevi di mettere il vostro nome ed indirizzo email in cima a
|
||||
tutti i file che create o che mangeggiate significativamente. Questo è
|
||||
tutti i file che create o che maneggiate significativamente. Questo è
|
||||
il primo posto dove le persone guarderanno quando troveranno un baco,
|
||||
o quando **loro** vorranno fare una modifica.
|
||||
|
||||
|
|
@ -787,12 +785,12 @@ anche per avere patch pulite, c'è del lavoro amministrativo da fare:
|
|||
"obj-$(CONFIG_xxx) += xxx.o". La sintassi è documentata nel file
|
||||
``Documentation/kbuild/makefiles.rst``.
|
||||
|
||||
- Aggiungete voi stessi in ``CREDITS`` se avete fatto qualcosa di notevole,
|
||||
solitamente qualcosa che supera il singolo file (comunque il vostro nome
|
||||
dovrebbe essere all'inizio dei file sorgenti). ``MAINTAINERS`` significa
|
||||
- Aggiungete voi stessi in ``CREDITS`` se credete di aver fatto qualcosa di
|
||||
notevole, solitamente qualcosa che supera il singolo file (comunque il vostro
|
||||
nome dovrebbe essere all'inizio dei file sorgenti). ``MAINTAINERS`` significa
|
||||
che volete essere consultati quando vengono fatte delle modifiche ad un
|
||||
sottosistema, e quando ci sono dei bachi; questo implica molto di più
|
||||
di un semplice impegno su una parte del codice.
|
||||
sottosistema, e quando ci sono dei bachi; questo implica molto di più di un
|
||||
semplice impegno su una parte del codice.
|
||||
|
||||
- Infine, non dimenticatevi di leggere
|
||||
``Documentation/process/submitting-patches.rst``.
|
||||
|
|
|
|||
|
|
@ -102,16 +102,11 @@ che non esistano.
|
|||
Sincronizzazione nel kernel Linux
|
||||
=================================
|
||||
|
||||
Se posso darvi un suggerimento: non dormite mai con qualcuno più pazzo di
|
||||
voi. Ma se dovessi darvi un suggerimento sulla sincronizzazione:
|
||||
**mantenetela semplice**.
|
||||
Se dovessi darvi un suggerimento sulla sincronizzazione: **mantenetela
|
||||
semplice**.
|
||||
|
||||
Siate riluttanti nell'introduzione di nuovi *lock*.
|
||||
|
||||
Abbastanza strano, quest'ultimo è l'esatto opposto del mio suggerimento
|
||||
su quando **avete** dormito con qualcuno più pazzo di voi. E dovreste
|
||||
pensare a prendervi un cane bello grande.
|
||||
|
||||
I due principali tipi di *lock* nel kernel: spinlock e mutex
|
||||
------------------------------------------------------------
|
||||
|
||||
|
|
@ -316,7 +311,7 @@ Pete Zaitcev ci offre il seguente riassunto:
|
|||
|
||||
- Se siete in un contesto utente (una qualsiasi chiamata di sistema)
|
||||
e volete sincronizzarvi con altri processi, usate i mutex. Potete trattenere
|
||||
il mutex e dormire (``copy_from_user*(`` o ``kmalloc(x,GFP_KERNEL)``).
|
||||
il mutex e dormire (``copy_from_user(`` o ``kmalloc(x,GFP_KERNEL)``).
|
||||
|
||||
- Altrimenti (== i dati possono essere manipolati da un'interruzione) usate
|
||||
spin_lock_irqsave() e spin_unlock_irqrestore().
|
||||
|
|
@ -979,9 +974,6 @@ fallisce nel trovare quello che vuole, quindi rilascia il *lock* di lettura,
|
|||
trattiene un *lock* di scrittura ed inserisce un oggetto; questo genere di
|
||||
codice presenta una corsa critica.
|
||||
|
||||
Se non riuscite a capire il perché, per favore state alla larga dal mio
|
||||
codice.
|
||||
|
||||
corsa fra temporizzatori: un passatempo del kernel
|
||||
--------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/process/botching-up-ioctls.rst
|
||||
|
||||
.. _it_configuregit:
|
||||
|
||||
Configurare Git
|
||||
===============
|
||||
|
||||
.. note:: To be translated
|
||||
|
|
@ -168,14 +168,15 @@ in questa ricerca:
|
|||
|
||||
.../scripts/get_maintainer.pl
|
||||
|
||||
Se questo script viene eseguito con l'opzione "-f" ritornerà il
|
||||
manutentore(i) attuale per un dato file o cartella. Se viene passata una
|
||||
patch sulla linea di comando, lo script elencherà i manutentori che
|
||||
dovrebbero riceverne una copia. Ci sono svariate opzioni che regolano
|
||||
quanto a fondo get_maintainer.pl debba cercare i manutentori;
|
||||
siate quindi prudenti nell'utilizzare le opzioni più aggressive poiché
|
||||
potreste finire per includere sviluppatori che non hanno un vero interesse
|
||||
per il codice che state modificando.
|
||||
Se questo script viene eseguito con l'opzione "-f" ritornerà il manutentore(i)
|
||||
attuale per un dato file o cartella. Se viene passata una patch sulla linea di
|
||||
comando, lo script elencherà i manutentori che dovrebbero riceverne una copia.
|
||||
Questo è la maniera raccomandata (non quella con "-f") per ottenere la lista di
|
||||
persone da aggiungere a Cc per le vostre patch. Ci sono svariate opzioni che
|
||||
regolano quanto a fondo get_maintainer.pl debba cercare i manutentori; siate
|
||||
quindi prudenti nell'utilizzare le opzioni più aggressive poiché potreste finire
|
||||
per includere sviluppatori che non hanno un vero interesse per il codice che
|
||||
state modificando.
|
||||
|
||||
Se tutto ciò dovesse fallire, parlare con Andrew Morton potrebbe essere
|
||||
un modo efficace per capire chi è il manutentore di un dato pezzo di codice.
|
||||
|
|
|
|||
|
|
@ -213,13 +213,28 @@ irrilevanti (quelli generati dal processo di generazione, per esempio, o i file
|
|||
di backup del vostro editor). Il file "dontdiff" nella cartella Documentation
|
||||
potrà esservi d'aiuto su questo punto; passatelo a diff con l'opzione "-X".
|
||||
|
||||
Le etichette sopra menzionante sono usate per descrivere come i vari
|
||||
sviluppatori sono stati associati allo sviluppo di una patch. Sono descritte
|
||||
in dettaglio nel documento :ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`;
|
||||
quello che segue è un breve riassunto. Ognuna di queste righe ha il seguente
|
||||
formato:
|
||||
Le etichette sopracitate danno un'idea di come una patch prende vita e sono
|
||||
descritte nel dettaglio nel documento
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
|
||||
Qui di seguito un breve riassunto.
|
||||
|
||||
::
|
||||
Un'etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch::
|
||||
|
||||
Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
|
||||
|
||||
Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti
|
||||
maggiori informazioni, per esempio un rapporto circa il baco risolto dalla
|
||||
patch, oppure un documento con le specifiche 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'
|
||||
|
||||
Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo
|
||||
sviluppo della patch. Tutte queste etichette seguono il formato::
|
||||
|
||||
tag: Full Name <email address> optional-other-stuff
|
||||
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@ Requisiti minimi per compilare il kernel
|
|||
Introduzione
|
||||
============
|
||||
|
||||
Questo documento fornisce una lista dei software necessari per eseguire i
|
||||
kernel 4.x.
|
||||
Questo documento fornisce una lista dei software necessari per eseguire questa
|
||||
versione del kernel.
|
||||
|
||||
Questo documento è basato sul file "Changes" del kernel 2.0.x e quindi le
|
||||
persone che lo scrissero meritano credito (Jared Mauch, Axel Boldt,
|
||||
|
|
@ -32,12 +32,13 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
|
|||
====================== ================= ========================================
|
||||
Programma Versione minima Comando per verificare la versione
|
||||
====================== ================= ========================================
|
||||
GNU C 4.9 gcc --version
|
||||
Clang/LLVM (optional) 10.0.1 clang --version
|
||||
GNU C 5.1 gcc --version
|
||||
Clang/LLVM (optional) 11.0.0 clang --version
|
||||
GNU make 3.81 make --version
|
||||
binutils 2.23 ld -v
|
||||
flex 2.5.35 flex --version
|
||||
bison 2.0 bison --version
|
||||
pahole 1.16 pahole --version
|
||||
util-linux 2.10o fdformat --version
|
||||
kmod 13 depmod -V
|
||||
e2fsprogs 1.41.4 e2fsck -V
|
||||
|
|
@ -58,6 +59,7 @@ iptables 1.4.2 iptables -V
|
|||
openssl & libcrypto 1.0.0 openssl version
|
||||
bc 1.06.95 bc --version
|
||||
Sphinx\ [#f1]_ 1.7 sphinx-build --version
|
||||
cpio any cpio --version
|
||||
====================== ================= ========================================
|
||||
|
||||
.. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel
|
||||
|
|
@ -111,6 +113,16 @@ Bison
|
|||
Dalla versione 4.16, il sistema di compilazione, durante l'esecuzione, genera
|
||||
un parsificatore. Questo richiede bison 2.0 o successivo.
|
||||
|
||||
pahole
|
||||
------
|
||||
|
||||
Dalla versione 5.2, quando viene impostato CONFIG_DEBUG_INFO_BTF, il sistema di
|
||||
compilazione genera BTF (BPF Type Format) a partire da DWARF per vmlinux. Più
|
||||
tardi anche per i moduli. Questo richiede pahole v1.16 o successivo.
|
||||
|
||||
A seconda della distribuzione, lo si può trovare nei pacchetti 'dwarves' o
|
||||
'pahole'. Oppure lo si può trovare qui: https://fedorapeople.org/~acme/dwarves/.
|
||||
|
||||
Perl
|
||||
----
|
||||
|
||||
|
|
@ -455,6 +467,11 @@ mcelog
|
|||
|
||||
- <http://www.mcelog.org/>
|
||||
|
||||
cpio
|
||||
----
|
||||
|
||||
- <https://www.gnu.org/software/cpio/>
|
||||
|
||||
Rete
|
||||
****
|
||||
|
||||
|
|
|
|||
|
|
@ -466,14 +466,52 @@ la riga della parentesi graffa di chiusura. Ad esempio:
|
|||
}
|
||||
EXPORT_SYMBOL(system_is_up);
|
||||
|
||||
6.1) Prototipi di funzione
|
||||
**************************
|
||||
|
||||
Nei prototipi di funzione, includete i nomi dei parametri e i loro tipi.
|
||||
Nonostante questo non sia richiesto dal linguaggio C, in Linux viene preferito
|
||||
perché è un modo semplice per aggiungere informazioni importanti per il
|
||||
lettore.
|
||||
|
||||
Non usate la parola chiave ``extern`` coi prototipi di funzione perché
|
||||
Non usate la parola chiave ``extern`` con le dichiarazioni di funzione perché
|
||||
rende le righe più lunghe e non è strettamente necessario.
|
||||
|
||||
Quando scrivete i prototipi di funzione mantenete `l'ordine degli elementi <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_.
|
||||
|
||||
Prendiamo questa dichiarazione di funzione come esempio::
|
||||
|
||||
__init void * __must_check action(enum magic value, size_t size, u8 count,
|
||||
char *fmt, ...) __printf(4, 5) __malloc;
|
||||
|
||||
L'ordine suggerito per gli elementi di un prototipo di funzione è il seguente:
|
||||
|
||||
- classe d'archiviazione (in questo caso ``static __always_inline``. Da notare
|
||||
che ``__always_inline`` è tecnicamente un attributo ma che viene trattato come
|
||||
``inline``)
|
||||
- attributi della classe di archiviazione (in questo caso ``__init``, in altre
|
||||
parole la sezione, ma anche cose tipo ``__cold``)
|
||||
- il tipo di ritorno (in questo caso, ``void *``)
|
||||
- attributi per il valore di ritorno (in questo caso, ``__must_check``)
|
||||
- il nome della funzione (in questo caso, ``action``)
|
||||
- i parametri della funzione(in questo caso,
|
||||
``(enum magic value, size_t size, u8 count, char *fmt, ...)``,
|
||||
da notare che va messo anche il nome del parametro)
|
||||
- attributi dei parametri (in questo caso, ``__printf(4, 5)``)
|
||||
- attributi per il comportamento della funzione (in questo caso, ``__malloc_``)
|
||||
|
||||
Notate che per la **definizione** di una funzione (il altre parole il corpo
|
||||
della funzione), il compilatore non permette di usare gli attributi per i
|
||||
parametri dopo i parametri. In questi casi, devono essere messi dopo gli
|
||||
attributi della classe d'archiviazione (notate che la posizione di
|
||||
``__printf(4,5)`` cambia rispetto alla **dichiarazione**)::
|
||||
|
||||
static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value,
|
||||
size_t size, u8 count, char *fmt, ...) __malloc
|
||||
{
|
||||
...
|
||||
}*)**``)**``)``)``*)``)``)``)``*``)``)``)*)
|
||||
|
||||
7) Centralizzare il ritorno delle funzioni
|
||||
------------------------------------------
|
||||
|
||||
|
|
@ -855,7 +893,7 @@ I messaggi del kernel non devono terminare con un punto fermo.
|
|||
Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo
|
||||
dovrebbero essere evitati.
|
||||
|
||||
Ci sono alcune macro per la diagnostica in <linux/device.h> che dovreste
|
||||
Ci sono alcune macro per la diagnostica in <linux/dev_printk.h> che dovreste
|
||||
usare per assicurarvi che i messaggi vengano associati correttamente ai
|
||||
dispositivi e ai driver, e che siano etichettati correttamente: dev_err(),
|
||||
dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad
|
||||
|
|
|
|||
|
|
@ -69,8 +69,8 @@ dovrebbero essere fatto negli argomenti di funzioni di allocazione di memoria
|
|||
piccoli di quelli che il chiamante si aspettava. L'uso di questo modo di
|
||||
allocare può portare ad un overflow della memoria di heap e altri
|
||||
malfunzionamenti. (Si fa eccezione per valori numerici per i quali il
|
||||
compilatore può generare avvisi circa un potenziale overflow. Tuttavia usare
|
||||
i valori numerici come suggerito di seguito è innocuo).
|
||||
compilatore può generare avvisi circa un potenziale overflow. Tuttavia, anche in
|
||||
questi casi è preferibile riscrivere il codice come suggerito di seguito).
|
||||
|
||||
Per esempio, non usate ``count * size`` come argomento::
|
||||
|
||||
|
|
@ -80,6 +80,9 @@ Al suo posto, si dovrebbe usare l'allocatore a due argomenti::
|
|||
|
||||
foo = kmalloc_array(count, size, GFP_KERNEL);
|
||||
|
||||
Nello specifico, kmalloc() può essere sostituta da kmalloc_array(), e kzalloc()
|
||||
da kcalloc().
|
||||
|
||||
Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate
|
||||
le funzioni del tipo *saturate-on-overflow*::
|
||||
|
||||
|
|
@ -100,9 +103,20 @@ Invece, usate la seguente funzione::
|
|||
invitati a riorganizzare il vostro codice usando il
|
||||
`flexible array member <#zero-length-and-one-element-arrays>`_.
|
||||
|
||||
Per maggiori dettagli fate riferimento a array_size(),
|
||||
array3_size(), e struct_size(), così come la famiglia di
|
||||
funzioni check_add_overflow() e check_mul_overflow().
|
||||
Per altri calcoli, usate le funzioni size_mul(), size_add(), e size_sub(). Per
|
||||
esempio, al posto di::
|
||||
|
||||
foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL);
|
||||
|
||||
dovreste scrivere:
|
||||
|
||||
foo = krealloc(size_add(current_size,
|
||||
size_mul(chunk_size,
|
||||
size_sub(count, 3))), GFP_KERNEL);
|
||||
|
||||
Per maggiori dettagli fate riferimento a array3_size() e flex_array_size(), ma
|
||||
anche le funzioni della famiglia check_mul_overflow(), check_add_overflow(),
|
||||
check_sub_overflow(), e check_shl_overflow().
|
||||
|
||||
simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull()
|
||||
----------------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -46,6 +46,7 @@ degli sviluppatori:
|
|||
stable-kernel-rules
|
||||
submit-checklist
|
||||
kernel-docs
|
||||
maintainers
|
||||
|
||||
Ed infine, qui ci sono alcune guide più tecniche che son state messe qua solo
|
||||
perché non si è trovato un posto migliore.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,24 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
: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
|
||||
=============================================================================
|
||||
|
||||
Lo scopo di questo documento è quello di fornire informazioni sul processo di
|
||||
sviluppo dedicate ai sottosistemi che vanno ad integrare quelle più generali
|
||||
descritte in :ref:`Documentation/translations/it_IT/process
|
||||
<it_development_process_main>`.
|
||||
|
||||
Indice:
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
:maxdepth: 2
|
||||
|
||||
maintainer-tip
|
||||
|
|
@ -931,12 +931,11 @@ che avete nel vostro portachiavi::
|
|||
uid [ unknown] Linus Torvalds <torvalds@kernel.org>
|
||||
sub rsa2048 2011-09-20 [E]
|
||||
|
||||
Poi, aprite il `PGP pathfinder`_. Nel campo "From", incollate l'impronta
|
||||
digitale della chiave di Linus Torvalds che si vede nell'output qui sopra.
|
||||
Nel campo "to", incollate il key-id della chiave sconosciuta che avete
|
||||
trovato con ``gpg --search``, e poi verificare il risultato:
|
||||
|
||||
- `Finding paths to Linus`_
|
||||
Poi, cercate un percorso affidabile da Linux Torvalds alla chiave che avete
|
||||
trovato con ``gpg --search`` usando la chiave sconosciuta.Per farlo potete usare
|
||||
diversi strumenti come https://github.com/mricon/wotmate,
|
||||
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, e
|
||||
https://the.earth.li/~noodles/pathfind.html.
|
||||
|
||||
Se trovate un paio di percorsi affidabili è un buon segno circa la validità
|
||||
della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver::
|
||||
|
|
@ -948,6 +947,3 @@ fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non
|
|||
sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`).
|
||||
Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso
|
||||
miglioramento rispetto alla cieca fiducia nei keyserver.
|
||||
|
||||
.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
|
||||
.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/process/maintainer-tip.rst
|
||||
|
||||
Il tascabile dei sorgenti tip
|
||||
=============================
|
||||
|
||||
.. note:: To be translated
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
:Original: Documentation/process/maintainers.rst
|
||||
|
||||
Lista dei manutentori e come inviare modifiche al kernel
|
||||
========================================================
|
||||
|
||||
Questa pagina non verrà tradotta. Fate riferimento alla versione originale in
|
||||
inglese.
|
||||
|
||||
.. note:: La pagina originale usa una direttiva speciale per integrare il file
|
||||
`MAINTAINERS` in sphinx. La parte di quel documento che si potrebbe
|
||||
tradurre contiene comunque informazioni già presenti in
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst
|
||||
<it_submittingpatches>`.
|
||||
|
|
@ -41,10 +41,10 @@ Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
|
|||
Procedura per sottomettere patch per i sorgenti -stable
|
||||
-------------------------------------------------------
|
||||
|
||||
- Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo
|
||||
di revisione -stable, ma dovrebbe seguire le procedure descritte in
|
||||
:ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.
|
||||
|
||||
.. note::
|
||||
Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo
|
||||
di revisione -stable, ma dovrebbe seguire le procedure descritte in
|
||||
:ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.
|
||||
|
||||
Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
|
||||
------------------------------------------------------------------------
|
||||
|
|
@ -90,9 +90,9 @@ L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
|
|||
dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
|
||||
incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
|
||||
fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
|
||||
particolarmente utile se la patch ha bisogno di qualche modifica per essere
|
||||
applicata ad un kernel più vecchio (per esempio, perché nel frattempo l'API è
|
||||
cambiata).
|
||||
particolarmente utile se una patch dev'essere riportata su una versione
|
||||
precedente (per esempio la patch richiede modifiche a causa di cambiamenti di
|
||||
API).
|
||||
|
||||
Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
|
||||
sorgenti principali (per esempio perché è stato necessario un lavoro di
|
||||
|
|
@ -167,9 +167,18 @@ Ciclo di una revisione
|
|||
della lista linux-kernel obietta la bontà della patch, sollevando problemi
|
||||
che i manutentori ed i membri non avevano compreso, allora la patch verrà
|
||||
rimossa dalla coda.
|
||||
- Alla fine del ciclo di revisione tutte le patch che hanno ricevuto l'ACK
|
||||
verranno aggiunte per il prossimo rilascio -stable, e successivamente
|
||||
questo nuovo rilascio verrà fatto.
|
||||
- Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
|
||||
un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
|
||||
dai testatori.
|
||||
- Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
|
||||
importanti, alcune patch potrebbero essere modificate o essere scartate,
|
||||
oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
|
||||
nuove -rc e così via finché non si ritiene che non vi siano più problemi.
|
||||
- Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
|
||||
con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
|
||||
commit rilascio.
|
||||
- Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
|
||||
patch che erano in coda e sono state verificate.
|
||||
- Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
|
||||
dalla squadra per la sicurezza del kernel, e non passerà per il normale
|
||||
ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
|
||||
|
|
@ -186,8 +195,19 @@ Sorgenti
|
|||
- Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
|
||||
trovato in rami distinti per versione al seguente indirizzo:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
|
||||
- I rilasci candidati di tutti i kernel stabili possono essere trovati al
|
||||
seguente indirizzo:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
|
||||
|
||||
|
||||
.. warning::
|
||||
I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
|
||||
subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
|
||||
Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
|
||||
sistema di CI)
|
||||
|
||||
Comitato per la revisione
|
||||
-------------------------
|
||||
|
|
|
|||
|
|
@ -26,6 +26,10 @@ Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
|
|||
Se non siete pratici di ``git``, allora è bene che lo impariate;
|
||||
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>`
|
||||
|
||||
Ottenere i sorgenti attuali
|
||||
---------------------------
|
||||
|
||||
|
|
@ -82,11 +86,11 @@ comporti come descritto.
|
|||
|
||||
I manutentori vi saranno grati se scrivete la descrizione della patch in un
|
||||
formato che sia compatibile con il gestore dei sorgenti usato dal kernel,
|
||||
``git``, come un "commit log". Leggete :ref:`it_explicit_in_reply_to`.
|
||||
``git``, come un "commit log". Leggete :ref:`it_the_canonical_patch_format`.
|
||||
|
||||
Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
|
||||
essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
|
||||
divisa. Leggete :ref:`split_changes`.
|
||||
divisa. Leggete :ref:`it_split_changes`.
|
||||
|
||||
Quando inviate o rinviate una patch o una serie, includete la descrizione
|
||||
completa delle modifiche e la loro giustificazione. Non limitatevi a dire che
|
||||
|
|
@ -102,17 +106,28 @@ do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed
|
|||
xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo
|
||||
comportamento.
|
||||
|
||||
Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo
|
||||
il suo numero o il suo URL. Se la patch è la conseguenza di una discussione
|
||||
su una lista di discussione, allora fornite l'URL all'archivio di quella
|
||||
discussione; usate i collegamenti a https://lore.kernel.org/ con il
|
||||
``Message-Id``, in questo modo vi assicurerete che il collegamento non diventi
|
||||
invalido nel tempo.
|
||||
Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno
|
||||
riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
|
||||
riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere
|
||||
quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
|
||||
o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
|
||||
riferimento ad una discussione precedentemente avvenuta su una lista di
|
||||
discussione, o qualcosa di documentato sul web, da cui poi è nata la patch in
|
||||
questione.
|
||||
|
||||
Tuttavia, cercate di rendere la vostra spiegazione comprensibile anche senza
|
||||
far riferimento a fonti esterne. In aggiunta ai collegamenti a bachi e liste
|
||||
di discussione, riassumente i punti più importanti della discussione che hanno
|
||||
portato alla creazione della patch.
|
||||
Quando volete fare riferimento ad una lista di discussione, preferite il
|
||||
servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
|
||||
sufficiente usare il campo ``Message-Id``, presente nell'intestazione del
|
||||
messaggio, senza parentesi angolari. Per esempio::
|
||||
|
||||
Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
|
||||
|
||||
Prima d'inviare il messaggio ricordatevi di verificare che il collegamento così
|
||||
creato funzioni e che indirizzi verso il messaggio desiderato.
|
||||
|
||||
Tuttavia, provate comunque a dare una spiegazione comprensibile anche senza
|
||||
accedere alle fonti esterne. Inoltre, riassumente i punti più salienti che hanno
|
||||
condotto all'invio della patch.
|
||||
|
||||
Se volete far riferimento a uno specifico commit, non usate solo
|
||||
l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
|
||||
|
|
@ -224,10 +239,11 @@ nella vostra patch.
|
|||
|
||||
Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi
|
||||
interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia
|
||||
delle revisioni per scoprire chi si occupa del codice. Lo script
|
||||
scripts/get_maintainer.pl può esservi d'aiuto. Se non riuscite a trovare un
|
||||
manutentore per il sottosistema su cui state lavorando, allora Andrew Morton
|
||||
(akpm@linux-foundation.org) sarà la vostra ultima possibilità.
|
||||
delle revisioni per scoprire chi si occupa del codice. Lo script
|
||||
scripts/get_maintainer.pl può esservi d'aiuto (passategli il percorso alle
|
||||
vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su
|
||||
cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la
|
||||
vostra ultima possibilità.
|
||||
|
||||
Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la
|
||||
vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
|
||||
|
|
@ -322,14 +338,19 @@ cosa stia accadendo.
|
|||
|
||||
Assicuratevi di dire ai revisori quali cambiamenti state facendo e di
|
||||
ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
|
||||
richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche
|
||||
in questo caso, rispondete con educazione e concentratevi sul problema che
|
||||
hanno evidenziato.
|
||||
richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche in
|
||||
questo caso, rispondete con educazione e concentratevi sul problema che hanno
|
||||
evidenziato. Quando inviate una version successiva ricordatevi di aggiungere un
|
||||
``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando
|
||||
le differenze rispetto a sottomissioni precedenti (vedere
|
||||
:ref:`it_the_canonical_patch_format`).
|
||||
|
||||
Leggete Documentation/translations/it_IT/process/email-clients.rst per
|
||||
le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare
|
||||
sulle liste di discussione.
|
||||
|
||||
.. _it_resend_reminders:
|
||||
|
||||
Non scoraggiatevi - o impazientitevi
|
||||
------------------------------------
|
||||
|
||||
|
|
@ -502,7 +523,8 @@ 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.
|
||||
permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va
|
||||
usata per i bachi, dunque non usatela per richieste di nuove funzionalità.
|
||||
|
||||
L'etichetta Tested-by: indica che la patch è stata verificata con successo
|
||||
(su un qualche sistema) dalla persona citata. Questa etichetta informa i
|
||||
|
|
@ -572,6 +594,8 @@ 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.
|
||||
|
||||
.. _it_the_canonical_patch_format:
|
||||
|
||||
Il formato canonico delle patch
|
||||
-------------------------------
|
||||
|
||||
|
|
@ -717,6 +741,8 @@ messe correttamente oltre la riga.::
|
|||
|
||||
Maggiori dettagli sul formato delle patch nei riferimenti qui di seguito.
|
||||
|
||||
.. _it_backtraces:
|
||||
|
||||
Aggiungere i *backtrace* nei messaggi di commit
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue