Un Kernel tradizionale è solitamente monolitico.
Ciò significa che contiene lo scheduler, la gestione della memoria virtuale, i gestori di file system, i driver
necessari per il controllo di tutte le periferiche collegate.
Questo tipo di Kernel è decisamente più complesso
da progettare,
da manutenere,
da aggiornare,
ma è anche
più veloce,
più efficiente.
La sua evoluzione è costituita dai Kernel "modulari" (Onion Skin), che pur mantenendo una loro unica
organicità, tengono separati al loro interno i servizi di scheduling, della gestione della memoria virtuale e del
file system.
Il micro Kernel invece porta avanti una filosofia completamente diversa, privilegiando l’idea che più è
leggero e minimale il Kernel che guarda alla macchina fisica e più portabile sarà il sistema operativo e
minore il costo della manutenzione e con aggiornamenti meno invasivi.
La filosofia del micro Kernel ebbe il suo apice negli anni ’90, e vide in prima fila Tanenbaum, un docente
universitario olandese di Amsterdam.
Tanenbaum e Torvalds hanno lavorato entrambi sulla base della impostazione del sistema Unix, ma con
finalità ed esiti diversi. Il primo ha creato Minix,, un sistema operativo a micro Kernel gratuito, scritto a scopo
didattico, che permetteva agli studenti universitari del professore di studiare un Kernel simile a Unix.
In Minix la teoria del micro Kernel è fedelmente implementata e la gestione della memoria e il file system,
ed altro ancora, sono moduli di sistema operativo che vengono eseguiti addirittura nello spazio utente e non
nello spazio Kernel.
Ciò significa che Tanenbaum ha veramente minimizzato il micro Kernel rendendolo estremamente
leggero, affidabile, con la possibilità di svolgere su di esso un’efficacissima e semplice manutenzione. Non
solo: un micro Kernel si avvia in pochi secondi con hardware meno performante di altri sistemi monolitici più
pesanti e complessi che necessitano di molto più tempo per essere caricati.
La sua diffusione è stata limitata, senz’altro, perché ogni modifica o miglioria doveva, per la licenza
contrattuale pensata per la sua diffusione, essere sottoposta all’approvazione di Tanenbaum.
Torvalds invece non ha scritto un micro Kernel, bensì un Kernel monolitico ispirato a Unix e,
probabilmente, a Minix.
La licenza era però totalmente libera e ciò ha scatenato energie infinitamente maggiori attorno al suo
progetto.
Ricapitolando possiamo concludere che i processori possono operare in due modalità:
modo Utente
modo Kernel
Nel modo Utente il processore si trova ad operare in un mondo virtuale dove le risorse non sono più
quelle fisiche vere, ma quelle create dal Kernel per l’Utente. Non si accorge degli altri programmi concorrenti
e vede risorse maggiori di quelle reali (ad esempio la memoria centrale).
Nel modo Kernel il processore vede ed esegue procedure nel mondo vero della macchina fisica.
Creare quindi dei Kernel monolitici significa scrivere gran parte del codice del sistema operativo che verrà
eseguito in modo Kernel.
Creare dei micro Kernel significa invece ridurre al minimo il codice del sistema operativo che verrà
eseguito in modo Kernel e spostare verso il modo Utente buona parte del restante sistema da realizzare.
Come esempio possiamo immaginare il codice che gestisce i files: il file system.
Esso è composto da varie funzionalità:
quelle legate al dispositivo hardware e che consentono semplicemente di leggere e scrivere sul
disco,
quelle che trattano l’organizzazione dei dati sul disco e quindi di dove possono essere rintracciate
o archiviate le informazioni,
quelle che gestiscono i dati e i files che devono essere conservati nel disco.
Nel Kernel Linux si ritrovano tutte le funzionalità sopra indicate.
Linux quindi si fa carico di gestire con il Kernel sia la parte di interazione elettronica con il disco, che la
sua organizzazione fisica e logica.
In Linux troviamo:
driver del dispositivo fisico
driver (modulo) del formato del filesystem (ext2, ext3, fat, etc.)
livello astratto del filesystem, uguale per ogni formato
Nel caso di un micro Kernel invece vi troveremmo solo il primo driver mentre le altre due parti della
gestione del file system sarebbero affidate a programmi da svolgersi nello spazio utente.
Ciò permetterebbe di “personalizzare” una parte del funzionamento tipico di un Sistema Operativo per
classi di utenti poiché il vero e proprio Kernel del Sistema sarebbe ridotto al minimo.
Questo approfondimento si conclude con altre due considerazioni.
Nonostante i vantaggi potenziali dell’architettura a micro Kernel (gestione più flessibile del sistema e
manutenzione ridotta), questa è rimasta disattesa nelle soluzioni commerciali.
Infatti Linux è monolitico e pure NT, il vero e proprio nuovo sistema di Microsoft che ha soppiantato il
DOS, partito con l’intento di perseguire la linea del micro Kernel, è di fatto un monolitico perché tutti i moduli
che stanno sopra il micro Kernel di NT, girando in modalità Kernel, di fatto, sono parte integrante del Kernel
stesso.
Nei due modelli a confronto quello arancione è l’insieme dei processi che verrà eseguito in modalità
Kernel e quindi non in modalità utente. Come si vede a destra molte funzioni del Kernel monolitico sono
poste a livello utente sebbene siano parte integrante del sistema operativo.
Applicazioni utente
1
IPC , File System
Schedulatore, Memoria Virtuale
Device Drivers, Dispatcher
1
2
Applicazioni
Utente
File
System
Device
Drivers
Unix
Server
Basic IPC, Schedulatore, Memoria Virtuale
Hardware
Hardware
KERNEL MONOLITICO
Micro KERNEL
Inter Process Communication (Comunicazione tra processi) è il modulo che permette la comunicazione
e lo scambio di dati tra processi.
2
Modulo del Sistema Operativo che effettua realizza effettivamente il passaggio del Processore da un
processo ad un altro su segnalazione dello schedulatore. Per questo motivo il dispatcher deve essere il più
rapido possibile.
