Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 74

Biuletyn 74

by Z98 on 2010-07-09
translated by Haos on 2010-07-11

top

Z różnych dziedzin

---

Wysiłki Amine Khaldiego, zmierzające do uporządkowania plików nagłówkowych w sterownikach, zaczęły wreszcie przynosić wymierne rezultaty. Oprócz wyczyszczenia nagłówków w dużej części sterowników, możliwe stało się wreszcie kompilowanie tychże nagłówków nie tylko w GCC, ale i w MSVC. Każdy, kto choć raz zetknął się z problemem stworzenia wieloplatformowego kodu C, zdaje sobie sprawę z licznych acz subtelnych różnic w dopuszczalnej przez oba te kompilatory składni, podnoszących znacznie poziom trudności stworzenia takiego kodu. Prace Amine nie tylko ułatwiły integrację z ReactOS nowo-tworzonych dlań sterowników ale również wyeliminowały kilka błędów kompilacji kernela ReactOS pod ARM.

Ekipa ReactOS od pewnego czasu zaabsorbowana jest problemami z DNS naszej strony, jak i serwerem oficjalnego BuildBota. Problemy z DNS jak dotąd udawało się rozwiązać dość sprawnie, dzięki czemu usługi są znów dostępne poprzez swoje nazwy domen. Z drugiej strony serwer BuildBota doznał dość poważnej awarii, związanej z jego procesorami, przez co nie był dostępny dobrych kilka dni. Testerzy, pozbawieni podstawowego źródła wersji instalacyjnych ReactOS dla każdej rewizji, zmuszeni byli zorganizować zastępcze rozwiązanie. Na szczęście udało się w tym celu wykorzystać testowy system BuildBota, postawiony przez Olafa Siejkę i działający już od kilku miesięcy. Wersje instalacyjne ReactOS z tego systemu dostępne są na stronie Samuela Serapiona, http://encodedpr.com

top

Yarotows

---

Akronim od “Yet Another Rewrite of the Old Win32 Subsystem” to doskonała nazwa gałęzi kodu, nad którą Jérôme Gardou i Timo Kreuzer pracują od wielu miesięcy. Wszystko zaczęło się od projektu Timo, dotyczącego poprawki kodu, odpowiedzialnego za wykorzystywanie sterowników grafiki przez podsystem Win32, prowadząc w rezultacie końcowym do sporego projektu poprawek w implementacji tegoż podsystemu. Bez tych poprawek ReactOS nie był w stanie dokonać chociażby tak elementarnych czynności, jak zmiana rozdzielczości czy ilości wyświetlanych na ekranie kolorów, bez konieczności restartu systemu. Mówi się, że inspiracją dla YAROTOWS było sceptyczne nastawienie kilku deweloperów do ARWINSS, gdyż zakres koniecznych zmian wykluczał możliwość przeprowadzenia ich na głównym drzewie kodu, ze względu na ryzyko istotnych regresji w funkcjonowaniu ReactOS. Na szczęście użycie gałęzi kodu w SVN umożliwia prace nad długo wyczekiwanymi poprawkami istotnych części systemu, bez ryzyka zepsucia głównego drzewa i zablokowania prac innych deweloperów.

W Windows, struktura GRAPHICS_DEVICE używana jest dla udostępnienia każdego obecnego urządzenia karty graficznej. Same urządzenia mogą wspierać wiele trybów graficznych za pomocą, których tworzą obraz przy użyciu różnych technik a te z kolei są udostępniane przez sterowniki grafiki, zarejestrowane właśnie w strukturze GRAPHICS_DEVICE. Sterowniki grafiki, jako takie, reprezentowane są przez tzw. logical device objects (LDEVOBJ), udostępniające wszystkie tryby wspierane przez sterownik, jaki reprezentują. Istnieją również, tzw. physical device objects (PDEVOBJ), prezentujące obecnie wykorzystywany tryb sterownika i udostępniające powierzchnię, na której dany sterownik rysuje obraz. Podsystem Win32, podczas swojej inicjalizacji przeszukuje rejestr w poszukiwaniu urządzeń graficznych i tworzy osobną strukturę, GRAPHICS_DEVICE, dla każdego z obecnych. Następnie, wybierany jest tryb i ładowany jest odpowiedni dla niego LDEVOBJ i PDEVOBJ. Podsystem Win32 w głównym drzewie ReactOS jednak nie miał zaimplementowanego LDEVOBJ, co sprawiało, ze cały mechanizm ładowania sterowników grafiki był kompletnie źle zaprojektowany, co również uniemożliwiało zmianę rozdzielczości bez restartu, gdyż tryb pracy winien być śledzony właśnie przez LDEVOBJ. Konieczne było napisanie od nowa całego mechanizmu ładowania sterowników, co będąc samo w sobie bardzo trudnym zadaniem, doprowadziło do licznych błędów i regresji, ale z drugiej strony zwiększyło w kolejnych krokach kompatybilność podsystemu Win32 w ReactOS z oryginałem.

