home *** CD-ROM | disk | FTP | other *** search
/ ftp.disi.unige.it / 2015-02-11.ftp.disi.unige.it.tar / ftp.disi.unige.it / pub / .person / DoderoG / doc_files / esercitaz1.txt < prev    next >
Text File  |  1997-12-01  |  6KB  |  145 lines
  1. Prima esercitazione di sistemi operativi
  2. 1997-1998
  3. Memory manager di Minix
  4.  
  5. Nell'implementazione della system call EXEC di Minix, il MM 
  6. controlla se e' gia` disponibile una 
  7. zona libera di memoria sufficiente a contenere la nuova immagine
  8.  di memoria, altrimenti la chiamata 
  9. abortisce. Questa politica sara' chiamata "il vecchio algoritmo di EXEC".
  10. Sarebbe invece meglio controllare se una zona libera sufficiente 
  11. sara` disponibile una volta rilasciata 
  12. la zona di memoria attualmente occupata dal processo che chiama 
  13. l'EXEC: nel seguito lo chiameremo "nuovo algoritmo di EXEC".
  14.  
  15. Si chiede di inserire nel MM il nuovo algoritmo, ed inserire 
  16. una nuova system call, la cui chiamata 
  17. provochi il funzionamento di EXEC con il nuovo algoritmo 
  18. (inizialmente, e fincheÆ non avviene tale 
  19. chiamata, i processi utilizzano sempre il vecchio algoritmo).
  20. Sintassi:  int extend();
  21. il parametro di ritorno e` un codice di errore negativo 
  22. (distinguendo le situazioni di errore se ne 
  23. esistono), oppure 0 se OK.
  24. Si osservi che se un processo chiama extend, dopo tale chiamata 
  25. il nuovo algoritmo saraÆ applicato 
  26. per tutti i processi ancora da attivare (anche dopo la 
  27. terminazione del processo che ha chiamato extend).
  28.  
  29. Consegnare il seguente materiale:
  30.   documentazione cartacea (vedi sotto);
  31.   un dischetto di bootstrap del sistema Minix modificato;
  32.   un secondo dischetto contenente, in due directories Minix 
  33.   distinte,  il sorgente dei file modificati,
  34.   sorgenti ed eseguibili dei programmi di test, piuÆ se 
  35.   necessari makefiles e scripts vari ecc.
  36.  
  37. Data di scadenza: lunedi' 19 gennaio 1998.
  38. Inserire il materiale in una busta chiusa con sopra scritti 
  39. numero del gruppo e nome-cognome-login 
  40. di ogni componente e consegnarla IN BUCA a Dodero o Gianuzzi.
  41. Tutto il materiale consegnato (documentazione e dischetti) 
  42. dovra' essere identificato allo stesso 
  43. modo (onde evitare disastri se qualcosa cadesse per terra, 
  44. si rimescolasse il contenuto delle buste 
  45. ecc).
  46.  
  47.  
  48. Documentazione
  49. 1. Files sorgenti
  50. Le modifiche apportate ai sorgenti Minix devono essere 
  51. identificate da commenti "speciali" e 
  52. commentate seguendo lo "stile" di Minix stesso.
  53. Esempio /* modifica gruppo xx */ ... /* fine modifica gruppo xx */
  54.  
  55. 2. Documentazione cartacea
  56. La documentazione cartacea puo' essere consegnata manoscritta 
  57. (purche' chiara e leggibile) oppure 
  58. scritta con word processors, oppure meta' e meta',  ecc.
  59. Essa  deve essere sintetica, in particolare non devono essere 
  60. riportate informazioni contenute in questo foglio, sul Tanenbaum ecc.
  61. La documentazione deve contenere una "copertina" che riporti nome, 
  62. cognome, login,data e firma 
  63. dei componenti il gruppo che hanno effettivamente svolto l'esercitazione.
  64. Nel testo della documentazione devono essere presenti in modo chiaro 
  65. le seguenti informazioni:
  66.  
  67.   informazioni di utente: deve essere possibile a chiunque sia 
  68. in possesso dei dischetti e della 
  69. documentazione, ricreare il kernel, ripassare i tests ecc.
  70.  
  71.   informazioni di sistema: chi fosse interessato a leggere i 
  72. sorgenti C modificati, deve trovare 
  73. informazioni su come e' stata fatta la modifica. 
  74. Vanno elencati: i files contenuti nei dischetti, e per 
  75. ciascun file le modifiche, sia inserimenti sia cancellazioni, 
  76. apportate alle strutture dati e alle 
  77. funzioni ivi contenute. Delle modifiche va data motivazione e 
  78. descrizione sintetica. La descrizione 
  79. va data in italiano o in pseudo-codice (bastano poche righe) 
  80. Non va descritta l'operazione riga per 
  81. riga! Verra' consegnato a chi ne fara' richiesta un esempio
  82. di cosa si intende per buona 
  83. documentazione di una funzione Minix non compresa tra quelle 
  84. facenti oggetto di questa esercitazione.
  85. (esempio di cosa NON scrivere: "la funzione pinco() confronta 
  86. il primo parametro con zero e se essi 
  87. sono uguali, azzera anche il secondo parametro". 
  88. Chiunque leggera' la documentazione sa anche leggere un IF!)
  89.  
  90.   informazioni sui tests: va motivata la scelta dei programmi 
  91. di tests, e ne vanno riportate le 
  92. modalita' di esecuzione. In particolare riportare i comandi 
  93. per ricompilare e rieseguire i tests se 
  94. sono semplici, altrimenti predisporre scripts che ricompilano, 
  95. lanciano programmi in background 
  96. ecc. Dei singoli programmi che compongono il test riportare 
  97. solo le caratteristiche rilevanti (il 
  98. sorgente dovrebbe essere comprensibile con l'aiuto al piu' di 
  99. qualche commento).
  100. (esempio: il programma P1 ha due loop annidati il cui scopo e' 
  101. di ritardare il processo per almeno..., 
  102. nel test n.2 si lanciano quattro copie di P1 e due di P2, e si 
  103. osserva che ....)
  104.  
  105.   Va fornito infine un commento dei risultati ottenuti, ad 
  106. esempio mostrando qualche situazione in 
  107. cui il nuovo algoritmo riesce a lanciare piu' processi del 
  108. vecchio algoritmo, oppure accade il 
  109. viceversa, e percheÆ si verificano tali differenze.
  110.  
  111. Consigli utili (a chi non ha mai realizzato grossi programmi):
  112.  
  113. LÆesercitazione si compone di tre parti: 
  114.   lÆinserimento del nuovo algoritmo allÆinterno di MM,  
  115. lasciando comunque il vecchio! Quindi 
  116. occorre innanzi tutto comprendere bene il vecchio algoritmo;
  117.   lÆinserimento di una system call,  
  118.   la realizzazione di uno stato del MM che consente di 
  119. passare al nuovo algoritmo dopo la system call. 
  120. Si raccomanda di progettare e realizzare separatamente le 
  121. tre parti (non fare tutte le modifiche 
  122. contemporaneamente! ) Si raccomanda quindi di sviluppare 
  123. versioni bootabili di Minix intermedie: 
  124. ad es. una in cui eÆ definita la system call extend 
  125. (ma non fa nulla), una in cui eÆ realizzato il nuovo 
  126. algoritmo al posto del vecchio ecc. 
  127.  
  128. Suggerimenti dettati dallÆesperienza (e validi anche dopo la consegna):
  129.  
  130. 1. Tenere sempre copie di tutto cioÆ che eÆ funzionante 
  131. anche se incompleto (la catastrofe eÆ in 
  132. agguato) e copie di modifiche parziali ecc. almeno come sorgenti. 
  133.  
  134. 2. Ripulire periodicamente le varie directories di tutte le prove
  135. non funzionanti ecc. (attenzione: 
  136. potreste cancellare le versioni buone e lasciare quelle non 
  137. funzionanti! Ma se non lo fate dopo un 
  138. poÆ perdete il filo)
  139.  
  140. 3. Fare degli script per tutte le sequenze di comandi non banali 
  141. e ripetute sovente
  142. 4. Scrivere la documentazione man mano che si fanno le modifiche 
  143. e tenerla coerente con le stesse.
  144.  
  145.