domenica, 1. gennaio 2012, 17:18
Guida per principianti a GNU/Linux: kernel monolitici e microkernel
Abbiamo visto che i processori moderni operano in due modi distinti: il modo kernel e il modo utente. Nel modo utente il processore crea una “realtà virtuale” in cui i programmi hanno l’illusione di essere gli unici a venire eseguiti (mentre invece sono in esecuzione insieme a decine di altri programmi) e hanno a disposizione uno spazio di memoria molto grande, più grande della memoria RAM realmente disponibile. Viceversa nel modo kernel (usato, appunto, dal kernel del sistema operativo in uso) queste “bugie” non ci sono perché chiaramente il kernel del sistema operativo deve conoscere la “verità”.
Ora, gli sviluppatori di sistemi operativi hanno due strade: usare massicciamente il modo kernel, oppure no. In altre parole, creare dei kernel che contengano molte funzioni, oppure dei kernel molto semplici che ne contengano poche: le funzioni in più verranno realizzate da programmi esterni al kernel.
Il primo approccio è quello dei kernel monolitici (ovvero: composti da un unico “pezzo”) il secondo è quello dei microkernel.
Vediamo di entrare più nel dettaglio, in modo da essere meno vaghi.
Prendiamo una funzione specifica tipica del kernel del sistema operativo, ovvero la gestione del filesystem. Di norma questa gestione è divisa in tre parti: una prima parte legata più strettamente all’hardware (scrivere e leggere sul disco), una seconda parte invece più astratta, ovvero l’organizzazione dei dati sul disco, una terza parte ancora più astratta che riguarda la rappresentazione dei file e delle directory, rappresentazione che è poi ciò che i programmi e gli utenti “vedono”.
Quello che distingue un formato di filesystem da un altro (ad esempio ntfs da etx3) è la seconda parte.
Prendiamo l’approccio del kernel Linux: il kernel gestisce sia la lettura/scrittura sul disco, attraverso il driver per l’hard disk, sia l’organizzazione dei dati sul disco stesso, sia l’organizzazione in file e directory. Nel kernel queste funzioni sono ben individuabili:
1. driver del dispositivo fisico
2. driver (modulo) del formato del filesystem (ext2, ext3, fat, ecc.)
3. livello astratto del filesystem, uguale per ogni formato
Ora, potremmo invece decidere che il kernel gestisca solo l’hardware (livello 1) e non gli altri due livelli. In questo caso il nostro kernel sarà più piccolo, ma avremo bisogno di programmi in modo utente che svolgano il ruolo del secondo e terzo livello. O potremmo decidere che solo il terzo vada tolto dal kernel, o solo il secondo. O persino tutti e tre.
Quale che sia la nostra scelta, più funzioni togliamo dal kernel, più ci avvicineremo all’architettura a microkernel, in cui appunto esiste un kernel minimale (micro) che svolge poche funzioni e poi tanti programmi in modo utente che implementano le funzioni di tipo più astratto.
E’ solo per cultura personale, visto che tante volte si legge che Linux è un kernel monolitico e non si sa bene che vuol dire. Adesso lo sapete.
Concludendo il discorso, ci sono buone ragioni per l’uno o l’altro modello. Nei fatti, i kernel monolitici hanno avuto maggiore successo, perché più semplici da realizzare e mantenere. Viceversa le architetture a microkernel permettono una gestione più flessibile: ad esempio potremmo decidere di montare un certo hard disk solo per un utente invece che per tutti, visto che il “montaggio” diventa un’operazione a livello utente e non più a livello di kernel.
Di contro però i microkernel hanno spesso grossi problemi di sincronizzazione tra le varie componenti, che ne rallentano sviluppo e mantenimento. Questo è uno dei motivi che ha rallentato lo sviluppo del kernel HURD, il kernel creato dal progetto GNU e che ormai langue da anni tra i progetti bellissimi mai finiti.
Esiste infine un terzo approccio, quello usato da Windows, da NT in poi: il kernel ibrido. In sostanza è come l’architettura a microkernel (cioè con un nucleo centrale e tanti “pezzettini” che girano sopra questo nucleo) solo che questi “pezzettini” funzionano anch’essi in modalità kernel e non in modalità utente, nei fatti annullando i vantaggi che una “vera” architettura a microkernel potrebbe portare. Da anni ci si interroga sul perché e finora la risposta più plausibile mi pare l’abbia data Linus Torvalds: la Microsoft doveva pagare il pedaggio alla teoria dominante all’inizio degli anni ’90, ovvero che i kernel monolitici fossero obsoleti. Solo che non erano tanto stupidi da impantanarsi in un vero e complicatissimo microkernel.
Il risultato è che, paradossalmente, il kernel di Windows contiene molte funzioni che invece in GNU/Linux sono esterne, come ad esempio la gestione della grafica (che su GNU/Linux è affidata a Xorg, un programma che gira in modo utente). In altre parole, il “finto” microkernel di Windows è in un certo senso più “monolitico” del kernel Linux.
Crescia