"Instabilità" delle interfaccia del kernel e driver (closed source)

[cdimauro]

Questa discussione nasce come "costola" di questa, in cui si parla genericamente di driver closed source.

Riporto parte di messaggi scritti che riguardano questo thread.

Originariamente inviato da cdimauro

A me interessa, perché vorrei capire meglio come funziona Linux, e le motivazioni che stanno alle base del vincolo che i driver devono essere open source.

Come dissi altre volte, finora Linux è l'unico s.o. (multipiattaforma) che conosco e che richiede espressamente questo modello: tantissimi altri (pur essendo anche multipiattaforma), non presentano limitazioni come questa.

Mi piacerebbe comprendere il perché di queste differenze.

Originariamente inviato da ilsensine

La "instabilità" delle interfacce del kernel non è fatta per mettere i bastoni tra le ruote ai driver closed source. E' un effetto collaterale.

E comunque un buon driver closed source, come quello nvidia, ne risente poco.

E' un discorso interessante, che meriterebbe un thread apposito. Aprilo pure se vuoi.

Eccoci dunque al nocciolo della questione: perché non è possibile ipotizzare di modificare il kernel in modo da esporre un'interfaccia sostanzialmente "immutabile" (nel tempo) e che venga anche incontro alle esigenze di chi sviluppa driver closed source per Linux?

[SilverXXX]

Mi iscrivo perchè mi interessa. Comunque ricordo che per un upgrde del kernel (il 2.6.7 mi pare) non è stato sufficente ricompilare l'interfaccia; i nuovi driver nvidia sono comunque usciti subito per ovviare al problema.
ps. riportato per dovere di cronaca .

[jappilas]

discorso interessante, per me parente prossimo di quello sulla "stabilità binaria" delle interfacce di livello applicativo (che laddove manchi, renda difficoltoso distribuire SW compatibile all' indietro e in avanti con linux in quanto tale, nel senso di prescidente da versione del kernel e magari addirittura distribuzione)

per i driver (moduli), ho l' impressione che il punto sia ancora più critico, almeno per quel poco di idea che mi sono fatto vagando per osnews e le pagine che da esso vengono referenziate ...

dalle FAQ di Atheos (poi forkato in Syllable): "In Linux un modulo è semplicemente una parte di kernel non ancora caricata, in atheos v'è una netta seprazione tra kernel e device driver": il che mi farebbe desumere che sotto atheos i driver verrebbero usati tramite chiamate a funzioni di libreria, mentre in linux i driver accederebbero effettivamente alle strutture dati interne al resto del codice del kernel a cui vengono connessi
ora, ponendo il caso che le strutture dati o la loro semantica di gestione debbano venire alterate da una versione all' altra del kernel per qualsivoglia motivo (da tali modifiche dipende magari l' introducibilità o meno di una funzione potenzialmente utile - ad es la kernel preemption, che in effetti non deve essere stata indolore)
in tal caso, per del codice appartenente al kernel, che su certi meccanismi e semantiche giocava, il compatibility break sarebbe praticamente logica conseguenza
cioè, se non ho capito male io...

[ilsensine]

Ok prima o poi mi spiegerai tutta la tua famelica sete di sapere su come gira il mondo linux

Ti dirò come funzionano un paio di cose, poi concluderò con un esempio che dimostra che questo:

in modo da esporre un'interfaccia sostanzialmente "immutabile" (nel tempo)

non solo è possibile (eccetto pochi corner-case), ma è addirittura stato fatto (e non si tratta di nvidia). Infine potremo scannarci fino alla morte, se vuoi, sul perché una cosa simile non entrerà mai nel kernel ufficiale


Cosa dà fastidio a un driver closed-source?
Gli aspetti importanti sono 2:
- dipendenza dai parametri di configurazione del kernel
- variazione delle interfacce nel tempo
Ci sarebbe anche la variazione ABI del gcc, ma ultimamente si sono dati una calmata (soprattutto per il codice c, ma stanno iniziando anche con il c++).

