SO2 wyklad 1 Wstęp

background image

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

background image

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

background image

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

background image

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");

background image

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


Wyszukiwarka

Podobne podstrony:
Microsoft PowerPoint Wyklad 1 Wstep do informatyki i
Microsoft PowerPoint Wyklad 2 Wstep do informatyki i
wykład 1 wstęp domikrobiologii, podział organizmow
wykład 4 - wstęp do słowotwórstwa, Nauka o współczesnym języku polskim
wde - pytania wykład, wstęp do elektroniki - wykład zaliczenie
Wykłady Wstęp do Prawoznawstwa
C Wyklady, Wstep
C Wyklady Wstep
wyklad 1 wstep
wykład 1 wstęp
Wykład 1 Wstęp
Wykład 1 wstęp
Wyklad 2 wstep do optyki
Ratownictwo Wykład Wstęp do immunol i alegol
wyklad 2, wstęp do socjologii
MP Wykład 7 Wstęp do prognozowania
Wyklad wstep

więcej podobnych podstron