Błędy, ujawnione przez poprawną implementację mechanizmu ładowania sterowników, pojawiły się dopiero teraz, gdyż poprzednia implementacja była zbyt uproszczona i nieprawdziwa, by dotrzeć do tego miejsca. Na szczęście MSDN okazał się ponownie nieocenionym źródłem informacji, ujawniając prawidłowy sposób, w jaki należy przeprowadzać operacje na sterownikach, umożliwiając również zapełnienie dziur w naszej implementacji. Dużym problemem było właściwe zapewnienie dostępu do powierzchni dla rysowania. Kontrola dostępu w tym miejscu jest konieczna, gdyż dopuszczenie dwóch różnych obiektów do rysowania na jednej powierzchni w tym samym czasie może doprowadzić do poważnych problemów. Zmiana trybu, podczas gdy jakiś obiekt rysuje na powierzchni także rodziłoby poważne konsekwencje, jako że właściwości powierzchni uległyby wówczas zmianie. W poprzedniej implementacji używano dwóch blokad, jednej dla powierzchni a drugiej na kontekście urządzenia. Mimo, iż takie rozwiązanie chroniło wprawdzie przed równoczesnym rysowaniem na powierzchni przez dwa obiekty, to zupełnie nie sprawdzało się w przypadku rysowania przy zmianie trybu. Blokada na powierzchni w tym przypadku zmieniała się w blokadę na PDEVOBJ, która uzyskana przez cokolwiek podczas zmiany trybu sprawiała, iż żaden obiekt nie mógł już korzystać z PDEVOBJ ani z przypisanej do niego powierzchni. To, że do tej pory raczej nikt się z tym problemem nie zetknął, wynika wyłącznie z faktu, iż nikomu wcześniej nie udało się zajść tak daleko ze zmianą trybu, by wywołać globalną blokadę systemu. Co ciekawe, wystarczyło zdjąć blokadę z powierzchni rysowania i pozostawić jedynie tą na PDEVOBJ, by rozwiązać ten problem i zabezpieczyć przed wielokrotnym rysowaniem.

YAROTOWS ujawnił jeszcze inny problem, związany z paletami kolorów. Palety to nic innego jak mapowanie liczb, zapisanych na powierzchni rysowania w postaci bitów, do określonej wartości koloru. Ich implementacja w ReactOS pozostawała wiele do życzenia i brakowało w niej funkcjonalności niezbędnej dla zmiany trybów. Jak można się było spodziewać problem sprawiały tutaj zmiany trybu, w którym prócz rozdzielczości ekranu zmianie ulegała liczba wyświetlanych kolorów, co winno wywołać również analogiczną zmianę palety przypisanej do PDEVOBJ. Taka zmiana jednak nie zachodziła, a powierzchnia rysowania, opierając się na nieodpowiedniej palecie w PDEVOBJ wyświetlała kompletnie nieprawidłowe kolory. Rozwiązanie tej kwestii oparło się na zmianie przypisania palety z PDEVOBJ do powierzchni rysowania, tak by paleta ulegała zmianie przy zmianie liczby wyświetlanych kolorów.

