Miesiąc: sierpień 2010

QEMU – podstawy

Emulator, maszyna wirtualna?

QEMU to zarówno maszyna wirtualna jak i emulator, ale co to tak właściwie znaczy?

QEMU jest emulatorem, gdyż potrafi uruchamiać pojedyncze programy jak i całe systemy operacyjne napisane dla procesora innego, od tego na którym aktualnie pracuje. Jest to możliwe dzięki szybkiej translacji rozkazów procesora docelowego na rozkazy procesora na którym działa QEMU.

QEMU w trybie wirtualizacji (potrzebny Xen lub moduł KVM) działa natomiast bezpośrednio na procesorze gospodarza.

Obsługiwane przez QEMU procesory to m. in.: x86, x86-64, PowerPC, MIPS, ARM, SPARC. Pełna lista tutaj.

Podstawowa obsługa – uruchamianie

QEMU to narzędzie konsolowe, podstawowy schemat uruchamiania to:

qemu [options] [image]

Wśród opcji możemy podać m. in.:

-M machine – wybór konkretnej architektury do emulacji (-M ? wyświetla listę dostępnych)

-cpu model – wybiera konkretny procesor (-cpu ? wyświetla listę dostępnych)

-fda file, -fdb file, -hda file, -hdb file, -hdc file, -hdd file, -cdrom file – włącza do naszego emulowanego systemu urządzenia: dystkietkę (przedrostki f), dyski (przedrostki h), cdrom z zwaratością taką jak zawiera file. Uwaga: nie można używać jednocześnie hdc i cdrom.

-boot x – ustala kolejność bootowania: a, b – pierszeństwo dyskietek, c – dysk twardy, d – cdrom.

-m megs – ustala ilość wirtualnego ramu na megs MiB, domyślnie jest to 128 MiB

-kernel file – bezpośrednio uruchamia podany plik zawierający jądro naszego systemu operacyjnego zgodnie ze specyfikacją Multiboot (będzie o tym, w którymś z najbliższych wpisów)

Istnieje jeszcze wiele przełączników pozwalających ustawiać sieć, bluetooth oraz różne inne urządzenia, ale tyle co tu opisałem, w zupełności wystarczy początkującemu osdevcowi :)

Spójrzmy na parę przykładów:

qemu linux.img

Uruchamia system z podanego obrazu linux.img, wszystkie opcje pozostają domyślne.

qemu -hda hda.img -m 128

Uruchamia emulator z podłączonym dyskiem o zawartości hda.img ze 128 MiB ramu. To co się dalej stanie, zależy od zawartości hda.img, gdyż wirtualny BIOS będzie próbował bootować system właśnie z owego dysku. Różnica między tym a poprzedni przykładem jest taka, iż poprzednia komenda mówiła explicite: „bootuj linux.img”, w tym przypadku dajemy QEMU informację o stanie: „Jest dysk, rób co chcesz” ;)

qemu -kernel kernel.bin

Uruchomi nasz kernel według specyfikacji Multiboot, inaczej mówiąc – nie potrzebujemy żadnego bootloadera, a nasz kernel powinien być w jakimś dobrze zdefiniowanym formacie wykonywalnym, np. ELF (o tym też innym razem).

Ficzery QEMU

W QEMU lubię szybkość działania i łatwość obsługi, ale to nie jedyne jego, oprócz wspomnianej już wieloarchitekturowości i bogatych możliwości konfiguracji,  zalety. Istotną cechą QEMU jest to, iż wspiera VBE 2.0 oraz posiada natywne wsparcie dla GDB. Moim ulubionym „ficzerem” jest natomiast QEMU monitor.

QEMU monitor

QEMU monitor, to diagnostyczny tryb emulatora pozwalający podglądać interesujące rzeczy. Po uruchomieniu systemu w QEMU wciskamy CTRL+ALT+2 i już jesteśmy w trybie monitora (CTRL+ALT+1 wraca z powrotem na ekran systemu, natomiast CTRL+ALT pozwala „odzyskać” z powrotem myszkę). W trybie monitora mamy dostępny szereg komend:

info cpus – podaje aktualny stan procesorów

info registers – wyświetla zawartość wszystkich rejestrów dostępnych dla danej architektury. Polecenie to jest szalenie przydatne, szczególnie na początkowych etapach osdevu – np. gdy chcemy sprawdzić czy stronicowanie jest już aktywne, gdzie właśnie utknął EIP naszego procesora i w wielu, wielu innych przypadkach.

Komenda info potrafi jeszcze co nieco, ale na razie tyle nam wystarczy. Kolejne przydatne polecenia to:

