Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 69

Biuletyn 69

by Z98 on 2010-03-03
translated by Haos on 2010-03-04

Obsługa pułapek

Jednym ze sposobów na niskopoziomową komunikację ze sprzętem jest użycie przerwań i wyjątków. Wymaga to wyspecjalizowanego kodu, wchodzącego także w skład modułu obsługi pułapek (ang. Trap handling). Słowem wyjaśnienia, pułapka jest to specjalny przypadek synchronicznego przerwania, zwykle wywoływanego przez krytyczny błąd (jak chociażby dzielenie przez zero). Wywołanie pułapki powoduje przejście z trybu użytkownika w tryb kernela, gdzie system operacyjny wykonuje zdefiniowaną uprzednio dla danego przypadku operację a następnie powraca do trybu użytkownika. Do tej pory, moduł ten w ReactOS napisany był w całości w asemblerze, jako, że język ten umożliwia przeprowadzanie operacji, dla których w czystym C nie ma zdefiniowanych metod. Do takich zaliczyć można m.in. manipulacje stosem, czy też zapis i odczyt określonych rejestrów – z definicji są to operacje specyficzne dla danej architektury procesora, próba przepisania ich na C nie dałaby wcale kodu uniwersalnego dla wielu architektur. W ramach projektu konwersji ReactOS na procesory ARM, odpowiedzialna za tenże projekt ekipa (tak zwani, „Arm Ninjas”) postanowiła stworzyć dla opisywanego modułu prostą warstwę abstrakcji i podłączyć do niej kod specyficzny dla architektury procesora, przepisany przy użyciu GCC intrinsics. Jest to zestaw specyficznych makr kompilatora, umożliwiających programiście precyzyjne wyznaczenie konkretnych funkcji asemblera, jakie kompilator ma użyć, jeszcze na poziomie języka C. W zamierzeniu miało to ułatwić zarówno kontrolę kodu jak i poprawia jego czytelność a w rezultacie przyniosło wymierne efekty w postaci naprawy kilku niedostrzeżonych do tej pory błędów. Mimo, że plan ekipy ARM nie wymagał od nich takiego podejścia, uznali, że przyniesie ono rozliczne korzyści całemu projektowi ReactOS. Niestety, zastosowane przez nich intrinsics w wersji GCC w perspektywie wykluczały kompilację tego modułu pod MSVC. Poprzedni kod czystego asemblera mógł być jeszcze skompilowany pośrednio do obiektów binarnych, z którymi MSVC mógł sobie poradzić. W tym momencie na scenę wkroczył Timo Kreuzer, z nieoczekiwanie prostym rozwiązaniem problemu – zamiast intrinsics użył z powrotem czystego asemblera. Na pierwszy rzut oka może wydawać się to powrotem do stanu początkowego, tym razem jednak zmiany Timo objęły wyłącznie kod już podłączony do wspomnianej wcześniej warstwy abstrakcji. Jedyną zmianą, zatem było porzucenie intrinsics w wersji GCC na korzyść czystego asemblera. Pozwoliło to połączyć najlepsze cechy obu rozwiązań (przejrzystość i czytelność warstwy abstrakcji w C z koniecznym kodem asemblera, niezależnym od użytego kompilatora) likwidując jednocześnie ich wady. Przy okazji udało mu się poprawić ustawienia flag i segmentów oraz sposób przekazywania parametrów przez rejestry, ze specyficznych dla GCC na uniwersalne. W teorii powinno to umożliwić asemblację kodu nawet w asemblerze Microsoftu.

ACPI

Advanced Configuration and Power Interface jest standardem, opisującym funkcje zarządzania energią przez komputery PC. Prace nad nowym kodem ACPI dla naszego systemu podjął Samuel Serapion, znany bardziej, jako deweloper podprojektu ReactOS x64 i mniej, jako drugi autor naszych biuletynów. Sam wykorzystał referencyjną implementację dostarczaną wraz ze standardem, przepisując ją na postać wykonywalną przez NT. Natrafił przy tym na poważny problem, związany z reprezentacją identyfikatorów sprzętu, przez co moduł ACPI nie chciał działać. Z pomocą przyszedł Cameron Gutman, czołowy deweloper stosu sieci, znajdując i poprawiając problem. Mimo, że moduł ACPI nadal nie jest ukończony, w szczególności brakuje obsługi kilku pakietów IRP (ang. I/O Request Packet), generowanych przez ACPI, Cameron umożliwił Samowi dalszą pracę nad swoim kodem.

Pliki nagłówkowe dla sterowników Windows

Od dłuższego czasu poszczycić się możemy się dobrą komunikacją jak i pewnymi formami współpracy z projektem Mingw64. Od tygodnia współpraca ta przeszła na nowy, wyższy poziom. Z Amine Khaldi, który jak dotąd prócz drobnych, lecz istotnych poprawek w kodzie, opiekował się głównie Bugzillą, skontaktował się Kai Tietz, z pytaniem czy nasz projekt nie byłby zainteresowany kooperacją przy poprawie plików nagłówkowych Windows w Mingw64. W przeważającej większości nasze pliki nagłówkowe są zgodne z oryginałem, a przynajmniej bardziej kompletne, jednak nie wszędzie poprawnie ustrukturyzowane. Amine i Kai mają nadzieję na wprowadzenie właściwej separacji i struktury we wspólnych, po zakończeniu tej operacji, plikach nagłówkowych. Zostanie ona przeprowadzona w odgałęzieniu repozytorium, tak by uniknąć jakichkolwiek przestojów w pracach na repozytorium głównym. Nieoczekiwanie, również Timo Kreuzer i Aleksiej Bragin dołączyli do prac. Timo ma nadzieję na stworzenie mechanizmu automatycznej generacji publicznych plików nagłówkowych, bardzo podobnie do użytej przez Microsoft w przypadku ich WDK i SDK. W przypadku powodzenia tego planu, nic nie stoi na przeszkodzie stworzenia naszego własnego DDK (Driver Developing Kit) dla Windows, zgodnego z oryginalnym, autorstwa Microsoftu. Nie rozwiąże to wprawdzie istniejących wciąż problemów GCC z kompilacją sterowników NT, głównie z powodu brakującego wsparcia dla SEH, ale i tak stanowiłoby istotny punkt wyjścia.

ReactOS na Dniach Linuxa w Chemnitz

Możecie spodziewać się licznej reprezentacji Ekipy ReactOS w trakcie Dni Linuxa w Chemnitz, między 13 a 14 marca. Zjawią się tam w celu promocji naszego projektu, będą odpowiadać na wasze pytania i postarają się nawiązać nowe kontakty we wspólnocie Open Source.