0xcafebabe -- per aspera ad astra

Sterownik jest specjalnym programem, którym głównym zadaniem jest sterowanie sprzętem, niedostępnym dla zwykłych, niskouprzywilejowanych, aplikacji. Post zawiera informacje o przykładzie, w jaki sposób pisać swój własny prosty sterownik, przy okazji debugując go za pomocą debuggera gdb.

Na początek, skrótowo, mamy do zrobienia kilka rzeczy:
1. Zainstalowanie nowego, Linuxowego systemu operacyjnego, na którym będziemy eksperymentować,
2. Skomponowanie własnej konfiguracji jądra tego nowego systemu, któremu wkompilujemy rozszerzenia umożliwiające zdalny dostęp przez debugger gdb,
3. Skonfigurowanie własnego środowiska programowania modułów przy użyciu Eclipse i kompilatora gcc,
4. Wymyślenie jakiejś sensownej polityki cyklu programowania i testowania, aby nie była ona aż tak bardzo niewygodna, że aż niemożliwa.

Rozumiem, że punkt 4 zazębia się ze znaną łacińską sentencją: de gustibus non est disputandum. Programowanie, jak każda dziedzina, którą robi się ostatecznie głównie samemu, w dużej mierze wymaga samozadowolenia ze środowiska pracy. Gustów jest jednak tak wiele, jak wiele jest charakterów na świecie, dlatego nie jest możliwe podanie jednego przepisu, który zadowoli wszystkich. Podana przeze mnie metoda jest zapewne jedną z miliona, która jednak dla mnie działa, przeciwnie do wielu konfiguracji na które sam obiłem się podczas moich wcześniejszych poszukiwań w czeluściach internetu, dlatego postanowiłem opisać ją nieco szerzej i nieco dostępniej, niż w postaci abstrakcyjnych skojarzeń i wyładowań elektromagnetycznych neuronów w moim mózgu ;). Dodam też jeszcze, że zanim zaczniesz się zapierać rękami i nogami przed nowym doświadczeniem konfiguracji środowiska, w którym możesz pracować, możesz wziąć pod uwagę też inną łacińską sentencję, która jest niejako patronką bloga, którego czytasz: per aspera ad astra ;).

Zabierając się do trybu jądra, wiele rzeczy powinieneś/powinnaś potrafić robić samemu/samej. To znaczy, instalacja nowego systemu Linuxowego nie powinna przysparzać Ci kłopotów. Powinieneś/Powinnaś wiedzieć, czym jest Eclipse, jak też wiedzieć, że potrzebujesz plugina CDT, który umożliwia pracę z kodem C/C++ z poziomu środowiska Eclipse. Co prawda korzystanie z tego IDE jest całkowicie opcjonalne, jednak nawet zatwardziały programista Emacs'owego Lisp'a nie może zakwestionować wygody programowania przy użyciu takich dodatków jak automatyczna analiza składni kodu, wyświetlanie semantycznych problemów w czasie rzeczywistym, wyświetlanie składowych struktur, argumentów funkcji, etc.

Powinieneś/Powinnaś mieć co nieco wiedzy na temat systemów wirtualizacji, przy czym podstawowa wiedza powinna w zupełności wystarczyć; temat jest na tyle obszerny, że wymaga swojej własnej dedykacji czasu i zasobów, aby zacząć się w niego zgłębiać, na co przyjdzie zapewne czas w przyszłości ;). Do wirtualizacji systemu wykorzystam program VirtualBox, ponieważ jest dostępny za darmo na większości dystrybucji Linuxowych.

Przydatną umiejętnością i wiedzą jest samodzielność podczas kompilacji własnych wersji kernela. Nie jest wymagana do tego znajomość programowania, i umiejętność tą posiada każdy szanujący się administrator sieci Linuxowych, dlatego – jeśli jeszcze tego nie robiłeś/robiłaś – idź, i zainstaluj Gentoo :).

Konfiguracja systemu do eksperymentów

Jak wspomniałem wcześniej, przyjmę, że posiadasz już zainstalowany wirtualny bazowy system Linuxowy w VirtualBox, którego nazwa właściwie nie gra roli, dopóki posiada on kernel z rodziny co najmniej 2.6. W swoich przykładach będę posługiwał się 32-bitową dystrybucją Fedora w wersji 15. Przy okazji, sam posiadam skonfigurowaną też 64-bitową dystrybucję Linux Mint Debian Edition pod kernel development; metody konfiguracji były takie same.