x /fmt addr oraz xp /fmt addr – pierwsza z nich wyświetla zawartość wirtualnej pamięci pod adresem addr w formacie fmt, natomiast druga robi to samo, tyle że dla pamięci fizycznej. Format jest natomiast następujący: count – ilość elementów do wyświetlenia (liczba dziesiętna), format – format wyświetlenia zawartości pamięci, tj. x – hex, d – dziesiętny, u – dziesiętny bez znaku, o – oktalny, c – char lub (uwaga!) i – instrukcja!, size – rozmiar, tj. b – 8 bitów, h – 16 bitów, w – 32 bity, g – 64 bity. Przykłady:

xp /40db 0x7C00

Wyświetli dziesiętnie 40 elementów bajtowych spod adres 0x7C00.

xp /40xh 0x7C00

Wyświetli heksadecymalnie 40 elementów dwubajtowcyh spod adresu 0x7C00.

xp /10i $eip

Wyświetli 10 kolejnych instrukcji po aktualnej pozycji EIP. Widzimy, że nie musimy tu podawać rozmiaru, gdyż jak wiadomo w x86 instrukcje mają zmienny rozmiar. Takie wyświetlenie jest szczególnie przydatne, gdy zastanawiamy się gdzie właśnie utknął nasz kernel :)

QEMU monitor posiada jeszcze wiele przydatnych opcji jak np. zrobienie screena, czy nagranie dźwięku jednak nie widzę sensu opisywania ich na obecnym etapie. Kompletny spis można znaleźć tu.

Na zakończenie

QEMU będzie nam bardzo pomocne w całej serii artykułów Tworzenie systemu operacyjnego. Będzie więc wiele okazji aby przećwiczyć zdobytą tutaj wiedzę na temat obsługi tego niezwykle zgrabnego narzędzia. Tymczasem zapraszam do ściągnięcia QEMU stąd, zapoznania się z dokumentacją tu oraz do spojrzenia na inne emulatory, np. bochs. Aha, jeśli ktoś naprawdę nie znosi konsolowych aplikacji, to istnieje parę graficznych nakładek na QEMU, jak np. qtemu czy qemulator, jednak żadnej z nich nie testowałem.

Tworzenie systemu operacyjnego – część 0x00: Wstęp i formalizmy

Skąd pomysł?

Po ponad 6 miesiącach od powstania idei serii postów, pierwsza część ujrzała właśnie światło dzienne. Pomysł na cykl notek zrodził mi się zaraz po ukończeniu kursu „Systemy operacyjne” na mojej ulubionej uczelni. Według (genialnego!) Prowadzącego, około 15% studentów po tym kursie przystępuje do napisania własnego systemu operacyjnego i wygląda na to, że ja jestem w grupie tych ~19 osób. Zapowiada się świetna zabawa :)

Co to będzie?

Seria będzie dokumentować i opowiadać o moich zmaganiach z próbą napisania (od zera) systemu operacyjnego o pewnej funkcjonalności. W postach postaram się zawrzeć wiedzę i kod, który krok po kroku będzie układał się w pełnowartościowy system operacyjny.

Po co to?

Cykl postów o tematyce programowania systemu operacyjnego będzie dokumentacją moich poczynań. Posty będą zdecydowanie miały charakter poznawczy, gdyż w żadnym przypadku nie jestem autorytetem w tej dziedzinie, a (na razie!) tylko początkującym amatorem. Proponuję więc nie polegać na zawartej tu wiedzy podczas kolokwiów z architektury komputerów ;) Proszę też o regularne komentarze z poprawkami do prezentowanych przeze mnie zagadnień – z pewnością będę je wtedy poprawiał. Przy okazji serii mam nadzieję zachęcić czytelników do zagłębienia się w fascynujący świat programowania systemowego, odkryć go nieco, a może nawet skłonić do napisania własnego systemu operacyjnego? Ponadto, nie znalazłem w internecie publikacji w języku polskim, które prowadziłyby krok po kroku (no dobrze, kilka by się znalazło, jednak kroki kończyły się zwykle na 3 odcinkach) po niezwykle zawiłej tematyce tworzenia systemu operacyjnego – będę więc pionierem ;> Przypominam również, że powstający system operacyjny nie ma za zadanie przewyższyć udziału rynkowego takich świetnych systemów jak Microsoft Windows, GNU/Linux czy Mac OS X, gdyż byłoby to niedorzeczne. To po prostu zwykły projekt eksperymentalny.

Co będzie potrzebne?

Najważniejszą rzeczą jest wytrwałość i chęć zdobywania wiedzy :) Posiadając te dwie cechy, nawet całkowity nowicjusz sporo może wynieść z tego cyklu. W swoich wypocinach postaram się zgrabnie balansować między nadmierną gęstością tekstu, a przesadną zwięzłością. Trudniejsze rzeczy postaram się dokładnie objaśniać, łatwiejsze będę traktował po macoszemu, dodając odnośniki, z których będzie można doczytać więcej. Zachęcam do komentowania rzeczy niejasnych i skomplikowanych tak, abym z czasem mógł dostosować poziom.