Poza nowymi, deweloperzy pracujący nad YAROTOWS musieli uporać się również z garścią o wiele starszych problemów. W określonej sytuacji Win32k mógł znaleźć się w sytuacji, w której różne wątki dążyłyby do uzyskania wyłącznych blokad na tych samych kilku obiektach, w różnej kolejności. Doprowadziłoby to do globalnej blokady systemu, gdyż żaden z wątków nie wypuściłby już uzyskanej blokady wyłącznej. Nieważne jak rzadka byłaby to sytuacja, nie wolno dopuścić do tego, by stabilność systemu zależała wyłącznie od tego czy takowa się zdarzy czy nie. Zastosowane rozwiązanie zmieniało sposób uzyskania blokady wyłącznej, zaprojektowany tak, by wykluczyć przedstawiony wyżej scenariusz. YAROTOWS poprawia również znacząco wydajność rysowania. Bitmapy do tej pory były alokowane z puli stronicowanej, której nigdy nie jest zbyt wiele dostępnej. W gałęzi, Win32 alokuje w tym celu pamięć ogólną systemu. Windows wprawdzie w tym przypadku korzysta z pamięci danej sesji, ale ze względu na bardzo szczątkową implementację sesji w ReactOS, takie rozwiązanie musi na razie wystarczyć. Mimo wszystko, kolejny komponent nie musi już korzystać z puli stronicowanej.

top

Korupcja pamięci

---

Nie tak dawno jeszcze Aleksiej Bragin zaimplementował mechanizm kontroli integralności puli pamięci, w celu wykrycia i usunięcia błędów, prowadzących do korupcji danych. Mechanizm ten dodawał obszar przed i za każdą alokacją w puli pamięci, następnie sprawdzał czy zapis na danej alokacji nie wychodził na dodany obszar. Niestety, mechanizm ten już nie działa poprawnie, ze względu na liczne zmiany w menedżerze puli pamięci. Obecnie Michael Martin stworzył inne rozwiązanie, wyłącznie dla puli pamięci niestronicowanej. Rozwiązanie Michaela polega na wykorzystaniu QEMU i podłączonego doń GDB w celu kontroli dostępów do pamięci. Michael zmodyfikował QEMU tak, by ten rejestrował i kontrolował każdy blok pamięci w ReactOS, którego adres wskazuje na alokację z puli pamięci. Kiedy tylko jakiś kod dotykał puli pamięci niestronicowanej, Michael sprawdzał listę zapisanych adresów, by sprawdzić czy operacja miała miejsce na właściwym bloku. Nie trzeba wyjaśniać jak bardzo spowolniło to pracę systemu, sprawiając, że ReactOS potrzebował ponad pięciu minut na uruchomienie się do GUI. Jeśli tylko Michael wykrył nieprawidłowy dostęp do pamięci, wywoływał z QEMU blokadę systemu i przejście do GDB, gdzie mógł spokojnie przeanalizować zdarzenie i wykryć sprawcę.

Jak dotąd Michael wykrył przynajmniej cztery błędy w kodzie, wywołujące korupcję niestronicowanej puli pamięci, z których trzy pochodziły z jego własnych fragmentów kodu. Jednym z nich związany był z poprawką w obiegu wiadomości, wspomnianej w Biuletynie 72, gdzie w dalszym ciągu zapisywane były identyfikatory tych wiadomości, które nie przechodziły przez obieg wiadomości. Dwa kolejne problemy zlokalizowane były w nowym kodzie USB Michaela – literówka oraz błąd w obliczeniach przesunięcia. Te trzy błędy zostały już naprawione. Ostatnim z nich jest błąd w UniATA i nad tym Michael nadal pracuje.

Odmiennym źródłem korupcji pamięci był stos dźwięku, testowany na prawdziwym sprzęcie. Testy polegały na użyciu natywnych sterowników do sprawdzanych urządzeń i próbie odtwarzania dźwięku, co jednak bardzo często wywoływało kraksy systemu, związane z korupcją pamięci. Johannes Anderwald nadal nie jest w stanie znaleźć przyczyny, szczególnie, że dany problem nie ujawnia się na QEMU, nie da się, zatem skorzystać z mechanizmu Michaela.

