Vai a leggere The Linux Kernel Driver Interface.
Questo è stato scritto per cercare di spiegare perché Linux non ha un'interfaccia del kernel binaria, né ha un'interfaccia del kernel stabile. Ti preghiamo di comprendere che questo articolo descrive le interfacce _in kernel_, non il kernel per le interfacce userspace. Il kernel nell'interfaccia userspace è quello che usano i programmi applicativi, l'interfaccia syscall. Quell'interfaccia è molto stabile nel tempo e non si romperà. Ho vecchi programmi che sono stati costruiti su un kernel pre 0.9something che funziona ancora bene sull'ultima versione del kernel 2.6. Questa interfaccia è quella che gli utenti e i programmatori di applicazioni possono contare per essere stabili.
Esso riflette la visione di una gran parte di sviluppatori del kernel Linux: la libertà di cambiare in-kernel dettagli di implementazione e le API in qualsiasi momento, permette loro di sviluppare molto più veloce e migliore.
Senza la promessa di mantenere le interfacce in-kernel identiche da una versione all'altra, non c'è modo per un modulo del kernel binario come VMWare di funzionare in modo affidabile su più kernel.
Ad esempio, se alcune strutture cambiano su una nuova versione del kernel (per prestazioni migliori o più funzioni o qualsiasi altra ragione), un modulo VMWare binario può causare danni catastrofici utilizzando il layout della vecchia struttura. Compilare nuovamente il modulo dal sorgente acquisirà il nuovo layout della struttura e quindi avrà una migliore possibilità di lavorare, anche se non ancora al 100%, nel caso in cui i campi siano stati rimossi o rinominati o forniti a scopi diversi.
Se una funzione modifica la sua lista di argomenti, o viene rinominata o altrimenti resa non più disponibile, nemmeno la ricompilazione dallo stesso codice sorgente funzionerà. Il modulo dovrà adattarsi al nuovo kernel. Dal momento che tutti (dovrebbero) hanno origine e (possono trovare qualcuno che) è in grado di modificarlo per adattarsi."Spingere il lavoro verso i nodi finali" è un'idea comune sia nel networking che nel software libero: poiché le risorse [ai margini]/[degli sviluppatori esterni al kernel di Linux] sono maggiori delle risorse limitate [della backbone]/[degli sviluppatori Linux], il compromesso per far sì che il primo faccia più del lavoro sia accettato.
D'altra parte, Microsoft ha preso la decisione che devono preservare il più possibile la compatibilità dei driver binari - non hanno scelta, dato che stanno giocando in un mondo proprietario. In un certo senso, ciò rende molto più facile per gli sviluppatori esterni che non devono più affrontare un obiettivo in movimento e per gli utenti finali che non devono mai modificare nulla. Al ribasso, questo costringe Microsoft a mantenere la retrocompatibilità, che è (nel migliore dei casi) dispendioso in termini di tempo per gli sviluppatori di Microsoft e (nel peggiore dei casi) è inefficiente, causa bug e impedisce il progresso in avanti.