code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/howto.rst <process_howto>`
:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>

.. _it_process_howto:

Come partecipare allo sviluppo del kernel Linux
===============================================

Questo è il documento fulcro di quanto trattato sull'argomento.
Esso contiene le istruzioni su come diventare uno sviluppatore
del kernel Linux e spiega come lavorare con la comunità di
sviluppo kernel Linux. Il documento non tratterà alcun aspetto
tecnico relativo alla programmazione del kernel, ma vi aiuterà
indirizzandovi sulla corretta strada.

Se qualsiasi cosa presente in questo documento diventasse obsoleta,
vi preghiamo di inviare le correzioni agli amministratori di questo
file, indicati in fondo al presente documento.

Introduzione
------------
Dunque, volete imparare come diventare sviluppatori del kernel Linux?
O vi è stato detto dal vostro capo, "Vai, scrivi un driver Linux per
questo dispositivo". Bene, l'obbiettivo di questo documento è quello
di insegnarvi tutto ciò che dovete sapere per raggiungere il vostro
scopo descrivendo il procedimento da seguire e consigliandovi
su come lavorare con la comunità. Il documento cercherà, inoltre,
di spiegare alcune delle ragioni per le quali la comunità lavora in un
modo suo particolare.

Il kernel è scritto prevalentemente nel linguaggio C con alcune parti
specifiche dell'architettura scritte in linguaggio assembly.
Per lo sviluppo kernel è richiesta una buona conoscenza del linguaggio C.
L'assembly (di qualsiasi architettura) non è richiesto, a meno che non
pensiate di fare dello sviluppo di basso livello per un'architettura.
Sebbene essi non siano un buon sostituto ad un solido studio del
linguaggio C o ad anni di esperienza, i seguenti libri sono, se non
altro, utili riferimenti:

- "The C Programming Language" di Kernighan e Ritchie [Prentice Hall]
- "Practical C Programming" di Steve Oualline [O'Reilly]
- "C:  A Reference Manual" di Harbison and Steele [Prentice Hall]

Il kernel è stato scritto usando GNU C e la toolchain GNU.
Sebbene si attenga allo standard ISO C11, esso utilizza una serie di
estensioni che non sono previste in questo standard. Il kernel è un
ambiente C indipendente, che non ha alcuna dipendenza dalle librerie
C standard, così alcune parti del C standard non sono supportate.
Le divisioni ``long long`` e numeri in virgola mobile non sono permessi.
Qualche volta è difficile comprendere gli assunti che il kernel ha
riguardo gli strumenti e le estensioni in uso, e sfortunatamente non
esiste alcuna indicazione definitiva. Per maggiori informazioni, controllate,
la pagina `info gcc`.

Tenete a mente che state cercando di apprendere come lavorare con la comunità
di sviluppo già esistente. Questo è un gruppo eterogeneo di persone, con alti
standard di codifica, di stile e di procedura. Questi standard sono stati
creati nel corso del tempo basandosi su quanto hanno riscontrato funzionare al
meglio per un squadra così grande e geograficamente sparsa. Cercate di
imparare, in anticipo, il più possibile circa questi standard, poichè ben
spiegati; non aspettatevi che gli altri si adattino al vostro modo di fare
o a quello della vostra azienda.

Note legali
------------
Il codice sorgente del kernel Linux è rilasciato sotto GPL. Siete pregati
di visionare il file, COPYING, presente nella cartella principale dei
sorgente, per eventuali dettagli sulla licenza. Se avete ulteriori domande
sulla licenza, contattate un avvocato, non chiedete sulle liste di discussione
del kernel Linux. Le persone presenti in queste liste non sono avvocati,
e non dovreste basarvi sulle loro dichiarazioni in materia giuridica.

Per domande più frequenti e risposte sulla licenza GPL, guardare:

	https://www.gnu.org/licenses/gpl-faq.html

Documentazione
--------------
I sorgenti del kernel Linux hanno una vasta base di documenti che vi
insegneranno come interagire con la comunità del kernel. Quando nuove
funzionalità vengono aggiunte al kernel, si raccomanda di aggiungere anche i
relativi file di documentatione che spiegano come usarele.
Quando un cambiamento del kernel genera anche un cambiamento nell'interfaccia
con lo spazio utente, è raccomandabile che inviate una notifica o una
correzione alle pagine *man* spiegando tale modifica agli amministratori di
queste pagine all'indirizzo mtk.manpages@gmail.com, aggiungendo
in CC la lista linux-api@vger.kernel.org.

Di seguito una lista di file che sono presenti nei sorgente del kernel e che
è richiesto che voi leggiate:

  :ref:`Documentation/translations/it_IT/admin-guide/README.rst <it_readme>`
    Questo file da una piccola anteprima del kernel Linux e descrive il
    minimo necessario per configurare e generare il kernel. I novizi
    del kernel dovrebbero iniziare da qui.

  :ref:`Documentation/translations/it_IT/process/changes.rst <it_changes>`

    Questo file fornisce una lista dei pacchetti software necessari
    a compilare e far funzionare il kernel con successo.

  :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`

    Questo file descrive lo stile della codifica per il kernel Linux,
    e parte delle motivazioni che ne sono alla base. Tutto il nuovo codice deve
    seguire le linee guida in questo documento. Molti amministratori
    accetteranno patch solo se queste osserveranno tali regole, e molte
    persone revisioneranno il codice solo se scritto nello stile appropriato.

  :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`

    Questo file descrive dettagliatamente come creare ed inviare una patch
    con successo, includendo (ma non solo questo):

       - Contenuto delle email
       - Formato delle email
       - I destinatari delle email

    Seguire tali regole non garantirà il successo (tutte le patch sono soggette
    a controlli realitivi a contenuto e stile), ma non seguirle lo precluderà
    sempre.

    Altre ottime descrizioni di come creare buone patch sono:

	"The Perfect Patch"
		https://www.ozlabs.org/~akpm/stuff/tpp.txt

	"Linux kernel patch submission format"
		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html

  :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst <it_stable_api_nonsense>`

    Questo file descrive la motivazioni sottostanti la conscia decisione di
    non avere un API stabile all'interno del kernel, incluso cose come:

      - Sottosistemi shim-layers (per compatibilità?)
      - Portabilità fra Sistemi Operativi dei driver.
      - Attenuare i rapidi cambiamenti all'interno dei sorgenti del kernel
        (o prevenirli)

    Questo documento è vitale per la comprensione della filosifia alla base
    dello sviluppo di Linux ed è molto importante per le persone che arrivano
    da esperienze con altri Sistemi Operativi.

  :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`
    Se ritenete di aver trovato un problema di sicurezza nel kernel Linux,
    seguite i passaggi scritti in questo documento per notificarlo agli
    sviluppatori del kernel, ed aiutare la risoluzione del problema.

  :ref:`Documentation/translations/it_IT/process/management-style.rst <it_managementstyle>`
    Questo documento descrive come i manutentori del kernel Linux operano
    e la filosofia comune alla base del loro metodo.  Questa è un'importante
    lettura per tutti coloro che sono nuovi allo sviluppo del kernel (o per
    chi è semplicemente curioso), poiché risolve molti dei più comuni
    fraintendimenti e confusioni dovuti al particolare comportamento dei
    manutentori del kernel.

  :ref:`Documentation/translations/it_IT/process/stable-kernel-rules.rst <it_stable_kernel_rules>`
    Questo file descrive le regole sulle quali vengono basati i rilasci del
    kernel, e spiega cosa fare se si vuole che una modifica venga inserita
    in uno di questi rilasci.

  :ref:`Documentation/translations/it_IT/process/kernel-docs.rst <it_kernel_docs>`
    Una lista di documenti pertinenti allo sviluppo del kernel.
    Per favore consultate questa lista se non trovate ciò che cercate nella
    documentazione interna del kernel.

  :ref:`Documentation/translations/it_IT/process/applying-patches.rst <it_applying_patches>`
    Una buona introduzione che descrivere esattamente cos'è una patch e come
    applicarla ai differenti rami di sviluppo del kernel.

Il kernel inoltre ha un vasto numero di documenti che possono essere
automaticamente generati dal codice sorgente stesso o da file
ReStructuredText (ReST), come questo. Esso include una completa
descrizione dell'API interna del kernel, e le regole su come gestire la
sincronizzazione (locking) correttamente

Tutte queste tipologie di documenti possono essere generati in PDF o in
HTML utilizzando::

	make pdfdocs
	make htmldocs

rispettivamente dalla cartella principale dei sorgenti del kernel.

I documenti che impiegano ReST saranno generati nella cartella
Documentation/output.
Questi posso essere generati anche in formato LaTex e ePub con::

	make latexdocs
	make epubdocs

Diventare uno sviluppatore del kernel
-------------------------------------
Se non sapete nulla sullo sviluppo del kernel Linux, dovreste dare uno
sguardo al progetto *Linux KernelNewbies*:

	https://kernelnewbies.org

Esso prevede un'utile lista di discussione dove potete porre più o meno ogni
tipo di quesito relativo ai concetti fondamentali sullo sviluppo del kernel
(assicuratevi di cercare negli archivi, prima di chiedere qualcosa alla
quale è già stata fornita risposta in passato). Esistono inoltre, un canale IRC
che potete usare per formulare domande in tempo reale, e molti documenti utili
che vi faciliteranno nell'apprendimento dello sviluppo del kernel Linux.

Il sito internet contiene informazioni di base circa l'organizzazione del
codice, sottosistemi e progetti attuali (sia interni che esterni a Linux).
Esso descrive, inoltre, informazioni logistiche di base, riguardanti ad esempio
la compilazione del kernel e l'applicazione di una modifica.

Se non sapete dove cominciare, ma volete cercare delle attività dalle quali
partire per partecipare alla comunità di sviluppo, andate al progetto Linux
Kernel Janitor's.

	https://kernelnewbies.org/KernelJanitors

È un buon posto da cui iniziare. Esso presenta una lista di problematiche
relativamente semplici da sistemare e pulire all'interno della sorgente del
kernel Linux. Lavorando con gli sviluppatori incaricati di questo progetto,
imparerete le basi per l'inserimento delle vostre modifiche all'interno dei
sorgenti del kernel Linux, e possibilmente, sarete indirizzati al lavoro
successivo da svolgere, se non ne avrete ancora idea.

Prima di apportare una qualsiasi modifica al codice del kernel Linux,
è imperativo comprendere come tale codice funziona. A questo scopo, non c'è
nulla di meglio che leggerlo direttamente (la maggior parte dei bit più
complessi sono ben commentati), eventualmente anche con l'aiuto di strumenti
specializzati. Uno degli strumenti che è particolarmente raccomandato è
il progetto Linux Cross-Reference, che è in grado di presentare codice
sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed
aggiornata fonte di consultazione del codice del kernel la potete trovare qui:

	https://elixir.bootlin.com/

Il processo di sviluppo
-----------------------
Il processo di sviluppo del kernel Linux si compone di pochi "rami" principali
e di molti altri rami per specifici sottosistemi. Questi rami sono:

  - I sorgenti kernel 4.x
  - I sorgenti stabili del kernel 4.x.y -stable
  - Sorgenti dei sottosistemi del kernel e le loro modifiche
  - Il kernel 4.x -next per test d'integrazione

I sorgenti kernel 4.x
~~~~~~~~~~~~~~~~~~~~~

I kernel 4.x sono amministrati da Linus Torvald, e possono essere trovati
su https://kernel.org nella cartella pub/linux/kernel/v4.x/. Il processo
di sviluppo è il seguente:

  - Non appena un nuovo kernel viene rilasciato si apre una finestra di due
    settimane. Durante questo periodo i manutentori possono proporre a Linus
    dei grossi cambiamenti; solitamente i cambiamenti che sono già stati
    inseriti nel ramo -next del kernel per alcune settimane. Il modo migliore
    per sottoporre dei cambiamenti è attraverso git (lo strumento usato per
    gestire i sorgenti del kernel, più informazioni sul sito
    https://git-scm.com/) ma anche delle patch vanno bene.

  - Al termine delle due settimane un kernel -rc1 viene rilasciato e
    l'obbiettivo ora è quello di renderlo il più solido possibile. A questo
    punto la maggior parte delle patch dovrebbero correggere un'eventuale
    regressione. I bachi che sono sempre esistiti non sono considerabili come
    regressioni, quindi inviate questo tipo di cambiamenti solo se sono
    importanti. Notate che un intero driver (o filesystem) potrebbe essere
    accettato dopo la -rc1 poiché non esistono rischi di una possibile
    regressione con tale cambiamento, fintanto che quest'ultimo è
    auto-contenuto e non influisce su aree esterne al codice che è stato
    aggiunto. git può essere utilizzato per inviare le patch a Linus dopo che
    la -rc1 è stata rilasciata, ma è anche necessario inviare le patch ad
    una lista di discussione pubblica per un'ulteriore revisione.

  - Una nuova -rc viene rilasciata ogni volta che Linus reputa che gli attuali
    sorgenti siano in uno stato di salute ragionevolmente adeguato ai test.
    L'obiettivo è quello di rilasciare una nuova -rc ogni settimana.

  - Il processo continua fino a che il kernel è considerato "pronto"; tale
    processo dovrebbe durare circa in 6 settimane.

È utile menzionare quanto scritto da Andrew Morton sulla lista di discussione
kernel-linux in merito ai rilasci del kernel:

	*"Nessuno sa quando un kernel verrà rilasciato, poichè questo è
	legato allo stato dei bachi e non ad una cronologia preventiva."*

I sorgenti stabili del kernel 4.x.y -stable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I kernel con versioni in 3-parti sono "kernel stabili". Essi contengono
correzioni critiche relativamente piccole nell'ambito della sicurezza
oppure significative regressioni scoperte in un dato 4.x kernel.

Questo è il ramo raccomandato per gli utenti che vogliono un kernel recente
e stabile e non sono interessati a dare il proprio contributo alla verifica
delle versioni di sviluppo o sperimentali.

Se non è disponibile alcun kernel 4.x.y., quello più aggiornato e stabile
sarà il kernel 4.x con la numerazione più alta.

4.x.y sono amministrati dal gruppo "stable" <stable@vger.kernel.org>, e sono
rilasciati a seconda delle esigenze. Il normale periodo di rilascio è
approssimativamente di due settimane, ma può essere più lungo se non si
verificano problematiche urgenti. Un problema relativo alla sicurezza, invece,
può determinare un rilascio immediato.

Il file Documentation/process/stable-kernel-rules.rst (nei sorgenti) documenta
quali tipologie di modifiche sono accettate per i sorgenti -stable, e come
avviene il processo di rilascio.

Sorgenti dei sottosistemi del kernel e le loro patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I manutentori dei diversi sottosistemi del kernel --- ed anche molti
sviluppatori di sottosistemi --- mostrano il loro attuale stato di sviluppo
nei loro repositori. In questo modo, altri possono vedere cosa succede nelle
diverse parti del kernel. In aree dove lo sviluppo è rapido, potrebbe essere
chiesto ad uno sviluppatore di basare le proprie modifiche su questi repositori
in modo da evitare i conflitti fra le sottomissioni ed altri lavori in corso

La maggior parte di questi repositori sono git, ma esistono anche altri SCM
in uso, o file di patch pubblicate come una serie quilt.
Gli indirizzi dei repositori di sottosistema sono indicati nel file
MAINTAINERS.  Molti di questi posso essere trovati su  https://git.kernel.org/.

Prima che una modifica venga inclusa in questi sottosistemi, sarà soggetta ad
una revisione che inizialmente avviene tramite liste di discussione (vedere la
sezione dedicata qui sotto). Per molti sottosistemi del kernel, tale processo
di revisione è monitorato con lo strumento patchwork.
Patchwork offre un'interfaccia web che mostra le patch pubblicate, inclusi i
commenti o le revisioni fatte, e gli amministratori possono indicare le patch
come "in revisione", "accettate", o "rifiutate". Diversi siti Patchwork sono
elencati al sito https://patchwork.kernel.org/.

Il kernel 4.x -next per test d'integrazione
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Prima che gli aggiornamenti dei sottosistemi siano accorpati nel ramo
principale 4.x, sarà necessario un test d'integrazione.
A tale scopo, esiste un repositorio speciale di test nel quale virtualmente
tutti i rami dei sottosistemi vengono inclusi su base quotidiana:

	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

In questo modo, i kernel -next offrono uno sguardo riassuntivo su quello che
ci si aspetterà essere nel kernel principale nel successivo periodo
d'incorporazione.
Coloro che vorranno fare dei test d'esecuzione del kernel -next sono più che
benvenuti.

Riportare Bug
-------------

Il file 'Documentation/admin-guide/reporting-issues.rst' nella
cartella principale del kernel spiega come segnalare un baco nel
kernel, e fornisce dettagli su quali informazioni sono necessarie agli
sviluppatori del kernel per poter studiare il problema.

Gestire i rapporti sui bug
--------------------------

Uno dei modi migliori per mettere in pratica le vostre capacità di hacking è
quello di riparare bachi riportati da altre persone. Non solo aiuterete a far
diventare il kernel più stabile, ma imparerete a riparare problemi veri dal
mondo ed accrescerete le vostre competenze, e gli altri sviluppatori saranno
al corrente della vostra presenza. Riparare bachi è una delle migliori vie per
acquisire meriti tra gli altri sviluppatori, perchè non a molte persone piace
perdere tempo a sistemare i bachi di altri.

Per lavorare sui bachi già segnalati, per prima cosa cercate il
sottosistema che vi interessa. Poi, verificate nel file MAINTAINERS
dove vengono collezionati solitamente i bachi per quel sottosistema;
spesso sarà una lista di discussione, raramente un bugtracker. Cercate
bachi nell'archivio e aiutate dove credete di poterlo fare. Potete
anche consultare https://bugzilla.kernel.org; però, solo una manciata di
sottosistemi lo usano attivamente, ciò nonostante i bachi che
coinvolgono l'intero kernel sono sempre riportati lì.

Liste di discussione
--------------------

Come descritto in molti dei documenti qui sopra, la maggior parte degli
sviluppatori del kernel partecipano alla lista di discussione Linux Kernel.
I dettagli su come iscriversi e disiscriversi dalla lista possono essere
trovati al sito:

	http://vger.kernel.org/vger-lists.html#linux-kernel

Ci sono diversi archivi della lista di discussione. Usate un qualsiasi motore
di ricerca per trovarli. Per esempio:

	https://lore.kernel.org/lkml/

É caldamente consigliata una ricerca in questi archivi sul tema che volete
sollevare, prima di pubblicarlo sulla lista. Molte cose sono già state
discusse in dettaglio e registrate negli archivi della lista di discussione.

Molti dei sottosistemi del kernel hanno anche una loro lista di discussione
dedicata.  Guardate nel file MAINTAINERS per avere una lista delle liste di
discussione e il loro uso.

Molte di queste liste sono gestite su kernel.org. Per informazioni consultate
la seguente pagina:

	http://vger.kernel.org/vger-lists.html

Per favore ricordatevi della buona educazione quando utilizzate queste liste.
Sebbene sia un pò dozzinale, il seguente URL contiene alcune semplici linee
guida per interagire con la lista (o con qualsiasi altra lista):

	http://www.albion.com/netiquette/

Se diverse persone rispondo alla vostra mail, la lista dei riceventi (copia
conoscenza) potrebbe diventare abbastanza lunga. Non cancellate nessuno dalla
lista di CC: senza un buon motivo, e non rispondete solo all'indirizzo
della lista di discussione. Fateci l'abitudine perché capita spesso di
ricevere la stessa email due volte: una dal mittente ed una dalla lista; e non
cercate di modificarla aggiungendo intestazioni stravaganti, agli altri non
piacerà.

Ricordate di rimanere sempre in argomento e di mantenere le attribuzioni
delle vostre risposte invariate; mantenete il "John Kernelhacker wrote ...:"
in cima alla vostra replica e aggiungete le vostre risposte fra i singoli
blocchi citati, non scrivete all'inizio dell'email.

Se aggiungete patch alla vostra mail, assicuratevi che siano del tutto
leggibili come indicato in Documentation/process/submitting-patches.rst.
Gli sviluppatori kernel non vogliono avere a che fare con allegati o patch
compresse; vogliono invece poter commentare le righe dei vostri cambiamenti,
il che può funzionare solo in questo modo.
Assicuratevi di utilizzare un gestore di mail che non alterì gli spazi ed i
caratteri. Un ottimo primo test è quello di inviare a voi stessi una mail e
cercare di sottoporre la vostra stessa patch. Se non funziona, sistemate il
vostro programma di posta, o cambiatelo, finché non funziona.

Ed infine, per favore ricordatevi di mostrare rispetto per gli altri
sottoscriventi.

Lavorare con la comunità
------------------------

L'obiettivo di questa comunità è quello di fornire il miglior kernel possibile.
Quando inviate una modifica che volete integrare, sarà valutata esclusivamente
dal punto di vista tecnico. Quindi, cosa dovreste aspettarvi?

  - critiche
  - commenti
  - richieste di cambiamento
  - richieste di spiegazioni
  - nulla

Ricordatevi che questo fa parte dell'integrazione della vostra modifica
all'interno del kernel.  Dovete essere in grado di accettare le critiche,
valutarle a livello tecnico ed eventualmente rielaborare nuovamente le vostre
modifiche o fornire delle chiare e concise motivazioni per le quali le
modifiche suggerite non dovrebbero essere fatte.
Se non riceverete risposte, aspettate qualche giorno e riprovate ancora,
qualche volta le cose si perdono nell'enorme mucchio di email.

Cosa non dovreste fare?

  - aspettarvi che la vostra modifica venga accettata senza problemi
  - mettervi sulla difensiva
  - ignorare i commenti
  - sottomettere nuovamente la modifica senza fare nessuno dei cambiamenti
    richiesti

In una comunità che è alla ricerca delle migliori soluzioni tecniche possibili,
ci saranno sempre opinioni differenti sull'utilità di una modifica.
Siate cooperativi e vogliate adattare la vostra idea in modo che sia inserita
nel kernel.  O almeno vogliate dimostrare che la vostra idea vale.
Ricordatevi, sbagliare è accettato fintanto che siate disposti a lavorare verso
una soluzione che è corretta.

È normale che le risposte alla vostra prima modifica possa essere
semplicemente una lista con dozzine di cose che dovreste correggere.
Questo **non** implica che la vostra patch non sarà accettata, e questo
**non** è contro di voi personalmente.
Semplicemente correggete tutte le questioni sollevate contro la vostra modifica
ed inviatela nuovamente.

Differenze tra la comunità del kernel e le strutture aziendali
--------------------------------------------------------------

La comunità del kernel funziona diversamente rispetto a molti ambienti di
sviluppo aziendali.  Qui di seguito una lista di cose che potete provare a
fare per evitare problemi:

  Cose da dire riguardanti le modifiche da voi proposte:

  - "Questo risolve più problematiche."
  - "Questo elimina 2000 stringhe di codice."
  - "Qui una modifica che spiega cosa sto cercando di fare."
  - "L'ho testato su 5 diverse architetture.."
  - "Qui una serie di piccole modifiche che.."
  - "Questo aumenta le prestazioni di macchine standard..."

 Cose che dovreste evitare di dire:

    - "Lo abbiamo fatto in questo modo in AIX/ptx/Solaris, di conseguenza
       deve per forza essere giusto..."
    - "Ho fatto questo per 20 anni, quindi.."
    - "Questo è richiesto dalla mia Azienda per far soldi"
    - "Questo è per la linea di prodotti della nostra Azienda"
    - "Ecco il mio documento di design di 1000 pagine che descrive ciò che ho
       in mente"
    - "Ci ho lavorato per 6 mesi..."
    - "Ecco una patch da 5000 righe che.."
    - "Ho riscritto il pasticcio attuale, ed ecco qua.."
    - "Ho una scadenza, e questa modifica ha bisogno di essere approvata ora"

Un'altra cosa nella quale la comunità del kernel si differenzia dai più
classici ambienti di ingegneria del software è la natura "senza volto" delle
interazioni umane. Uno dei benefici dell'uso delle email e di irc come forma
primordiale di comunicazione è l'assenza di discriminazione basata su genere e
razza. L'ambienti di lavoro Linux accetta donne e minoranze perchè tutto quello
che sei è un indirizzo email.  Aiuta anche l'aspetto internazionale nel
livellare il terreno di gioco perchè non è possibile indovinare il genere
basandosi sul nome di una persona. Un uomo può chiamarsi Andrea ed una donna
potrebbe chiamarsi Pat. Gran parte delle donne che hanno lavorato al kernel
Linux e che hanno espresso una personale opinione hanno avuto esperienze
positive.

La lingua potrebbe essere un ostacolo per quelle persone che non si trovano
a loro agio con l'inglese.  Una buona padronanza del linguaggio può essere
necessaria per esporre le proprie idee in maniera appropiata all'interno
delle liste di discussione, quindi è consigliabile che rileggiate le vostre
email prima di inviarle in modo da essere certi che abbiano senso in inglese.

Spezzare le vostre modifiche
----------------------------

La comunità del kernel Linux non accetta con piacere grossi pezzi di codice
buttati lì tutti in una volta. Le modifiche necessitano di essere
adeguatamente presentate, discusse, e suddivise in parti più piccole ed
indipendenti.  Questo è praticamente l'esatto opposto di quello che le
aziende fanno solitamente.  La vostra proposta dovrebbe, inoltre, essere
presentata prestissimo nel processo di sviluppo, così che possiate ricevere
un riscontro su quello che state facendo. Lasciate che la comunità
senta che state lavorando con loro, e che non li stiate sfruttando come
discarica per le vostre aggiunte.  In ogni caso, non inviate 50 email nello
stesso momento in una lista di discussione, il più delle volte la vostra serie
di modifiche dovrebbe essere più piccola.

I motivi per i quali dovreste frammentare le cose sono i seguenti:

1) Piccole modifiche aumentano le probabilità che vengano accettate,
   altrimenti richiederebbe troppo tempo o sforzo nel verificarne
   la correttezza.  Una modifica di 5 righe può essere accettata da un
   manutentore con a mala pena una seconda occhiata. Invece, una modifica da
   500 linee può richiedere ore di rilettura per verificarne la correttezza
   (il tempo necessario è esponenzialmente proporzionale alla dimensione della
   modifica, o giù di lì)

   Piccole modifiche sono inoltre molto facili da debuggare quando qualcosa
   non va. È molto più facile annullare le modifiche una per una che
   dissezionare una patch molto grande dopo la sua sottomissione (e rompere
   qualcosa).

2) È importante non solo inviare piccole modifiche, ma anche riscriverle e
   semplificarle (o più semplicemente ordinarle) prima di sottoporle.

Qui un'analogia dello sviluppatore kernel Al Viro:

	*"Pensate ad un insegnante di matematica che corregge il compito
	di uno studente (di matematica). L'insegnante non vuole vedere le
	prove e gli errori commessi dallo studente prima che arrivi alla
	soluzione. Vuole vedere la risposta più pulita ed elegante
	possibile.  Un buono studente lo sa, e non presenterebbe mai le
	proprie bozze prima prima della soluzione finale"*

	*"Lo stesso vale per lo sviluppo del kernel. I manutentori ed i
	revisori non vogliono vedere il procedimento che sta dietro al
	problema che uno sta risolvendo. Vogliono vedere una soluzione
	semplice ed elegante."*

Può essere una vera sfida il saper mantenere l'equilibrio fra una presentazione
elegante della vostra soluzione, lavorare insieme ad una comunità e dibattere
su un lavoro incompleto.  Pertanto è bene entrare presto nel processo di
revisione per migliorare il vostro lavoro, ma anche per riuscire a tenere le
vostre modifiche in pezzettini che potrebbero essere già accettate, nonostante
la vostra intera attività non lo sia ancora.

In fine, rendetevi conto che non è accettabile inviare delle modifiche
incomplete con la promessa che saranno "sistemate dopo".

Giustificare le vostre modifiche
--------------------------------

Insieme alla frammentazione delle vostre modifiche, è altrettanto importante
permettere alla comunità Linux di capire perché dovrebbero accettarle.
Nuove funzionalità devono essere motivate come necessarie ed utili.

Documentare le vostre modifiche
-------------------------------

Quando inviate le vostre modifiche, fate particolare attenzione a quello che
scrivete nella vostra email.  Questa diventerà il *ChangeLog* per la modifica,
e sarà visibile a tutti per sempre.  Dovrebbe descrivere la modifica nella sua
interezza, contenendo:

 - perchè la modifica è necessaria
 - l'approccio d'insieme alla patch
 - dettagli supplementari
 - risultati dei test

Per maggiori dettagli su come tutto ciò dovrebbe apparire, riferitevi alla
sezione ChangeLog del documento:

 "The Perfect Patch"
      http://www.ozlabs.org/~akpm/stuff/tpp.txt

A volte tutto questo è difficile da realizzare. Il perfezionamento di queste
pratiche può richiedere anni (eventualmente). È un processo continuo di
miglioramento che richiede molta pazienza e determinazione. Ma non mollate,
si può fare. Molti lo hanno fatto prima, ed ognuno ha dovuto iniziare dove
siete voi ora.

----------

Grazie a Paolo Ciarrocchi che ha permesso che la sezione "Development Process"
(https://lwn.net/Articles/94386/) fosse basata sui testi da lui scritti, ed a
Randy Dunlap e Gerrit Huizenga per la lista di cose che dovreste e non
dovreste dire. Grazie anche a Pat Mochel, Hanna Linder, Randy Dunlap,
Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton,
Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
David A. Wheeler, Junio Hamano, Michael Kerrisk, e Alex Shepard per le
loro revisioni, commenti e contributi.  Senza il loro aiuto, questo documento
non sarebbe stato possibile.

Manutentore: Greg Kroah-Hartman <greg@kroah.com>


code:
.. raw:: latex

	\renewcommand\thesection*
	\renewcommand\thesubsection*

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/index.rst <process_index>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_process_index:

Lavorare con la comunità di sviluppo del kernel
===============================================

Quindi volete diventare sviluppatori del kernel?  Benvenuti! C'è molto da
imparare sul lato tecnico del kernel, ma è anche importante capire come
funziona la nostra comunità.  Leggere questi documenti renderà più facile
l'accettazione delle vostre modifiche con il minimo sforzo.

Di seguito le guide che ogni sviluppatore dovrebbe leggere.

.. toctree::
   :maxdepth: 1

   howto
   code-of-conduct
   development-process
   submitting-patches
   programming-language
   coding-style
   maintainer-pgp-guide
   email-clients
   kernel-enforcement-statement
   kernel-driver-statement

Poi ci sono altre guide sulla comunità che sono di interesse per molti
degli sviluppatori:

.. toctree::
   :maxdepth: 1

   changes
   stable-api-nonsense
   management-style
   stable-kernel-rules
   submit-checklist
   kernel-docs
   maintainers

Ed infine, qui ci sono alcune guide più tecniche che son state messe qua solo
perché non si è trovato un posto migliore.

.. toctree::
   :maxdepth: 1

   applying-patches
   adding-syscalls
   magic-number
   volatile-considered-harmful
   clang-format
   ../riscv/patch-acceptance

.. only::  subproject and html

   Indices
   =======

   * :ref:`genindex`

repo_name: angery/linux


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_kernel_docs:

Indice di documenti per le persone interessate a capire e/o scrivere per il kernel Linux
========================================================================================

.. note::
   Questo documento contiene riferimenti a documenti in lingua inglese; inoltre
   utilizza dai campi *ReStructuredText* di supporto alla ricerca e che per
   questo motivo è meglio non tradurre al fine di garantirne un corretto
   utilizzo.
   Per questi motivi il documento non verrà tradotto. Per favore fate
   riferimento al documento originale in lingua inglese.


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/kernel-driver-statement.rst <process_statement_driver>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_process_statement_driver:

Dichiarazioni sui driver per il kernel
======================================

Presa di posizione sui moduli per il kernel Linux
-------------------------------------------------

Noi, i sottoscritti sviluppatori del kernel, consideriamo pericoloso
o indesiderato qualsiasi modulo o driver per il kernel Linux di tipo
*a sorgenti chiusi* (*closed-source*). Ripetutamente, li abbiamo
trovati deleteri per gli utenti Linux, le aziende, ed in generale
l'ecosistema Linux. Questi moduli impediscono l'apertura, la stabilità,
la flessibilità, e la manutenibilità del modello di sviluppo di Linux
e impediscono ai loro utenti di beneficiare dell'esperienza dalla
comunità Linux. I fornitori che distribuiscono codice a sorgenti chiusi
obbligano i propri utenti a rinunciare ai principali vantaggi di Linux
o a cercarsi nuovi fornitori.
Perciò, al fine di sfruttare i vantaggi che codice aperto ha da offrire,
come l'abbattimento dei costi e un supporto condiviso, spingiamo i
fornitori ad adottare una politica di supporto ai loro clienti Linux
che preveda il rilascio dei sorgenti per il kernel.

Parliamo solo per noi stessi, e non per una qualsiasi azienda per la
quale lavoriamo oggi, o abbiamo lavorato in passato, o lavoreremo in
futuro.

 - Dave Airlie
 - Nick Andrew
 - Jens Axboe
 - Ralf Baechle
 - Felipe Balbi
 - Ohad Ben-Cohen
 - Muli Ben-Yehuda
 - Jiri Benc
 - Arnd Bergmann
 - Thomas Bogendoerfer
 - Vitaly Bordug
 - James Bottomley
 - Josh Boyer
 - Neil Brown
 - Mark Brown
 - David Brownell
 - Michael Buesch
 - Franck Bui-Huu
 - Adrian Bunk
 - François Cami
 - Ralph Campbell
 - Luiz Fernando N. Capitulino
 - Mauro Carvalho Chehab
 - Denis Cheng
 - Jonathan Corbet
 - Glauber Costa
 - Alan Cox
 - Magnus Damm
 - Ahmed S. Darwish
 - Robert P. J. Day
 - Hans de Goede
 - Arnaldo Carvalho de Melo
 - Helge Deller
 - Jean Delvare
 - Mathieu Desnoyers
 - Sven-Thorsten Dietrich
 - Alexey Dobriyan
 - Daniel Drake
 - Alex Dubov
 - Randy Dunlap
 - Michael Ellerman
 - Pekka Enberg
 - Jan Engelhardt
 - Mark Fasheh
 - J. Bruce Fields
 - Larry Finger
 - Jeremy Fitzhardinge
 - Mike Frysinger
 - Kumar Gala
 - Robin Getz
 - Liam Girdwood
 - Jan-Benedict Glaw
 - Thomas Gleixner
 - Brice Goglin
 - Cyrill Gorcunov
 - Andy Gospodarek
 - Thomas Graf
 - Krzysztof Halasa
 - Harvey Harrison
 - Stephen Hemminger
 - Michael Hennerich
 - Tejun Heo
 - Benjamin Herrenschmidt
 - Kristian Høgsberg
 - Henrique de Moraes Holschuh
 - Marcel Holtmann
 - Mike Isely
 - Takashi Iwai
 - Olof Johansson
 - Dave Jones
 - Jesper Juhl
 - Matthias Kaehlcke
 - Kenji Kaneshige
 - Jan Kara
 - Jeremy Kerr
 - Russell King
 - Olaf Kirch
 - Roel Kluin
 - Hans-Jürgen Koch
 - Auke Kok
 - Peter Korsgaard
 - Jiri Kosina
 - Aaro Koskinen
 - Mariusz Kozlowski
 - Greg Kroah-Hartman
 - Michael Krufky
 - Aneesh Kumar
 - Clemens Ladisch
 - Christoph Lameter
 - Gunnar Larisch
 - Anders Larsen
 - Grant Likely
 - John W. Linville
 - Yinghai Lu
 - Tony Luck
 - Pavel Machek
 - Matt Mackall
 - Paul Mackerras
 - Roland McGrath
 - Patrick McHardy
 - Kyle McMartin
 - Paul Menage
 - Thierry Merle
 - Eric Miao
 - Akinobu Mita
 - Ingo Molnar
 - James Morris
 - Andrew Morton
 - Paul Mundt
 - Oleg Nesterov
 - Luca Olivetti
 - S.Çağlar Onur
 - Pierre Ossman
 - Keith Owens
 - Venkatesh Pallipadi
 - Nick Piggin
 - Nicolas Pitre
 - Evgeniy Polyakov
 - Richard Purdie
 - Mike Rapoport
 - Sam Ravnborg
 - Gerrit Renker
 - Stefan Richter
 - David Rientjes
 - Luis R. Rodriguez
 - Stefan Roese
 - Francois Romieu
 - Rami Rosen
 - Stephen Rothwell
 - Maciej W. Rozycki
 - Mark Salyzyn
 - Yoshinori Sato
 - Deepak Saxena
 - Holger Schurig
 - Amit Shah
 - Yoshihiro Shimoda
 - Sergei Shtylyov
 - Kay Sievers
 - Sebastian Siewior
 - Rik Snel
 - Jes Sorensen
 - Alexey Starikovskiy
 - Alan Stern
 - Timur Tabi
 - Hirokazu Takata
 - Eliezer Tamir
 - Eugene Teo
 - Doug Thompson
 - FUJITA Tomonori
 - Dmitry Torokhov
 - Marcelo Tosatti
 - Steven Toth
 - Theodore Tso
 - Matthias Urlichs
 - Geert Uytterhoeven
 - Arjan van de Ven
 - Ivo van Doorn
 - Rik van Riel
 - Wim Van Sebroeck
 - Hans Verkuil
 - Horst H. von Brand
 - Dmitri Vorobiev
 - Anton Vorontsov
 - Daniel Walker
 - Johannes Weiner
 - Harald Welte
 - Matthew Wilcox
 - Dan J. Williams
 - Darrick J. Wong
 - David Woodhouse
 - Chris Wright
 - Bryan Wu
 - Rafael J. Wysocki
 - Herbert Xu
 - Vlad Yasevich
 - Peter Zijlstra
 - Bartlomiej Zolnierkiewicz


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_process_statement_kernel:

Applicazione della licenza sul kernel Linux
===========================================

Come sviluppatori del kernel Linux, abbiamo un certo interessa su come il
nostro software viene usato e su come la sua licenza viene fatta rispettare.
Il rispetto reciproco degli obblighi di condivisione della GPL-2.0 è
fondamentale per la sostenibilità di lungo periodo del nostro software e
della nostra comunità.

Benché ognuno abbia il diritto a far rispettare il diritto d'autore per i
propri contributi alla nostra comunità, condividiamo l'interesse a far si che
ogni azione individuale nel far rispettare i propri diritti sia condotta in
modo da portare beneficio alla comunità e che non abbia, involontariamente,
impatti negativi sulla salute e la crescita del nostro ecosistema software.
Al fine di scoraggiare l'esecuzione di azioni inutili, concordiamo che è nel
migliore interesse della nostra comunità di sviluppo di impegnarci nel
rispettare i seguenti obblighi nei confronti degli utenti del kernel Linux
per conto nostro e di qualsiasi successore ai nostri interessi sul diritto
d'autore:

    Malgrado le clausole di risoluzione della licenza GPL-2.0, abbiamo
    concordato che è nel migliore interesse della nostra comunità di sviluppo
    adottare le seguenti disposizioni della GPL-3.0 come permessi aggiuntivi
    alla nostra licenza nei confronti di qualsiasi affermazione non difensiva
    di diritti sulla licenza.

	In ogni caso, se cessano tutte le violazioni di questa Licenza, allora
	la tua licenza da parte di un dato detentore del copyright viene
	ripristinata (a) in via cautelativa, a meno che e fino a quando il
	detentore del copyright non cessa esplicitamente e definitivamente
	la tua licenza, e (b) in via permanente se il detentore del copyright
	non ti notifica in alcun modo la violazione entro 60 giorni dalla
	cessazione della licenza.

	Inoltre, la tua licenza da parte di un dato detentore del copyright
	viene ripristinata in maniera permanente se il detentore del copyright
	ti notifica la violazione in maniera adeguata, se questa è la prima
	volta che ricevi una notifica di violazione di questa Licenza (per
	qualunque Programma) dallo stesso detentore di copyright, e se rimedi
	alla violazione entro 30 giorni dalla data di ricezione della notifica
	di violazione.

Fornendo queste garanzie, abbiamo l'intenzione di incoraggiare l'uso del
software.  Vogliamo che le aziende e le persone usino, modifichino e
distribuiscano a questo software.  Vogliamo lavorare con gli utenti in modo
aperto e trasparente per eliminare ogni incertezza circa le nostre aspettative
sul rispetto o l'ottemperanza alla licenza che possa limitare l'uso del nostro
software.  Vediamo l'azione legale come ultima spiaggia, da avviare solo quando
gli altri sforzi della comunità hanno fallito nel risolvere il problema.

Per finire, una volta che un problema di non rispetto della licenza viene
risolto, speriamo che gli utenti si sentano i benvenuti ad aggregarsi a noi
nello sviluppo di questo progetto.  Lavorando assieme, saremo più forti.

Ad eccezione deve specificato, parliamo per noi stessi, e non per una qualsiasi
azienda per la quale lavoriamo oggi, o per cui abbiamo lavorato in passato, o
lavoreremo in futuro.

  - Laura Abbott
  - Bjorn Andersson (Linaro)
  - Andrea Arcangeli
  - Neil Armstrong
  - Jens Axboe
  - Pablo Neira Ayuso
  - Khalid Aziz
  - Ralf Baechle
  - Felipe Balbi
  - Arnd Bergmann
  - Ard Biesheuvel
  - Tim Bird
  - Paolo Bonzini
  - Christian Borntraeger
  - Mark Brown (Linaro)
  - Paul Burton
  - Javier Martinez Canillas
  - Rob Clark
  - Kees Cook (Google)
  - Jonathan Corbet
  - Dennis Dalessandro
  - Vivien Didelot (Savoir-faire Linux)
  - Hans de Goede
  - Mel Gorman (SUSE)
  - Sven Eckelmann
  - Alex Elder (Linaro)
  - Fabio Estevam
  - Larry Finger
  - Bhumika Goyal
  - Andy Gross
  - Juergen Gross
  - Shawn Guo
  - Ulf Hansson
  - Stephen Hemminger (Microsoft)
  - Tejun Heo
  - Rob Herring
  - Masami Hiramatsu
  - Michal Hocko
  - Simon Horman
  - Johan Hovold (Hovold Consulting AB)
  - Christophe JAILLET
  - Olof Johansson
  - Lee Jones (Linaro)
  - Heiner Kallweit
  - Srinivas Kandagatla
  - Jan Kara
  - Shuah Khan (Samsung)
  - David Kershner
  - Jaegeuk Kim
  - Namhyung Kim
  - Colin Ian King
  - Jeff Kirsher
  - Greg Kroah-Hartman (Linux Foundation)
  - Christian König
  - Vinod Koul
  - Krzysztof Kozlowski
  - Viresh Kumar
  - Aneesh Kumar K.V
  - Julia Lawall
  - Doug Ledford
  - Chuck Lever (Oracle)
  - Daniel Lezcano
  - Shaohua Li
  - Xin Long
  - Tony Luck
  - Catalin Marinas (Arm Ltd)
  - Mike Marshall
  - Chris Mason
  - Paul E. McKenney
  - Arnaldo Carvalho de Melo
  - David S. Miller
  - Ingo Molnar
  - Kuninori Morimoto
  - Trond Myklebust
  - Martin K. Petersen (Oracle)
  - Borislav Petkov
  - Jiri Pirko
  - Josh Poimboeuf
  - Sebastian Reichel (Collabora)
  - Guenter Roeck
  - Joerg Roedel
  - Leon Romanovsky
  - Steven Rostedt (VMware)
  - Frank Rowand
  - Ivan Safonov
  - Anna Schumaker
  - Jes Sorensen
  - K.Y. Srinivasan
  - David Sterba (SUSE)
  - Heiko Stuebner
  - Jiri Kosina (SUSE)
  - Willy Tarreau
  - Dmitry Torokhov
  - Linus Torvalds
  - Thierry Reding
  - Rik van Riel
  - Luis R. Rodriguez
  - Geert Uytterhoeven (Glider bvba)
  - Eduardo Valentin (Amazon.com)
  - Daniel Vetter
  - Linus Walleij
  - Richard Weinberger
  - Dan Williams
  - Rafael J. Wysocki
  - Arvind Yadav
  - Masahiro Yamada
  - Wei Yongjun
  - Lv Zheng
  - Marc Zyngier (Arm Ltd)


code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_kernel_licensing:

Regole per licenziare il kernel Linux
=====================================

Il kernel Linux viene rilasciato sotto i termini definiti dalla seconda
versione della licenza *GNU General Public License* (GPL-2.0), di cui una
copia è disponibile nel file LICENSES/preferred/GPL-2.0; a questo si
aggiunge eccezione per le chiamate di sistema come descritto in
LICENSES/exceptions/Linux-syscall-note; tutto ciò è descritto nel file COPYING.

Questo documento fornisce una descrizione su come ogni singolo file sorgente
debba essere licenziato per far si che sia chiaro e non ambiguo. Questo non
sostituisce la licenza del kernel.

La licenza descritta nel file COPYING si applica ai sorgenti del kernel nella
loro interezza, quindi i singoli file sorgenti possono avere diverse licenze ma
devono essere compatibili con la GPL-2.0::

    GPL-1.0+  :  GNU General Public License v1.0 o successiva
    GPL-2.0+  :  GNU General Public License v2.0 o successiva
    LGPL-2.0  :  GNU Library General Public License v2
    LGPL-2.0+ :  GNU Library General Public License v2 o successiva
    LGPL-2.1  :  GNU Lesser General Public License v2.1
    LGPL-2.1+ :  GNU Lesser General Public License v2.1 o successiva

A parte questo, i singolo file possono essere forniti con una doppia licenza,
per esempio con una delle varianti compatibili della GPL e alternativamente con
una licenza permissiva come BSD, MIT eccetera.

I file d'intestazione per l'API verso lo spazio utente (UAPI) descrivono
le interfacce usate dai programmi, e per questo sono un caso speciale.
Secondo le note nel file COPYING, le chiamate di sistema sono un chiaro
confine oltre il quale non si estendono i requisiti della GPL per quei
programmi che le usano per comunicare con il kernel.  Dato che i file
d'intestazione UAPI devono poter essere inclusi nei sorgenti di un
qualsiasi programma eseguibile sul kernel Linux, questi meritano
un'eccezione documentata da una clausola speciale.

Il modo più comune per indicare la licenza dei file sorgenti è quello di
aggiungere il corrispondente blocco di testo come commento in testa a detto
file.  Per via della formattazione, dei refusi, eccetera, questi blocchi di
testo sono difficili da identificare dagli strumenti usati per verificare il
rispetto delle licenze.

Un'alternativa ai blocchi di testo è data dall'uso degli identificatori
*Software Package Data Exchange* (SPDX) in ogni file sorgente.  Gli
identificatori di licenza SPDX sono analizzabili dalle macchine e sono precisi
simboli stenografici che identificano la licenza sotto la quale viene
licenziato il file che lo include.  Gli identificatori di licenza SPDX sono
gestiti del gruppo di lavoro SPDX presso la Linux Foundation e sono stati
concordati fra i soci nell'industria, gli sviluppatori di strumenti, e i
rispettivi gruppi legali. Per maggiori informazioni, consultate
https://spdx.org/

Il kernel Linux richiede un preciso identificatore SPDX in tutti i file
sorgenti.  Gli identificatori validi verranno spiegati nella sezione
`Identificatori di licenza`_ e sono stati copiati dalla lista ufficiale di
licenze SPDX assieme al rispettivo testo come mostrato in
https://spdx.org/licenses/.

Sintassi degli identificatori di licenza
----------------------------------------

1. Posizionamento:

   L'identificativo di licenza SPDX dev'essere posizionato come prima riga
   possibile di un file che possa contenere commenti.  Per la maggior parte
   dei file questa è la prima riga, fanno eccezione gli script che richiedono
   come prima riga '#!PATH_TO_INTERPRETER'.  Per questi script l'identificativo
   SPDX finisce nella seconda riga.

|

2. Stile:

   L'identificativo di licenza SPDX viene aggiunto sotto forma di commento.
   Lo stile del commento dipende dal tipo di file::

      sorgenti C:	// SPDX-License-Identifier: <SPDX License Expression>
      intestazioni C:	/* SPDX-License-Identifier: <SPDX License Expression> */
      ASM:	/* SPDX-License-Identifier: <SPDX License Expression> */
      scripts:	# SPDX-License-Identifier: <SPDX License Expression>
      .rst:	.. SPDX-License-Identifier: <SPDX License Expression>
      .dts{i}:	// SPDX-License-Identifier: <SPDX License Expression>

   Se un particolare programma non dovesse riuscire a gestire lo stile
   principale per i commenti, allora dev'essere usato il meccanismo accettato
   dal programma.  Questo è il motivo per cui si ha "/\* \*/" nei file
   d'intestazione C.  Notammo che 'ld' falliva nell'analizzare i commenti del
   C++ nei file .lds che venivano prodotti.  Oggi questo è stato corretto,
   ma ci sono in giro ancora vecchi programmi che non sono in grado di
   gestire lo stile dei commenti del C++.

|

3. Sintassi:

   Una <espressione di licenza SPDX> può essere scritta usando l'identificatore
   SPDX della licenza come indicato nella lista di licenze SPDX, oppure la
   combinazione di due identificatori SPDX separati da "WITH" per i casi
   eccezionali. Quando si usano più licenze l'espressione viene formata da
   sottoespressioni separate dalle parole chiave "AND", "OR" e racchiuse fra
   parentesi tonde "(", ")".

   Gli identificativi di licenza per licenze come la [L]GPL che si avvalgono
   dell'opzione 'o successive' si formano aggiungendo alla fine il simbolo "+"
   per indicare l'opzione 'o successive'.::

      // SPDX-License-Identifier: GPL-2.0+
      // SPDX-License-Identifier: LGPL-2.1+

   WITH dovrebbe essere usato quando sono necessarie delle modifiche alla
   licenza.  Per esempio, la UAPI del kernel linux usa l'espressione::

      // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
      // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note

   Altri esempi di usi di WITH all'interno del kernel sono::

      // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
      // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0

   Le eccezioni si possono usare solo in combinazione con identificatori di
   licenza. Gli identificatori di licenza riconosciuti sono elencati nei
   corrispondenti file d'eccezione. Per maggiori dettagli consultate
   `Eccezioni`_ nel capitolo `Identificatori di licenza`_

   La parola chiave OR dovrebbe essere usata solo quando si usa una doppia
   licenza e solo una dev'essere scelta.  Per esempio, alcuni file dtsi sono
   disponibili con doppia licenza::

      // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause

   Esempi dal kernel di espressioni per file licenziati con doppia licenza
   sono::

      // SPDX-License-Identifier: GPL-2.0 OR MIT
      // SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
      // SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
      // SPDX-License-Identifier: GPL-2.0 OR MPL-1.1
      // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
      // SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL

   La parola chiave AND dovrebbe essere usata quando i termini di più licenze
   si applicano ad un file. Per esempio, quando il codice viene preso da
   un altro progetto il quale da i permessi per aggiungerlo nel kernel ma
   richiede che i termini originali della licenza rimangano intatti::

      // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT

   Di seguito, un altro esempio dove entrambe i termini di licenza devono
   essere rispettati::

      // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+

Identificatori di licenza
-------------------------

Le licenze attualmente in uso, così come le licenze aggiunte al kernel, possono
essere categorizzate in:

1. _`Licenze raccomandate`:

   Ovunque possibile le licenze qui indicate dovrebbero essere usate perché
   pienamente compatibili e molto usate.  Queste licenze sono disponibile nei
   sorgenti del kernel, nella cartella::

     LICENSES/preferred/

   I file in questa cartella contengono il testo completo della licenza e i
   `Metatag`_.  Il nome di questi file è lo stesso usato come identificatore
   di licenza SPDX e che deve essere usato nei file sorgenti.

   Esempi::

     LICENSES/preferred/GPL-2.0

   Contiene il testo della seconda versione della licenza GPL e i metatag
   necessari::

     LICENSES/preferred/MIT

   Contiene il testo della licenza MIT e i metatag necessari.

   _`Metatag`:

   I seguenti metatag devono essere presenti in un file di licenza:

   - Valid-License-Identifier:

     Una o più righe che dichiarano quali identificatori di licenza sono validi
     all'interno del progetto per far riferimento alla licenza in questione.
     Solitamente, questo è un unico identificatore valido, ma per esempio le
     licenze che permettono l'opzione 'o successive' hanno due identificatori
     validi.

   - SPDX-URL:

     L'URL della pagina SPDX che contiene informazioni aggiuntive riguardanti
     la licenza.

   - Usage-Guidance:

     Testo in formato libero per dare suggerimenti agli utenti. Il testo deve
     includere degli esempi su come usare gli identificatori di licenza SPDX
     in un file sorgente in conformità con le linea guida in
     `Sintassi degli identificatori di licenza`_.

   - License-Text:

     Tutto il testo che compare dopo questa etichetta viene trattato
     come se fosse parte del testo originale della licenza.

   Esempi::

      Valid-License-Identifier: GPL-2.0
      Valid-License-Identifier: GPL-2.0+
      SPDX-URL: https://spdx.org/licenses/GPL-2.0.html
      Usage-Guide:
        To use this license in source code, put one of the following SPDX
	tag/value pairs into a comment according to the placement
	guidelines in the licensing rules documentation.
	For 'GNU General Public License (GPL) version 2 only' use:
	  SPDX-License-Identifier: GPL-2.0
	For 'GNU General Public License (GPL) version 2 or any later version' use:
	  SPDX-License-Identifier: GPL-2.0+
      License-Text:
        Full license text

   ::

      SPDX-License-Identifier: MIT
      SPDX-URL: https://spdx.org/licenses/MIT.html
      Usage-Guide:
	To use this license in source code, put the following SPDX
	tag/value pair into a comment according to the placement
	guidelines in the licensing rules documentation.
	  SPDX-License-Identifier: MIT
      License-Text:
        Full license text

|

2. Licenze deprecate:

   Questo tipo di licenze dovrebbero essere usate solo per codice già esistente
   o quando si prende codice da altri progetti.  Le licenze sono disponibili
   nei sorgenti del kernel nella cartella::

     LICENSES/deprecated/

   I file in questa cartella contengono il testo completo della licenza e i
   `Metatag`_.  Il nome di questi file è lo stesso usato come identificatore
   di licenza SPDX e che deve essere usato nei file sorgenti.

   Esempi::

     LICENSES/deprecated/ISC

   Contiene il testo della licenza Internet System Consortium e i suoi
   metatag::

     LICENSES/deprecated/GPL-1.0

   Contiene il testo della versione 1 della licenza GPL e i suoi metatag.

   Metatag:

   I metatag necessari per le 'altre' ('other') licenze sono gli stessi
   di usati per le `Licenze raccomandate`_.

   Esempio del formato del file::

      Valid-License-Identifier: ISC
      SPDX-URL: https://spdx.org/licenses/ISC.html
      Usage-Guide:
        Usage of this license in the kernel for new code is discouraged
        and it should solely be used for importing code from an already
        existing project.
        To use this license in source code, put the following SPDX
        tag/value pair into a comment according to the placement
        guidelines in the licensing rules documentation.
          SPDX-License-Identifier: ISC
      License-Text:
        Full license text

|

3. Solo per doppie licenze

   Queste licenze dovrebbero essere usate solamente per codice licenziato in
   combinazione con un'altra licenza che solitamente è quella preferita.
   Queste licenze sono disponibili nei sorgenti del kernel nella cartella::

     LICENSES/dual

   I file in questa cartella contengono il testo completo della rispettiva
   licenza e i suoi `Metatag`_.  I nomi dei file sono identici agli
   identificatori di licenza SPDX che dovrebbero essere usati nei file
   sorgenti.

   Esempi::

     LICENSES/dual/MPL-1.1

   Questo file contiene il testo della versione 1.1 della licenza *Mozilla
   Pulic License* e i metatag necessari::

     LICENSES/dual/Apache-2.0

   Questo file contiene il testo della versione 2.0 della licenza Apache e i
   metatag necessari.

   Metatag:

   I requisiti per le 'altre' ('*other*') licenze sono identici a quelli per le
   `Licenze raccomandate`_.

   Esempio del formato del file::

    Valid-License-Identifier: MPL-1.1
    SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
    Usage-Guide:
      Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used for
      dual-licensed files where the other license is GPL2 compatible.
      If you end up using this it MUST be used together with a GPL2 compatible
      license using "OR".
      To use the Mozilla Public License version 1.1 put the following SPDX
      tag/value pair into a comment according to the placement guidelines in
      the licensing rules documentation:
    SPDX-License-Identifier: MPL-1.1
    License-Text:
      Full license text

|

4. _`Eccezioni`:

   Alcune licenze possono essere corrette con delle eccezioni che forniscono
   diritti aggiuntivi.  Queste eccezioni sono disponibili nei sorgenti del
   kernel nella cartella::

     LICENSES/exceptions/

   I file in questa cartella contengono il testo completo dell'eccezione e i
   `Metatag per le eccezioni`_.

   Esempi::

      LICENSES/exceptions/Linux-syscall-note

   Contiene la descrizione dell'eccezione per le chiamate di sistema Linux
   così come documentato nel file COPYING del kernel Linux; questo viene usato
   per i file d'intestazione per la UAPI.  Per esempio
   /\* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note \*/::

      LICENSES/exceptions/GCC-exception-2.0

   Contiene la 'eccezione di linking' che permette di collegare qualsiasi
   binario, indipendentemente dalla sua licenza, con un compilato il cui file
   sorgente è marchiato con questa eccezione. Questo è necessario per creare
   eseguibili dai sorgenti che non sono compatibili con la GPL.

   _`Metatag per le eccezioni`:

   Un file contenente un'eccezione deve avere i seguenti metatag:

   - SPDX-Exception-Identifier:

     Un identificatore d'eccezione che possa essere usato in combinazione con
     un identificatore di licenza SPDX.

   - SPDX-URL:

     L'URL della pagina SPDX che contiene informazioni aggiuntive riguardanti
     l'eccezione.

   - SPDX-Licenses:

     Una lista di licenze SPDX separate da virgola, che possono essere usate
     con l'eccezione.

   - Usage-Guidance:

     Testo in formato libero per dare suggerimenti agli utenti. Il testo deve
     includere degli esempi su come usare gli identificatori di licenza SPDX
     in un file sorgente in conformità con le linea guida in
     `Sintassi degli identificatori di licenza`_.

   - Exception-Text:

     Tutto il testo che compare dopo questa etichetta viene trattato
     come se fosse parte del testo originale della licenza.

   Esempi::

      SPDX-Exception-Identifier: Linux-syscall-note
      SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
      SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+
      Usage-Guidance:
        This exception is used together with one of the above SPDX-Licenses
	to mark user-space API (uapi) header files so they can be included
	into non GPL compliant user-space application code.
        To use this exception add it with the keyword WITH to one of the
	identifiers in the SPDX-Licenses tag:
	  SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
      Exception-Text:
        Full exception text

   ::

      SPDX-Exception-Identifier: GCC-exception-2.0
      SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
      SPDX-Licenses: GPL-2.0, GPL-2.0+
      Usage-Guidance:
        The "GCC Runtime Library exception 2.0" is used together with one
	of the above SPDX-Licenses for code imported from the GCC runtime
	library.
        To use this exception add it with the keyword WITH to one of the
	identifiers in the SPDX-Licenses tag:
	  SPDX-License-Identifier: <SPDX-License> WITH GCC-exception-2.0
      Exception-Text:
        Full exception text

Per ogni identificatore di licenza SPDX e per le eccezioni dev'esserci un file
nella sotto-cartella LICENSES.  Questo è necessario per permettere agli
strumenti di effettuare verifiche (come checkpatch.pl), per avere le licenze
disponibili per la lettura e per estrarre i diritti dai sorgenti, così come
raccomandato da diverse organizzazioni FOSS, per esempio l'`iniziativa FSFE
REUSE <https://reuse.software/>`_.

