Commit b67aa4ef authored by Federico Vaga's avatar Federico Vaga Committed by Jonathan Corbet
Browse files

doc:it_IT: align Italian translation 



Translation for the following patches:

commit c4f4af40 ("docs: Add documentation for Symbol Namespaces")
commit 36bc683d ("kernel-doc: rename the kernel-doc directive 'functions' to 'identifiers'")
commit a035d552 ("Makefile: Globally enable fall-through warning")
commit b9918bdc ("Documentation/process: Add fallthrough pseudo-keyword")
commit 58ad30cf ("docs: fix reference to core-api/namespaces.rst")
commit fb0e0ffe ("Documentation: bring process docs up to date")
commit 7af51678 ("docs: deprecated.rst: Add BUG()-family")
commit 7929b983 ("docs: Remove :c:func: from process/deprecated.rst")
commit 76136e02 ("docs: deprecated.rst: Clean up fall-through details")
commit d8401f50 ("docs: deprecated.rst: Add %p to the list")
commit b1735296 ("docs: locking: Drop :c:func: throughout")
commit 6adb7755 ("docs: locking: Add 'need' to hardirq section")

Signed-off-by: default avatarFederico Vaga <federico.vaga@vaga.pv.it>
Link: https://lore.kernel.org/r/20200430222037.4480-1-federico.vaga@vaga.pv.it


Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 16a398d1

Documentation/translations/it_IT/doc-guide/kernel-doc.rst

+16 −9
Original line number Original line Diff line number Diff line
@@ -515,6 +515,22 @@ internal: *[source-pattern ...]* 
    .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c

    .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c

       :internal:

       :internal:





identifiers: *[ function/type ...]*

  Include la documentazione per ogni *function* e *type*  in *source*.

  Se non vengono esplicitamente specificate le funzioni da includere, allora

  verranno incluse tutte quelle disponibili in *source*.



  Esempi::



    .. kernel-doc:: lib/bitmap.c

       :identifiers: bitmap_parselist bitmap_parselist_user



    .. kernel-doc:: lib/idr.c

       :identifiers:



functions: *[ function ...]*

  Questo è uno pseudonimo, deprecato, per la direttiva 'identifiers'.



doc: *title*

doc: *title*

  Include la documentazione del paragrafo ``DOC:`` identificato dal titolo

  Include la documentazione del paragrafo ``DOC:`` identificato dal titolo

  (*title*) all'interno del file sorgente (*source*). Gli spazi in *title* sono

  (*title*) all'interno del file sorgente (*source*). Gli spazi in *title* sono
@@ -528,15 +544,6 @@ doc: *title* 
    .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c

    .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c

       :doc: High Definition Audio over HDMI and Display Port

       :doc: High Definition Audio over HDMI and Display Port





functions: *function* *[...]*

  Dal file sorgente (*source*) include la documentazione per le funzioni

  elencate (*function*).



  Esempio::



    .. kernel-doc:: lib/bitmap.c

       :functions: bitmap_parselist bitmap_parselist_user



Senza alcuna opzione, la direttiva kernel-doc include tutti i commenti di

Senza alcuna opzione, la direttiva kernel-doc include tutti i commenti di

documentazione presenti nel file sorgente (*source*).

documentazione presenti nel file sorgente (*source*).

Documentation/translations/it_IT/kernel-hacking/hacking.rst

+18 −0
Original line number Original line Diff line number Diff line
@@ -627,6 +627,24 @@ Alcuni manutentori e sviluppatori potrebbero comunque richiedere 
:c:func:`EXPORT_SYMBOL_GPL()` quando si aggiungono nuove funzionalità o

:c:func:`EXPORT_SYMBOL_GPL()` quando si aggiungono nuove funzionalità o

interfacce.

interfacce.





:c:func:`EXPORT_SYMBOL_NS()`

----------------------------



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`



:c:func:`EXPORT_SYMBOL_NS_GPL()`

--------------------------------



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`



Procedure e convenzioni

Procedure e convenzioni

=======================

=======================

Documentation/translations/it_IT/kernel-hacking/locking.rst

+86 −86

File changed.

Preview size limit exceeded, changes collapsed.

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

+49 −46
Original line number Original line Diff line number Diff line
@@ -23,18 +23,18 @@ ogni due o tre mesi viene effettuata un rilascio importante del kernel. 
I rilasci più recenti sono stati:

I rilasci più recenti sono stati:





	======  =================

	======  =================

	4.11	Aprile 30, 2017

	5.0     3 marzo, 2019

	4.12	Luglio 2, 2017

	5.1     5 maggio, 2019

	4.13	Settembre 3, 2017

	5.2     7 luglio, 2019

	4.14	Novembre 12, 2017

	5.3     15 settembre, 2019

	4.15	Gennaio 28, 2018

	5.4     24 novembre, 2019

	4.16	Aprile 1, 2018

	5.5     6 gennaio, 2020

	======  =================

	======  =================





Ciascun rilascio 4.x è un importante rilascio del kernel con nuove

Ciascun rilascio 5.x è un importante rilascio del kernel con nuove

