Autore: Albe
Lo studio dei sistemi operativi, come di quasi tutte le branche dell’informatica, e’ in continua evoluzione: cerca di rispondere alle nuove richieste applicative e di sfruttare i miglioramenti dell’hardware; prova ad adattarsi alle ultime frontiere architetturali (per esempio, calcolo distribuito e parallelo) mantenendo sempre le funzioni per cui e’ nato (fornire determinate astrazioni alle applicazioni).
Spesso, in questo campo, sono le universita’ a proporre nuove idee. Alcune di esse muoiono negli stessi dipartimenti dove sono state concepite; altre invece, piu’ fortunate o semplicemente piu’ applicabili, riescono a farsi strada nel mondo commerciale e possono diventare dei veri e propri standard di
riferimento per intere generazioni di sistemi.
A questa seconda categoria appartiene anche l’idea di ridurre, per quanto possibile, il kernel di un sistema operativo (di farlo diventare, quindi, un microkernel), implementando molte astrazioni a livello utente invece che nel nucleo del sistema. Il concetto di microkernel, dagli anni ’80 ad oggi, e’ stato
apprezzato e criticato, lodato ed attaccato; si e’ imposto — lentamente — come modello di riferimento, dapprima puramente teorico, e poi anche pratico (oggi, diversi sistemi operativi moderni — sia commerciali che accademici — ne fanno uso).
In questo documento cerchero’ di spiegare che cosa e’ un microkernel, mostrandone le caratteristiche principali (anche attraverso alcuni esempi), e i vantaggi e gli svantaggi rispetto ad un’architettura piu’ tradizionale.
Cos’`e un microkernel?
Tutti i sistemi operativi, tranne rare eccezioni, comprendono un kernel: un nucleo, appunto, che gira in modalita’ privilegiata, ed amministra le risorse della macchina semplificandole (“astraendole”) per le applicazioni a livello utente.
Nei sistemi tradizionali (per esempio UNIX) le astrazioni fornite dal kernel sono parecchie: device fisici, file, processi, memoria, canali di comunicazione, e via dicendo. Un kernel di questo genere e’ chiamato monolitico.
Nei sistemi basati su microkernel, invece, il nucleo offre poche astrazioni: giusto quelle che, per poter funzionare, hanno bisogno della modalita’ privilegiata. Tutto il resto — per esempio device driver, filesystem, socket — viene implementato in modalita’ utente da speciali processi (tipicamente chiamati
server) a cui si appoggiano le normali applicazioni.
Per esempio, supponiamo che un programma voglia aprire un file: nel caso monolitico, esso contattera’ il kernel attraverso una system call, il kernel fara’ le sue operazioni e ritornera’ il risultato (un file descriptor oppure un messaggio di errore) al chiamante. Con un’architettura a microkernel, invece,
il programma comunichera’ al server del filesystem la sua intenzione di aprire un file; il server, se necessario, contattera’ a sua volta altri server, e, una volta terminato il suo compito, inviera’ una risposta al programma che l’aveva chiamato.
Si puo’ gia’ intuire quanto sia importante la comunicazione tra i diversi processi che girano sopra ad un microkernel. La IPC (Inter-Process Communication), infatti, e’ la principale astrazione fornita da un qualsiasi microkernel (insieme a quella di processo, ovviamente, senza la quale non ci sarebbe IPC).
Si capisce come essa, molto facilmente, possa diventare il collo di bottiglia di questi sistemi: tornando all’esempio di prima, con un kernel monolitico
l’apertura di un file richiede una sola chiamata di sistema, mentre con
un microkernel sono necessarie almeno due IPC (quindi almeno due system
call).
Promesse e fatti
A questo punto `e lecito chiedersi: se ogni operazione, nei sistemi a microkernel,
comporta un overhead maggiore rispetto al caso monolitico, dove stanno
i vantaggi?
La risposta e’: modularita’, flessibilita’, estensibilita’, semplicita’, manutenibilita’, sicurezza. O meglio, questo e’ cio’ che i microkernel promettevano, quando sono nati. Con un hardware sempre pi`u veloce, l’overhead dovuto alle IPC non si sarebbe neanche fatto sentire troppo.
Il problema dei kernel monolitici, infatti, era una complessit`a sempre
crescente: nel corso degli anni erano state incorporate nei nuclei numerose
funzionalita’, che li avevano resi grossi e difficili da gestire. I microkernel,
invece, proponevano un modello molto piu’ flessibile: con essi, l’aggiunta di
nuove caratteristiche e di nuovi servizi poteva avvenire in modo trasparente
e indolore, semplicemente scrivendo un nuovo server.
Vennero quindi progettati e scritti microkernel come Mach e Chorus. Il
clima, in quel periodo 1, era di entusiasmo generale: i microkernel sarebbero
potuti uscire dal mondo della teoria, e dominare quello della pratica.
Purtroppo, i primi confronti di prestazioni furono una vera e propria doccia
fredda, e confermarono i timori che alcuni studiosi avevano nutrito fin
1Nella prima met`a degli anni ’80
2
dall’inizio: i microkernel si dimostrarono lenti, troppo lenti per reggere un
confronto con i sistemi tradizionali. Per esempio, una IPC di Mach (circa
115 µs su un 486-DX50) era quasi 6 volte pi`u lenta di una chiamata di
sistema Unix (circa 20 µs sullo stesso hardware) [2]. Sembrava che, qualsiasi
ottimizzazione si apportasse, la soglia dei 100 µs per IPC non fosse
raggiungibile.
Per superare questo problema, senza rinunciare al design moderno dei
microkernel, si pens`o di reintrodurre in kernel-mode alcuni servizi critici: si
sarebbero cos`ı limitati i passaggi da modalit`a utente a modalit`a kernel e gli
switch tra diversi address-space, guadagnando alcuni punti nelle prestazioni.
Mach e Chorus adottarono questa soluzione, e lo stesso fecero i progettisti di
WindowsNT.
Bisogna per`o dire che, in questo modo, ci si allontanava da quella che
era la filosofia iniziale dei microkernel (ossia limitare le parti in kernel-mode,
e implementare quasi tutti i servizi in user-mode): si otteneva una sorta
di ibrido tra micro e monolitico, senza comunque riuscire a raggiungere le
prestazioni desiderate; inoltre, i microkernel “allargati” si dimostravano piuttosto
grossi e poco flessibili, quasi come i sistemi monolitici che, in origine,
si erano proposti di superare.
3 Nuova generazione
Neppure la soluzione “ibrida” sembrava risolvere i problemi dei microkernel.
Si doveva quindi tornare al design monolitico, rinunciando all’enorme
potenziale di flessibilit`a e scalabilit`a promesso dai microkernel? Qualcuno
era convinto che fosse necessario; altri, invece, non erano disposti a farlo e
iniziarono a considerare delle alternative e ad esplorare nuove strade.
Verso la met`a degli anni ’90, alcuni studiosi iniziarono a progettare e a
scrivere dei microkernel molto piccoli, tanto piccoli da essere talvolta soprannominati
nanokernel. Un tipico esempio `e il microkernel L4, che fornisce solo
3 astrazioni (thread, IPC e spazi di indirizzamento) accessibili da 7 system
call; in totale, `e “grosso” 12 Kb (contro i 300 Kb circa di Mach 3, che offre
all’incirca 140 chiamate di sistema).
Il suo autore principale, Jochen Liedtke, sosteneva che le basse prestazioni
di sistemi come Mach non fossero imputabili al concetto di microkernel, ma
all’implementazione di tali sistemi. Per esempio, in [1] vengono confrontati
i cache misses di Ultrix (monolitico) con quelli di un sistema basato su
Mach. Quest’ultimo risulta meno performante rispetto al primo; ma, secondo
Liedtke, la ragione di ci`o `e da ricercare nel modo in cui `e stato scritto Mach.
In altre parole, un microkernel progettato e sviluppato correttamente ridurrebbe, o addirittura colmerebbe, la differenza di prestazioni con un sistema monolitico. E il modo corretto per sviluppare un microkernel consisterebbe nell’ottimizzarlo per l’hardware su cui poi dovra’ girare.
Liedtke infatti afferma che un grosso problema dei microkernel “di prima generazione”, come Mach, sta nel fatto che essi sono quasi del tutto indipendenti dalla macchina su cui girano. Egli sostiene invece che i microkernel debbano dipendere necessariamente dall’hardware sottostante: in questo modo,
cache misses o TLB misses risulterebbero notevolmente ridotti.
A dimostrazione di ci`o, in [2] Liedtke riporta alcuni dati relativi alle performance di L4 (scritto e ottimizzato per il processore 486): su un 486-DX50, una IPC di 8 byte richiederebbe circa 5 µs , contro i 115 µs di Mache i 20 µs di una system call Unix.
Un’altra caratteristica dei microkernel “di seconda generazione”, come ho gia’ anticipato, consiste nelle dimensioni ridotte. L’idea, infatti, `e di superare l’inflessibilita’ della generazione precedente, cercando di focalizzare il microkernel sui meccanismi e non sui comportamenti. Secondo Liedtke, infatti, il
microkernel dovrebbe comprendere pochi meccanismi semplici e definiti, sui quali implementare, attraverso i server in user-mode, le politiche desiderate.
I sistemi come Mach erano concepiti in una maniera tale che fosse inevitabile implementare alcune policy all’interno del microkernel; inoltre, i tentativi di ottimizzazione, come abbiamo gia’ visto, avevano riportato nel kernel diverse funzionalita’, limitando quindi la flessibilita’ del sistema. L4 invece,
grazie al suo design semplice ed elegante, cerca di limitare al massimo le policy del kernel, dando quindi la possibilit`a di avere sistemi molto piu’ flessibili 3.
4 Mach
Nei paragrafi precedenti ho riassunto brevemente la storia dei microkernel,
accennando anche ad alcune caratteristiche di questi sistemi. Nelle sezioni
successive vedremo in modo pi`u approfondito alcuni aspetti di due importanti
microkernel: Mach e L4.
Mach `e stato probabilmente il microkernel pi`u influente: in esso, infatti,
si trovano alcuni concetti basilari — per esempio, il gestore dei page fault
in user-mode, o la gestione degli IRQ come IPC — ripresi poi da molti altri
sistemi successivi.
2Mechanism, not policy. Questo principio viene usato in molte applicazioni Unix, per
esempio l’X Window System.
3Un altro design molto flessibile `e quello di Exokernel, che non fornisce astrazioni ma
ha l’unica funzione di “multiplexare” le risorse hardware in modo sicuro. Il sistema risulta
molto personalizzabile ed estensibile
Le astrazioni fornite da Mach [4] sono cinque:
• task (la base per l’allocazione delle risorse),
• thread (l’unit`a base di esecuzione di istruzioni),
• port (i “canali” per la comunicazione tra task),
• message (un insieme di dati di un determinato tipo),
• memory object (l’unit`a base per la gestione della memoria).
4.1 Task e thread
Come accade in molti sistemi operativi, anche Mach fa distinzione tra task e
thread4.
Un thread `e, semplicemente, un esecutore di istruzioni. Di conseguenza,
le uniche informazioni associate ad esso sono lo stato del program counter e
dei registri del processore, oltre ad alcuni parametri. I thread sono spesso
chiamati anche “processi leggeri” (lightweight processes), ad indicare il fatto
che possiedono poche informazioni di stato, e sono quindi veloci da creare,
distruggere, riprendere e interrompere.
Un task puo’ essere considerato come un insieme di thread che condividono delle risorse comuni (per esempio uno spazio di indirizzamento virtuale, o delle porte di comunicazione). Un task non esegue operazioni: infatti, questa funzione e’ svolta dai suoi thread (o, spesso, il suo unico thread).
4.2 Porte e messaggi
Tutte le funzioni di IPC sono svolte attraverso i concetti di porte e messaggi.
Le primitive per lo scambio dei messaggi sono fondamentali: con esse, infatti, i task (o i thread) possono parlare tra loro e con il kernel, tant’e’ vero che quasi tutte le altri funzioni di Mach si basano sulle funzioni send e receive.
Come ho gia’ accennato, una porta e’ un canale di comunicazione; in pratica, e’ una coda di una determinata lunghezza, in cui possono risiedere dei messaggi in arrivo.
Un messaggio e’ formato da un header e da una serie di oggetti di un certo tipo; questi oggetti possono contenere dei semplici dati, oppure dei diritti su una porta (che vediamo tra un attimo) o delle porzioni di memoria virtuale trattate con il metodo copy-on-write.
Task e thread rappresentano due diversi aspetti del concetto di processo. I progettisti
di Mach cercarono di tenerli separati per ragioni di flessibilit`a ed efficienza [4].
Per leggere o scrivere messaggi, i task e i thread devono possedere dei determinati diritti (port right) su una porta. Esistono tre tipi di diritti: lettura (receive right), scrittura (send right) e scrittura singola (send-once right). Il diritto di lettura e’ esclusivo: per ogni porta, pu`o esserci un solo ricevitore (un solo task che pu`o leggere i messaggi in arrivo); il diritto di scrittura, al contrario, pu`o essere posseduto da parecchi task.
Porte e messaggi si prestano bene anche ad astrarre alcuni meccanismi di livello piu’ basso, come gli interrupt e le porte hardware. Grazie a queste astrazioni, e’ possibile avere device driver in user-mode, raggiungendo quindi una flessibilita’ e una stabilita’ senza pari. Infatti, le IRQ che arrivano a Mach
vengono convertite in messaggi e, in questo modo, possono essere ricevute da un qualsiasi task. Tuttavia, dal momento che il meccanismo di IPC di Mach e’ abbastanza lento, i driver piu’ “critici” vengono tenuti nel kernel, in modo che le prestazioni non risultino eccessivamente degradate.
4.3 Gestione della memoria
Un concetto originale nell’architettura di Mach consiste nella possibilita’ di avere un gestore della memoria (o, piu’ precisamente, un pager) esterno [3]: un task, cioe’, che viene invocato dal kernel in caso di page fault e che si occupa di caricare dalla memoria di massa la pagina mancante (ed eventualmente di scaricarne un’altra, nel caso in cui non ci sia abbastanza spazio nella memoria
centrale).
In sostanza, il pager crea dei memory object, ovvero degli insiemi di byte sui quali i task possono compiere determinate operazioni (scrittura e lettura).
Ogni memory object e’ rappresentato da una porta; quando si verifica un page fault, il kernel esegue una chiamata (una RPC, ovvero una send piu’ una receive) alla porta del relativo memory object; il pager riceve la RPC, carica la pagina voluta e la riporta al kernel; quest’ultimo infine stabilisce il
mapping tra indirizzo fisico e virtuale, e permette al task che aveva generato il page fault di riprendere l’esecuzione.
5 L4
Il microkernel L4 ha raggiunto, negli ultimi anni, un buon successo, grazie al
design innovativo ed elegante proposto dal suo autore, Jochen Liedtke. E’,
pero’, un successo che per ora si limita al campo della teoria, dal momento
che quasi nessun sistema operativo, attualmente, si basa su questo microkernel
(Mach invece e’ stato usato con successo da diversi sistemi, tra i quali
MacOSX).
L4 riprende diversi concetti di Mach e dei microkernel precedenti, basandosi
per`o sul concetto di “funzionalita” (functionality [5]): il microkernel
deve essere il piu’ piccolo possibile, senza pero’ che cio’ comprometta la sicurezza
o la funzionalita’ del sistema. Citando [6]: “un servizio e’ incluso nel
microkernel se e solo se risulta impossibile da implementare al di fuori del
kernel senza perdita di sicurezza”. I servizi inclusi in L4 sono solamente tre:
• address space,
• thread,
• IPC.
5.1 Address space
In [2] Liedtke individua, tra le cause di inflessibilita’ dei microkernel di prima
generazione, il fatto che in questi sistemi esista una policy per la gestione della
memoria all’interno del microkernel. Infatti, le funzioni del pager esterno
sono limitate ed `e sempre il kernel a stabilire il mapping tra indirizzo fisico
e virtuale.
La soluzione proposta da Liedtke consiste nell’usare degli spazi di indirizzamento
(address space) costruiti ricorsivamente. Uno spazio di indirizzamento
consiste nella porzione di memoria (virtuale) accessibile da un thread.
Su esso sono definite tre operazioni:
• grant: il proprietario di uno spazio di indirizzamento decide di assegnarne
una porzione ad un altro thread. La memoria assegnata scompare
dallo spazio del primo thread, ed appare in quello del secondo;
• map: questa operazione e’ simile al grant, tranne per il fatto che la
memoria mappata viene condivisa tra il primo e il secondo thread
(compare in entrambi gli spazi di indirizzamento);
• flush: quando un thread esegue un flush su una sua pagina, signifi-
ca che essa scompare da tutti gli altri thread che l’avevano ricevuta,
direttamente o indirettamente, dal primo thread.
Grazie a queste tre operazioni, si puo’ ottenere una gestione della memoria
abbastanza elaborata, con la possibilit`a di avere anche pi`u di un gestore di
memoria contemporaneamente. Si comincia con un unico spazio di indirizzamento iniziale, 0, posseduto dal kernel: 0 descrive un mapping “uno-a-uno” tra l’intera memoria fisica e la memoria virtuale. Questo spazio di indirizzamento, pero’, viene quasi subito assegnato (con una grant) ad un task caricato
in fase di boot. Questo gestore iniziale si trova quindi ad avere l’intero 0: tutte le richieste di memoria successive devono essere rivolte a lui, e non piu’ al kernel. Esso puo’, a questo punto, decidere di utilizzare la politica di gestione della memoria che preferisce.
Thread
I concetti di thread e task sono simili a quelli di Mach: il thread e’ l’astrazione
che rappresenta l’esecutore di istruzioni, mentre un task e’ un insieme di
thread che condividono un address space. In L4, in realta’, address space e
task sono sostanzialmente la stessa cosa: per questo, tra le astrazioni fornite
dal microkernel, i task non vengono nominati.
IPC
Come ho gi`a accennato, le funzioni di IPC fornite da L4 sono particolarmente
veloci e quindi sono uno dei punti forti di questo microkernel. Grazie ad esse
e’ possibile implementare, oltre alla comunicazione tra thread, la gestione
delle eccezioni e degli interrupt tramite task in user-mode, come succedeva
in Mach. A differenza di quest’ultimo sistema, pero’, in L4 non esiste il
concetto di porta: per identificare il mittente e il destinatario di un messaggio
vengono usati degli UID, Unique IDentifier, che, come dice il nome,
identificano univocamente i task e i thread.
Clan e Chief
L4 fornisce un meccanismo per garantire protezione e sicurezza tra diversi
task. Funziona in questo modo: un task che crea un altro task diventa il
capo (chief ) di quest’ultimo; il task creato, a sua volta, entra a far parte del
clan “capeggiato” dal suo creatore. Le comunicazioni tra task dello stesso
clan sono libere, senza limitazioni. Quando, invece, due task appartenenti
a clan diversi si vogliono parlare, entrano in gioco i capi dei rispettivi clan,
che svolgono una funzione di filtro: essi, infatti, vengono informati dell’uscita
(o entrata) di messaggi nel loro clan, e quindi possono decidere di lasciarli
passare, bloccarli, o modificarli.
Riferimenti bibliografici
[1] Jochen Liedtke, On microkernel construction, in Proceedings of the 15th
ACM Symposium on Operating System Principles, ACM Press, New
York, 1995, pp. 237-250.
[2] Jochen Liedtke, Towards real microkernels, in Communication of the
ACM, Sett. 1996, Vol. 39, N. 9, pp. 70-77.
[3] Michael Young, Avadis Tevanian, Richard Rashid, David Golub, Jeffrey
Eppinger, Jonathan Chew, William Bolosky, David Black, Robert
Baron, The duality of Memory and Communication in the Implementation
of a Multiprocessor Operating System, in Proceedings of the 11th
ACM Symposium on Operating System Principles, ACM Press, New
York, 1987.
[4] Keith Loepere, Mach 3 Kernel Principles, Open Software Foundation and
Carnegie Mellon University, 1992.
[5] Jochen Liedtke, L4 Reference Manual, version 2.00, GDM, 1996.
[6] Alan Au, Gernot Heiser, L4 User Manual, version 1.14, School of Computer
Science and Engineering, The University of New South Wales,
Sydney 2052, Australia, 1999.