System operacyjny, przynajmniej z początku, będzie napisany w języku C z małym dodatkiem assemblera x86 (będę używał „dialektu” NASM-a), zatem znajomość C, jak również nieco assemblera zdecydowanie się przyda.

Z całą pewnością potrzebny będzie jakiś działający system operacyjny z dostępnymi narzędziami programistycznymi. W swoich postach będę opisywał tworzenie systemu operacyjnego w środowisku GNU/Linux w połączeniu z typowymi dla tej platformy narzędziami takimi jak gcc czy binutils. Przedstawione przykłady, da się jednak bez problemu skompilować pod Windowsem, czy Mac OS X, wymagałoby to jednak nieco więcej pracy (jeśli będzie taka potrzeba, mogę opisać techniki w oddzielnym poście). Zwolenników systemów innych niż Linux zachęcam do zainstalowania jakiejś łatwej i przyjemnej dystrybucji, choćby na maszynie wirtualnej i programowania w takim środowisku. Gwarantuję, że inicjalny trud się opłaci.

Kolejna rzeczą, która nie jest konieczna, ale znacząco ułatwi nam programowanie i testowanie naszego systemu będzie emulator platformy x86 (gdyż na tą platformę będzie powstawał nasz system). Mój wybór padł na qemu. Emulator przyda się, aby uruchamiać świeżo skompilowany system – choć oczywiście dla wytrwałych pozostaje opcja odpalania systemu na prawdziwej maszynie.

Formalizmy

Koniec gadania, przystępujmy do rzeczy. Chcemy napisać system operacyjny, no dobrze… tylko co to tak właściwie jest? W literaturze dałoby się znaleźć setki mniej lub bardziej zmyślnych/złożonych/obszernych definicji, wymyślić nowych można by było kilka kolejnych, a więc… która jest dobra? Odpowiedzi na to pytanie nie ma, gdyż brakuje obiektywnych kryteriów oceny, czy dana definicja jest poprawna, zła, ładna, zgrabna itd. Mi najbardziej do gustu przypadła następująca:

System operacyjny jest to zbiór programów i procedur spełniających dwie podstawowe funkcje:

– zarządzanie zasobami systemu komputerowego,

– tworzenie maszyny wirtualnej.

Natomiast najtrafniejsza definicja zasobu systemu to wg mnie:

Zasobem systemu jest każdy jego element sprzętowy lub programowy, który może być przydzielony danemu procesowi.

Definicją procesu zajmiemy się przy innej okazji.

Teraz kilka słów wyjaśnień. Jak widać z definicji systemu operacyjnego – nie jest on sam w sobie programem, a zbiorem programów i procedur. System, który będziemy implementować za jakiś czas będzie wyglądał z punktu widzenia czysto technicznego jakby był jednym programem, jednak to tylko decyzja implementacyjna – w ogólności tak być nie musi. Pierwsza funkcja, którą pełni system operacyjny wydaje się być jasna – zarządza on zasobami, które oferuje. Zarządza, czyli udziela dostępu użytkownikowi, czy też raczej programowi użytkowemu. Zasoby sprzętowe to na przykład dysk twardy, pamięć, czy też komputery podłączone w sieci, do stacji na której działa system operacyjny. Zasoby programowe to natomiast wszelkiego rodzaju tablice, czy też semafory. Druga funkcja, czyli tworzenie maszyny wirtualnej może brzmieć nieco tajemniczo. Sama maszyna wirtualna jest raczej kojarzona z procesem wirtualizacji, stawianiem odseparowanych serwerów itp., tym razem chodzi jednak po prostu o tworzenie warstwy abstrakcji łatwej do oprogramowania, użytkowania i tę właśnie warstwę nazywamy maszyną wirtualną. Nieformalnie reasumując: system operacyjny ma za zadanie oferować to, co posiada, w przystępnej formie ;)

Rozważmy teraz takie pytanie: Czy program działający na mikrokontrolerze np. mikrofalówki, lodówki, czy pralki jest systemem operacyjnym? Odpowiedź na to pytanie (według podanej wyżej definicji) to: nie. Program ten jest zadany odgórnie, nie ma możliwości oprogramowywania go – nie posiada żadnej warstwy abstrakcji i o zasobach tutaj też trudno mówić. Z kolei, zastanówmy się nad takim telewizorem, który działa w oparciu o jądro Linux. Tu sprawa nie jest już taka prosta. W końcu wiadomo, że Linux to system operacyjny (puryści mogliby się doczepić do tego stwierdzenia.. ;)), tylko że ten system dla użytkownika końcowego jest całkowicie przezroczysty – nie ma on bezpośredniego dostępu do zasobów, szczególnej maszyny wirtualnej też tu nie widać. Zatem, czy patrząc na telewizor w kontekście pudełka,  w którego środku coś się dzieje i otrzymujemy obraz, należy mówić o systemie operacyjnym? Tak jak już mówiłem, z definicjami nie jest łatwo.

