SO2_wyklad

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

, dzi ki czemu system ten sta si atwy w przenoszeniu na inne platformy sprz towe

ę ł

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

). 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

. 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

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

ę ą

Pozosta cz

pozostawiono w assemblerze.

łą

ęść

Dok adniej – atwiej by o go przenie na inne platformy, ni system napisany w ca o ci w assemblerze.

ść

ł ś

W a ciwie ten skrót rozwijano jako "Keep It Simple, Stupid!". Osobi cie wol wersj agodniejsz :-)

ł ś

ę ł

Ostatnio pojawiaj si g osy, e te mechanizmy komunikacji staj si powoli przestarza e.

ę ł

W kwestii j zykowej: piszemy Linux, ale odmieniamy: Linuksa, Linuksowi, itd.

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

. 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

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

łą

. Poszczególne dystrybucje Linuksa mog dodawa inne liczby do tych

przedstawionych wy ej.

Istniej równie przerwania synchroniczne.

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.

Wraz z pojawieniem si j dra 2.6.0 proponowano zmian znaczenia numeru rewizji, ale ta propozycja chyba zosta a

ę ą

odrzucona.

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

. 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

jest ograniczony i wynosi w przypadku architektur 32 bitowych 8KB

, 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

. 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

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.

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"

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”):

# 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.

łą

ł ą ź