Come si confronta il kernel Linux con le architetture microkernel?

Ho letto una volta che uno dei vantaggi di un'architettura microkernel è che puoi interrompere / avviare servizi essenziali come reti e filesystem, senza bisogno di riavviare l'intero sistema. Ma considerando che il kernel Linux al giorno d'oggi (è sempre stato così?) Offre la possibilità di utilizzare i moduli per ottenere lo stesso effetto, quali sono i (rimanenti) vantaggi di un microkernel?

I microkernel richiedono meno codice per essere eseguito nella modalità più interna e più affidabile rispetto ai kernel monolitici . Questo ha molti aspetti, come:

• I micro kernel consentono di caricare e scaricare a piacimento funzionalità non fondamentali (come driver per hardware non connesso o non in uso). Ciò è principalmente realizzabile su Linux, attraverso i moduli.
• I micro kernel sono più robusti: se un componente non kernel si arresta in modo anomalo, non porterà l'intero sistema con sé. Un file system 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 micro kernel hanno una base informatica più piccola e affidabile . Quindi anche un driver di dispositivo o un file system dannoso non può assumere il controllo dell'intero sistema (ad esempio un driver di origine dubbia per il tuo ultimo dispositivo 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 utente (tranne per (parte del) driver del dispositivo video). Molti unici moderni consentono agli utenti ordinari di caricare i driver del file system tramite FUSE . Alcuni dei filtri di pacchetti di rete Linux possono essere eseguiti 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.

Un classico (se datato) letto su Linux e microkernels è il dibattito Tanenbaum – Torvalds . Venti anni dopo, si potrebbe dire che Linux si sta muovendo molto lentamente verso una struttura di microkernel (i moduli caricabili sono apparsi all'inizio, FUSE è più recente), ma c'è ancora molta strada da fare.

Un'altra cosa che è cambiata è la crescente rilevanza della virtualizzazione su desktop e computer embedded di fascia alta: per alcuni scopi, la distinzione rilevante non è tra kernel e userland ma tra hypervisor e SO guest.

Un microkernel limita il tempo minimo in cui il sistema è in modalità kernel, al contrario dello spazio utente.

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 tale processo si interrompe. Linux è robusto in questo senso, ma è ancora possibile per qualsiasi sottosistema kernel scrivere sulla memoria di qualsiasi altro sottosistema kernel, intenzionalmente o accidentalmente.

Il concetto di microkernel mette un sacco di roba che è tradizionalmente la modalità kernel, come i driver di rete e dei dispositivi, nello spazio utente. Poiché il microkernel non è realmente responsabile di molto, ciò significa anche che può essere più semplice e più 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 cattivo.

Dovresti leggere l'altro lato del problema:

Informatica ad alte prestazioni estreme o Perché i microkernel fanno schifo

Il file system appartiene al kernel

Dai un'occhiata all'architettura x86 - il kernel monolitico usa solo gli anelli 0 e 3. Uno spreco, davvero. Ma ancora una volta può essere più veloce, a causa della minore commutazione del contesto.

1. Il kernel monolitico è molto più vecchio del microkernel . È usato in Unix mentre l'idea del microkernel è apparsa alla fine degli anni '80 .

2. Esempi di sistemi operativi con kernel monolitico sono UNIX, LINUX mentre i sistemi operativi con microkernel sono QNX, L4, HURD e inizialmente Mach (non MacOS X) che è stato successivamente convertito in kernel ibrido. Anche MINIX non è un microkernel puro perché i suoi driver di dispositivo sono compilati come parte del kernel.

3. I noccioli monolitici sono più veloci dei microrganismi . Il primo microkernel Mach è più lento del 50% rispetto ai kernel monolitici. Le versioni successive come L4 sono solo il 2% o il 4% più lente del kernel monolitico .

4. I kernel monolitici sono generalmente voluminosi mentre il microkernel puro deve essere di piccole dimensioni , anche adattarsi alla cache di primo livello del processore (microkernel di prima generazione).

5. Nei kernel monolitici, i driver di dispositivo risiedono nello spazio del kernel mentre nei driver di dispositivo del microkernel risiedono nello spazio dell'utente .

6. Poiché i driver di dispositivo risiedono nello spazio del kernel, rende il kernel monolitico meno sicuro del microkernel (un errore nel driver può causare un arresto anomalo). I micro kernel sono più sicuri dei kernel monolitici, quindi vengono utilizzati in molti dispositivi militari.

7. I kernel monolitici usano segnali e socket per garantire l'IPC mentre l'approccio microkernel utilizza le code dei messaggi . Il 1 ^° gen di microkernel scarsamente applicata IPC quindi erano lento su cambiamenti di contesto.

8. Aggiungere nuove funzionalità a un sistema monolitico significa ricompilare l'intero kernel mentre è possibile aggiungere nuove funzionalità o patch senza ricompilare

Windows NT (il kernel sottostante agli attuali sistemi Windows) è iniziato con un design microkernel piuttosto vanigliato. A causa di problemi di prestazioni, sempre più codice "userland" è migrato nel "micokernel" ... oggi la sua struttura microkernel è rudimentale.

Il caso è che il kernel Linux è un ibrido di monolitico e microkernel. In una pura implementazione monolitica non ci sono moduli che si caricano in fase di esecuzione.

I termini monolithic kernele microkernelnon possono essere confrontati seriamente in quanto descrivono diversi aspetti della progettazione del kernel (struttura vs. dimensione).

Un tipico kernel monolitico era il kernel SunOS-4.x e Linux è ancora simile, poiché si configura manualmente il contenuto del kernel di base.

Il kernel Solaris (a partire dalla 2.1 sul 1992) non può più essere chiamato monolitico poiché tutti i driver vengono caricati automaticamente su richiesta e solo una piccola parte viene caricata durante l'avvio iniziale.

SunOS-4.x e Solaris (SunOS-5.x) e Linux sono tutte implementazioni a contesto singolo. Il loro intero codice viene eseguito in un unico contesto MMU.

Mac OS X si basa su Mach e funziona come un'implementazione multi-contesto con diversi processi separati da contesti MMU. In questo concetto, i driver si trovano in processi e contesti MMU separati.

Molte persone chiamano Mac OS X un "sistema microkernel", ma è possibile che il kernel di base non sia più piccolo del kernel di base di Solaris.

Così sembra che sarebbe meglio parlare di single context kernelsrispetto multi context kernels.