Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 89

Biuletyn 89

by Z98 on 2011-12-14
translated by Haos on 2011-12-18

RPC

Zdalne wywołania procedur (Remote Procedure Calls, albo RPC) stanowią istotny składnik systemu Windows, używany chociażby w przypadku usług. Zawierająca ich kod biblioteka - rpcrt4, jest zatem jedną z istotniejszych dla prawidłowego i stabilnego działania systemu ReactOS i równie istotna w projekcie Wine. Sam fakt iż kod WINE działa dostatecznie dobrze w systemie Linux, nie jest żadną gwarancją dla naszego projektu, co więcej, każda z dotychczasowych prób synchronizacji kodu rpcrt4 WINE do nowej wersji, kończyła się bardzo problematycznie, wywołując nieodmiennie ból głowy, problemy z uruchomieniem się naszego systemu i licznymi błędami przy uruchamianiu czy korzystaniu z usług. Thomas Faber - student z ostatniego Google Summer of Code, autor systemu testów dla kodu trybu kernela i jednocześnie nowy nabytek naszej ekipy, znalazł - jak uważa - istotne źródło naszych dotychczasowych problemów z błędami, wywołanymi przez kod RPC z WINE. Kiedy proces dokonuje zdalnego wywołania procedury, otrzymuje od systemu uchwyt reprezentujący to wywołanie, który winien identyfikować tą unikalną operację RPC pośród innych. Unikalność tego uchwytu winna być zapewniona wygenerowaną losowo liczbą. Kod WINE bazował na dostępnym w Linux generatorze liczb losowych, reprezentowanym przez /dev/urandom - którego to w NT i ReactOS nie ma. Co gorsze, funkcja WinAPI którą kod WINE wywoływał w celu wygenerowania liczby losowej, w ReactOS nie była wcale zaimplementowana, co powodowało, iż ta sama liczba mogła zostać użyta więcej niż raz dla wygenerowania identyfikatorów rożnych operacji RPC. Taki błąd wprowadzał niesamowite zamieszanie w systemie i był źródłem różnych objawów, wyglądających na osobne problemy. Thomas poradził sobie z błędem poprawnie implementując brakującą funkcję i wprowadzając inny algorytm generowania liczby losowej. Liczymy iż pozwoli to uniknąć sporej części problemów przy następnej synchronizacji kodu w przyszłości.

Menedżer Pamięci

Wielu z testujących ReactOS narzekało na błąd z powodu którego instalacja systemu zatrzymywała się na rejestracji biblioteki mshtml. Próby debugowania tego problemu doprowadziły naszych programistów daleko w głąb trzewi Menedżera Pamięci, przy okazji ujawniając liczne nieprawidłowości w kodzie tego modułu. Bezpośrednią przyczyną błędu było wyzerowanie struktur danych w stogu (Heap) co sprawiało, że Menedżer Stogu gubił swoje dane o blokach pamięci w trakcie kopiowania biblioteki mshtml. Bez tych informacji Menedżer Stogu nie mógł za-alokować kolejnych bloków i grzązł w nieskończonej pętli. Prawie jedna trzecia Ekipy była do tej pory w jakiś sposób zaangażowana w próby naprawy tego błędu, jednak w ich opinii istnieje tylko jedno prawidłowe rozwiązanie - pod-projekt ARM3, mający na celu przepisanie od nowa modułu Menedżera Pamięci, musi zostać jak najszybciej ukończony. Thomas, jeden z zaangażowanych, początkowo podejrzewał setupapi - bibliotekę odpowiedzialną za instalację innych bibliotek i sterowników. Jej kod - skomplikowany i mało czytelny - mógł wywoływać podobne objawy gdyby dochodziło w nim do przepełnień bufora pamięci. Thomas zaimplementował zatem własną, bardzo okrojoną wersję Menedżera Stogu i wymusił na setupapi korzystanie z niego. Rezultat wykluczył jednak zupełnie winę setupapi, problem zdawał się leżeć znacznie głębiej, w Menedżerze Pamięci. Co gorsze, ku frustracji programistów, problem mshtml zdarzał się losowo, co mogłoby sugerować błąd wyścigu w kodzie.

Cameron Gutman także wziął udział w polowaniu na błąd mshtml, chociaż niedługo potem zajął się poprawką, nadesłaną przez Nikołaja Myltsewa, związaną ze stronicowaniem. Uogólniając, pamięć wirtualna za-alokowana przez aplikację nie przekłada się bezpośrednio na przydzieloną tej aplikacji pamięć fizyczną. Windows używa struktury Working Set do śledzenia wszystkich stronic użytych przez aplikacje w ostatnim czasie, jak i dolnego/górnego ich limitu dla wszystkich procesów. Windows będzie próbował utrzymać working set w pamięci fizycznej, o ile jest w niej dość miejsca nań. Celem working set jest zapobieżenie sytuacji, w której jedna aplikacja zajęłaby całą dostępną fizycznie pamięć, dlatego Menedżer Pamięci regulować będzie jej wykorzystanie przez uruchomione procesy, poprzez wyrzucanie stronic working set różnych procesów z pamięci. Stronice, które zostały zmienione w pamięci fizycznej, muszą również zostać zaktualizowane w pliku stronicowania, nim będą mogły zostać ponownie wykorzystane. W momencie wyrzucania stronic working setu z pamięci fizycznej, ReactOS wyszukiwał dostatecznej ich ilości, by zwolnić wystarczający obszar pamięci wedle wymagania. Niestety, gdy brakowało stronic czystych, balancer nie mógł zwalniać stronic zmodyfikowanych, zapisując uprzednio ich zmiany. Problem ten prowadził w końcu do wyczerpania stronic możliwych do zwolnienia a więc i do niepowodzenia operacji alokowania pamięci i w rezultacie do kraksy systemu. Po drobnych zmianach poprawki Nikołaja znalazły się w głównym drzewie kodu, dzięki czemu Menedżer Pamięci może już wyrzucać stronice zmodyfikowane i odzyskiwać zajętą przez nie pamięć.