Po pierwsze, należałoby ściągnąć interesującą nas wersję kernela z oficjalnej kernelowej strony, kernel.org. Jest to kernel nazywany przez dystrybucje mianem „vanilla”, czyli podstawowy, bez żadnych patchów innych podmiotów (tutaj: bez żadnych patchów Fedory), usprawniających interoperacyjność z innymi składnikami systemu. To, co ściągniesz, będziesz posiadał/posiadała w całości w taki sposób, w jaki sobie to skonfigurujesz, dlatego musisz upewnić się, że wiesz, co należy zrobić, aby Twój nowy kernel wiedział jak się utrzymać po otrzymaniu kontroli przez MBR ;). Ale po kolei.

Dla eksperymentu można ściągnąć najnowszą wersję kernela, którą jest wersja 3.0.2 (w momencie pisania tego posta) i zapisać go do katalogu np. ~/dev/custom-kernel. Wersja ściągnięta w ten sposób po części jest już skonfigurowana pod development, więc pozostaną nam do zaznaczenia tylko w sumie same szczegóły. Po ściągnięciu pliku i jego rozpakowaniu, można wejść do katalogu i zweryfikować, że pliki są na swoim miejscu (np. istnieje plik arch/x86/kernel/kgdb.c), po czym uruchomić make menuconfig (być może trzeba będzie doinstalować pakiet ncurses-devel).

Opcje do koniecznego zaznaczenia (w kernelach w wersjach innych niż 3.0.2 niektórych opcji może nie być; należy wziąć to raczej na inteligencję, a nie na proste kopiowanie):

Kernel hacking → [*] Enable __deprecated logic,
Kernel hacking → [ ] Strip assembler-generated symbols during link,
Kernel hacking → [ ] Enable unused/obsolete exported symbols,
Kernel hacking → [*] Kernel debugging (i wszystkie dzieci),
Kernel hacking → [*] Debug object operations,
Kernel hacking → [*] Kernel memory leak detector,

Tych kilka opcji ułatwi debugowanie mechanizmów synchronizacji międzywątkowej:

Kernel hacking → [*] RT Mutex debugging, deadlock detection,
Kernel hacking → [*] Spinlock and rw-lock debugging: basic checks,
Kernel hacking → [*] Mutex debugging: basic checks,
Kernel hacking → [*] Lock debugging: detect incorrect freeing of live locks,
Kernel hacking → [*] Lock debugging: prove locking correctness,
Kernel hacking → [*] RCU debugging: prove RCU correctness,
Kernel hacking → [*] KGDB: kernel debugger → [*] KGDB: use kgdb over the serial console oraz [*] „KGDB: Allow debugging with traps in notifiers” – natomiast reszta powinna być odznaczona,
Kernel hacking → [*] Enable verbose x86 bootup info messages – więcej informacji od kernela, gdy coś pójdzie niezgodnie z planem,
Kernel hacking → [ ] Write protect kernel read-only data structures – zaznaczona opcja nie pozwoli na zakładanie pułapek – gdb zwracałby błąd „error accessing memory address (...)”.

Znajduje się tutaj o wiele więcej opcji, które mogą być wykorzystywane w różnych aspektach pracy nad sterownikami, jednak my nie będziemy z nich korzystać. Właściwie, to nie będziemy korzystać z większości tego, co znajduje się w tabelce powyżej, ale wydaje mi się, że taki setup stanowi dość dobry bootstrap do samodzielnego sprawdzania, co, jak, gdzie, z kim i dlaczego :)

Po wybraniu wszystkich opcji, jak też i tych, które wiesz, że są Ci potrzebne, czy to do prawidłowego działania kernela na Twojej maszynie wirtualnej, czy z jakiegokolwiek innego powodu, warto zapisać aktualną konfigurację do pliku o nazwie .config przy pomocy opcji „Save an Alternate Configuration file”, po czym można już wyjść z menuconfig'a.

Kompilacja zostanie rozpoczęta po wykonaniu polecenia make -j 2, gdzie zamiast 2 wstaw liczbę core'ów w twojej maszynie wirtualnej, podwojonej przez 2. Ja wybrałem maszynę z jednym rdzeniem, choć polecam stworzyć maszynę z dwoma lub więcej rdzeniami; ich większa ilość w znaczący sposób może przyspieszyć problemy z synchronizacją algorytmów, problemy z poprawnym blokowaniem odpowiednich mutex'ów, poprawne wstawianie sekcji krytycznych o poprawnej długości w poprawne miejsca w kodzie, słowem: programowanie algorytmów przy użyciu wielozadaniowości stanie się bardziej naturalne.

Jak wiadomo, proces budowy kernela trwa dość długo nawet na szybkich procesorach. Lepiej mieć tutaj możliwie jak największą liczbę core'ów, np. 4 lub więcej; wtedy większa liczba argumentu -j polecenia make potrafi przyspieszyć build nawet kilkukrotnie, oszczędzając nam sporo czasu, a – jak wiadomo – czas, to pieniądz.

