Emacs w wydaniu dla twardzieli

Na przestrzeni czasu zaprzyjaźniłem się ze świetnym edytorem jakim jest Emacs. Nasza długotrwała relacja spowodowała, że postanowiłem przenieść ten związek na wyższy poziom.. i udało się, jest jeszcze lepiej :). Teraz rozstajemy się jeszcze rzadziej. Jeśli Drogi Czytelniku też masz ochotę na głębszy romans, zapraszam do lektury tego wpisu.

Destrukcja

Podobno czasem bywa, że aby coś zbudować, trzeba coś zniszczyć. Tak zrobimy i tym razem i tworzenie  nowego, lepszego świata zaczniemy od… usunięcia Emacsa i wszystkiego co z nim związane z systemu. Większość osób instaluje edytor z dystrybucyjnego repozytorium. Takie rozwiązanie jest wygodne, ale ma kilka przykrych konsekwencji. Przede wszystkim repozytoria często zawierają nieaktualne wersje, a wbrew pozorom Emacs rozwija się całkiem szybko, więc łatwo pozostać w tyle. Drugą sprawą są zależności, które instalują się przy okazji – nie zawsze wiadomo co to jest. Różne dystrybucje wykorzystują różne rodzaje repozytoriów, a więc ewentualne przeniesienie naszego środowiska pomiędzy dystrybucjami może sprawić niepotrzebny kłopot. Odpowiedzią na te problemy jest kompilacja – proces sporo trudniejszy, no ale coś za coś. W każdym razie pacman -R (czy co tam kto używa) do rąk i do dzieła! Ważne, aby wszystko usunąć – nie tylko podstawowy edytor, ale również wszystkie pakiety wspomagające – dodatkowe mody itd.

Budowanie

Po słodkim zniszczeniu pora zacząć budowanie nowego świata. Pierwszym krokiem będzie sklonowanie najnowszej wersji z repozytorium:

git clone git://git.savannah.gnu.org/emacs.git

a następnie kompilacja i instalacja:

./autogen.sh
./configure
make
sudo make install

i gotowe! Nasz nowy, błyszczący Emacs jest gotowy. W przypadku gdybyśmy chcieli zaktualizować naszą kompilację należy wyczyścić stare efekty, pobrać zmiany i powtórzyć cały proces:

make clean
git pull
./autogen.sh
./configure
make
sudo make install

Prace wykończeniowe

Nie od dziś wiadomo, że to prace wykończeniowe zajmują najwięcej zasobów – tak też jest w tym wypadku.

Dodatki

„Goły” Emacs, mimo że bardzo rozbudowany, nie posiada wszystkiego, co potrzebne do szczęścia. Z tego powodu na pewno chcielibyśmy wyposażyć naszą kompilację w szereg dodatków. Wszystkie dodatkowe moduły warto trzymać uporządkowane, w jednym miejscu. W ten sposób przeniesienie ich na inny system będzie wymagało zaledwie skopiowania pojedynczego katalogu. Genialne w swej prostocie, prawda? Osobiście preferuję przechowywanie dodatków w katalogu ~/.emacs.d, w którym utworzyłem sobie dwa katalogi: modules i themes, które odpowiednio zawierają moduły i motywy graficzne.

Konfiguracja

Skonfigurowanie Emacsa, skrojone do indywidualnych potrzeb jest zadaniem dosyć skomplikowanym. Zajmę się tym w kolejnej notce z serii emacsowej. Na chwilę obecną proponuję obejrzeć mój plik konfiguracyjny, który jest dosyć obszernie skomentowany.

Uruchamianie

Gdy mamy już wszystko elegancko skonfigurowane można swobodnie zacząć używać Emacsa, ale… wpisanie w konsoli „emacs” jest passe, demode i w ogóle bleee. Osobiście, w trakcie uruchamiania systemu odpalam Emacsa w trybie daemona:

emacs --daemon

Wtedy Emacs będzie pracował zawsze w tle, a jego uruchomienie za pomocą polecenia:

emacsclient

będzie się odbywało niemal natychmiastowo. Istotną zaletą takiego podejścia jest ciągłe przechowywanie sesji no i wysoka efektywność i wygoda. Wadą natomiast może być konieczność rozsądnego zarządzania buforami, które nie zamykają się same. W tym miejscu warto również stworzyć dla powyższego polecenia wygodny alias – w moim wypadku jest to po prostu e. e nazwa_pliku uruchamia mi ramkę Emacsa z plikiem gotowym do edycji i jest to co najmniej tak wygodne jak vim ;>.

Na zakończenie

Używanie Emacsa w ten sposób jest bardzo wygodne i już wiem, że nie zamienię go na nic innego :). Serdecznie polecam wszystkim spróbowanie takiego podejścia. Niedoświadczonym proponuję sklonowanie sobie mojego repozytorium z dotfiles:

git clone git://github.com/luksow/dotfiles.git

Można tam znaleźć mój katalog .emacs.d, plik konfiguracyjny Emacsa .emacs oraz plik .bash_rc z ustawieniami aliasów.

Powodzenia!

Tworzenie systemu operacyjnego – część 0×06: Porządki, GDT, VGA…

W szóstej odsłonie serii zajmę się małymi porządkami, które zaprocentują w najbliższej przyszłości. Przede wszystkim uporządkuję kilka spraw, wrócę raz jeszcze do GDT oraz napiszę kilka funkcji, które będą pomocne przy wypisywanu komunikatów diagnostycznych, których nigdy za wiele ;).

Raczkująca przenośność

Twórcy niektórych systemów operacyjnych stawiają sobie za zadanie dotarcie do możliwe (potencjalnie!) najszerszej rzeszy użytkowników. Tworzą oni implementacje dla różnych architektur procesorów i starają się, aby dodanie kolejnych było w miarę łatwe. Inni całkowicie na to leją, gdyż biznesowo patrząc – jest to nieopłacalne. Przykłady jednych i drugich łatwo wymyślić, więc nie będę ich tu podawał ;). W swoim systemie postanowiłem zrobić kroczek w stronę stworzenia przenośnego systemu operacyjnego – maksymalnie wykorzystuję język C, który jest przenośny (od mikrokontrolerów aż do dużych, „poważnych” procesorów), a minimalizuję użycie assemblera, który tej cechy nie posiada.

Magia typedef

Każdy, kto programował trochę w C i C++ wie jak bardzo przydatnym i potężnym narzędziem jest słowo kluczowe typedef. Każdy znany mi system operacyjny często i gęsto wykorzstuje „typedefowanie” – mam więc i ja :).

Wielokrotnie podczas tworzenia oprogramowania poziomu jądra potrzebne są nam typy, które posiadają ściśle określoną liczbę bitów – 8, 16, 32 itd. Typy o ustalonej długości służą do tworzenia flag, pól bitowych itp. Niestety specyfika architektur i co gorsza – kompilatorów powoduje, iż dany typ (int, short, long) ma często nieznaną z góry bitową długość. Można sobie jednak z tym poradzić tworząc odpowiednie definicje typów jak np. moje:

typedef unsigned int u32int;
typedef signed int s32int;
typedef unsigned short u16int;
typedef signed short s16int;
typedef unsigned char u8int;
typedef signed char s8int;

Dzięki temu, dla każdej architektury można stworzyć taki plik i podczas kompilacji włączać odpowiedni. Takie podejście ma jeszcze jedną zaletę – nazwa s8int (s od signed, 8 od liczby bitów i int od typu całkowitoliczbowego) jest bardziej wymowna niż char :). To pierwszy, malutki krok ku przenośności – wymaga on jednak konsekwencji w stosowaniu.

Opakowanie

W języku C nie da się zaprogramować wszystkiego – czasem trzeba skorzystać z instrukcji assemblera specyficznych dla danej architektury. Bywa jednak, że pewna instrukcja występuje na niemal każdej architekturze, jednak pod inną postacią. Warto wtedy opakować taką instrukcję w odpowiednią funkcję w języku C. Przykładem takiej instrukcji jest instrukcja zatrzymująca prace procesora – dla x86 jest to instrukcja hlt:

inline void hlt()
{
	asm volatile("hlt");
}

Opakowanie jak widać jest banalne, a może w przyszłości oszczędzić wiele kłopotów. Co więcej, możemy ją teraz swobodnie wykorzystywać w wielu miejscach w kodzie w C!

Warto jeszcze zauważyć, że używam składni tzw. inline assembly, która dla GCC jest bardzo specyficzna (czyt. paskudna). Jest jednak o tym dużo artykułów, więc ja się rozpisywać nie będę.

GDT – znowu…

Jakiś czas temu pisałem o multiboot, który ustawia odpowiednio tablicę GDT. Wszystko byłoby pięknie – jest jednak pewien problem – nie wiemy dokładnie gdzie znajduje się ta tablica, nie wiemy również, co tak naprawdę się tam znajduje. Warto więc ustawić ją jeszcze raz – po swojemu i w znanym miejscu, a do tego – używając głównie C. Na początek struktura deskryptora:

