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.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.