Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 68

Biuletyn 68

by Z98 on 2010-01-22
translated by Haos on 2010-01-24

ARWINSS, czyli do trzech razy sztuka

Wokół ARWINSS narosły już legendy, co do założeń, funkcjonalności, powodów dla którego ten pod-projekt został zainicjowany, wszystko to pomimo kilku oświadczeń wydanych przez Aleksieja Bragina. Dochodzi do sytuacji, w których osoby z częściową jedynie wiedzą o ARWINSS usiłują mimo wszystko snuć na ten temat daleko idące, acz w przeważającej większości nieprawdziwe, spekulacje. Celem ARWINSS nie jest zastąpienie obecnie rozwijanego podsystemu Windows32. Jego równoległy rozwój ma służyć, tymczasowo, do pokonania ograniczeń w obecnym podsystemie, dzięki zastosowaniu alternatywnego podejścia do problemu - nie jest to próba całkowitego odtworzenia środowiska z systemu Windows. Jednocześnie, ARWINSS jest związany wyłącznie z Win32 i sam w sobie nie stanowi odrębnego systemu operacyjnego. Twierdzenia, zatem, jakoby ReactOS "zaczynal od nowa" czy "całkowicie zmieniał kierunek" są co najmniej poważnie przesadzone. W toku prac nad ARWINSS, zapewne, techniczne jego zalety jak i wady staną się o wiele wyraźniejsze, nic jednak nie stoi na przeszkodzie by równolegle nie pracować nad dotychczasowym podsystemem Win32, czy też by oba podsystemy mogły koegzystować. Co więcej, użytkownik winien mieć możliwość wyboru jednego z nich wedle uznania. Niniejszym przedstawiliśmy oficjalne stanowisko Ekipy ReactOS, mając nadzieję iż wyjaśnienia rzucą nieco światła na coś co mogło wyglądać jak nagła i nieoczekiwana a zarazem poważna zmiana w projekcie.

Przypomnijmy zatem jeszcze raz, iż ARWINSS bazuje na wielowarstwowej architekturze zastosowanej w WINE, gdzie większość użytecznego dla nas kodu znajduje się na najwyższej warstwie. Poniżej znajduje się sterownik trybu użytkownika, który izoluje jeszcze niższą warstwę natywnego systemu grafiki. Dla każdego systemu grafiki, na którym chcemy używać WINE, wymagany jest osobny sterownik, na przykład WineX11 dla X11, trwają również prace nad sterownikiem dla Quartz. Nie istnieje natomiast sterownik dla systemu grafiki Win32, gdyż musiałby powielać już zaimplementowane funkcje. ARWINSS w przeciwieństwie do WINE takiego sterownika wymaga. Nazwany WineNT, umieszczony jest jako warstwa pomiędzy bibliotekami Win32 stworzonymi przez WINE a częścią podsystemu Win32 po stronie kernela (Win32k). W Windows, te biblioteki Win32 odwoływałyby się bezpośrednio do Win32k, za pośrednictwem syscalls (System Calls), ale implementacja WINE, jak wspomnieliśmy powyżej, wymaga warstwy pośredniczącej. Co istotne, opisany sterownik trybu użytkownika zajmuje się wyłącznie interakcją bibliotek Win32 z systemem graficznym, a pozostałe, równie istotne operacje i usługi, wymagają obsługi przez komponent nazywany WineServer. Na szczęście, w ReactOS ta funkcjonalność została już zaimplementowana, w sposób zbliżony do oryginalnej, tak więc Aleksiej musiał jedynie przekierować wywołania z tychże bibliotek, do odpowiednich komponentów i funkcji w ReactOS. Obecność WineX11 na niektórych diagramach jak i w repozytorium SVN, doprowadziła do wybuchu spekulacji, jakoby ReactOS miał używać X Windows. Jednakowoż WineX11, będąc składnikiem początkowego importu kodu z Wine, z całą pewnością nie był i nigdy nie będzie użyty w ReactOS. Posłużył dla Aleksieja za formę do stworzenia WineNT i efektywnie został przezeń zastąpiony. Żadnemu z deweloperów, mających styczność z ARWINSS nie przyszło do głowy używanie X Windows, zatem zainteresowanie tymże komponentem było z pewnością dla Ekipy wielkim zaskoczeniem.

Na koniec, chcielibyśmy wspomnieć o istotnej różnicy pomiędzy ARWINSS i WINE na systemach *nix. Jako, że system X Windows od zawsze funkcjonował w trybie użytkownika, komunikacja z nim wymagała swego rodzaju wywołań RPC, przez długi czas X Windows nie był w stanie zaoferować bardziej efektywnej metody wywołań. Użyte w ARWINSS syscalls, czyli wywołania między bibliotekami Win32 w trybie użytkownika a Win32k w trybie kernela, kierowane poprzez sterownik WineNT powinny zapewnić większą wydajność, w porównaniu do ich odpowiedników z WINE.

Moduł zarządzania pamięcią

Prace Arta Yerkesa nad modułem pamięci cache nabrały niesamowitego tempa w przeciągu ostatnich kilku miesięcy, szczególnie re-implementacja i upraszczanie licznych, zapuszczonych funkcji. Dobrym przykładem będzie balancer, decydujący o wyborze stronic do zapisu na dysk. Innym, równie intensywnie rozwijanym sub-modułem cache jest funkcja zapisująca stronice, która zaczęła działać poprawnie, gdy Arty uprościł sposób w jaki miała ona rezerwować zasoby podczas operacji stronicowania. Gdy menedżer stronicowania musi wyeksmitować stronicę, by zrobić miejsce na nowe dane, spróbuje znaleźć taką, która nie była ostatnio modyfikowana, tudzież nie była "brudna", tak by zminimalizować ilość danych do zapis na dysk. Pomocne jest zatem regularne zapisywanie "brudnych" stronic, gdy system nie jest obciążony i między innymi tym zajmuje się menedżer stronicowania. Do niedawna ta funkcja w ReactOS nie pracowała jak należy, głównie z powodu zbyt skomplikowanego algorytmu do synchronizacji podczas operacji na pamięci.