1) dipendenza dai parametri di configurazione del kernel
Un kernel può essere ottimizzato per diversi compiti; questo non causa una variazione delle interfacce "livello codice", ma una variazione a livello compilato (una struttura può avere più o meno campi, una macro essere definita in modi diversi o diventare una funzione vera e propria, ecc.). Le distribuzioni forniscono normalmente due o più kernel precompilati con ottimizzazioni differenti, per venire incontro almeno ai casi più comuni. Un driver compilato per uno di questi kernel, fa boom se lo si utilizza in un altro (ci sono delle verifiche, normalmente abilitate, per far sì che il kernel rifiuti di caricare un modulo che è compilato con parametri differenti).
Ti elenco i casi più importanti:
- kernel smp/up
Cambia il modo in cui sono definiti gli spinlock. Noop per un kernel up, qualcos'altro per un kernel smp. Oltre a variazioni di diversa natura.
- preempt/no preempt
Cambiano gli spinlock (anche nei kernel up), e qualche altra cosa.
- stack 4k/8k
Cambia la posizione delle informazioni sul task corrente, posto all'inizio dello stack. Inoltre, le funzioni che operano con lo stack 4k devono essere opportunamente "dietetiche". Il passaggio da 8k a 4k ha richiesto mesi di cleanup, e ancora ci sono corner case in cui è consigliabile 8k.
Con lo stack a 4k gli irq handler hanno una propria pagina di stack, per mitigare l'effetto della riduzione di stack. Con lo stack a 8k, prendono "in prestito" lo stack kernel space del processo che hanno interrotto.
- Tipo di processore per cui il kernel è ottimizzato
Sceglie il set di istruzioni e il tuning di ottimizzazione per il compilatore. Fin qui non c'è problema, ma possono esserci altri effetti (in particolare nelle funzioni di copia da/a memoria).
- Tipo di supporto della memoria: 1GB/4GB/64GB
A complicare le cose, ci sono in giro patch che consentono la divisione dello spazio ring3 e del ring0 in due regioni 4GB/4GB distinte (la FC2 ho scoperto che usa questa divisione). Inoltre, alcuni utenti pazzoidi (io), a volte cambiano la normale divisione 3GB/1GB in qualcos'altro (nel mio caso, mi serviva 2.5GB/1.5GB).
Le differenze si notano nelle funzioni inline di accesso ai dati dei programmi userspace, nella mappatura delle pagine highmem, nella gestione delle page table...
- CONFIG_REGPARM
Abilita il passaggio dei parametri alle funzioni per registri, invece che per stack. Incompatibilità totale.
- Supporto hotplug
Causa o meno lo scarto di intere sezioni di codice dal modulo, runtime.
- Supporto per alcuni file system virtuali (devfs, sysfs...)
Compila o rende noop inline certe funzioni.
- Alcune opzioni di diagnostica interna (debug di spinlock/slab/kobject/allocator/file system... )
Varia la dimensione di alcune strutture e la definizione di alcune funzioni inline. E' di minore impatto, in quanto è di importanza prevalentemente per gli sviluppatori; gli utenti finali disabilitano normalmente queste funzionalità per avere un kernel più veloce.
- Altre opzioni di minore importanza

Il resto alla prossima puntata, ora devo lavorare un pò

[SilverXXX]

Originariamente inviato da jappilas

... "In Linux un modulo è semplicemente una parte di kernel non ...ancora caricata, in atheos v'è una netta seprazione tra kernel e device driver": il che mi farebbe desumere che sotto atheos i driver verrebbero usati tramite chiamate a funzioni di libreria, mentre in linux i driver accederebbero effettivamente alle strutture dati interne al resto del codice del kernel a cui vengono connessi ...

Dovrebbe essere cos', dato che è un kernel monolitico. O no?

[ilsensine]

2) variazione delle interfacce nel tempo
Visto che del kernel sono disponibili tutti i sorgenti, ci sono minori vincoli nel mantenere rigide le interfacce quando si trovano soluzioni migliori. Ovviamente essendo un punto molto delicato, viene fatto solo quando effettivamente necessario/inevitabile, e con regole e modalità ben precise.

Ovviamente le "interfacce" con i programmi userspace, le syscall, device node ecc., sono molto più rigide. Linus si vanta di poter usare ancora un programma compilato ai tempi del kernel 0.9x.
La modifica delle interfacce interne non è una esclusiva di linux, è adottata anche dalla "concorrenza". In ogni nuova major release di windows il driver model può subire variazioni, fermo restando la compatibilità con i programmi utente (le applicazioni per windows 3.1 sostanzialmente girano ancora, mi risulta, e anche molte applicazioni per DOS). Semplicemente da noi capita più di frequente, cosa resa possibile dalla disponibilità dei sorgenti di tutte le parti del kernel.

Al di là di cosa motivi un cambio di interfaccia, possono esserci diverse implicazioni nel codice dei driver:
1) Nessuna: se si è fortunati, le modifiche sono ben mascherate dal cambiamento di macro, funzioni inline o altro che, quando correttamente utilizzate, rendono trasparenti modifiche anche sostanziali. Diventa un pò come "compilare il kernel con una diversa configurazione".