funzionalità, modifiche interne dell'API, e molto altro.  Un tipico

funzionalità, modifiche interne dell'API, e molto altro.  Un tipico

rilascio 4.x contiene quasi 13,000 gruppi di modifiche con ulteriori

rilascio contiene quasi 13,000 gruppi di modifiche con ulteriori

modifiche a parecchie migliaia di linee di codice.  La 4.x. è pertanto la

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

linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema

di sviluppo continuo che integra costantemente nuove importanti modifiche.

di sviluppo continuo che integra costantemente nuove importanti modifiche.
@@ -55,8 +55,8 @@ verrà descritto dettagliatamente più avanti). 
La finestra di inclusione resta attiva approssimativamente per due settimane.

La finestra di inclusione resta attiva approssimativamente per due settimane.

Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è

Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è

chiusa e rilascerà il primo degli "rc" del kernel.

chiusa e rilascerà il primo degli "rc" del kernel.

Per il kernel che è destinato ad essere 2.6.40, per esempio, il rilascio

Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio

che emerge al termine della finestra d'inclusione si chiamerà 2.6.40-rc1.

che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.

Questo rilascio indica che il momento di aggiungere nuovi componenti è

Questo rilascio indica che il momento di aggiungere nuovi componenti è

passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.

passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
@@ -76,22 +76,23 @@ Mentre le correzioni si aprono la loro strada all'interno del ramo principale, 
il ritmo delle modifiche rallenta col tempo.  Linus rilascia un nuovo

il ritmo delle modifiche rallenta col tempo.  Linus rilascia un nuovo

kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima

kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima

che il kernel venga considerato sufficientemente stabile e che il rilascio

che il kernel venga considerato sufficientemente stabile e che il rilascio

finale 2.6.x venga fatto.  A quel punto tutto il processo ricomincerà.

finale venga fatto.  A quel punto tutto il processo ricomincerà.





Esempio: ecco com'è andato il ciclo di sviluppo della versione 4.16

Esempio: ecco com'è andato il ciclo di sviluppo della versione 5.4

(tutte le date si collocano nel 2018)

(tutte le date si collocano nel 2018)









	==============  =======================================

	==============  =======================================

	Gennaio 28	4.15 rilascio stabile

	15 settembre	5.3 rilascio stabile

	Febbraio 11	4.16-rc1, finestra di inclusione chiusa

	30 settembre	5.4-rc1, finestra di inclusione chiusa

	Febbraio 18	4.16-rc2

	6 ottobre	5.4-rc2

	Febbraio 25	4.16-rc3

	13 ottobre	5.4-rc3

	Marzo 4		4.16-rc4

	20 ottobre	5.4-rc4

	Marzo 11	4.16-rc5

	27 ottobre	5.4-rc5

	Marzo 18	4.16-rc6

	3 novembre	5.4-rc6

	Marzo 25	4.16-rc7

	10 novembre	5.4-rc7

	Aprile 1		4.17 rilascio stabile

	17 novembre	5.4-rc8

	24 novembre	5.4 rilascio stabile

	==============  =======================================

	==============  =======================================





In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e

In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
@@ -108,43 +109,44 @@ tipo di perfezione difficilmente viene raggiunta; esistono troppe variabili 
in un progetto di questa portata.  Arriva un punto dove ritardare il rilascio

in un progetto di questa portata.  Arriva un punto dove ritardare il rilascio

finale peggiora la situazione; la quantità di modifiche in attesa della

finale peggiora la situazione; la quantità di modifiche in attesa della

prossima finestra di inclusione crescerà enormemente, creando ancor più

prossima finestra di inclusione crescerà enormemente, creando ancor più

regressioni al giro successivo.  Quindi molti kernel 4.x escono con una

regressioni al giro successivo.  Quindi molti kernel 5.x escono con una

manciata di regressioni delle quali, si spera, nessuna è grave.

manciata di regressioni delle quali, si spera, nessuna è grave.





Una volta che un rilascio stabile è fatto, il suo costante mantenimento è

Una volta che un rilascio stabile è fatto, il suo costante mantenimento è

affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.

affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.

Questa squadra rilascia occasionalmente degli aggiornamenti relativi al

Questa squadra rilascia occasionalmente degli aggiornamenti relativi al

rilascio stabile usando la numerazione 4.x.y.  Per essere presa in

rilascio stabile usando la numerazione 5.x.y.  Per essere presa in

considerazione per un rilascio d'aggiornamento, una modifica deve:

considerazione per un rilascio d'aggiornamento, una modifica deve:

(1) correggere un baco importante (2) essere già inserita nel ramo principale

(1) correggere un baco importante (2) essere già inserita nel ramo principale

per il prossimo sviluppo del kernel.  Solitamente, passato il loro rilascio

per il prossimo sviluppo del kernel.  Solitamente, passato il loro rilascio

iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.

iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.