typedef struct gdt_descr
{
	u16int limit_low;
	u16int base_low;
	u8int base_middle;
	u8int access;
	u8int granularity;
	u8int base_high;
} __attribute__((packed)) gdt_descr_t;

oraz wskaźnika na samą tablicę:

typedef struct gdt_ptr
{
	u16int limit;
	u32int base;
} __attribute__((packed)) gdt_ptr_t;

W obu przypadkach używam atrybutu packed, który instruuje kompilator, aby nie stosował wyrównania naturalnego dla architektury (to pewien rozdzaj optymalizacji) – tylko aby bajty były ciasno upakowane koło siebie ;). Struktura powyższych typów powinna być jasna. Została ona szeroko omówiona w poprzenich częściach kursu. Pozostałe kwestie są już trywialne, na początek deklaracja tablicy i wskaźnika na nią:

#define GDT_LEN 5

static gdt_descr_t gdt[GDT_LEN];
static gdt_ptr_t gdt_ptr;

funkcja ustawiająca pojedynczy deskryptor:

static void gdt_set_desc(gdt_descr_t* descr, u32int base, u32int limit, u8int access, u8int granularity)
{
        descr->base_low = (base & 0xFFFF);
        descr->base_middle = (base >> 16) & 0xFF;
        descr->base_high = (base >> 24) & 0xFF;
        descr->limit_low = (limit & 0xFFFF);
        descr->granularity = ((limit >> 16) & 0x0F) | (granularity & 0xF0);
        descr->access = access;
}

oraz funkcja ustawiająca poszczególne deskryptory:

void gdt_init()
{
        gdt_set_desc(&gdt[0], 0, 0, 0, 0);                // null
        gdt_set_desc(&gdt[1], 0, 0xFFFFFFFF, 0x9A, 0xCF); // ring0 code
        gdt_set_desc(&gdt[2], 0, 0xFFFFFFFF, 0x92, 0xCF); // ring0 data
        gdt_set_desc(&gdt[3], 0, 0xFFFFFFFF, 0xFA, 0xCF); // ring3 code
        gdt_set_desc(&gdt[4], 0, 0xFFFFFFFF, 0xF2, 0xCF); // ring3 data

        gdt_ptr.base = (u32int) &gdt;
        gdt_ptr.limit = sizeof(gdt_descr_t) * GDT_LEN - 1;

        gdt_set(&gdt_ptr);
}

Warto zauważyć, że tym razem tworzymy dokładnie 5 deskryptorów. Pierwszy z nich to tradycyjnie deskryptor NULL, następnie mamy deskryptory kodu i danych dla przestrzeni jądra oraz deskryptory kodu i danych dla przestrzeni użytkownika. Wszystkie, oprócz NULL, rozciągają się oczywiście na całe 4GiB pamięci – różnią się tylko typem i prawami dostępu. Pozostała już tylko funkcja ustawiająca nową tablicę GDT, czyli gdt_set(), niestety tym razem należy skorzystać z kodu assemblera:

[GLOBAL gdt_set]

gdt_set:
        mov     eax, [esp+4]    ; get passed pointer
        lgdt    [eax]           ; load new GDT pointer

        mov     ax, 0x10        ; load all data segment registers
        mov     ds, ax
        mov     es, ax
        mov     fs, ax
        mov     gs, ax
        mov     ss, ax
        jmp     0x08:.flush     ; far jump to code segment
.flush:
        ret

kod ten jest jednak bardzo prosty i powinien być bez problemu zrozumiały.

VGA

Najstarsza metoda debuggowania programów (podobno odnaleziono ją na ścianach jaskini Lascaux) polega na wypisywaniu otrzymywanych wartości i „ręcznej” ich analizie. Niestety, w przestrzeni jądra jest to często jedyna dostępna możliwość. Warto więc zadbać o taką możliwość od samego początku. W swoim systemie (przynajmniej na razie) wykorzystuję podstawowe możliwości kart zgodnych z VGA, tak jak robiłem to już wcześniej. Funkcja inicjująca wykrywa typ monitora i ustawia odpowiedni adres pamięci zamapowanej na pamięć VGA. Przy wykrywaniu korzystam z pomocnych informacji, które pozostawił BIOS. Ustawiam też wirtualną pozycję kursora:

#define SCREEN_HEIGHT 25
#define SCREEN_WIDTH 80

static u16int* vga_mem;
static int cursor;

void vga_init()
{
        cursor = 0;

        if ((*((volatile u16int*) 0x410) & 0x30) == 0x30) // detecting monochrome monitor
                vga_mem = (u16int*) 0xB0000;
        else
                vga_mem = (u16int*) 0xB8000; // it's color
}

Powyżej widać też definicje wysokości i szerokości typowego monitora VGA, czyli 80×25 znaków.

Pierwszą „piszącą” funkcją jest funkcja czyszcząca ekran:

void vga_cls()
{
        int i;
        for (i = 0; i < SCREEN_WIDTH * SCREEN_HEIGHT; ++i)
                *(vga_mem + i) = (u16int) 3872; // ((((0 << 4) | (15 & 0xFF)) << 8) | 0x20) // white spaces on black background
}

Jak widać, po prostu piszę 80*25 spacji na czarnym tle ;). Jeśli sposób pisania po ekranie nadal jest niejasny, to proponuję spojrzeć na ten wpis.

Najważniejszą funkcją, jest jednak funkcja produkująca napisy na ekranie. Jest ona dosyć skomplikowana, gdyż sterownik VGA nie potrafi wypisywać znaków nowej linii \n, tabulacji \t oraz powrotu karetki \r - są one obsługiwane oddzielnie:

void vga_puts(const char* str)
{
	// white letters on black background
	const u16int attribute = 3840; // ((((0 << 4) | (15 & 0x0F)) << 8))

	int i = 0;
	while (str[i] != '\0')
	{
		if (cursor == SCREEN_WIDTH * SCREEN_HEIGHT)
		{
			vga_scroll();
			cursor = SCREEN_WIDTH * (SCREEN_HEIGHT - 1);
		}

		switch (str[i])
		{
		case '\n':
			cursor = cursor + 80 - cursor % 80;
			break;
		case '\r':
			cursor = cursor - cursor % 80;
			break;
		case '\t':
			// increment to align to 8
			while ((cursor % 80) % 8 != 0)
				++cursor;
			break;
		default:
			vga_mem[cursor] = (u16int) (attribute | str[i]);
			++cursor;
		}

		++i;
	}
}

W przypadku typowego znaku po prostu wpisuję odpowiednią wartość do pamięci pod adresem vga_mem[cursor] i inkrementuję pozycję kursora. Dla \n dodaję 80 (długość linii) a następnie odejmuję tyle, aby powstała liczba była podzielna bez reszty przez 80 - czyli po prostu przechodzę do kolejnej linii. Dla \r robię operację podobną - tyle, że nie dodaję 80, co powinno być oczywiste. Dla \t dodaję do pozycji kursora 1 dopóki pozycja w aktualnym wierszu jest niepodzielna przez 8 (typowe zachowanie tabulacji w systemach UNIX).  Na początku funkcji widać jeszcze obsługę sytuacji, gdy zapełnimy cały ekran znakami - przenoszę wtedy nasz wirtualny kursor na początek ostatniej linijki i wywołuję wtedy scroll(), która przepisuje wiersze "o jeden do góry ekranu" - pierwszy wiersz zostaje nadpisany drugim itd., ostatni wiersz zostaje wyczyszczony:

static void vga_scroll()
{
        int i;
        // rewrite lines one up
        for (i = 0; i < SCREEN_WIDTH * (SCREEN_HEIGHT - 1); ++i)
                vga_mem[i] = vga_mem[i + SCREEN_WIDTH];

        // clear last line
        for(i = 0; i < SCREEN_WIDTH; ++i)
                vga_mem[SCREEN_WIDTH * (SCREEN_HEIGHT - 1) + i] = 3872; // ((((0 << 4) | (15 & 0xFF)) << 8) | 0x20) // white spaces on black background
}

Do boju

Mając pod kontrolą najważniejszą strukturę danych - GDT oraz odpowiednie (acz niekompletne) narzędzia do debuggowania możemy śmiało zagłębiać się w kolejne mechanizmy architektury x86. W końcu, za każdym razem, gdy coś nie zadziała - będziemy mogli sprawdzić dlaczego :).

Typowo, kompletny kod, w którego organizacji zaszły spore zmiany, jest dostępny tu:

git clone git://github.com/luksow/OS.git --branch 0x06

oraz bezpośrednio do obejrzenia tu.

Moja praca inżynierska

Pierwszy semestr działań związanych z pracą inżynierską za mną, pora więc na małe podsumowanie. Tak jak narzekam na wiele aspektów związanych z moimi studiami, to tym razem zdecydowanie są powody do zadowolenia. Poniżej skrótowy opis rozwój „sytuacji” w moim wypadku.

