Systemy Operacyjne – semestr drugi
Wyk ad pierwszy
ł
„Rodowód” Linuksa
Inspiracj dla autora systemu Linux by system Minix napisany przez Andrew Tanenbauma, który bazowa z kolei na
ą
ł
ł
systemie Unix. Termin Unix w obecnych czasach oznacza ca rodzin systemów operacyjnych opartych na wspólnej
łą
ę
filozofii, której ród em jest projekt systemu operacyjnego, jaki powsta w roku 1969 w Bell Labs, b d cych cz ci
ź
ł
ł
ę ą
ęś ą
ameryka skiego koncernu AT&T. System ten jest pochodn innego systemu operacyjnego Multics, nad którego
ń
ą
powstaniem pracowano w trzech o rodkach: w MIT, w AT&T i w General Electric. Firma AT&T po pewnym czasie
ś
wycofa a si z prac, ale osoby zatrudnione przy tym projekcie pozosta y jej pracownikami. Do ich grona nale eli mi dzy
ł
ę
ł
ż
ę
innymi Ken Thompson, Dennis Ritchie i Douglas McIlroy. To ta trójka odegra a najwi ksz rol w powstaniu pierwszej
ł
ę
ą
ę
wersji systemu Unix. Prac nad ni rozpocz li Ken Thompson i Dennis Ritchie, pisz c ca y kod w assemblerze
ę
ą
ę
ą
ł
komputera PDP-7, który poznali tworz c wcze niej gr „Space Travel” dla tej platformy sprz towej. Znacz cy wk ad do
ą
ś
ę
ę
ą
ł
projektu systemu wniós Douglas McIlroy, opracowywuj c np.: cza nienazwane, które s jednym z rodków
ł
ą
łą
ą
ś
zapewniaj cych komunikacj mi dzy procesami, a tak e wyznaczaj c regu y tworzenia kodu, które dzi s cz ci
ą
ę
ę
ż
ą
ł
ś ą
ęś ą
in ynierii oprogramowania. W
ż
roku 1973 kod ród owy Uniksa zosta w wi kszo ci przepisany w j zyku C, który
ź
ł
ł
ę
ś
ę
opracowa Dennis Ritchie
ł
1
, dzi ki czemu system ten sta si atwy w przenoszeniu na inne platformy sprz towe
ę
ł
ę ł
ę
2
.
W roku 1980 roku AT&T zacz o sprzedawa wersj systemu Unix, któr nazwano System III. Wersja ta by a
ęł
ć
ę
ą
ł
rozprowadzana razem z kodem ród owym, a wi c wiele firm i innych instytucji, które naby o ten system, mog o go
ź
ł
ę
ł
ł
modyfikowa wprowadzaj c nowe funkcjonalno ci. Pod wzgl dem wprowadzonych do tego systemu innowacji
ć
ą
ś
ę
wyró nia si Uniwersytet Berkeley. Wszystkie wersje systemu Unix, które powsta y w tej placówce by y oznaczane
ż
ł
ę
ł
ł
nazw BSD (Berkeley System Distribution). Najwi kszy wk ad do prac nad Uniksem BSD wniós Bill Joy. To
ą
ę
ł
ł
w Berkeley powsta s ynny edytor vi, pow oka csh, a tak e tu dodano do j dra podsystemy odpowiedzialne za obs ug
ł ł
ł
ż
ą
ł
ę
protoko u TCP/IP i pami wirtualn . Z czasem te funkcjonalno ci zosta y w czone do dystrybucji rozpowszechnianej
ł
ęć
ą
ś
ł
łą
przez AT&T (wersja System V). W chwili obecnej rozwój ga zi BSD jest kontynuowany przez takie projekty, jak
łę
FreeBSD, OpenBSD, NetBSD i DragonFly BSD. Aby uporz dkowa rozwój Uniksa opracowano kilka standardów,
ą
ć
z których najwa niejszymi s POSIX oraz SUS. Wi kszo odmian Uniksa spe nia
ż
ą
ę
ść
ł
wymagania tych standardów.
W chwili obecnej niemal e wszystkie odmiany Uniksa to systemy wielodost pne i wielozadaniowe, obs uguj ce
ż
ę
ł
ą
wszystkie cechy nowych architektur sprz towych. Jest jednak e kilka cech, które odró niaj go od innych systemów
ę
ż
ż
ą
operacyjnych. Przede wszystkim jest on systemem o stosunkowo prostej budowie (jego twórcy stosowali zasad Keep It
ę
Small and Simple – KISS
3
). J dro Uniksa implementuje niewielk liczb wywo a systemowych, podczas gdy w innych
ą
ą
ę
ł ń
systemach ta liczba dochodzi do dziesi tek tysi cy. Wywo ania systemowe w Uniksie zosta y opracowane w my l
ą
ę
ł
ł
ś
zasady sformu owanej przez Douglasa McIlroy'a: „Rób jedn rzecz, ale rób j dobrze”, co oznacza, e wykonuj jedn
ł
ą
ą
ż
ą
ą
czynno , ale w sposób uniwersalny. Wi kszo
elementów w systemie Unix jest traktowana jako plik, co znacznie
ść
ę
ść
u atwia zarz dzanie urz dzeniami i
ł
ą
ą
danymi. W ko cu Unix ma mechanizmy, które pozwalaj na tworzenie w krótkim
ń
ą
czasie nowych procesów, oraz dostarcza rodków prostej komunikacji mi dzy nimi
ś
ę
4
. Unix by tak e jednym
ł
ż
z pierwszych systemów operacyjnych, które zosta y napisane w j zyku wysokiego poziomu, co uczyni o go systemem
ł
ę
ł
przeno nym.
ś
Historia Linuksa
Linux
5
jest systemem uniksopodobnym (ang. Unix-like), ale nie jest Uniksem. Prac nad j drem tego systemu
ę
ą
rozpocz Linus Benedict Torvalds w roku 1991, wzoruj c si na wspomnianym systemie Minix. Nie oznacza to jednak,
ął
ą
ę
e kod przez niego napisany zawiera fragmenty kodu Miniksa lub oryginalnego Uniksa. Linux powsta „od zera”, ale
ż
ł
jest zgodny z standardami POSIX i SUS. Pierwsza wersja kodu ród owego Linuksa mia a ponad 10 tysi cy wierszy
ź
ł
ł
ę
kodu. Bie ce wersje licz oko o 5 milionów linii kodu i s tworzone przez obszern grup programistów,
żą
ą
ł
ą
ą
ę
wspó pracuj cych ze sob przez Internet. Prace tej grupy koordynuje oczywi cie Linus Torvalds. Kod ród owy Linuksa
ł
ą
ą
ś
ź
ł
dost pny jest na zasadach licencji GNU GPL v2.0, która gwarantuje, e jest on wolnodost pny. Nale y zauwa y , e
ę
ż
ę
ż
ż ć ż
s owo Linux ma dwa znaczenia. W powy szym tek cie oznacza o ono po prostu j dro systemu operacyjnego. W drugim
ł
ż
ś
ł
ą
znaczeniu, oznacza podstawow wersj systemu operacyjnego, która oprócz j dra zawiera równie zestaw narz dzi do
ą
ę
ą
ż
ę
kompilacji programów w j zykach C i assembler, bibliotek j zyka C i pow ok systemow . Wszystkie wymienione tu
ę
ę ę
ł
ę
ą
elementy, oprócz j dra, zosta y stworzone przez fundacj GNU, za o on przez Richarda Stallmana. Istnieje wiele
ą
ł
ę
ł ż
ą
odmian systemu Linux, nazywanych dystrybucjami, które oprócz wymienionych tu podstawowych narz dzi zawieraj
ę
ą
równie inne oprogramowanie np. system X Window, b d cy implementacj interfejsu graficznego u ytkownika, oraz
ż
ę ą
ą
ż
1
Pozosta cz
pozostawiono w assemblerze.
łą
ęść
2
Dok adniej – atwiej by o go przenie na inne platformy, ni system napisany w ca o ci w assemblerze.
ł
ł
ł
ść
ż
ł ś
3
W a ciwie ten skrót rozwijano jako "Keep It Simple, Stupid!". Osobi cie wol wersj agodniejsz :-)
ł ś
ś
ę
ę ł
ą
4
Ostatnio pojawiaj si g osy, e te mechanizmy komunikacji staj si powoli przestarza e.
ą
ę ł
ż
ą
ę
ł
5
W kwestii j zykowej: piszemy Linux, ale odmieniamy: Linuksa, Linuksowi, itd.
ę
1
Systemy Operacyjne – semestr drugi
szereg innych aplikacji, niezb dnych u ytkownikom. W dalszej cz ci wyk adu s owo „Linux” b dzie oznacza o
ę
ż
ęś
ł
ł
ę
ł
wy cznie j dro systemu operacyjnego. Pierwotnie Linux przeznaczony by wy cznie na architektur i386 (powsta na
łą
ą
ł
łą
ę
ł
komputerze wyposa onym w procesor Intel 80386). Obecnie obs uguje obs uguje ca gam mniej lub bardziej
ż
ł
ł
łą
ę
popularnych platform sprz towych, takich jak : AMD64, PowerPC, Sparc, Ultra Sparc, MIPS. Wspiera równie
ę
ż
architektury równoleg e (SMP, ostatnio NUMA).
ł
Zasada dzia ania j dra
ł
ą
J dro (
ą
ang. kernel
) systemu (nazywane czasami rdzeniem (ang. core)) jest cz ci systemu operacyjnego, która stale
ęś ą
rezyduje w pami ci komputera, nadzoruje prac sprz tu i aplikacji u ytkownika, oraz dostarcza tym ostatnim
ę
ę
ę
ż
okre lonych us ugi. Najcz ciej j dro (monolityczne) zawiera takie elementy, jak: procedury obs ugi przerwa ,
ś
ł
ęś
ą
ł
ń
mechanizm szeregowania, mechanizm zarz dzania pami ci i obs ugi plików. J dro pracuje w trybie
ą
ę ą
ł
ą
uprzywilejowanym, co oznacza, e ma nieograniczony dost p do wszystkich zasobów systemu komputerowego, w tym
ż
ę
do pami ci operacyjnej. Obszar pami ci zajmowany przez j dro nazywany jest
ę
ę
ą
przestrzeni adresow j dra
ą
ą ą
. Dosyć
cz sto o czynno ciach wykonywanych przez j dro mówimy, e zachodz w
ę
ś
ą
ż
ą
przestrzeni j dra
ą
. Procesy u ytkownika
ż
pracuj w trybie procesora, w którym dost p do zasobów systemu jest ograniczony. Obszary pami ci
ą
ę
ę
przyporz dkowane aplikacjom u ytkownika nazywamy
ą
ż
przestrzeni adresow u ytkownika
ą
ą
ż
. Analogicznie jak ma to
miejsce w przypadku j dra, o czynno ciach, które s wykonywane przez aplikacje mówimy, e s wykonywane
ą
ś
ą
ż
ą
w przestrzeni u ytkownika
ż
. Do komunikacji mi dzy procesami u ytkownika, a j drem s u
ę
ż
ą
ł żą wywo ania systemowe
ł
.
Zazwyczaj aplikacje u ytkownika nie wywo uj ich bezpo rednio, lecz korzystaj z funkcji dost pnych w standardowej
ż
ł ą
ś
ą
ę
bibliotece j zyka C (
ę
libc
). Niektóre z tych funkcji zawieraj sam kod wywo ania funkcji systemowej, czyli s swego
ą
ł
ą
rodzaju „opakowaniami” na wywo ania systemowe, inne funkcje wykonuj przed zainicjalizowaniem wywo ania
ł
ą
ł
systemowego dodatkowe czynno ci, jeszcze inne mog korzysta z wi kszej liczby wywo a systemowych. S równie
ś
ą
ć
ę
ł ń
ą
ż
funkcje, które nie korzystaj w ogóle z wywo a systemowych. Je li j dro wykonuje za po rednictwem wywo ania
ą
ł ń
ś
ą
ś
ł
systemowego jak
us ug dla aplikacji u ytkownika, to dzia a w
ąś
ł
ę
ż
ł
kontek cie procesu
ś
, co oznacza, e kod j dra
ż
ą
realizuj cy to wywo anie ma dost p do informacji o procesie, który korzysta z tego wywo ania. W takiej sytuacji mo na
ą
ł
ę
ł
ż
równie powiedzie , e aplikacja wykonuje wywo anie systemowe w przestrzeni j dra, cho nie jest to okre lenie
ż
ć ż
ł
ą
ć
ś
poprawne. J dro systemu jest oprogramowaniem sterowanym zdarzeniami. Zdarzenia pochodz ce od sprz tu s
ą
ą
ę
ą
sygnalizowane za pomoc
ą przerwań. Te przerwania pojawiaj si zazwyczaj asynchronicznie
ą
ę
6
. Z ka dym z nich jest
ż
zwi zany pewien numer, na podstawie którego j dro odnajduje i wykonuje odpowiedni procedur obs ugi tego
ą
ą
ą
ę
ł
przerwania. Te procedury s wykonywane w
ą
kontek cie przerwania
ś
, co oznacza, e nie s zwi zane z adnym
ż
ą
ą
ż
konkretnym procesem. Pozwala to przyspieszy ich dzia anie. J dro ma równie mo liwo
blokowania wszystkich
ć
ł
ą
ż
ż
ść
przerwa lub tylko wybranych przerwa , na czas obs ugi jednego z nich. Reasumuj c, procesor w systemie
ń
ń
ł
ą
komputerowym, który kontroluje Linux, albo wykonuje kod aplikacji, albo kod j dra w kontek cie procesu, albo kod
ą
ś
j dra w kontek cie przerwania.
ą
ś
Porównanie z innymi systemami uniksowymi
J dro sytemu Linux jest podobne do rdzeni innych systemów wzorowanych na Uniksie, ale istnieje równie kilka
ą
ż
znacz cych ró nic. Podobnie jak w wi kszo ci Uniksów, j dro Linuksa jest monolityczne, ale udost pnia mo liwo
ą
ż
ę
ś
ą
ę
ż
ść
korzystania z adowanych dynamicznie modu ów, które zazwyczaj s sterownikami urz dze . Linux obs uguje równie
ł
ł
ą
ą
ń
ł
ż
symetryczne przetwarzanie wieloprocesorowe (SMP), co nie jest cech wszystkich Uniksów. Podobnie jak Solaris i IRIX,
ą
Linux mo e obs ugiwa od wersji 2.6 wyw aszczanie zada j dra. J dro Linuksa nie rozró nia w tków i procesów,
ż
ł
ć
ł
ń ą
ą
ż
ą
traktuje je niemal e w ten sam sposób. Niektóre mechanizmy, które przez twórców Uniksa zosta y uznane za ma o
ż
ł
ł
wydajne lub wr cz za zb dne (jak np. obs uga strumieni) nie zosta y w ogóle zaimplementowane w j drze Linuksa. Ze
ę
ę
ł
ł
ą
wzgl dów wydajno ciowych strony pami ci zajmowanej przez j dra Linuksa nie podlegaj wymianie. Ta ostatnia cecha
ę
ś
ę
ą
ą
jest konsekwencj faktu, e Linux jest tworzony przez ogromn spo eczno
programistów – w wyniku dyskusji
ą
ż
ą
ł
ść
i rozwa a cz onkowie tej spo eczno
doszli do wniosku, e taki mechanizm spowodowa by pogorszenie wydajno ci
ż ń
ł
ł
ść
ż
ł
ś
systemu. Kolejne wersje j dra s oznaczane symbolami sk adaj cymi si z trzech
ą
ą
ł
ą
ę
7
liczb rozdzielonych kropkami.
Pierwsza liczba to g ówny numer wersji, druga to numer podwersji – je li jest parzysta, to jest to wersja stabilna, je li
ł
ś
ś
nieparzysta to wersja rozwojowa. Trzeci numer jest numerem rewizji i oznacza, e w poprzedniej wersji j dra znaleziono
ż
ą
jaki b d i wydano poprawion wersj
ś
łą
ą
ę
8
. Poszczególne dystrybucje Linuksa mog dodawa inne liczby do tych
ą
ć
przedstawionych wy ej.
ż
6
Istniej równie przerwania synchroniczne.
ą
ż
7
Pojawi a si równie czwarta liczba (j dro 2.6.8.1). Jej wprowadzenie zwi zane by o z naprawieniem powa nego b du,
ł
ę
ż
ą
ą
ł
ż
łę
który wykryto tu po wypuszczeniu wersji 2.6.8. Po d ugiej przerwie wprowadzono j ponownie.
ż
ł
ą
8
Wraz z pojawieniem si j dra 2.6.0 proponowano zmian znaczenia numeru rewizji, ale ta propozycja chyba zosta a
ę ą
ę
ł
odrzucona.
2
Systemy Operacyjne – semestr drugi
Krótka charakterystyka metodologii programowania j dra
ą
Poniewa j dro systemu z definicji ma by optymalne pod wzgl dem wykorzystania pami ci i szybko ci dzia ania, to
ż ą
ć
ę
ę
ś
ł
przegl daj c kod ród owy Linuksa mo emy spotka wiele fragmentów, które ami niektóre przyj te kanony dobrze
ą
ą
ź
ł
ż
ć
ł
ą
ę
napisanego oprogramowania (jak cho by u ywanie instrukcji
ć
ż
goto
). Tak, jak w przypadku innych systemów
uniksopodobnych, wi kszo
kodu Linuksa jest napisana w j zyku C, a tylko niewielka cz
, zale na od konkretnej
ę
ść
ę
ęść
ż
architektury sprz towej w assemblerze
ę
9
. Pisz c w asny fragment j dra, czy to w postaci modu u, czy ingeruj c
ą
ł
ą
ł
ą
w istniej cy kod nale y mie wiadomo pewnych ogranicze . Przede wszystkim, pisz c kod j dra nie mamy dost pu
ą
ż
ć ś
ść
ń
ą
ą
ę
do funkcji standardowej biblioteki C (libc, a konkretniej glibc). Jest to naturaln konsekwencj tego, e to j dro
ą
ą
ż
ą
stanowi wsparcie dla tej biblioteki, a nie odwrotnie. Na szcz cie zosta y zaimplementowane w j drze funkcje, b d ce
ęś
ł
ą
ę ą
substytutami tych z biblioteki glibc. Zamiast funkcji printf jest funkcja printk, zamiast funkcji do manipulowania
a cuchami znaków, które s dost pne po w czeniu pliku
ł ń
ą
ę
łą
string.h
s podobne funkcje dost pne po w czeniu pliku
ą
ę
łą
linux/string.h
. Uogólniaj c – j dro mo e korzysta wy cznie ze swoich plików nag ówkowych, niedozwolone jest
ą
ą
ż
ć
łą
ł
korzystanie z zewn trznych plików nag ówkowych. Kod j dra jest pisany z wykorzystaniem standardu ISO C99 j zyka
ę
ł
ą
ę
C, oraz z wykorzystaniem rozszerze GNU C. Oznacza to, e mo e by kompilowany prawie wy cznie przez kompilator
ń
ż
ż
ć
łą
C pochodz cy z GCC (Gnu Compilers Collection). Do wspomnianych rozszerze nale y wykorzystywanie funkcji
ą
ń
ż
rozwijanych w miejscu wywo ania (ang.
ł
inline functions
), obecnie wprowadzone ju do standardu j zyka C. Takie
ż
ę
funkcje s bardziej bezpieczne i eleganckie ni makra, a
ą
ż
przy tym równie skuteczne. Funkcje rozwijane w miejscu
wywo ania s definiowane z u yciem s ów kluczowych
ł
ą
ż
ł
static
i inline. Nale y jednak pami ta , aby nie nadu ywa
ż
ę ć
ż
ć
takich funkcji, bo prowadzi to do niepotrzebnego zwi kszenia obj to ci kodu wynikowego. Innym z wykorzystywanych
ę
ę ś
rozszerze jest mo liwo
wprowadzania wstawek assemblerowych do kodu napisanego w j zyku C. Te wstawki s
ń
ż
ść
ę
ą
stosowane wsz dzie tam, gdzie wymagana jest optymalizacja szybko ci dzia ania j dra. Kompilator gcc udost pnia
ę
ś
ł
ą
ę
dwie dyrektywy wspomagaj ce optymalizacj kodu. S to
ą
ę
ą
likely()
i unlikely(). S u
one do oznaczania
ł żą
prawdopodobie stwa wykonania kodu w instrukcjach warunkowych, np.: jako
ń
unlikely()
mo emy zaznaczy warunki
ż
ć
zwi zane z obs ug wi kszo ci wyj tków. Pisz c kod dzia aj cy w przestrzeni j dra musimy pami ta , e nie mamy
ą
ł
ą
ę
ś
ą
ą
ł ą
ą
ę ć ż
„siatki zabezpieczaj cej” w postaci ochrony pami ci. Je li b dziemy le zarz dza pami ci j dra, to mo emy naruszy
ą
ę
ś
ę
ź
ą
ć
ę ą ą
ż
ć
stabilno
systemu operacyjnego. Je li chcemy u y liczb i arytmetyki zmiennoprzecinkowej, to musimy sami
ść
ś
ż ć
oprogramowa FPU, jednak e nigdy dot d potrzeba u ywania takiej arytmetyki w przestrzeni j dra nie zaistnia a.
ć
ż
ą
ż
ą
ł
Rozmiar stosu j dra
ą
10
jest ograniczony i wynosi w przypadku architektur 32 bitowych 8KB
11
, a w przypadku 64
bitowych procesorów Alpha 16KB. Procesy u ytkownika dysponuj stosem znajduj cym si w przestrzeni
ż
ą
ą
ę
u ytkownika, który nie jest ograniczony
ż
12
. Programuj c w j drze musimy pami ta o
ą
ą
ę ć
synchronizacji dost pu do
ę
zasobów wspó dzielonych. Mamy do dyspozycji np. takie rodki synchronizacji jak semafory i
ł
ś
rygle p tlowe (
ę
ang. spin-
lock)
, czyli semafory z aktywnym oczekiwaniem. Ostatni wa n rzecz , o której nale y pami ta pisz c lub zmieniaj c
ą
ż ą
ą
ż
ę ć
ą
ą
kod j dra, to przeno no . Nawet pisz c kod w j zyku C mo emy do wiadczy ró nych problemów, jak cho by
ą
ś
ść
ą
ę
ż
ś
ć
ż
ć
porz dek bitów i
ą
bajtów w s owie, czy rozmiary poszczególnych typów danych.
ł
Bardzo krótkie wprowadzenie do tworzenia modu ów j dra 2.6
ł
ą
13
Modu y j dra s form bibliotek wspó dzielonych, jednak e nie s one dynamicznie czone z procesami u ytkownika
ł
ą
ą
ą
ł
ż
ą
łą
ż
lecz z samym j drem. Dzi ki modu om mo emy atwo dodawa lub usuwa now funkcjonalno
do j dra, bez
ą
ę
ł
ż
ł
ć
ć
ą
ść
ą
konieczno ci restartowania systemu. Pisz c w asny modu nale y by wiadomym tego, e b d w module mo e
ś
ą
ł
ł
ż
ć ś
ż
łą
ż
spowodowa powa ne konsekwencje dla pracy systemu, a w niektórych przypadkach mo e równie doprowadzi do
ć
ż
ż
ż
ć
uszkodzenia sprz tu.
ę
Sposób pisania modu ów dla j dra Linuksa 2.6 ró ni si od tego, który obowi zywa we wcze niejszych wersjach.
ł
ą
ż
ę
ą
ł
ś
Przede wszystkim, aby skompilowa modu nale y mie zainstalowany ca y kod ród owy j dra w systemie. Kompilacj
ć
ł
ż
ć
ł
ź
ł
ą
ę
wykonujemy za pomoc programu narz dziowego „make”. W ramce poni ej przedstawiona zosta a zawarto
pliku
ą
ę
ż
ł
ść
konfiguracyjnego (Makefile) dla tego programu.
9
Dodajmy: w notacji AT&T.
10 Okre lenia co najmniej myl ce. Chodzi o stos j dra, który jest przydzielany ka demu procesowi u ytkownika
ś
ą
ą
ż
ż
i u ywany je li ten proces zainicjalizuje wywo anie systemowe.
ż
ś
ł
11 Trwa dyskusja, czy nie zmniejszy tego rozmiaru do 4KB.
ć
12 Dok adniej: po wykonaniu z poziomu pow oki tcsh polecenia limit otrzymuj informacj , e stos w przestrzeni
ł
ł
ę
ę ż
u ytkownika ma rozmiar 8MB, po wykonaniu polecenia unlimit (konto u ytkownika nieuprzywilejowanego)
ż
ż
i ponownym wykonaniu limit okazuje si , e rozmiar stosu jest nieograniczony (moja bie ca dystrybucja Linuksa to
ę ż
żą
Mandriva Linux 2005 LE).
13 Ca o rozdzia u (wraz z przyk adami) bazuje na ksi ce” Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman,
ł ść
ł
ł
ąż
"Linux Device Drivers"
3
Systemy Operacyjne – semestr drugi
Tre
tego pliku zosta a zapo yczona z ksi ki
ść
ł
ż
ąż
"Linux Device Drivers" i uzupe niona o regu
ł
łę
„clean” usuwaj c pliki powsta e w wyniku
ą ą
ł
kompilacji lub edycji pliku z kodem ród owym
ź
ł
modu u. Aby program „make” wykona regu
ł
ł
łę
„clean” nale y go wywo a nast puj co: „make
ż
ł ć
ę
ą
clean”. Wywo ania programu bez parametru
ł
spowoduje skompilowanie modu u o nazwie
ł
„first”. Który modu ma zosta skompilowany
ł
ć
okre la wiersz „obj-m := first.o” pliku
ś
konfiguracyjnego.
Modu o nazwie „first” jest modu em typu „Hello World!”, który powinni stworzy wszyscy pocz tkuj cy programi ci,
ł
ł
ć
ą
ą
ś
chc cy pisa w asne modu y (kod nale y umie ci w pliku
ą
ć ł
ł
ż
ś ć
o nazwie „first.c”):
4
# If KERNELRELEASE is defined, we've been invoked from the
# kernel bulid system an can use its language.
ifneq ($(KERNELRELEASE),)
obj-m := first.o
# Otherwise we were called directly from command
# line; invoke the kernel bulid system.
else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
endif
clean:
rm -f *~
rm -rf .tmp_versions
rm -f first.ko
rm -f first.mod.c
rm -f first.mod.o
rm -f first.o
rm -f .first*
#include<linux/init.h>
#include<linux/module.h>
static int __init first_init(void)
{
printk(KERN_ALERT"Welcome\n");
return 0;
}
static void __exit first_exit(void)
{
printk(KERN_ALERT"Good bye\n");
}
module_init(first_init);
module_exit(first_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Arkadiusz Chrobot <a.chrobot@tu.kielce.pl>");
MODULE_DESCRIPTION("Another \"Hello World!\" kernel module :-)");
MODULE_VERSION("1.0");
Systemy Operacyjne – semestr drugi
Pliki nag ówkowe „linux/init.h” i „linux/module.h” s do czane do kodu ka dego modu u j dra. Zawieraj mi dzy
ł
ą
łą
ż
ł
ą
ą
ę
innymi makra preprocesora, które zostan opisane ni ej. Funkcje o nazwach „first_init” i „first_exit” s odpowiedzialne
ą
ż
ą
odpowiednio za wykonanie inicjalizacji tu po za adowaniu modu u i deinicjalizacj tu przed usuni ciem modu u
ż
ł
ł
ę
ż
ę
ł
z pami ci operacyjnej. Obie funkcje zosta y zdefiniowane z u yciem s owa kluczowego
ę
ł
ż
ł
static
, co oznacza, e s
ż
ą
dost pne wewn trz przestrzeni nazw modu u „first”, co zapobiega ewentualnemu konfliktowi nazw. adna z tych
ę
ą
ł
Ż
funkcji nie przyjmuje parametrów wywo ania. Funkcja „first_exit” nic równie nie zwraca, natomiast „fist_init” zwraca
ł
ż
warto typu
ść
int
. Je li u yliby my terminologii znanej z j zyków obiektowych, to o tych funkcjach mo emy my le jako
ś
ż
ś
ę
ż
ś ć
o konstruktorze i destruktorze. W nag ówkach takich funkcji mog , ale nie musz wyst powa znaczniki __init i
ł
ą
ą
ę
ć
__exit.
Pierwszy sygnalizuje, e funkcja jest u ywana wy cznie podczas inicjalizacji modu u i po jej wykonaniu mo na zwolni
ż
ż
łą
ł
ż
ć
pami
na ni przydzielon . Drugi znacznik sygnalizuje, e funkcja jest u ywana wy cznie podczas sprz tania. Ten
ęć
ą
ą
ż
ż
łą
ą
znacznik ma znaczenie je li modu jest w czany do kodu j dra na etapie kompilacji, lub gdy j dro jest tak
ś
ł
łą
ą
ą
skonfigurowane, e nie pozwala na usuni cie za adowanych modu ów. Makra
ż
ę
ł
ł
module_init
oraz module_exit przyjmują
jako parametry wywo ania adresy funkcji odpowiedzialnych za inicjalizacj i sprz tanie po module. Te makra
ł
ę
ą
pozwalaj programi cie powiadomi kompilator, które funkcje b d odpowiedzialne za inicjalizacj i sprz tanie po
ą
ś
ć
ę ą
ę
ą
module. Cztery pozosta e makra nie s obowi zkowe i pozwalaj okre li licencj na jakiej modu jest
ł
ą
ą
ą
ś ć
ę
ł
rozpowszechniany, autora modu u (zalecane jest podanie jego adresu e-mail), opis modu u oraz jego wersj . Wszystkie
ł
ł
ę
te informacje s zapisane w postaci a cuchów znaków, wed ug konwencji obowi zuj cej w j zyku C. Maj c plik
ą
ł ń
ł
ą
ą
ę
ą
wynikowy mo emy je odczyta pos uguj c si programem „modinfo” np.: „modinfo first.ko”. Nieumieszczenie w kodzie
ż
ć
ł
ą
ę
modu u m
ł
akra MODULE_LICENSE lub podanie nazwy innej ni która z wolnych licencji spowoduje wyst pienie
ż
ś
ą
komunikatu ostrzegawczego, mówi cego o tym, e j dro zosta o „ska one” modu em o nieznanej lub niedopuszczalnej
ą
ż
ą
ł
ż
ł
licencji. Nazwy licencji, które nie generuj takiego ostrze enia, to: „GPL”, „GPL v2”, „
ą
ż
“GPL additional rights”, „Dual
BSD/GPL”, „Dual MPL/GPL”. Modu y na licencji niewolnej mog jako parametr tego makra przekaza „Proprietary”.
ł
ą
ć
W kodzie modu u wyst puj wywo ania funkcji „printk”. Warto zwróci uwag na znacznik b d cy argumentem
ł
ę
ą
ł
ć
ę
ę ą
wywo ania tej funkcji i poprzedzaj cy w a ciwy a cuch znaków. Okre la on poziom wa no ci wypisywanego
ł
ą
ł ś
ł ń
ś
ż
ś
komunikatu lub inaczej poziom logowania. Istnieje kilka takich znaczników: KERN_EMERG – sytuacja awaryjna,
KERN_ALERT – problem wymagaj cy natychmiastowej reakcji, KERN_CRIT – sytuacja krytyczna, KERN_ERR – b d,
ą
łą
KERN_WARNING – ostrze enie, KERN_NOTICE – sytuacja normalna, ale zasz o zdarzenie godne zauwa enia,
ż
ł
ż
KERN_INFO – informacja, KERN_DEBUG – komunikat diagnostyczny. Komunikaty od modu ów j dra zapisywane s
ł
ą
ą
w pliku dziennika systemowego (zazwyczaj /var/log/messages), wypisywane na konsol i mo na je wy wietli na ekran
ę
ż
ś
ć
za pomoc polecenia „dmesg”. Modu y j dra mo emy adowa lub usuwa b d c zalogowanymi jako u ytkownik „root”
ą
ł
ą
ż
ł
ć
ć ę ą
ż
lub jako u ytkownik posiadaj cy takie uprawnienia (patrz polecenia „sudo” i
ż
ą
„su”). Korzystaj c z polecenia „insmod”
ą
mo emy za adowa modu , a
ż
ł
ć
ł
poleceniem „rmmod” usun , np.: „insmod first.ko”, „rmmod first”. Informacje
ąć
o za adowanych modu ach mo emy uzyska u ywaj c polecenia „lsmod”, równie b d c zalogowanymi jako zwyk y
ł
ł
ż
ć
ż
ą
ż
ę ą
ł
u ytkownik. Istniej równie inne narz dzia do obs ugi modu ów, które nie b d tutaj opisywane (np. „modprobe”). Ze
ż
ą
ż
ę
ł
ł
ę ą
wzgl du na dosy cz ste zmiany w API j dra warto zapozna si z dzia aniem makrodefinicji preprocesora
ę
ć
ę
ą
ć
ę
ł
LINUX_VERSION_CODE i KERNEL_VERSION. Pierwsza zwraca wersj róde j dra zainstalowanych w
ę ź
ł ą
systemie
w postaci warto ci typu
ś
int
, a druga zamienia numer wersji j dra przekazany jej przez argumenty w
ą
postaci trzech liczb
(np. KERNEL_VERSION(2,6,19)) na posta numeryczn . Dzi ki nim mo emy napisa odpowiednie instrukcje
ć
ą
ę
ż
ć
warunkowe dla preprocesora, aby w cza b d nie okre lone fragmenty kodu do kompilacji.
łą
ł ą ź
ś
5