Quindi, per esempio, la storia del kernel 4.13 appare così:

Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):





	==============  ===============================

	==============  ===============================

	Settembre 3 	4.13 rilascio stabile

	15 settembre	5.2 rilascio stabile FIXME settembre è sbagliato

	Settembre 13	4.13.1

	14 luglio	5.2.1

	Settembre 20	4.13.2

	21 luglio	5.2.2

	Settembre 27	4.13.3

	26 luglio	5.2.3

	Ottobre 5	4.13.4

	28 luglio	5.2.4

	Ottobre 12	4.13.5

	31 luglio	5.2.5

	...		...

	...		...

	Novembre 24	4.13.16

	11 ottobre	5.2.21

	==============  ===============================

	==============  ===============================





La 4.13.16 fu l'aggiornamento finale per la versione 4.13.

La 5.2.21 fu l'aggiornamento finale per la versione 5.2.





Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi

Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi

riceveranno assistenza per un lungo periodo di tempo.  Al momento in cui

riceveranno assistenza per un lungo periodo di tempo.  Al momento in cui

scriviamo, i manutentori dei kernel stabili a lungo termine sono:

scriviamo, i manutentori dei kernel stabili a lungo termine sono:





	======  ======================  ==========================================

	======  ================================  ==========================================

	3.16	Ben Hutchings			  (kernel stabile molto più a lungo termine)

	3.16	Ben Hutchings			  (kernel stabile molto più a lungo termine)

	4.1	Sasha Levin

	4.4	Greg Kroah-Hartman e Sasha Levin  (kernel stabile molto più a lungo termine)

	4.4	Greg Kroah-Hartman	(kernel stabile molto più a lungo termine)

	4.9	Greg Kroah-Hartman e Sasha Levin

	4.9	Greg Kroah-Hartman

	4.14	Greg Kroah-Hartman e Sasha Levin

	4.14	Greg Kroah-Hartman

	4.19	Greg Kroah-Hartman e Sasha Levin

	======  ======================  ==========================================

	5.4i	Greg Kroah-Hartman e Sasha Levin

	======  ================================  ==========================================









Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro

Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
@@ -229,12 +231,13 @@ Come le modifiche finiscono nel Kernel 
--------------------------------------

--------------------------------------





Esiste una sola persona che può inserire le patch nel repositorio principale

Esiste una sola persona che può inserire le patch nel repositorio principale

del kernel: Linus Torvalds.  Ma, di tutte le 9500 patch che entrarono nella

del kernel: Linus Torvalds.  Ma, per esempio, di tutte le 9500 patch

versione 2.6.38 del kernel, solo 112 (circa l'1,3%) furono scelte direttamente

che entrarono nella versione 2.6.38 del kernel, solo 112 (circa

da Linus in persona.  Il progetto del kernel è cresciuto fino a raggiungere

l'1,3%) furono scelte direttamente da Linus in persona.  Il progetto

una dimensione tale per cui un singolo sviluppatore non può controllare e

del kernel è cresciuto fino a raggiungere una dimensione tale per cui

selezionare indipendentemente ogni modifica senza essere supportato.

un singolo sviluppatore non può controllare e selezionare

La via scelta dagli sviluppatori per indirizzare tale crescita è stata quella

indipendentemente ogni modifica senza essere supportato.  La via

scelta dagli sviluppatori per indirizzare tale crescita è stata quella

di utilizzare un sistema di "sottotenenti" basato sulla fiducia.

di utilizzare un sistema di "sottotenenti" basato sulla fiducia.





Il codice base del kernel è spezzato in una serie si sottosistemi: rete,

Il codice base del kernel è spezzato in una serie si sottosistemi: rete,

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

+3 −3
Original line number Original line Diff line number Diff line
@@ -313,7 +313,7 @@ che conta gli utenti attivi, dovreste chiamarla ``count_active_users()`` o 
qualcosa di simile, **non** dovreste chiamarla ``cntusr()``.

qualcosa di simile, **non** dovreste chiamarla ``cntusr()``.





Codificare il tipo di funzione nel suo nome (quella cosa chiamata notazione

Codificare il tipo di funzione nel suo nome (quella cosa chiamata notazione

ungherese) fa male al cervello - il compilatore conosce comunque il tipo e

ungherese) è stupido - il compilatore conosce comunque il tipo e

può verificarli, e inoltre confonde i programmatori.  Non c'è da

può verificarli, e inoltre confonde i programmatori.  Non c'è da

sorprendersi che MicroSoft faccia programmi bacati.

sorprendersi che MicroSoft faccia programmi bacati.
@@ -825,8 +825,8 @@ linguaggio assembler. 




Agli sviluppatori del kernel piace essere visti come dotti. Tenete un occhio

Agli sviluppatori del kernel piace essere visti come dotti. Tenete un occhio

di riguardo per l'ortografia e farete una belle figura. In inglese, evitate

di riguardo per l'ortografia e farete una belle figura. In inglese, evitate

l'uso di parole mozzate come ``dont``: usate ``do not`` oppure ``don't``.

l'uso incorretto di abbreviazioni come ``dont``: usate ``do not`` oppure

Scrivete messaggi concisi, chiari, e inequivocabili.

``don't``.  Scrivete messaggi concisi, chiari, e inequivocabili.





I messaggi del kernel non devono terminare con un punto fermo.

I messaggi del kernel non devono terminare con un punto fermo.