Assignment: http://students.mimuw.edu.pl/ZSO/PUBLIC-SO/2018-2019/z2_driver/index.html
Device implementation in QEMU: https://github.com/koriakin/qemu/tree/harddoom2
Modified Doom using the driver: https://github.com/koriakin/prboom-plus/tree/doomdev2

Dostarczone rozwiązanie jest w pełni asynchroniczne -- wykorzystuje blok wczytywania poleceń, wysyłanie poleceń przez użytkownika nie wymaga czekania na wykonanie poprzednich. Czytanie z/pisanie do buforów przez użytkownika wykorzystuje mechanizm FENCE_WAIT do czekania na urządzenie.

W plikach dma_buffer.h i dma_buffer.c znajduje się definicja "surowego" bufora wykorzystującego pamięć DMA do komunikacji z urządzeniem wraz z algorytmami kopiowania danych między takim buforem a zwykłym buforem w pamięci RAM.
Do zapamiętania adresów stron bufora zdecydowałem się wykorzystać zwyczajną tablicę 1024 wskaźników -- pewien jej sufiks jest złożony z NULLi, jeśli potrzebujemy mniejszej liczby stron. Uznałem że 1024 jest na tyle małą liczbą, że nie warto implementować bardziej skomplikowanego mechanizmu (np. opartego na listach).

W plikach hd2_buffer.h i hd2_buffer.c znajduje się definicja bufora wykorzystywanego przez urządzenie jako bufor ramki, bufor tekstur, itd., wraz z odpowiadającym interfejsem plikowym do komunikacji z użytkownikiem. Wykorzystuje on wewnętrzne surowy bufor opisany w poprzednim akapicie. Do zarządzania czasem życia bufora wykorzystuję strukturę kref z linuxa. Licznik referencji jest podnoszony w dwóch sytuacjach: gdy zestaw aktywnych buforów jest zapisywany w kontekście (przy poleceniu ioctl setup), oraz gdy zestaw buforów jest "instalowany" na urządzeniu -- za każdym razem gdy do kolejki poleceń trafia polecenie setup z tymi buforami. Oprócz tego jedna referencja jest przeznaczona dla użytkownika i zwalniana gdy użytkownik zamknie wszystkie swoje deskryptory (w liczbie 1) do odpowiedniego pliku. Referencje w kontekście są zwalniane przy zmianie aktywnych buforów lub zamknięciu kontekstu. Mechanizm zwalniania referencji przez urządzenie jest nieco bardziej skomplikowany: za każdym razem gdy instalowany jest nowy zestaw buforów, zbiór buforów które zostały właśnie "usunięte" trafia na koniec pewnej kolejki FIFO wraz z numerem odpowiadającym wartości rejestru FENCE dla tego polecenia. Przy każdym wysłanym zestawie poleceń, korzystając z aktualnej wartości rejestru FENCE na urządzeniu, usuwamy z kolejki bufory które na pewno już nie są używane przez urządzenie (lub zostały zainstalowane później w następnym poleceniu setup -- ale to znaczy, że znowu zostały im podniesione referencje), zmniejszając odpowiednie liczinki referencji. Kolejka czyszczona jest do końca gdy urządzenie jest usuwane.

W pliku context.c znajduje się definicja "kontekstu" -- pliku otrzymanego przez użytkownika w momencie otwarcia urządzenia znakowego, zawierającego zestaw buforów wykorzystywanych przy wysyłaniu poleceń przez ten kontekst. Znajduje się tutaj również kod walidujący polecenia przysłane przez użytkownika zanim zostaną one przekazane niżej, do urządzenia. W celu uniknięcia wyłoań kmalloc, wraz z kontekstem alokowany jest niewielki bufor stałego rozmiaru służący do kopiowania poleceń od użytkownika.

W końcu, w pliku hd2.c znajduje się definicja struktury harddoom2 reprezentującej samo urządzenie (po jednej takiej strukturze na każde urządzenie /dev/doomX). Plik ten zawiera również kod tłumaczący polecenia użytkownika na polecenia urządzenia, kod piszący do bufora poleceń, obsługę przerwań oraz inicjalizację i zwalnianie zasobów urządzenia pci i samego modułu.