JNODE - kompilacja i wstępne zapoznanie się pod Windowsem

JNode to system operacyjny w większości opierający się na kodzie zarządzalnym Javy. Niewielka część startująca jest napisana napisana w assemblerze (kompilator dostępny też w Javie). Po więcej informacji zapraszam tutaj: http://en.wikipedia.org/wiki/JNode http://lsantha.blogspot.com/2009/03/why-jnode.html http://www.duminy.fr/blog/?p=29&language=en Strona domowa projektu. Radzę zapoznać się z informacjami na tej stronie Pobieramy źródła dostępne tutaj: https://jnode.svn.sourceforge.net/svnroot/jnode/trunk/ Do tego potrzebujemy jakiegoś klienta SVN. Polecam: http://tortoisesvn.tigris.org/. Zakładam, że JDK 1.6.0 albo nowsze zainstalowane ? Przechodzimy do linii poleceń i wywołujemy: build Mamy trochę opcji dostępnych. Radzę budować wersję 32 bitowe. Te 64 bitowe mogą nie działać (przy najmniej na ten czas jest takie info na stronie). x86 nie chciało mi działać do spółki z QEMU. Budowany jest obraz startowy dysku i w głównej jest dostępny qemu.bat jak mniemam do uruchomienia wirtualnej maszyny. Budujemy więc build cd-x86. Ten skrypt tak uruchamia nam ANTa z odpowiednimi parametrami i poustawianymi ścieżkami odpowiednio. Sam ANT jest dostarczany razem ze źródłami. Możemy bez problemy zapodać więcej celów do wykonania: build clean cd-x86 x86. Polecam zapoznać się z dokumentacją do ANTa. Jest to niezbędne by zrozumieć jak to wszystko jest budowane. A bez tego ciężko zrozumieć jak to wszystko działa. Cały proces kompilacji napisany jest w ANTcie, a co bardziej skomplikowane rzeczy w Javie jako rozszerzone zadania ANTa. Zaraz na samym początku z sieci zostanie pobrana biblioteka klas Javy GNU Classpath. Z tej implementacji klas Javy korzysta JNode. O tym jak jest realizowany połączenie pomiędzy tą biblioteką, a klasami niższego poziomu, a sterownikami, a kernelem systemu (nie napisanym w kodzie zarządzalnym), a samym sprzętem ... o tym później. W dokumentacji projektu można znaleźć mapę pamięci całej 32-bitowej przestrzeni adresowej. Cały system nie korzysta z żadnej ochrony pamięci udostępnianej przez procesor, nie musi się też martwić, że jakiś program wykona tzw. instrukcję uprzywilejowane. Nie musi się przejmować przełączaniem kontekstu podczas przełączania wątków. Wywołanie systemowe, odwołanie do sterownika to po prostu wywołanie odpowiedniej metody. W Windows to prawie nigdy nie dzieje się bezpośrednio, większość funkcji systemowych wymaga przełączenia kontekstu. Ogólnie systemu typu JNode mają o wiele mniejsze narzuty na przełączanie zadań i wywoływanie funkcji powiedzmy ogólnie z innych bibliotek. Na ten czas JNode nie potrafi wykorzystać więcej niż jednego procesora (obecnie należało by powiedzieć więcej niż jednego jądra). Dobra wracamy do kompilacja JNode. Nie mamy kompilatora Nasm assemblera. Pobieramy werjsę Win32. Jak widać pierwsza poprawka, w źródłach JNode widziałem jakiś assembler, podobno jest też jakiś zewnętrzny projekt assemblera napisanego w Javie, ale póki co kernel jest budowany w Nasmie. Musimy go gdzieś wypakować i dodać do ścieżki systemowej katalog. Ponawiamy budowanie. Znowu błąd. Zmieniamy nazwę nasm.exe na nasmw.exe. Ponawiamy budowanie. O kelejny problem. Odnajdujemy BootDiskBuilder.java i poprawiamy na większą geometrię dysku, ja pierwszą wartość zwięszyłem dwukrotnie. Kompilujemy. W katalogu \all\build\cdroms powinniśmy znaleźć obraz ISO płyty wraz z plikiem konfiguracyjnym dla VMWare. System udało mi się uruchomić z płyty CD na VMWare jak i VirtualBoxie. Na teraz to tam więcej nie działa niż działa. Nie ma GUI, a było. Złe polecenie wywołuje wyjątek. Nie widzę żadnych obrazów dyskó twardych. Co chwile uruchamia się GC i nic nie da się zrobić przez parę sekund. W głównym katalogu mamy możliwość uruchomienia konfiguracji poprzez configure.sh. Wstępnie temu się przyglądając widzimy, że w katalogu głównym tworzony jest plik konfiguracyjny jnode.properties. W katalogu głównym mamy plik jnode.properties.dist. Zmieniamy mu nazwę i mamy plik konfiguracyjny. Oto odpowiednik configure.sh dla Windowsa: set CP=%CD%/builder/build/classes;%CD%/all/build/descriptors/jnode-configure.jar;%CD%/builder/lib/jnode-configure-dist.jar;%CD%/shell/lib/nanoxml-2.2.3.jar

if exist "%1" (
 java -cp %CP% org.jnode.configure.Configure %1
)
else (
 java -cp %CP% org.jnode.configure.Configure %CD%/all/conf-source/script.xml
)

Ja w sumie po porównaniu z plikiem dist nie pozmieniałem zbyt dużo. Zmieniłem GC i poustawiałem by generował obraz dysku dla VMWare. Bardzo by się on przydał. Generowanie CD trwa długo i zawiera on dużo niepotrzebnych rzeczy (jest target cd-x86-lite). Znowu musiałem powiększyć dysk twardy. Zrobiłem jeszcze raz clean i zbudowałem wszystko od początku czy to czasem nie jest jakiś bug. Wygląda to na jakiś bug w systemie budowania, być może przez to nie obrazu dysku dla VMWare ? Nie co męczyć się z tymi błędami teraz. Po integracji z Eclipse, gdzie można debugować skrypty Anta oraz także wskakiwać do kodu Javy dla zadań wszystko powinno być prostsze.