Prolog

Na koniec poprzedniego semestru należało zadeklarować opiekuna i temat pracowni inżynierskiej. Zadanie zdecydowanie niełatwe, szczególnie gdy ma się tylko garstkę własnych doświadczeń i cudzych opinii na temat poszczególnych ludzi. Temat też należy dobrać z głową, jednak tu już prościej – zwykle wiadomo co kogo interesuje :). Ja szczęśliwie nie miałem problemu z doborem prowadzącego – oczywiście chciałem, aby opiekunem pracy został dr inż. Tomasz Jordan Kruk. Wiązało się to z niemałym, papierkowym rajdem po dziekanatach i sekretariatach, jednak bez większych problemów. Problem był natomiast z precyzyjnym tematem pracy. Wiedziałem tylko, że chcę aby dotyczył on zagadnień niskopoziomowych, związanychz  systemami operacyjnymi. Od słowa do słowa, dostałem propozycję zajęcia się systemem Google Chrome OS… i zgodziłem się bez większych oporów :). Pełne brzmienie tematu zostało wybrane jako Budowa systemu Chrome OS – uroczo prawda? Temat zdecydowanie nieoklepany tzn. nieznany, co mogło się wiązać z pewnymi trudnościami.

Zawiązanie akcji

Kolejne tygodnie po wybraniu tematu wiązały się z przekopywaniem Internetu w poszukiwaniu informacji na temat tegoż tworu. Martwiące było to, iż odnalazłem pełno marketingowego bełkotu, a rzetelnych informacji – jak na lekarstwo. W zasadzie jedyne sensowne źródło wiedzy, to strona projektu z dosyć ubogą dokumentacją. Wyzwania – to lubię! Długa i dokładna analiza materiałów przekonały mnie, że najciekawszym elementem systemu Chrome OS są mechanizmy bezpieczeństwa. Za namową Prowadzącego, przez kolejne tygodnie pracowałem nad pierwszym rozdziałem mojej pracy, który nosi tytuł Mechanizmy bezpieczeństwa systemu Google Chrome OS. Muszę przyznać, że to dopiero było wyzwanie! Myśli i treści wiele, jednak ubranie ich w techniczno-naukowy język to prawdziwa sztuka. Uważam się za osobę, która dba o język polski, dlatego każde zdanie składałem z wielkim namaszczeniem. To nie to samo, co blog, gdzie mogę czasem strzelić emotkę, tudzież całkiem kolokwialne stwierdzenie, czy ohydny anglicyzm ;). Ostatecznie, tempo pisania sięgało jednego (sic!) słowa na minutę. Rewelacyjnie, prawda? Efektem tygodni pracy było 16 stron tekstu, z którego naprawdę jestem zadowolony. Mój Opiekun również docenił moją pracę i podsunął mi pomysł, aby zrobić z tego rodziału materiał konferencyjny bądź artykuł – czemu nie!

W tym miejscu wtrącę słówko na temat składania tekstu. Na mojej uczelni (jak zapewne na wielu innych) lansuje się system składu tekstu o intrygującej nazwie LaTeX. Przeczytanie książeczki o tym narzędziu zajęło mi 2 dni, które przepełniły mnie lekką obawą przed czymś z goła innym niż Word ;). Ostatecznie jednak, praca z LateXem okazała się prawdziwą przyjemnością i zdecydowanie ułatwiła mi pracę. Po prostu mogłem skoncentrować się na samym pisaniu, a  nie na ustawianiu marginesów. Z całego serca polecam wszystkim, do każdego rodzaju pisania (prace, dokumentacje, korespondencja, a nawet CV).

Rozwój akcji

Po napisanym rozdziale przyszła pora na wybranie części praktycznej (bo i z tego powinna się składać praca inżynierska). Tu zaczęły się niemałe problemy, bo rozszerzanie Chrome OS może być trudne i niewykonalne w przewidzianym czasie inżynierki. Szczęśliwie, podczas pisania poprzedniego rozdziału natrafiłem na bardzo ciekawą rzecz: koncepcję kontenerów procesów (jest to mechanizm parawirtualizacji o którym niebawem napiszę więcej). Zrodził się więc pomysł, aby rozszerzyć części składowe kontenerów. Ucieszyło mnie to niezmiernie, gdyż oznacza to dużo grzebania w Linuksie! Kolejne 4 tygodnie spędziłem na poznawaniu budowy Linuksa i oswajaniu się z procesem rozwoju jądra. Temat mnie naprawdę wciągnął i z trudem mogłem oderwać się od czytania artykułów i kodu oraz oglądania nagrań z różnych konferencji o tematyce jądra Linuksa. Finalnie, udało mi się zdecydować na rozwijanie mechanizmu cgroups i nad tym będę pracował w najbliższych tygodniach.

Uważny czytelnik może zauważyć, że od chwili wymyślenia tematu zacząłem dosyć mocno się od niego oddalać – i to jest właśnie najlepsza część mojej pracy inżynierskiej – mogę dowolnie zmieniać jej kształt i prowadzić rzeczywiste, odkrywcze badanie, a nie odtwórcze kompilowanie XX źródeł wiadomości. Aktualnie, wygląda na to, że temat będzie brzmiał Mechanizmy zabezpieczeń w nowoczesnych dystrybucjach Linuksa na przykładzie Chrome OS , ale kto wie co przyniesie przyszłość.

I co dalej?

Tak jak pisałem, będę teraz pracował nad praktyczną częścią pracy. Później przyjdzie pora na kolejne rozdziały – jakie? To się jeszcze okaże.

Mała porada

Wszystkim osobom, które dopiero szykują się do pisania pracy inżynierskiej polecam bardzo dobrze zastanowić się nad doborem opiekuna. Nieważne jak zdolni jesteście, dobry mentor może Wam wiele pomóc. Nie chodzi przecież o to, aby prowadził za rękę i pokazywał co, kiedy i ile napisać, tylko o to, aby odpowiednio kierunkował, podpowiadał i ostrzegał przed potencjalnymi zagrożeniami. Temat natomiast, przy współpracy z odpowiednią osobą, wyklaruje się sam.

Koncepcja pamięci wirtualnej

Pamięć

Jednym z zadań systemu operacyjnego jest zarządzanie zasobami – tzn. przydzielanie ich i odbieranie wykonywającym się programom. Pamięć, zaraz po czasie procesora, jest najważniejszym i zarazem najpopularniejszym zasobem, który używany jest przez procesy. Jak pokazuje historia, rozwój pamięci jest bardzo szybki – IBM 7094 z 1962 roku miał standardowo około 150 KiB pamięci, a sam komputer kosztował 3.5 mln USD. Na dzień dzisiejszy, przeciętny komputer ma 10000 razy więcej pamięci i kosztuje 10000 razy mniej :). Z drugiej strony, programy rozrastają się jeszcze szybciej niż dostępna pamięć – 1 MiB wystarczał kiedyś, żeby polecieć w kosmos, natomiast Windows Vista ledwo zipie na komputerze z 1 GiB pamięci ;).

Pamięci powinno być dużo – najlepiej nieskończenie dużo. Do tego jeszcze warto, aby była ona nieskończenie szybka, nieulotna i tania. Niestety – nie da się! W ramach rozwiązania tego problemu wprowadzono koncepcję hierarchii pamięci. Zgodnie z nią komputery wyposażone są w nieco bardzo szybkiej, małej i drogiej pamięci (rejestry, cache); w dużo szybkiej i niedrogiej pamięci (RAM) oraz w ogromnie dużo, bardzo wolnej, ale bardzo taniej pamięci (HDD, DVD itd.). Do wygodnej pracy z taką hierarchią niezbędne jest stworzenie pewnej abstrakcji, która pozwalałaby nie przejmować się tym, czy operujemy na cache’u, RAM-ie, czy wczytujemy wymiecione programy z dysku – ale o tym za chwilę, na razie zajmijmy się najprostszym przypadkiem.

Brak abstrakcji

W tym modelu zarządzania pamięcią, każdy wykonywający się program operuje bezpośrednio na pamięci fizycznej (RAM) – wykonanie instrukcji mov [0x9000], 24 spowoduje wpisanie wartości 24 pod adres 0x9000. Wydaje się to intuicyjnie oczywiste, jednak pociąga to za sobą wiele skomplikowanych problemów. Przede wszystkim ciężko tu zapewnić ochronę – procesy mogą odczytywać i zapisywać pamięć, która nie należy do nich. Do tego, każdy proces musi wiedzieć gdzie został załadowany tak aby instrukcje odwoływania się do pamięci były poprawne. Każdy proces musi również znać i przestrzegać limitów pamięci, które raczej powinny być sztywne. Wszystkie te problemy starano się jakoś rozwiązać i tak np. wprowadzono podział pamięci na pewne zakresy, które przypisywane były procesom poprzez odpowiednie znaczniki. Inny sposób zakłada natomiast wymiatanie całej pamięci na dysk, wybranie kolejnego procesu do wykonania, a następnie wczytanie całej jego pamięci z dysku – jest to rozwiązania wyjątkowo nieefektywne. Dokładniejsze studium przypadku ujawnia wiele kolejnych problemów – np. alokacja dużej tablicy (ciągłej!) w pofragmentowanej przestrzeni może się okazać niemożliwe – potrzebny jest wtedy mechanizm relokacji. Na wiele problemów związanych z brakiem abstrakcji znajdziemy pewne (lepsze lub gorsze) remedium, niestety niektórych rzeczy obejść się nie uda – np. potrzeby powiększenia przestrzeni adresowej ponad dostępna pamięć fizyczną. Na koniec warto jednak dodać, iż całkowity brak abstrakcji na pamięci jest wciąż popularny i uzasadniony – w systemach wbudowanych. Procesy działające w takich systemach są zwykle małe i zaufane – nie potrzebna jest im szczególna ochrona, czy wygoda programowania.

