Jak niektórzy z Was wiedzą, weteran i jeden z głównych deweloperów Haiku Michael Lötz, znany w społeczności Haiku jako mmlr, zaczął prace nad systemem Haiku w ramach swojego kontraktu. Michael zamierza w przyszłości zamieszczać krótsze notki z podsumowaniem swoich postępów, ale tym razem postanowił napisać dłuższy artykuł, bo wiele się wydarzyło.
Wpa_supplicant
Został dokończony port Wpa_supplicant, dzięki czemu w Haiku działa szyfrowanie Wi-Fi. Wpa_supplicant jest odpowiedzialny za obsługę uwierzytelniania i zarządzania kluczami w sieciach bezprzewodowych. mmlr nie jest pewny czy kod źródłowy Wpa_supplicant nie był przypadkiem przenoszony kilka razy, w każdym razie Michael otrzymał tę wersję której nie dokończył Axel Dörfler, podczas swojego zeszłorocznego kontraktu. Ze względu na brak czasu to przez kilka miesięcy, nie było przeprowadzanych żadnych prac nad tą funkcjonalnością, do czasu aż zaczął przy tym dłubać Fredrik Holmqvist. Sytuacja znowu się powtórzyła, na szczęście mmlr dokończył nad tym prace dzięki hojności społeczności Haiku. Przy okazji zdradził także, że już w lipcu nad tym siedział i miał kilka w miarę działających wersji, ale historia znów zatoczyła koło…
Dla Michaela było oczywiste, że swoja prace podczas kontraktu rozpocznie od dokończenia tego. Poprzednie wersje nie działały stabilnie, bo wymagały lepszej integracji z Haiku. Trzeba nam wiedzieć, że Wpa_supplicant to typowa unixowa aplikacja. W tym kontekście oznacza to, że cały program jest napisany w taki sposób, że opiera się on na jednym uruchomionym procesie w danym czasie. Działa też w klasycznej pętli zdarzeń, czyli pracuje wtedy kiedy ma wskazane zadanie przez sygnały, lub dane oczekujące w kolejce. Przy tym założeniu jest bezpieczne tylko zmodyfikować prawie wszystkie dane wykonywane bezpośrednio, ponieważ nie musisz się martwić, że coś działa na tych samych danych, że inny proces je wykorzystuje w tym samym czasie. Na przykład można zmienić listę skonfigurowanych, wykrywanych i aktywnych sieci bez konieczności synchronizacji tych zmian z niczym innym. W przypadku Haiku podstawowa koncepcja jest zupełnie inna, bo większość rzeczy jest wielowątkowa, lub bazuje na zdarzeniach. Prawie wszystko jest zatem wstanie wykorzystać wiele wątków, czy też operować na wspólnych danych i prawidłowo obsługiwać modyfikacje tych danych.
Można łatwo się domyślić co się stanie, kiedy do wpa_supplicant zaczną nadchodzić powiadomienia z sieci i żądania z różnych wątków, na kod który tak naprawdę nie został do tego obmyślany, zaprojektowany. Jako, że wpa_supplicant przez większość czasu po prostu oczekuje na wydarzenia, to rzeczywiście działa przez większość czasu, dopóki nie zostaną zmodyfikowane krytyczne dane. I taki był stan kodu, kiedy stworzył z tego samodzielną paczkę w lipcu. Cóż, przez większość czasu to dobrze działało, ale jeśli coś uzyskało czasowe uprawnienia( o co nie było trudno), to wpa_supplicant zawieszał się lub przestawał działać. By móc uzyskać stabilne działanie, trzeba było to jakoś zintegrować.
Istnieją zasadniczo dwie możliwości w takie sytuacji. Albo “asymiluje się” kod i restrukturyzuje go tak, by mógł działać w środowisku wielowątkowym, bądź sprawić by Haiku obchodziło część rzeczy i oznaczało je tak, że kod wpa_supplicant będzie działać tak jak na innych platformach. Fajnie by było mieć pierwszą opcję, ale ona wiąże się z ogromnym nakładem pracy( kod wpa_supplicant jest bardzo obszerny). Poza tym utraciło by się możliwość korzystania z oryginalnego kodu i trzeba byłoby dopisać specyficzne dla Haiku rzeczy. Następnie musiano by utrzymywać fork wpa_supplicant i samemu dodawać poprawki, aktualizacje z oryginalnego kodu. W dłuższej perspektywie jest to kosztowne i podatne na błędy.
Zamiast tego skorzystał z drugiej opcji. Zasadniczo mamy teraz obsługiwane wszystko co przychodzi, powiadomienia sieci, żądania dołączenia/opuszczenia i inne zdarzenia, wszystko to zostało oznaczone “do zrobienia” w jednej kolejce. Pętla zdarzeń wpa_supplicant jest następnie powiadamiana o obecności żądań tak, że idzie dalej i przetwarza wszystkie z nich w jednowątkowy sposób. Choć brzmi to dość prosto, to teraz ma to swój własny zestaw problemów, które wymagały sporo pracy. Z jednej strony, nie można dokonywać żadnych synchronicznych żądań do wpa_supplicant, np. wykonywanie żądania i czekania na odpowiedź z klasy zestawu sieci( network kit), lub net_server. To dlatego, że wpa_supplicant może mieć dostęp do innych funkcji zestawu sieci( a pośrednio net_server), które same z siebie robią synchroniczne żądania i blokują całość w martwym punkcie… W końcu większość problemów została rozwiązana i teraz mamy dość stabilny komponent który działa( przynajmniej nigdy nie zawiesił mu się od tego czasu).
Kolejną sprawą jest to, że wpa_supplicant dostarczany jest teraz z GUI co ułatwia wprowadzanie danych sieciowych, takich jak nazwa sieci, metoda uwierzytelniania i ewentualnie hasło/klucz. Dzięki temu można odejść od metody edytowania pliku konfiguracyjnego w edytorze tekstowym, by móc wprowadzić te dane, które są niezbędne do obsługi szyfrowania Wi-Fi. Chodzi o to, że wpa_supplicant jest używany do zbierania tych informacji i że używa natywnego zestawu klas sieci, do przechowywania tych danych do późniejszego użytku. W następstwie tego net_server będzie w stanie zapewnić te informacje wpa_supplicant w taki sposób, że można będzie się połączyć z siecią, bez konieczności podawania kolejny raz tych samych danych. Koncepcja ta w zasadzie pozwala na konfigurację sieci w natywny sposób dla Haiku, która w użyciu jest oderwana( wyabstrahowana) od sposobu “proszącego” o te dane. W związku z tym jest możliwe, aby zastąpić korzystania z wpa_supplicant różnymi “proszącymi”( suplikantami), jeśli zachodzi potrzeba aby to zrobić. Umożliwia to także tworzenie natywnych narzędzi, modyfikowanie ich i używanie w podobnych( różnych) konfiguracjach( np. skaner sieci WLAN, który pozwala automatycznie skonfigurować sieć).
Jednym z centralnych punktów przechowywania takich konfiguracji sieci, jest oczywiście zapisywanie sieciowych danych uwierzytelniających( klucz WEP, klucz dzielony, certyfikat, kombinacje użytkownik/hasło). Bez wątpienia mogą one być zapisane jako zwykły tekst w pliku konfiguracyjnym, ale z punktu widzenia bezpieczeństwa nie jest to zalecane. Idealnie jest jak te listy uwierzytelniające są przechowywane w jednym miejscu, są zaszyfrowane i jednocześnie są wykorzystywane w innych zastosowaniach. Haiku obecnie brakuje takiej funkcjonalności znanej z innych platform, tzn. menedżera list uwierzytelniania tzw. “Keychains” i “Wallets”. Zrealizowanie tego jest priorytetem Michaela. I nie musi zaczynać od zera jak Axel Dörfler, który w tej samej sytuacji napisał zarys API, które to łączy w sobie różne koncepcje implementacji z innych platform.
W sumie wpa_supplicant jest od tej pory stabilny i powinien działać na większości kart bezprzewodowych, bo mamy sterownik bazujący na sterowniku z FreeBSD( z kilkoma wyjątkami które muszą być wyłączone ze względu na błędy). Modyfikacja kodu Haiku z wpa_supplicant jest teraz dostępna na Haiku-Ports, także jako opcjonalny pakiet do zainstalowania( w terminalu wpisać installoptionalpackage wpa_supplicant – zostanie to pobrane z serwera 😉 ). Można sobie też pobrać wcześniej z komputera, z działającym internetem. Co prawda UI tego nie jest jeszcze dokończone, ale ostatecznym celem jest to, by konfigurowanie sieci nie wymagało żadnych szczegółowych instrukcji.
Od tłumacza: Póki nie ma menedżera haseł, to trzeba będzie wpisywać hasło za każdym razem kiedy chcemy się połączyć. Jest to niewygodne, więc możemy sobie to ułatwić wpisując hasło na stałe w /boot/common/settings/network/wireless_network – plain-text niestety. Plik musi mieć poniższy format:
network SSID_sieci{
authentication wep|wpa|wpa2
password mojehaslo
}
Dzięki temu uzyskamy automatyczne połączania się z siecią.
Ja tak nie musiałem robić, bo używam graficznego konfiguratora ustawień sieci, w ustawieniach systemowych. Ale mam niezaszyfrowaną sieć, admin filtruje po adresie MAC.
Możemy także łączyć się z siecią za pomocą konsoli systemowej. Więcej dowiemy się z lektury tego artykułu, dotyczącego łączenia się z siecią Wi-Fi w Haiku. To jest bardziej archiwalny artykuł, ale może okazać się czasem pomocny.
Inny użytkownik mnie powiadomił, że już jest GUI do tego :).
Thinkpad
Możecie być ciekawi co się jeszcze wydarzyło, więc mmlr kupił sobie nowego laptopa. Jego poprzedni notebook pochodził ze stajni HP i cechował się niezwykle małowydajnym, niskonapięciowym procesorem… Większosć swoich prac przy Haiku wykonywał właśnie na nim. Teraz posiada ThinkPad’a X1 który kupił sobie za pieniądze uzyskane z kontraktu. Poprzedni komputer był dobry do zwykłego użytkowania, ale okazał się strasznie niewygodny w pracy przy systemie operacyjnym. Stało się jasne, że jest mu potrzebny nowy sprzęt.
Obecny laptop ma procesor i5 2.5 GHz( Sandy Bridge) i zintegrowaną kartę graficzną Intela. Ma także kilka innych udogodnień, które są mało istotne z jego punktu widzenia. Ale wybierając sobie nowego notebooka, to kierował się dobrą współpracą z otwartoźródłowymi systemami operacyjnymi, żeby nie było problemów z rozwojem sterowników. Także procesory, chipsety, karty graficzne i dźwiękowe( HDA) Intela są bardzo popularne wśród użytkowników, a sam Intel wspiera rozwój sterowników open source i publikuje stosowne dokumentacje.
mmlr był gotów włożyć swoją pracę w rozwój tych sterowników dla Haiku i rozwiązania problemów Haiku z platforma SandyBridge. Platforma ta została przynajmniej częściowo przetestowana i działa. Kupując go myślał, że jedyne problemy będzie miał z Wi-Fi i kartą graficzną. A internet będzie działał przynajmniej w sposób przewodowy. W każdym razie swój artykuł napisał i zamieścił w internecie, za pomocą tego laptopa :).
Kiedy w końcu przyszła mu paczka z nowym komputerem, pierwsze co zrobił to zmniejszył partycję z Windoswem 7 do rozsądnych rozmiarów ;), no i zainstalował Haiku i jego bootmanager. Następnie sprawdził czy taka kombinacja działa. Haiku nie obsługuje jeszcze xHCI, więc Michael dodał to do swojej listy rzeczy do zrobienia. Po uruchomieniu Haiku stwierdził, że touchpad i trackpoint działają. Ale przyciski na touchpadzie nie( wylądowało to na liście rzeczy doz robienia). To nie są oddzielne przyciski, lewo i prawoklik są realizowane za pomocą wciśnięcia touchpada z odpowiedniej strony. Ma to niski priorytet, bo mmlr jest przyzwyczajony do korzystania z trackpointa, a touchpada używa jedynie do przewijania.
Bardziej istotne było to, że Haiku uruchamiało się w trybie VESA, a w trybie VESA nie ma jego natywnej rozdzielczości 1366×768. Otrzymał jedynie niewyraźny i niewygodny obraz z rozdzielczością 1024×768. Problem ten dostał najwyższy priorytet na jego liście TO-DO( do zrobienia). Potem spojrzał na stan sieci i ku jego zaskoczeniu znalazł bez problemu swoją sieć przewodową i bezprzewodową. Okazało się, że sterownik iprowifi4965 ma szerszy zakres obsługiwanego sprzętu – także serię 6000. Po kliknięciu, wpa_suplicant od razu prosił o hasło i zaskoczyło. Michael nie ma pojęcia czy sieć przewodowa rzeczywiście działa, bo nie miał potrzeby korzystania z niej.
Zintegrowana karta dźwiękowa jest wykrywana przez Haiku, ale niestety nie wytwarza dźwięku. Ten problem ogólnie dotyczy Haiku i jest już dużo “biletów” na bugliście z tym związanych. mmlr po pracach nad sterownikiem karty graficznej ma zamiar się tym zająć( TO-DO).
W zasadzie utknął przy nienatywnej rozdzielczości i musiał zająć się wdrażaniem wsparcia dla chipu graficznego Sandy Bridge( intel_extreme). Rozpoczął badanie innych sterowników, w szczególności zmian jakich musi dokonać, by sterownik w Haiku wspierał ten konkretny model karty graficznej. Robiąc to spostrzegł, ze architektura z Sandy Bridge jest podobna do architektury Iron Lake, zastosowanej w poprzedniej generacji modułów graficznych. Oba są nieobsługiwane. Umieszczenie GPU i CPU w jednym chipie, a także zintegrowanie tam mostka północnego( Platform Control Hub, PCH – w przyszłości dodadzą tam też mostek południowy, tworząc tym samym jeden układ SOC) sporo namieszało. Nie było tak źle jak się z początku wydawało. Podstawowa struktura jest niemalże taka sama, jak w tradycyjnej, zintegrowanej karcie graficznej. Oznacza to o wiele mniej pracy do wykonania, bo nie trzeba pisać sterownika od podstaw, a można się oprzeć na istniejącym sterowniku intel_extreme i włączyć do niego obsługę nowych integr.
I przy tym było trochę rzeczy do wykonania. Trzeba było wyciągnąć pewne elementy z użyciem różnych lokalizacji rejestrów i dodać specyfikę SandyBridge tu i tam. Szczęśliwie szybko uzyskał natywną rozdzielczość. Głównie dlatego, że w BIOSie były zaprogramowane poprawne wartości karty graficznej. W skrócie to wystarczyło ustawić jedynie odpowiedni tryb( sprawa jest bardziej skomplikowana, ale do tego się to sprowadza). Port HDMI i większość DVI nie są w ogóle zaprogramowane w Haiku. To z czym ma teraz do czynienia mmlr, to zrestrukturyzowanie sterownika intel_extreme i zmuszenie go do lepszej obsługi portów.
Choroba
Niestety Michael także zachorował i był mnie wydajny w swojej pracy przez ostatnie dwa tygodnie. Musiał pracować w krótszych seriach. Jest mu przykro z tego powodu. Ale zapewnił, że wywiąże się z zakontraktowanych godzin i że pieniądze zebrane przez społeczność nie zostaną zmarnowane.
Odpoczynek
Podczas pracy przy bardziej złożonych zadaniach które trwają dosyć długo, by uzyskać satysfakcjonujący efekt, jak np. praca przy sterowniku intel_extreme. Czasami trzeba zrobić sobie przerwę, aby nie frustrować się. W takich przypadkach Michael rozgląda się za innymi rzeczami, które go denerwują w Haiku. Lub patrzy na buglistę w poszukiwaniu lżejszego zadania.
W tym przypadku natrafił na ciekawy bug powodujący złe rysowanie się okien w przestrzeni roboczej, podczas ich przeciągania do innych obszarów roboczych( wiele pulpitów). Pomyślał, że nie musi być to trudne do wyśledzenia. Ustawił sobie środowisko testowe w app_server i odtworzył błąd. Chociaż patrząc na kod źródłowy nie zauważał błędu, lecz zaczął to bardziej drążyć i dotarł do celu. W końcu spostrzegł jak rozmiar obszaru roboczego wydaje się, że “przeskakuje” w aplecie przestrzeni roboczych w zależności od tego, co znajduje się na obszarze roboczym. Okazuje się, że różne konfiguracje ekranu są przechowywane( poprawnie) na obszarze roboczym, aby obszar roboczy utrzymał prawidłową konfigurację, nawet podczas podłączania różnych monitorów. Najwyraźniej ten mechanizm nie jest w pełni uwzględniony i poprawnie działa dla aktualnie widocznej przestrzeni roboczej, a inne obszary robocze biorą pierwszą dostępną konfigurację. mmlr napisał także, że wróci do tego jak niedługo zaczną wprowadzać wsparcie dla wielu monitorów.
Różne inne rzeczy
Tak jak inni deweloperzy Michael otrzymuje wszystkie commity za pomocą listy mailingowej commitów, aktualizacje ticketów z listy mailingowej bugtrackera, a także dyskusje na liście deweloperów i inne. I nieraz podczas przeglądania skrzynki e-mail zauważa coś, co go zaintryguje( oczywiście w godzinach niezwiązanych z jego kontraktem), znajduje szybkie rozwiązanie tego i naprawia to, więc czasami kontekst commita wydaje się niezrozumiały z punktu widzenia użytkownika.
Podczas swojego kontraktu jest stale podłączony do kanału irc Haiku. Z jednej strony jest to najbardziej łatwy i bezpośredni sposób skontaktowania się z nim i on może coś zakomunikować. Stara się także pomagać innym w dziedzinach w których jest kompetentny.
Konkluzja
Michael dziękuje wszystkim darczyńcom, a także członkom Haiku Inc.m dzięki którym to wszystko stało się możliwe. Nie tylko liczą się dla niego pieniądze, ale także zaufanie jakie jest pokładane w nim i jego pracy. Jeszcze kilka miesięcy temu nie podejrzewał, że jego hobby stanie się jego głównym źródłem utrzymania. I opowiada, że opłacało się robić to wszystko, by znaleźć się w takiej sytuacji.
Gdy Michael pisał te słowa Begeistert dopiero miał się odbyć. Wziął udział w imprezie, dużo dyskutował z innymi deweloperami i wziął udział w corocznym coding sprint, który to jest integralną częścią tego spotkania miłośników Haiku. Po wzięciu udziału w Begeistert, wrócił do prac w ramach swojego kontraktu.
Dodaj komentarz