Ho iniziato a pensare a questo problema nel contesto dell'etichetta sulla mailing list del kernel Linux. Essendo il progetto di software libero più conosciuto e probabilmente di maggior successo e importante al mondo, il kernel Linux riceve molta stampa. E il fondatore e leader del progetto, Linus Torvalds, chiaramente non ha bisogno di presentazioni qui.
Linus attira occasionalmente polemiche con le sue fiamme sull'LKML. Queste fiamme hanno spesso, per sua stessa ammissione, a che fare con la rottura dello spazio dell'utente. Il che mi porta alla mia domanda.
Posso avere una prospettiva storica sul perché rompere lo spazio utente è una cosa così negativa? A quanto ho capito, l'interruzione dello spazio utente richiederebbe correzioni a livello di applicazione, ma è una cosa così negativa, se migliora il codice del kernel?
A quanto ho capito, la politica dichiarata di Linus è che non rompere lo spazio utente ha la meglio su tutto il resto, inclusa la qualità del codice. Perché è così importante e quali sono i pro ei contro di una tale politica?
(Ci sono chiaramente alcuni svantaggi in una tale politica, applicata in modo coerente, dal momento che Linus occasionalmente ha "disaccordi" con i suoi principali luogotenenti sull'LKML esattamente su questo argomento. Per quanto ne so, si fa sempre strada nella questione.)
Risposta accettata:
Il motivo non è storico ma pratico. Ci sono molti molti molti programmi che girano sul kernel Linux; se un'interfaccia del kernel interrompe quei programmi, tutti dovrebbero aggiornare quei programmi.
Ora è vero che la maggior parte dei programmi infatti non dipendono direttamente dalle interfacce del kernel (le chiamate di sistema), ma solo dalle interfacce della libreria standard C (i wrapper C attorno alle chiamate di sistema). Oh, ma quale libreria standard? Glibc? uClibC? Dieta? Bionico? musulmano? ecc.
Ma ci sono anche molti programmi che implementano servizi specifici del sistema operativo e dipendono dalle interfacce del kernel che non sono esposte dalla libreria standard. (Su Linux, molti di questi sono offerti tramite /proc e /sys .)
E poi ci sono i binari compilati staticamente. Se un aggiornamento del kernel rompe uno di questi, l'unica soluzione sarebbe ricompilarli. Se hai la fonte:Linux supporta anche il software proprietario.
Anche quando la fonte è disponibile, raccoglierla tutta può essere una seccatura. Soprattutto quando stai aggiornando il tuo kernel per correggere un bug con il tuo hardware. Le persone spesso aggiornano il loro kernel indipendentemente dal resto del loro sistema perché hanno bisogno del supporto hardware. Nelle parole di Linus Torvalds:
Interrompere i programmi utente semplicemente non è accettabile. (...) Sappiamo che le persone usano vecchi binari per anni e anni, e che fare una nuova versione non significa che puoi semplicemente buttarla via. Puoi fidarti di noi.
Spiega anche che uno dei motivi per renderlo una regola forte è evitare l'inferno delle dipendenze in cui non solo dovresti aggiornare un altro programma per far funzionare un kernel più recente, ma devi anche aggiornare un altro programma, un altro e un altro , perché tutto dipende da una certa versione di tutto.
È un po' ok per avere una dipendenza unidirezionale ben definita. È triste, ma inevitabile a volte. (…) Ciò che NON va bene è avere una dipendenza a due vie. Se il codice HAL dello spazio utente dipende da un nuovo kernel, va bene, anche se sospetto che gli utenti spererebbero che non sarebbe il "kernel della settimana", ma più un "kernel degli ultimi mesi".
Ma se hai una dipendenza BIDIREZIONALE, sei fregato. Ciò significa che devi eseguire l'aggiornamento in blocco e che NON È ACCETTABILE. È orribile per l'utente, ma, cosa ancora più importante, è orribile per gli sviluppatori, perché significa che non puoi dire "si è verificato un bug" e fare cose come cercare di restringere il campo con la bisezione o simili.
Nello spazio utente, quelle dipendenze reciproche vengono solitamente risolte mantenendo diverse versioni di libreria in giro; ma puoi eseguire solo un kernel, quindi deve supportare tutto ciò che le persone potrebbero voler fare con esso.
Correlati:spiegazione dell'ordine di ordinamento?Ufficialmente,
la compatibilità con le versioni precedenti per [chiamate di sistema dichiarate stabili] sarà garantita per almeno 2 anni.
In pratica però,
Ci si aspetta che la maggior parte delle interfacce (come le syscall) non cambino mai e siano sempre disponibili.
Ciò che cambia più spesso sono le interfacce che devono essere utilizzate solo da programmi relativi all'hardware, in /sys . (/proc , d'altra parte, che dall'introduzione di /sys è stato riservato a servizi non relativi all'hardware, praticamente non si interrompe mai in modi incompatibili.)
In sintesi,
l'interruzione dello spazio utente richiederebbe correzioni a livello di applicazione
e questo è negativo perché c'è un solo kernel, che le persone vogliono aggiornare indipendentemente dal resto del loro sistema, ma ci sono molte molte applicazioni là fuori con interdipendenze complesse. È più facile mantenere stabile il kernel che mantenere aggiornate migliaia di applicazioni su milioni di configurazioni diverse.