Pamięć wirtualna

Wirtualny – słowo często używane w informatyce, nie zawsze poprawnie, nie zawsze świadomie :). Ciekawy tego co mówi na ten temat słownik języka polskiego – sprawdziłem i zdziwiłem się co nie miara. Nic więc dziwnego, że dezinformacja się szerzy :D. Mówiąc wymijająco (ale za to prawdziwie) – to co znaczy wirtualny – zależy od kontekstu :). Wracając jednak do tematu…

Pamięć wirtualna to mechanizm zapewniający wykonywającemu się programowi dostęp do pełnej, niezależnej od innych procesów przestrzeni adresowej. Przestrzeń ta w szczególności nie musi odpowiadać pamięci fizycznej (co jest sytuacją typową) – może być nieciągła, pofragmentowana i przechowywana na nośnikach trwałych (dysku). Zachodzi więc pewne mapowanie adresu wirtualnego (na którym operuje proces) na adres w pamięci fizycznej. To podejście rozwiązuje nam wszystkie problemy związane z ochroną (oddzielne przestrzenie adresowe = brak możliwości „wchodzenia sobie w drogę”), ładowaniem do pamięci (procesy mogą być np. ładowane pod stały adres), nieciągłością przy alokacji tablic (sprawę załatwia mapowanie – ciągły obszar mapowany jest na nieciągły, który był aktualnie dostępny). Nie ma rzeczy idealnych, więc łatwo się domyślić, że muszą być jakieś wady. Tak jest i tym razem. Pamięć wirtualna znacząco komplikuję budowę architektur (potrzebna jest jednostka zarządzania pamięcią), a także powodują pewien narzut związany z pośredniością, co może mieć znaczenie np. w systemach czasu rzeczywistego.

Dla uzupełnienia dodam, że pamięć wirtualną buduje się w oparciu o pamięć RAM i urządzenia dyskowe. Wspomniany wcześniej cache jest w zasadzie dla programisty i systemu operacyjnego przezroczysty (podsystemy architektury decydują o tym, co ma być cache’owane), a rejestrami zajmują się kompilatory i programiści assemblera (i tak nie przydałyby się w budowaniu pamięci wirtualnej).

Praktycznie

Praktycznie rzecz ujmując pamięć wirtualna jest jak najbardziej pożądana (oprócz wspomnianych systemów czasu rzeczywistego) i w zasadzie nie spotyka się w dużych komputerach jej braku. Pamięć wirtualną realizować można na dwa sposoby – za pomocą segmentacji oraz za pomocą stronicowania (o którym w następnym wpisie), z czego tak jak pisałem, ta druga metoda jest zdecydowanie popularniejsza.

„Daj się poznać” – sukces!

Statystyka

W zeszłym tygodniu minął 10 tydzień pracy nad moim projektem. Na blogu, łącznie z tym, wiszą 23 posty otaggowane „daj się poznać”. 20 z wymienionych, to posty stricte konkursowe, 6 z nich to posty dotykające projektu bezpośrednio, pozostałe 14, to potężna dawka wiedzy przydatnej podczas tworzenia systemu operacyjnego. 3 posty trafiły na dotnetomaniaka, generując znaczny ruch :) Najbardziej popularnym postem, był nieco kontrowersyjny wpis Edytor tekstu zamiast wypasionego IDE?. Skandalizowanie zawsze w cenie? ;>

Kod?

Zabrzmi to śmiesznie, ale projekt ma w obecnym stadium poniżej 100 linii. To dużo i mało jednocześnie. Dużo, gdyż wiedza potrzebna i zalecana do napisania tych <100 linii jest naprawdę obszerna. Mało, gdyż to wciąż tylko <100 linii, gdy inne projekty konkursowe mają ich tysiące. Tak jak wspominałem, projekt nie stanowi pełnoprawnego „produktu”, a jest przedmiotem swoistych badań – i w takiej formie idealnie się sprawdza.

Słodki smak sukcesu

Swój udział w konkursie uważam za ogromny sukces, niezależnie od miejsca, które zajmę. Dzięki Maćkowi, zmobilizowałem się do regularnego pisania postów (choć bywało ciężko). Pokazałem sam sobie, że się da. Jak się okazało – najtrudniej jest zacząć. Bolączką mojego bloga były naprawdę sporadyczne i nietematyczne posty – teraz to się zmieniło. Kolejnym aspektem sukcesu jest pozytywna informacja zwrotna, którą dostałem. Wszystkim, którzy pozytywnie wyrazili się na temat mojej pracy serdecznie dziękuję – to niesamowita motywacja do dalszego działania.

Co dalej?

Projekt i seria postów na temat tworzenia systemu operacyjnego na pewno nie skończy się wraz z konkursem. Całość mam zamiar jeszcze dłuuuuugo kontynuować. Nie mogę zagwarantować, że posty dalej będą pojawiać się tak regularnie, jak przez czas trwania konkursu, postaram się jednak pisać jak najczęściej.

Na koniec

Jeśli seria postów konkursowych przypadła Ci do gustu drogi Czytelniku, nie zapomnij zagłosować na mnie po 15 listopada! Tak czy inaczej, zachęcam do subskrypcji mojego bloga i regularnego zaglądania tutaj! Będzie coraz lepiej – gwarantuję!

Tworzenie systemu operacyjnego – część 0×05: Multiboot Specification

Multiboot Specification

Multiboot Specification jest próbą stworzenia ustandaryzowanego sposobu bootowania systemów operacyjnych. Chodzi o to, aby każdy bootloader zgodny z Multiboot Specification był w stanie bootować każdy system operacyjny również zgodny z Multiboot Specification. Ma to ułatwić tworzenie środowisk z wieloma systemami operacyjnymi.

Multiboot Specification nie definiuje tego, jak ma być napisany bootloader, a jedynie odpowiedni interfejs. Referencyjną implementacją Multiboot Specifciation jest GNU GRUB. Wiele systemów operacyjnych (np. Linux), bootloaderów i maszyn wirtualnych (np. QEMU) jest zgodnych z tą specyfikacją, więc nie jest ona tylko teoretycznym dokumentem. Niezwykle istotną cechą bootloaderów zgodnych z Multiboot Specification jest to, że są one w stanie bootować kernel skompilowany do popularnych formatów plików wykonywalnych np. ELF. Dzięki temu możemy korzystać ze wszelkich dobrodziejstw, które formaty oferują.

O konkretnych cechach Multiboot Specification wspomnę przy okazji kodu, poniżej.

Multiboot Specification mam i ja!

W swoim projekcie systemu operacyjnego postanowiłem porzucić własny bootloader na rzecz bootloadera zgodnego z Multiboot Specification. Może się to wydawać dziwne, bo napisanie całego kodu związanego z bootowaniem zajęło mi sporo czasu, ale tak naprawdę ma to głębokie uzasadnienie. Przede wszystkim, mój bootloader jest bardzo ubogi i prosty – nie potrafi bootować żadnych formatów plików wykonywalnych, a jedynie płaskie binarki, co jest niezwykle uciążliwe, gdyż muszę polegać na magicznych stałych. Ponadto nie dostarcza on żadnych informacji systemowi operacyjnemu – wszystko trzeba zrobić samodzielnie. Oczywiście, można napisać ten kod samodzielnie… Jednak uważam, że nie jest on wystarczająco pasjonujący, aby się nim zajmować :). Dzięki Multiboot Specification będziemy mogli przestać zajmować się szczegółami, a przejść do rzeczy :).

Kod – czyli co my musimy zrobić dla Multiboot Specification, a co on zrobi dla nas?

Na chwilę musimy powrócić do assemblera, aby dostarczyć kilku informacji wymaganych przez bootloader i od razu możemy skoczyć do kodu w C.

global loader				; set visible to linker
extern main				; main from main.c
 
; some useful macro values
FLAGS		equ	0		; this is the multiboot 'flag' field
MAGIC		equ	0x1BADB002	; 'magic number' lets bootloader find the header
CHECKSUM	equ	-(MAGIC + FLAGS); checksum required
STACKSIZE	equ	0x4000		; 16 KiB for stack
 