2) Alcune: a volte è necessario cambiare la semantica di funzionamento di alcune funzioni, che può avere o meno influenza su altre parti di codice. Ad esempio, nei kernel 2.4 ad ogni dispositivo PCI rilevato dal sistema veniva automaticamente associato l'irq corrispondente già in fase di identificazione; durante la storia del 2.6, per vari motivi, l'assegnazione dell'irq è stata posticipata alla fase di attivazione del dispositivo. Questo vuol dire che se un driver richiedeva l'irq prima di attivare il dispositivo, non poteva più funzionare; tutti quelli che facevano l'opposto, non hanno notato differenze. E' stata comunque mantenuta la possibilità di selezionare il "vecchio funzionamento", per dar tempo a chi mantiene driver esterni o closed source di effettuare i necessari ritocchi.

3) Modifiche più invasive
In alcuni casi i cambiamenti si hanno proprio nei prototipi delle funzioni, o nella sostituzione di funzioni con altre. Queste modifiche sono trattate con molta attenzione, e normalmente testate per lunghi periodi dentro un ramo parallelo (ad es. -mm).
Nei casi più semplici è proprio il gruppo che modifica l'interfaccia che si occupa di intervenire nei punti dove è necessario; nei casi più complicati, il gruppo di ogni subsystem deve occuparsi di implementare le modifiche nel proprio ramo.
Spesso vengono mantenute sia le interfacce vecchie che quelle nuove, marcando le vecchie come "deprecate" e documentando cosa occorre fare per utilizzare le nuove. Viene anche schedulato un periodo dopo il quale le vecchie interfacce verranno effettivamente rimosse, che può essere di molti mesi o un anno e più. Esempio: il povero devfs, reso obsoleto da tempo dal udev, non ci sarà più dal 2.6.13 in poi.

4) Modifiche strutturali
Sono rare, normalmente viene mantenuta per compatibilità anche la vecchia struttura per un lungo periodo. Esempio: oss->alsa (gli oss, obsoleti da tempo, saranno comunque rimossi non prima di dicembre).
Le strutture sostitutive vengono sviluppate e testate in rami paralleli, non di rado per tempi biblici (da quanti _anni_ sono disponibili i driver alsa? )
In alcune circostanze le modifche sono così profonde da non rendere possibile il mantenimento parallelo della vecchia struttura; in passato questo avveniva nel ciclo di vita dei kernel di sviluppo (2.x con x dispari); con il cambio del modello di sviluppo, potrebbe anche avvenire durante il ramo 2.6 (fermo restando il lungo test parallelo, e una adeguata e tempestiva documentazione di cosa cambierà e perché).

[ilsensine]

Originariamente inviato da ilsensine

Ti dirò come funzionano un paio di cose, poi concluderò con un esempio che dimostra che questo:

non solo è possibile (eccetto pochi corner-case), ma è addirittura stato fatto (e non si tratta di nvidia).

http://ndiswrapper.sourceforge.net/

Let's the flame begin

[ilsensine]

Originariamente inviato da SilverXXX

Mi iscrivo perchè mi interessa. Comunque ricordo che per un upgrde del kernel (il 2.6.7 mi pare) non è stato sufficente ricompilare l'interfaccia; i nuovi driver nvidia sono comunque usciti subito per ovviare al problema.

Normalmente si tratta di modifiche apportate al glue code open source del driver nvidia, che spesso sono gli stessi sviluppatori linux che si "divertono" ad aggiornare.
E' raro che nvidia debba metter mano al core closed source.

[cdimauro]

Originariamente inviato da ilsensine

Ok prima o poi mi spiegerai tutta la tua famelica sete di sapere su come gira il mondo linux

Veramente la mia famelica sete riguarda il sapere di per sé.
Linux ormai è diventato il mio strumento di lavoro, per cui se aumento il mio bagaglio di conoscenza in merito male non è...

Ti dirò come funzionano un paio di cose, poi concluderò con un esempio che dimostra che questo:

non solo è possibile (eccetto pochi corner-case), ma è addirittura stato fatto (e non si tratta di nvidia).

OK, ho visto, però non mi sembra esattamente in linea col discorso generale: è un wrapper che permette di usare i driver per Windows sviluppati per le periferiche di rete.

Non è un "driver model" per Linux.

Infine potremo scannarci fino alla morte, se vuoi, sul perché una cosa simile non entrerà mai nel kernel ufficiale

Su queste cose non c'è motivo di scannarci, però vorrei saperlo lo stesso, tenendo presente che pur sempre di un wrapper si tratta.