Jeśli chce ci się kombinować, możesz skompilować kernel na swojej natywnej maszynie, jednak musisz upewnić się, że maszyna natywna i maszyna wirtualna posiadają dokładnie taką samą wersję kompilatora gcc, który jest dość strategicznym punktem jeśli chodzi o ogólny temat programowania na system Linux.

Nawet jeśli jednak posiadasz tylko dwa core'y (lub jeden; choć statystyki mówią, że najczęstrzym przypadkiem są jednak dwa core'y), nie powinieneś/powinnaś narzekać, ponieważ jeszcze nie tak dawno temu, na maszynach z kilku lat wstecz (np. 8 lat) kompilacja kernela trwała całą noc... podejrzewam też, że nie posiadasz sprzętu klasy Pentium 133, ale jeśli tak – skocz na rower :)

Po zakończeniu procesu kompilacji, należy zainstalować nowy kernel w katalogu /boot (razem z plikiem System.map):

i zainstalować dla niego wszystkie skompilowane sterowniki:

Zauważ też w aktualnym katalogu plik vmlinux, który też będzie potrzebny, ale na razie nie trzeba go nigdzie kopiować:

Teraz należałoby skonfigurować domyślny bootloader, by odpalał nasz kernel, a nie ten z domyślnej dystrybucji. W Fedorze znajduje się grub w pierwszej wersji, to znaczy, że należy zmodyfikować plik /boot/grub/menu.lst, zmieniając dyrektywę timeout na np. 10, wstawiając hash (#) przed hiddenmenu, aby dyrektywę tą wyłączyć, oraz dopisując nowy deskryptor naszego eksperymentalnego jądra, która, najlepiej gdy będzie kopią deskryptora innego kernela, ale nieco zmodyfikowaną, tzn. oczywiście zmieni się ścieżka do pliku z naszym kernelem, jak też i zniknie argument quiet z końca jego linii poleceń. Oprócz tego należy dodać argument inicjujący debugger kgdb – kgdboc=ttyS0,115200, co znaczy, że kgdb będzie nasłuchiwał na porcie szeregowym numer zero, czyli pierwszym ;), jak również opcję kgdbwait, która mówi kernelowi, aby poczekał na początkowe podłączenie się debuggera gdb na maszynie natywnej – ale tą opcję wstawimy trochę później, więc jeszcze jej nie dodawaj ;).

Oprócz tego, jeśli też korzystasz z Fedory, zwróć uwagę na to, że domyślna instalacja rozkłada partycje przy użyciu LVM; aby poprawnie wystartować kernel przy LVM, należy zbudować initrd dla nowej wersji kernela. Na szczęście ogranicza się to tylko do wywołania programu dracut:

(gdzie 3.0.2 to wersja twojego kernela). Następnie zaktualizuj konfigurację gruba, wstawiając opisywany wcześniej deskryptor (u Ciebie może się trochę różnić, ale pamiętaj o argumencie kgdboc na końcu linii „kernel”):

Grub w wersji 2 łatwiej skonfigurować za pomocą polecenia grub-mkconfig. Odsyłam do Google po nieco więcej szczegółów :).

Pora na test polowy, czyli restart wirtualnego systemu i sprawdzenie, czy cały system wstaje poprawnie i startuje do graficznego interfejsu – jeśli tak jest, można chyba założyć, że kernel został skonfigurowany poprawnie i można przystąpić do kroku następnego. W tym kroku polecam wykorzystać funkcję robienia snapshotów w VirtualBox – znacznie przyspieszy kombinowanie w przypadku, gdy twój kernel nie będzie chciał się podnieść. W razie gdy tak się stanie, musisz przeanalizować to, co kernel wypisał na ekranie zanim przestał odpowiadać i w jakiś sposób dojść do tego, co powoduje problem. Być może nie wkompilowałeś/wkompilowałaś w jądro obsługi systemu plików, tylko zrobiłeś/zrobiłaś sam moduł? Być może brakuje obsługi chipsetu, jakiegoś kontrolera dysków? VMware znane jest ze swoich niestandardowych wymagań jeśli chodzi o własną kompilację linuxowego kernela, proponuję więc skorzystać z Google w celu odnalezienia prawidłowych ustawień.