section .text
align 4
; setting multiboot header
multiboot_header:
	dd	MAGIC
   	dd	FLAGS
   	dd	CHECKSUM
 
loader:
	mov	esp, stack + STACKSIZE	; set up the stack
	push	eax			; pass multiboot magic number as second parameter
	push	ebx			; pass multiboot info structure as first parameter
 
	call	main			; call C code
 
section .bss
align 4
stack:
   	resb 	STACKSIZE		; reserve stack space

Najbardziej istotne są makra z linii 5-7. Pierwsze z nich określa flagi, które informują bootloader, czego od niego oczekujemy. Wśród możliwych opcji jest: wyrównanie modułów do rozmiaru strony, dołączenie mapy pamięci oraz dostępnych trybów video. Po więcej informacji zapraszam tu. Póki co, nie potrzebujemy niczego, stąd wartość 0. Drugie to wartość magiczna, która pozwala bootloaderowi zidentyfikować nagłówek. Liczba 0x1BADB002 jest urocza, prawda? :) Trzecia wartość, to suma kontrolna, która powinna mieć wartość, taką że dodana do pól: FLAGS i MAGIC daje zero.

Kolejne linijki są oczywiste. W sekcji kodu musimy zamieścić kolejno wartość magiczną, flagi oraz sumę kontrolną, co dzieje się w liniach 14-16. Etykieta loader to rzeczywisty punkt wejściowy naszego jądra. W wierszu 19 ustalamy początek stosu, na którego miejsce rezerwujemy w sekcji bss (linia 28). Istotne jest, aby miejsce rezerwowane było w sekcji bss, bo inaczej rezerwacja będzie polegała na stworzeniu dużego pliku z wieloma zerami, a przecież nie o to nam chodzi. Etykieta bss załatwia sprawę – kompilator „wie”, że tylko rezerwujemy przestrzeń w odpowiednim miejscu w pamięci. Następnie w liniach 20 i 21 odkładamy zawartość dwóch rejestrów na stos (istotna jest kolejność – jeśli masz wątpliwości czemu pierwsza instrukcja odpowiada drugiemu parametrowi, spójrz do konwencji wołania) tak, aby przekazać je do funkcji main, którą wołamy w linii 23. Znaczenie przekazanych parametrów omówię poniżej.

Spójrzmy teraz na kod jądra w C:

char hello[] = "Hello from kernel!";

int main(void* mbd, unsigned int magic)
{
	int count = 0;
	int i = 0;
	unsigned char *videoram = (unsigned char *) 0xB8000; /* 0xB0000 for monochrome monitors */

	if ( magic != 0x2BADB002 )
	{
		/* something went wrong.. */
		while(1); /* .. so hang! :) */
	}

	/* clear screen */
	for(i=0; i<16000; ++i)
	{
		videoram[count++] = 'A';
		videoram[count++] = 0x00; /* print black 'A' on black background */
	}

	/* print string */
	i = 0;
	count = 0;
	while(hello[i] != '\0')
	{
		videoram[count++] = hello[i++];
		videoram[count++] = 0x07; /* grey letters on black background */
	}

	while(1); /* just spin */

	return 0;
}

Widzimy, że tym razem do funkcji main przekazane są dwa parametry, które włożyliśmy na stos. Pierwszy z nich to struktura informacyjna dostarczona przez bootloader, która zawiera informacje zarządane za pomocą flag. Druga, to kolejna wartość magiczna, infomująca nas o tym, czy wszystko poszło prawidłowo. Tym razem jest to 0x2BADB002. W liniach 41-45 widzimy bardzo prymitywną :) obsługę sytuacji błędnej. Reszta kodu jest taka, jak w odcinku poprzednim.

Co tak właściwie się stało? Specyfikacja Multiboot zapewnia nam że:

  • rejestr EAX będzie zawierał magiczną wartość 0x2BADB002, jeśli jądro zostało prawidłowo załadowane (stąd wkładanie rejestru EAX na stos w pierwszym przedstawionym kodzie)
  • rejestr EBX będzie zawierał adres struktury informacyjnej z danymi zażądanymi we fladze (stąd wkładanie rejestru EBX na stos w pierwszym przedstawionym kodzie)
  • linia A20 będzie aktywowana
  • rejestry segmentowe będą ustawione tak, aby realizowany był płaski model pamięci
  • będzie aktywowany tryb chroniony procesora
  • bit 17 i 9 rejestru EFLAGS będzie zgaszony

Jak widać, Multiboot Specification zapewnia nam wszystko, co poprzedni bootloader oraz sporo więcej. Więcej na temat struktur i gwarantowanego stanu tutaj.

Skrypt linkera pozostaje prawie bez zmian. Istotne jest, że tym razem musimy zdefiniować punkt wejściowy naszego programu (jądra), czyli etykietę loader oraz to, że możemy zażądać, aby nasz kernel został załadowany daleeeeeko za granicą 1MiB! Ja ładuję go zaraz za tą granicą:

ENTRY (loader)

SECTIONS {
    . = 0x00100000;

    .text : {
        *(.text)
    }

    .rodata ALIGN (0x1000) : {
        *(.rodata)
    }

    .data ALIGN (0x1000) : {
        *(.data)
    }

    .bss : {
        *(.bss)
    }
}

Uważny czytelnik zauważy ustawienie wyrównań (polecenia ALIGN), które jednak aktualnie nie mają dużego znaczenia, więc nie będę ich omawiał.

Pozostała nam kompilacja do formatu elf w wariancie dla architektury i386 (x86):

nasm -f elf -o ./bin/loader.o loader.asm
gcc -o ./bin/main.o -c main.c -m32 -nostdlib -nostartfiles -nodefaultlibs
ld -melf_i386 -T linker.ld -o ./bin/kernel.bin ./bin/loader.o ./bin/main.o

Oraz uruchamianie:

qemu -kernel ./bin/kernel.bin

Użycie QEMU może być zdziwieniem, gdyż nie używamy tu żadnego bootloadera typu GRUB. QEMU jednak, tak jak wspominałem, posiada wbudowany bootloader zgodny z Multiboot Specification. Włącza się go za pomocą przełącznika -kernel. Jeśli ktoś jednak bardzo chce może użyć GRUBa.

To tyle, nasz stuningowany kernel powinien działać.

NIH

Jestem zwolennikiem unikania syndromu NIH, stąd decyzja o użyciu dobrze napisanego i przetestowanego bootloadera zgodnego z Multiboot Specification. Stan naszej wiedzy nie ucierpiał na tej decyzji, gdyż mamy już za sobą napisanie prostego bootloadera :). W przyszłości będzie można do niego wrócić i wzbogacić go o ładowanie plików w formacie ELF i jeszcze kilka ficzerów. Na razie jednak, zajmijmy się tym co najważniejsze, czyli jądrem naszego systemu operacyjnego.

Tradycyjnie, pełen kod odcinka można pobrać tak:

git clone git://github.com/luksow/OS.git --branch 0x05

Lub obejrzeć go tu.

Pliki wykonywalne/obiektowe

Co to?

Uruchomienie programu to czynność oczywista, która polega, z grubsza (w zależności od systemu operacyjnego), na dwukliku na ikonę „pliczek.exe”, wykonania w terminalu polecenia „./kodzik” lub wybrania odpowiedniej pozycji z menu telefonu. Niewiele osób zastanawia się, co tak naprawdę kryje się za wspomnianymi plikami, które powodują uruchomienie programu – nie jest to też wcale takie oczywiste.

Pliki te nazywa się najczęściej wykonywalnymi. Niestety, jak to często bywa, nie ma ogólnoprzyjętego zestawu nazewnictwa i definicji, stąd liczne nieporozumienia między określeniem „plik wykonywalny”, a „plik obiektowym” (polska nazwa jest dla mnie dziwna, po angielsku to object file) – spróbujmy to jakoś ogarnąć. Plikiem obiektowym, najwygodniej jest nazywać każdy plik, który zawiera uporządkowane sekcje kodu maszynowego (składającego się z instrukcji). Dodatkowo, w takim pliku mogą, ale nie muszą, znajdować się dane oraz metadane. Plik wykonywalny, to natomiast rodzaj pliku obiektowego, który może być bezpośrednio wykonany pod kontrolą systemu operacyjnego. Innym przykładem pliku obiektowego może być np. biblioteka dynamiczna/współdzielona.

