doc🇮🇹 add some process/* translations

Translated documents:
- 2.Process
- 3.Early-stage
- 4.Coding
- 5.Posting
- 6.Followthrough
- 7.AdvancedTopics
- 8.Conclusion
- adding-syscalls

Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

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

@@ -1,12 +1,531 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/2.Process.rst <development_process>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
 
 .. _it_development_process:
 
 Come funziona il processo di sviluppo
 =====================================
 
-.. warning::
+Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con
+un numero di utenti e sviluppatori relativamente basso.  Con una base
+di milioni di utenti e con 2000 sviluppatori coinvolti nel giro di un anno,
+il kernel da allora ha messo in atto un certo numero di procedure per rendere
+lo sviluppo più agevole.  È richiesta una solida conoscenza di come tale
+processo si svolge per poter esserne parte attiva.
 
-    TODO ancora da tradurre
+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:
+
+	======  =================
+	4.11	Aprile 30, 2017
+	4.12	Luglio 2, 2017
+	4.13	Settembre 3, 2017
+	4.14	Novembre 12, 2017
+	4.15	Gennaio 28, 2018
+	4.16	Aprile 1, 2018
+	======  =================
+
+Ciascun rilascio 4.x è un importante rilascio del kernel con nuove
+funzionalità, modifiche interne dell'API, e molto altro.  Un tipico
+rilascio 4.x contiene quasi 13,000 gruppi di modifiche con ulteriori
+modifiche a parecchie migliaia di linee di codice.  La 4.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.
+
+Viene seguita una disciplina abbastanza lineare per l'inclusione delle
+patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
+"finestra di inclusione" viene dichiarata aperta.  In quel momento il codice
+ritenuto sufficientemente stabile(e che è accettato dalla comunità di sviluppo)
+viene incluso nel ramo principale del kernel.  La maggior parte delle
+patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
+saranno inserite durante questo periodo, ad un ritmo che si attesta sulle
+1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
+
+(per inciso, vale la pena notare che i cambiamenti integrati durante la
+"finestra di inclusione" non escono dal nulla; questi infatti, sono stati
+raccolti e, verificati in anticipo.  Il funzionamento di tale procedimento
+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 2.6.40, per esempio, il rilascio
+che emerge al termine della finestra d'inclusione si chiamerà 2.6.40-rc1.
+Questo rilascio indica che il momento di aggiungere nuovi componenti è
+passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
+
+Nelle successive sei/dieci settimane, potranno essere sottoposte solo modifiche
+che vanno a risolvere delle problematiche.  Occasionalmente potrà essere
+consentita una modifica più consistente, ma tali occasioni sono rare.
+Gli sviluppatori che tenteranno di aggiungere nuovi elementi al di fuori della
+finestra di inclusione, tendenzialmente, riceveranno un accoglienza poco
+amichevole. Come regola generale: se vi perdete la finestra di inclusione per
+un dato componente, la cosa migliore da fare è aspettare il ciclo di sviluppo
+successivo (un'eccezione può essere fatta per i driver per hardware non
+supportati in precedenza; se toccano codice non facente parte di quello
+attuale, che non causino regressioni e che potrebbero essere aggiunti in
+sicurezza in un qualsiasi momento)
+
+Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
+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
+che il kernel venga considerato sufficientemente stabile e che il rilascio
+finale 2.6.x venga fatto.  A quel punto tutto il processo ricomincerà.
+
+Esempio: ecco com'è andato il ciclo di sviluppo della versione 4.16
+(tutte le date si collocano nel 2018)
+
+
+	==============  =======================================
+	Gennaio 28	4.15 rilascio stabile
+	Febbraio 11	4.16-rc1, finestra di inclusione chiusa
+	Febbraio 18	4.16-rc2
+	Febbraio 25	4.16-rc3
+	Marzo 4		4.16-rc4
+	Marzo 11	4.16-rc5
+	Marzo 18	4.16-rc6
+	Marzo 25	4.16-rc7
+	Aprile 1		4.17 rilascio stabile
+	==============  =======================================
+
+In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
+creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
+rilevate nel precedente rilascio.  Nessun baco è il benvenuto, ma quelli che
+procurano problemi su sistemi che hanno funzionato in passato sono considerati
+particolarmente seri.  Per questa ragione, le modifiche che portano ad una
+regressione sono viste sfavorevolmente e verranno quasi sicuramente annullate
+durante il periodo di stabilizzazione.
+
+L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
+conosciute prima che avvenga il rilascio stabile.  Nel mondo reale, questo
+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 4.x 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 4.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 4.13 appare così:
+
+	==============  ===============================
+	Settembre 3 	4.13 rilascio stabile
+	Settembre 13	4.13.1
+	Settembre 20	4.13.2
+	Settembre 27	4.13.3
+	Ottobre 5	4.13.4
+	Ottobre 12	4.13.5
+	...		...
+	Novembre 24	4.13.16
+	==============  ===============================
+
+La 4.13.16 fu l'aggiornamento finale per la versione 4.13.
+
+Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
+riceveranno assistenza per un lungo periodo di tempo.  Al momento in cui
+scriviamo, i manutentori dei kernel stabili a lungo termine sono:
+
+	======  ======================  ==========================================
+	3.16	Ben Hutchings		(kernel stabile molto più a lungo termine)
+	4.1	Sasha Levin
+	4.4	Greg Kroah-Hartman	(kernel stabile molto più a lungo termine)
+	4.9	Greg Kroah-Hartman
+	4.14	Greg Kroah-Hartman
+	======  ======================  ==========================================
+
+
+Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
+manutentori, alla loro necessità e al tempo per tenere aggiornate proprio
+quelle versioni.  Non ci sono altri kernel a lungo termine in programma per
+alcun rilascio in arrivo.
+
+Il ciclo di vita di una patch
+-----------------------------
+
+Le patch non passano direttamente dalla tastiera dello sviluppatori
+al ramo principale del kernel. Esiste, invece, una procedura disegnata
+per assicurare che ogni patch sia di buona qualità e desiderata nel
+ramo principale.  Questo processo avviene velocemente per le correzioni
+meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
+Per uno sviluppatore la maggior frustrazione viene dalla mancanza di
+comprensione di questo processo o dai tentativi di aggirarlo.
+
+Nella speranza di ridurre questa frustrazione, questo documento spiegherà
+come una patch viene inserita nel kernel.  Ciò che segue è un'introduzione
+che descrive il processo ideale.  Approfondimenti verranno invece trattati
+più avanti.
+
+Una patch attraversa, generalmente, le seguenti fasi:
+
+ - Progetto. In questa fase sono stabilite quelli che sono i requisiti
+   della modifica - e come verranno soddisfatti.  Il lavoro di progettazione
+   viene spesso svolto senza coinvolgere la comunità, ma è meglio renderlo
+   il più aperto possibile; questo può far risparmiare molto tempo evitando
+   eventuali riprogettazioni successive.
+
+ - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
+   interessate, e gli sviluppatori in quella lista risponderanno coi loro
+   commenti.  Se si svolge correttamente, questo procedimento potrebbe far
+   emergere problemi rilevanti in una patch.
+
+ - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
+   nel ramo principale, un manutentore importante del sottosistema dovrebbe
+   accettarla - anche se, questa accettazione non è una garanzia che la
+   patch arriverà nel ramo principale. La patch sarà visibile nei sorgenti
+   del sottosistema in questione e nei sorgenti -next (descritti sotto).
+   Quando il processo va a buon fine, questo passo porta ad una revisione
+   più estesa della patch e alla scoperta di problemi d'integrazione
+   con il lavoro altrui.
+
+-  Per favore, tenete da conto che la maggior parte dei manutentori ha
+   anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
+   non essere la loro priorità più alta.  Se una vostra patch riceve
+   dei suggerimenti su dei cambiamenti necessari, dovreste applicare
+   quei cambiamenti o giustificare perché non sono necessari.  Se la vostra
+   patch non riceve alcuna critica ma non è stata integrata dal
+   manutentore del driver o sottosistema, allora dovreste continuare con
+   i necessari aggiornamenti per mantenere la patch aggiornata al kernel
+   più recente cosicché questa possa integrarsi senza problemi; continuate
+   ad inviare gli aggiornamenti per essere revisionati e integrati.
+
+ - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
+   inserita all'interno nel repositorio principale, gestito da
+   Linus Torvalds.  In questa fase potrebbero emergere nuovi problemi e/o
+   commenti; è importante che lo sviluppatore sia collaborativo e che sistemi
+   ogni questione che possa emergere.
+
+ - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
+   toccati dalla patch è aumentato, quindi, ancora una volta, potrebbero
+   emergere nuovi problemi.
+
+ - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
+   si dimentichi del codice dopo la sua integrazione, questo comportamento
+   lascia una brutta impressione nella comunità di sviluppo.  Integrare il
+   codice elimina alcuni degli oneri facenti parte della manutenzione, in
+   particolare, sistemerà le problematiche causate dalle modifiche all'API.
+   Ma lo sviluppatore originario dovrebbe continuare ad assumersi la
+   responsabilità per il codice se quest'ultimo continua ad essere utile
+   nel lungo periodo.
+
+Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
+di lavoro) è quello di cercare di ridurre tutta la procedura ad una singola
+"integrazione nel remo principale".  Questo approccio inevitabilmente conduce
+a una condizione di frustrazione per tutti coloro che sono coinvolti.
+
+Come le modifiche finiscono nel Kernel
+--------------------------------------
+
+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
+versione 2.6.38 del kernel, solo 112 (circa l'1,3%) furono scelte direttamente
+da Linus in persona.  Il progetto del kernel è cresciuto fino a raggiungere
+una dimensione tale per cui un singolo sviluppatore non può controllare e
+selezionare 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.
+
+Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
+supporto per specifiche architetture, gestione della memoria, video e
+strumenti, etc.  Molti sottosistemi hanno un manutentore designato: ovvero uno
+sviluppatore che ha piena responsabilità di tutto il codice presente in quel
+sottosistema.  Tali manutentori di sottosistema sono i guardiani
+(in un certo senso) della parte di kernel che gestiscono; sono coloro che
+(solitamente) accetteranno una patch per l'inclusione nel ramo principale
+del kernel.
+
+I manutentori di sottosistema gestiscono ciascuno la propria parte dei sorgenti
+del kernel, utilizzando abitualmente (ma certamente non sempre) git.
+Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
+di stilare una lista delle patch, includendo informazioni sull'autore ed
+altri metadati.  In ogni momento, il manutentore può individuare quale patch
+nel sua repositorio non si trova nel ramo principale.
+
+Quando la "finestra di integrazione" si apre, i manutentori di alto livello
+chiederanno a Linus di "prendere" dai loro repositori le modifiche che hanno
+selezionato per l'inclusione.  Se Linus acconsente, il flusso di patch si
+convoglierà nel repositorio di quest ultimo, divenendo così parte del ramo
+principale del kernel.  La quantità d'attenzione che Linus presta alle
+singole patch ricevute durante l'operazione di integrazione varia.
+È chiaro che, qualche volta, guardi più attentamente.  Ma, come regola
+generale, Linus confida nel fatto che i manutentori di sottosistema non
+selezionino pessime patch.
+
+I manutentori di sottosistemi, a turno, possono "prendere" patch
+provenienti da altri manutentori.  Per esempio, i sorgenti per la rete rete
+sono costruiti da modifiche che si sono accumulate inizialmente nei sorgenti
+dedicati ai driver per dispositivi di rete, rete senza fili, ecc.  Tale
+catena di repositori può essere più o meno lunga, benché raramente ecceda
+i due o tre collegamenti.  Questo processo è conosciuto come
+"la catena della fiducia", perché ogni manutentore all'interno della
+catena si fida di coloro che gestiscono i livelli più bassi.
+
+Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
+del kernel si basa sul trovare il manutentore giusto.  Di norma, inviare
+patch direttamente a Linus non è la via giusta.
+
+
+Sorgenti -next
+--------------
+
+La catena di sottosistemi guida il flusso di patch all'interno del kernel,
+ma solleva anche un interessante quesito: se qualcuno volesse vedere tutte le
+patch pronte per la prossima finestra di integrazione?
+Gli sviluppatori si interesseranno alle patch in sospeso per verificare
+che non ci siano altri conflitti di cui preoccuparsi; una modifica che, per
+esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
+conflitto con qualsiasi altra modifica che utilizzi la vecchia versione di
+quella funzione.  Revisori e tester vogliono invece avere accesso alle
+modifiche nella loro totalità prima che approdino nel ramo principale del
+kernel.  Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
+d'interesse, ma questo sarebbe un lavoro enorme e fallace.
+
+La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
+raccolti per essere testati e controllati.  Il più vecchio di questi sorgenti,
+gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
+di tutto).  L'-mm integra patch proveniente da una lunga lista di sottosistemi;
+e ha, inoltre, alcune patch destinate al supporto del debugging.
+
+Oltre a questo, -mm contiene una raccolta significativa di patch che sono
+state selezionate da Andrew direttamente.  Queste patch potrebbero essere
+state inviate in una lista di discussione, o possono essere applicate ad una
+parte del kernel per la quale non esiste un sottosistema dedicato.
+Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
+se per una patch non esiste una via chiara per entrare nel ramo principale,
+allora è probabile che finirà in -mm.  Le patch passate per -mm
+eventualmente finiranno nel sottosistema più appropriato o saranno inviate
+direttamente a Linus.  In un tipico ciclo di sviluppo, circa il 5-10% delle
+patch andrà nel ramo principale attraverso -mm.
+
+La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
+the moment) all'indirizzo:
+
+      http://www.ozlabs.org/~akpm/mmotm/
+
+È molto probabile che l'uso dei sorgenti MMOTM diventi un'esperienza
+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
+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
+vengono assemblati; e possono essere scaricate da:
+
+	http://www.kernel.org/pub/linux/kernel/next/
+
+Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
+tutte le patch incorporate durante una finestra di integrazione dovrebbero
+aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
+della finestra di integrazione.
+
+
+Sorgenti in preparazione
+------------------------
+
+Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
+molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
+al kernel.  Questi restano nella cartella drivers/staging fintanto che avranno
+bisogno di maggior lavoro; una volta completato, possono essere spostate
+all'interno del kernel nel posto più appropriato.  Questo è il modo di tener
+traccia dei driver che non sono ancora in linea con gli standard di codifica
+o qualità, ma che le persone potrebbero voler usare ugualmente e tracciarne
+lo sviluppo.
+
+Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
+che non sono completamente pronti vengono inviati a lui, e ciascun driver avrà
+la propria sotto-cartella in drivers/staging/.  Assieme ai file sorgenti
+dei driver, dovrebbe essere presente nella stessa cartella anche un file TODO.
+Il file TODO elenca il lavoro ancora da fare su questi driver per poter essere
+accettati nel kernel, e indica anche la lista di persone da inserire in copia
+conoscenza per ogni modifica fatta.  Le regole attuali richiedono che i
+driver debbano, come minimo, compilare adeguatamente.
+
+La *preparazione* può essere una via relativamente facile per inserire nuovi
+driver all'interno del ramo principale, dove, con un po' di fortuna, saranno
+notati da altri sviluppatori e migliorati velocemente.  Entrare nella fase
+di preparazione non è però la fine della storia, infatti, il codice che si
+trova nella cartella staging che non mostra regolari progressi potrebbe
+essere rimosso.  Le distribuzioni, inoltre, tendono a dimostrarsi relativamente
+riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
+nel migliore dei casi, una tappa sulla strada verso il divenire un driver
+del ramo principale.
+
+
+Strumenti
+---------
+
+Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
+dipende pesantemente dalla capacità di guidare la raccolta di patch in
+diverse direzioni.  L'intera cosa non funzionerebbe se non venisse svolta
+con l'uso di strumenti appropriati e potenti.  Spiegare l'uso di tali
+strumenti non è lo scopo di questo documento, ma c'è spazio per alcuni
+consigli.
+
+In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
+di gestione dei sorgenti. Git è una delle diverse tipologie di sistemi
+distribuiti di controllo versione che sono stati sviluppati nella comunità
+del software libero.  Esso è calibrato per lo sviluppo del kernel, e si
+comporta abbastanza bene quando ha a che fare con repositori grandi e con un
+vasto numero di patch.  Git ha inoltre la reputazione di essere difficile
+da imparare e utilizzare, benché stia migliorando.  Agli sviluppatori
+del kernel viene richiesta un po' di familiarità con git; anche se non lo
+utilizzano per il proprio lavoro, hanno bisogno di git per tenersi al passo
+con il lavoro degli altri sviluppatori (e con il ramo principale).
+
+Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
+potete consultare:
+
+	http://git-scm.com/
+
+Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
+
+Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
+popolare è quasi sicuramente Mercurial:
+
+	http://www.selenic.com/mercurial/
+
+Mercurial condivide diverse caratteristiche con git, ma fornisce
+un'interfaccia che potrebbe risultare più semplice da utilizzare.
+
+L'altro strumento che vale la pena conoscere è Quilt:
+
+	http://savannah.nongnu.org/projects/quilt/
+
+
+Quilt è un sistema di gestione delle patch, piuttosto che un sistema
+di gestione dei sorgenti.  Non mantiene uno storico degli eventi; ma piuttosto
+è orientato verso il tracciamento di uno specifico insieme di modifiche
+rispetto ad un codice in evoluzione.  Molti dei più grandi manutentori di
+sottosistema utilizzano quilt per gestire le patch che dovrebbero essere
+integrate.  Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
+quilt è il miglior strumento per svolgere il lavoro.
+
+
+Liste di discussione
+--------------------
+
+Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
+le liste di discussione.  È difficile essere un membro della comunità
+pienamente coinvolto se non si partecipa almeno ad una lista da qualche
+parte.  Ma, le liste di discussione di Linux rappresentano un potenziale
+problema per gli sviluppatori, che rischiano di venir sepolti da un mare di
+email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
+o entrambi.
+
+Molte delle liste di discussione del Kernel girano su vger.kernel.org;
+l'elenco principale lo si trova sul sito:
+
+	http://vger.kernel.org/vger-lists.html
+
+Esistono liste gestite altrove; un certo numero di queste sono in
+lists.redhat.com.
+
+La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
+linux-kernel.  Questa lista è un luogo ostile dove trovarsi; i volumi possono
+raggiungere i 500 messaggi al giorno, la quantità di "rumore" è elevata,
+la conversazione può essere strettamente tecnica e i partecipanti non sono
+sempre preoccupati di mostrare un alto livello di educazione.  Ma non esiste
+altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
+gli sviluppatori che evitano tale lista si perderanno informazioni importanti.
+
+Ci sono alcuni consigli che possono essere utili per sopravvivere a
+linux-kernel:
+
+- Tenete la lista in una cartella separata, piuttosto che inserirla nella
+  casella di posta principale.  Così da essere in grado di ignorare il flusso
+  di mail per un certo periodo di tempo.
+
+- Non cercate di seguire ogni conversazione - nessuno lo fa.  È importante
+  filtrare solo gli argomenti d'interesse (sebbene va notato che le
+  conversazioni di lungo periodo possono deviare dall'argomento originario
+  senza cambiare il titolo della mail) e le persone che stanno partecipando.
+
+- Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
+
+- Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
+  tutti i Cc:.  In assenza di importanti motivazioni (come una richiesta
+  esplicita), non dovreste mai togliere destinatari.  Assicuratevi sempre che
+  la persona alla quale state rispondendo sia presente nella lista Cc. Questa
+  usanza fa si che divenga inutile chiedere esplicitamente di essere inseriti
+  in copia nel rispondere al vostro messaggio.
+
+- Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
+  di far domande.  Molti sviluppatori possono divenire impazienti con le
+  persone che chiaramente non hanno svolto i propri compiti a casa.
+
+- Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
+  alla frase alla quale state rispondendo).  Ciò renderebbe la vostra risposta
+  difficile da leggere e genera scarsa impressione.
+
+- Chiedete nella lista di discussione corretta.  Linux-kernel può essere un
+  punto di incontro generale, ma non è il miglior posto dove trovare
+  sviluppatori da tutti i sottosistemi.
+
+Infine, la ricerca della corretta lista di discussione è uno degli errori più
+comuni per gli sviluppatori principianti.  Qualcuno che pone una domanda
+relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
+di chiedere sulla lista netdev, che è la lista frequentata dagli sviluppatori
+di rete.  Ci sono poi altre liste per i sottosistemi SCSI, video4linux, IDE,
+filesystem, etc.  Il miglior posto dove cercare una lista di discussione è il
+file MAINTAINERS che si trova nei sorgenti del kernel.
+
+Iniziare con lo sviluppo del Kernel
+-----------------------------------
+
+Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
+singole persone che da aziende.  Altrettanto comuni sono i passi falsi che
+rendono l'inizio di tale relazione più difficile di quello che dovrebbe essere.
+
+Le aziende spesso cercano di assumere sviluppatori noti per creare un gruppo
+di sviluppo iniziale.  Questo, in effetti, può essere una tecnica efficace.
+Ma risulta anche essere dispendiosa e non va ad accrescere il bacino di
+sviluppatori kernel con esperienza.  È possibile anche "portare a casa"
+sviluppatori per accelerare lo sviluppo del kernel, dando comunque
+all'investimento un po' di tempo.  Prendersi questo tempo può fornire
+al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
+che l'azienda stessa, e che possono supportare la formazione di altre persone.
+Nel medio periodo, questa è spesso uno delle soluzioni più proficue.
+
+I singoli sviluppatori sono spesso, comprensibilmente, una perdita come punto
+di partenza.  Iniziare con un grande progetto può rivelarsi intimidatorio;
+spesso all'inizio si vuole solo verificare il terreno con qualcosa di piccolo.
+Questa è una delle motivazioni per le quali molti sviluppatori saltano alla
+creazione di patch che vanno a sistemare errori di battitura o
+problematiche minori legate allo stile del codice.  Sfortunatamente, tali
+patch creano un certo livello di rumore che distrae l'intera comunità di
+sviluppo, quindi, sempre di più, esse vengono degradate.  I nuovi sviluppatori
+che desiderano presentarsi alla comunità non riceveranno l'accoglienza
+che vorrebbero con questi mezzi.
+
+Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
+
+::
+
+     Il primo progetto per un neofita del kernel dovrebbe essere
+     sicuramente quello di "assicurarsi che il kernel funzioni alla
+     perfezione sempre e su tutte le macchine sulle quali potete stendere
+     la vostra mano".  Solitamente il modo per fare ciò è quello di
+     collaborare con gli altri nel sistemare le cose (questo richiede
+     persistenza!) ma va bene - è parte dello sviluppo kernel.
+
+(http://lwn.net/Articles/283982/).
+
+In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
+di consultare, in generale, la lista di regressioni e di bachi aperti.
+Non c'è mai carenza di problematiche bisognose di essere sistemate;
+accollandosi tali questioni gli sviluppatori accumuleranno esperienza con
+la procedura, ed allo stesso tempo, aumenteranno la loro rispettabilità
+all'interno della comunità di sviluppo.

Documentation/translations/it_IT/process/3.Early-stage.rst

@@ -1,12 +1,241 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
 
 .. _it_development_early_stage:
 
-Primi passi della pianificazione
-================================
+I primi passi della pianificazione
+==================================
 
-.. warning::
+Osservando un progetto di sviluppo per il kernel Linux, si potrebbe essere
+tentati dal saltare tutto e iniziare a codificare.  Tuttavia, come ogni
+progetto significativo, molta della preparazione per giungere al successo
+viene fatta prima che una sola linea di codice venga scritta.  Il tempo speso
+nella pianificazione e la comunicazione può far risparmiare molto
+tempo in futuro.
 
-    TODO ancora da tradurre
+Specificare il problema
+-----------------------
+
+Come qualsiasi progetto ingegneristico, un miglioramento del kernel di
+successo parte con una chiara descrizione del problema da risolvere.
+In alcuni casi, questo passaggio è facile: ad esempio quando un driver è
+richiesto per un particolare dispositivo.  In altri casi invece, si
+tende a confondere il problema reale con le soluzioni proposte e questo
+può portare all'emergere di problemi.
+
+Facciamo un esempio: qualche anno fa, gli sviluppatori che lavoravano con
+linux audio cercarono un modo per far girare le applicazioni senza dropouts
+o altri artefatti dovuti all'eccessivo ritardo nel sistema.  La soluzione
+alla quale giunsero fu un modulo del kernel destinato ad agganciarsi al
+framework Linux Security Module (LSM); questo modulo poteva essere
+configurato per dare ad una specifica applicazione accesso allo
+schedulatore *realtime*.  Tale modulo fu implementato e inviato nella
+lista di discussione linux-kernel, dove incontrò subito dei problemi.
+
+Per gli sviluppatori audio, questo modulo di sicurezza era sufficiente a
+risolvere il loro problema nell'immediato.  Per l'intera comunità kernel,
+invece, era un uso improprio del framework LSM (che non è progettato per
+conferire privilegi a processi che altrimenti non avrebbero potuto ottenerli)
+e un rischio per la stabilità del sistema.  Le loro soluzioni di punta nel
+breve periodo, comportavano un accesso alla schedulazione realtime attraverso
+il meccanismo rlimit, e nel lungo periodo un costante lavoro nella riduzione
+dei ritardi.
+
+La comunità audio, comunque, non poteva vedere al di là della singola
+soluzione che avevano implementato; erano riluttanti ad accettare alternative.
+Il conseguente dissenso lasciò in quegli sviluppatori un senso di
+disillusione nei confronti dell'intero processo di sviluppo; uno di loro
+scrisse questo messaggio:
+
+	Ci sono numerosi sviluppatori del kernel Linux davvero bravi, ma
+	rischiano di restare sovrastati da una vasta massa di stolti arroganti.
+	Cercare di comunicare le richieste degli utenti a queste persone è
+	una perdita di tempo. Loro sono troppo "intelligenti" per stare ad
+	ascoltare dei poveri mortali.
+
+	(http://lwn.net/Articles/131776/).
+
+La realtà delle cose fu differente; gli sviluppatori del kernel erano molto
+più preoccupati per la stabilità del sistema, per la manutenzione di lungo
+periodo e cercavano la giusta soluzione alla problematica esistente con uno
+specifico modulo.  La morale della storia è quella di concentrarsi sul
+problema - non su di una specifica soluzione- e di discuterne con la comunità
+di sviluppo prima di investire tempo nella scrittura del codice.
+
+Quindi, osservando un progetto di sviluppo del kernel, si dovrebbe
+rispondere a questa lista di domande:
+
+- Qual'è, precisamente, il problema che dev'essere risolto?
+
+- Chi sono gli utenti coinvolti da tal problema? A quale caso dovrebbe
+  essere indirizzata la soluzione?
+
+- In che modo il kernel risulta manchevole nell'indirizzare il problema
+  in questione?
+
+Solo dopo ha senso iniziare a considerare le possibili soluzioni.
+
+Prime discussioni
+-----------------
+
+Quando si pianifica un progetto di sviluppo per il kernel, sarebbe quanto meno
+opportuno discuterne inizialmente con la comunità prima di lanciarsi
+nell'implementazione.  Una discussione preliminare può far risparmiare sia
+tempo che problemi in svariati modi:
+
+ - Potrebbe essere che il problema sia già stato risolto nel kernel in
+   una maniera che non avete ancora compreso.  Il kernel Linux è grande e ha
+   una serie di funzionalità e capacità che non sono scontate nell'immediato.
+   Non tutte le capacità del kernel sono documentate così bene come ci
+   piacerebbe, ed è facile perdersi qualcosa.  Il vostro autore ha assistito
+   alla pubblicazione di un driver intero che duplica un altro driver
+   esistente di cui il nuovo autore era ignaro.  Il codice che rinnova
+   ingranaggi già esistenti non è soltanto dispendioso; non verrà nemmeno
+   accettato nel ramo principale del kernel.
+
+ - Potrebbero esserci proposte che non sono considerate accettabili per
+   l'integrazione all'interno del ramo principale. È meglio affrontarle
+   prima di scrivere il codice.
+
+ - È possibile che altri sviluppatori abbiano pensato al problema; potrebbero
+   avere delle idee per soluzioni migliori, e potrebbero voler contribuire
+   alla loro creazione.
+
+Anni di esperienza con la comunità di sviluppo del kernel hanno impartito una
+chiara lezione: il codice per il kernel che è pensato e sviluppato a porte
+chiuse, inevitabilmente, ha problematiche che si rivelano solo quando il
+codice viene rilasciato pubblicamente.  Qualche volta tali problemi sono
+importanti e richiedono mesi o anni di sforzi prima che il codice possa
+raggiungere gli standard richiesti della comunità.
+Alcuni esempi possono essere:
+
+ - La rete Devicescape è stata creata e implementata per sistemi
+   mono-processore.  Non avrebbe potuto essere inserita nel ramo principale
+   fino a che non avesse supportato anche i sistemi multi-processore.
+   Riadattare i meccanismi di sincronizzazione e simili è un compito difficile;
+   come risultato, l'inserimento di questo codice (ora chiamato mac80211)
+   fu rimandato per più di un anno.
+
+ - Il filesystem Reiser4 include una seria di funzionalità che, secondo
+   l'opinione degli sviluppatori principali del kernel, avrebbero dovuto
+   essere implementate a livello di filesystem virtuale.  Comprende
+   anche funzionalità che non sono facilmente implementabili senza esporre
+   il sistema al rischio di uno stallo.  La scoperta tardiva di questi
+   problemi - e il diniego a risolverne alcuni - ha avuto come conseguenza
+   il fatto che Raiser4 resta fuori dal ramo principale del kernel.
+
+ - Il modulo di sicurezza AppArmor utilizzava strutture dati del
+   filesystem virtuale interno in modi che sono stati considerati rischiosi e
+   inattendibili.  Questi problemi (tra le altre cose) hanno tenuto AppArmor
+   fuori dal ramo principale per anni.
+
+Ciascuno di questi casi è stato un travaglio e ha richiesto del lavoro
+straordinario, cose che avrebbero potuto essere evitate con alcune
+"chiacchierate" preliminari con gli sviluppatori kernel.
+
+Con chi parlare?
+----------------
+
+Quando gli sviluppatori hanno deciso di rendere pubblici i propri progetti, la
+domanda successiva sarà: da dove partiamo?  La risposta è quella di trovare
+la giusta lista di discussione e il giusto manutentore.  Per le liste di
+discussione, il miglior approccio è quello di cercare la lista più adatta
+nel file MAINTAINERS.  Se esiste una lista di discussione di sottosistema,
+è preferibile pubblicare lì piuttosto che sulla lista di discussione generale
+del kernel Linux; avrete maggiori probabilità di trovare sviluppatori con
+esperienza sul tema, e l'ambiente che troverete potrebbe essere più
+incoraggiante.
+
+Trovare manutentori può rivelarsi un po' difficoltoso.  Ancora, il file
+MAINTAINERS è il posto giusto da dove iniziare.  Il file potrebbe non essere
+sempre aggiornato, inoltre, non tutti i sottosistemi sono rappresentati qui.
+Coloro che sono elencati nel file MAINTAINERS potrebbero, in effetti, non
+essere le persone che attualmente svolgono quel determinato ruolo.  Quindi,
+quando c'è un dubbio su chi contattare, un trucco utile è quello di usare
+git (git log in particolare) per vedere chi attualmente è attivo all'interno
+del sottosistema interessato.  Controllate chi sta scrivendo le patch,
+e chi, se non ci fosse nessuno, sta aggiungendo la propria firma
+(Signed-off-by) a quelle patch.  Quelle sono le persone maggiormente
+qualificate per aiutarvi con lo sviluppo di nuovo progetto.
+
+Il compito di trovare il giusto manutentore, a volte, è una tale sfida che
+ha spinto gli sviluppatori del kernel a scrivere uno script che li aiutasse
+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 tutto ciò dovesse fallire, parlare con Andrew Morton potrebbe essere
+un modo efficace per capire chi è il manutentore di un dato pezzo di codice.
+
+Quando pubblicare
+-----------------
+
+Se potete, pubblicate i vostri intenti durante le fasi preliminari, sarà
+molto utile.  Descrivete il problema da risolvere e ogni piano che è stato
+elaborato per l'implementazione.  Ogni informazione fornita può aiutare
+la comunità di sviluppo a fornire spunti utili per il progetto.
+
+Un evento che potrebbe risultare scoraggiate e che potrebbe accadere in
+questa fase non è il ricevere una risposta ostile, ma, invece, ottenere
+una misera o inesistente reazione.  La triste verità è che: (1) gli
+sviluppatori del kernel tendono ad essere occupati, (2) ci sono tante persone
+con grandi progetti e poco codice (o anche solo la prospettiva di
+avere un codice) a cui riferirsi e (3) nessuno è obbligato a revisionare
+o a fare osservazioni in merito ad idee pubblicate da altri.  Oltre a
+questo, progetti di alto livello spesso nascondono problematiche che si
+rivelano solo quando qualcuno cerca di implementarle; per questa ragione
+gli sviluppatori kernel preferirebbero vedere il codice.
+
+Quindi, se una richiesta pubblica di commenti riscuote poco successo, non
+pensate che ciò significhi che non ci sia interesse nel progetto.
+Sfortunatamente, non potete nemmeno assumere che non ci siano problemi con
+la vostra idea.  La cosa migliore da fare in questa situazione è quella di
+andare avanti e tenere la comunità informata mentre procedete.
+
+Ottenere riscontri ufficiali
+----------------------------
+
+Se il vostro lavoro è stato svolto in un ambiente aziendale - come molto
+del lavoro fatto su Linux - dovete, ovviamente, avere il permesso dei
+dirigenti prima che possiate pubblicare i progetti, o il codice aziendale,
+su una lista di discussione pubblica.  La pubblicazione di codice che non
+è stato rilascio espressamente con licenza GPL-compatibile può rivelarsi
+problematico; prima la dirigenza, e il personale legale, troverà una decisione
+sulla pubblicazione di un progetto, meglio sarà per tutte le persone coinvolte.
+
+A questo punto, alcuni lettori potrebbero pensare che il loro lavoro sul
+kernel è preposto a supportare un prodotto che non è ancora ufficialmente
+riconosciuto.  Rivelare le intenzioni dei propri datori di lavori in una
+lista di discussione pubblica potrebbe non essere una soluzione valida.
+In questi casi, vale la pena considerare se la segretezza sia necessaria
+o meno; spesso non c'è una reale necessità di mantenere chiusi i progetti di
+sviluppo.
+
+Detto ciò, ci sono anche casi dove l'azienda legittimamente non può rivelare
+le proprie intenzioni in anticipo durante il processo di sviluppo.  Le aziende
+che hanno sviluppatori kernel esperti possono scegliere di procedere a
+carte coperte partendo dall'assunto che saranno in grado di evitare, o gestire,
+in futuro, eventuali problemi d'integrazione. Per le aziende senza questo tipo
+di esperti, la migliore opzione è spesso quella di assumere uno sviluppatore
+esterno che revisioni i progetti con un accordo di segretezza.
+La Linux Foundation applica un programma di NDA creato appositamente per
+aiutare le aziende in questa particolare situazione; potrete trovare più
+informazioni sul sito:
+
+    http://www.linuxfoundation.org/en/NDA_program
+
+Questa tipologia di revisione è spesso sufficiente per evitare gravi problemi
+senza che sia richiesta l'esposizione pubblica del progetto.

Documentation/translations/it_IT/process/4.Coding.rst

@@ -1,12 +1,447 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/4.Coding.rst <development_coding>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
 
 .. _it_development_coding:
 
 Scrivere codice corretto
 ========================
 
-.. warning::
+Nonostante ci sia molto da dire sul processo di creazione, sulla sua solidità
+e sul suo orientamento alla comunità, la prova di ogni progetto di sviluppo
+del kernel si trova nel codice stesso.  È il codice che sarà esaminato dagli
+altri sviluppatori ed inserito (o no) nel ramo principale. Quindi è la
+qualità di questo codice che determinerà il successo finale del progetto.
 
-    TODO ancora da tradurre
+Questa sezione esaminerà il processo di codifica.  Inizieremo con uno sguardo
+sulle diverse casistiche nelle quali gli sviluppatori kernel possono
+sbagliare.  Poi, l'attenzione si sposterà verso "il fare le cose
+correttamente" e sugli strumenti che possono essere utili in questa missione.
+
+Trappole
+--------
+
+Lo stile del codice
+*******************
+
+Il kernel ha da tempo delle norme sullo stile di codifica che sono descritte in
+:ref:`Documentation/translations/it_IT/process/coding-style.rst <codingstyle>`.
+Per la maggior parte del tempo, la politica descritta in quel file è stata
+praticamente informativa.  Ne risulta che ci sia una quantità sostanziale di
+codice nel kernel che non rispetta le linee guida relative allo stile.
+La presenza di quel codice conduce a due distinti pericoli per gli
+sviluppatori kernel.
+
+Il primo di questi è credere che gli standard di codifica del kernel
+non sono importanti e possono non essere applicati.  La verità è che
+aggiungere nuovo codice al kernel è davvero difficile se questo non
+rispetta le norme; molti sviluppatori richiederanno che il codice sia
+riformulato prima che anche solo lo revisionino.  Una base di codice larga
+quanto il kernel richiede una certa uniformità, in modo da rendere possibile
+per gli sviluppatori una comprensione veloce di ogni sua parte.  Non ci sono,
+quindi, più spazi per un codice formattato alla carlona.
+
+Occasionalmente, lo stile di codifica del kernel andrà in conflitto con lo
+stile richiesto da un datore di lavoro.  In alcuni casi, lo stile del kernel
+dovrà prevalere prima che il codice venga inserito.  Mettere il codice
+all'interno del kernel significa rinunciare a un certo grado di controllo
+in differenti modi - incluso il controllo sul come formattare il codice.
+
+L’altra trappola è quella di pensare che il codice già presente nel kernel
+abbia urgentemente bisogno di essere sistemato.  Gli sviluppatori potrebbero
+iniziare a generare patch che correggono lo stile come modo per prendere
+famigliarità con il processo, o come modo per inserire i propri nomi nei
+changelog del kernel – o entrambe.  La comunità di sviluppo vede un attività
+di codifica puramente correttiva come "rumore"; queste attività riceveranno
+una fredda accoglienza.  Di conseguenza è meglio evitare questo tipo di patch.
+Mentre si lavora su un pezzo di codice è normale correggerne anche lo stile,
+ma le modifiche di stile non dovrebbero essere fatte fini a se stesse.
+
+Il documento sullo stile del codice non dovrebbe essere letto come una legge
+assoluta che non può mai essere trasgredita.  Se c’è un a buona ragione
+(per esempio, una linea che diviene poco leggibile se divisa per rientrare
+nel limite di 80 colonne), fatelo e basta.
+
+Notate che potete utilizzare lo strumento “clang-format” per aiutarvi con
+le regole, per una riformattazione automatica e veloce del vostro codice
+e per revisionare interi file per individuare errori nello stile di codifica,
+refusi e possibili miglioramenti.  Inoltre è utile anche per classificare gli
+``#includes``, per allineare variabili/macro, per testi derivati ed altri
+compiti del genere.  Consultate il file
+:ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>`
+per maggiori dettagli
+
+
+Livelli di astrazione
+*********************
+
+
+I professori di Informatica insegnano ai propri studenti a fare ampio uso dei
+livelli di astrazione nel nome della flessibilità e del nascondere informazioni.
+Certo il kernel fa un grande uso dell'astrazione; nessun progetto con milioni
+di righe di codice potrebbe fare altrimenti e sopravvivere.  Ma l'esperienza
+ha dimostrato che un'eccessiva o prematura astrazione può rivelarsi dannosa
+al pari di una prematura ottimizzazione.  L'astrazione dovrebbe essere usata
+fino al livello necessario e non oltre.
+
+Ad un livello base, considerate una funzione che ha un argomento che viene
+sempre impostato a zero da tutti i chiamanti.  Uno potrebbe mantenere
+quell'argomento nell'eventualità qualcuno volesse sfruttare la flessibilità
+offerta.  In ogni caso, tuttavia, ci sono buone possibilità che il codice
+che va ad implementare questo argomento aggiuntivo, sia stato rotto in maniera
+sottile, in un modo che non è mai stato notato - perché non è mai stato usato.
+Oppure, quando sorge la necessità di avere più flessibilità, questo argomento
+non la fornisce in maniera soddisfacente.  Gli sviluppatori di Kernel,
+sottopongono costantemente patch che vanno a rimuovere gli argomenti
+inutilizzate; anche se, in generale, non avrebbero dovuto essere aggiunti.
+
+I livelli di astrazione che nascondono l'accesso all'hardware -
+spesso per poter usare dei driver su diversi sistemi operativi - vengono
+particolarmente disapprovati.  Tali livelli oscurano il codice e possono
+peggiorare le prestazioni; essi non appartengono al kernel Linux.
+
+D'altro canto, se vi ritrovate a dover copiare una quantità significativa di
+codice proveniente da un altro sottosistema del kernel, è tempo di chiedersi
+se, in effetti, non avrebbe più senso togliere parte di quel codice e metterlo
+in una libreria separata o di implementare quella funzionalità ad un livello
+più elevato.  Non c'è utilità nel replicare lo stesso codice per tutto
+il kernel.
+
+
+#ifdef e l'uso del preprocessore in generale
+********************************************
+
+Il preprocessore C sembra essere una fonte di attrazione per qualche
+programmatore C, che ci vede una via per ottenere una grande flessibilità
+all'interno di un file sorgente.  Ma il preprocessore non è scritto in C,
+e un suo massiccio impiego conduce a un codice che è molto più difficile
+da leggere per gli altri e che rende più difficile il lavoro di verifica del
+compilatore.  L'uso eccessivo del preprocessore è praticamente sempre il segno
+di un codice che necessita di un certo lavoro di pulizia.
+
+La compilazione condizionata con #ifdef è, in effetti, un potente strumento,
+ed esso viene usato all'interno del kernel.  Ma esiste un piccolo desiderio:
+quello di vedere il codice coperto solo da una leggera spolverata di
+blocchi #ifdef.  Come regola generale, quando possibile, l'uso di #ifdef
+dovrebbe essere confinato nei file d'intestazione.  Il codice compilato
+condizionatamente può essere confinato a funzioni tali che, nel caso in cui
+il codice non deve essere presente, diventano vuote.  Il compilatore poi
+ottimizzerà la chiamata alla funzione vuota rimuovendola.  Il risultato è
+un codice molto più pulito, più facile da seguire.
+
+Le macro del preprocessore C presentano una serie di pericoli, inclusi
+valutazioni multiple di espressioni che hanno effetti collaterali e non
+garantiscono una sicurezza rispetto ai tipi.  Se siete tentati dal definire
+una macro, considerate l'idea di creare invece una funzione inline.  Il codice
+che ne risulterà sarà lo stesso, ma le funzioni inline sono più leggibili,
+non considerano i propri argomenti più volte, e permettono al compilatore di
+effettuare controlli sul tipo degli argomenti e del valore di ritorno.
+
+
+Funzioni inline
+***************
+
+Comunque, anche le funzioni inline hanno i loro pericoli.  I programmatori
+potrebbero innamorarsi dell'efficienza percepita derivata dalla rimozione
+di una chiamata a funzione.  Queste funzioni, tuttavia, possono ridurre le
+prestazioni.  Dato che il loro codice viene replicato ovunque vi sia una
+chiamata ad esse, si finisce per gonfiare le dimensioni del kernel compilato.
+Questi, a turno, creano pressione sulla memoria cache del processore, e questo
+può causare rallentamenti importanti.  Le funzioni inline, di norma, dovrebbero
+essere piccole e usate raramente.  Il costo di una chiamata a funzione, dopo
+tutto, non è così alto; la creazione di molte funzioni inline è il classico
+esempio di un'ottimizzazione prematura.
+
+In generale, i programmatori del kernel ignorano gli effetti della cache a
+loro rischio e pericolo.  Il classico compromesso tempo/spazio teorizzato
+all'inizio delle lezioni sulle strutture dati spesso non si applica
+all'hardware moderno.  Lo spazio *è* tempo, in questo senso un programma
+più grande sarà più lento rispetto ad uno più compatto.
+
+I compilatori più recenti hanno preso un ruolo attivo nel decidere se
+una data funzione deve essere resa inline oppure no.  Quindi l'uso
+indiscriminato della parola chiave "inline" potrebbe non essere non solo
+eccessivo, ma anche irrilevante.
+
+Sincronizzazione
+****************
+
+Nel maggio 2006, il sistema di rete "Devicescape" fu rilasciato in pompa magna
+sotto la licenza GPL e reso disponibile per la sua inclusione nella ramo
+principale del kernel.  Questa donazione fu una notizia bene accolta;
+il supporto per le reti senza fili era considerata, nel migliore dei casi,
+al di sotto degli standard; il sistema Deviscape offrì la promessa di una
+risoluzione a tale situazione.  Tuttavia, questo codice non fu inserito nel
+ramo principale fino al giugno del 2007 (2.6.22). Cosa accadde?
+
+Quel codice mostrava numerosi segnali di uno sviluppo in azienda avvenuto
+a porte chiuse.  Ma in particolare, un grosso problema fu che non fu
+progettato per girare in un sistema multiprocessore.  Prima che questo
+sistema di rete (ora chiamato mac80211) potesse essere inserito, fu necessario
+un lavoro sugli schemi di sincronizzazione.
+
+Una volta, il codice del kernel Linux poteva essere sviluppato senza pensare
+ai problemi di concorrenza presenti nei sistemi multiprocessore.  Ora,
+comunque, questo documento è stato scritto su di un portatile dual-core.
+Persino su sistemi a singolo processore, il lavoro svolto per incrementare
+la capacità di risposta aumenterà il livello di concorrenza interno al kernel.
+I giorni nei quali il codice poteva essere scritto senza pensare alla
+sincronizzazione sono da passati tempo.
+
+Ogni risorsa (strutture dati, registri hardware, etc.) ai quali si potrebbe
+avere accesso simultaneo da più di un thread deve essere sincronizzato.  Il
+nuovo codice dovrebbe essere scritto avendo tale accortezza in testa;
+riadattare la sincronizzazione a posteriori è un compito molto più difficile.
+Gli sviluppatori del kernel dovrebbero prendersi il tempo di comprendere bene
+le primitive di sincronizzazione, in modo da sceglier lo strumento corretto
+per eseguire un compito.  Il codice che presenta una mancanza di attenzione
+alla concorrenza avrà un percorso difficile all'interno del ramo principale.
+
+Regressioni
+***********
+
+Vale la pena menzionare un ultimo pericolo: potrebbe rivelarsi accattivante
+l'idea di eseguire un cambiamento (che potrebbe portare a grandi
+miglioramenti) che porterà ad alcune rotture per gli utenti esistenti.
+Questa tipologia di cambiamento è chiamata "regressione", e le regressioni son
+diventate mal viste nel ramo principale del kernel.  Con alcune eccezioni,
+i cambiamenti che causano regressioni saranno fermati se quest'ultime non
+potranno essere corrette in tempo utile.  È molto meglio quindi evitare
+la regressione fin dall'inizio.
+
+Spesso si è argomentato che una regressione può essere giustificata se essa
+porta risolve più problemi di quanti non ne crei.  Perché, dunque, non fare
+un cambiamento se questo porta a nuove funzionalità a dieci sistemi per
+ognuno dei quali esso determina una rottura?  La migliore risposta a questa
+domanda ci è stata fornita da Linus nel luglio 2007:
+
+::
+   Dunque, noi non sistemiamo bachi introducendo nuovi problemi. Quella
+   via nasconde insidie, e nessuno può sapere del tutto se state facendo
+   dei progressi reali. Sono due passi avanti e uno indietro, oppure
+   un passo avanti e due indietro?
+
+(http://lwn.net/Articles/243460/).
+
+Una particolare tipologia di regressione mal vista consiste in una qualsiasi
+sorta di modifica all'ABI dello spazio utente.  Una volta che un'interfaccia
+viene esportata verso lo spazio utente, dev'essere supportata all'infinito.
+Questo fatto rende la creazione di interfacce per lo spazio utente
+particolarmente complicato: dato che non possono venir cambiate introducendo
+incompatibilità, esse devono essere fatte bene al primo colpo.  Per questa
+ragione sono sempre richieste: ampie riflessioni, documentazione chiara e
+ampie revisioni dell'interfaccia verso lo spazio utente.
+
+
+Strumenti di verifica del codice
+--------------------------------
+Almeno per ora la scrittura di codice priva di errori resta un ideale
+irraggiungibile ai più.  Quello che speriamo di poter fare, tuttavia, è
+trovare e correggere molti di questi errori prima che il codice entri nel
+ramo principale del kernel.  A tal scopo gli sviluppatori del kernel devono
+mettere insieme una schiera impressionante di strumenti che possano
+localizzare automaticamente un'ampia varietà di problemi.  Qualsiasi problema
+trovato dal computer è un problema che non affliggerà l'utente in seguito,
+ne consegue che gli strumenti automatici dovrebbero essere impiegati ovunque
+possibile.
+
+Il primo passo consiste semplicemente nel fare attenzione agli avvertimenti
+proveniente dal compilatore.  Versioni moderne di gcc possono individuare
+(e segnalare) un gran numero di potenziali errori.  Molto spesso, questi
+avvertimenti indicano problemi reali.  Di regola, il codice inviato per la
+revisione non dovrebbe produrre nessun avvertimento da parte del compilatore.
+Per mettere a tacere gli avvertimenti, cercate di comprenderne le cause reali
+e cercate di evitare le "riparazioni" che fan sparire l'avvertimento senza
+però averne trovato la causa.
+
+Tenete a mente che non tutti gli avvertimenti sono disabilitati di default.
+Costruite il kernel con "make EXTRA_CFLAGS=-W" per ottenerli tutti.
+
+Il kernel fornisce differenti opzioni che abilitano funzionalità di debugging;
+molti di queste sono trovano all'interno del sotto menu "kernel hacking".
+La maggior parte di queste opzioni possono essere attivate per qualsiasi
+kernel utilizzato per lo sviluppo o a scopo di test.  In particolare dovreste
+attivare:
+
+ - ENABLE_WARN_DEPRECATED, ENABLE_MUST_CHECK, e FRAME_WARN per ottenere degli
+   avvertimenti dedicati a problemi come l'uso di interfacce deprecate o
+   l'ignorare un importante valore di ritorno di una funzione.  Il risultato
+   generato da questi avvertimenti può risultare verboso, ma non bisogna
+   preoccuparsi per gli avvertimenti provenienti da altre parti del kernel.
+
+ - DEBUG_OBJECTS aggiungerà un codice per tracciare il ciclo di vita di
+   diversi oggetti creati dal kernel e avvisa quando qualcosa viene eseguito
+   fuori controllo.  Se state aggiungendo un sottosistema che crea (ed
+   esporta) oggetti complessi propri, considerate l'aggiunta di un supporto
+   al debugging dell'oggetto.
+
+ - DEBUG_SLAB può trovare svariati errori di uso e di allocazione di memoria;
+   esso dovrebbe esser usato dalla maggior parte dei kernel di sviluppo.
+
+ - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, e DEBUG_MUTEXES troveranno un certo
+   numero di errori comuni di sincronizzazione.
+
+Esistono ancora delle altre opzioni di debugging, di alcune di esse
+discuteremo qui sotto.  Alcune di esse hanno un forte impatto e non dovrebbero
+essere usate tutte le volte.  Ma qualche volta il tempo speso nell'capire
+le opzioni disponibili porterà ad un risparmio di tempo nel breve termine.
+
+Uno degli strumenti di debugging più tosti è il *locking checker*, o
+"lockdep".  Questo strumento traccerà qualsiasi acquisizione e rilascio di
+ogni *lock* (spinlock o mutex) nel sistema, l'ordine con il quale i *lock*
+sono acquisiti in relazione l'uno con l'altro, l'ambiente corrente di
+interruzione, eccetera.  Inoltre esso può assicurare che i *lock* vengano
+acquisiti sempre nello stesso ordine, che le stesse assunzioni sulle
+interruzioni si applichino in tutte le occasioni, e così via.  In altre parole,
+lockdep può scovare diversi scenari nei quali il sistema potrebbe, in rari
+casi, trovarsi in stallo.  Questa tipologia di problema può essere grave
+(sia per gli sviluppatori che per gli utenti) in un sistema in uso; lockdep
+permette di trovare tali problemi automaticamente e in anticipo.
+
+In qualità di programmatore kernel diligente, senza dubbio, dovrete controllare
+il valore di ritorno di ogni operazione (come l'allocazione della memoria)
+poiché esso potrebbe fallire.  Il nocciolo della questione è che i percorsi
+di gestione degli errori, con grande probabilità, non sono mai stati
+collaudati del tutto.  Il codice collaudato tende ad essere codice bacato;
+potrete quindi essere più a vostro agio con il vostro codice se tutti questi
+percorsi fossero stati verificati un po' di volte.
+
+Il kernel fornisce un framework per l'inserimento di fallimenti che fa
+esattamente al caso, specialmente dove sono coinvolte allocazioni di memoria.
+Con l'opzione per l'inserimento dei fallimenti abilitata, una certa percentuale
+di allocazione di memoria sarà destinata al fallimento; questi fallimenti
+possono essere ridotti ad uno specifico pezzo di codice.  Procedere con
+l'inserimento dei fallimenti attivo permette al programmatore di verificare
+come il codice risponde quando le cose vanno male.  Consultate:
+Documentation/fault-injection/fault-injection.txt per avere maggiori
+informazioni su come utilizzare questo strumento.
+
+Altre tipologie di errori possono essere riscontrati con lo strumento di
+analisi statica "sparse".  Con Sparse, il programmatore può essere avvisato
+circa la confusione tra gli indirizzi dello spazio utente e dello spazio
+kernel, un miscuglio fra quantità big-endian e little-endian, il passaggio
+di un valore intero dove ci sia aspetta un gruppo di flag, e così via.
+Sparse deve essere installato separatamente (se il vostra distribuzione non
+lo prevede, potete trovarlo su https://sparse.wiki.kernel.org/index.php/Main_Page);
+può essere attivato sul codice aggiungendo "C=1" al comando make.
+
+Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) è in grado di trovare
+una vasta varietà di potenziali problemi di codifica; e può inoltre proporre
+soluzioni per risolverli.  Un buon numero di "patch semantiche" per il kernel
+sono state preparate nella cartella scripts/coccinelle; utilizzando
+"make coccicheck" esso percorrerà tali patch semantiche e farà rapporto su
+qualsiasi problema trovato.  Per maggiori informazioni, consultate
+:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`.
+
+Altri errori di portabilità sono meglio scovati compilando il vostro codice
+per altre architetture.  Se non vi accade di avere un sistema S/390 o una
+scheda di sviluppo Blackfin sotto mano, potete comunque continuare la fase
+di compilazione.  Un vasto numero di cross-compilatori per x86 possono
+essere trovati al sito:
+
+	http://www.kernel.org/pub/tools/crosstool/
+
+Il tempo impiegato nell'installare e usare questi compilatori sarà d'aiuto
+nell'evitare situazioni imbarazzanti nel futuro.
+
+
+Documentazione
+--------------
+
+La documentazione è spesso stata più un'eccezione che una regola nello
+sviluppo del kernel.  Nonostante questo, un'adeguata documentazione aiuterà
+a facilitare l'inserimento di nuovo codice nel kernel, rende la vita più
+facile per gli altri sviluppatori e sarà utile per i vostri utenti.  In molti
+casi, la documentazione è divenuta sostanzialmente obbligatoria.
+
+La prima parte di documentazione per qualsiasi patch è il suo changelog.
+Questi dovrebbero descrivere le problematiche risolte, la tipologia di
+soluzione, le persone che lavorano alla patch, ogni effetto rilevante
+sulle prestazioni e tutto ciò che può servire per la comprensione della
+patch.  Assicuratevi che il changelog dica *perché*, vale la pena aggiungere
+la patch; un numero sorprendente di sviluppatori sbaglia nel fornire tale
+informazione.
+
+Qualsiasi codice che aggiunge una nuova interfaccia in spazio utente - inclusi
+nuovi file in sysfs o /proc - dovrebbe includere la documentazione di tale
+interfaccia così da permette agli sviluppatori dello spazio utente di sapere
+con cosa stanno lavorando.  Consultate: Documentation/ABI/README per avere una
+descrizione di come questi documenti devono essere impostati e quali
+informazioni devono essere fornite.
+
+Il file :ref:`Documentation/translations/it_IT/admin-guide/kernel-parameters.rst <kernelparameters>`
+descrive tutti i parametri di avvio del kernel.  Ogni patch che aggiunga
+nuovi parametri dovrebbe aggiungere nuove voci a questo file.
+
+Ogni nuova configurazione deve essere accompagnata da un testo di supporto
+che spieghi chiaramente le opzioni e spieghi quando l'utente potrebbe volerle
+selezionare.
+
+Per molti sottosistemi le informazioni sull'API interna sono documentate sotto
+forma di commenti formattati in maniera particolare; questi commenti possono
+essere estratti e formattati in differenti modi attraverso lo script
+"kernel-doc".  Se state lavorando all'interno di un sottosistema che ha
+commenti kerneldoc dovreste mantenerli e aggiungerli, in maniera appropriata,
+per le funzioni disponibili esternamente.  Anche in aree che non sono molto
+documentate, non c'è motivo per non aggiungere commenti kerneldoc per il
+futuro; infatti, questa può essere un'attività utile per sviluppatori novizi
+del kernel.  Il formato di questi commenti, assieme alle informazione su come
+creare modelli per kerneldoc, possono essere trovati in
+:ref:`Documentation/translations/it_IT/doc-guide/ <doc_guide>`.
+
+Chiunque legga un ammontare significativo di codice kernel noterà che, spesso,
+i commenti si fanno maggiormente notare per la loro assenza.  Ancora una volta,
+le aspettative verso il nuovo codice sono più alte rispetto al passato;
+inserire codice privo di commenti sarà più difficile.  Detto ciò, va aggiunto
+che non si desiderano commenti prolissi per il codice.  Il codice dovrebbe
+essere, di per sé, leggibile, con dei commenti che spieghino gli aspetti più
+sottili.
+
+Determinate cose dovrebbero essere sempre commentate.  L'uso di barriere
+di memoria dovrebbero essere accompagnate da una riga che spieghi perché sia
+necessaria.  Le regole di sincronizzazione per le strutture dati, generalmente,
+necessitano di una spiegazioni da qualche parte.  Le strutture dati più
+importanti, in generale, hanno bisogno di una documentazione onnicomprensiva.
+Le dipendenze che non sono ovvie tra bit separati di codice dovrebbero essere
+indicate.  Tutto ciò che potrebbe indurre un inserviente del codice a fare
+una "pulizia" incorretta, ha bisogno di un commento che dica perché è stato
+fatto in quel modo.  E così via.
+
+Cambiamenti interni dell'API
+----------------------------
+
+L'interfaccia binaria fornita dal kernel allo spazio utente non può essere
+rotta tranne che in circostanze eccezionali.  L'interfaccia di programmazione
+interna al kernel, invece, è estremamente fluida e può essere modificata al
+bisogno.  Se vi trovate a dover lavorare attorno ad un'API del kernel o
+semplicemente non state utilizzando una funzionalità offerta perché questa
+non rispecchia i vostri bisogni, allora questo potrebbe essere un segno che
+l'API ha bisogno di essere cambiata.  In qualità di sviluppatore del kernel,
+hai il potere di fare questo tipo di modifica.
+
+Ci sono ovviamente alcuni punti da cogliere.  I cambiamenti API possono essere
+fatti, ma devono essere giustificati.  Quindi ogni patch che porta ad una
+modifica dell'API interna dovrebbe essere accompagnata da una descrizione
+della modifica in sé e del perché essa è necessaria.  Questo tipo di
+cambiamenti dovrebbero, inoltre, essere fatti in una patch separata, invece di
+essere sepolti all'interno di una patch più grande.
+
+L'altro punto da cogliere consiste nel fatto che uno sviluppatore che
+modifica l'API deve, in generale, essere responsabile della correzione
+di tutto il codice del kernel che viene rotto per via della sua modifica.
+Per una funzione ampiamente usata, questo compito può condurre letteralmente
+a centinaia o migliaia di modifiche, molte delle quali sono in conflitto con
+il lavoro svolto da altri sviluppatori.  Non c'è bisogno di dire che questo
+può essere un lavoro molto grosso, quindi è meglio essere sicuri che la
+motivazione sia ben solida.  Notate che lo strumento Coccinelle può fornire
+un aiuto con modifiche estese dell'API.
+
+Quando viene fatta una modifica API incompatibile, una persona dovrebbe,
+quando possibile, assicurarsi che quel codice non aggiornato sia trovato
+dal compilatore.  Questo vi aiuterà ad essere sicuri d'avere trovato,
+tutti gli usi di quell'interfaccia.  Inoltre questo avviserà gli sviluppatori
+di codice fuori dal kernel che c'è un cambiamento per il quale è necessario del
+lavoro.  Il supporto al codice fuori dal kernel non è qualcosa di cui gli
+sviluppatori del kernel devono preoccuparsi, ma non dobbiamo nemmeno rendere
+più difficile del necessario la vita agli sviluppatori di questo codice.

Documentation/translations/it_IT/process/5.Posting.rst

@@ -1,12 +1,348 @@
 .. include:: ../disclaimer-ita.rst
 
-:Original: :ref:`Documentation/process/4.Posting.rst <development_posting>`
+:Original: :ref:`Documentation/process/5.Posting.rst <development_posting>`
+:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
 
 .. _it_development_posting:
 
 Pubblicare modifiche
 ====================
 
-.. warning::
+Prima o poi arriva il momento in cui il vostro lavoro è pronto per essere
+presentato alla comunità per una revisione ed eventualmente per la sua
+inclusione nel ramo principale del kernel.  Com'era prevedibile,
+la comunità di sviluppo del kernel ha elaborato un insieme di convenzioni
+e di procedure per la pubblicazione delle patch; seguirle renderà la vita
+più facile a tutti quanti.  Questo documento cercherà di coprire questi
+argomenti con un ragionevole livello di dettaglio; più informazioni possono
+essere trovare nella cartella 'Documentation', nei file
+:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`,
+:ref:`translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>`, e
+:ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
 
-    TODO ancora da tradurre
+
+Quando pubblicarle
+------------------
+
+C'è sempre una certa resistenza nel pubblicare patch finché non sono
+veramente "pronte".  Per semplici patch questo non è un problema.
+Ma quando il lavoro è di una certa complessità, c'è molto da guadagnare
+dai riscontri che la comunità può darvi prima che completiate il lavoro.
+Dovreste considerare l'idea di pubblicare un lavoro incompleto, o anche
+preparare un ramo git disponibile agli sviluppatori interessati, cosicché
+possano stare al passo col vostro lavoro in qualunque momento.
+
+Quando pubblicate del codice che non è considerato pronto per l'inclusione,
+è bene che lo diciate al momento della pubblicazione.  Inoltre, aggiungete
+informazioni sulle cose ancora da sviluppare e sui problemi conosciuti.
+Poche persone guarderanno delle patch che si sa essere fatte a metà,
+ma quelli che lo faranno penseranno di potervi aiutare a condurre il vostro
+sviluppo nella giusta direzione.
+
+
+Prima di creare patch
+---------------------
+
+Ci sono un certo numero di cose che dovreste fare prima di considerare
+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.
+
+ - Assicuratevi che il vostro codice sia conforme alla linee guida del
+   kernel sullo stile del codice.
+
+ - La vostra patch ha delle conseguenze in termini di prestazioni?
+   Se è così, dovreste eseguire dei *benchmark* che mostrino il loro
+   impatto (anche positivo); un riassunto dei risultati dovrebbe essere
+   incluso nella patch.
+
+ - Siate certi d'avere i diritti per pubblicare il codice.  Se questo
+   lavoro è stato fatto per un datore di lavoro, egli avrà dei diritti su
+   questo lavoro e dovrà quindi essere d'accordo alla sua pubblicazione
+   con una licenza GPL
+
+Come regola generale, pensarci un po' di più prima di inviare il codice
+ripaga quasi sempre lo sforzo.
+
+
+Preparazione di una patch
+-------------------------
+
+La preparazione delle patch per la pubblicazione può richiedere una quantità
+di lavoro significativa, ma, ripetiamolo ancora, generalmente sconsigliamo
+di risparmiare tempo in questa fase, anche sul breve periodo.
+
+Le patch devono essere preparate per una specifica versione del kernel.
+Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale
+così come lo si trova nei sorgenti git di Linus.  Quando vi basate sul ramo
+principale, cominciate da un punto di rilascio ben noto - uno stabile o
+un -rc - piuttosto che creare il vostro ramo da quello principale in un punto
+a caso.
+
+Per facilitare una revisione e una verifica più estesa, potrebbe diventare
+necessaria la produzione di versioni per -mm, linux-next o i sorgenti di un
+sottosistema.  Basare questa patch sui suddetti sorgenti potrebbe richiedere
+un lavoro significativo nella risoluzione dei conflitti e nella correzione dei
+cambiamenti di API; questo potrebbe variare a seconda dell'area d'interesse
+della vostra patch e da quello che succede altrove nel kernel.
+
+Solo le modifiche più semplici dovrebbero essere preparate come una singola
+patch; tutto il resto dovrebbe essere preparato come una serie logica di
+modifiche.  Spezzettare le patch è un po' un'arte; alcuni sviluppatori
+passano molto tempo nel capire come farlo in modo che piaccia alla comunità.
+Ci sono alcune regole spannometriche, che comunque possono aiutare
+considerevolmente:
+
+ - La serie di patch che pubblicherete, quasi sicuramente, non sarà
+   come quella che trovate nel vostro sistema di controllo di versione.
+   Invece, le vostre modifiche dovranno essere considerate nella loro forma
+   finale, e quindi separate in parti che abbiano un senso.  Gli sviluppatori
+   sono interessati in modifiche che siano discrete e indipendenti, non
+   alla strada che avete percorso per ottenerle.
+
+ - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
+   patch separata.  Queste modifiche possono essere piccole ("aggiunto un
+   campo in questa struttura") o grandi (l'aggiunta di un driver nuovo,
+   per esempio), ma dovrebbero essere concettualmente piccole da permettere
+   una descrizione in una sola riga.  Ogni patch dovrebbe fare modifiche
+   specifiche che si possano revisionare indipendentemente e di cui si possa
+   verificare la veridicità.
+
+ - Giusto per riaffermare quando detto sopra: non mischiate diversi tipi di
+   modifiche nella stessa patch.  Se una modifica corregge un baco critico
+   per la sicurezza, riorganizza alcune strutture, e riformatta il codice,
+   ci sono buone probabilità che venga ignorata e che la correzione importante
+   venga persa.
+
+ - Ogni modifica dovrebbe portare ad un kernel che compila e funziona
+   correttamente; se la vostra serie di patch si interrompe a metà il
+   risultato dovrebbe essere comunque un kernel funzionante.  L'applicazione
+   parziale di una serie di patch è uno scenario comune nel quale il
+   comando "git bisect" viene usato per trovare delle regressioni; se il
+   risultato è un kernel guasto, renderete la vita degli sviluppatori più
+   difficile così come quella di chi s'impegna nel nobile lavoro di
+   scovare i problemi.
+
+ - Però, non strafate.  Una volta uno sviluppatore pubblicò una serie di 500
+   patch che modificavano un unico file - un atto che non lo rese la persona
+   più popolare sulla lista di discussione del kernel.  Una singola patch
+   può essere ragionevolmente grande fintanto che contenga un singolo
+   cambiamento *logico*.
+
+ - Potrebbe essere allettante l'idea di aggiungere una nuova infrastruttura
+   come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
+   finché l'ultima patch della serie non abilita tutto quanto.  Quando è
+   possibile, questo dovrebbe essere evitato; se questa serie aggiunge delle
+   regressioni, "bisect" indicherà quest'ultima patch come causa del
+   problema anche se il baco si trova altrove.  Possibilmente, quando una
+   patch aggiunge del nuovo codice dovrebbe renderlo attivo immediatamente.
+
+Lavorare per creare la serie di patch perfetta potrebbe essere frustrante
+perché richiede un certo tempo e soprattutto dopo che il "vero lavoro" è
+già stato fatto.  Quando ben fatto, comunque, è tempo ben speso.
+
+
+Formattazione delle patch e i changelog
+---------------------------------------
+
+Quindi adesso avete una serie perfetta di patch pronte per la pubblicazione,
+ma il lavoro non è davvero finito.  Ogni patch deve essere preparata con
+un messaggio che spieghi al resto del mondo, in modo chiaro e veloce,
+il suo scopo.  Per ottenerlo, ogni patch sarà composta dai seguenti elementi:
+
+ - Un campo opzionale "From" col nome dell'autore della patch.  Questa riga
+   è necessaria solo se state passando la patch di qualcun altro via email,
+   ma nel dubbio non fa di certo male aggiungerlo.
+
+ - Una descrizione di una riga che spieghi cosa fa la patch.  Questo
+   messaggio dovrebbe essere sufficiente per far comprendere al lettore lo
+   scopo della patch senza altre informazioni.  Questo messaggio,
+   solitamente, presenta in testa il nome del sottosistema a cui si riferisce,
+   seguito dallo scopo della patch.  Per esempio:
+
+   ::
+
+	gpio: fix build on CONFIG_GPIO_SYSFS=n
+
+ - Una riga bianca seguita da una descrizione dettagliata della patch.
+   Questa descrizione può essere lunga tanto quanto serve; dovrebbe spiegare
+   cosa fa e perché dovrebbe essere aggiunta al kernel.
+
+ - Una o più righe etichette, con, minimo, una riga *Signed-off-by:*
+   col nome dall'autore della patch.  Queste etichette verranno descritte
+   meglio più avanti.
+
+Gli elementi qui sopra, assieme, formano il changelog di una patch.
+Scrivere un buon changelog è cruciale ma è spesso un'arte trascurata;
+vale la pena spendere qualche parola in più al riguardo.  Quando scrivete
+un changelog dovreste tenere ben presente che molte persone leggeranno
+le vostre parole.  Queste includono i manutentori di un sotto-sistema, e i
+revisori che devono decidere se la patch debba essere inclusa o no,
+le distribuzioni e altri manutentori che cercano di valutare se la patch
+debba essere applicata su kernel più vecchi, i cacciatori di bachi che si
+chiederanno se la patch è la causa di un problema che stanno cercando,
+gli utenti che vogliono sapere com'è cambiato il kernel, e molti altri.
+Un buon changelog fornisce le informazioni necessarie a tutte queste
+persone nel modo più diretto e conciso possibile.
+
+A questo scopo, la riga riassuntiva dovrebbe descrivere gli effetti della
+modifica e la motivazione della patch nel modo migliore possibile nonostante
+il limite di una sola riga.  La descrizione dettagliata può spiegare meglio
+i temi e fornire maggiori informazioni.  Se una patch corregge un baco,
+citate, se possibile, il commit che lo introdusse (e per favore, quando
+citate un commit aggiungete sia il suo identificativo che il titolo),
+Se il problema è associabile ad un file di log o all' output del compilatore,
+includeteli al fine d'aiutare gli altri a trovare soluzioni per lo stesso
+problema.  Se la modifica ha lo scopo di essere di supporto a sviluppi
+successivi, ditelo.  Se le API interne vengono cambiate, dettagliate queste
+modifiche e come gli altri dovrebbero agire per applicarle.  In generale,
+più riuscirete ad entrare nei panni di tutti quelli che leggeranno il
+vostro changelog, meglio sarà il changelog (e il kernel nel suo insieme).
+
+Non serve dirlo, un changelog dovrebbe essere il testo usato nel messaggio
+di commit in un sistema di controllo di versione.  Sarà seguito da:
+
+ - La patch stessa, nel formato unificato per patch ("-u").  Usare
+   l'opzione "-p" assocerà alla modifica il nome della funzione alla quale
+   si riferisce, rendendo il risultato più facile da leggere per gli altri.
+
+Dovreste evitare di includere nelle patch delle modifiche per file
+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:
+
+::
+
+	tag: Full Name <email address>  optional-other-stuff
+
+Le etichette in uso più comuni sono:
+
+ - Signed-off-by: questa è la certificazione che lo sviluppatore ha il diritto
+   di sottomettere la patch per l'integrazione nel kernel.  Questo rappresenta
+   il consenso verso il certificato d'origine degli sviluppatori, il testo
+   completo potrà essere trovato in
+   :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
+   Codice che non presenta una firma appropriata non potrà essere integrato.
+
+ - Co-developed-by: indica che la patch è stata sviluppata anche da un altro
+   sviluppatore assieme all'autore originale.  Questo è utile quando più
+   persone lavorano sulla stessa patch.  Da notare che questa persona deve
+   avere anche una riga "Signed-off-by:" nella patch.
+
+ - Acked-by: indica il consenso di un altro sviluppatore (spesso il manutentore
+   del codice in oggetto) all'integrazione della patch nel kernel.
+
+ - Tested-by: menziona la persona che ha verificato la patch e l'ha trovata
+   funzionante.
+
+ - Reviwed-by: menziona lo sviluppatore che ha revisionato la patch; per
+   maggiori dettagli leggete la dichiarazione dei revisori in
+   :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
+
+ - Reported-by: menziona l'utente che ha riportato il problema corretto da
+   questa patch; quest'etichetta viene usata per dare credito alle persone
+   che hanno verificato il codice e ci hanno fatto sapere quando le cose non
+   funzionavano correttamente.
+
+ - 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.
+
+Inviare la modifica
+-------------------
+
+Prima di inviare la vostra patch, ci sarebbero ancora un paio di cose di cui
+dovreste aver cura:
+
+ - Siete sicuri che il vostro programma di posta non corromperà le patch?
+   Le patch che hanno spazi bianchi in libertà o andate a capo aggiunti
+   dai programmi di posta non funzioneranno per chi le riceve, e spesso
+   non verranno nemmeno esaminate in dettaglio.  Se avete un qualsiasi dubbio,
+   inviate la patch a voi stessi e verificate che sia integra.
+
+   :ref:`Documentation/translations/it_IT/process/email-clients.rst <it_email_clients>`
+   contiene alcuni suggerimenti utili sulla configurazione dei programmi
+   di posta al fine di inviare patch.
+
+ - Siete sicuri che la vostra patch non contenga sciocchi errori?  Dovreste
+   sempre processare le patch con scripts/checkpatch.pl e correggere eventuali
+   problemi riportati.  Per favore tenete ben presente che checkpatch.pl non è
+   più intelligente di voi, nonostante sia il risultato di un certa quantità di
+   ragionamenti su come debba essere una patch per il kernel.  Se seguire
+   i suggerimenti di checkpatch.pl rende il codice peggiore, allora non fatelo.
+
+Le patch dovrebbero essere sempre inviate come testo puro.  Per favore non
+inviatele come allegati; questo rende molto più difficile, per i revisori,
+citare parti della patch che si vogliono commentare.  Invece, mettete la vostra
+patch direttamente nel messaggio.
+
+Quando inviate le patch, è importante inviarne una copia a tutte le persone che
+potrebbero esserne interessate.  Al contrario di altri progetti, il kernel
+incoraggia le persone a peccare nell'invio di tante copie; non presumente che
+le persone interessate vedano i vostri messaggi sulla lista di discussione.
+In particolare le copie dovrebbero essere inviate a:
+
+ - I manutentori dei sottosistemi affetti della modifica.  Come descritto
+   in precedenza, il file MAINTAINERS è il primo luogo dove cercare i nomi
+   di queste persone.
+
+ - Altri sviluppatori che hanno lavorato nello stesso ambiente - specialmente
+   quelli che potrebbero lavorarci proprio ora.  Usate git potrebbe essere
+   utile per vedere chi altri ha modificato i file su cui state lavorando.
+
+ - Se state rispondendo a un rapporto su un baco, o a una richiesta di
+   funzionalità, includete anche gli autori di quei rapporti/richieste.
+
+ - Inviate una copia alle liste di discussione interessate, o, se nient'altro
+   è adatto, alla lista linux-kernel
+
+ - Se state correggendo un baco, pensate se la patch dovrebbe essere inclusa
+   nel prossimo rilascio stabile.  Se è così, la lista di discussione
+   stable@vger.kernel.org dovrebbe riceverne una copia.  Aggiungete anche
+   l'etichetta "Cc: stable@vger.kernel.org" nella patch stessa; questo
+   permetterà alla squadra *stable* di ricevere una notifica quando questa
+   correzione viene integrata nel ramo principale.
+
+Quando scegliete i destinatari della patch, è bene avere un'idea di chi
+pensiate che sia colui che, eventualmente, accetterà la vostra patch e
+la integrerà.  Nonostante sia possibile inviare patch direttamente a
+Linus Torvalds, e lasciare che sia lui ad integrarle,solitamente non è la
+strada migliore da seguire.  Linus è occupato, e ci sono dei manutentori di
+sotto-sistema che controllano una parte specifica del kernel.  Solitamente,
+vorreste che siano questi manutentori ad integrare le vostre patch.  Se non
+c'è un chiaro manutentore, l'ultima spiaggia è spesso Andrew Morton.
+
+Le patch devono avere anche un buon oggetto.  Il tipico formato per l'oggetto
+di una patch assomiglia a questo:
+
+::
+
+	[PATCH nn/mm] subsys: one-line description of the patch
+
+dove "nn" è il numero ordinale della patch, "mm" è il numero totale delle patch
+nella serie, e "subsys" è il nome del sottosistema interessato.  Chiaramente,
+nn/mm può essere omesso per una serie composta da una singola patch.
+
+Se avete una significative serie di patch, è prassi inviare una descrizione
+introduttiva come parte zero.  Tuttavia questa convenzione non è universalmente
+seguita; se la usate, ricordate che le informazioni nell'introduzione non
+faranno parte del changelog del kernel.  Quindi per favore, assicuratevi che
+ogni patch abbia un changelog completo.
+
+In generale, la seconda parte e quelle successive di una patch "composta"
+dovrebbero essere inviate come risposta alla prima, cosicché vengano viste
+come un unico *thread*.  Strumenti come git e quilt hanno comandi per inviare
+gruppi di patch con la struttura appropriata.  Se avete una serie lunga
+e state usando git, per favore state alla larga dall'opzione --chain-reply-to
+per evitare di creare un annidamento eccessivo.

Documentation/translations/it_IT/process/6.Followthrough.rst

@@ -1,10 +1,240 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
 
+.. _it_development_followthrough:
+
+=============
 Completamento
 =============
 
-.. warning::
+A questo punto, avete seguito le linee guida fino a questo punto e, con
+l'aggiunta delle vostre capacità ingegneristiche, avete pubblicato una serie
+perfetta di patch.  Uno dei più grandi errori che possono essere commessi
+persino da sviluppatori kernel esperti è quello di concludere che il
+lavoro sia ormai finito.  In verità, la pubblicazione delle patch
+simboleggia una transizione alla fase successiva del processo, con,
+probabilmente, ancora un po' di lavoro da fare.
 
-    TODO ancora da tradurre
+È raro che una modifica sia così bella alla sua prima pubblicazione che non
+ci sia alcuno spazio di miglioramento.  Il programma di sviluppo del kernel
+riconosce questo fatto e quindi, è fortemente orientato al miglioramento
+del codice pubblicato.  Voi, in qualità di autori del codice, dovrete
+lavorare con la comunità del kernel per assicurare che il vostro codice
+mantenga gli standard qualitativi richiesti.  Un fallimento in questo
+processo è quasi come impedire l'inclusione delle vostre patch nel
+ramo principale.
+
+Lavorare con i revisori
+=======================
+
+Una patch che abbia una certa rilevanza avrà ricevuto numerosi commenti
+da parte di altri sviluppatori dato che avranno revisionato il codice.
+Lavorare con i revisori può rivelarsi, per molti sviluppatori, la parte
+più intimidatoria del processo di sviluppo del kernel.  La vita può esservi
+resa molto più facile se tenete presente alcuni dettagli:
+
+ - Se avete descritto la vostra modifica correttamente, i revisori ne
+   comprenderanno il valore e il perché vi siete presi il disturbo di
+   scriverla.  Ma tale valore non li tratterrà dal porvi una domanda
+   fondamentale: come verrà mantenuto questo codice nel kernel nei prossimi
+   cinque o dieci anni?  Molti dei cambiamenti che potrebbero esservi
+   richiesti - da piccoli problemi di stile a sostanziali ristesure -
+   vengono dalla consapevolezza che Linux resterà in circolazione e in
+   continuo sviluppo ancora per diverse decadi.
+
+ - La revisione del codice è un duro lavoro, ed è un mestiere poco
+   riconosciuto; le persone ricordano chi ha scritto il codice, ma meno
+   fama è attribuita a chi lo ha revisionato.  Quindi i revisori potrebbero
+   divenire burberi, specialmente quando vendono i medesimi errori venire
+   fatti ancora e ancora.  Se ricevete una revisione che vi sembra abbia
+   un tono arrabbiato, insultante o addirittura offensivo, resistente alla
+   tentazione di rispondere a tono.  La revisione riguarda il codice e non
+   la persona, e i revisori non vi stanno attaccando personalmente.
+
+ - Similarmente, i revisori del codice non stanno cercando di promuovere
+   i loro interessi a vostre spese.  Gli sviluppatori del kernel spesso si
+   aspettano di lavorare sul kernel per anni, ma sanno che il loro datore
+   di lavoro può cambiare.  Davvero, senza praticamente eccezioni, loro
+   stanno lavorando per la creazione del miglior kernel possibile; non
+   stanno cercando di creare un disagio ad aziende concorrenti.
+
+Quello che si sta cercando di dire è che, quando i revisori vi inviano degli
+appunti dovete fare attenzione alle osservazioni tecniche che vi stanno
+facendo.  Non lasciate che il loro modo di esprimersi o il vostro orgoglio
+impediscano che ciò accada.  Quando avete dei suggerimenti sulla revisione,
+prendetevi il tempo per comprendere cosa il revisore stia cercando di
+comunicarvi.  Se possibile, sistemate le cose che il revisore vi chiede di
+modificare.  E rispondete al revisore ringraziandolo e spiegando come
+intendete fare.
+
+Notate che non dovete per forza essere d'accordo con ogni singola modifica
+suggerita dai revisori.  Se credete che il revisore non abbia compreso
+il vostro codice, spiegateglielo.  Se avete un'obiezione tecnica da fargli
+su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione
+al problema.  Se la vostra spiegazione ha senso, il revisore la accetterà.
+Tuttavia, la vostra motivazione potrebbe non essere del tutto persuasiva,
+specialmente se altri iniziano ad essere d'accordo con il revisore.
+Prendetevi quindi un po' di tempo per pensare ancora alla cosa. Può risultare
+facile essere accecati dalla propria soluzione al punto che non realizzate che
+c'è qualcosa di fondamentalmente sbagliato o, magari, non state nemmeno
+risolvendo il problema giusto.
+
+Andrew Morton suggerisce che ogni suggerimento di revisione che non è
+presente nella modifica del codice dovrebbe essere inserito in un commento
+aggiuntivo; ciò può essere d'aiuto ai futuri revisori nell'evitare domande
+che sorgono al primo sguardo.
+
+Un errore fatale è quello di ignorare i commenti di revisione nella speranza
+che se ne andranno.  Non andranno via.  Se pubblicherete nuovamente il
+codice senza aver risposto ai commenti ricevuti, probabilmente le vostre
+modifiche non andranno da nessuna parte.
+
+Parlando di ripubblicazione del codice: per favore tenete a mente che i
+revisori non ricorderanno tutti i dettagli del codice che avete pubblicato
+l'ultima volta. Quindi è sempre una buona idea quella di ricordare ai
+revisori le questioni sollevate precedetemene e come le avete risolte.
+I revisori non dovrebbero star lì a cercare all'interno degli archivi per
+famigliarizzare con ciò che è stato detto l'ultima volta; se li aiutate
+in questo senso, saranno di umore migliore quando riguarderanno il vostro
+codice.
+
+Se invece avete cercato di far tutto correttamente ma le cose continuano
+a non andar bene?  Molti disaccordi di natura tecnica possono essere risolti
+attraverso la discussione, ma ci sono volte dove qualcuno deve prendere
+una decisione.  Se credete veramente che tale decisione andrà contro di voi
+ingiustamente, potete sempre tentare di rivolgervi a qualcuno più
+in alto di voi.  Per cose di questo genere la persona con più potere è
+Andrew Morton.  Andrew è una figura molto rispettata all'interno della
+comunità di sviluppo del kernel; lui può spesso sbrogliare situazioni che
+sembrano irrimediabilmente bloccate.  Rivolgersi ad Andrew non deve essere
+fatto alla leggera, e non deve essere fatto prima di aver esplorato tutte
+le altre alternative.  E tenete a mente, ovviamente, che nemmeno lui
+potrebbe non essere d'accordo con voi.
+
+Cosa accade poi
+===============
+
+Se la modifica è ritenuta un elemento valido da essere aggiunta al kernel,
+e una volta che la maggior parte degli appunti dei revisori sono stati
+sistemati, il passo successivo solitamente è quello di entrare in un
+sottosistema gestito da un manutentore.  Come ciò avviene dipende dal
+sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
+In particolare, ci potrebbero essere diversi sorgenti - uno, magari, dedicato
+alle modifiche pianificate per la finestra di fusione successiva, e un altro
+per il lavoro di lungo periodo.
+
+Per le modifiche proposte in aree per le quali non esiste un sottosistema
+preciso (modifiche di gestione della memoria, per esempio), i sorgenti di
+ripiego finiscono per essere -mm.  Ed anche le modifiche che riguardano
+più sottosistemi possono finire in quest'ultimo.
+
+L'inclusione nei sorgenti di un sottosistema può comportare per una patch,
+un alto livello di visibilità.  Ora altri sviluppatori che stanno lavorando
+in quei medesimi sorgenti avranno le vostre modifiche.  I sottosistemi
+solitamente riforniscono anche Linux-next, rendendo i propri contenuti
+visibili all'intera comunità di sviluppo.  A questo punto, ci sono buone
+possibilità per voi di ricevere ulteriori commenti da un nuovo gruppo di
+revisori; anche a questi commenti dovrete rispondere come avete già fatto per
+gli altri.
+
+Ciò che potrebbe accadere a questo punto, in base alla natura della vostra
+modifica, riguarda eventuali conflitti con il lavoro svolto da altri.
+Nella peggiore delle situazioni, i conflitti più pesanti tra modifiche possono
+concludersi con la messa a lato di alcuni dei lavori svolti cosicché le
+modifiche restanti possano funzionare ed essere integrate.  Altre volte, la
+risoluzione dei conflitti richiederà del lavoro con altri sviluppatori e,
+possibilmente, lo spostamento di alcune patch da dei sorgenti a degli altri
+in modo da assicurare che tutto sia applicato in modo pulito.  Questo lavoro
+può rivelarsi una spina nel fianco, ma consideratevi fortunati: prima
+dell'avvento dei sorgenti linux-next, questi conflitti spesso emergevano solo
+durante l'apertura della finestra di integrazione e dovevano essere smaltiti
+in fretta.  Ora essi possono essere risolti comodamente, prima dell'apertura
+della finestra.
+
+Un giorno, se tutto va bene, vi collegherete e vedrete che la vostra patch
+è stata inserita nel ramo principale de kernel. Congratulazioni!  Terminati
+i festeggiamenti (nel frattempo avrete inserito il vostro nome nel file
+MAINTAINERS) vale la pena ricordare una piccola cosa, ma importante: il
+lavoro non è ancora finito.  L'inserimento nel ramo principale porta con se
+nuove sfide.
+
+Cominciamo con il dire che ora la visibilità della vostra modifica è
+ulteriormente cresciuta.  Ci potrebbe portare ad una nuova fase di
+commenti dagli sviluppatori che non erano ancora a conoscenza della vostra
+patch.  Ignorarli potrebbe essere allettante dato che non ci sono più
+dubbi sull'integrazione della modifica.  Resistete a tale tentazione, dovete
+mantenervi disponibili agli sviluppatori che hanno domande o suggerimenti
+per voi.
+
+Ancora più importante: l'inclusione nel ramo principale mette il vostro
+codice nelle mani di un gruppo di *tester* molto più esteso.  Anche se avete
+contribuito ad un driver per un hardware che non è ancora disponibile, sarete
+sorpresi da quante persone inseriranno il vostro codice nei loro kernel.
+E, ovviamente, dove ci sono *tester*, ci saranno anche dei rapporti su
+eventuali bachi.
+
+La peggior specie di rapporti sono quelli che indicano delle regressioni.
+Se la vostra modifica causa una regressione, avrete un gran numero di
+occhi puntati su di voi; la regressione deve essere sistemata il prima
+possibile.  Se non vorrete o non sarete capaci di sistemarla (e nessuno
+lo farà per voi), la vostra modifica sarà quasi certamente rimossa durante
+la fase di stabilizzazione.  Oltre alla perdita di tutto il lavoro svolto
+per far si che la vostra modifica fosse inserita nel ramo principale,
+l'avere una modifica rimossa a causa del fallimento nel sistemare una
+regressione, potrebbe rendere più difficile per voi far accettare
+il vostro lavoro in futuro.
+
+Dopo che ogni regressione è stata affrontata, ci potrebbero essere altri
+bachi ordinari da "sconfiggere".  Il periodo di stabilizzazione è la
+vostra migliore opportunità per sistemare questi bachi e assicurarvi che
+il debutto del vostro codice nel ramo principale del kernel sia il più solido
+possibile.  Quindi, per favore, rispondete ai rapporti sui bachi e ponete
+rimedio, se possibile, a tutti i problemi.  È a questo che serve il periodo
+di stabilizzazione; potete iniziare creando nuove fantastiche modifiche
+una volta che ogni problema con le vecchie sia stato risolto.
+
+Non dimenticate che esistono altre pietre miliari che possono generare
+rapporti sui bachi: il successivo rilascio stabile, quando una distribuzione
+importante usa una versione del kernel nel quale è presente la vostra
+modifica, eccetera.  Il continuare a rispondere a questi rapporti è fonte di
+orgoglio per il vostro lavoro.  Se questa non è una sufficiente motivazione,
+allora, è anche consigliabile considera che la comunità di sviluppo ricorda
+gli sviluppatori che hanno perso interesse per il loro codice una volta
+integrato.  La prossima volta che pubblicherete una patch, la comunità
+la valuterà anche sulla base del fatto che non sarete disponibili a
+prendervene cura anche nel futuro.
+
+
+Altre cose che posso accadere
+=============================
+
+Un giorno, potreste aprire la vostra email e vedere che qualcuno vi ha
+inviato una patch per il vostro codice.  Questo, dopo tutto, è uno dei
+vantaggi di avere il vostro codice "là fuori".  Se siete d'accordo con
+la modifica, potrete anche inoltrarla ad un manutentore di sottosistema
+(assicuratevi di includere la riga "From:" cosicché l'attribuzione sia
+corretta, e aggiungete una vostra firma "Signed-off-by"), oppure inviate
+un "Acked-by:" e lasciate che l'autore originale la invii.
+
+Se non siete d'accordo con la patch, inviate una risposta educata
+spiegando il perché.  Se possibile, dite all'autore quali cambiamenti
+servirebbero per rendere la patch accettabile da voi.  C'è una certa
+riluttanza nell'inserire modifiche con un conflitto fra autore
+e manutentore del codice, ma solo fino ad un certo punto.  Se siete visti
+come qualcuno che blocca un buon lavoro senza motivo, quelle patch vi
+passeranno oltre e andranno nel ramo principale in ogni caso. Nel kernel
+Linux, nessuno ha potere di veto assoluto su alcun codice.  Eccezione
+fatta per Linus, forse.
+
+In rarissime occasioni, potreste vedere qualcosa di completamente diverso:
+un altro sviluppatore che pubblica una soluzione differente al vostro
+problema.  A questo punto, c'è una buona probabilità che una delle due
+modifiche non verrà integrata, e il "c'ero prima io" non è considerato
+un argomento tecnico rilevante.  Se la modifica di qualcun'altro rimpiazza
+la vostra ed entra nel ramo principale, esiste un unico modo di reagire:
+siate contenti che il vostro problema sia stato risolto e andate avanti con
+il vostro lavoro.  L'avere un vostro lavoro spintonato da parte in questo
+modo può essere avvilente e scoraggiante, ma la comunità ricorderà come
+avrete reagito anche dopo che avrà dimenticato quale fu la modifica accettata.

Documentation/translations/it_IT/process/7.AdvancedTopics.rst

@@ -1,13 +1,191 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/7.AdvancedTopics.rst <development_advancedtopics>`
-
+:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
 
 .. _it_development_advancedtopics:
 
 Argomenti avanzati
 ==================
 
-.. warning::
+A questo punto, si spera, dovreste avere un'idea su come funziona il processo
+di sviluppo.  Ma rimane comunque molto da imparare!  Questo capitolo copre
+alcuni argomenti che potrebbero essere utili per gli sviluppatori che stanno
+per diventare parte integrante del processo di sviluppo del kernel.
 
-    TODO ancora da tradurre
+Gestire le modifiche con git
+-----------------------------
+
+L'uso di un sistema distribuito per il controllo delle versioni del kernel
+ebbe iniziò nel 2002 quando Linux iniziò a provare il programma proprietario
+BitKeeper.  Nonostante l'uso di BitKeeper fosse opinabile, di certo il suo
+approccio alla gestione dei sorgenti non lo era.  Un sistema distribuito per
+il controllo delle versioni accelerò immediatamente lo sviluppo del kernel.
+Oggigiorno, ci sono diverse alternative libere a BitKeeper.  Per il meglio o il
+peggio, il progetto del kernel ha deciso di usare git per gestire i sorgenti.
+
+Gestire le modifiche con git può rendere la vita dello sviluppatore molto
+più facile, specialmente quando il volume delle modifiche cresce.
+Git ha anche i suoi lati taglienti che possono essere pericolosi; è uno
+strumento giovane e potente che è ancora in fase di civilizzazione da parte
+dei suoi sviluppatori.  Questo documento non ha lo scopo di insegnare l'uso
+di git ai suoi lettori; ci sarebbe materiale a sufficienza per un lungo
+documento al riguardo.  Invece, qui ci concentriamo in particolare su come
+git è parte del processo di sviluppo del kernel.  Gli sviluppatori che
+desiderassero diventare agili con git troveranno più informazioni ai
+seguenti indirizzi:
+
+	http://git-scm.com/
+
+	http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
+
+e su varie guide che potrete trovare su internet.
+
+La prima cosa da fare prima di usarlo per produrre patch che saranno
+disponibili ad altri, è quella di leggere i siti qui sopra e di acquisire una
+base solida su come funziona git.  Uno sviluppatore che sappia usare git
+dovrebbe essere capace di ottenere una copia del repositorio principale,
+esplorare la storia della revisione, registrare le modifiche, usare i rami,
+eccetera.  Una certa comprensione degli strumenti git per riscrivere la storia
+(come ``rebase``) è altrettanto utile.  Git ha i propri concetti e la propria
+terminologia; un nuovo utente dovrebbe conoscere *refs*, *remote branch*,
+*index*, *fast-forward merge*, *push* e *pull*, *detached head*, eccetera.
+Il tutto potrebbe essere un po' intimidatorio visto da fuori, ma con un po'
+di studio i concetti non saranno così difficili da capire.
+
+Utilizzare git per produrre patch da sottomettere via email può essere
+un buon esercizio da fare mentre si sta prendendo confidenza con lo strumento.
+
+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,
+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 http://kernel.org/faq/.
+
+In git è normale avere a che fare con tanti rami.  Ogni linea di sviluppo
+può essere separata in "rami per argomenti" e gestiti indipendentemente.
+In git i rami sono facilissimi, per cui non c'è motivo per non usarli
+in libertà.  In ogni caso, non dovreste sviluppare su alcun ramo dal
+quale altri potrebbero attingere.  I rami disponibili pubblicamente dovrebbero
+essere creati con attenzione; integrate patch dai rami di sviluppo
+solo quando sono complete e pronte ad essere consegnate - non prima.
+
+Git offre alcuni strumenti che vi permettono di riscrivere la storia del
+vostro sviluppo.  Una modifica errata (diciamo, una che rompe la bisezione,
+oppure che ha un qualche tipo di baco evidente) può essere corretta sul posto
+o fatta sparire completamente dalla storia.  Una serie di patch può essere
+riscritta come se fosse stata scritta in cima al ramo principale di oggi,
+anche se ci avete lavorato per mesi.  Le modifiche possono essere spostate
+in modo trasparente da un ramo ad un altro.  E così via.  Un uso giudizioso
+di git per revisionare la storia può aiutare nella creazione di una serie
+di patch pulite e con meno problemi.
+
+Un uso eccessivo può portare ad altri tipi di problemi, tuttavia, oltre
+alla semplice ossessione per la creazione di una storia del progetto che sia
+perfetta.  Riscrivere la storia riscriverà le patch contenute in quella
+storia, trasformando un kernel verificato (si spera) in uno da verificare.
+Ma, oltre a questo, gli sviluppatori non possono collaborare se non condividono
+la stessa vista sulla storia del progetto; se riscrivete la storia dalla quale
+altri sviluppatori hanno attinto per i loro repositori, renderete la loro vita
+molto più difficile.  Quindi tenete conto di questa semplice regola generale:
+la storia che avete esposto ad altri, generalmente, dovrebbe essere vista come
+immutabile.
+
+Dunque, una volta che il vostro insieme di patch è stato reso disponibile
+pubblicamente non dovrebbe essere più sovrascritto.  Git tenterà di imporre
+questa regola, e si rifiuterà di pubblicare nuove patch che non risultino
+essere dirette discendenti di quelle pubblicate in precedenza (in altre parole,
+patch che non condividono la stessa storia).  È possibile ignorare questo
+controllo, e ci saranno momenti in cui sarà davvero necessario riscrivere
+un ramo già pubblicato.  Un esempio è linux-next dove le patch vengono
+spostate da un ramo all'altro al fine di evitare conflitti.  Ma questo tipo
+d'azione dovrebbe essere un'eccezione.  Questo è uno dei motivi per cui lo
+sviluppo dovrebbe avvenire in rami privati (che possono essere sovrascritti
+quando lo si ritiene necessario) e reso pubblico solo quando è in uno stato
+avanzato.
+
+Man mano che il ramo principale (o altri rami su cui avete basato le
+modifiche) avanza, diventa allettante l'idea di integrare tutte le patch
+per rimanere sempre aggiornati.  Per un ramo privato, il *rebase* può essere
+un modo semplice per rimanere aggiornati, ma questa non è un'opzione nel
+momento in cui il vostro ramo è stato esposto al mondo intero.
+*Merge* occasionali possono essere considerati di buon senso, ma quando
+diventano troppo frequenti confondono inutilmente la storia.  La tecnica
+suggerita in questi casi è quella di fare *merge* raramente, e più in generale
+solo nei momenti di rilascio (per esempio gli -rc del ramo principale).
+Se siete nervosi circa alcune patch in particolare, potete sempre fare
+dei *merge* di test in un ramo privato.  In queste situazioni git "rerere"
+può essere utile; questo strumento si ricorda come i conflitti di *merge*
+furono risolti in passato cosicché non dovrete fare lo stesso lavoro due volte.
+
+Una delle lamentele più grosse e ricorrenti sull'uso di strumenti come git
+è il grande movimento di patch da un repositorio all'altro che rende
+facile l'integrazione nel ramo principale di modifiche mediocri, il tutto
+sotto il naso dei revisori.  Gli sviluppatori del kernel tendono ad essere
+scontenti quando vedono succedere queste cose; preparare un ramo git con
+patch che non hanno ricevuto alcuna revisione o completamente avulse, potrebbe
+influire sulla vostra capacita di proporre, in futuro, l'integrazione dei
+vostri rami.  Citando Linus
+
+::
+
+	Potete inviarmi le vostre patch, ma per far si che io integri una
+	vostra modifica da git, devo sapere che voi sappiate cosa state
+	facendo, e ho bisogno di fidarmi *senza* dover passare tutte
+	le modifiche manualmente una per una.
+
+(http://lwn.net/Articles/224135/).
+
+Per evitare queste situazioni, assicuratevi che tutte le patch in un ramo
+siano strettamente correlate al tema delle modifiche; un ramo "driver fixes"
+non dovrebbe fare modifiche al codice principale per la gestione della memoria.
+E, più importante ancora, non usate un repositorio git per tentare di
+evitare il processo di revisione.  Pubblicate un sommario di quello che il
+vostro ramo contiene sulle liste di discussione più opportune, e , quando
+sarà il momento, richiedete che il vostro ramo venga integrato in linux-next.
+
+Se e quando altri inizieranno ad inviarvi patch per essere incluse nel
+vostro repositorio, non dovete dimenticare di revisionarle.  Inoltre
+assicuratevi di mantenerne le informazioni di paternità; al riguardo git "am"
+fa del suo meglio, ma potreste dover aggiungere una riga "From:" alla patch
+nel caso in cui sia arrivata per vie traverse.
+
+Quando richiedete l'integrazione, siate certi di fornire tutte le informazioni:
+dov'è il vostro repositorio, quale ramo integrare, e quali cambiamenti si
+otterranno dall'integrazione.  Il comando git request-pull può essere d'aiuto;
+preparerà una richiesta nel modo in cui gli altri sviluppatori se l'aspettano,
+e verificherà che vi siate ricordati di pubblicare quelle patch su un
+server pubblico.
+
+Revisionare le patch
+--------------------
+
+Alcuni lettori potrebbero avere obiezioni sulla presenza di questa sezione
+negli "argomenti avanzati" sulla base che anche gli sviluppatori principianti
+dovrebbero revisionare le patch.  É certamente vero che non c'è modo
+migliore di imparare come programmare per il kernel che guardare il codice
+pubblicato dagli altri.  In aggiunta, i revisori sono sempre troppo pochi;
+guardando il codice potete apportare un significativo contributo all'intero
+processo.
+
+Revisionare il codice potrebbe risultare intimidatorio, specialmente per i
+nuovi arrivati che potrebbero sentirsi un po' nervosi nel questionare
+il codice - in pubblico - pubblicato da sviluppatori più esperti.  Perfino
+il codice scritto dagli sviluppatori più esperti può essere migliorato.
+Forse il suggerimento migliore per i revisori (tutti) è questo: formulate
+i commenti come domande e non come critiche.  Chiedere "Come viene rilasciato
+il *lock* in questo percorso?" funziona sempre molto meglio che
+"qui la sincronizzazione è sbagliata".
+
+Diversi sviluppatori revisioneranno il codice con diversi punti di vista.
+Alcuni potrebbero concentrarsi principalmente sullo stile del codice e se
+alcune linee hanno degli spazio bianchi di troppo.  Altri si chiederanno
+se accettare una modifica interamente è una cosa positiva per il kernel
+o no.  E altri ancora si focalizzeranno sui problemi di sincronizzazione,
+l'uso eccessivo di *stack*, problemi di sicurezza, duplicazione del codice
+in altri contesti, documentazione, effetti negativi sulle prestazioni, cambi
+all'ABI dello spazio utente, eccetera.  Qualunque tipo di revisione è ben
+accetta e di valore, se porta ad avere un codice migliore nel kernel.

Documentation/translations/it_IT/process/8.Conclusion.rst

@@ -1,12 +1,85 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/8.Conclusion.rst <development_conclusion>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
 
 .. _it_development_conclusion:
 
 Per maggiori informazioni
 =========================
 
-.. warning::
+Esistono numerose fonti di informazioni sullo sviluppo del kernel Linux
+e argomenti correlati. Primo tra questi sarà sempre la cartella Documentation
+che si trova nei sorgenti kernel.
 
-    TODO ancora da tradurre
+Il file :ref:`process/howto.rst <it_process_howto>` è un punto di partenza
+importante; :ref:`process/submitting-patches.rst <it_submittingpatches>` e
+:ref:`process/submitting-drivers.rst <it_submittingdrivers>` sono
+anch'essi qualcosa che tutti gli sviluppatori del kernel dovrebbero leggere.
+Molte API interne al kernel sono documentate utilizzando il meccanismo
+kerneldoc; "make htmldocs" o "make pdfdocs" possono essere usati per generare
+quei documenti in HTML o PDF (sebbene le versioni di TeX di alcune
+distribuzioni hanno dei limiti interni e fallisce nel processare
+appropriatamente i documenti).
+
+Diversi siti web approfondiscono lo sviluppo del kernel ad ogni livello
+di dettaglio.  Il vostro autore vorrebbe umilmente suggerirvi
+http://lwn.net/ come fonte; usando l'indice 'kernel' su LWN troverete
+molti argomenti specifici sul kernel:
+
+	http://lwn.net/Kernel/Index/
+
+Oltre a ciò, una risorsa valida per gli sviluppatori kernel è:
+
+	http://kernelnewbies.org/
+
+E, ovviamente, una fonte da non dimenticare è http://kernel.org/, il luogo
+definitivo per le informazioni sui rilasci del kernel.
+
+Ci sono numerosi libri sullo sviluppo del kernel:
+
+	Linux Device Drivers, 3rd Edition (Jonathan Corbet, Alessandro
+	Rubini, and Greg Kroah-Hartman).  In linea all'indirizzo
+	http://lwn.net/Kernel/LDD3/.
+
+	Linux Kernel Development (Robert Love).
+
+	Understanding the Linux Kernel (Daniel Bovet and Marco Cesati).
+
+Tutti questi libri soffrono di un errore comune: tendono a risultare in un
+certo senso obsoleti dal momento che si trovano in libreria da diverso
+tempo.  Comunque contengono informazioni abbastanza buone.
+
+La documentazione per git la troverete su:
+
+	http://www.kernel.org/pub/software/scm/git/docs/
+
+	http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
+
+
+
+Conclusioni
+===========
+
+Congratulazioni a chiunque ce l'abbia fatta a terminare questo documento di
+lungo-respiro.  Si spera che abbia fornito un'utile comprensione d'insieme
+di come il kernel Linux viene sviluppato e di come potete partecipare a
+tale processo.
+
+Infine, quello che conta è partecipare.  Qualsiasi progetto software
+open-source non è altro che la somma di quello che i suoi contributori
+mettono al suo interno.  Il kernel Linux è cresciuto velocemente e bene
+perché ha ricevuto il supporto di un impressionante gruppo di sviluppatori,
+ognuno dei quali sta lavorando per renderlo migliore.  Il kernel è un esempio
+importante di cosa può essere fatto quando migliaia di persone lavorano
+insieme verso un obiettivo comune.
+
+Il kernel può sempre beneficiare di una larga base di sviluppatori, tuttavia,
+c'è sempre molto lavoro da fare.  Ma, cosa non meno importante, molti degli
+altri partecipanti all'ecosistema Linux possono trarre beneficio attraverso
+il contributo al kernel.  Inserire codice nel ramo principale è la chiave
+per arrivare ad una qualità del codice più alta, bassa manutenzione e
+bassi prezzi di distribuzione, alti livelli d'influenza sulla direzione
+dello sviluppo del kernel, e molto altro.  È una situazione nella quale
+tutti coloro che sono coinvolti vincono.  Mollate il vostro editor e
+raggiungeteci; sarete più che benvenuti.

Documentation/translations/it_IT/process/adding-syscalls.rst

@@ -1,12 +1,643 @@
 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/adding-syscalls.rst <addsyscalls>`
+:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
 
 .. _it_addsyscalls:
 
 Aggiungere una nuova chiamata di sistema
 ========================================
 
-.. warning::
+Questo documento descrive quello che è necessario sapere per aggiungere
+nuove chiamate di sistema al kernel Linux; questo è da considerarsi come
+un'aggiunta ai soliti consigli su come proporre nuove modifiche
+:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
 
-    TODO ancora da tradurre
+
+Alternative alle chiamate di sistema
+------------------------------------
+
+La prima considerazione da fare quando si aggiunge una nuova chiamata di
+sistema è quella di valutare le alternative.  Nonostante le chiamate di sistema
+siano il punto di interazione fra spazio utente e kernel più tradizionale ed
+ovvio, esistono altre possibilità - scegliete quella che meglio si adatta alle
+vostra interfaccia.
+
+ - Se le operazioni coinvolte possono rassomigliare a quelle di un filesystem,
+   allora potrebbe avere molto più senso la creazione di un nuovo filesystem o
+   dispositivo.  Inoltre, questo rende più facile incapsulare la nuova
+   funzionalità in un modulo kernel piuttosto che essere sviluppata nel cuore
+   del kernel.
+
+     - Se la nuova funzionalità prevede operazioni dove il kernel notifica
+       lo spazio utente su un avvenimento, allora restituire un descrittore
+       di file all'oggetto corrispondente permette allo spazio utente di
+       utilizzare ``poll``/``select``/``epoll`` per ricevere quelle notifiche.
+     - Tuttavia, le operazioni che non si sposano bene con operazioni tipo
+       :manpage:`read(2)`/:manpage:`write(2)` dovrebbero essere implementate
+       come chiamate :manpage:`ioctl(2)`, il che potrebbe portare ad un'API in
+       un qualche modo opaca.
+
+ - Se dovete esporre solo delle informazioni sul sistema, un nuovo nodo in
+   sysfs (vedere ``Documentation/translations/it_IT/filesystems/sysfs.txt``) o
+   in procfs potrebbe essere sufficiente.  Tuttavia, l'accesso a questi
+   meccanismi richiede che il filesystem sia montato, il che potrebbe non
+   essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
+   Evitate d'aggiungere nuove API in debugfs perché questo non viene
+   considerata un'interfaccia di 'produzione' verso lo spazio utente.
+ - Se l'operazione è specifica ad un particolare file o descrittore, allora
+   potrebbe essere appropriata l'aggiunta di un comando :manpage:`fcntl(2)`.
+   Tuttavia, :manpage:`fcntl(2)` è una chiamata di sistema multiplatrice che
+   nasconde una notevole complessità, quindi è ottima solo quando la nuova
+   funzione assomiglia a quelle già esistenti in :manpage:`fcntl(2)`, oppure
+   la nuova funzionalità è veramente semplice (per esempio, leggere/scrivere
+   un semplice flag associato ad un descrittore di file).
+ - Se l'operazione è specifica ad un particolare processo, allora
+   potrebbe essere appropriata l'aggiunta di un comando :manpage:`prctl(2)`.
+   Come per :manpage:`fcntl(2)`, questa chiamata di sistema è un complesso
+   multiplatore quindi è meglio usarlo per cose molto simili a quelle esistenti
+   nel comando ``prctl`` oppure per leggere/scrivere un semplice flag relativo
+   al processo.
+
+
+Progettare l'API: pianificare le estensioni
+-------------------------------------------
+
+Una nuova chiamata di sistema diventerà parte dell'API del kernel, e
+dev'essere supportata per un periodo indefinito.  Per questo, è davvero
+un'ottima idea quella di discutere apertamente l'interfaccia sulla lista
+di discussione del kernel, ed è altrettanto importante pianificarne eventuali
+estensioni future.
+
+(Nella tabella delle chiamate di sistema sono disseminati esempi dove questo
+non fu fatto, assieme ai corrispondenti aggiornamenti -
+``eventfd``/``eventfd2``, ``dup2``/``dup3``, ``inotify_init``/``inotify_init1``,
+``pipe``/``pipe2``, ``renameat``/``renameat2`` --quindi imparate dalla storia
+del kernel e pianificate le estensioni fin dall'inizio)
+
+Per semplici chiamate di sistema che accettano solo un paio di argomenti,
+il modo migliore di permettere l'estensibilità è quello di includere un
+argomento *flags* alla chiamata di sistema.  Per assicurarsi che i programmi
+dello spazio utente possano usare in sicurezza *flags* con diverse versioni
+del kernel, verificate se *flags* contiene un qualsiasi valore sconosciuto,
+in qual caso rifiutate la chiamata di sistema (con ``EINVAL``)::
+
+    if (flags & ~(THING_FLAG1 | THING_FLAG2 | THING_FLAG3))
+        return -EINVAL;
+
+(Se *flags* non viene ancora utilizzato, verificate che l'argomento sia zero)
+
+Per chiamate di sistema più sofisticate che coinvolgono un numero più grande di
+argomenti, il modo migliore è quello di incapsularne la maggior parte in una
+struttura dati che verrà passata per puntatore.  Questa struttura potrà
+funzionare con future estensioni includendo un campo *size*::
+
+    struct xyzzy_params {
+        u32 size; /* userspace sets p->size = sizeof(struct xyzzy_params) */
+        u32 param_1;
+        u64 param_2;
+        u64 param_3;
+    };
+
+Fintanto che un qualsiasi campo nuovo, diciamo ``param_4``, è progettato per
+offrire il comportamento precedente quando vale zero, allora questo permetterà
+di gestire un conflitto di versione in entrambe le direzioni:
+
+ - un vecchio kernel può gestire l'accesso di una versione moderna di un
+   programma in spazio utente verificando che la memoria oltre la dimensione
+   della struttura dati attesa sia zero (in pratica verificare che
+   ``param_4 == 0``).
+ - un nuovo kernel può gestire l'accesso di una versione vecchia di un
+   programma in spazio utente estendendo la struttura dati con zeri (in pratica
+   ``param_4 = 0``).
+
+Vedere :manpage:`perf_event_open(2)` e la funzione ``perf_copy_attr()`` (in
+``kernel/events/core.c``) per un esempio pratico di questo approccio.
+
+
+Progettare l'API: altre considerazioni
+--------------------------------------
+
+Se la vostra nuova chiamata di sistema permette allo spazio utente di fare
+riferimento ad un oggetto del kernel, allora questa dovrebbe usare un
+descrittore di file per accesso all'oggetto - non inventatevi nuovi tipi di
+accesso da spazio utente quando il kernel ha già dei meccanismi e una semantica
+ben definita per utilizzare i descrittori di file.
+
+Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` ritorna un nuovo
+descrittore di file, allora l'argomento *flags* dovrebbe includere un valore
+equivalente a ``O_CLOEXEC`` per i nuovi descrittori.  Questo rende possibile,
+nello spazio utente, la chiusura della finestra temporale fra le chiamate a
+``xyzzy()`` e ``fcntl(fd, F_SETFD, FD_CLOEXEC)``, dove un inaspettato
+``fork()`` o ``execve()`` potrebbe trasferire il descrittore al programma
+eseguito (Comunque, resistete alla tentazione di riutilizzare il valore di
+``O_CLOEXEC`` dato che è specifico dell'architettura e fa parte di una
+enumerazione di flag ``O_*`` che è abbastanza ricca).
+
+Se la vostra nuova chiamata di sistema ritorna un nuovo descrittore di file,
+dovreste considerare che significato avrà l'uso delle chiamate di sistema
+della famiglia di :manpage:`poll(2)`. Rendere un descrittore di file pronto
+per la lettura o la scrittura è il tipico modo del kernel per notificare lo
+spazio utente circa un evento associato all'oggetto del kernel.
+
+Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` ha un argomento
+che è il percorso ad un file::
+
+    int sys_xyzzy(const char __user *path, ..., unsigned int flags);
+
+dovreste anche considerare se non sia più appropriata una versione
+:manpage:`xyzzyat(2)`::
+
+    int sys_xyzzyat(int dfd, const char __user *path, ..., unsigned int flags);
+
+Questo permette più flessibilità su come lo spazio utente specificherà il file
+in questione; in particolare, permette allo spazio utente di richiedere la
+funzionalità su un descrittore di file già aperto utilizzando il *flag*
+``AT_EMPTY_PATH``, in pratica otterremmo gratuitamente l'operazione
+:manpage:`fxyzzy(3)`::
+
+ - xyzzyat(AT_FDCWD, path, ..., 0) is equivalent to xyzzy(path,...)
+ - xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
+
+(Per maggiori dettagli sulla logica delle chiamate \*at(), leggete la pagina
+man :manpage:`openat(2)`; per un esempio di AT_EMPTY_PATH, leggere la pagina
+man :manpage:`fstatat(2)`).
+
+Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` prevede un parametro
+per descrivere uno scostamento all'interno di un file, usate ``loff_t`` come
+tipo cosicché scostamenti a 64-bit potranno essere supportati anche su
+architetture a 32-bit.
+
+Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` prevede l'uso di
+funzioni riservate, allora dev'essere gestita da un opportuno bit di privilegio
+(verificato con una chiamata a ``capable()``), come descritto nella pagina man
+:manpage:`capabilities(7)`.  Scegliete un bit di privilegio già esistente per
+gestire la funzionalità associata, ma evitate la combinazione di diverse
+funzionalità vagamente collegate dietro lo stesso bit, in quanto va contro il
+principio di *capabilities* di separare i poteri di root.  In particolare,
+evitate di aggiungere nuovi usi al fin-troppo-generico privilegio
+``CAP_SYS_ADMIN``.
+
+Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` manipola altri
+processi oltre a quello chiamato, allora dovrebbe essere limitata (usando
+la chiamata ``ptrace_may_access()``) di modo che solo un processo chiamante
+con gli stessi permessi del processo in oggetto, o con i necessari privilegi,
+possa manipolarlo.
+
+Infine, state attenti che in alcune architetture non-x86 la vita delle chiamate
+di sistema con argomenti a 64-bit viene semplificata se questi argomenti
+ricadono in posizioni dispari (pratica, i parametri 1, 3, 5); questo permette
+l'uso di coppie contigue di registri a 32-bit.  (Questo non conta se gli
+argomenti sono parte di una struttura dati che viene passata per puntatore).
+
+
+Proporre l'API
+--------------
+
+Al fine di rendere le nuove chiamate di sistema di facile revisione, è meglio
+che dividiate le modifiche i pezzi separati.  Questi dovrebbero includere
+almeno le seguenti voci in *commit* distinti (ognuno dei quali sarà descritto
+più avanti):
+
+ - l'essenza dell'implementazione della chiamata di sistema, con i prototipi,
+   i numeri generici, le modifiche al Kconfig e l'implementazione *stub* di
+   ripiego.
+ - preparare la nuova chiamata di sistema per un'architettura specifica,
+   solitamente x86 (ovvero tutti: x86_64, x86_32 e x32).
+ - un programma di auto-verifica da mettere in ``tools/testing/selftests/``
+   che mostri l'uso della chiamata di sistema.
+ - una bozza di pagina man per la nuova chiamata di sistema. Può essere
+   scritta nell'email di presentazione, oppure come modifica vera e propria
+   al repositorio delle pagine man.
+
+Le proposte di nuove chiamate di sistema, come ogni altro modifica all'API del
+kernel, deve essere sottomessa alla lista di discussione
+linux-api@vger.kernel.org.
+
+
+Implementazione di chiamate di sistema generiche
+------------------------------------------------
+
+Il principale punto d'accesso alla vostra nuova chiamata di sistema
+:manpage:`xyzzy(2)` verrà chiamato ``sys_xyzzy()``; ma, piuttosto che in modo
+esplicito, lo aggiungerete tramite la macro ``SYSCALL_DEFINEn``. La 'n'
+indica il numero di argomenti della chiamata di sistema; la macro ha come
+argomento il nome della chiamata di sistema, seguito dalle coppie (tipo, nome)
+per definire i suoi parametri.  L'uso di questa macro permette di avere
+i metadati della nuova chiamata di sistema disponibili anche per altri
+strumenti.
+
+Il nuovo punto d'accesso necessita anche del suo prototipo di funzione in
+``include/linux/syscalls.h``, marcato come asmlinkage di modo da abbinargli
+il modo in cui quelle chiamate di sistema verranno invocate::
+
+    asmlinkage long sys_xyzzy(...);
+
+Alcune architetture (per esempio x86) hanno le loro specifiche tabelle di
+chiamate di sistema (syscall), ma molte altre architetture condividono una
+tabella comune di syscall. Aggiungete alla lista generica la vostra nuova
+chiamata di sistema aggiungendo un nuovo elemento alla lista in
+``include/uapi/asm-generic/unistd.h``::
+
+    #define __NR_xyzzy 292
+    __SYSCALL(__NR_xyzzy, sys_xyzzy)
+
+Aggiornate anche il contatore __NR_syscalls di modo che sia coerente con
+l'aggiunta della nuove chiamate di sistema; va notato che se più di una nuova
+chiamata di sistema viene aggiunga nella stessa finestra di sviluppo, il numero
+della vostra nuova syscall potrebbe essere aggiustato al fine di risolvere i
+conflitti.
+
+Il file ``kernel/sys_ni.c`` fornisce le implementazioni *stub* di ripiego che
+ritornano ``-ENOSYS``.  Aggiungete la vostra nuova chiamata di sistema anche
+qui::
+
+    COND_SYSCALL(xyzzy);
+
+La vostra nuova funzionalità del kernel, e la chiamata di sistema che la
+controlla, dovrebbero essere opzionali. Quindi, aggiungete un'opzione
+``CONFIG`` (solitamente in ``init/Kconfig``).  Come al solito per le nuove
+opzioni ``CONFIG``:
+
+ - Includete una descrizione della nuova funzionalità e della chiamata di
+   sistema che la controlla.
+ - Rendete l'opzione dipendente da EXPERT se dev'essere nascosta agli utenti
+   normali.
+ - Nel Makefile, rendere tutti i nuovi file sorgenti, che implementano la
+   nuova funzionalità, dipendenti dall'opzione CONFIG (per esempio
+   ``obj-$(CONFIG_XYZZY_SYSCALL) += xyzzy.o``).
+ - Controllate due volte che sia possibile generare il kernel con la nuova
+   opzione CONFIG disabilitata.
+
+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 elemento nella tabella generica in ``include/uapi/asm-generic/unistd.h``
+ - *stub* di ripiego in ``kernel/sys_ni.c``
+
+
+Implementazione delle chiamate di sistema x86
+---------------------------------------------
+
+Per collegare la vostra nuova chiamate di sistema alle piattaforme x86,
+dovete aggiornate la tabella principale di syscall.  Assumendo che la vostra
+nuova chiamata di sistema non sia particolarmente speciale (vedere sotto),
+dovete aggiungere un elemento *common* (per x86_64 e x32) in
+arch/x86/entry/syscalls/syscall_64.tbl::
+
+    333   common   xyzzy     sys_xyzzy
+
+e un elemento per *i386* ``arch/x86/entry/syscalls/syscall_32.tbl``::
+
+    380   i386     xyzzy     sys_xyzzy
+
+Ancora una volta, questi numeri potrebbero essere cambiati se generano
+conflitti durante la finestra di integrazione.
+
+
+Chiamate di sistema compatibili (generico)
+------------------------------------------
+
+Per molte chiamate di sistema, la stessa implementazione a 64-bit può essere
+invocata anche quando il programma in spazio utente è a 32-bit; anche se la
+chiamata di sistema include esplicitamente un puntatore, questo viene gestito
+in modo trasparente.
+
+Tuttavia, ci sono un paio di situazione dove diventa necessario avere un
+livello di gestione della compatibilità per risolvere le differenze di
+dimensioni fra 32-bit e 64-bit.
+
+Il primo caso è quando un kernel a 64-bit supporta anche programmi in spazio
+utente a 32-bit, perciò dovrà ispezionare aree della memoria (``__user``) che
+potrebbero contenere valori a 32-bit o a 64-bit.  In particolar modo, questo
+è necessario quando un argomento di una chiamata di sistema è:
+
+ - un puntatore ad un puntatore
+ - un puntatore ad una struttura dati contenente a sua volta un puntatore
+   ( ad esempio ``struct iovec __user *``)
+ - un puntatore ad un tipo intero di dimensione variabile (``time_t``,
+   ``off_t``, ``long``, ...)
+ - un puntatore ad una struttura dati contenente un tipo intero di dimensione
+   variabile.
+
+Il secondo caso che richiede un livello di gestione della compatibilità è
+quando uno degli argomenti di una chiamata a sistema è esplicitamente un tipo
+a 64-bit anche su architetture a 32-bit, per esempio ``loff_t`` o ``__u64``.
+In questo caso, un valore che arriva ad un kernel a 64-bit da un'applicazione
+a 32-bit verrà diviso in due valori a 32-bit che dovranno essere riassemblati
+in questo livello di compatibilità.
+
+(Da notare che non serve questo livello di compatibilità per argomenti che
+sono puntatori ad un tipo esplicitamente a 64-bit; per esempio, in
+:manpage:`splice(2)` l'argomento di tipo ``loff_t __user *`` non necessita
+di una chiamata di sistema ``compat_``)
+
+La versione compatibile della nostra chiamata di sistema si chiamerà
+``compat_sys_xyzzy()``, e viene aggiunta utilizzando la macro
+``COMPAT_SYSCALL_DEFINEn()`` (simile a SYSCALL_DEFINEn).  Questa versione
+dell'implementazione è parte del kernel a 64-bit ma accetta parametri a 32-bit
+che trasformerà secondo le necessità (tipicamente, la versione
+``compat_sys_`` converte questi valori nello loro corrispondente a 64-bit e
+può chiamare la versione ``sys_`` oppure invocare una funzione che implementa
+le parti comuni).
+
+Il punto d'accesso *compat* deve avere il corrispondente prototipo di funzione
+in ``include/linux/compat.h``, marcato come asmlinkage di modo da abbinargli
+il modo in cui quelle chiamate di sistema verranno invocate::
+
+    asmlinkage long compat_sys_xyzzy(...);
+
+Se la chiamata di sistema prevede una struttura dati organizzata in modo
+diverso per sistemi a 32-bit e per quelli a 64-bit, diciamo
+``struct xyzzy_args``, allora il file d'intestazione
+``then the include/linux/compat.h`` deve includere la sua versione
+*compatibile* (``struct compat_xyzzy_args``); ogni variabile con
+dimensione variabile deve avere il proprio tipo ``compat_`` corrispondente
+a quello in ``struct xyzzy_args``.  La funzione ``compat_sys_xyzzy()``
+può usare la struttura ``compat_`` per analizzare gli argomenti ricevuti
+da una chiamata a 32-bit.
+
+Per esempio, se avete i seguenti campi::
+
+    struct xyzzy_args {
+        const char __user *ptr;
+        __kernel_long_t varying_val;
+        u64 fixed_val;
+        /* ... */
+    };
+
+nella struttura ``struct xyzzy_args``, allora la struttura
+``struct compat_xyzzy_args`` dovrebbe avere::
+
+    struct compat_xyzzy_args {
+        compat_uptr_t ptr;
+        compat_long_t varying_val;
+        u64 fixed_val;
+        /* ... */
+    };
+
+La lista generica delle chiamate di sistema ha bisogno di essere
+aggiustata al fine di permettere l'uso della versione *compatibile*;
+la voce in ``include/uapi/asm-generic/unistd.h`` dovrebbero usare
+``__SC_COMP`` piuttosto di ``__SYSCALL``::
+
+    #define __NR_xyzzy 292
+    __SC_COMP(__NR_xyzzy, sys_xyzzy, compat_sys_xyzzy)
+
+Riassumendo, vi serve:
+
+ - un ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` per il punto d'accesso
+   *compatibile*
+ - un prototipo in ``include/linux/compat.h``
+ - (se necessario) una struttura di compatibilità a 32-bit in
+   ``include/linux/compat.h``
+ - una voce ``__SC_COMP``, e non ``__SYSCALL``, in
+   ``include/uapi/asm-generic/unistd.h``
+
+Compatibilità delle chiamate di sistema (x86)
+---------------------------------------------
+
+Per collegare una chiamata di sistema, su un'architettura x86, con la sua
+versione *compatibile*, è necessario aggiustare la voce nella tabella
+delle syscall.
+
+Per prima cosa, la voce in ``arch/x86/entry/syscalls/syscall_32.tbl`` prende
+un argomento aggiuntivo per indicare che un programma in spazio utente
+a 32-bit, eseguito su un kernel a 64-bit, dovrebbe accedere tramite il punto
+d'accesso compatibile::
+
+    380   i386     xyzzy     sys_xyzzy    __ia32_compat_sys_xyzzy
+
+Secondo, dovete capire cosa dovrebbe succedere alla nuova chiamata di sistema
+per la versione dell'ABI x32.  Qui C'è una scelta da fare: gli argomenti
+possono corrisponde alla versione a 64-bit o a quella a 32-bit.
+
+Se c'è un puntatore ad un puntatore, la decisione è semplice: x32 è ILP32,
+quindi gli argomenti dovrebbero corrispondere a quelli a 32-bit, e la voce in
+``arch/x86/entry/syscalls/syscall_64.tbl`` sarà divisa cosicché i programmi
+x32 eseguano la chiamata *compatibile*::
+
+    333   64       xyzzy     sys_xyzzy
+    ...
+    555   x32      xyzzy     __x32_compat_sys_xyzzy
+
+Se non ci sono puntatori, allora è preferibile riutilizzare la chiamata di
+sistema a 64-bit per l'ABI x32 (e di conseguenza la voce in
+arch/x86/entry/syscalls/syscall_64.tbl rimane immutata).
+
+In ambo i casi, dovreste verificare che i tipi usati dagli argomenti
+abbiano un'esatta corrispondenza da x32 (-mx32) al loro equivalente a
+32-bit (-m32) o 64-bit (-m64).
+
+
+Chiamate di sistema che ritornano altrove
+-----------------------------------------
+
+Nella maggior parte delle chiamate di sistema, al termine della loro
+esecuzione, i programmi in spazio utente riprendono esattamente dal punto
+in cui si erano interrotti -- quindi dall'istruzione successiva, con lo
+stesso *stack* e con la maggior parte del registri com'erano stati
+lasciati prima della chiamata di sistema, e anche con la stessa memoria
+virtuale.
+
+Tuttavia, alcune chiamata di sistema fanno le cose in modo differente.
+Potrebbero ritornare ad un punto diverso (``rt_sigreturn``) o cambiare
+la memoria in spazio utente (``fork``/``vfork``/``clone``) o perfino
+l'architettura del programma (``execve``/``execveat``).
+
+Per permettere tutto ciò, l'implementazione nel kernel di questo tipo di
+chiamate di sistema potrebbero dover salvare e ripristinare registri
+aggiuntivi nello *stack* del kernel, permettendo così un controllo completo
+su dove e come l'esecuzione dovrà continuare dopo l'esecuzione della
+chiamata di sistema.
+
+Queste saranno specifiche per ogni architettura, ma tipicamente si definiscono
+dei punti d'accesso in *assembly* per salvare/ripristinare i registri
+aggiuntivi e quindi chiamare il vero punto d'accesso per la chiamata di
+sistema.
+
+Per l'architettura x86_64, questo è implementato come un punto d'accesso
+``stub_xyzzy`` in ``arch/x86/entry/entry_64.S``, e la voce nella tabella
+di syscall (``arch/x86/entry/syscalls/syscall_64.tbl``) verrà corretta di
+conseguenza::
+
+    333   common   xyzzy     stub_xyzzy
+
+L'equivalente per programmi a 32-bit eseguiti su un kernel a 64-bit viene
+normalmente chiamato ``stub32_xyzzy`` e implementato in
+``arch/x86/entry/entry_64_compat.S`` con la corrispondente voce nella tabella
+di syscall ``arch/x86/entry/syscalls/syscall_32.tbl`` corretta nel
+seguente modo::
+
+    380   i386     xyzzy     sys_xyzzy    stub32_xyzzy
+
+Se una chiamata di sistema necessita di un livello di compatibilità (come
+nella sezione precedente), allora la versione ``stub32_`` deve invocare
+la versione ``compat_sys_`` piuttosto che quella nativa a 64-bit.  In aggiunta,
+se l'implementazione dell'ABI x32 è diversa da quella x86_64, allora la sua
+voce nella tabella di syscall dovrà chiamare uno *stub* che invoca la versione
+``compat_sys_``,
+
+Per completezza, sarebbe carino impostare una mappatura cosicché
+*user-mode* Linux (UML) continui a funzionare -- la sua tabella di syscall
+farà riferimento a stub_xyzzy, ma UML non include l'implementazione
+in ``arch/x86/entry/entry_64.S`` (perché UML simula i registri eccetera).
+Correggerlo è semplice, basta aggiungere una #define in
+``arch/x86/um/sys_call_table_64.c``::
+
+    #define stub_xyzzy sys_xyzzy
+
+
+Altri dettagli
+--------------
+
+La maggior parte dei kernel tratta le chiamate di sistema allo stesso modo,
+ma possono esserci rare eccezioni per le quali potrebbe essere necessario
+l'aggiornamento della vostra chiamata di sistema.
+
+Il sotto-sistema di controllo (*audit subsystem*) è uno di questi casi
+speciali; esso include (per architettura) funzioni che classificano alcuni
+tipi di chiamate di sistema -- in particolare apertura dei file
+(``open``/``openat``), esecuzione dei programmi (``execve``/``exeveat``)
+oppure multiplatori di socket (``socketcall``). Se la vostra nuova chiamata
+di sistema è simile ad una di queste, allora il sistema di controllo dovrebbe
+essere aggiornato.
+
+Più in generale, se esiste una chiamata di sistema che è simile alla vostra,
+vale la pena fare una ricerca con ``grep`` su tutto il kernel per la chiamata
+di sistema esistente per verificare che non ci siano altri casi speciali.
+
+
+Verifica
+--------
+
+Una nuova chiamata di sistema dev'essere, ovviamente, provata; è utile fornire
+ai revisori un programma in spazio utente che mostri l'uso della chiamata di
+sistema.  Un buon modo per combinare queste cose è quello di aggiungere un
+semplice programma di auto-verifica in una nuova cartella in
+``tools/testing/selftests/``.
+
+Per una nuova chiamata di sistema, ovviamente, non ci sarà alcuna funzione
+in libc e quindi il programma di verifica dovrà invocarla usando ``syscall()``;
+inoltre, se la nuova chiamata di sistema prevede un nuova struttura dati
+visibile in spazio utente, il file d'intestazione necessario dev'essere
+installato al fine di compilare il programma.
+
+Assicuratevi che il programma di auto-verifica possa essere eseguito
+correttamente su tutte le architetture supportate.  Per esempio, verificate che
+funzioni quando viene compilato per x86_64 (-m64), x86_32 (-m32) e x32 (-mx32).
+
+Al fine di una più meticolosa ed estesa verifica della nuova funzionalità,
+dovreste considerare l'aggiunta di nuove verifica al progetto 'Linux Test',
+oppure al progetto xfstests per cambiamenti relativi al filesystem.
+
+ - https://linux-test-project.github.io/
+ - git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
+
+
+Pagine man
+----------
+
+Tutte le nuove chiamate di sistema dovrebbero avere una pagina man completa,
+idealmente usando i marcatori groff, ma anche il puro testo può andare.  Se
+state usando groff, è utile che includiate nella email di presentazione una
+versione già convertita in formato ASCII: semplificherà la vita dei revisori.
+
+Le pagine man dovrebbero essere in copia-conoscenza verso
+linux-man@vger.kernel.org
+Per maggiori dettagli, leggere
+https://www.kernel.org/doc/man-pages/patches.html
+
+
+Non invocate chiamate di sistema dal kernel
+-------------------------------------------
+
+Le chiamate di sistema sono, come già detto prima, punti di interazione fra
+lo spazio utente e il kernel.  Perciò, le chiamate di sistema come
+``sys_xyzzy()`` o ``compat_sys_xyzzy()`` dovrebbero essere chiamate solo dallo
+spazio utente attraverso la tabella syscall, ma non da nessun altro punto nel
+kernel.  Se la nuova funzionalità è utile all'interno del kernel, per esempio
+dev'essere condivisa fra una vecchia e una nuova chiamata di sistema o
+dev'essere utilizzata da una chiamata di sistema e la sua variante compatibile,
+allora dev'essere implementata come una funzione di supporto
+(*helper function*) (per esempio ``kern_xyzzy()``).  Questa funzione potrà
+essere chiamata dallo *stub* (``sys_xyzzy()``), dalla variante compatibile
+(``compat_sys_xyzzy()``), e/o da altri parti del kernel.
+
+Sui sistemi x86 a 64-bit, a partire dalla versione v4.17 è un requisito
+fondamentale quello di non invocare chiamate di sistema all'interno del kernel.
+Esso usa una diversa convenzione per l'invocazione di chiamate di sistema dove
+``struct pt_regs`` viene decodificata al volo in una funzione che racchiude
+la chiamata di sistema la quale verrà eseguita successivamente.
+Questo significa che verranno passati solo i parametri che sono davvero
+necessari ad una specifica chiamata di sistema, invece che riempire ogni volta
+6 registri del processore con contenuti presi dallo spazio utente (potrebbe
+causare seri problemi nella sequenza di chiamate).
+
+Inoltre, le regole su come i dati possano essere usati potrebbero differire
+fra il kernel e l'utente.  Questo è un altro motivo per cui invocare
+``sys_xyzzy()`` è generalmente una brutta idea.
+
+Eccezioni a questa regola vengono accettate solo per funzioni d'architetture
+che surclassano quelle generiche, per funzioni d'architettura di compatibilità,
+o per altro codice in arch/
+
+
+Riferimenti e fonti
+-------------------
+
+ - Articolo di Michael Kerris su LWN sull'uso dell'argomento flags nelle
+   chiamate di sistema: https://lwn.net/Articles/585415/
+ - Articolo di Michael Kerris su LWN su come gestire flag sconosciuti in
+   una chiamata di sistema: https://lwn.net/Articles/588444/
+ - Articolo di Jake Edge su LWN che descrive i limiti degli argomenti a 64-bit
+   delle chiamate di sistema: https://lwn.net/Articles/311630/
+ - Una coppia di articoli di David Drysdale che descrivono i dettagli del
+   percorso implementativo di una chiamata di sistema per la versione v3.14:
+
+    - https://lwn.net/Articles/604287/
+    - https://lwn.net/Articles/604515/
+
+ - Requisiti specifici alle architetture sono discussi nella pagina man
+   :manpage:`syscall(2)` :
+   http://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
+ - Collezione di email di Linux Torvalds sui problemi relativi a ``ioctl()``:
+   http://yarchive.net/comp/linux/ioctl.html
+ - "Come non inventare interfacce del kernel", Arnd Bergmann,
+   http://www.ukuug.org/events/linux2007/2007/papers/Bergmann.pdf
+ - Articolo di Michael Kerris su LWN sull'evitare nuovi usi di CAP_SYS_ADMIN:
+   https://lwn.net/Articles/486306/
+ - Raccomandazioni da Andrew Morton circa il fatto che tutte le informazioni
+   su una nuova chiamata di sistema dovrebbero essere contenute nello stesso
+   filone di discussione di email: https://lkml.org/lkml/2014/7/24/641
+ - Raccomandazioni da Michael Kerrisk circa il fatto che le nuove chiamate di
+   sistema dovrebbero avere una pagina man: https://lkml.org/lkml/2014/6/13/309
+ - Consigli da Thomas Gleixner sul fatto che il collegamento all'architettura
+   x86 dovrebbe avvenire in un *commit* differente:
+   https://lkml.org/lkml/2014/11/19/254
+ - Consigli da Greg Kroah-Hartman circa la bontà d'avere una pagina man e un
+   programma di auto-verifica per le nuove chiamate di sistema:
+   https://lkml.org/lkml/2014/3/19/710
+ - Discussione di Michael Kerrisk sulle nuove chiamate di sistema contro
+   le estensioni :manpage:`prctl(2)`: https://lkml.org/lkml/2014/6/3/411
+ - Consigli da Ingo Molnar che le chiamate di sistema con più argomenti
+   dovrebbero incapsularli in una struttura che includa un argomento
+   *size* per garantire l'estensibilità futura:
+   https://lkml.org/lkml/2015/7/30/117
+ - Un certo numero di casi strani emersi dall'uso (riuso) dei flag O_*:
+
+    - commit 75069f2b5bfb ("vfs: renumber FMODE_NONOTIFY and add to uniqueness
+      check")
+    - commit 12ed2e36c98a ("fanotify: FMODE_NONOTIFY and __O_SYNC in sparc
+      conflict")
+    - commit bb458c644a59 ("Safer ABI for O_TMPFILE")
+
+ - Discussion from Matthew Wilcox about restrictions on 64-bit arguments:
+   https://lkml.org/lkml/2008/12/12/187
+ - Raccomandazioni da Greg Kroah-Hartman sul fatto che i flag sconosciuti dovrebbero
+   essere controllati: https://lkml.org/lkml/2014/7/17/577
+ - 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://lkml.org/lkml/2011/8/31/244