Sistema Operativo NACHOS

Università degli Studi di Napoli Federico II

Nachos - not another completely heuristic operating system

di Dexter - dexterp37@gmail.com © 2006 Dexter - dexterp37@gmail.com

Indice

• Introduzione
  • Panoramica
  • Perché Nachos?
• Compilare ed eseguire Nachos
  • Struttura del direttorio
  • Problemi incontrati
• Architettura e design
  • Nachos e simulatore macchina
  • Threads, Scheduler e Multiprogrammazione
  • File System
  • Memoria Virtuale
• Spunti, riflessioni ed approfondimenti
  • Microkernel vs Kernel monolitico… vs no Kernel?
  • File System: crittografia e protezione
  • Nachos: sulla strada dei 64 bit
• Conclusioni
  • Riferimenti

Introduzione

Panoramica

Quali sono le reali differenze tra un calcolatore ed un ferro da stiro? Teoricamente ben poche, sono entrambe macchine che richiedono l’ausilio dell’uomo per portare a termine compiti ben definiti. Per quale motivo, allora, non scrivo questa tesina con un ferro da stiro? Perché quella macchina non è stata progettata per essere flessibile, in altre parole per adattarsi, tramite opportuni mezzi e stratagemmi, ad altre funzionalità. È proprio questo bisogno di flessibilità, di riutilizzazione, uno dei motivi principali che hanno portato alla creazione di meccanismi di gestione intelligenti (i Sistemi Operativi) per semplificare ed ottimizzare l’uso delle risorse “macchina”. L’evoluzione dei sistemi operativi ha tracciato numerosi profondi cambiamenti lungo il suo cammino, ma mai perdendo di vista le sue fondamentali prerogative: efficienza, affidabilità e semplicità.

Perché Nachos?

Nachos, l’oggetto di questa breve trattazione, è un piccolo sistema operativo sviluppato per motivi didattici in ambito universitario. La scelta di esaminare questo sistema operativo, invece che gli altri proposti, è stata dettata da una semplice considerazione: perché esaminare un sistema operativo “completo e funzionante” quando, per sete di conoscenza ed esperienza, si ha la possibilità di gestire ed analizzare un sistema operativo sostanzialmente completo in tutte le sue parti, ma allo stesso tempo profondamente ostico da compilare, ricco di piccoli bug e che lascia molto spazio ad idee ed implementazioni personali?

Concetto chiave in Ingegneria che porta ad una maggiore efficienza ed un abbattimento dei costi. “Never ever reinvent the wheel”

Compilare ed eseguire Nachos

Struttura del direttorio

Il codice sorgente di Nachos è suddiviso in direttori, ognuno dei quali contiene il sorgente di una componente logica del sistema operativo. Ogni cartella contiene il suo Makefile che è in grado di generare un eseguibile di prova del sottosistema logico in esame (per esempio eseguire l’utility make nella cartella threads genera una versione di Nachos per testare le funzionalità relative ai threads).

• Nachos/code – contiene l’albero dei sorgenti del sistema operativo
• Nachos/code/bin – sorgente delle utilità necessarie a generare eseguibili utilizzabili dal sistema Nachos (coff2noff)
• Nachos/code/filesys – sorgente relativo al file system
• Nachos/code/lib – sorgente di alcune funzionalità di libreria utilizzate dal kernel (liste e funzioni per il debug)
• Nachos/code/machine – sorgente del simulatore macchina
• Nachos/code/network – sorgente relativo alle funzionalità di networking
• Nachos/code/test – sorgente delle applicazioni utente scritte per essere eseguite da Nachos
• Nachos/code/threads – contiene il sorgente relativo alla gestione dei threads
• Nachos/code/userprog – sorgente relativo alle funzionalità per il caricamento ed esecuzione delle applicazioni utente

Problemi incontrati

“Fissare i concetti attraverso la pratica” – questo è lo slogan e obiettivo primo di Nachos. Sotto questo aspetto possiamo, con molto rammarico, affermare che Nachos stesso è la principale resistenza al compimento del suo obiettivo. Il primo problema affrontato per ottenere una versione eseguibile del sistema operativo ha riguardato la compilazione mediate il software gcc. L’ipotesi più plausibile è che, essendo il codice di base moderatamente vecchio, sia stato compilato attraverso strumenti più “permissivi e tolleranti” ad errori nel codice (sono stati riscontrati svariati errori nell’uso di puntatori, nonché sintassi C++ non conforme all’attuale standard ANSI C++). La risoluzione di ogni piccolo problema ha spesso comportato il sorgere di numerose altre piccole incompatibilità, che hanno sicuramente distolto l’attenzione, almeno in quei momenti, dall’analisi del sistema operativo. Segue una breve lista (esemplificativa, dato il numero) di cambiamenti effettuati.

• threads/thread.cc (358-362): gli indirizzi delle funzioni non erano salvati correttamente. Risolto utilizzando operatori di address-of (&) ed effettuando il casting a void* (es. machineState[PCState] = (void*)&ThreadRoot;)
• threads/synchlist.h (50): la funzione membro di classe SelfTestHelper era usata come callback e quindi passata come parametro ad un'altra funzione richiedente una funzione di tipo VoidFuncPtr. Ovviamente i tipi non corrispondevano, avendo le funzioni membro di classe non statiche il parametro implicito this
• machine/machine.h (174): l’operatore friend richiede di specificare la keyword class nel caso si stia dichiarando una classe amica
• machine/elevatortest.h (15): dopo la direttiva #endif non devono essere presenti ulteriori comandi (il problema è comune a molti headers)
• machine/elevatortest.cc (65): non è rispettato il prototipo di funzione VoidFuncPtr 2 Un Makefile è un file usato dall’utility GNU chiamata make usata, nel nostro caso, per produrre eseguibili da sorgente in modo automatizzato.
• lib/sysdep.cc (460): non sono effettuati gli opportuni casting nei parametri delle chiamate a funzioni di sistema
• code/makefile.common (29): il parametro di gcc –fwritable-strings è obsoleto

Architettura e design

Nachos e simulatore macchina

Il sistema operativo Nachos è eseguito come processo utente UNIX e, come tale, gode degli stessi diritti di un normale software. Per semplificare e rendere agevole l’uso di Nachos (no...