Wszystkie pliki obiektowe są zapisane na dysku w pewnym ustalonym formacie, zależnym od systemu operacyjnego, w którym mają być uruchamiane. Format ten definiuje w jaki sposób w pliku zapisane są instrukcje, dane i metadane. Instrukcje to po prostu kod maszynowy, dane to wszelkie zmienne i struktury, które są zdefiniowane bezpośrednio w źródle (np. zmienne statyczne, łańcuchy znaków). Metadane to natomiast bardziej skomplikowana sprawa. To, co wchodzi w ich skład zależy przede wszystkim od samego formatu – jego przeznaczenia. Metadanymi są np.: identyfikator formatu (który często jest po prostu „magicznymi liczbami”) umieszczony w nagłówku, wskazówki na temat relokacji, informacje dla debuggera, tablica symboli. To na podstawie metadanych pliku wykonywalnego system operacyjny „wie”, jak rozmieścić kod i dane programu w pamięci i skąd w zasadzie zacząć jego wykonywanie. Metadane pliku wykonywalnego powinny być kompletne, tzn. powinny zawierać pełen opis, pozwalający na uruchomienie programu tak, aby przeniesienie go na analogiczny system operacyjny nie wymagało dodatkowych czynności. Można powiedzieć, iż metadane są instrukcją obsługi do załączonego kodu i danych, dla systemu operacyjnego.

Przykłady

Jak to w życiu bywa – standardy – każdy ma własne ;) Stąd formatów plików obiektowych jest bardzo wiele, może nawet tyle co formatów audio, czy obrazów. Poniżej przedstawiłem króciótką charakterystykę kilku z nich:

  • a.out – pierwotny format plików wykonywalnych UNIXa, który pojawił się tam już w pierwszej wersji, jeszcze na komputery PDP-7. Jest niezwykle prosty i popularny, ale w nowych rozwiązaniach raczej nieużywany. Teraz nietrudno zgadnąć, skąd wzięła się domyślna nazwa programów kompilowanych pod UNIXem :)
  • COFF (Common Object File Format) – format COFF zastąpił a.out na pozycji domyślnego formatu plików  obiektowych (sam został już jednak zastąpiony przez format ELF). W formacie COFF można przechowywać pojedyncze funkcje, symbole, fragmenty programów, biblioteki oraz może być on bezpośrednio wykonywany.
  • ELF (Executable and Linking Format) – ELF zastąpił natomiast COFF na pozycji lidera w systemach uniksopodobnych (i nie doczekał się jeszcze zdetronizowania). Mimo kilku wad, jest dobrze udokumentowany i bardzo popularny. Został opracowany w Unix System Laboratories podczas prac nad sławnym Systemem V R4.
  • COM – wyjątkowo prosty format używany przez MS-DOS. Można powiedzieć, że jest on „płaską binarką” – nie zawiera żadnych nagłówków. W związku z tym, iż pliki o formacie COM wykonywane były w trybie rzeczywistym, są ograniczone co do rozmiaru do wielkości jednego segmentu trybu rzeczywistego.
  • MZ – format MZ zastąpił COM w MS-DOS 2.0 i jest zdecydowanie bardziej zaawansowany ;) Na uwagę zasługuje fakt, że jego nazwa (i jednocześnie identyfikator zawarty w pierwszych dwóch bajtach pliku – 0x4D (M) 0x5A (Z)) wzięła się od inżyniera Marka Zbikowskiego – rodzimo brzmiące nazwisko, prawda? :)
  • NE (New Executable) – format NE zastąpił natomiast MZ i został wprowadzony w Windowsie 3.x. Niestety posiada on limity rozmiaru takie jak MZ oraz również jest 16 bitowy.
  • PE (Portable Executable) – w końcu, współczesny format plików wykonywalnych dla systemu Windows, wprowadzony wraz z wersją 95. Oczywiście jest on 32 bitowy i posiada wiele udogodnień w stosunku do poprzedników. Warto też wspomnieć, iż jest on kontenerem dla binarek .NETa.

Podsumowanie

Celem stosowania formatów jest ustandaryzowanie pewnych kwestii. Jak widać na powyższych przykładach, nie jest to łatwe – każdy chce mieć coś do powiedzenia :) Stosowanie różnych formatów plików obiektowych na różnych systemach operacyjnych sprawia iż „binarki” (pliki wykonywalne) nie są przenośne – uruchomienie skompilowanego, nawet prostego programu typu hello world, nie jest możliwe na obu systemach. Stąd powstały koncepcje wielu emulatorów, jak choćby WINE czy liczne klony „pegasusa” :), które starają się ten problem usunąć.

Nawiązując do projektowania systemów operacyjnych z formatami plików obiektowych spotkać można się np. przy tworzeniu interfejsu binarnego aplikacji czy też kompilując jądro do formatu łatwego do przeczytania przez konkretny bootloader.

Emacs dla C/C++

Co się przydaje?

To czego potrzebuję do pełni szczęścia podczas programowania w C/C++ to:

  • Szybkie działanie edytora
  • Kolorowanie składni
  • Automatyczne formatowanie kodu
  • Inteligentne uzupełnianie kodu
  • Wsparcie dla debuggera
  • Przeglądanie kodu
  • Możliwość rozszerzenia IDE o własne snippety, generację kodu

Wydaje mi się, że moje wymagania nie jest zbyt wygórowane. Niestety, nie jest łatwo o edytor spełniający wszystkie powyższe życzenia. Na szczęście Emacs, po odpowiednim tuningu spełnia wszystkie moje wymagania.

Out of the box

Świeża instalacja Emacsa, w miarę nowej wersji (co do starszych nie mam rozeznania) zapewnia kolorwanie składni, automatyczne formatowanie kodu, wsparcie dla debuggera (gdb) oraz możliwość tworzenia własnych rozszerzeń. Przyzwoicie prawda? Oczywiście wszystko to jest, do granic możliwości, konfigurowalne. Począwszy od zmiany kolorów, poprzez wybór predefiniowanych/własnych stylów formatowania kodu aż do tworzenia własnych skrótów i (mini)skryptów – wszystko to jest oczywiście możliwe! Ponadto, Emacs doskonale integruje się z powłoką systemu, pozwalając na obsługę buildów nie opuszczając edytora.

Na oddzielny akapit zasługuje wspomnienie o tym, że Emacs działa naprawdę szybko, nawet na starych komputerach. Mówiąc szybko, mam na myśli SZYBKO, a nie tak jak Eclipse, czy VS :)

Jest jeszcze kilka cech, których brakuje, ale to załatwiają zgrabne pluginy, o których poniżej.

CEDET

CEDET, czyli Collection of Emacs Development Environment Tools, to kombajn, który obowiązkowo należy doinstalować do Emacsa. Niezależnie jakiego języka programowania używasz, zawsze znajdziesz tu coś dla siebie. Aktualnie, wsparcie dla C/C++ jest najlepiej rozwinięte. Wtyczka oferuje m. in. uzupełnianie kodu, które spokojnie może konkurować z Intellisense z Visual Studio (np. w szybkości działania). Nie są to „naiwne” ctags (dostępne np. w vimie), tylko uzupełnianie z prawdziwego zdarzenia! Niestety, C++ nie jest językiem stworzonym do łatwej analizy, stąd CEDET czasem się myli, ale to raczej wyjątki, niż reguły. Wtyczka posiada również wsparcie dla „code templates” oraz szukanie odniesień w kodzie (do funkcji, metod, klas itd.), które działają całkiem przyzwoicie.

Inne ficzery, których jednak nie używam na co dzień to generacja diagramów UML (!) oraz wsparcie dla zarządzania projektami. Wśród obsługiwanych (lepiej lub gorzej) języków znajdują się: C, C++, Java, Emacs Lisp, Make, Scheme, Erlang, Texinfo, HTML, CEDET, Awk,  Simula, JavaScript, Python, C#, PHP, Ruby, SRecode Templates, Bourne Shell, Scala, dot. Niestety, wsparcie dla wielu z nich, pozostawia wiele do życzenia.

ECB

ECB – Emacs Code Browser, to wtyczka, wymagająca do działania wspomnianego wyżej dodatku CEDET, która zapewnia wygodne i sprawne przeglądanie kodu. Dzięki ECB zyskujemy, okienko (oczywiście w pełni konfigurowalne) umożliwiające nawigację po strukturze katalogów. Niby to nic takiego, ale jeśli rozważymy dowolną możliwość konfiguracji, to da się dzieki temu pluginowi uzyskać naprawdę ciekawe efekty.

Dla wymagających

Jeśli powyższy zestaw funkcjonalności to dla Was za mało, możecie poszperać i znaleźć tysiące, setki tysięcy rozszerzeń do Emacsa wszelkiej maści. Wszak legenda głosi, że do Emacsa napisano już wszstko :) Będzie więc bardzo łatwo o narzędzia dodające obsługę systemów kontroli wersji, czy generacje dokumentacji na podstawie kodu. Szukanie można rozpocząć np. tu.

Na koniec

Mój poprzedni post o edytorach tekstu wzbudził bardzo duże zainteresowanie, można więc spodziewać się więcej postów w tym temacie. W przyszłości m. in. zaprezentuję swój config i ujawnię cały zestaw dodatków, których używam :)

Poniżej zamieszczam screena prezentującego trio Emacs + CEDET + ECB w akcji:

Po lewej widać okienko ECB, z drzewem katalogów. Górne okienko zawiera kod, natomiast dolne – propozycje uzupełnienia kodu. Oczywiście okienko z kodem podczas pisania nie jest takie małe. Normalnie okienka ECB oraz „code completion” są ukryte. Screen natomiast nie oddaje nawet połowy pozytywnych wrażeń z użytkowania dobrze skonfigurowanego Emacsa. Polecam spróbować!

Tworzenie systemu operacyjnego – część 0×04: Kernel w C

Assemblerowi już dziękujemy

Assembler, mimo swego ukrytego piękna, jest dosyć męczącym językiem jeśli chodzi o programowanie dużych projektów. Brak jakiegokolwiek poziomu abstrakcji pozwala na pełną kontrolę wydajności, kosztem dużego nakładu pracy na pisanie i poprawianie kodu ;) Idealnym następcą assemblera zdaje się być język C, który oferuje przyzwoitą wydajność, oferując przy tym podstawowe i wystarczające mechanizmy do programowania projektów wymagających niskopoziomowego podejścia. Niebezpodstawnie najważniejsze i największe projekty powstały właśnie w tym języku – UNIX (i wszystkie pochodne), Windows, MacOS X oraz Quake III – to wszystko projekty stworzone (głównie) w C.

Mój system operacyjny będzie również w zdecydowanej większości napisany w C. Lubię ten język za prostotę, a jednocześnie ogrom możliwości. Na C++ i inne bajery przyjdzie jeszcze czas :)

Ostatnie pożegnanie

Nim porzucimy assemblera, musimy ustawić jeszcze kilka rzeczy. Wróćmy więc do kodu z wcześniejszego odcinka serii i odpowiednio go zmodyfikujmy:

[BITS 32]
clear_pipe:
	mov	ax, 0x10	; GDT address of data segment
	mov	ds, ax		; set data segment register
	mov	ss, ax		; set stack segment register
	mov	esp, 0x9000	; set stack
	mov	ebp, esp	; set bracket pointer
	jmp	0x7F00		; jump to code
	times 256-($-$$) db 0	; fill rest with zeros for alignment

W liniach 74-76 po raz kolejny przypomina nam o sobie segmentacja. Musimy ustawić rejestry DS i SS (data segment i stack segment) na odpowiedni adres w tablicy GDT. Przypominam, że trzeci deskryptor (po code i null) ustawiliśmy jako segment danych, stąd adres 0x10 (wynika to z budowy selektora!). Kolejnym krokiem jest ustawienie stosu i ramki stosu – robimy to nieco „na pałę” wybierając fragment wolnej pamięci i ustawiając tam początek stosu. Na koniec pozostaje tylko skoczyć do kodu. Tu jednak należy się ważna uwaga. Wyrównanie w architekturze x86 to zdecydowanie pożądana sprawa – zapewnia poprawność i optymalność. Stąd wypełnienie do 256 bajtów w linii 80. Dzięki temu możemy łatwo obliczyć, gdzie znajdzie się nasz kod. Bootloader załadowany jest pod adres 0x7C00, zajmuje 512 bajtów, ustawienie środowiska zajmuje 256 bajtów, stąd 0x7C00 + 512 + 256 = 0x7F00, co ma swoje odzwierciedlenie w linii 79. To tyle, możemy się pożegnać z asmem.

Jego wysokość – C

Od teraz możemy pisać w C. Napiszemy więc prosty kod, który wyczyści ekran i wypisze na nim przykładowy napis, a nastepnie zawiśnie w nieskończonej pętli. Pisanie na ekran w trybie chronionym wygląda inaczej niż w trybie rzeczywistym, ale jest równie łatwe. Aby wypisać coś na ekranie używamy zamapowanego obszaru pamięci dla karty graficznej – dla kolorowych monitorów obszar ten zaczyna się od adresu 0xB8000, a dla monitorów monochromatycznych od adresu 0xB0000. Każda literka składa się z dwóch bajtów – pierwszy z nich to znak w ASCII, drugi to kolor i tło (podobnie do trybu rzeczywistego). Zapisując takie pary pod kolejne adresy począwszy od wskazanych powyżej – otrzymujemy napis na ekranie. Więcej na temat można przeczytać np. tu. Spójrzmy na kod:

char hello[] = "Hello from kernel!";

int main()
{
	int count = 0;
	int i = 0;
	unsigned char *videoram = (unsigned char *) 0xB8000; /* 0xB0000 for monochrome monitors */

	/* clear screen */
	for(i=0; i<16000; ++i)
	{
		videoram[count++] = 'A';
		videoram[count++] = 0x00; /* print black 'A' on black background */
	}

	/* print string */
	i = 0;
	count = 0;
	while(hello[i] != '\0')
	{
		videoram[count++] = hello[i++];
		videoram[count++] = 0x07; /* grey letters on black background */
	}

	while(1); /* just spin */

	return 0;
}

Myślę, że nie wymaga on większego komentarza. Najpierw czyścimy ekran pisząc czarne literki na czarnym tle - wypełniamy tak całą pamięć video, która powinna wynosić 16000 bajtów. Następnie przystępujemy do wypisania napisu, a na końcu kręcimy się w nieskończonej pętli. Proste, prawda?

Linkowanie

Pozostał jeszcze problem kompilacji. Jak skompilować ten kod, aby zadziałał? Należy skłonić kompilator, aby wygenerował kod w postaci płaskiej binarki, ale.. skąd będzie wiedział, gdzie zaczyna się kod i poszczególne dane? Za to odpowiedzialny jest linker (konsolidator). Nie będę tutaj omawiał do czego konsolidator służy, gdyż myślę, że jest to wiedza dosyć elementarna. W razie czego można się doszkolić tutaj. Po kolei - zacznijmy od kompilacji:

gcc -m32 -c -o ./bin/main.o main.c

Wygeneruje nam to plik obiektowy w formacie ELF, lecz nie jest to dla nas istotne. Należy pamiętać o przełączniku -m32  (w przypadku gdy używamy systemu 64 bitowego), który kompiluje kod z myślą o architekturze x86.

Kolejnym krokiem jest odpowiednie przekształcenie pliku obiektowego do postaci binarnej. W tym celu musimy użyć linkera z odpowiednim skryptem:

OUTPUT_FORMAT("binary")
OUTPUT_ARCH ("i386")
ENTRY (main)

SECTIONS
{
	. = 0x7F00;
	.text : { *(.text) }
	.data : { *(.data) }
	.bss : { *(.bss) }
	.rodata : { *(.rodata) }
}

Pisanie skryptów linkera jest trudne i nie będę póki co omawiał szczegółów. Nieco informacji w przyzwoitej formie można znaleźć tu. W linii 1 wskazujemy typ pliku jaki chcemy uzyskać (płaska binarka). Linia 2 to docelowa architektura, natomiast w linii 3 informujemy konsolidator, że punktem wejścia do naszego programu jest funkcja main. Od linii 5 zaczynają się schody - deklaracja poszczególnych sekcji programu. W linii 7 deklarujemy, iż cały program będzie załadowany pod adresem 0x7F00 i od tego adresu mają zaczynać się kolejne sekcje (linie 8 - 11) w kolejności text (kod), data (dane), bss (dane niezainicjalizowane), (rodata) dane tylko do odczytu. Linker jest na tyle "inteligentny", iż potrafi obliczyć sobie odpowiednie przesunięcia na podstawie długości poszczególnych sekcji, zaczynając od adresu wskazanego w linii 7.

Teraz pozostaje już tylko uruchomić konsolidator:

ld -T linker.ld ./bin/main.o -o ./bin/main.bin

I gotowe! Możemy uruchamiać nasz zaczątek kernela, napisany w C :)

Niemiły zapach...

Odwaliliśmy kawał dobrej roboty. Możemy od teraz swobodnie pisać kod kernela w C. Jak pewnie zauważyliście, mamy w kodzie sporo "magicznych" wartości, które co gorsza uzależnione są od rozmiarów poszczególnych fragmentów kodu. Dodatkowo, nie mamy kontroli co, gdzie i jak ładowane jest do pamięci - wszystko leży gdzieś koło siebie. Postaramy się rozwiązać (dosyć drastycznie) ten problem w nastepnym odcinku serii.

Pełen kod odcinka można pobrać tak:

git clone git://github.com/luksow/OS.git --branch 0x04

Lub obejrzeć go tu.

Tworzenie systemu operacyjnego – część 0×03: Przejście do trybu chronionego

Potrzebna wiedza

W końcu nadszedł dzień, w którym nasz system operacyjny będzie działał w trybie chronionym :) Do zrozumienia odcinka 0x03 potrzebna będzie wiedza na temat używania sprzętu poprzez porty, linii A20, segmentacji i jej realizacji w x86 czyli GDT oraz tego, czym jest sam tryb chroniony. Po zdobyciu tych nietrywialnych informacji, możemy przejść do sedna.

Skok

