Progetto conclusivo del corso di Li4d (a.a. 2000-2001)

GEstore Azioni

(GEA)

Scopo del progetto

Lo scopo del progetto gea e' quello di realizzare comandi esterni (stile Unix) in grado di  gestire un insieme di azioni da eseguire sul file system. Tali comandi utilizzano un file di azioni (comandi) definite dall'utente e contenute all'interno del file .my_actions  collocato nella home dell'utente. Il file di azioni .my_actions contiene una sequenza di strutture definite nel seguente modo:

typedef struct azione {
                     int  action_id;                                         /*  identificativo della azione */
                    char action_class[MAXCLASS];        /* MAXCLASS  macro che definisce la lunghezza massima dell'identificatore di classe */
                    char action[MAXACTION];               /* MAXACTION  macro che definisce la lunghezza massima del comando */
                    char path[MAXPATH];                       /* MAXCLASS  macro che definisce la lunghezza massima del path a cui applicare la azione */
              } ;

Ad ogni struttura corrisponde una azione definita dall'utente. Ogni azione e' caratterizzata da un nome che la identifica (action_id), dalla classe della azione (action_class[MAXCLASS]),  e da un comando (che viene memorizzato con le eventuali opzioni in action[MAXACTION]) da applicare ricorsivamente al path memorizzato in path[MAXPATH]. Possono essere definite piu' azioni con lo stesso identificativo di classe in quanto una classe raccoglie azioni omogenee (ad esempio uno stesso comando applicato a path diversi o uno stesso comando con opzioni diverse).

Un esempio di contenuto logico (ricordate che il file deve memorizzare strutture) del file .my_actions  potrebbe essere il seguente:

                   action_id = 1
          action_class = "rimuovi"
          action = "rm -f *.c"
          path = "$HOME/PIPPO"
                   action_id = 2
          action_class = "rimuovi"
          action = "rm -f *.log"
          path = "$HOME/PIPPO"
                   action_id = 3
          action_class = "rimuovi"
          action = "rm -f *.c"
          path = "$HOME/TOPOLINO"
                   action_id = 4
          action_class = "compila"
          action = "make"
          path = "$HOME/PIPPO"
                   action_id = 5
          action_class = "visualizza"
          action = "netscape *.html"
          path = "$HOME/WEB"
 

Ogni azione deve essere gestita da un processo figlio. Il processo che gestisce una azione deve riportare la lista dei file a cui il comando definito in action e' stato applicato e se tale applicazione ha avuto successo oppure no, in append ad un file di log chiamato .my_actions_log. Tale file e' comune a tutti i processi figlio.  Ogni linea salvata durante il log deve essere preceduta dalla data e ora in cui questa viene scritta.

Il software gea deve mettere a disposizione dell'utente dei comandi (specificati di seguito) per

 

Comandi per la gestione delle azioni

La gestione delle azioni avviene tramite i seguenti comandi:

Rimozione di una specifica azione:

rmaction action_id1 ... action_idn

rimuove le azioni con identificatori action_id1 ... action_idn dal file .my_actions. Le cancellazioni avvengono logicamente attraverso l'assegnamento di un valore negativo ai campi action_id. Se un identificativo di azione non e' trovato, si deve generare un messaggio che segnala tale errore sullo standard error e continuare ad elaborare gli identificatori di azione rimanenti. Se il file .my_actions si svuota,  lo si rimuove.
 

Rimozione di una classe di azioni:

rmclass action_class1 ... action_classn

rimuove le azioni con identificatori di classe action_class1 ... action_classn dal file .my_actions. Le cancellazioni avvengono logicamente attraverso l'assegnamento di un valore negativo ai campi action_id. Se un identificativo di classe non e' trovato, si deve generare un messaggio che segnala tale errore sullo standard error e continuare ad elaborare gli identificatori di classe rimanenti. Se il file .my_actions si svuota,  lo si rimuove.
 

Rimozione di azioni definite su una directory:

rmpath dir1 ... dirn

rimuove le azioni associate alla directory dir1 ... dirn dal file .my_actions. Le cancellazioni avvengono logicamente attraverso l'assegnamento di un valore negativo ai campi action_id. Se una directory non e' trovata, si deve generare un messaggio che segnala tale errore sullo standard error e continuare ad elaborare le directory rimanenti. Se il file .my_actions si svuota,  lo si rimuove.
 

Aggiunta di una azione:

addaction

