NACHOS - Appendice

Introduzione a Nachos: sistema operativo istruzionale

Di Thomas E. Anderson, Università della California, Berkeley

Ascolto e dimentico, vedo e ricordo, faccio ed imparo. - Proverbio cinese

Approccio pratico all'apprendimento

Un buon modo per avere una conoscenza profonda dei concetti chiave di un sistema operativo moderno è quello di sporcarsi le mani — prendere il codice di un sistema operativo e vedere come funziona a basso livello, scrivere elementi importanti del sistema operativo stesso con le proprie mani, ed osservare gli effetti del proprio lavoro. Molti concetti sono compresi meglio con esempi e sperimentazioni. Per questo motivo abbiamo ideato un progetto per il corso di sistemi operativi, per mostrare come usare concetti base per risolvere problemi reali.

Il progetto Nachos

Il progetto che abbiamo ideato è un sistema operativo istruzionale ideato per essere usato come materiale didattico in corsi di sistemi operativi per laureandi e specializzandi. Nachos contiene il codice sorgente per un semplice ma completo sistema operativo, un simulatore che permette il suo uso su macchine in ambiente UNIX, ed una serie di esercizi da portare a termine. Nachos permette a tutti di esplorare i più importanti elementi di un moderno sistema operativo descritti nel libro, da thread e sincronizzazione dei processi, al file system, alla multiprogrammazione, alla memoria virtuale, al networking. Gli esercizi richiederanno di progettare ed implementare importanti funzionalità in ognuna di queste aree.

Nachos è distribuito gratuitamente. Al momento può essere eseguito sia su macchine DEC MIPS UNIX che su macchine Sun SPARC; sono in fase di creazione versioni per altre macchine. Vedi la Sezione D.4 per capire come ottenere una copia di Nachos.

In questa appendice daremo solo una panoramica del sistema operativo Nachos e del simulatore, e descriveremo le nostre esperienze riguardo le esercitazioni assegnate. Nachos è in continua evoluzione in quanto il campo dei sistemi operativi è in continua evoluzione. Possiamo quindi dare solo una istantanea di Nachos; nella Sezione D.4 spiegheremo come ottenere una versione più aggiornata.

Panoramica

Molti dei primi progetti dei corsi di sistemi operativi furono progettati in risposta allo sviluppo di UNIX negli anni ’70. I primi sistemi operativi, come MULTICS e OS/360, erano troppo complicati da capire, e molto di più da modificare, in un semestre. Perfino UNIX era troppo complicato per questo scopo, ma mostrava che il cuore di un sistema operativo poteva essere scritto solo in poche decine di pagine, con poche semplici, ma potenti, interfacce. I recenti avanzamenti nel campo dei sistemi operativi, delle architetture hardware e dell’ingegneria del software, hanno provocato la morte di molti progetti di sistemi operativi sviluppati nello scorso ventennio perché obsoleti. Il networking ed il calcolo distribuito sono oramai una realtà comune. I thread sono una funzionalità fondamentale per la costruzione sia di sistemi operativi sia di applicazioni concorrenti di alto livello. Il rapporto costo-performance tra memorie, velocità CPU e memorie di massa è differente da quello imposto da core memory, magnetic drums, discrete logic e lettori di carte.

Nachos è ideato per aiutare ad assimilare questi concetti riguardanti i moderni sistemi operativi. Nachos illustra e sfrutta delle ultime tecnologie nel campo dei sistemi operativi, quali thread e RPC, i più recenti avanzamenti nel campo hardware quali RISC e la prevalenza delle gerarchie di memoria nonché le più moderne tecniche di design del software quali la stratificazione dei protocolli (protocol layering) e la programmazione orientata agli oggetti (object oriented programming).

Durante la progettazione di Nachos, abbiamo dovuto costantemente affrontare il problema del bilanciamento tra semplicità e realismo nella scelta riguardo a quale codice fornire come parte del sistema di base e quale lasciare come esercizio. Un nostro obiettivo è stato bilanciare il tempo che si sarebbe speso a leggere il codice con il tempo speso a progettare ed implementare, nonché con il tempo speso per imparare nuovi concetti.

Avremmo potuto fornire solamente l’hardware, lasciando al lettore il compito di sviluppare un sistema operativo da zero. Questo approccio non è molto pratico, data la portata degli argomenti da trattare. Al contrario, fornendo codice troppo realistico, si rischierebbe molto facilmente di perdere di vista le idee principali in una foresta di dettagli.

