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? :)