Przypisek od tłumacza: Z98 pomija niestety przyczynę, dla której Michael zabrał się za lokalizowanie przyczyn korupcji pamięci. Kod za nie odpowiedzialny pojawił się w drzewie już jakiś czas temu, ale do tej pory problemy z nim związane były po prostu dobrze ukryte. Niedawno jednak Sir Richard z Arm Ninjas ukończył i dodał do drzewa nowy mechanizm zarządzania puli pamięci, o którym mowa w pierwszym akapicie. Bazujący na pracach Aleksieja Bragina i ulepszony, przez Arm Ninjas, ów menedżer puli pamięci dość rygorystycznie nadzorował stan jej poprawności. Tam, gdzie wcześniej korupcja przechodziła niezauważenie, wywołując problemy w ukryciu, teraz menedżer puli obwieszczał to wszem i wobec, wyrzucając systemowy kod błędu (BugCheck) 0x00000019. Michael na oba błędy z USB, teraz zawieszające system, natrafił podczas prac na swojej implementacji USB. Błąd w obiegu wiadomości natomiast był ciężki do replikowania, pojawiając się najczęściej na starcie serii testów przeprowadzanych przez nowy system BuildBot (wspominany w pierwszej części biuletynu), nadzorowany przez niżej tu wymienionego, waszego uniżonego tłumaczącego sługi, który to składa po raz kolejny wielkie podziękowania Michaelowi, który jako jeden z nielicznych zgodził się tym problemem zająć, jak widzimy z wielkim pożytkiem dla systemu.

top

Filesystem Notifications

---

Pierre Schweitzer od dłuższego czasu zajęty studiami i swoją pracą nad systemem plików w ReactOS niedawno powrócił do aktywności w wielkim stylu. Wysłał do drzewa kodu efekt swojej wielomiesięcznej pracy nad powiadomieniami systemu plików. Brak tej funkcjonalności odpowiadał za wiele problemów w systemie, głównie w jego powłoce. Najwyraźniej widać to przy deinstalowaniu aplikacji, kiedy to powłoka powinna być powiadomiona o skasowaniu katalogu z aplikacją. Dzieje się to, gdy system plików wysyła powiadomienie do powłoki o skasowaniu danego katalogu, co oczywiście w ReactOS do tej pory nie mogło mieć miejsca. Inne możliwe problemy były do tej pory maskowane przez błędy w innych fragmentach systemu. Istnieją generalnie dwa rodzaje powiadomień, jedne przechodzące z Plug&Play, informujące system o stanie partycji dyskowych, na przykład w przypadku montowania i domontowywania pamięci USB. Drugi rodzaj powiadomień tyczy się zmian zawartości katalogów.

Z tych dwóch rodzajów, Pierre zdołał częściowo zaimplementować zmiany stanu partycji. Wymagały dużo większego wysiłku, z powodu problematycznego stanu podsystemu PnP w ReactOS. Wszystkie powiadomienia, wysyłane do nasłuchujących je programów, przechodzą przez menedżer PnP. Kiedy program informuje system operacyjny, że chce otrzymywać powiadomienia o zmianie stanu, to właśnie menedżer PnP otrzymuje taką rejestrację i obsługuje listę zainteresowanych obiektów.

Powiadomienia o stanie plików nadal wymagają znacznej pracy, jednakże Pierre zdołał już stworzyć podstawy ku temu. W biuletynie 51 jest mowa o bibliotece File System Runtime Library, również tworzonej przez Pierre. Jednym z zadań FsRtl jest wstępne obsługiwanie powiadomień, zarówno stanu plików jak i woluminów. Miejsce przeznaczenia powiadomień zależy już od ich typu: stan woluminów obsługuje PnP, a plików – FsRtl. Gdy zarejestrowały się w celu otrzymywania powiadomień o zmianie stanu, sterownik systemu plików wysyła I/O Request Packet (IRP) z informacją, o czym dany program chce być powiadamiany. Sterownik wówczas rejestruje te powiadomienie na liście, utrzymywanej przez FsRtl, która jest parsowana w poszukiwaniu zainteresowanych, gdy dany plik ulega zmianie. W przypadku znalezienia właściwego wpisu na tejże liście, FsRtl dodaje odpowiednie informacje i zwraca, zakańczając IRP. Pierre obecnie ma dokończoną część rejestracji powiadomień, pracując nadal nad właściwym wysyłaniem powiadomień. Po ukończeniu tegoż Pierre planuje zająć się kolejnymi problemami, jakie ReactOS ma z systemem plików.

top