Na koniec

To tyle na pierwszy odcinek serii. W kolejnym odcinku zajmiemy się już konkretami, czyli własnościami architektury x86. Poniżej załączam listę stron z materiałami, które zdecydowanie będą się przydawać.

OSDev.org – bardzo aktywny serwis typu wiki, traktujący o tematyce programowania systemów operacyjnych. Polecam od niego zaczynać szukanie odpowiedzi na pojawiające się wątpliwości.

Bona Fide OS Developer – strona zawiera pokaźną ilość przydatnych tutoriali, niestety nie jest zbyt często uaktualniana

Operating System Resource Center – skarbnica wiedzy o wszelakich zasobach systemów operacyjnych. Panuje tam trochę bałaganu, nie mniej jednak, można tam znaleźć masę przydatnych informacji.

Intel® 64 and IA-32 Architectures Software Developer’s Manuals – darmowe (!) podręczniki Intela do architektury x86 (i x86-64), zawierające 2 grube tomy na temat programowania systemowego. Przystępnie napisane, zwięźle objaśniają subtelności architektoniczne. Da się tam chyba znaleźć odpowiedź na każde pytanie, choć tego nikt nie jest pewien, bo nikt nie dał rady ich przeczytać ;)

Into the Void – skrócony (jakby ten intelowski okazał się za długi, ciężko dostępny) opis instrukcji architektury x86

W porządku, to tyle. Do usłyszenia w następnej części!

Mój udział w konkursie „Daj się poznać”

Konkurs daj się poznać oficjalnie rozpoczęty! Na stronie uczestników aktualnie widnieją 24 osoby (w tym ja, a jakże!), co należy uznać za niemały sukces. W tej notce chciałbym po krótce wyjaśnić, co będzie można u mnie przeczytać/zobaczyć.

Co?

Moim projektem jest… system operacyjny. Pomysł na serię postów dotyczących osdevu jest dosyć leciwy, jednak brak czasu i motywacji spowodowały odwlekanie go w czasie. „Daj się poznać” natomiast ma być dla mnie motywacją, aby owa seria powstała. Chciałbym jednak podkreślić, że konkurs sam w sobie nie jest powodem powstania projektu i niezależnie od przebiegu „zawodów” seria będzie miała swoją kontynuację.

Po co?

Odpowiedź na pytanie jest bardzo prosta – aby się czegoś nauczyć. Zaczynając ten projekt nie mam zamiaru przewyższyć udziału rynkowego takich świetnych systemów jak Microsoft Windows, GNU/Linux czy Mac OS X. Inicjatywa ma być zabawą połączoną z całkiem poważnym „riserczem”.

Dla kogo?

Seria ta przeznaczona jest dla wszystkich, którzy zainteresowani są tym, jak działa komputer (a konkretniej model systemowy architektury x86) – w detalach! Część czytelników zapewne zechce skompilować i pobawić się kodem, inni pewnie przejrzą tylko omawiane aspekty – wszyscy czytelnicy jednak, mam nadzieję, czegoś ciekawego się dowiedzą.

Kiedy?

Seria postów na ten temat ruszy jak tylko wrócę z urlopu – czyli najprawdopodobniej na przełomie sierpnia i września :) Wszystkich, którzy są zainteresowani, już dzisiaj zachęcam do subskrypcji kanału RSS, gwarantuję, że nie pożałujecie :) Posty dotyczące projektu oznaczone będą tagiem osdev, dodatkowo te, biorące udział w konkursie tagiem daj się poznać.

Problemy?

Widzę jeden poważny problem – częstotliwość postów. Tak jak wspomniałem, osdev to poważny temat, który wymaga na bieżąco intensywnego doszkalania się – nie wiem, czy będę w stanie produkować pełnej jakości (a innych, niż dopracowane – nie chcę) posty dwa razy w tygodniu (szczególnie, że niektóre zagadnienia wymagają przyswojenia dwóch setek stron z manuali Intela ;)).  Opcją jest również od czasu do czasu post o używanych przeze mnie narzędziach – które również mogą się przydać innym. Jeśli jednak nie podołam „z normą” – trudno, obejdzie się bez nagród ;). Mam nadzieję, że konkurs przysporzy mi wiernych czytelników serii – i to jest dla mnie priorytetem.

Do usłyszenia na przełomie sierpnia i września i nie zapomnijcie o zasubskrybowaniu kanału!

Byłbym zapomniał – kodów źródłowych projektu szukajcie tutaj, na razie niestety, nic tam nie ma.