I microkernel richiedono meno codice per essere eseguiti nella modalità più interna e affidabile rispetto ai kernel monolitici. Questo ha molti aspetti, come:
- I microkernel consentono di caricare e scaricare a piacere funzionalità non fondamentali (come driver per hardware non connesso o non in uso). Questo è per lo più realizzabile su Linux, attraverso i moduli.
- I microkernel sono più robusti:se un componente non-kernel va in crash, non porterà con sé l'intero sistema. Un filesystem difettoso o un driver di dispositivo può causare l'arresto anomalo di un sistema Linux. Linux non ha alcun modo per mitigare questi problemi oltre alle pratiche di codifica e ai test.
- I microkernel hanno una base di calcolo attendibile più piccola. Quindi anche un driver di dispositivo o un filesystem dannoso non può assumere il controllo dell'intero sistema (ad esempio un driver di dubbia origine per il tuo ultimo gadget USB non sarebbe in grado di leggere il tuo disco rigido).
- Una conseguenza del punto precedente è che gli utenti ordinari possono caricare i propri componenti che sarebbero componenti del kernel in un kernel monolitico.
Le GUI Unix sono fornite tramite X window, che è il codice userland (ad eccezione di (parte del) driver del dispositivo video). Molte unice moderne consentono agli utenti ordinari di caricare i driver del filesystem tramite FUSE. Parte del filtraggio dei pacchetti di rete di Linux può essere eseguito in userland. Tuttavia, i driver di dispositivo, gli scheduler, i gestori di memoria e la maggior parte dei protocolli di rete sono ancora solo kernel.
Una lettura classica (anche se datata) su Linux e i microkernel è il dibattito Tanenbaum-Torvalds. Vent'anni dopo, si potrebbe dire che Linux si sta muovendo molto molto lentamente verso una struttura a microkernel (i moduli caricabili sono apparsi presto, FUSE è più recente), ma c'è ancora molta strada da fare.
Un'altra cosa che è cambiata è l'accresciuta rilevanza della virtualizzazione su desktop e computer embedded di fascia alta:per alcuni scopi, la distinzione rilevante non è tra il kernel e l'area utente, ma tra l'hypervisor e i sistemi operativi guest.
Un microkernel limita il tempo in cui il sistema è in modalità kernel, al contrario dello spazio utente, al minimo assoluto possibile.
Se si verifica un arresto anomalo in modalità kernel, l'intero kernel si arresta e ciò significa che l'intero sistema si arresta. Se si verifica un arresto anomalo in modalità utente, solo quel processo si interrompe. Linux è robusto in questo senso, ma è ancora possibile che qualsiasi sottosistema del kernel scriva sulla memoria di qualsiasi altro sottosistema del kernel, intenzionalmente o accidentalmente.
Il concetto di microkernel mette molte cose che sono tradizionalmente in modalità kernel, come il networking e i driver di dispositivo, nello spazio utente. Poiché il microkernel non è realmente responsabile di molto, ciò significa anche che può essere più semplice e affidabile. Pensa al modo in cui il protocollo IP, essendo semplice e stupido, porta davvero a reti robuste spingendo la complessità ai margini e lasciando il nucleo snello e meschino.
Dovresti leggere l'altro lato della questione:
Extreme High Performance Computing o Perché i microkernel fanno schifo
Il file system appartiene al kernel