W poprzednim odcinku ładowaliśmy zawartość dysku do pamięci. Wykorzystamy teraz tę umiejętność do załadowania kodu przejścia. Musimy zatem zamienić linijkę w której haltowaliśmy procesor na linijkę:

jmp	0x0000:0x7E00	; jump to setup code

która skoczy pod adres, do którego załadowaliśmy zawartość dysku.

Halo? A20?

Teraz, zgodnie z arkanami sztuki powinniśmy odblokować linię A20.., ale zaraz! Może producent sprzętu zrobił to za nas? Poniższy kod sprawdzi czy linia A20 jest gotowa do użycia:

[ORG 0x7E00]			; here is where our code will be loaded
[BITS 16]

check_a20:			; check if A20 is not enabled, it's all about comparing 0xFFFF:0x7E0E with 0xAA55 - for wrapping memory
	mov	ax, 0xFFFF
	mov	es, ax
	mov	di, 0x7E0E
	mov	al, byte[es:di]
	cmp	al, 0x55	; comparing with 0x55 (first part)
	jne	enter_pmode	; if first byte is not wrapping around then second of course too
	; now we have to check if it not happened by chance
	mov	al, 0x69	; therefore we will set first byte and check results
	mov	byte[es:di], al	; load new value
	mov	bl, byte[0x7DFE]	; load old value
	cmp	bl, 0x69
	jne	enter_pmode

Pamiętamy, że ostatnie 2 bajty bootloadera, załadowane do pamięci to zawsze 0xAA55, wiemy też, że jeśli A20 nie jest aktywna, to po granicy 1MiB pamięć zawija się. Wykorzystajmy więc sprytnie ten fakt – jeśli A20 jest nieaktywna, to nasze bajty bootloadera odnajdziemy pod adresem o 1MiB dalej, niż rzeczywiście są. 0xAA55 znajduje się pod adresem 0x7DFE, a więc odpowiednik powinien być pod adresem FFFF:7E0E.

Nasz kod robi proste porównanie. Jeśli pierwszy bajt nie jest równy temu 1 MiB dalej, to znaczy, że A20 jest aktywna (linia 10). Z tego, że jest równy, nie możemy niestety wnioskować, że A20 jest nieaktywna – bo może być to przypadek. Musimy więc pamięć za granicą 1MiB, odpowiadającą bootloaderowi, ustawić na pewną wartość (linia 13), a następnie odczytać zawartość adresu 0x7DFE (linia 14) i sprawdzić, czy są równe (linia 15). Jeśli są równe, musimy spróbować aktywować linię A20. Może wydawać się to skomplikowane, ale tak naprawdę to dosyć prosty trik.

Aktywacja A20

Linię A20 spróbujemy aktywować na 2 sposoby – przerwaniem BIOS-u oraz klasycznie – kontrolerem klawiatury. Oczywiście nie wyczerpuje to szerokiego repertuaru sposobów i w profesjonalnym systemie operacyjnym musielibyśmy postarać się bardziej. Więcej metod tu.

Spójrzmy na kod:

enable_a20:			; let's enable A20 line first, we'll use only basic methods
	; first, try enabling it via BIOS
	mov	ax, 0x2401
	int	0x15
	jnc	enter_pmode

	; then try conventional way - keyboard controller
	call	wait_a20
	mov	al, 0xD1 	; proper value
	out	0x64, al 	; proper port
	call	wait_a20 	; wait
	mov	al, 0xDF	; proper value
	out	0x60, al	; proper port
	call	wait_a20	; wait
	jmp	enter_pmode	; not so safe assumption that we enabled A20 line...


wait_a20:			; waits for keyboard controller to finish
	in	al, 0x64
	test	al, 2
	jnz	wait_a20
	ret

Linijki 20 – 21 to standardowe wywołanie przerwania. Przerwanie to ustawia flagę carry, jeśli się nie powieidzie, stąd kontrola w linii 22. Więcej o tym przerwaniu można przeczytać tutaj.

Druga metoda wymaga o wiele więcej kodu. Funkcja wait_a20 jest funkcją aktywnego oczekiwania na kontroler klawiatury. Musimy ją wywoływać po każdej próbie zapisu. Sama procedura zapisu do kontrolera klawiatury też jest nietrywialna – najpierw musimy wysłać do portu 0x64 wartość 0xD1 (linia 27), a następnie wysłać do portu 0x60 wartość 0xDF (linia 30). Po wykonaniu tych operacji zakładamy, że linia A20 jest aktywna, choć tak naprawdę, nie możemy być tego pewni.

GDT

Przed przejściem do trybu chronionego musimy ustawić tablicę GDT:

gdt:
gdt_null:
	dq	0		; it's just null..
gdt_code:
	dw 	0xFFFF		; limit (4GB)
	dw	0		; base (0)
	db	0		; base (still 0)
	db	10011010b	; [present][privilege level][privilege level][code segment][code segment][conforming][readable][access]
	db	11001111b	; [granularity][32 bit size bit][reserved][no use][limit][limit][limit][limit]
	db 	0		; base again
gdt_data:
   	dw	0xFFFF		; it's just same as above
   	dw	0		; it's just same as above
	db	0		; it's just same as above
	db	10010010b	; [present][privilege level][privilege level][data segment][data segment][expand direction][writeable][access]
	db 	11001111b	; it's just same as above
	db 	0		; it's just same as above
gdt_end:

gdt_desc:
   	dw 	gdt_end - gdt	; it's size
   	dd	gdt		; and location

Tablica zawiera 3 deskryptory. Pierwszy z nich to null descriptor, który jest zawsze wymagany (niektóre emulatory, np. BOCHS narzekają na jego brak). Drugi deskryptor to deskryptor kodu, który rozciąga się na całą 4GiB przestrzeń adresową. Ostatni deskryptor, to deskryptor danych, który również rozciąga się na całe 4GiB przestrzeni adresowej. W ten sposób otrzymujemy płaski model pamięci, w którym nie widać segmentacji. Ustawień poszczególnych bitów nie będę tłumaczył, gdyż są one opisane w kodzie, a dokładniejsze informacje można znaleźć w moim artykule. Warto zwrócić uwagę na sprytne oznaczenie deskryptorów poprzez etykiety gdt oraz gdt_end, co umożliwia nam eleganckie i poprawne ustawienie rozmiaru (linia 69) oraz adresu (linia 70) w strukturze opisującej GDT.

pmode!!!

Uff, teraz możemy już naprawdę przejść do trybu chronionego.

enter_pmode:
	cli
	lgdt 	[gdt_desc]
	mov 	eax, cr0
	or 	eax, 1
	mov 	cr0, eax
	jmp 	0x8:clear_pipe	; do the far jump, to clear instruction pipe

Aby przejść do trybu chronionego musimy upewnić się, że przerwania są wyłączone (linia 42). Zalecane jest także wyłączenie przerwań niemaskowalnych (NMI), ale nie jest to konieczne. W linii 43 ładujemy strukturę opisującą GDT to rejestru gdtr. Aby aktywować tryb chroniony musimy ustawić najmłodszy bit rejestru CR0 – dzieje się to w liniach 44, 45 oraz 46. Po wykonaniu instrukcji z linii 46 jesteśmy już w trybie chronionym! Pięknie, prawda? :) Niestety, w kolejce instrukcji pozostały śmieci po trybie rzeczywistym. Musimy ją oczyścić robiąc skok długi. Dokonujemy tego w linii 47. Pierwszy człon adresu wskazuje nam, którego deskryptora z GDT chcemy użyć – 0x8 odpowiada pierwszemu indeksowi w tablicy GDT (inne pola selektora zajmują bity 0 – 2, 3 bit, to pierwszy bit indeksu); drugi człon, to po prostu adres w naszym kodzie. Załadowanie CS odpowiednią wartością powoduje faktyczne przejście do trybu chronionego.

No i jesteśmy!

Ostatni fragment kodu to po prostu zatrzymanie się w, mlekiem i miodem płynącej, krainie 32 bitowej:

[BITS 32]
clear_pipe:
	hlt			; in pmode :)
	jmp clear_pipe

Co teraz?

Świat stoi teraz przed nami otworem! Możemy korzystać ze wszystkich dobrodziejstw architektury x86, które opisywałem tutaj. Następnym krokiem powinno być prawdopodobnie ustawienie zarządzania pamięcią i obsługa przerwań, ale wcale nie musimy tego robić. Możemy równie dobrze w tym miejscu napisać kod obliczający kolejne liczby pierwsze i w taki sposób być autorem jedynego systemu operacyjnego na świecie, który takie coś robi ;). Tak więc – do dzieła! Aha, jeśli tu dotarłeś, to należą Ci się gratulacje – większość początkujących osdevowców nie osiąga trybu chronionego.

W następnym odcinku porzucimy trudny i męczący assembler i spróbujemy coś napisać w zgrabnym C!

Pełny kod odcinka można pobrać tak:

git clone git://github.com/luksow/OS.git --branch 0x03

Lub po prostu obejrzeć go tu.