Krokiem następnym (zakładając optymistycznie, że kernel wstał i załadował się w poprawny sposób) będzie stworzenie pewnego swojego rodzaju tunelu komunikacyjnego między debuggerem kgdb na systemie wirtualnym, a debuggerem gdb uruchamianym na systemie natywnym. W skrócie, polega to na tym, że kernel wirtualny z rozszerzeniami kgdb będzie sterowany przez te rozszerzenia; wszystkie rozkazy zatrzymania się, inspekcji obszarów pamięci, kontynuacji czy odczytywania instrukcji będą wprowadzane w życie przez kgdb, który jest uruchomiony na systemie wirtualnym. Jednak rozkazy dla kgdb będą wysyłane portem szeregowym przez natywnie uruchomiony debugger gdb, który po prostu będzie korzystał ze swojego standardowego protokołu debugowania zdalnego, który jest „przypadkowo” ;) rozumiany przez kgdb. W skrócie - kgdb, który działa w trybie jądra, jest po prostu stubem remote debugging dla gdb.

Niżej opisane zmiany opcji w VirtualBox należy przeprowadzić na wyłączonym systemie wirtualnym – co wynika z ograniczenia samego VirtualBox'a, który w chwili obecnej nie pozwala na dokonywanie tak „inwazyjnych” zmian maszyn wirtualnych. VMware z kolei raczej nie powinien mieć z tym problemu.

Po wejściu w opcję „Serial Ports”, zaznacz opcję „Enable Serial Port”, zaznaczając, że chodzi o (wirtualny) port COM1. Tryb portu powinien zawierać wartość „Host pipe”, opcja „Create Pipe” powinna być zaznaczona, oraz pole tekstowe „Port/File path” powinna zawierać ścieżkę do pliku na dysku, która powinna zawierać informacje o wybranym pipe'ie. Jak widać na screenshocie, u mnie widnieje ścieżka /home/antek/serial.

Pora teraz zainstalować program socat. Jego nazwa jest skrótem od socket cat (gdzie cat jest z kolei skrótem od concatenate) i służy do tłumaczeń różnych technik przesyłania informacji na inne techniki. Jest nam potrzebny, ponieważ konfigurujemy VirtualBox'a tak, aby port szeregowy systemu wirtualnego przekierowywał zapisane do niego dane do pipe'a stworzonego w wybranym pliku (w moim przypadku: /home/antek/serial). Gdb jednak nie posiada umiejętności zdalnego debugowania poprzez zwykłe pipe'y, dlatego trzeba tego pipe'a przetłumaczyć na coś, z czego można czytać jak ze zwykłego portu szeregowego. Takim czymś może być podsystem pseudoterminali („pty”), który zwykle „mieszka” na systemie natywnym w katalogu /dev/pts. Zdecydowana większość dystrybucji jest skonfigurowana w ten sposób, że pod ten katalog montowany jest system plików devpts, który podsystem ten implementuje. Socat potrafi zaalokować nowy pseudoterminal, umieszczając w nim dane, które odczyta z pipe'a o nazwie /home/antek/serial. Jeśli to mu się uda, wtedy gdb może podłączyć się do nowo-zaalokowanego pseudoterminala, hostowanego przez socat'a, który będzie forwardował wszystkie instrukcje z gdb do podłączonego pipe'a, który z kolei będzie wpychał ten ciąg danych do VirtualBox'a, który z kolei będzie oszukiwał system wirtualny, że owe dane nadchodzą z portu szeregowego, który zostanie odczytany przez kgdb i wykona on odpowiednią akcję. Dane zwrotne, z wynikami, będą podążać tą samą drogą, ale w przeciwną stronę :).

Być może brzmi to w dość przewrotny sposób, ale wszystko sprowadza się do stwierdzenia: za pomocą socat'a należy przetłumaczyć /home/antek/serial na wolny pseudoterminal w katalogu /dev/pts. Proste polecenie załatwi sprawę:

W wyjściu programu będzie widniał numer pseudoterminala, pod który podpięty jest pipe serial. Ten numer należy zapamiętać, ponieważ trzeba go będzie wpisać potem jako argument jednego polecenia gdb. Oto przykład wyjścia, który mówi o zainicjowanym pseudoterminalu numer 3, czyli /dev/pts/3:

Skoro już wiesz jak z niego korzystać, możesz chwilowo go opuścić przez naciśnięcie ^C.