Cosa dà fastidio a un driver closed-source?
Gli aspetti importanti sono 2:
- dipendenza dai parametri di configurazione del kernel

Sei stato chiarissimo e ti ringrazio.

nVidia coi suoi driver riesce davvero a risolvere TUTTI i problemi legati a queste diverse configurazioni del kernel? Se è così, penso la domanda che mi sono posto all'inizio del thread ha già una risposta.

Sarebbe da vedere, comunque, a che prezzo nVidia riesce ad ottenere la compatibilità con qualunque kernel.

- variazione delle interfacce nel tempo

Su questo c'è poco da dire, perché come giustamente hai riportato capita un po' a tutti, col passare degli anni.

Ci sarebbe anche la variazione ABI del gcc, ma ultimamente si sono dati una calmata (soprattutto per il codice c, ma stanno iniziando anche con il c++).

Qui non ti seguo più: che problemi può comportare un compilatore, qual è il GCC?

[ilsensine]

Originariamente inviato da cdimauro

Veramente la mia famelica sete riguarda il sapere di per sé.
Linux ormai è diventato il mio strumento di lavoro, per cui se aumento il mio bagaglio di conoscenza in merito male non è...

Non ti abbattere, prima o poi knoppix partirà anche sul tuo computer

OK, ho visto, però non mi sembra esattamente in linea col discorso generale: è un wrapper che permette di usare i driver per Windows sviluppati per le periferiche di rete.
Non è un "driver model" per Linux.

Era solo un esempio, e ritengo molto valido, di come sia possibile realizzare una interfaccia standard e invariante per i driver in linux, per far contenti i produttori di driver closed source.

nVidia coi suoi driver riesce davvero a risolvere TUTTI i problemi legati a queste diverse configurazioni del kernel? Se è così, penso la domanda che mi sono posto all'inizio del thread ha già una risposta.

Bè a loro serviva una "interfaccia invariante", e se la sono fatti in casa. Ho idea che usino qualcosa di simile anche sotto gli altri s/o (il "core" è sostanzialmente lo stesso che usano per linux), anche se l'interfaccia per linux è la più "critica", vista la volubilità dei kernel con cui si deve interfacciare.
Hanno risolto gran parte dei loro problemi.

Qui non ti seguo più: che problemi può comportare un compilatore, qual è il GCC?

Un binario (generico) creato con una versione di gcc potrebbe non essere compatibile, in fase di link, con un binario creato con un'altra versione. In passato era piuttosto frequente, ora di meno.
Spero che con il passaggio al gcc 4 non escano fuori nuovamente problemi.
Nota che questa rogna è presente, e forse in misura maggiore per chi usa il c++, anche nei programmi userspace.

Su queste cose non c'è motivo di scannarci, però vorrei saperlo lo stesso, tenendo presente che pur sempre di un wrapper si tratta.

Noi riteniamo utile poter configurare un kernel in base alle nostre esigenze, e questo comporta inevitabilmente una modifica intrinseca nei binari che ne escono fuori. Inoltre abbiamo meno scrupoli a modificare una interfaccia, quando lo riteniamo necessario. Fin qui è chiaro.
Quindi, se ti serve una interfaccia invariante a livello binario, l'unico modo per averla è creare una specie di wrapper. Ma non lo facciamo, né abbiamo alcuna intenzione di farlo

[cdimauro]

Originariamente inviato da ilsensine

Non ti abbattere, prima o poi knoppix partirà anche sul tuo computer

Dovrei provare la versione a 64 bit: magari avrò più "fortuna"...

Era solo un esempio, e ritengo molto valido, di come sia possibile realizzare una interfaccia standard e invariante per i driver in linux, per far contenti i produttori di driver closed source.

OK. Quindi questo wrapper funziona sempre, a prescindere dal tipo di kernel, in maniera simile a quanto avviene coi driver nVidia.

Ottimo. Essendo un progetto open, chi vorrà sviluppare driver closed avrà molto del lavoro servito già su un piatto d'argento.

Un binario (generico) creato con una versione di gcc potrebbe non essere compatibile, in fase di link, con un binario creato con un'altra versione. In passato era piuttosto frequente, ora di meno.
Spero che con il passaggio al gcc 4 non escano fuori nuovamente problemi.
Nota che questa rogna è presente, e forse in misura maggiore per chi usa il c++, anche nei programmi userspace.

Ho capito. Comunque sono problemi di link/er, più che di binario vero e proprio.