aggiunge una action al file .my_actions. Il comando chiede all'utente le stringhe da associare  ai campi action_class, action, e   path. Inoltre, il comando memorizza la nuova azione all'inteno della prima locazione libera nel file .my_actions, aggiornando di conseguenza il campo action_id. Come locazione libera e' da intendersi una locazione con action_id negativo (cancellazione logica), e in mancanza di una locazione cancellata logicamente, si crea una nuova locazione alla fine del file. Se il file .my_actions non esiste, lo si crea.
 

Visualizza classe di azione:

showclass [action_class] [-all]

mostra a video la lista delle azioni di classe  action_class contenute nel file .my_actions. Se la flag  -all e' presente, tutte le azioni vengono mostrate. Se l'identificativo di classe action_class non e' trovato, si deve generare un messaggio che segnala tale errore sullo standard error.
 

Visualizza le azioni associate ad una directory:

showdir [dir] [-all]

mostra a video la lista delle azioni associate alla directoy dir contenute nel file .my_actions. Se la flag  -all e' presente, tutte le azioni vengono mostrate. Se la directory dir non e' trovata, si deve generare un messaggio che segnala tale errore sullo standard error.
 

Esegui azioni:

doaction action_id1 ... action_idn [-d dir] [-c action_class] -n nproc

esegue le azioni  action_id1 ... action_idn e quelle associate alla directory  dir e alla classe di azioni  action_class se le rispettive flag sono presenti. Se una azione compare piu' volte perche' citata esplicitamente o implicitamente con l'uso delle flag, questa deve essere eseguita una ed una sola volta. La flag -n deve essere presente e nproc indica il numero (massimo) di processi figlio che possono essere simultaneamente attivi. Quindi, se si invoca un comando che coinvolge (esplicitamente o implicitamente) 5 azioni usando 2 come valore di nproc, solo due processi figlio alla volta possono essere attivi. Da un punto di vista implementativo questo implica che il pade non puo' generare piu' di  nproc figli alla volta, cioe' generati  nproc figli deve attendere la terminazione di un figlio prima di poterne generare un altro. Se qualche identificativo di azione, classe, o directory non e' trovato, generare un messaggio che segnala l'errore sullo standard error.

Consistenza delle operazioni

Ci si deve assicurare che l'esecuzione di sezioni critiche nei vari comandi sia non interrompibile da un ^C e che, qualora l'utente tenti comunque di interromperle con un ^C venga dapprima richiesta conferma dell'interruzione e quindi l'operazione venga effettivamente interrotta senza che ne' il file delle azioni, ne' il file di log risultino inconsistenti.
 

Implementazione del progetto

Per implementare gea dovrete usare il piu' possibile le chiamate di sistema viste a lezione.
 

Svolgimento del progetto

Il progetto deve essere svolto individualmente. Non sono ammessi progetti a gruppi.
 

Valutazione del progetto

La valutazione del progetto consiste nella discussione dello stesso, presso lo studio del docente. La discussione si conclude con l'assegnazione di un punteggio che contribuisce alla definizione del voto di Sistemi operativi I:

Consegna del progetto

Il progetto puo' essere consegnato in una qualunque delle sessioni di esame dell'anno accademico 2000-2001.

 La consegna consiste in due passi:

  1. invio, per email, al docente, del file tar.gz contenente tutti i sorgenti relativi al progetto.
  2. consegna, in forma cartacea, al docente, di una relazione di massimo 8 pagine, con la descrizione delle principali scelte progettuali e con una breve descrizione che metta il docente in grado di compilare e provare il vostro eseguibile. Alla relazione deve essere allegato il codice di tutti i sorgenti, indipendentemente dal fatto che tali sorgenti siano effettivamente stati inoltrati via email al docente.

  3.  

Discussione del progetto

La discussione del progetto consiste in due fasi:
  1. lo studente compila il progetto sulla macchina del docente e ne dimostra la conformita' alle specifiche, mediante semplici esempi di utilizzo.
  2. lo studente risponde al docente su domande che hanno a che fare con la realizzazione del progetto, alle scelte effettuate e/o alle possibili migliorie o innovazioni del codice presentato.
Il tutto dovrebbe prendere non piu' di mezz'ora, salvo che non si siano riscontrati problemi particolari.
 

Assistenza

Per tutta la durata del progetto il docente e' disponibile, nel normale orario di ricevimento, a risolvere ogni dubbio e/o questione che riguardi il progetto.
Potete inoltre richiedere spiegazioni e/o chiarimenti per email (perso@di.unipi.it)