Documentation/translations/it_IT/process/stable-api-nonsense.rst

   1 .. include:: ../disclaimer-ita.rst
   2
   3 :Original: :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
   4 :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
   5
   6 .. _it_stable_api_nonsense:
   7
   8 L'interfaccia dei driver per il kernel Linux
   9 ============================================
  10
  11 (tutte le risposte alle vostre domande e altro)
  12
  13 Greg Kroah-Hartman <greg@kroah.com>
  14
  15 Questo è stato scritto per cercare di spiegare perché Linux **non ha
  16 un'interfaccia binaria, e non ha nemmeno un'interfaccia stabile**.
  17
  18 .. note::
  19
  20    Questo articolo parla di interfacce **interne al kernel**, non delle
  21    interfacce verso lo spazio utente.
  22
  23    L'interfaccia del kernel verso lo spazio utente è quella usata dai
  24    programmi, ovvero le chiamate di sistema.  Queste interfacce sono **molto**
  25    stabili nel tempo e non verranno modificate.  Ho vecchi programmi che sono
  26    stati compilati su un kernel 0.9 (circa) e tuttora funzionano sulle versioni
  27    2.6 del kernel.  Queste interfacce sono quelle che gli utenti e i
  28    programmatori possono considerare stabili.
  29
  30 Riepilogo generale
  31 ------------------
  32
  33 Pensate di volere un'interfaccia del kernel stabile, ma in realtà non la
  34 volete, e nemmeno sapete di non volerla.  Quello che volete è un driver
  35 stabile che funzioni, e questo può essere ottenuto solo se il driver si trova
  36 nei sorgenti del kernel.  Ci sono altri vantaggi nell'avere il proprio driver
  37 nei sorgenti del kernel, ognuno dei quali hanno reso Linux un sistema operativo
  38 robusto, stabile e maturo; questi sono anche i motivi per cui avete scelto
  39 Linux.
  40
  41 Introduzione
  42 ------------
  43
  44 Solo le persone un po' strambe vorrebbero scrivere driver per il kernel con
  45 la costante preoccupazione per i cambiamenti alle interfacce interne.  Per il
  46 resto del mondo, queste interfacce sono invisibili o non di particolare
  47 interesse.
  48
  49 Innanzitutto, non tratterò **alcun** problema legale riguardante codice
  50 chiuso, nascosto, avvolto, blocchi binari, o qualsia altra cosa che descrive
  51 driver che non hanno i propri sorgenti rilasciati con licenza GPL.  Per favore
  52 fate riferimento ad un avvocato per qualsiasi questione legale, io sono un
  53 programmatore e perciò qui vi parlerò soltanto delle questioni tecniche (non
  54 per essere superficiali sui problemi legali, sono veri e dovete esserne a
  55 conoscenza in ogni circostanza).
  56
  57 Dunque, ci sono due tematiche principali: interfacce binarie del kernel e
  58 interfacce stabili nei sorgenti.  Ognuna dipende dall'altra, ma discuteremo
  59 prima delle cose binarie per toglierle di mezzo.
  60
  61 Interfaccia binaria del kernel
  62 ------------------------------
  63
  64 Supponiamo d'avere un'interfaccia stabile nei sorgenti del kernel, di
  65 conseguenza un'interfaccia binaria dovrebbe essere anche'essa stabile, giusto?
  66 Sbagliato.  Prendete in considerazione i seguenti fatti che riguardano il
  67 kernel Linux:
  68
  69   - A seconda della versione del compilatore C che state utilizzando, diverse
  70     strutture dati del kernel avranno un allineamento diverso, e possibilmente
  71     un modo diverso di includere le funzioni (renderle inline oppure no).
  72     L'organizzazione delle singole funzioni non è poi così importante, ma la
  73     spaziatura (*padding*) nelle strutture dati, invece, lo è.
  74
  75   - In base alle opzioni che sono state selezionate per generare il kernel,
  76     un certo numero di cose potrebbero succedere:
  77
  78       - strutture dati differenti potrebbero contenere campi differenti
  79       - alcune funzioni potrebbero non essere implementate (per esempio,
  80         alcuni *lock* spariscono se compilati su sistemi mono-processore)
  81       - la memoria interna del kernel può essere allineata in differenti modi
  82         a seconda delle opzioni di compilazione.
  83
  84   - Linux funziona su una vasta gamma di architetture di processore. Non esiste
  85     alcuna possibilità che il binario di un driver per un'architettura funzioni
  86     correttamente su un'altra.
  87
  88 Alcuni di questi problemi possono essere risolti compilando il proprio modulo
  89 con la stessa identica configurazione del kernel, ed usando la stessa versione
  90 del compilatore usato per compilare il kernel.  Questo è sufficiente se volete
  91 fornire un modulo per uno specifico rilascio su una specifica distribuzione
  92 Linux.  Ma moltiplicate questa singola compilazione per il numero di
  93 distribuzioni Linux e il numero dei rilasci supportati da quest'ultime e vi
  94 troverete rapidamente in un incubo fatto di configurazioni e piattaforme
  95 hardware (differenti processori con differenti opzioni); dunque, anche per il
  96 singolo rilascio di un modulo, dovreste creare differenti versioni dello
  97 stesso.
  98
  99 Fidatevi, se tenterete questa via, col tempo, diventerete pazzi; l'ho imparato
 100 a mie spese molto tempo fa...
 101
 102
 103 Interfaccia stabile nei sorgenti del kernel
 104 -------------------------------------------
 105
 106 Se parlate con le persone che cercano di mantenere aggiornato un driver per
 107 Linux ma che non si trova nei sorgenti, allora per queste persone l'argomento
 108 sarà "ostico".
 109
 110 Lo sviluppo del kernel Linux è continuo e viaggia ad un ritmo sostenuto, e non
 111 rallenta mai.  Perciò, gli sviluppatori del kernel trovano bachi nelle
 112 interfacce attuali, o trovano modi migliori per fare le cose.  Se le trovano,
 113 allora le correggeranno per migliorarle.  In questo frangente, i nomi delle
 114 funzioni potrebbero cambiare, le strutture dati potrebbero diventare più grandi
 115 o più piccole, e gli argomenti delle funzioni potrebbero essere ripensati.
 116 Se questo dovesse succedere, nello stesso momento, tutte le istanze dove questa
 117 interfaccia viene utilizzata verranno corrette, garantendo che tutto continui
 118 a funzionare senza problemi.
 119
 120 Portiamo ad esempio l'interfaccia interna per il sottosistema USB che ha subito
 121 tre ristrutturazioni nel corso della sua vita.  Queste ristrutturazioni furono
 122 fatte per risolvere diversi problemi:
 123
 124   - È stato fatto un cambiamento da un flusso di dati sincrono ad uno
 125     asincrono.  Questo ha ridotto la complessità di molti driver e ha
 126     aumentato la capacità di trasmissione di tutti i driver fino a raggiungere
 127     quasi la velocità massima possibile.
 128   - È stato fatto un cambiamento nell'allocazione dei pacchetti da parte del
 129     sottosistema USB per conto dei driver, cosicché ora i driver devono fornire
 130     più informazioni al sottosistema USB al fine di correggere un certo numero
 131     di stalli.
 132
 133 Questo è completamente l'opposto di quello che succede in alcuni sistemi
 134 operativi proprietari che hanno dovuto mantenere, nel tempo, il supporto alle
 135 vecchie interfacce USB.  I nuovi sviluppatori potrebbero usare accidentalmente
 136 le vecchie interfacce e sviluppare codice nel modo sbagliato, portando, di
 137 conseguenza, all'instabilità del sistema.
 138
 139 In entrambe gli scenari, gli sviluppatori hanno ritenuto che queste importanti
 140 modifiche erano necessarie, e quindi le hanno fatte con qualche sofferenza.
 141 Se Linux avesse assicurato di mantenere stabile l'interfaccia interna, si
 142 sarebbe dovuto procedere alla creazione di una nuova, e quelle vecchie, e
 143 mal funzionanti, avrebbero dovuto ricevere manutenzione, creando lavoro
 144 aggiuntivo per gli sviluppatori del sottosistema USB.  Dato che gli
 145 sviluppatori devono dedicare il proprio tempo a questo genere di lavoro,
 146 chiedergli di dedicarne dell'altro, senza benefici, magari gratuitamente, non
 147 è contemplabile.
 148
 149 Le problematiche relative alla sicurezza sono molto importanti per Linux.
 150 Quando viene trovato un problema di sicurezza viene corretto in breve tempo.
 151 A volte, per prevenire il problema di sicurezza, si sono dovute cambiare
 152 delle interfacce interne al kernel.  Quando è successo, allo stesso tempo,
 153 tutti i driver che usavano quelle interfacce sono stati aggiornati, garantendo
 154 la correzione definitiva del problema senza doversi preoccupare di rivederlo
 155 per sbaglio in futuro.  Se non si fossero cambiate le interfacce interne,
 156 sarebbe stato impossibile correggere il problema e garantire che non si sarebbe
 157 più ripetuto.
 158
 159 Nel tempo le interfacce del kernel subiscono qualche ripulita.  Se nessuno
 160 sta più usando un'interfaccia, allora questa verrà rimossa.  Questo permette
 161 al kernel di rimanere il più piccolo possibile, e garantisce che tutte le
 162 potenziali interfacce sono state verificate nel limite del possibile (le
 163 interfacce inutilizzate sono impossibili da verificare).
 164
 165
 166 Cosa fare
 167 ---------
 168
 169 Dunque, se avete un driver per il kernel Linux che non si trova nei sorgenti
 170 principali del kernel, come sviluppatori, cosa dovreste fare?  Rilasciare un
 171 file binario del driver per ogni versione del kernel e per ogni distribuzione,
 172 è un incubo; inoltre, tenere il passo con tutti i cambiamenti del kernel è un
 173 brutto lavoro.
 174
 175 Semplicemente, fate sì che il vostro driver per il kernel venga incluso nei
 176 sorgenti principali (ricordatevi, stiamo parlando di driver rilasciati secondo
 177 una licenza compatibile con la GPL; se il vostro codice non ricade in questa
 178 categoria: buona fortuna, arrangiatevi, siete delle sanguisughe)
 179
 180 Se il vostro driver è nei sorgenti del kernel e un'interfaccia cambia, il
 181 driver verrà corretto immediatamente dalla persona che l'ha modificata.  Questo
 182 garantisce che sia sempre possibile compilare il driver, che funzioni, e tutto
 183 con un minimo sforzo da parte vostra.
 184
 185 Avere il proprio driver nei sorgenti principali del kernel ha i seguenti
 186 vantaggi:
 187
 188   - La qualità del driver aumenterà e i costi di manutenzione (per lo
 189     sviluppatore originale) diminuiranno.
 190   - Altri sviluppatori aggiungeranno nuove funzionalità al vostro driver.
 191   - Altri persone troveranno e correggeranno bachi nel vostro driver.
 192   - Altri persone troveranno degli aggiustamenti da fare al vostro driver.
 193   - Altri persone aggiorneranno il driver quando è richiesto da un cambiamento
 194     di un'interfaccia.
 195   - Il driver sarà automaticamente reso disponibile in tutte le distribuzioni
 196     Linux senza dover chiedere a nessuna di queste di aggiungerlo.
 197
 198 Dato che Linux supporta più dispositivi di qualsiasi altro sistema operativo,
 199 e che girano su molti più tipi di processori di qualsiasi altro sistema
 200 operativo; ciò dimostra che questo modello di sviluppo qualcosa di giusto,
 201 dopo tutto, lo fa :)
 202
 203
 204
 205 ------
 206
 207 Dei ringraziamenti vanno a Randy Dunlap, Andrew Morton, David Brownell,
 208 Hanna Linder, Robert Love, e Nishanth Aravamudan per la loro revisione
 209 e per i loro commenti sulle prime bozze di questo articolo.