Quindi, se ti serve una interfaccia invariante a livello binario, l'unico modo per averla è creare una specie di wrapper. Ma non lo facciamo, né abbiamo alcuna intenzione di farlo

Non c'è problema: l'importante è che chi sia interessato abbia la possibilità di poterlo fare...

[ilsensine]

Originariamente inviato da cdimauro

OK. Quindi questo wrapper funziona sempre, a prescindere dal tipo di kernel, in maniera simile a quanto avviene coi driver nVidia.

Ottimo. Essendo un progetto open, chi vorrà sviluppare driver closed avrà molto del lavoro servito già su un piatto d'argento.

Bè sì, anche se è limitato al caso wireless.
ndiswrapper è nato per quei produttori che ignorano completamente l'esistenza di parecchi altri s/o a questo mondo. Il motivo per cui io stesso _detesto_ simili soluzioni, lo puoi trovare riassunto qui (dove puoi vedere come ndiswrapper sia tutto sommato "inutile"):
http://www.figuiere.net/hub/blog/?20...ivers-for-wifi
Oltre a essere "inutile", ndiswrapper è anche "dannoso": per molti chip wireless ci sono progetti liberi nativi, a volte basati su reverse engineering, che necessitano dei feedback e bug report di quanti più utenti possibile. Questi feedback sono _essenziali_ per lo sviluppo di driver liberi, e ho letto sviluppatori lamentarsi dell'esistenza stessa di ndiswrapper in quanto non stimolava l'adozione di un driver libero in via di sviluppo.

Ho capito. Comunque sono problemi di link/er, più che di binario vero e proprio.

E' un dettaglio che non noti, quando un binario non funziona

[cdimauro]

Ma LOL!

Comunque quello dei driver e dei wripper mi sembra il classico problema del cane che si mangia la coda.

Se non ci sono i wrapper ci si deve accontentare dei driver disponibili se e quando ci sono.

Se ci sono i wrapper le case produttrici di periferiche tendono a non scrivere driver nativi.

Non so cos'è meglio fra le due... E' un po' come WinE / Cedega e i giochi per Linux...

[ilsensine]

Per curiosità, che ti "costringono" a fare con linux al lavoro?

[DanieleC88]

Originariamente inviato da cdimauro

E' un po' come WinE / Cedega e i giochi per Linux...

Scusami se vado un po' OT, ma ho notato che scrivi sempre WinE. Si scrive WINE, perché l'acronimo è "WINE Is Not an Emulator", e non "Windows Emulator". In effetti, tecnicamente WINE non è un'emulatore, anche se viene usato per il 99% delle volte in tale modo.

[DanieleC88]

Ooops, doppio post...

[cdimauro]

Originariamente inviato da ilsensine

Per curiosità, che ti "costringono" a fare con linux al lavoro?

Sviluppo applicazioni di vario tipo, principalmente in Python (e Apache/mod_python, quando serve): si va da programmi di interfacciamento con operatori di telefonia mobile allo sviluppo di server e client web. Uso spesso SSH, mysql, apache, e pacchetti di vario tipo per Python.

Non mi posso lamentare: ho sempre cose nuove su cui metter le mani e acquisire esperienza.

[cdimauro]

Originariamente inviato da DanieleC88

Scusami se vado un po' OT, ma ho notato che scrivi sempre WinE. Si scrive WINE, perché l'acronimo è "WINE Is Not an Emulator", e non "Windows Emulator". In effetti, tecnicamente WINE non è un'emulatore, anche se viene usato per il 99% delle volte in tale modo.

Non so che dirti, mi viene naturale così: sarà la mia passione sfrenata per gli emulatori che mi fa scrivere "WinE", evidenziando la "E" di "Emulator"...

[-ThePunisher-]

Originariamente inviato da cdimauro

Non so che dirti, mi viene naturale così: sarà la mia passione sfrenata per gli emulatori che mi fa scrivere "WinE", evidenziando la "E" di "Emulator"...

O semplicemente la tua ignoranza

A kazzaro! Ma parla come magni e tornatene da quer cesso di tu moglie!

[-ThePunisher-]

Originariamente inviato da cdimauro

Veramente la mia famelica sete riguarda il sapere di per sé.
Linux ormai è diventato il mio strumento di lavoro, per cui se aumento il mio bagaglio di conoscenza in merito male non è...

AHAHAHAHAHHAHAHHAHAH!

non sapevo che i kazzari avessero "una famelica sete" (bella frase no-sense) di sapere su certi argomenti. Piuttosto pensavo lo avessero per latre cose come la stupidità dove te regni incontrastato mi sa