Systemy operacyjne

Projekt pierwszy - przykładowe tematy

Programowanie z wykorzystaniem API systemów Uniksowych
1.  Prosty interpreter poleceń [10p] Zaprojektuj i zaimplementuj prosty interpreter poleceń. Interpreter pobiera ze standardowego wejścia pojedynczy wiersz. Nastepnie dokonuje prostej analizy wiersza dzieląc go na słowa separowane spacjami. Pierwsze słowo jest nazwą programu który należy uruchomić (wykorzystując zmienną PATH), a pozostałe są argumentami. Shell uruchamia program i standardowo czeka na zakończenie jego pracy, chyba że ostatnim słowem jest znak & co powoduje uruchomienie programu w tle, jak w normalnym shellu bash. Shell kończy pracę gdy otrzyma znak końca pliku. Dzięki temu mozliwe jest przygotowanie prostych skryptów, które można uruchamiać z wiersza poleceń bash-a, jeżeli pierwsza linia skryptu ma postać #!/home/student/moj_shell  (gdzie po ! podaje się scieżkę do programu shella). Dodatkowe opcje to:

a) [6p] możliwość przekierowania standardowego wyjścia polecenia przy pomocy >>
b) [9p] możliwość tworzenia potoków o dowolnej długości przy pomocy znaku |
c)  [9p] historia poleceń - shell przechowuje (w zewnętrznym pliku w katalogu domowym użytkownika - tak że historia powinna "przetrwać" zakończenie shella) dokładną treść 20 poleceń, a wysłanie sygnału SIGBRK powoduje wyświetlenie historii na standardowym wyjściu - uwaga na niuanse związane z obsługą sygnałów !!!

Uwaga: Jako minimum, oprócz części podstawowej, projekt powinien mieć zrealizowany jeden z punktów a)-c)
2. [12p]  Demon synchronizujący dwa podkatalogi: Program który otrzymuje co najmniej dwa argumenty: scieżkę źródłową scieżkę docelową . Jeżeli któraś ze ścieżek nie jest katalogiem program powraca natychmiast z komunikatem błędu. W przeciwnym wypadku staje się demonem. Demon wykonuje następujęce czynności: śpi przez pięć minut (czas spania można zmieniać przy pomocy dodatkowego opcjonalnego argumentu), po czym po obudzeniu się porównuje katalog źródłowy z katalogiem docelowym. Pozycje które nie są zwykłymi plikami są ignorowane (np. katalogi i dowiązania symboliczne). Jeżeli demon (a) napotka na  nowy plik w katalogu źródłowym, i tego pliku brak w katalogu docelowym lub (b) plik w katalogu docelowym ma późniejszą datę ostatniej modyfikacji demon wykonuje kopię pliku z  katalogu źródłowego do katalogu docelowego - ustawiając w katalogu docelowym datę modyfikacji tak aby przy kolenym obudzeniu nie trzeba było wykonać kopii (chyba  ze plik w katalogu źródłowym zostanie ponownie zmieniony). Jeżeli zaś odnajdzie plik w katalogu docelowym, którego nie ma w katalogu źródłowym to usuwa ten plik z katalogu docelowego. Możliwe jest również natychmiastowe obudzenie się demona poprzez wysłanie mu sygnału SIGUSR1. Wyczerpująca informacja o każdej akcji typu uśpienie/obudzenie się demona (naturalne lub w wyniku sygnału), wykonanie kopii lub usunięcie pliku jest przesłana do logu systemowego. Informacja ta powinna zawierać aktualną datę.

a) [10p.]  Dodatkowa opcja -R pozwalająca na rekurencyjną synchronizację katalogów (teraz pozycje będące katalogami nie są ignorowane). W szczególności jeżeli demon  stwierdzi w katalogu docelowym  podkatalog którego brak w katalogu źródłowym powinien usunąć go wraz z zawartością.
b) [2p.] W zależności  od rozmiaru plików dla małych plików wykonywane jest kopiowanie przy pomocy read/write a w przypadku dużych przy pomocy mmap/write (plik źródłowy) zostaje zamapowany w całości w pamięci. Próg dzielący pliki małe od dużych  może być przekazywany jako opcjonalny argument.

Uwagi: (a) Wszelkie operacje na plikach należy wykonywać przy pomocy API Linuksa a nie standardowej biblioteki języka C (b)  kopiowanie za każdym obudzeniem całego drzewa katalgów zostanie potraktowane jako poważny błąd (c) podobnie jak przezucenie części zadań na shell systemowy (funkcja system).


Uwagi:

<>1.) Projekty pisane są w grupach dwuosobowych.
2.) Odbiór projektu  polega na dostarczeniu  kodu źródłowego (płytka CD) +  raportu na papierze (razem z płytką w koszulce foliowej) zawierającego:

a) Dane wykonawców i prowadzącego + treść zadania,
b) Kodu programu z komentarzami.

c) Opis najistotniejszych algorytmów
d) Opis najważniejszych modułów (funkcji i zmiennych globalnych)

3.) Kary: za beznadziejny styl programowania max: -5p. za niekompletność punktów c) d) dokumentacji -4p.


Na ostateczną liczbę punktów bardzo duży wpływ będzie miała rozmowa, która zostanie w późniejszym terminie przeprowadzona z zespołem realizującym projekt.

Opracował: Wojciech Kwedlo