La seconda parte del progetto `e quella che getta le basi di un vero e proprio sistema operativo. Durante lo svolgimento di questo compito, gli studenti dovranno sviluppare una serie di funzionalit`a che permettano al sistema di gestire l’esecuzione concorrente di pi`u processi, realizzando un semplice scheduler, di effettuare operazioni di input/output e richiamare servizi di sistema sotto forma di system call.
Questa fase richiede un pi`u profondo livello di comprensione del funzionamento del- l’hardware e dei sistemi operativi per poter essere svolta correttamente. Il documento di specifica propone una serie di semplici algoritmi per realizzare le varie funzionalit`a, poi testate dall’unit`a di verifica, lasciando agli studenti la libert`a di implementarne va- rianti ottimizzate. Viene inoltre richiesto di intraprendere alcune scelte implementative cardine, tra cui, per esempio, il metodo di gestione dei tempi di esecuzione dei processi o l’organizzazione interna delle strutture dati.
1Il linguaggio consigliato per svolgere l’esercizio `e il C [33], ma pu`o essere utilizzato qualsiasi linguag-
gio per cui esista un compilatore in grado di generare file binari eseguibili dal processore ARM7TDMI, a patto di utilizzare, in fase di linking, la mappa della memoria fornita e, possibilmente, implementare meccanismi per accedere alle funzioni di libreria.
4.2.1
Gestione Processi
Questa parte del progetto richiede la realizzazione del core di un sistema operativo mul- tiprocesso, con uno schema a condivisione del tempo, `e dunque necessario implementare un algoritmo di scheduling dei processi attivi. Viene proposto di realizzare un semplice scheduler round-robin in modo da garantire ad ogni processo in attesa l’opportunit`a di prendere il controllo del processore. Questa propriet`a `e intrinsecamente garantita dalla semplice struttura dell’algoritmo di selezione round-robin, per cui tutti gli elementi della lista di interesse vengono selezionati in un ordine prestabilito, ottenendo tutti il medesimo quantitativo di risorse (in questo caso la risorsa in oggetto `e il tempo di esecuzione).
Per gestire l’avvio e la terminazione dei processi, il nucleo deve esporre appositi servizi di sistema, inoltre ad ogni processo viene associato un identificatore univoco generato secondo un algoritmo a scelta degli studenti.
Infine si richiede di implementare un semplice algoritmo di deadlock detection, basato sulla differenza tra semafori (cfr. sec. 4.2.2) “Soft Blocking” e “Hard Blocking”. I primi sono semafori associati ai device, per i quali si presuppone che, prima o poi, le risor- se richieste vengano liberate a causa della terminazione di un comando su dispositivo; i semafori del secondo tipo sono invece quelli non direttamente controllati dal sistema ope- rativo e che permettono la sincronizzazione inter-processo. Una volta effettuata questa distinzione, risulta chiaro che, se nessun processo `e pronto ad eseguire, nessun processo sta aspettando il termine di un’operazione di input/output ed uno o pi`u processi sono in attesa su un semaforo “Hard Blocking”, allora quei processi saranno in mutua attesa e si pu`o dichiarare che il sistema `e in stato di deadlock.
4.2.2
Active Semaphore List
Per l’interazione tra i processi e con i dispositivi esterni `e necessario realizzare un mecca- nismo di sincronizzazione, viene quindi proposto uno schema di semafori pesati di basso livello.
Il documento di specifica richiede la realizzazione di un modulo, denominato Active Semaphore List, per la gestione dei semafori attivi; questi saranno identificati da un intero e conservati in una lista ordinata, in modo da semplificare l’ottimizzazione dell’algoritmo di ricerca. L’intero che definisce ogni semaforo ha doppia valenza: il valore vero e proprio dell’intero rispecchia lo stato interno del semaforo (i.e. il numero di risorse attualmente disponibili/richieste associate a quel semaforo), il puntatore all’intero viene utilizzato come identificativo univoco per fare riferimento ad ogni semaforo.
Oltre ai semafori gestiti dall’Active Sempahore List (abbreviato in ASL), vengono definiti anche una serie di semafori di sistema associati ai device esterni, questi semafori saranno utili per gestire le richieste di input/output da parte dei processi.
4.2.3
Interrupt Handler
Il nucleo del sistema `e il componente che si occupa di gestire la comunicazione a pi`u basso livello con i dispositivi emulati collegati a µARM. La comunicazione tra i device ed il processore avviene attraverso due canali: il bus di sistema, attraverso cui passano i flussi di dati, e le linee di interrupt, che i dispositivi utilizzano per richiamare l’attenzione del processore all’avvenire di un cambiamento di stato. La gestione dell’interazione a basso livello con i dispositivi dovr`a, quindi, essere implementata in due parti diverse del core: la gestione delle richieste ai device sar`a un servizio offerto dal sistema, dunque viene raggruppata con le chiamate di sistema disponibili (cfr. sec. 4.2.4), la gestione delle risposte deve invece avvenire in conseguenza alle interruzioni dell’esecuzione da parte del dispositivo, `e quindi inclusa nel gestore degli interrupt.
Un caso particolare `e quello dell’interval timer: questo speciale dispositivo `e l’unica fonte di temporizzazione disponibile nel sistema, quindi il gestore degli interrupt dovr`a utilizzarlo simultaneamente per svolgere due diversi lavori di sincronizzazione: lo sche- duling dei processi ed il servizio di attesa. La soluzione a questo problema `e uno dei compiti pi`u interessanti lasciato agli studenti.
4.2.4
Low Level System Calls
Come accennato in precedenza, questo livello del sistema operativo deve essere in grado di fornire alcuni servizi di basso livello ai processi privilegiati che li richiedano. La documentazione dichiara la lista di funzioni richiamabili, i loro parametri ed il risultato atteso, lasciando la scelta della maggior parte dei dettagli implementativi come compito per gli studenti.
Poich´e le funzionalit`a offerte da questo livello permettono la creazione e la termina- zione di processi con permessi arbitrari, oltre all’accesso diretto alla memoria fisica del sistema ed ai device, le chiamate di sistema devono essere accessibili soltanto a processi che eseguano con privilegi massimi (i.e. System/Kernel Mode). I livelli superiori del sistema forniranno servizi con capacit`a pi`u limitate richiamabili anche da processi senza privilegi, questi servizi fungeranno in parte da wrapper per le chiamate di basso livello, in modo tale da renderle pi`u “sicure”.