Sistema Operativo NACHOS

CPU4 Nachos implementa una semplice strategia FIFO per lo short term scheduling

© 2006 Dexter - dexterp37@gmail.com

Quando il sistema è attivato (la macchina di prova è a singolo processore), viene chiamata la funzione Scheduler::Run, la quale a sua volta inizierà la sequenza di operazioni necessarie per il cambio di contesto. Scendendo più nei dettagli possiamo notare come in questa funzione dapprima si salva lo stato del vecchio thread (Thread::SaveUserState per salvare lo stato dei registri della CPU e AddrSpace::SaveState per le informazioni riguardo lo spazio degli indirizzi), poi si disabilitano gli interrupts e successivamente viene chiamata la funzione assembly di basso livello SWITCH (machine-dependent e definita in switch.s) che attua il cambio di contesto modificando gli opportuni registri della CPU. Nel caso in cui il processo non dovesse terminare volontariamente (finire il suo compito) prima di X unità di tempo, al generarsi della specifica interruzione il scheduler lo...

interromperebbe e metterebbe in una coda, prendendone un altro dall'inizio della stessa per eseguirlo (Round Robin).

3.3 File System

Secondo le scelte fatte nel Makefile, Nachos è compilato con una differente implementazione del file system. La definizione FILESYS_STUB forza l'uso di una classe per questo sottosistema che utilizza syscall UNIX per la gestione dei file. Non utilizzando la su citata opzione si utilizza l'implementazione Nachos del file system, che però soffre di limitazioni, anche se molte di facile risoluzione. Per eseguire le operazioni di lettura e scrittura il file system comunica, attraverso opportune chiamate del kernel di Nachos, con il simulatore macchina e, più precisamente, con l'emulazione del disco rigido (machine/disk.cc). Il disco è astratto a partire da un normale file UNIX presente nella cartella di lavoro di Nachos, che è trattato alla stregua di un vero disco: è suddiviso in settori e le operazioni

di lettura/scrittura sono adeguatamente soggette ad errori e ritardi. Le due più grandi limitazioni di cui soffre questa implementazione del file system sono la mancanza di un albero del direttorio e la grandezza dei file fissa. Lo spazio dei nomi dei file è infatti completamente piatto, ovvero oltre al direttorio radice non esistono ulteriori direttori di livelli successivi. Una possibile semplice (ma inefficiente) soluzione a questo problema, sperimentata durante la stesura di questa analisi del sistema operativo, è stata implementata modificando la classe FileHeader ed aggiungendo un campo di tipo intero che funge da bitfield contenente gli attributi del file (e quindi anche se il file è un direttorio o un semplice file). Si è reso quindi necessario modificare la classe FileSystem (nelle funzioni Create ed Open) ed adattare la struttura DirectoryEntry (in filesys/directory.h) trasformando il campo InUse in un più efficiente bitfield. Anche laclasse OpenFile ha avuto bisogno di alcune modifiche. O Nachs File System (non STUB) S SEmulatozione Accesso iDisco Sincrono m(disk.cc) (syncdisk.cc) u. UNIX File System F.3.3.1 File System di Nachos5 Purtroppo non si è riusciti ad ottenere una versione completamente funzionante per la data di consegna di questa analisi. 6 Per memorizzare valori booleani è possibile utilizzare 1 solo bit, invece che occupare tutti i bit di una variabile C++ bool. I restanti bit possono essere usati per memorizzare altre opzioni, nel nostro caso se l'header è di un direttorio o di un file normale. © 2006 Dexter - dexterp37@gmail.com 73.4 Memoria Virtuale L'uso della memoria virtuale comporta numerosi vantaggi tra cui lo svincolo della grandezza del programma da quella della memoria fisica e la possibilità di allocare dati in spazi fisici non continui pure continuando ad utilizzare indirizzi virtuali contigui. In Nachos sono implementate due tecniche per la gestione della

memoria: paginazione e Translation Lookaside Buffer (TLB).

Contrariamente alla teoria studiata, in questo sistema operativo la TLB non funge da cache per la tabella delle pagine, ma la sostituisce completamente; se il sistema TLB è attivo ed una pagina non vi è presente, è generato un PageFault (anche se la pagina potrebbe già essere in memoria!) ma non si accede alla tabella delle pagine. La traduzione degli indirizzi avviene come di consueto, individuando il page frame e l'offset.

Ogni riferimento alla lettura o alla scrittura di valori in memoria è soddisfatto attraverso le funzioni Machine::ReadMem e Machine::WriteMem. Queste due funzioni fanno uso della routine Machine::Translate, che è il vero cuore del sistema di traduzione degli indirizzi virtuali in indirizzi fisici. Segue un estratto di tale funzione, con i relativi commenti.

// calculate the virtual page number, and offset within the page, vpn = (unsigned)

virtAddr / PageSize;
offset = (unsigned) virtAddr % PageSize;
if (tlb == NULL) { // => page table => vpn is index into table
    if (vpn >= pageTableSize) {
        DEBUG(dbgAddr, "Illegal virtual page # " << virtAddr);
        return AddressErrorException;
    } else if (!pageTable[vpn].valid) {
        DEBUG(dbgAddr, "Invalid virtual page # " << virtAddr);
        return PageFaultException;
    }
    entry = &pageTable[vpn];
} else {
    for (entry = NULL, i = 0; i < TLBSize; i++) {
        if (tlb[i].valid && (tlb[i].virtualPage == vpn)) {
            entry = &tlb[i]; // FOUND!
            break;
        }
    }
    if (entry == NULL) { // not found
        DEBUG(dbgAddr, "Invalid TLB entry for this virtual page!");
        return PageFaultException; // really, this is a TLB fault,
        // the page may be in memory,
        // but not in the TLB
    }
}