Mikrokod procesora

Temat wymaga pewnego wprowadzania w metody projektowania i produkcji CPU. Procesory muszą spełniać standard ISA (Instruction Set Architecture), określający instrukcje jakie muszą wykonywać, zdaje sobie z tego sprawę wielu programistów. Nieliczni jednak wiedzą, iż sam procesor nie wykonuje instrukcji specyfikowanych w ISA bezpośrednio. Istnieje bowiem poziom jeszcze niższy, poziom mikrokodu, kontrolujący operacje procesora tak, by otrzymać wynik zgodny z wymaganiem standardu. Mikrokody te nie są udokumentowane, AMD i Intel traktują je jak tajemnice handlowe. Obecnie, projekty procesorów straszą stopniem komplikacji, nie można dziwić się więc przypadkom, gdy trafiają się błędy typowo sprzętowe. Naprawa sprzętu wymagałaby wielkich nakładów przy zmianie projektu i wycofaniu błędnych modeli, lecz od pewnego czasu możliwe jest modyfikowanie samego mikrokodu, w celu kompensacji błędów. AMD i Intel oferują te modyfikacje mikrokodu za darmo, deweloperom systemów operacyjnych, w postaci plików binarnych, lecz sposób w jaki Windows z nich korzysta jest bliżej nieznany. Pierre Schweitzer zainteresował się tym tematem i ma już kilka pomysłów do wypróbowania, lecz ze względu na niski priorytet i konieczność dokładniejszego zbadania niektórych kwestii - odłożył go na później. Jest to jednak interesujący przykład problemów, na jakie można natrafić na styku sprzętu i oprogramowania.

Setup

Podczas prób instalacji ReactOS na systemach z niewielką ilością pamięci, ujawniło się ograniczenie natury projektowej, mogące istotnie wpłynąć na czas pierwszego etapu instalacji. Zawartość pliku cab, zawierającego pliki systemowe, musi zostać wypakowana na dysk docelowy. Autor tego rozwiązania nie wziął pod uwagę scenariusza, w którym rozmiar pliku cab przekracza rozmiar pamięci fizycznej tej maszyny. Przy każdym wypakowywanym pliku systemowym bowiem, archiwum cab przetwarzane jest sekwencyjnie od początku. Gdy brakuje pamięci fizycznej, ReactOS musi stronicować pamięć, przerzucając jedne na dysk a wczytując inne. Cameron, zauważywszy to ograniczenie, zmodyfikował program wypakowujący, tak by śledził swoją ostatnią pozycję w archiwum, dzięki czemu plik cab przetwarzany jest tylko raz, w sposób ciągły. Zmiana ta była nie tylko właściwa, z punktu widzenia dobrej praktyki programowania, ale i wyraźnie przyspieszyła pracę samego instalatora.

Scatter/Gather DMA

Tradycyjne operacje DMA wymagały dla zapisu pojedynczego, ciągłego bloku pamięci o wymaganej wielkości. W wielu przypadkach system nie może przydzielić bloku o wystarczającej wielkości. Scatter/Gather DMA pozwala obejść to ograniczenie, rejestrując kilka mniejszych bloków, zamiast jednego dużego i zapisując dane do nich. Od dłuższego czasu ReactOS zawierał w sobie wszystkie niezbędne mechanizmy, brakowało tylko spajających i udostępniających je API. Cameron dokończył implementację tych funkcji, dzięki czemu ReactOS może już obsługiwać wymagające S/G DMA sterowniki, głównie kart sieciowych.

Freeloader - optymalizacja zużycia pamięci

Jakiś czas temu Timo Kreuzer zauważył, iż freeloader nie wykorzystuje pamięci w sposób efektywny. Freeloader alokuje pamięć dla dwóch typów danych: niezbędnych dla pełnego uruchomienia systemu oraz tych przekazywanych dla kernela. Domyślnie, freeloader alokował jeden blok o rozmiarze 4MB i używał go w całości dla obu typów danych. Blok ten był w całości przekazywany do kernela, mimo że po uruchomieniu systemu, dane kernela zajmowały tylko jego część. Aby zredukować takie marnotrawstwo, Timo podzielił ów blok na dwie części, dedykowane dla każdego z typów danych. Pozwala to na zwolnienie pamięci z jednego z bloków, co zmniejszało całkowite jej zużycie przez system. Mimo, że niewielka, zmiana ta może mieć istotne znaczenie w długim okresie czasu.

API ścieżek

Wiele z regresji, ujawnionych przy okazji zmian w module ładującym, zostało wywołanych przez nie do końca poprawne funkcje obsługi ścieżek. Moduł ładujący, dokonując wielu operacji dostępu do plików podczas swojego działania przy uruchamianiu programów i bibliotek, wykorzystuje takie funkcje bardzo intensywnie. Alex Ionescu przeznaczył ostatnio wiele czasu na sprawdzenie i przepisanie funkcji związanych z konwersją, kodowaniem znaków, przetwarzaniem skrótów czy zwracaniem kodu błędów w przypadku niepowodzenia operacji. Rozwiązało to większość obecnych do tej pory regresji modułu ładującego i równocześnie powinno usprawnić działanie wielu aplikacji.