_`MODULE_LICENSE`
-----------------

   I moduli del kernel necessitano di un'etichetta MODULE_LICENSE(). Questa
   etichetta non sostituisce le informazioni sulla licenza del codice sorgente
   (SPDX-License-Identifier) né fornisce informazioni che esprimono o
   determinano l'esatta licenza sotto la quale viene rilasciato.

   Il solo scopo di questa etichetta è quello di fornire sufficienti
   informazioni al caricatore di moduli del kernel, o agli strumenti in spazio
   utente, per capire se il modulo è libero o proprietario.

   Le stringe di licenza valide per MODULE_LICENSE() sono:

    ============================= =============================================
    "GPL"			  Il modulo è licenziato con la GPL versione 2.
				  Questo non fa distinzione fra GPL'2.0-only o
				  GPL-2.0-or-later. L'esatta licenza può essere
				  determinata solo leggendo i corrispondenti
				  file sorgenti.

    "GPL v2"			  Stesso significato di "GPL". Esiste per
				  motivi storici.

    "GPL and additional rights"   Questa è una variante che esiste per motivi
				  storici che indica che i sorgenti di un
				  modulo sono rilasciati sotto una variante
				  della licenza GPL v2 e quella MIT. Per favore
				  non utilizzatela per codice nuovo.

    "Dual MIT/GPL"		  Questo è il modo corretto per esprimere il
				  il fatto che il modulo è rilasciato con
				  doppia licenza a scelta fra: una variante
				  della GPL v2 o la licenza MIT.

    "Dual BSD/GPL"		  Questo modulo è rilasciato con doppia licenza
				  a scelta fra: una variante della GPL v2 o la
				  licenza BSD. La variante esatta della licenza
				  BSD può essere determinata solo attraverso i
				  corrispondenti file sorgenti.

    "Dual MPL/GPL"		  Questo modulo è rilasciato con doppia licenza
				  a scelta fra: una variante della GPL v2 o la
				  Mozilla Public License (MPL). La variante
				  esatta della licenza MPL può essere
				  determinata solo attraverso i corrispondenti
				  file sorgenti.

    "Proprietary"		  Questo modulo è rilasciato con licenza
				  proprietaria. Questa stringa è solo per i
				  moduli proprietari di terze parti e non può
				  essere usata per quelli che risiedono nei
				  sorgenti del kernel. I moduli etichettati in
				  questo modo stanno contaminando il kernel e
				  gli viene assegnato un flag 'P'; quando
				  vengono caricati, il caricatore di moduli del
				  kernel si rifiuterà di collegare questi
				  moduli ai simboli che sono stati esportati
				  con EXPORT_SYMBOL_GPL().

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


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_magicnumbers:

I numeri magici di Linux
========================

Questo documento è un registro dei numeri magici in uso.  Quando
aggiungete un numero magico ad una struttura, dovreste aggiungerlo anche
a questo documento; la cosa migliore è che tutti i numeri magici usati
dalle varie strutture siano unici.

È **davvero** un'ottima idea proteggere le strutture dati del kernel con
dei numeri magici.  Questo vi permette in fase d'esecuzione di (a) verificare
se una struttura è stata malmenata, o (b) avete passato a una procedura la
struttura errata.  Quest'ultimo è molto utile - particolarmente quando si passa
una struttura dati tramite un puntatore void \*.  Il codice tty, per esempio,
effettua questa operazione con regolarità passando avanti e indietro le
strutture specifiche per driver e discipline.

Per utilizzare un numero magico, dovete dichiararlo all'inizio della struttura
dati, come di seguito::

	struct tty_ldisc {
		int	magic;
		...
	};

Per favore, seguite questa direttiva quando aggiungerete migliorie al kernel!
Mi ha risparmiato un numero illimitato di ore di debug, specialmente nei casi
più ostici dove si è andati oltre la dimensione di un vettore e la struttura
dati che lo seguiva in memoria è stata sovrascritta.  Seguendo questa
direttiva, questi casi vengono identificati velocemente e in sicurezza.