7 Indirizzi che non corrispondono direttamente ad indirizzi fisici, ma dai quali questi ultimi possono essere agevolmentericavati attraverso una preposta funzione y = f(x)© 2006 Dexter - dexterp37@gmail.com 84. Spunti,

riflessioni ed approfondimenti

4.1 Microkernel vs Kernel monolitico... vs no Kernel

E' stupefacente come la mente umana tenda a (ri)classificare le informazioni in categorie ed innovare, spesso ricalcando la strada tradizionalista, riproponendogli stessi schemi con modifiche più o meno sostanziali. Al centro dei numerosi dibattiti riguardanti i sistemi operativi [4], si pone la spinosa questione riguardo la struttura e la presenza del kernel, ovvero del cuore di questi complessi software di gestione delle risorse.

I primi sistemi operativi progettati contemplavano una struttura del kernel detta monolitica, in quanto operavano una completa astrazione dell'hardware mediante interfacce di alto livello e realizzando i servizi necessari (gestione memoria, processi e sincronizzazione) mediante chiamate di sistema o primitive, il tutto in un unico "blocco" eseguito in supervisor mode. Questa tecnica, riconosciuta obsoleta già dai primi anni '90,

è è ancora in uso in molti sistemi operativi (UNIX, Linux, etc.) in quanto, se implementata bene e priva di bug, determina un kernel molto efficiente. Tra i principali svantaggi di questa architettura figurano la grandezza del kernel in memoria, l'eccessiva integrazione del sistema (che può essere considerata una lama a doppio taglio, dato che un bug in una componente potrebbe risultare in un crash per tutto il sistema) e la difficoltà di aggiungere nuovi dispositivi hardware. Una seconda strada percorsa si è concretizzata nel 1985 nel sistema operativo Mach, uno dei primissimi prototipi dell'università Carnegie Mellon ad architettura a microkernel. In un sistema del genere il kernel offre una semplice astrazione sull'hardware e gestisce intimamente operazioni basilari quali la gestione dei thread, gli spazi di indirizzamento, la comunicazione tra processi ed i timer, delegando a programmi che non vengono eseguiti in supervisor mode chiamati

servers l'implementazioni di altre funzionalità (networking, etc.). Tra i principali vantaggi di questo approccio risalta l'affidabilità del sistema rispetto ai crash dei singoli server (un crash in un server, infatti, non produce il blocco della macchina), il facile mantenimento e sviluppo e la possibilità di personalizzazione del sistema (l'amministratore può infatti decidere quali server avviare al boot, senza ricompilare il kernel). Il problema delle prestazioni rappresenta, invece, la palla al piede di questa tecnologia: le comunicazioni tra server-server e server-kernel necessitano di sistemi di comunicazioni estremamente veloci ed efficienti. Esistono inoltre alcune varianti di questo modello, tra cui: microkernel modificato (ovvero un ibrido tra kernel monolitico e microkernel, che assorbe nel kernel alcuni server per limitare il numero di chiamate esterne per migliorare le prestazioni) e esokernel (che non effettua una vera e propria astrazione hardware,

lasciando ai programmi utente la libertà di accedere a tutte le risorse ed aree di memoria). Gli approcci appena descritti, giustificano la necessità di un'entità centrale che controlli, gestisca e decida: in poche parole, che garantisca sicurezza. La maggior parte dei sistemi operativi esistenti segue questa strada, ma esistono alcuni sistemi operativi che fanno a meno del kernel (Unununium [5], TUNES [6]). Il principio guida di questi sistemi sta nel fatto che la sicurezza (intesa come controllo dell'accesso alle aree di memoria) è gestita a livello del linguaggio di programmazione: i programmi vengono, infatti, eseguiti allo stesso livello del sistema operativo. Il problema della protezione e separazione della memoria si presenta solo con i linguaggi (C, C++, Assembly) che permettono l'accesso arbitrario alla memoria. Nulla, in questi sistemi, è una entità statica e totalitaria, per la quale i dati sono obbligati a passare; il sistemaNon è altro che una collezione di oggetti dinamici e rimpiazzabili che cooperano tra loro, secondo paradigmi anch'essi variabili. Concetti come desktop, file e file8. Flag hardware che stabilisce se il software in esecuzione può agire su determinate aree critiche (registri macchina, tabelle dei descrittori, etc.)9. Si rende infatti necessario ricompilare il kernel, per aggiungere l'adeguato modulo driver. © 2006 Dexter - dexterp37@gmail.com 9system sono in questi sistemi abbandonati in favore di nuovi paradigmi (si rimanda alla sezione Riferimenti per ulteriori approfondimenti). 4.2 File System: crittografia e protezione Un ruolo di vitale importanza, spesso sottovalutato, per la sicurezza di un sistema informatico è giocato dal File System. Come già noto il file system è quel sottosistema logico che si occupa di organizzare e gestire i file su un dispositivo di memorizzazione. La sua corretta implementazione e configurazione è fondamentale per garantire la riservatezza, l'integrità e la disponibilità dei dati. In particolare, la crittografia e la protezione dei file sono aspetti cruciali per prevenire accessi non autorizzati e garantire la privacy delle informazioni.