PRIMA ESERCITAZIONE DI SISTEMI OPERATIVI 1997-1998 Memory manager di Minix ----------------------- Nell'implementazione della system call EXEC di Minix, il MM controlla se e' gia` disponibile una zona libera di memoria sufficiente a contenere la nuova immagine di memoria, altrimenti la chiamata abortisce. Questa politica sara' chiamata "il vecchio algoritmo di EXEC". Sarebbe invece meglio controllare se una zona libera sufficiente sara` disponibile una volta rilasciata la zona di memoria attualmente occupata dal processo che chiama l'EXEC: nel seguito lo chiameremo "nuovo algoritmo di EXEC". Si chiede: - di inserire una nuova system call extend(), la cui chiamata provochi il funzionamento di EXEC con il nuovo algoritmo (in mancanza di tale chiamata i processi utilizzano sempre il vecchio algoritmo); - di consegnare il seguente materiale: - documentazione cartacea (vedi sotto); - un dischetto di bootstrap del sistema Minix modificato; - un secondo dischetto contenente, in due directories Minix distinte, il sorgente dei file modificati, e sorgenti ed eseguibili dei programmi di test; Data di scadenza: lunedi' 20 gennaio 1998. Inserire il materiale in una busta chiusa con sopra scritti numero del gruppo e nome-cognome-login di ogni componente e consegnarla IN BUCA a Dodero o Gianuzzi. Tutto il materiale consegnato (documentazione e dischetti) dovra' essere identificato allo stesso modo (onde evitare disastri se qualcosa cadesse per terra, si rimescolasse il contenuto delle buste ecc). Documentazione -------------- 1. Files sorgenti Le modifiche apportate ai sorgenti Minix devono essere identificate da commenti "speciali" e commentate seguendo lo "stile" di Minix stesso. Esempio /* modifica gruppo xx */ ... /* fine modifica gruppo xx */ 2. Documentazione cartacea La documentazione cartacea puo' essere consegnata manoscritta (purche' chiara e leggibile) oppure scritta con word processors, oppure meta' e meta', ecc. Essa deve essere sintetica, in particolare non devono essere riportate informazioni contenute in questo foglio, sul Tanenbaum ecc. La documentazione deve contenere una "copertina" che riporti nome, cognome, login e firma dei componenti il gruppo che hanno effettivamente svolto l'esercitazione. Nel testo della documentazione devono essere presenti in modo chiaro e sintetico le seguenti informazioni: a. informazioni di utente: deve essere possibile a chiunque sia in possesso dei dischetti e della documentazione, ricreare il kernel, ripassare i tests ecc. b. informazioni di sistema: chi fosse interessato a leggere i sorgenti C modificati, deve trovare informazioni su come e' stata fatta la modifica. Vanno elencati: i files contenuti nei dischetti, e per ciascun file le modifiche, sia inserimenti sia cancellazioni, apportate alle strutture dati e alle funzioni ivi contenute. Delle modifiche va data motivazione e descrizione sintetica. La descrizione va data in italiano (bastano poche righe) Non va descritta l'operazione riga per riga! (esempio di cosa NON scrivere: "la funzione pinco() confronta il primo parametro con zero e se essi sono uguali, azzera anche il secondo parametro". Chiunque leggera' la documentazione sa anche leggere un IF!) Verra' consegnato a chi ne fara' richiesta un esempio di cosa si intende per buona documentazione di una funzione Minix non compresa tra quelle facenti oggetto di questa esercitazione. c. informazioni sui tests: va motivata la scelta dei programmi di tests, e ne vanno riportate le modalita' di esecuzione. Dei singoli programmi che compongono il test riportare solo le caratteristiche rilevanti (il sorgente dovrebbe essere comprensibile con l'aiuto al piu' di qualche commento). (esempio: il programma P1 ha due loop annidati il cui scopo e' di ritardare il processo per almeno..., nel test n.2 si lanciano quattro copie di P1 e due di P2, e si osserva che ....) d. Va fornito infine un commento dei risultati ottenuti, ad esempio mostrando qualche situazione in cui il nuovo algoritmo riesce a lanciare piu' processi del vecchio algoritmo, oppure accade il viceversa.