# Opisy prac dyplomowych ###### tags: `mimiker` ## Implementacja podsystemu autoryzacji w systemie operacyjnym Mimiker **Oryginał**: Celem pracy jest zaimplementowanie wieloużytkownikowości w Mimikerze. Kluczową częścią systemu uprawnień jest umiejętność rozróżniania użytkowników oraz przyznawania im odpowiednich praw dostępu do zasobów i wykonywania różnych akcji (dostęp do plików, możliwość wysyłania sygnałów etc). W Mimikerze implementujemy standardowy Uniksowy system uprawnień. **Edycja 2** Wielodostępność, czyli możliwość jednoczesnej pracy wielu użytkowników na jednej instalacji, jest kluczową cechą systemów operacyjnych. Bezpieczne współdzielenie zasobów (procesora, pamięci, urządzeń plikopodobnych) w takich systemach wymaga implementacji **podsystemu autoryzacji**, który definiuje **uprawnienia** użytkownika do konkretnego zasobu oraz umożliwia zmianę **tożsamości** procesów (czyli użytkownika, na rzecz którego dany proces działa). Obecnie w Mimikerze brakuje podsystemu autoryzacji, zadaniem magistranta będzie zaimplementowanie go, wzorując się na rozwiązaniach zastosowanych w jądrach systemów **BSD**. Konkretniej, zadanie sprowadza się do zidentyfikowania w istniejącym kodzie systemu Mimiker struktur danych, które powinny przetrzymywać informacje o uprawnieniach, dodania tych uprawnień, zaimplementowania nowych wywołań systemowych (np. `setuid`, `seteuid`, `setgid`, `access`) oraz modyfikacji już istniejących (np. `fork`, `exec`), wszystko to przy zachowaniu domyślnej uniksowej semantyki uprawnień. ## Implementation of the Terminal Subsystem and Job Control in the Mimiker Operating System **Tytuł po polsku**: Implementacja podsystemu terminali i kontroli zadań w systemie operacyjnym Mimiker **Opis**: Większość aplikacji posiadających tekstowy interfejs wymaga wsparcia dla pojęcia terminala zarówno w jądrze, jak i w przestrzeni użytkownika (w postaci bibliotek, np. ncurses). Dodatkowo, zarządzanie (np. zatrzymywanie lub przerywanie) programami uruchamianymi z powłoki wymaga wsparcia dla kontroli zadań. Praca przedstawia specyfikację i implementację podsystemu terminali i kontroli zadań w systemie operacyjnym Mimiker. Zarówno podsystem terminali, jak i kontroli zadań są zgodne ze specyfikacją POSIX, co umożliwia łatwe przenoszenie programów z innych systemów z nią zgodnych. **Edycja**: Terminale znakowe łączące się linią telefoniczną z komputerem głównym już dawno wyszły z użycia, jednak sama koncepcja terminalu przetrwała próbę czasu. Tak jest w systemach uniksowych, gdzie większość aplikacji posiadających tekstowy interfejs użytkownika wymaga wsparcia dla terminali, zarówno w jądrze (w postaci sterownika), jak i w przestrzeni użytkownika (w postaci bibliotek, np. ncurses). Dodatkowo, zarządzanie (np. zatrzymywanie lub przerywanie) programami uruchamianymi z powłoki wymaga wsparcia dla kontroli zadań. Praca przedstawia specyfikację i implementację podsystemu terminali i kontroli zadań w systemie operacyjnym Mimiker. Zarówno podsystem terminali, jak i kontroli zadań są zgodne ze specyfikacją POSIX, co umożliwia łatwe przenoszenie programów z innych systemów z nią zgodnych. **Opis**: W części praktycznej zajmiemy się: - przystosowaniem systemu operacyjnego Mimiker do portowania - stworzeniem portu dla architektury AArch64 (stosowana w nowym sprzęcie Apple!) - minimalnym zbiorem sterowników potrzebnych do uruchomienia systemu na płytce Raspberry Pi 3 - przystosowaniem infrastruktury projektu (mam tu na myśli testy, budowanie, korzystanie z openocd) W części pisemnej opiszemy: - sprzęt z którym przyszło nam współpracować - problemy które napotkaliśmy w trakcie części praktycznej (brak sensownej dokumentacji?) - zastosowane rozwiązania w kodzie - różnice pomiędzy tym co mamy na mips a AArch64 W efekcie chcemy: - uzyskać system, który działa na fizycznym sprzęcie i przechodzi testy przygotowane dla architektury mips pod emulatorem qemu - stworzyć mini poradnik odnośnie tego jak przygotować port systemu unix-like na nową architekturę **Edycja** ## Port systemu operacyjnego Mimiker na architekturę AArch64 Podstawową platformą sprzętową dla systemu **Mimiker** jest wciąż leciwa [Malta][1] z procesorem architektury MIPS. Celem pracy jest zmiana tego stanu rzeczy i opracowanie funkcjonującego portu Mimikera na platformę Rasbperry Pi3 (AArch64). Część praktyczna polega na - przystosowaniu systemu operacyjnego Mimiker do portowania - stworzeniu portu dla architektury AArch64 - zaprogramowaniu minimalnego zbioru sterowników potrzebnych do uruchomienia systemu na płytce Raspberry Pi 3 - przystosowaniu infrastruktury projektu do budowania kodu automatycznego uruchamiania testów dla wielu platform (łącznie z narzędziami CI/CD) Głównym celem pracy jest otrzymanie jądra systemu Mimiker działającego zarówno w programowym emulatorze systemu architektury AArch64 jak i fizycznej płytce Raspberry Pi3. Dodatkowy cel, to przygotowanie przewodnika dla programistów przenoszących system Mimiker na inne platformy. Punktem wyjścia do podjęcia tej pracy może być lektura [2]. [1]:https://mimiker.ii.uni.wroc.pl/documents/MD00627-2B-MALTA_R-USM-01.01.pdf [2]: Michał Barnaś: Warstwa abstrakcji sprzętu dla procesorów z rodziny ARMv8, praca inżynierska obroniona w II UWr., 2019. ## Infrastruktura czasu i narzędzia do profilowania jądra systemu operacyjnego mimiker **Opis**: Mierzenie czasu jak i jego kontrolowanie jest jedną z kluczowych elementów każdego systemu operacyjnego. Praca ma na celu zaimplementowanie rzeczywistego odmierzania czasu, a także dostarczenia narzędzi umożliwiających zbieranie informacji o działaniu systemu. Za pomocą tych danych, umożliwić optymalizację kluczowych fragmentów jądra systemu operacyjnego. **Edycja** Mierzenie czasu oraz jego kontrolowanie jest jedną z podstawowych funkcjonalności każdego systemu operacyjnego, istotną zarówno z punktu widzenia użytkownika końcowego jak i dla prawidłowego działania samego systemu (planowanie i priorytetyzacja procesów, wywłaszczanie, komunikacja z urządzeniami I/O). Praca ma na celu **zaimplementowanie rzeczywistego odmierzania czasu** (RTC), a także **dostarczenie narzędzi umożliwiających zbieranie informacji o działaniu systemu podczas wykonania**. Ten drugi cel (*profiling*) dotyczy podsystemu do analizy wydajności jądra, czyli identyfikacji jego fragmentów zabierających wyjątkowo dużo czasu podczas wykonania. Do pomiaru tego czasu dyplomant wykorzysta zaprogramowaną wcześniej przez siebie infrastukturę czasomierzy.