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 8L'interfaccia dei driver per il kernel Linux 9============================================ 10 11(tutte le risposte alle vostre domande e altro) 12 13Greg Kroah-Hartman <greg@kroah.com> 14 15Questo è stato scritto per cercare di spiegare perché Linux **non ha 16un'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 30Riepilogo generale 31------------------ 32 33Pensate di volere un'interfaccia del kernel stabile, ma in realtà non la 34volete, e nemmeno sapete di non volerla. Quello che volete è un driver 35stabile che funzioni, e questo può essere ottenuto solo se il driver si trova 36nei sorgenti del kernel. Ci sono altri vantaggi nell'avere il proprio driver 37nei sorgenti del kernel, ognuno dei quali hanno reso Linux un sistema operativo 38robusto, stabile e maturo; questi sono anche i motivi per cui avete scelto 39Linux. 40 41Introduzione 42------------ 43 44Solo le persone un po' strambe vorrebbero scrivere driver per il kernel con 45la costante preoccupazione per i cambiamenti alle interfacce interne. Per il 46resto del mondo, queste interfacce sono invisibili o non di particolare 47interesse. 48 49Innanzitutto, non tratterò **alcun** problema legale riguardante codice 50chiuso, nascosto, avvolto, blocchi binari, o qualsia altra cosa che descrive 51driver che non hanno i propri sorgenti rilasciati con licenza GPL. Per favore 52fate riferimento ad un avvocato per qualsiasi questione legale, io sono un 53programmatore e perciò qui vi parlerò soltanto delle questioni tecniche (non 54per essere superficiali sui problemi legali, sono veri e dovete esserne a 55conoscenza in ogni circostanza). 56 57Dunque, ci sono due tematiche principali: interfacce binarie del kernel e 58interfacce stabili nei sorgenti. Ognuna dipende dall'altra, ma discuteremo 59prima delle cose binarie per toglierle di mezzo. 60 61Interfaccia binaria del kernel 62------------------------------ 63 64Supponiamo d'avere un'interfaccia stabile nei sorgenti del kernel, di 65conseguenza un'interfaccia binaria dovrebbe essere anche'essa stabile, giusto? 66Sbagliato. Prendete in considerazione i seguenti fatti che riguardano il 67kernel 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 88Alcuni di questi problemi possono essere risolti compilando il proprio modulo 89con la stessa identica configurazione del kernel, ed usando la stessa versione 90del compilatore usato per compilare il kernel. Questo è sufficiente se volete 91fornire un modulo per uno specifico rilascio su una specifica distribuzione 92Linux. Ma moltiplicate questa singola compilazione per il numero di 93distribuzioni Linux e il numero dei rilasci supportati da quest'ultime e vi 94troverete rapidamente in un incubo fatto di configurazioni e piattaforme 95hardware (differenti processori con differenti opzioni); dunque, anche per il 96singolo rilascio di un modulo, dovreste creare differenti versioni dello 97stesso. 98 99Fidatevi, se tenterete questa via, col tempo, diventerete pazzi; l'ho imparato 100a mie spese molto tempo fa... 101 102 103Interfaccia stabile nei sorgenti del kernel 104------------------------------------------- 105 106Se parlate con le persone che cercano di mantenere aggiornato un driver per 107Linux ma che non si trova nei sorgenti, allora per queste persone l'argomento 108sarà "ostico". 109 110Lo sviluppo del kernel Linux è continuo e viaggia ad un ritmo sostenuto, e non 111rallenta mai. Perciò, gli sviluppatori del kernel trovano bachi nelle 112interfacce attuali, o trovano modi migliori per fare le cose. Se le trovano, 113allora le correggeranno per migliorarle. In questo frangente, i nomi delle 114funzioni potrebbero cambiare, le strutture dati potrebbero diventare più grandi 115o più piccole, e gli argomenti delle funzioni potrebbero essere ripensati. 116Se questo dovesse succedere, nello stesso momento, tutte le istanze dove questa 117interfaccia viene utilizzata verranno corrette, garantendo che tutto continui 118a funzionare senza problemi. 119 120Portiamo ad esempio l'interfaccia interna per il sottosistema USB che ha subito 121tre ristrutturazioni nel corso della sua vita. Queste ristrutturazioni furono 122fatte 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 133Questo è completamente l'opposto di quello che succede in alcuni sistemi 134operativi proprietari che hanno dovuto mantenere, nel tempo, il supporto alle 135vecchie interfacce USB. I nuovi sviluppatori potrebbero usare accidentalmente 136le vecchie interfacce e sviluppare codice nel modo sbagliato, portando, di 137conseguenza, all'instabilità del sistema. 138 139In entrambe gli scenari, gli sviluppatori hanno ritenuto che queste importanti 140modifiche erano necessarie, e quindi le hanno fatte con qualche sofferenza. 141Se Linux avesse assicurato di mantenere stabile l'interfaccia interna, si 142sarebbe dovuto procedere alla creazione di una nuova, e quelle vecchie, e 143mal funzionanti, avrebbero dovuto ricevere manutenzione, creando lavoro 144aggiuntivo per gli sviluppatori del sottosistema USB. Dato che gli 145sviluppatori devono dedicare il proprio tempo a questo genere di lavoro, 146chiedergli di dedicarne dell'altro, senza benefici, magari gratuitamente, non 147è contemplabile. 148 149Le problematiche relative alla sicurezza sono molto importanti per Linux. 150Quando viene trovato un problema di sicurezza viene corretto in breve tempo. 151A volte, per prevenire il problema di sicurezza, si sono dovute cambiare 152delle interfacce interne al kernel. Quando è successo, allo stesso tempo, 153tutti i driver che usavano quelle interfacce sono stati aggiornati, garantendo 154la correzione definitiva del problema senza doversi preoccupare di rivederlo 155per sbaglio in futuro. Se non si fossero cambiate le interfacce interne, 156sarebbe stato impossibile correggere il problema e garantire che non si sarebbe 157più ripetuto. 158 159Nel tempo le interfacce del kernel subiscono qualche ripulita. Se nessuno 160sta più usando un'interfaccia, allora questa verrà rimossa. Questo permette 161al kernel di rimanere il più piccolo possibile, e garantisce che tutte le 162potenziali interfacce sono state verificate nel limite del possibile (le 163interfacce inutilizzate sono impossibili da verificare). 164 165 166Cosa fare 167--------- 168 169Dunque, se avete un driver per il kernel Linux che non si trova nei sorgenti 170principali del kernel, come sviluppatori, cosa dovreste fare? Rilasciare un 171file 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 173brutto lavoro. 174 175Semplicemente, fate sì che il vostro driver per il kernel venga incluso nei 176sorgenti principali (ricordatevi, stiamo parlando di driver rilasciati secondo 177una licenza compatibile con la GPL; se il vostro codice non ricade in questa 178categoria: buona fortuna, arrangiatevi, siete delle sanguisughe) 179 180Se il vostro driver è nei sorgenti del kernel e un'interfaccia cambia, il 181driver verrà corretto immediatamente dalla persona che l'ha modificata. Questo 182garantisce che sia sempre possibile compilare il driver, che funzioni, e tutto 183con un minimo sforzo da parte vostra. 184 185Avere il proprio driver nei sorgenti principali del kernel ha i seguenti 186vantaggi: 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 198Dato che Linux supporta più dispositivi di qualsiasi altro sistema operativo, 199e che girano su molti più tipi di processori di qualsiasi altro sistema 200operativo; ciò dimostra che questo modello di sviluppo qualcosa di giusto, 201dopo tutto, lo fa :) 202 203 204 205------ 206 207Dei ringraziamenti vanno a Randy Dunlap, Andrew Morton, David Brownell, 208Hanna Linder, Robert Love, e Nishanth Aravamudan per la loro revisione 209e per i loro commenti sulle prime bozze di questo articolo. 210