Il nostro approccio è stato quello di scrivere la più semplice implementazione possibile per ogni sottosistema (subsystem) di Nachos; ciò fornisce un esempio funzionante — anche se molto semplicistico — delle operazioni di ogni componente di un sistema operativo. L’implementazione base del kernel di Nachos include un thread manager, un file system, la possibilità di eseguire programmi ed una semplice network mailbox. Come risultato della nostra enfasi sulla semplicità, il kernel base comprende circa 2.500 linee di codice; circa la metà di queste contiene la descrizione delle interfacce ed i commenti (il simulatore hardware conta altre 2.500 linee, ma non è necessario conoscere i dettagli delle sue operazioni per completare gli esercizi). È quindi molto pratico leggere, capire e modificare Nachos durante un corso della durata di un singolo semestre. Anche se costruire un progetto attorno un sistema tipo UNIX aggiungerebbe del realismo, il fatto che il solo file system di UNIX 4.3BSD, escluso i driver per le periferiche, sono circa 5.000 linee di codice lo rende un esempio di base non molto pratico.

Abbiamo scoperto che il kernel base di Nachos può demistificare un gran numero di concetti riguardanti i sistemi operativi che sono molto difficili da capire in astratto. Il semplice fatto di leggere e seguire l’esecuzione del sistema di base può rispondere a domande su come un sistema operativo funziona a basso livello, come:

• Come fanno tutte le componenti di un sistema operativo ad integrarsi?
• Come fa un sistema operativo ad iniziare un thread? Come un processo?
• Cosa succede quando un thread context cambia in un altro thread?
• Come fanno le interruzioni ad interagire con le sezioni critiche?
• Cosa succede con le system call? Cosa succede con un page fault?
• Come funziona la traduzione degli indirizzi?
• Quali strutture di dati in un file system sono sul disco e quali in memoria?
• Quali dati sono scritti sul disco quando un utente crea un file?
• Come si interfaccia un sistema operativo con le periferiche di I/O?
• Cosa vuol dire costruire uno strato (layer) di un protocollo network su un altro?

Ovviamente, solamente leggere il codice è una perdita di tempo; abbiamo risolto questo problema mantenendo il codice più semplice possibile ed ideando esercizi che modificano il sistema in modi fondamentali. Dato che partiamo con codice funzionante, l’esercizio può concentrarsi sui molto più interessanti aspetti della progettazione di sistemi operativi, dove esistono pro e contro e non esiste una singola risposta esatta.

La struttura di Nachos

Prima di iniziare a discutere le esercitazioni, ecco una breve panoramica sulla struttura di Nachos. La figura D.1 illustra come le principali componenti di Nachos sono integrate insieme. Come molti dei primi sistemi operativi istruzionali, Nachos è eseguito su una simulazione della macchina reale. Quando i primi progetti di sistemi operativi furono sviluppati negli anni ’70 e nei primi anni ’80, i simulatori venivano utilizzati per ottimizzare l’uso delle scarse risorse hardware. Senza un simulatore, ogni studente avrebbe avuto bisogno di una macchina per provare nuove versioni del kernel. Ora che i personal computer sono diventati una realtà comune, c'è ancora una qualche ragione per sviluppare un sistema operativo su un simulatore, invece che su una macchina reale?

Crediamo che la risposta sia “sì”, perché l’uso di un simulatore semplifica il debugging. Su una macchina reale, il comportamento di un sistema operativo è non-deterministico; a seconda delle precise tempistiche delle interruzioni, il sistema operativo può seguire un percorso nel codice invece di un altro. La sincronizzazione può aiutare a rendere il comportamento del sistema operativo più predicibile, ma che succede nel caso il nostro codice di sincronizzazione contiene un bug che rende possibile l’accesso a dati da parte di due thread nello stesso istante? Il kernel potrebbe comportarsi correttamente la maggior parte del tempo ma, comunque, bloccarsi occasionalmente. Senza avere la possibilità di ricreare il comportamento che ha portato al verificarsi del blocco, sarebbe molto difficile risalire alle cause del problema. L’esecuzione su un simulatore, invece che su una macchina reale, ci permette invece di ricreare le particolari condizioni che hanno portato al verificarsi di un determinato problema. Ovviamente, il debugging di sequenze di esecuzioni non ripetibili è parte della vita di un ingegnere di sistemi operativi professionista, ma non è consigliabile rendere questa esperienza parte di un corso introduttivo sui sistemi operativi.

L’esecuzione su un simulatore ha anche altri vantaggi. Durante la fase di debugging, si potrebbe avere il bisogno di effettuare modifiche veloci al sistema, di ricompilare e di verificare se il cambiamento ha risolto o no il problema. L’uso di un simulatore riduce il tempo richiesto per questo ciclo di modifica-compilazione-verifica; alternativamente l’intero sistema sarebbe dovuto essere riavviato per testare la nuova versione del kernel. Inoltre, i normali strumenti di debugging non funzionano sui kernel dei sistemi operativi in esecuzione diretta su hardware reale, mentre possono essere utilizzati efficacemente in un ambiente simulato.