Druga rzecz to poprawne skonfigurowanie sieci na maszynie wirtualnej. Najlepiej posłuży do tego tryb mostka (bridged adapter), o nazwie takiej, jak twój interfejs sieciowy na maszynie natywnej, ponieważ wtedy maszyna wirtualna dostanie numer IP, który będzie „widziany” z maszyny natywnej (i wszystkich maszyn w sieci) przy użyciu standardowych poleceń sieciowych (np. lftp, rsync, ping). Być może będziesz musiał/musiała zmienić ustawienia DHCP swojego routera, by uwzględniał adres MAC wirtualnej karty sieciowej (który widnieje w polu „Mac Address”) i zaopatrywał go w wybrany numer IP – jeśli takowy serwer DHCP posiadasz. Jeśli nie, standardowa metoda konfiguracji statycznego adresu IP interfejsu sieciowego na maszynie wirtualnej (ifconfig) powinna załatwić sprawę. Właściwie ten krok nie jest niezbędny, ponieważ sama komunikacja debuggera będzie realizowana przez wirtualny port szeregowy – ale jeśli tego nie zrobisz, synchronizacja kodu źródłowego przez rsync (co będzie opisane w dalszej części posta), nie będzie działać. Może wpadniesz na inny pomysł, jak to wygodnie zrobić; dla mnie wygodnie jest tak, jak opisałem wyżej ;).

Pora przetestować połączenie z gdb. Włącz maszynę wirtualną i poczekaj na pełne uruchomienie systemu. Uruchom terminal i z poziomu użytkownika root wykonaj polecenie:

które zawiesi system ;). Jest to jednak zawieszenie kontrolowane! Podczas gdy system wirtualny jest zawieszony, na systemie natywnym uruchom socat'a, zgodnie z opisem kilka paragrafów powyżej. Po uzyskaniu numeru pseudoterminala, na maszynie natywnej uruchom gdb i powiedz mu, aby połączył się z uzyskanym numerem pty. Przykładowo, jeśli będzie to /dev/pts/3, polecenie powinno wyglądać tak:

(jeśli dostaniesz tutaj, lub w późniejszych krokach, błędy typu warning: Invalid remote reply, spróbuj po prostu naciskać ^C aż do uzyskania znaku zachęty, po czym ponownie wpisz rozkaz target remote (...) - desynchronizacja powinna zostać naprawiona)

Gdb uzyskał połączenie zdalne z wirtualnym kernelem. Kgdb po stronie wirtualnej wysłał raport na temat swojego stanu; aktualnie stoi w kernelu na adresie 0xc0485592 i oczekuje na dalsze rozkazy, które możemy wysyłać normalnie za pomocą gdb w standardowy sposób. Przykładowo, aby pobrać wartość rejestru EIP, można wysłać polecenie p $eip:

Zwróci ono tą samą wartość którą uzyskaliśmy przed chwilą w innym miejscu, co znaczy, że wyniki mają logiczny sens, więc teoretycznie wszystko działa jak powinno. Lub też np. chcąc zrobić dump 20 bajtów spod adresu, na który wskazuje rejestr ESI, można wykonać to polecenie:

Podobnie, jeśli chcesz wyświetlić kod asemblerowy w miejscu, gdzie aktualnie jesteś, możesz wykonać np.:

Wszystko pięknie, oprócz tego, że nie wiemy gdzie jesteśmy! Gdzie jest kod? Jak go zobaczyć? Jak postawić pułapkę na jakiejś funkcji? Jeszcze nie możemy tego zrobić, bo brakuje nam symboli – czyli nazw funkcji i zmiennych, które zmapowane są pod konkretne adresy.

Pamiętasz plik vmlinux? Ten plik zawiera mapowanie symboli do adresów. Teraz jest ten moment, gdy go potrzebujemy, razem ze źródłami wersji kernela, którą posiadasz na systemie wirtualnym. Najpierw odwieś wirtualny system za pomocą polecenia continue:

I przekopiuj plik vmlinux z głównego katalogu źródeł kernela (czyli z tego katalogu, z którego robiłeś/robiłaś make menuconfig) na system natywny, przy użyciu wybranej przez siebie metody (np. scp, sshfs, ftp, virtualbox shared folders, wyślij mailem, etc ;) - przy kopiowaniu możesz chcieć spakować plik np. tar i bzip2 przed wysyłaniem przez sieć).

Po uzyskaniu wszystkiego na systemie natywnym, wyjdź z sesji gdb (^C do skutku) i uruchom go jeszcze raz, z katalogu źródeł kernela z systemu natywnego, i tym razem jako parametr podając plik vmlinux. Aktualne przebywanie w katalogu źródeł kernela jest ważne, ponieważ gdb będzie szukał źródeł kernela relatywnie do swojego aktualnego katalogu pracy (working directory):

Gdb tutaj powinien zawisnąć w oczekiwaniu na pułapkę. Na systemie wirtualnym ponownie wyślij sygnał „g” do /proc/sysrq-trigger. Gdb powinien wtedy zatrzymać się w:

Sukces ;) Można wyświetlać kod:

aktualną historię ramek:

stawiać pułapki:

i wyświetlać źródła asm, posiadając wszystkie symbole pokazane na swoich miejscach:

Wygląda na to, że wszystko działa jak należy. Kontynuujmy więc nasz kernel:

I przejdźmy do dalszej części tutoriala ;).

Konfigurowanie Eclipse

Należałoby w końcu skonfigurować swoje środowisko programowania.

Przyjmuję, że masz już zainstalowane i skonfigurowane Eclipse wraz z pluginem CDT. Stwórz nowy, pusty projekt C, który nie jest zarządzany przez żadne Eclipse'owe mechanizmy automatycznego generowania plików Makefile – będzie trzeba napisać (i utrzymywać) własny Makefile. Nazwą projektu w oknie wizarda nowego projektu może być np. adx-tutorial.

Należy pamiętać o wyłączeniu zarządzania Makefile'ami:

Pierwszy krok to dodanie nowego pustego pliku Makefile o treści:

Plik możesz skopiować w całości i wkleić do swojego, zmieniając w przyszłości tylko cztery zmienne w początkowych liniach pliku, upewniając się jednocześnie, że spacje zostaną zamienione na tab'y, a konkretnie seria spacji zostanie zamieniona na jeden tabulator ;). Znaczenie zmiennych jest takie:

MODULENAME – jest to nazwa pliku, jaki będzie nosił plik sterownika. Do tego ciągu znaków zostanie doklejone rozszerzenie '.ko' – oczywiście, będzie je można potem zmienić.

OBJECTLIST – jest to lista plików obiektowych, z których linker będzie musiał skonsolidować sterownik. Pliki obiektowe muszą kończyć się rozszerzeniem '.o', oraz ich nazwa musi być taka sama jak plików '.c' – czyli, mając w projekcie pliki źródłowe: main.c oraz secondary.c, twój OBJECTLIST wyglądałby tak: main.o secondary.o.

TARGETNAME – jest to nazwa katalogu, który zawiera projekt. Innymi słowy, jest to też nazwa projektu w Eclipse. Będzie potrzebna do konfiguracji rsync poniżej,

VIRTUALSYSTEM – numer IP, pod który można robić rsync, czyli numer IP systemu wirtualnego. Na początku niech będzie tutaj pusto; powinno zostać też puste w przypadku, gdy nie udało ci się zrobić konfiguracji sieciowej opartej na połączeniu mostkowanym, lub też nie chciałeś/chciałaś tego robić.

Reszty części Makefile nie trzeba teraz zmieniać. Dla kompletu, stwórz w projekcie dwa pliki z kodem źródłowym C: adxmain.c orac debug.c. Przepisz do nich taką treść:

adxmain.c:

dummy.c:

Pora teraz przetestować, czy reguły kompilacji rzeczywiście działają. Tak powinien wyglądać mniej więcej poprawny log build'a Eclipse, po wybraniu opcji kompilacji:

(błędem rsync na chwilę obecną się nie przejmuj)

Jeśli w katalogu nie pojawił się żaden plik z rozszerzeniem .ko, sprawdź czy masz zainstalowane poprawne nagłówki swojego aktualnie uruchomionego kernela (aktualną wersję można odczytać przy pomocy polecenia uname -r). Jeśli jednak plik się pojawił, gratulacje!, jest to sterownik, gotowy do załadowania poleceniem insmod, ale tylko pod twój aktualnie uruchomiony kernel na systemie natywnym. Aby sterownik działał poprawnie na systemie wirtualnym, na którym ma działać (ponieważ tylko system wirtualny będzie można wygodnie debugować i nikt nie ucierpi z powodu nieplanowanych kernel paniców), trzeba źródła przekopiować na system wirtualny i tam skompilować. Tutaj do gry wkracza rsync, który w łatwy sposób pozwoli na synchronizację drzewa kodów źródłowych sterownika na wirtualną maszynę. Przed jego użyciem jednak, należy poprawnie skonfigurować demon'a rsync na systemie wirtualnym. Nie jest to na szczęście trudne i ogranicza się do edytowania pliku /etc/rsyncd.conf (jeśli go nie ma, stwórz go):

Teraz trzeba wybrać sobie katalog, do którego rsync z systemu natywnego będzie kopiował pliki na system wirtualny. Ten katalog w moim przykładzie nosi nazwę workspacepp. Jeśli chcesz go zmienić, musisz zrobić też to w pliku Makefile, który znajduje się kilka paragrafów wyżej, w regule o nazwie rsync.

Składnia pliku rsyncd.conf jest szerzej opisana w manualach rsync, dlatego tutaj wkleję tylko przykład, jak powinna wyglądać deklaracja katalogu workspacepp:

I tyle ;), ścieżkę path oczywiście zmodyfikuj, aby pasowała do Twojego środowiska. Demon rsync jest uruchamiany przez:

Nie zapomnij też stworzyć katalogu workspacepp na systemie wirtualnym:

Demon rsync jest gotowy i czeka na swoim porcie na requesty nowych połączeń. Pamiętaj jednak o tym, że wiele dystrybucji posiada domyślnie konfigurowany firewall, który nie pozwala na połączenia przychodzące; Fedora jest jedną z tych dystrybucji, które ten firewall mają aktywny. Można go całkowicie wyłączyć, albo skorzystać z polecenia wstawienia „pustej” reguły akceptacji pakietów na sam początek łańcucha wejściowego, czyli łańcucha odpowiedzialnego za odbieranie pakietów do lokalnych gniazd (socketów):

Reguła ta na pierwszym miejscu spowoduje akceptowanie wszystkich połączeń (praktycznie równoważne jest to usunięciu wszystkich reguł z łańcucha INPUT i ustawieniu domyślnej polityki akceptacji pakietów na ACCEPT). Lub też, zamiast 0/0 wstaw numer IP swojego systemu natywnego, aby tylko jemu pozwolić na połączenie się z rsync. Podejrzewam jednak, że w przypadku zacisza domowej sieci LAN, wyłączenie firewalla będzie skuteczniejsze, szybsze i łatwiejsze (no, chyba, że korzystasz z WIFI „zabezpieczonej” kluczem WEP – wtedy przerwij czytanie tego tutoriala i zainteresuj się uaktywnianiem WPA2 na swoim hotspocie, najlepiej już teraz).

Po poprawnym skonfigurowaniu, lub wyłączeniu firewalla, czas przetestować skrypt build i synchronizację źródeł. Wywołaj kompilację projektu w Eclipse raz jeszcze – tym razem błąd rsync nie powinien mieć miejsca i źródła powinny zostać skopiowane na system wirtualny w poprawny sposób. Na systemie wirtualnym powinny pojawić się pliki z hosta:

Teraz, na systemie wirtualnym pozostaje przejść do katalogu adx-tutorial, wykonać make clean (ponieważ wszystkie obiekty i metadane pochodzą z systemu natywnego), i ponownie wykonać make (bez „all”), aby skompilować sterownik pod nowy kernel. Jeśli pojawią się błędy, to znaczy, że nowa wersja kernela zawiera nieco inne struktury lub zasady użycia pewnych mechanizmów. Najlepiej wziąć pod uwagę to w swoim sterowniku, aby kompilował się na starszych, jak i nowszych kernelach.

Spinanie wszystkiego w całość

Czas na krótkie podsumowanie.

Posiadasz maszynę wirtualną, która będzie odgrywała „linii frontu”, czyli systemu który będzie uruchamiał sterownik. W przypadku, gdy sterownik zawiera błąd powodujący kernel panic, zawieszeniu ulegnie tylko system wirtualny, chroniąc system natywny przed śmiercią przez restart.

Sterownik programować możesz przy użyciu Eclipse, które zawiera mnóstwo opcji i rozszerzeń wspomagających pracę. Przy każdorazowej kompilacji, aktualne źródła będą kopiowane również na system wirtualny, by w razie potrzeby tam skompilować sterownik i od razu spróbować go załadować, wraz z przeprowadzaniem odpowiednich testów jego działania. Jednym z głównych argumentów przemawiających za użyciem Eclipse jest jednak auto-uzupełnianie składni przez plugin CDT. W Visual Studio owo auto-uzupełnianie nosi nazwę intellisense i jest czymś, bez czego niektórzy nie wyobrażają sobie programowania ;). Auto-uzupełnianie Eclipse jest ulepszane z wersji na wersje, a plugin, który je realizuje nosi prostą nazwę Indexer'a.

Nie jest to jednak idealne rozwiązanie, zawiera kilka błędów, które niekoniecznie są intuicyjne, ale zaopatruje w pewne mechanizmy pozwalające na radzenie sobie z problemami. Jednym z takich mechanizmów jest włączenie opcji debug Indexer'a, które powinny rzucić nieco wyraźniejsze światło na jakiekolwiek problemy, które mogą spowodować brak takiego zachowania, jakie chcielibyśmy, aby istniało ;). Tryb debug włącza się poprzez dodanie kilku linijek do pliku np. debug.ini, w katalogu Eclipse, oraz uruchomienie eclipse z argumentem -debug debug.ini.

Plik debug.ini:

Uruchomienie Eclipse z argumentem -debug debug.ini (z konsoli) spowoduje wypisywanie informacji diagnostycznych indexer'a; błędy syntaktyczne, które raportuje indexer, uniemożliwiające poprawne zbieranie wyglądu struktur, będą wyświetlone między tymi informacjami, więc warto nauczyć się to wyjście interpretować.

