Perché l'API del modulo Linux non è compatibile con le versioni precedenti?
Perché l'API del modulo Linux non è compatibile con le versioni precedenti? Sono frustrato nel trovare driver aggiornati dopo aver aggiornato il kernel Linux.
Ho un adattatore wireless che necessita di un driver proprietario, ma il produttore ha interrotto questo dispositivo circa 7 anni fa. Poiché il codice è molto vecchio ed è stato scritto per Linux 2.6.0.0, non è compilabile con i kernel Linux più recenti. Ho usato molte distribuzioni Linux ma lo stesso problema è ovunque. Sebbene esista un driver open source distribuito con il kernel Linux, non funziona. Alcune persone stanno cercando di modificare il vecchio codice proprietario per renderlo compatibile con gli ultimi kernel Linux, ma quando viene rilasciato un nuovo kernel Linux, ci vogliono mesi per rendere il codice compatibile con quello. Entro quel tempo, viene rilasciata un'altra nuova versione. Per questo motivo, non posso eseguire l'aggiornamento a un nuovo kernel Linux; a volte non riesco nemmeno ad aggiornare la mia distribuzione.
Risposte
Greg Kroah-Hartman ha scritto su questo argomento qui:https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html
Oltre ad alcuni dettagli tecnici riguardanti la compilazione del codice C, estrae un paio di problemi di ingegneria del software di base che determinano la loro decisione.
Linux Kernel è sempre un work in progress. Questo accade per molte ragioni:
- Arrivano nuove esigenze. Le persone vogliono che il loro software faccia di più, ecco perché la maggior parte di noi esegue l'aggiornamento, vogliamo le funzionalità più recenti e migliori. Questi possono richiedere una rielaborazione del software esistente.
- Vengono rilevati bug che devono essere corretti, a volte i bug riguardano il design stesso e non possono essere risolti senza una significativa rielaborazione
- Nuove idee e modi di dire nascono nel mondo del software e le persone trovano modi molto più semplici/eleganti/efficienti per fare le cose.
Questo è vero per la maggior parte dei software , e qualsiasi software che non viene mantenuto morirà di una morte lenta e dolorosa . Quello che stai chiedendo è perché quel vecchio codice non mantenuto funziona ancora?
Perché le vecchie interfacce non vengono mantenute?
Per garantire la compatibilità con le versioni precedenti sarebbe necessario mantenere le vecchie interfacce (spesso "rotte" e non sicure). Ovviamente è teoricamente possibile farlo, tranne per il fatto che comporta un costo significativo .
Greg Kroah-Hartman scrive
Se Linux avesse dovuto garantire di preservare un'interfaccia sorgente stabile, sarebbe stata creata una nuova interfaccia e quella vecchia e rotta avrebbe dovuto essere mantenuta nel tempo, portando a lavoro extra per gli [sviluppatori]. Dal momento che tutti gli [sviluppatori] Linux svolgono il proprio lavoro nel proprio tempo libero, non è possibile chiedere ai programmatori di svolgere lavoro extra senza alcun guadagno, gratuitamente.
Anche se Linux è open source, c'è ancora solo un tempo limitato per gli sviluppatori per mantenerlo. Quindi la manodopera può ancora essere discussa in termini di "costo". Gli sviluppatori devono scegliere come trascorrere il loro tempo:
- Dedica molto tempo alla manutenzione di interfacce vecchie/non funzionanti/lente/non sicure. Questo a volte può essere il doppio o il triplo del tempo impiegato per scrivere l'interfaccia nella prima istanza.
- Butta via le vecchie interfacce e aspettati che altri manutentori di software [facciano il loro lavoro e] mantengano il proprio software.
A conti fatti, le interfacce di binning sono davvero convenienti (per gli sviluppatori del kernel) . Se vuoi sapere perché gli sviluppatori non passano mesi e anni della loro vita a salvarti dal pagare $ 10 per un nuovo adattatore wifi ... questo è il motivo. Ricorda che è conveniente in termini di tempo e costi per gli sviluppatori del kernel, non necessariamente conveniente per te o per i produttori.
Anche se ho contribuito con alcune patch (molto minori) al kernel di Linux, non mi considero uno sviluppatore del kernel. Tuttavia, ecco quello che so:
Un driver scritto per la versione del kernel 2.6.0.0 precede l'eliminazione del Big Kernel Lock (BKL) avvenuta nella versione del kernel 2.6.39.
Il BKL è stato creato quando Linux era ancora un sistema operativo a processore singolo (single-core, single-thread). Non appena è stato aggiunto il supporto SMP, gli sviluppatori hanno riconosciuto che il BKL sarebbe diventato un grosso collo di bottiglia a un certo punto, ma finché c'erano solo pochi core/thread nel sistema in totale, era in qualche modo tollerabile. Ma all'inizio è diventato un vero problema per le persone che usano Linux nei supercomputer, e così è iniziato il lavoro per sostituire tutto ciò che necessitava del BKL con meccanismi di blocco più capillari o, quando possibile, con metodi senza blocco.
Sui computer moderni, che possono avere un numero di core a due cifre su desktop normali e laptop ad alta potenza, per non parlare dei server, anche un'API del modulo kernel compatibile con le versioni precedenti 2.6.0 dovrebbe implementare BKL.
Se un modulo legacy dice "Voglio prendere il BKL", il resto del kernel non ha idea di cosa il modulo stia pianificando di fare con esso, e quindi il meccanismo di compatibilità con le versioni precedenti dovrebbe accettare tutti i blocchi che hanno sostituito il BKL solo per coprire tutte le possibilità. Sarebbe un grande successo in termini di prestazioni. E i nuovi metodi senza blocco dovrebbero anche verificare la presenza del blocco legacy, che in primo luogo vanifica il punto di essere senza blocco. Quindi l'esistenza stessa del meccanismo di compatibilità con le versioni precedenti degraderebbe le prestazioni del sistema, anche se nessun modulo legacy fosse effettivamente caricato.
Più di recente, le patch di sicurezza di Spectre/Meltdown hanno apportato grandi cambiamenti a ciò che deve accadere quando si supera il confine tra kernel e spazio utente. Qualsiasi modulo compilato prima dell'implementazione delle correzioni Spectre/Meltdown può essere inaffidabile con i kernel post-Specre/Meltdown.
Solo due settimane fa stavo risolvendo i problemi di un vecchio server che necessitava di un ciclo di spegnimento manuale quando gli aggiornamenti di sicurezza venivano applicati dall'automazione. Questo era già successo diverse volte ed era riproducibile. Ho scoperto che aveva una versione molto vecchia del megasrdriver di archiviazione proprietario precedente alle patch Spectre/Meltdown, che non era inclusa negli aggiornamenti automatici. Dopo aver aggiornato il driver alla versione corrente, il problema è scomparso. A proposito, questo era su un semplice sistema RHEL 6.10.
Ho anche visto server bloccarsi durante il caricamento di driver proprietari di monitoraggio hardware pre-Spectre/Meltdown con un kernel post-Spectre/Meltdown. Sulla base di questa esperienza, sono pienamente convinto che le correzioni di Spectre/Meltdown debbano essere trattate come un evento spartiacque: il kernel ei moduli devono essere tutti versioni prima delle correzioni o tutte versioni successive alle correzioni; mescolare e abbinare porterà solo al dolore e alle chiamate di sveglia di mezzanotte per l'amministratore di sistema di guardia.
E poiché Spectre era un problema a livello di progettazione della CPU , è "un dono che continua a dare": alcune persone troveranno nuovi modi per sfruttare i punti deboli, e quindi gli sviluppatori del kernel dovranno trovare modi per bloccare gli exploit.
Questi sono solo due dei grandi problemi che un modulo API del kernel legacy compatibile con 2.6.0.0 dovrebbe risolvere. Sono sicuro che ce ne sono molti altri.
E poi c'è il lato più filosofico. Pensaci: cosa rende possibile Linux?
Gran parte di esso sono le specifiche hardware aperte . Se le specifiche hardware sono aperte, chiunque può partecipare. Poiché il codice sorgente del sistema operativo è aperto, chiunque può contribuire, a beneficio di tutti. E non puoi mantenere le specifiche di programmazione hardware come segreto commerciale se il tuo codice driver è open-source.
Gli sviluppatori del kernel Linux tendono a credere nel modello open source. Questo è il motivo per cui hanno fatto le loro scelte di progettazione e sviluppo in modo che il modo preferito per la partecipazione del produttore dell'hardware sia rendere open-source il driver, farlo unire alla distribuzione principale dei sorgenti del kernel e poi (e solo allora ) trarre vantaggio dall'intera comunità di sviluppatori del kernel nel mantenerlo.
Ciò fornisce alcuni incentivi ai progettisti e ai produttori di hardware per renderlo possibile. Se hai qualcosa che desideri mantenere segreto, fai lo sforzo di incapsularlo in un ASIC, o forse in un firmware firmato, se necessario. (In quest'ultimo caso, concedi ad altri l'autorizzazione a ridistribuire il pacchetto firmware.)
Ma poiché il kernel è open source, gli sviluppatori del kernel non possono esattamente impedire ad altri di mantenere i driver proprietari separatamente. Ma non hanno nemmeno alcun incentivo a prendersi cura di loro.
In effetti, la seccatura extra causata dai driver binari proprietari nel debug del kernel è un incentivo per lo sviluppatore del kernel a non preoccuparsi dello sviluppo dei driver proprietari: "Rendono il mio lavoro più difficile, perché dovrei fare qualcosa in particolare per rendere il loro più facile?"
Quindi, gli sviluppatori del kernel generalmente fanno ciò che è più vantaggioso per loro come gruppo/comunità. Se ciò include alcune modifiche all'API del modulo, così sia. I driver di terze parti non entrano nemmeno nell'equazione.