Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 71

Biuletyn 71

by Z98 on 2010-04-22
translated by Haos on 2010-04-28

Stos NT USB

Zanim pojawiła się Vista, w architekturze USB zawarty był niskopoziomowy sterownik - usbport. To właśnie ten sterownik tworzył obiekty urządzenia dla każdego kontrolera USB i odbierał IRP (I/O Request Packet). W zależności od rodzaju kontrolera, usbport mógł wywołać jeden z trzech sterowników pomocniczych: usbehci, usbohci lub usbuhci. Pakiety IRP wysyłał usbhub, a wszystkie te komponenty tworzyły razem niskopoziomową część stosu USB. Większość sterowników USB, dystrybuowanych przez firmy dla ich produktów działa ponad tymi sterownikami, korzystając z biblioteki wsparcia - usbd. Bez tychże komponentów niskiego poziomu, klienckie sterowniki USB od producentów nie będą działać.

Michael Martin zajął się stworzeniem wyżej wymienionych komponentów niskiego poziomu do stosu USB. Obecnie stworzył już podstawowy sterownik usbehci, testując go wciąż w Windows XP, poprzez podmianę oryginalnego sterownika usbehci od Microsoftu. Pomocny okazał się kod pvdrivers, zawarty w Xen, chociaż nie zawiera on kompletnej implementacji sterowników niskopoziomowych. Bardzo rzadko producenci urządzeń USB muszą re-implementować coś, co już zawarte jest w systemie. Jak dotąd, sterownik Michaela z powodzeniem komunikuje się z Menedżerem PnP w Windows XP, jednak sam w sobie jest tylko pojedynczym elementem układanki, będącej kompletnym stosem USB.

Narzędzia do kompilacji

Budując jakikolwiek obiekt, kompilator GCC dodaje podkreślnik przed sygnaturą funkcji, czego wymaga linker. Blokuje to niestety możliwość linkowania z obiektami stworzonymi przez kompilator C/C++ Microsoftu, który Timo chce zastosować dla swojego odgałęzienia kodu (x86-64). Potencjalnym rozwiązaniem jest użycie flagi konfiguracyjnej -fno-leading-underscore - co wyłącza dodawanie podkreślnika, ale zmusza do zastosowania tej samej flagi w linkerze, a także budowanie w GCC wszystkich pozostałych obiektów z tą właśnie flagą. ReactOS używa wielu prekompilowanych bibliotek C++ w samym środowisku kompilacji (Build Environment), które do tej pory nie zawierały tej flagi. Poprawne rozwiązanie tego problemu wymagałoby zmian w GCC jak i w binutils, w postaci stosownych łatek kodu. Kai Tietz z projektu MinGW-w64 dostarczył stosownych poprawek, umożliwiając Timo Kreuzerowi usunięcie używanych do tej pory niekompletnych i nie do końca poprawnych rozwiązań.

Poza poprawianiem plików nagłówkowych, Amine Khaldi pracuje równolegle nad użyciem kompilatora LLVM z Clang do kompilacji ReactOS. W dalszym ciągu liczne błędy w Clang, z ktorych część Amine raportuje tutaj, uniemożliwiają jego użycie w tym celu. Dwa z nich już zostały naprawione, w przypadku pozostałych Amine pozostaje w kontakcie z deweloperami Clang, pracując nad ich rozwiązaniem. Jak wiadomo, możliwość użycia więcej niż jednego kompilatora zawsze jest wartością dodaną. Na listach dyskusyjnych Clang/LLVM pojawiły się też dyskusje, dotyczące perspektyw zapewnienia wsparcia dla SEH (Structured Exception Handling), które jak dotąd istnieje przede wszystkim w kompilatorze Microsoftu. Bez jakiegokolwiek wsparcia dla SEH, użycie Clang/LLVM dla kompilacji ReactOS nie ma większego sensu. Ostatecznie możliwe jest przeniesienie biblioteki Portable SEH, autorstwa KJK::Hyperion, wiązałoby się to jednak ze stworzeniem osobnej jej wersji, gdyż mechanizmy użyte w obecnej wersji PSEH nie zadziałałyby poprawnie w Clang/LLVM.