Poprawna konfiguracja indexera polega na poprawnym wpisaniu ścieżek include do opcji projektu, we Właściwościach projektu → C/C++ General → Paths and Symbols. Należy tylko zainteresować się ścieżkami GNU C, ponieważ nie będziemy używać C++. Jako, że na systemie natywnym będziesz kompilować sterownik dla kernela natywnego (w wersji natywnej), ścieżki include powinny zostać pobrane właśnie z niego: /usr/src/linux/include oraz /usr/src/linux/arch/x86/include powinny załatwić sprawę.

Oprócz tego, w zakładce Symbols dodaj symbol o nazwie __KERNEL__, której przyporządkuj liczbę 1. Pytanie o przebudowę indeksu potwierdź przyciskiem YES i zaobserwuj wyjście diagnostyczne w konsoli, z której uruchomiłeś/uruchomiłaś Eclipse.

Można teraz przetestować indexer ;), czyli np. napisz definicję prostej struktury zaraz za #include'm:

oraz w funkcji main napisz:

Być może zdarzyć się taka sytuacja, gdzie po napisaniu „a.” i kliknięciu Ctrl+spacja nie wyskoczy okienko z podpowiedzią składowych struktury o typie AA. Winą jest indexer; nie zebrał informacji o składowych struktury, zadeklarowanej kilka linijek wyżej. Spróbujmy dowiedzieć się, jaki jest tego powód.

Ten przykładowy problem indexer'a zawiera kilka informacji w wyjściu diagnostycznym:

Błąd znajduje się w linii, która zawiera string Syntax error ;) i dotyczy linii 7 pliku adxmain.c. Znajduje się w niej deklaracja funkcji inicjującej moduł, razem ze specyfikatorem __init – zapewne to powoduje błąd, ponieważ indexer nie zna tego symbolu. Kliknięcie F3 na tym specyfikatorze pokazuje nam, że jego definicja znajduje się w pliku linux/init.h, którego nie includujemy w swoim pliku źródłowym. Dodaj więc odpowiedni #include na samę górę pliku i spróbuj ponowić Ctrl+spację zaraz po „a.”. Podpowiedź pojawiła się, więc wygląda na to, że wszystko gra.

Jak już zapewnie zauważyłeś/zauważyłaś, setup opisany przeze mnie powyżej posiada pewną charakterystyczną cechę programowania pod dwie wersje kernela; jedna wersja znajduje się na systemie natywnym, druga wersja na systemie wirtualnym. Posiada to pozytywny skutek uboczny, którym jest zwracanie uwagi na różnicę w strukturach między różnymi wersjami kernela. Sam kernel zmienia się bardzo szybko (jeśli nie jest to aktualnie najbardziej zmieniający się produkt dostępny na rynku), dlatego zwracanie uwagi na poprawną interpretację API, które np. oznaczone są jako przestarzałe, jest bardzo ważne. Samo programowanie sterownika nie jest jedynym aspektem na który trzeba zwracać uwagę – równie ważne jest utrzymanie kodu, które im starszy jest projekt, tym więcej czasu zajmuje. Kod nieutrzymywany z czasem traci swoją ważność – czasami wcześniej, czasami później, jednak nie należy się do niego przywiązywać ;). Jak pisałem też wcześniej, konfiguracja opisana powyżej służy w sumie tylko mi i nie mam dowodów na to, że będzie wygodna dla kogokolwiek innego. Zawiera też ogromną ilość rzeczy, które można usprawnić, przykładowo: usunąć manager'a X'ów i bootować tylko do linii poleceń; skrócić i wyrzucić niepotrzebne usługi ładowane przy starcie, aby jeszcze bardziej zmniejszyć czas ładowania systemu po kernel panic'u. Można napisać też serię skryptów które będą ułatwiać pracę z Twoim sterownikiem, ale treść tych skryptów zależy w sumie od tego, co ten sterownik miałby robić.

Tutaj dochodzimy do sensu programowania w trybie jądra; mianowicie, co i w jaki sposób można czegoś dokonać ;). W kolejnym poście opiszę szybko krótki sterownik, który można zaprogramować; będzie on pobierał pewne dane z kernela, które przydać się mogą w trybie user-mode, a nie są eksportowane przez system plików /proc. Sterownik korzystać będzie ze standardowych mechanizmów stosowanych w tym wirtualnym systemie plików i będzie tworzył nowy „plik”, który można odczytać cat'em. Zupełnie jak np. /proc/cpuinfo. Do następnego więc ;)