Giuro che non sono riuscito a farmi venire in mente un titolo meno criptico… ma vabbè, cerco di far capire ai meno geek di cosa stiamo parlando… anche perché sono sicuro che un tema come questo debba essere dominio di tutti, e non solo di pochi che si sentono a loro agio parlando di kernel.
Da sempre una delle accuse rivolte al team di sviluppo di Linux (se mai esistesse questa entità) è quella di ostinarsi a non rilasciare un sistema per facilitare lo sviluppo di driver esterni al tree (e magari anche un po’ chiusi…). Adesso le cose potrebbero cambiare radicalmente.
La richiesta
La scelta di non rilasciare una cosa del genere è stata spesso motivata dallo stesso Linus Torvalds tirando in ballo il diritto all’evoluzione e il dovere di stravolgere ogni singola parte del kernel che possa essere migliorabile. E fin qui niente di male.
Un altro dei motivi è sempre stato invece correlato alla non-volontà di rendere più facile la scrittura di driver proprietari o chiusi per il kernel Linux. Una sorta di “tu non aiuti me, io non aiuto te” per cui non si è mai voluto venire incontro agli sviluppatori di driver proprietari che chiedono a gran voce un modo stabile per non dover riscrivere i driver chiusi ad ogni nuovo cambio di API.
La concessione
Leggo oggi su SlashDot che la risposta a questa eterna richiesta è arrivata da Linus e il team del kernel. Sì, anche dallo stesso Kroah-Hartman di cui ho scritto in passato nei post “Gli sviluppatori del kernel fanno la proposta indecente“, “Piace la “proposta indecente” degli hacker del kernel” e “Aggiornamento sulla “proposta indecente” degli hacker del kernel“. Era stato il primo ad annunciare qualcosa del genere.
La risposta ha dell’incredibile, ed è che è stato finalmente implementato un sistema per garantire tali richieste. Il problema verrà risolto creando un’interfaccia tra kernelspace e userspace, che resterà stabile. La maggior parte del codice dei driver chiusi andrà così fuori dal kernel, mentre solo una piccola parte andrà direttamente nel kernel. La comunicazione tra le due parti sarà regolata da un dispositivo virtuale (char device) e da sysfs.
I vantaggi per gli sviluppatori
Voglio chiarire che questa novità dovrebbe essere intesa come un vantaggio per tutti gli sviluppatori: la possibilità offerta è di scrivere meno codice, soprattutto nel senso di non doverlo mantenere così aggressivamente.
I vantaggi per le aziende
Questo nuovo modo di trattare con le aziende che vogliono scrivere driver per Linux ha due essenziali spunti di discussione. Da una parte una semplificazione per chi scrive driver proprietari, che quindi dovrebbe portare a codice migliore (si spera) e – se non erro – ad eliminare la necessità di ricompilare tali driver ad ogni minimo cambio di kernel. Dall’altra la ovvia reazione scettica di chi non vede di buon occhio i driver proprietari e avrebbe preferito continuare con la linea dura: “o dentro o fuori”.
Io, come credo la maggior parte di voi, sono uno splendido esempio di piccole contraddizioni e amorevoli idiosincrasie, per cui pur preferendo l’idea di avere un sistema al 100% opensource, non posso fare a meno di applaudire a questa decisione. Questo mi permetterà di avere un sistema che funziona meglio? Bene. Ostacolerà o scoraggerà anche eventuali rilasci di driver opensource? Lo vedremo.
Verso un microkernel?
Ovviamente no, ma è una delle cose che mi sono venute in mente leggendo l’annuncio. Una delle polemiche storiche, portata avanti per anni, è quella di Linux Macrokernel (o kernel monolitico) contro il concetto stesso – per Linus fallace – di Microkernel.
Magari si arriverà ad un compromesso tra Micro e Macro, diciamo un Mediokernel :D
Tengo a precisare che quanto scritto è semplicemente frutto di ricordi di letture, flame sulla LKML e articoli sparsi, potrei aver scritto qualche imperfezione e invito eventuali sviluppatori con esperienza di kernel a correggermi eventualmente :)
Chi ha detto che parlare di kernel debba essere noioso? :)
uuuuuuuuuh, magari gli scarpari alla ati decidono di rimboccarsi le maniche
Beh in effetti la cosa interessa
Vantaggi e svantaggi di vario genere. Lascio perdere quelli politici, e cerco di rimanere sul tecnico.
Una tale scelta permette di tenere più codice driver fuori dal kernel space. Questo ha due effetti, teoricamente:
1. Maggiore stabilità del kernel: se il codice fuori dal kernel space è scritto male e fa saltare via un puntatore, questo non inficia lo spazio kernel, che di per sè è self-trusted e quindi più aperto a “minacce” di driver scritti male.
2. Più lentezza. Il passaggio bidirezionale tra user e kernel space introduce necessariamente overhead.
Ora, facendo le cose come si deve, il punto 2. può essere “smussato” fino ad avere un compromesso favorevole anziché sfavorevole.
Il punto 1. è un vantaggio, quindi lasciamolo.
Fortunatamente, grazie alla pulizia di sistemi Unix in generale, da tempo su sistemi come Linux, driver come quelli delle stampanti o come (metà) di quelli video sono già in userspace da tempo, evitando così i malfuzionamenti dei sistemi Windows pre-Vista (solo con Vista hanno capito che i driver di stampanti e schede video vanno fuori dal kernel, nonostante sia scritto sui libri da molto, molto tempo).
Ma l’attuale kernel non è “micro” ? Per Linus sarebbe fallace il kernel modulare?
Andrea Zanchi
Il kernel Linux non è mai stato microkernel. È un monolitico con la possibilità di caricare estensioni a run-time, ma queste estensioni vengono caricate sempre in kernel-space.
@ Nemo
> Lascio perdere quelli politici, e cerco di rimanere sul tecnico.
Linux _e’_ politico :)
> mediokernel
di solito si dice kernel ibrido :P
finalmente – forse – il driver della scheda wireless non mi manderà più in freeze l’intero sistema
ecco li vedo gia’ flotte di driver proprietari
non portabili pieni di bug e non debuggabili
Rabbrividiamo
domanda ignorante (non sono per niente esperto di kernel…tutt’altro!):
nel post #25 della messagebox si fa riferimento al nuovo rilascio dei driver amd/ati ( http://ati.amd.com/support/drivers/linux/linux-radeon.html ).
in che contesto si inseriscono questi?
mi sembra che non rispondano certo alle promesse fatte da ati di sviluppare driver open, ma allo stesso tempo rappresentano uno sforzo della ati di rispondere alle esigenze del mondo linux di driver di qualità.
qualcuno li ha provati?
e poi dico: ma se gli sviluppatori del kernel ti dicono “ti sviluppiamo i driver NOI”, perché dovrebbero fare delle resistenze e preferire spendere risorse a svilupparli loro (le aziende produttrici di hw)?
@felipe: ci sono novità aggiornate a luglio a proposito di questa iniziativa del team kernel?
un po’ confuso…
g
@visik7
a me andrebbe già benone iniziare a vedere le “flotte di driver proprietari” (al posto della attuale “penuria di drivers”) ;)
> “tu non aiuti me, io non aiuto te”
ma non è un po’ anche lo spirito della GPL?!?
(puoi usare il mio codice solo se anche te lo ridistribuisci gratis)
@felipe:
Un microkernel ha kernel-threads separati per gestire i processi fondamentali
(IPC, a volte lo scheduler per l’user-space, VM)… Linux resterà, come lo è da sempre, un kernel
monolitico con la possibilità di caricare “al volo” moduli.
@asd: Linux è di destra o di sinistra?
@chi invoca a gran voce i driver proprietari:
Come questi, per intendersi?
http://www.ossblog.it/post/2897/samsung-driver-setuid-root
Da quel che ho capito leggendo i commenti su Osnews
– La possibilità dei driver proprietari non era lo scopo delle API, ma c’è
– Queste API sono troppo limitate per i driver che interesserebbero i più, e cioé quelli grafici :-)
(A parte dettagli tecnici stiamo parlando di roba userspace, cioé roba “lenta”)
La cosa buona è che un driver userspace non dovrebbe essere in grado di far crashare un sistema. Vero?
Linux, come detto già, non è micro-kernel ma nemmeno “realmente” kernel-monolitico … la definizione esatta è ibrido o modulare (infatti la compilazione del kernel permette l’inserimento statico e modulare di alcune parti). Wikipedia aiuta (http://it.wikipedia.org/wiki/Kernel).
Per quanto riguarda la decisione di una “apertura” verso i driver proprietari credo sia una decisione del tipo “vediamo quali aziende vogliono realmente che il proprio prodotto funzioni su linux”. Diciamo che come sempre è modo per far funzionare tutte le periferiche in attesa che la comunità possa svilupparne di propri :D
>La cosa buona è che un driver userspace non dovrebbe essere in grado di far crashare un sistema.
Dipende da quanta libertà daranno ai driver queste nuove API…
Ma di solito un driver gira in ring0 (o comunque ha accesso a tutta la memoria fisica)
e quindi __può__ far crashare il sistema…
Ma staremo a vedere… Perchè gia la definizione “driver in userspace” è un mezzo controsenso…
@n3ur0m4n: gli unici driver proprietari che uso (ipw3945 e nvidia) sono guarda un po’ gli unici che mi danno problemi senza una speranza di fix ne da parte di ubuntu ne da parte di intel.
pensa se tutto l’hardware che hai sul computer fosse fatto da driver proprietari che magari conflittando tra di loro oppure danneggiano funzioni come hibernate o suspend o peggio mandano in kernel panic a random
e nessuno fixa perche’ chi sviluppa il driver e’ un cane e non c’e’ codice su cui mettere le mani
@lestat82ta: linux non è ibrido, è monolitico.
@zakk, un driver può starsene in userspace purché un task in kernel space effettui le operazioni a livello hardware (e questa è circa l’idea), e quindi *non* ha nemmeno accesso a tutta la memoria fisica…
@visik7, almeno un driver proprietario scritto col buco del culo non ti tira giù l’intero sistema se qualcosa va storto, girando in user space. E comunque ci guadagniamo tutti, è un driver libero quello della scheda wireless che mi inchiodava tutto…
ciao!
@lestat82ta: un kernel è ibrido se riprende concetti sia microkernel che monolitici, quindi Linux NON è ibrido. “Forse” modulare. Se per modulare intendiamo la possibilità di caricare moduli decisi in fase di compilazione. Ma in genere anche il termine modulare sta ad indicare altro.
visik7 ha scritto:
|pensa se tutto l’hardware che hai sul computer fosse fatto da driver |proprietari che magari conflittando tra di loro oppure danneggiano funzioni
|come hibernate o suspend o peggio mandano in kernel panic a random
|e nessuno fixa perche’ chi sviluppa il driver e’ un cane e non c’e’ codice su cui |mettere le mani
io aggiungerei e nessuno fixa perchè tanto è uscito il modello nuovo e lo devono pur vendere…quindi con la promessa “il nuovo funziona meglio” ci invogliano a fare aggiornamenti hw totalmente non necessari.. basterebbe sistemare il driver!! e in ogni caso anche se non ci fosse malafede è normale che un azienda si concentra sulla scrittura di driver per hw nuovo abbandonando per forza di cose i vecchi modelli che finiranno per essere incompatibili prima o poi, con le nuovo versioni degli altri software con i quali lavorano tipo un driver video lavora con kernel xorg librerie etc etc etc….riflettete
quoto lestat82ta dove dice “vediamo quali aziende”
e secondo me sta li il punto di queste api, proprio vedere a quali produttori interessa linux dandogli qualcosa di meno incasinato da gestire. anche se, imho, se gli interessava linux, potevano benissimo fare i driver prima e senza ne api ne calabroni.
poi comunque va bene per farci un driver per una periferica che non richiede elevate prestazioni da parte del so… un driver di una scheda video in questo modo non ce lo vedo granchè, quindi ati non è da prendere nemmeno in considerazione, e se facessero con questa soluzione dei driver finalmente xgl, sono proprio dei mascalzoni :D
@visik: benchè abbia lo stesso problema di NoWhereMan, ti faccio presente che i driver ralink non sono proprietari…Anzi… sono liberissimi… http://rt2x00.serialmonkey.com/wiki/index.php?title=Main_Page
@NoWhereMan:
Le possibilità allora sono due:
1) Con questa nuova interfaccia il driver dirà al kernel “scrivimi questa cosa qua in memoria all’indirizzo X”, il kernel eseguirà contento e allora sarà come avere accesso diretto alla memoria.
2) Il kernel farà dei controlli sulla memoria che il driver vuole leggere/scrivere… In tal caso i driver avranno un rallentamento molto sensibile, e la soluzione non sarà accettabile, ad esempio, per driver video o per audio appena più avanzato della riproduzione stereo.
@italyanker mi sfugge dove vuoi andare a parare
Pingback:Top Posts « WordPress.com
Hai dimenticato di riportare che quella patch era già conosciuta dal “finto” ( IN YOUR HUMBLE OPINION ) team di sviluppo da un anno (e che forse c’era qualcuno che la usa :) )
Coooooooooomunque … la questione dei driver open e non open non c’entra ; e nemmeno la possibilità per le aziende di sviluppare più agevolmente o meno driver per il pinguino ; non si tratta di un ABI kernel space stabile ma di un’ABI in user space ;)
IMHO , l’ultimo punto è paradossalmente ( almeno dal tuo punto di vista ; lo scarti con un “ovviamente no ” ) il più plausibile :
– esiste già da tempo F.U.S.E.
– API for Userspace Drivers
– oltre a KVM sono stati introdotti in mainline 2 altri sistemi di virtualizzazione : XEN e Iguest . Chi capisce di sistemi sa che un sistema di virtualizzazione introduce un ulteriore strato di astrazione sulle risorse fisiche poichè il sistema (hardware) deve essere condiviso non fra più processi o thread, ma fra più ambienti operativi. Agli informatici di vecchia data (ammesso che ce ne siano) chiedo se VMS ricorda loro qualcosa ;)
Anche se il risultato di questa evoluzione non sarà un microkernel puro, ci si avvicinerà di molto.
Una cosa che nessuno ha ancora osservato, è che un microkernel consente di aumentare la portabilità su più famiglie di CPUs e/o più architetture : basta aggiungerci il supporto in Userspace. Al limite potrebbe sparire il concetto di formato binario specifico della CPU : gli eseguibili potrebbero adottare un formato binario universale la cui esecuzione sarà effettuata dal supporto alla specifica CPU presente negli userspace-drivers.
Questa cosa mi ricorda un altro sistema ;)
E’ un passo evolutivo che anche linux “dovrà” seguire anche perchè il nuovo hardware lo permetterà in maniera più agevole e a costi accessibili.
@visik7: esattamente dove “vado a parare” io.
Bah, nutro una gran stima nel kernel linux proprio per la scelta e la rigidità del mettere tutti i driver in kernel space, non voglio ritrovarmi con un microkernel o con approcci diversi, linux E’ così, i driver DEVONO stare in kernel space e NON SI DISCUTE.
Se proprio vogliono metterci dei driver in userspace, che gli diano un nome diverso.
Giusto, i microkernel sono il MALE.
ma LOL! :D
E voto anche io per il nome diverso. Qualcosa ti “Sbragazzeghl”. Mi manca lo Sbragazzeghl per la uèbcam. Suona già bene.
io trovo utile il fatto se ho capito giusto, che ho un driver che va sempre bene per qualsiasi kernel piazzo, senza a starmelo ricompilare tutte le sacrosante volte, oppure beccare periferiche che solo magicamente ubuntu comunity è riuscita a fare un “restricted -modules” e che manco urlando contro gesu, dio ed il papa, non riesco a trovare un driver compilabile, o funzionale per tale periferica.
in questo caso via compilo una volta e non me la sto a menare a lungo.
beh, certo un medium-kernel avrebbe sicuramente una gestione del prefetch diciamo…mistica!
Lol! Non picchiatemi! :)