doc: align Italian translation
Translation for the following patches commit0ca0d55526("docs/core-api: Consistent code style") commit9912d0bb9d("docs: process: submitting-patches.rst: avoid using ReST :doc:`foo` markup") commit6349469a4f("Documentation/submitting-patches: Document RESEND tag on patches") commitdbbe7c962c("docs: networking: drop special stable handling") commit7f3f7bfbbe("docs: kernel-hacking: hacking.rst: avoid using ReST :doc:`foo` markup") commit6ab0493dfc("deprecated.rst: Include details on "no_hash_pointers" ") commit77167b966b("docs: submitting-patches: clarify the role of LKML ") Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Link: https://lore.kernel.org/r/20210731085513.11820-1-federico.vaga@vaga.pv.it Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Federico Vaga
Jonathan Corbet
parent
27f373cb5c
commit
191cf329f1
|
|
@ -42,15 +42,15 @@ nomi: EXPORT_SYMBOL_NS() ed EXPORT_SYMBOL_NS_GPL(). Queste macro richiedono un
|
|||
argomento aggiuntivo: lo spazio dei nomi.
|
||||
Tenete presente che per via dell'espansione delle macro questo argomento deve
|
||||
essere un simbolo di preprocessore. Per esempio per esportare il
|
||||
simbolo `usb_stor_suspend` nello spazio dei nomi `USB_STORAGE` usate::
|
||||
simbolo ``usb_stor_suspend`` nello spazio dei nomi ``USB_STORAGE`` usate::
|
||||
|
||||
EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE);
|
||||
|
||||
Di conseguenza, nella tabella dei simboli del kernel ci sarà una voce
|
||||
rappresentata dalla struttura `kernel_symbol` che avrà il campo
|
||||
`namespace` (spazio dei nomi) impostato. Un simbolo esportato senza uno spazio
|
||||
dei nomi avrà questo campo impostato a `NULL`. Non esiste uno spazio dei nomi
|
||||
di base. Il programma `modpost` e il codice in kernel/module.c usano lo spazio
|
||||
rappresentata dalla struttura ``kernel_symbol`` che avrà il campo
|
||||
``namespace`` (spazio dei nomi) impostato. Un simbolo esportato senza uno spazio
|
||||
dei nomi avrà questo campo impostato a ``NULL``. Non esiste uno spazio dei nomi
|
||||
di base. Il programma ``modpost`` e il codice in kernel/module.c usano lo spazio
|
||||
dei nomi, rispettivamente, durante la compilazione e durante il caricamento
|
||||
di un modulo.
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ ed EXPORT_SYMBOL_GPL() che non specificano esplicitamente uno spazio dei nomi.
|
|||
|
||||
Ci sono molti modi per specificare questo simbolo di preprocessore e il loro
|
||||
uso dipende dalle preferenze del manutentore di un sottosistema. La prima
|
||||
possibilità è quella di definire il simbolo nel `Makefile` del sottosistema.
|
||||
possibilità è quella di definire il simbolo nel ``Makefile`` del sottosistema.
|
||||
Per esempio per esportare tutti i simboli definiti in usb-common nello spazio
|
||||
dei nomi USB_COMMON, si può aggiungere la seguente linea in
|
||||
drivers/usb/common/Makefile::
|
||||
|
|
@ -97,7 +97,7 @@ USB_STORAGE usando la seguente dichiarazione::
|
|||
|
||||
MODULE_IMPORT_NS(USB_STORAGE);
|
||||
|
||||
Questo creerà un'etichetta `modinfo` per ogni spazio dei nomi
|
||||
Questo creerà un'etichetta ``modinfo`` per ogni spazio dei nomi
|
||||
importato. Un risvolto di questo fatto è che gli spazi dei
|
||||
nomi importati da un modulo possono essere ispezionati tramite
|
||||
modinfo::
|
||||
|
|
@ -116,7 +116,7 @@ mancanti.
|
|||
4. Caricare moduli che usano simboli provenienti da spazi dei nomi
|
||||
==================================================================
|
||||
|
||||
Quando un modulo viene caricato (per esempio usando `insmod`), il kernel
|
||||
Quando un modulo viene caricato (per esempio usando ``insmod``), il kernel
|
||||
verificherà la disponibilità di ogni simbolo usato e se lo spazio dei nomi
|
||||
che potrebbe contenerli è stato importato. Il comportamento di base del kernel
|
||||
è di rifiutarsi di caricare quei moduli che non importano tutti gli spazi dei
|
||||
|
|
@ -144,22 +144,22 @@ Lo scenario tipico di chi scrive un modulo potrebbe essere::
|
|||
|
||||
- scrivere codice che dipende da un simbolo appartenente ad uno spazio
|
||||
dei nomi non importato
|
||||
- eseguire `make`
|
||||
- eseguire ``make``
|
||||
- aver notato un avviso da modpost che parla di un'importazione
|
||||
mancante
|
||||
- eseguire `make nsdeps` per aggiungere import nel posto giusto
|
||||
- eseguire ``make nsdeps`` per aggiungere import nel posto giusto
|
||||
|
||||
Per i manutentori di sottosistemi che vogliono aggiungere uno spazio dei nomi,
|
||||
l'approccio è simile. Di nuovo, eseguendo `make nsdeps` aggiungerà le
|
||||
l'approccio è simile. Di nuovo, eseguendo ``make nsdeps`` aggiungerà le
|
||||
importazioni mancanti nei moduli inclusi nel kernel::
|
||||
|
||||
- spostare o aggiungere simboli ad uno spazio dei nomi (per esempio
|
||||
usando EXPORT_SYMBOL_NS())
|
||||
- eseguire `make` (preferibilmente con allmodconfig per coprire tutti
|
||||
- eseguire ``make`` (preferibilmente con allmodconfig per coprire tutti
|
||||
i moduli del kernel)
|
||||
- aver notato un avviso da modpost che parla di un'importazione
|
||||
mancante
|
||||
- eseguire `make nsdeps` per aggiungere import nel posto giusto
|
||||
- eseguire ``make nsdeps`` per aggiungere import nel posto giusto
|
||||
|
||||
Potete anche eseguire nsdeps per moduli esterni. Solitamente si usa così::
|
||||
|
||||
|
|
|
|||
|
|
@ -634,7 +634,7 @@ Definita in ``include/linux/export.h``
|
|||
|
||||
Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno
|
||||
spazio dei nomi. Lo spazio dei nomi è documentato in
|
||||
:doc:`../core-api/symbol-namespaces`
|
||||
Documentation/translations/it_IT/core-api/symbol-namespaces.rst.
|
||||
|
||||
:c:func:`EXPORT_SYMBOL_NS_GPL()`
|
||||
--------------------------------
|
||||
|
|
@ -643,7 +643,7 @@ Definita in ``include/linux/export.h``
|
|||
|
||||
Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare uno
|
||||
spazio dei nomi. Lo spazio dei nomi è documentato in
|
||||
:doc:`../core-api/symbol-namespaces`
|
||||
Documentation/translations/it_IT/core-api/symbol-namespaces.rst.
|
||||
|
||||
Procedure e convenzioni
|
||||
=======================
|
||||
|
|
|
|||
|
|
@ -183,9 +183,11 @@ di Linus:
|
|||
affrontare il giudizio di Linus, allora forse potrai usare "%px",
|
||||
assicurandosi anche di averne il permesso.
|
||||
|
||||
Infine, sappi che un cambio in favore di "%p" con hash `non verrà
|
||||
accettato
|
||||
<https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@mail.gmail.com/>`_.
|
||||
Potete disabilitare temporaneamente l'hashing di "%p" nel caso in cui questa
|
||||
funzionalità vi sia d'ostacolo durante una sessione di debug. Per farlo
|
||||
aggiungete l'opzione di debug "`no_hash_pointers
|
||||
<https://git.kernel.org/linus/5ead723a20e0447bc7db33dc3070b420e5f80aa6>`_" alla
|
||||
riga di comando del kernel.
|
||||
|
||||
Vettori a dimensione variabile (VLA)
|
||||
------------------------------------
|
||||
|
|
|
|||
|
|
@ -41,12 +41,6 @@ Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
|
|||
Procedura per sottomettere patch per i sorgenti -stable
|
||||
-------------------------------------------------------
|
||||
|
||||
- Se la patch contiene modifiche a dei file nelle cartelle net/ o drivers/net,
|
||||
allora seguite le linee guida descritte in
|
||||
:ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst <it_netdev-FAQ>`;
|
||||
ma solo dopo aver verificato al seguente indirizzo che la patch non sia
|
||||
già in coda:
|
||||
https://patchwork.kernel.org/bundle/netdev/stable/?state=*
|
||||
- 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>`.
|
||||
|
|
|
|||
|
|
@ -14,14 +14,15 @@ una certa familiarità col "sistema". Questo testo è una raccolta di
|
|||
suggerimenti che aumenteranno significativamente le probabilità di vedere le
|
||||
vostre patch accettate.
|
||||
|
||||
Questo documento contiene un vasto numero di suggerimenti concisi. Per
|
||||
maggiori dettagli su come funziona il processo di sviluppo del kernel leggete
|
||||
:doc:`development-process`.
|
||||
Leggete anche :doc:`submit-checklist` per una lista di punti da
|
||||
verificare prima di inviare del codice. Se state inviando un driver,
|
||||
allora leggete anche :doc:`submitting-drivers`; per delle patch
|
||||
Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori
|
||||
dettagli su come funziona il processo di sviluppo del kernel leggete
|
||||
Documentation/translations/it_IT/process/development-process.rst. Leggete anche
|
||||
Documentation/translations/it_IT/process/submit-checklist.rst per una lista di
|
||||
punti da verificare prima di inviare del codice. Se state inviando un driver,
|
||||
allora leggete anche
|
||||
Documentation/translations/it_IT/process/submitting-drivers.rst; per delle patch
|
||||
relative alle associazioni per Device Tree leggete
|
||||
:doc:`submitting-patches`.
|
||||
Documentation/translations/it_IT/process/submitting-patches.rst.
|
||||
|
||||
Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
|
||||
Se non siete pratici di ``git``, allora è bene che lo impariate;
|
||||
|
|
@ -193,7 +194,7 @@ ed integrate.
|
|||
---------------------------------------------
|
||||
|
||||
Controllate che la vostra patch non violi lo stile del codice, maggiori
|
||||
dettagli sono disponibili in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`.
|
||||
dettagli sono disponibili in Documentation/translations/it_IT/process/coding-style.rst.
|
||||
Non farlo porta semplicemente a una perdita di tempo da parte dei revisori e
|
||||
voi vedrete la vostra patch rifiutata, probabilmente senza nemmeno essere stata
|
||||
letta.
|
||||
|
|
@ -230,13 +231,13 @@ 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à.
|
||||
|
||||
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
|
||||
è proprio l'ultima spiaggia, il volume di email su questa lista fa si che
|
||||
diversi sviluppatori non la seguano. Guardate nel file MAINTAINERS per trovare
|
||||
la lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
|
||||
patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le
|
||||
liste di discussione che non sono interessate al vostro lavoro.
|
||||
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
|
||||
dovrebbe essere usata per inviare tutte le patch, ma il traffico è tale per cui
|
||||
diversi sviluppatori la trascurano. Guardate nel file MAINTAINERS per trovare la
|
||||
lista di discussione dedicata ad un sottosistema; probabilmente lì la vostra
|
||||
patch riceverà molta più attenzione. Tuttavia, per favore, non spammate le liste
|
||||
di discussione che non sono interessate al vostro lavoro.
|
||||
|
||||
Molte delle liste di discussione relative al kernel vengono ospitate su
|
||||
vger.kernel.org; potete trovare un loro elenco alla pagina
|
||||
|
|
@ -257,7 +258,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle
|
|||
distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
|
||||
in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
|
||||
lista di discussione pubblica. Leggete anche
|
||||
:doc:`/admin-guide/security-bugs`.
|
||||
Documentation/admin-guide/security-bugs.rst.
|
||||
|
||||
Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
|
||||
essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
|
||||
|
|
@ -266,12 +267,7 @@ essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
|
|||
|
||||
nella vostra patch, nell'area dedicata alle firme (notate, NON come destinatario
|
||||
delle e-mail). In aggiunta a questo file, dovreste leggere anche
|
||||
:ref:`Documentation/translations/it_IT/process/stable-kernel-rules.rst <it_stable_kernel_rules>`
|
||||
|
||||
Tuttavia, notate, che alcuni manutentori di sottosistema preferiscono avere
|
||||
l'ultima parola su quali patch dovrebbero essere aggiunte ai kernel stabili.
|
||||
La rete di manutentori, in particolare, non vorrebbe vedere i singoli
|
||||
sviluppatori aggiungere alle loro patch delle righe come quella sopracitata.
|
||||
Documentation/translations/it_IT/process/stable-kernel-rules.rst.
|
||||
|
||||
Se le modifiche hanno effetti sull'interfaccia con lo spazio utente, per favore
|
||||
inviate una patch per le pagine man ai manutentori di suddette pagine (elencati
|
||||
|
|
@ -330,7 +326,7 @@ così la possibilità che il vostro allegato-MIME venga accettato.
|
|||
Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
|
||||
potrebbe chiedervi di rinviarle come allegato MIME.
|
||||
|
||||
Leggete :doc:`/translations/it_IT/process/email-clients`
|
||||
Leggete Documentation/translations/it_IT/process/email-clients.rst
|
||||
per dei suggerimenti sulla configurazione del programmi di posta elettronica
|
||||
per l'invio di patch intatte.
|
||||
|
||||
|
|
@ -351,7 +347,7 @@ 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.
|
||||
|
||||
Leggete :doc:`/translations/it_IT/process/email-clients` per
|
||||
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.
|
||||
|
||||
|
|
@ -369,6 +365,16 @@ aver inviato le patch correttamente. Aspettate almeno una settimana prima di
|
|||
rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
|
||||
durante la finestra d'integrazione.
|
||||
|
||||
Potete anche rinviare la patch, o la serie di patch, dopo un paio di settimane
|
||||
aggiungendo la parola "RESEND" nel titolo::
|
||||
|
||||
[PATCH Vx RESEND] sub/sys: Condensed patch summary
|
||||
|
||||
Ma non aggiungete "RESEND" quando state sottomettendo una versione modificata
|
||||
della vostra patch, o serie di patch - "RESEND" si applica solo alla
|
||||
sottomissione di patch, o serie di patch, che non hanno subito modifiche
|
||||
dall'ultima volta che sono state inviate.
|
||||
|
||||
Aggiungete PATCH nell'oggetto
|
||||
-----------------------------
|
||||
|
||||
|
|
@ -795,8 +801,7 @@ Greg Kroah-Hartman, "Come scocciare un manutentore di un sottosistema"
|
|||
No!!!! Basta gigantesche bombe patch alle persone sulla lista linux-kernel@vger.kernel.org!
|
||||
<https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net>
|
||||
|
||||
Kernel Documentation/translations/it_IT/process/coding-style.rst:
|
||||
:ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`
|
||||
Kernel Documentation/translations/it_IT/process/coding-style.rst.
|
||||
|
||||
E-mail di Linus Torvalds sul formato canonico di una patch:
|
||||
<https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org>
|
||||
|
|
|
|||
Loading…
Reference in New Issue