Registro dei cambiamenti::

					Theodore Ts'o
					31 Mar 94

  La tabella magica è aggiornata a Linux 2.1.55.

					Michael Chastain
					<mailto:mec@shout.net>
					22 Sep 1997

  Ora dovrebbe essere aggiornata a Linux 2.1.112. Dato che
  siamo in un momento di congelamento delle funzionalità
  (*feature freeze*) è improbabile che qualcosa cambi prima
  della versione 2.2.x.  Le righe sono ordinate secondo il
  campo numero.

					Krzysztof G. Baranowski
					<mailto: kgb@knm.org.pl>
					29 Jul 1998

  Aggiornamento della tabella a Linux 2.5.45. Giusti nel congelamento
  delle funzionalità ma è comunque possibile che qualche nuovo
  numero magico s'intrufoli prima del kernel 2.6.x.

					Petr Baudis
					<pasky@ucw.cz>
					03 Nov 2002

  Aggiornamento della tabella magica a Linux 2.5.74.

					Fabian Frederick
					<ffrederick@users.sourceforge.net>
					09 Jul 2003

===================== ================ ======================== ==========================================
Nome magico           Numero           Struttura                File
===================== ================ ======================== ==========================================
PG_MAGIC              'P'              pg_{read,write}_hdr      ``include/linux/pg.h``
APM_BIOS_MAGIC        0x4101           apm_user                 ``arch/x86/kernel/apm_32.c``
FASYNC_MAGIC          0x4601           fasync_struct            ``include/linux/fs.h``
SLIP_MAGIC            0x5302           slip                     ``drivers/net/slip.h``
MGSLPC_MAGIC          0x5402           mgslpc_info              ``drivers/char/pcmcia/synclink_cs.c``
BAYCOM_MAGIC          0x19730510       baycom_state             ``drivers/net/baycom_epp.c``
HDLCDRV_MAGIC         0x5ac6e778       hdlcdrv_state            ``include/linux/hdlcdrv.h``
KV_MAGIC              0x5f4b565f       kernel_vars_s            ``arch/mips/include/asm/sn/klkernvars.h``
CODA_MAGIC            0xC0DAC0DA       coda_file_info           ``fs/coda/coda_fs_i.h``
YAM_MAGIC             0xF10A7654       yam_port                 ``drivers/net/hamradio/yam.c``
CCB_MAGIC             0xf2691ad2       ccb                      ``drivers/scsi/ncr53c8xx.c``
QUEUE_MAGIC_FREE      0xf7e1c9a3       queue_entry              ``drivers/scsi/arm/queue.c``
QUEUE_MAGIC_USED      0xf7e1cc33       queue_entry              ``drivers/scsi/arm/queue.c``
NMI_MAGIC             0x48414d4d455201 nmi_s                    ``arch/mips/include/asm/sn/nmi.h``
===================== ================ ======================== ==========================================


code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: ../disclaimer-ita.rst

:Original: Documentation/process/maintainer-handbooks.rst
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_maintainer_handbooks_main:

Note sul processo di sviluppo dei sottosistemi e dei sorgenti dei manutentori
=============================================================================

Lo scopo di questo documento è quello di fornire informazioni sul processo di
sviluppo dedicate ai sottosistemi che vanno ad integrare quelle più generali
descritte in :ref:`Documentation/translations/it_IT/process
<it_development_process_main>`.

Indice:

.. toctree::
   :numbered:
   :maxdepth: 2

   maintainer-tip