Początkowo, kod zarządzania pamięcią ReactOS był niezwykle uproszczony. W miarę prac, dodawano coraz więcej kodu, by zapobiec lub przełamywać stan blokad, jak i do samego zarządzania zasobami. Dobrym przykładem będą pageops, reprezentujące stan funkcji obsługującej błędy, podczas przetwarzania określonego adresu w określonym procesie. Art nie znał nikogo, kto by używał tego podejścia, najprawdopodobniej autorem był Dawid Welch, poprzedni główny deweloper kernela. Niestety, implementacja użyta w ReactOS wymagała powielenia znacznych ilości kodu w funkcji obsługującej błędy, tak by mogła śledzić co pozostałe funkcje o podobnej funkcjonalności robią lub do czego uzyskały dostęp. Art usunął pageops ze swojej kopii roboczej, zastępując je prostszym mechanizmem, który miał wyłącznie uniemożliwić dostęp innych procesów do wrażliwych obszarów pamięci, bez uprzedniego wywołania. Mimo, że bardzo uproszczone, ten sposób radzenia sobie ze współdzieleniem dostępu jest najłatwiejszy do zaprogramowania i najbardziej niezawodny. W tym momencie ReactOS bardziej potrzebuje stabilności i poprawności, niż jakiś iluzyjnych optymalizacji.

Istotną modyfikacją, wprowadzoną przez Arta, była zmiana sposobu w jaki mechanizm stronicowania decydował, które strony mają zostać wyrugowane na dysk, w momencie gdy zabraknie pamięci RAM. Jeśli system wymaga większej ilości stronic trybu użytkownika, niektóre z tych właśnie stronic będą musiały zostać wyrzucone na dysk. Do tej pory kolejne zapytania kończyły się wzajemnym wyrzucaniem z powrotem na dysk stronic, które dopiero co zostały do pamięci wczytane, co powodowało znaczące spowolnienie pracy systemu przy pewnych operacjach. Mechanizm stronicowania zaimplementowany przez Arta jest znacznie bardziej elastyczny, co pozwoli unikać podobnych problemów.

Na równie poważny problem Art natrafił przy okazji mapowania sekcji i stronic. Sekcjami nazywamy pewne abstrakcyjne struktury pamięci, złożone z wielu stronic. Jak dotąd, jedynym sposobem sprawdzenia, do której sekcji należy dana stronica, była kontrola przestrzeni adresowej, do której zmapowana była dana sekcja. W pewnych sytuacjach jednak, sekcje nie są mapowane do przestrzeni adresowych, co znacznie komplikuje proces stronicowania. Art zdołał obejść problem za pomocą paru parę bitów, pożyczonych z jednej ze struktur danych, używanej w Menedżerze Pamięci.

Podsumowując, prace Arta przyczynią się do znacznej poprawy niezawodności systemu ReactOS, na razie wyłącznie w jego gałęzi kodu. Stronicowanie jest procesem niezwykle istotnym do radzenia sobie z sytuacjami, gdzie system wymaga więcej pamięci, niż ma fizycznie do dyspozycji. Do tej pory ReactOS radził sobie z tym procesem bardzo źle, zarówno z perspektywy wydajności, jak i integralności danych. Dzięki Artowi, ReactOS może zadziałać nawet na systemie z 32 MB pamięci RAM. Jest to granica, której przekroczenie jest prawie niemożliwe, ze względu na miejsce jakie musi w pamięci zajmować kod, bez którego system w ogóle nie może funkcjonować. Z tak niewielką ilością pamięci i tak ciężko będzie uruchomić cokolwiek poza ReactOSem.

Wsparcie Ext2

Dzięki postępującym pracom nad kontrolerem pamięci cache, Art był w stanie wystartować ReactOS z partycji Ext2 i następnie używać jej. Instalator sam w sobie wciąż nie obsługuje tego systemu plików, Art musiał więc ręcznie przenieść system na partycję a następnie uruchomić Freeldr za pomocą GRUB. Poza pracą Pierre Schweitzera nad biblioteką Runtime systemu plików, Art potrzebował dodać jedynie kilka drobiazgów. Najprostszy z nich, dodać w zarysie 'Opportunistic locking' (tzw oplocki), z funkcjonalnością opartą na sieciowych systemach plików. W rzeczywistości żadne nie-sieciowe systemy plików z nich nie korzystają, ale Matt Wu, autor sterownika Ext2, użytego przez Arta, bardzo dokładnie przestrzegał zasad wedle których tworzy się takowe systemy, zawierając w sterowniku również oplocki. Czyni to ów sterownik tym bardziej wartościowym dla naszego projektu, umożliwiając bardziej rygorystyczne testy poprawności. Pozostałymi, brakującymi elementami były bloki kontroli pamięci i blokady zakresów. Oba związane są z mapowaniem bloków systemu plików do fizycznych bloków na dysku. Do pełnej funkcjonalności wciąż brak wsparcia ze strony instalatora, jak również bootloader'a. Niniejszy eksperyment stanowi bardzo istotny krok na drodze do wsparcia bardziej skomplikowanych systemów plików, a tworzony właśnie od nowa sterownik FAT z pewnością skorzysta z dodanych tu przy okazji funkcjonalności. W dalszym ciągu prace Arta są ograniczone do jego gałęzi kodu, jeszcze trochę czasu upłynie, zanim dotrą one do wydań ReactOSa.