capitol ul 2

14
Capitolul 2 – Structura sistemelor de operare Capitolul 2 STRUCTURA SISTEMELOR DE OPERARE Sistemele de operare sunt colecţii de programe (sisteme software) de complexitate deosebită. Pentru a stăpâni această complexitate, conform principiilor ingineriei software, sistemul trebuie împărţit în subsisteme care se pot analiza, proiecta şi realiza separat ţinându-se cont însă şi de legăturile obligatorii între subsisteme. Responsabilităţile unui sistem de operare prezentate în capitolul precedent pot fi considerate ca o cale de divizare funcţională a unui sistem de operare, dar în stabilirea structurii unui astfel de sistem există şi alţi factori care trebuie luaţi în considerare. Printre aceştia se menţionează caracteristicile hardware ale sistemului de calcul, domeniul principal de aplicaţii avut în vedere, limbajul de implementare utilizat etc. Complexitatea sistemelor de operare mai face ca acelaşi sistem să apară cu diferite organizări când este examinat din diferite puncte de vedere. Posibile puncte de vedere sunt: a) organizarea codului sursă; b) organizarea memoriei; c) condiţiile de execuţie; d) interacţiunea dintre componente; e) adaptabilitatea la configuraţiile hardware. Întrucât primul aspect, organizarea codului sursă ţine în primul rând de proiectarea şi implementarea sistemelor de operare, el nu va fi analizat mai în detaliu. Se consideră însă că celelalte aspecte, care se manifestă direct în timpul funcţionării unui sistem de operare sunt importante şi pentru utilizatori şi mai ales pentru programatorii de sistem, ca şi pentru administratorii sistemelor de 15

Upload: linsu-sorin-constantin

Post on 17-Feb-2016

215 views

Category:

Documents


1 download

DESCRIPTION

fg

TRANSCRIPT

Page 1: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

Capitolul 2STRUCTURA SISTEMELOR DE OPERARE

Sistemele de operare sunt colecţii de programe (sisteme software) de complexitate deosebită. Pentru a stăpâni această complexitate, conform principiilor ingineriei software, sistemul trebuie împărţit în subsisteme care se pot analiza, proiecta şi realiza separat ţinându-se cont însă şi de legăturile obligatorii între subsisteme.

Responsabilităţile unui sistem de operare prezentate în capitolul precedent pot fi considerate ca o cale de divizare funcţională a unui sistem de operare, dar în stabilirea structurii unui astfel de sistem există şi alţi factori care trebuie luaţi în considerare. Printre aceştia se menţionează caracteristicile hardware ale sistemului de calcul, domeniul principal de aplicaţii avut în vedere, limbajul de implementare utilizat etc.

Complexitatea sistemelor de operare mai face ca acelaşi sistem să apară cu diferite organizări când este examinat din diferite puncte de vedere. Posibile puncte de vedere sunt:

a) organizarea codului sursă;b) organizarea memoriei;c) condiţiile de execuţie;d) interacţiunea dintre componente;e) adaptabilitatea la configuraţiile hardware.

Întrucât primul aspect, organizarea codului sursă ţine în primul rând de proiectarea şi implementarea sistemelor de operare, el nu va fi analizat mai în detaliu. Se consideră însă că celelalte aspecte, care se manifestă direct în timpul funcţionării unui sistem de operare sunt importante şi pentru utilizatori şi mai ales pentru programatorii de sistem, ca şi pentru administratorii sistemelor de operare. Fiecare aspect va fi discutat într-un subcapitol separat.

2.1 Organizarea memoriei

O anumită parte a oricărui sistem de operare trebuie să se găsească permanent în memorie în timpul funcţionării unui sistem de calcul. Aceasta este partea rezidentă a sistemului şi constă din procedurile care tratează serviciile critice, cum ar fi planificarea proceselor tratarea erorilor, verificarea securităţii, precum şi tratarea iniţială a apelurilor sistem. Se mai foloseşte şi denumirea de nucleu pentru aceste funcţii, dar trebuie reţinut că şi alte componente pot fi rezidente.

Componentele utilizate mai puţin frecvent, cum ar fi unele elemente specializate ale sistemului de gestionare a fişierelor sau cele legate de interfaţa prin comenzi, nu rămân în permanenţă în memoria internă, ci sunt încărcate la cerere de pe un suport de memorie externă. Acestea sunt componentele tranzitorii ale sistemului de operare.

15

Page 2: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

De regulă, componentele rezidente ocupă o zonă fixă a memoriei interne, care include regiunea cu adresele cele mai mici unde se găsesc în majoritatea arhitecturilor hardware vectorii de întrerupere.

În unele arhitecturi o porţiune a spaţiului de adrese este rezervată pentru intrări/ieşiri mapate în memorie ("memory-mapped I/O"), adresele din această porţiune referindu-se la registre din interfeţele hardware cu echipamentele periferice şi nu la memoria propriu-zisă.

Accesul la aceste adrese este de obicei rezervat pentru sistemul de operare. Componentele tranzitorii pot avea o zonă de memorie rezervată sau pot fi încărcate în orice zonă de memorie disponibilă, intrând în competiţie pentru memorie cu programele utilizator. În al doilea caz, multe arhitecturi solicită operaţia de relocare, adică de modificare a unor adrese din program pentru a se face referiri corecte în instrucţiunile de salt sau de acces la date. În funcţie de suportul hardware disponibil, această operaţie poate fi mai simplă sau mai complexă.

Se prezintă în continuare hărţi de memorie ("memory maps") pentru câteva sisteme de operare tipice, pentru a ilustra modul în care este utilizată memoria internă de către sistemele de operare. În general trebuie avute în vedere trei aspecte distincte:

a) conţinutul spaţiului virtual de adrese când este în execuţie un program utilizator;

b) conţinutul spaţiului virtual de adrese când este în execuţie o componentă a sistemului de operare;

c) conţinutul memoriei fizice. Nu în toate sistemele cele trei aspecte vor fi însă distincte şi relevante.

Figura 7: Harta de memorie la CP/MProbabil cea mai simplă situaţie este cea întâlnită în sistemul de operare

CP/M, prezentată în figura 7. Memoria direct adresabilă în sistem este de 64

16

BIOS

BDOS

CCP

Nefolosit

Program + date

aplicatie

Zona de comanda

64k

~ 54k

256

0

Page 3: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

kocteţi, limită impusă de arhitectura microprocesorului Intel 8080. Sistemul de operare foloseşte primii 256 de octeţi ai memoriei pentru vectorii de întrerupere şi pentru informaţii de sistem cum ar fi tamponul pentru linia de comandă curentă. Cele două componente rezidente ale sistemului de operare, BIOS (Basic Input/Ouptput System) şi BDOS (Basic Disk Operating System) ocupă zona superioară a spaţiului de adrese, folosind împreună cca 10 kocteţi. În aceasta regiune mai este inclusă şi stiva sistemului, de dimensiune fixă, care este utilizată atât de sistem cât şi de unele programe. Trebuie remarcat că programele utilizator îşi rezervă de obicei propria lor stivă. Interpretorul de comenzi, CCP (Command Control Processor) este încărcat când devine necesar în zona tranzitorie, ocupând cca 2 kocteţi în partea superioară a acesteia. El poate acoperit de programele de aplicaţie, care se încarcă întotdeauna de la adresa 256 (100h) a memoriei şi deci nu trebuie să fie relocabile.

Sistemul de operare MS-DOS (PC-DOS) are schema de utilizare a memoriei din figura 8. Arhitectura microprocesorului Intel 8086 permite adresarea directă a până la 1 M-octet de memorie. Sistemul MS-DOS rezervă zona peste 640K pentru memoria video şi pentru programe memorate în ROM, în special sistemul de bază de introducere/extragere (ROM BIOS) şi o serie de programe de test activate la pornirea calculatorului.

Figura 8: Harta de memorie la MS-DOSa) harta fizică

b) adrese virtuale într-un proces

17

1 M

640 K

1536

0

BIOS (ROM)

Memoria video

Interpretorul de comenzi tranzitoriu

Nefolosit

Program + date

aplicatie

Rezident SO

Zona de comanda

64 K

0

Stiva aplicatie

Date aplicatie

Program aplicatie

Zona comunicatie

64 K

0

256

a) b)

Page 4: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

Figura 9: Harta de memorie în UNIX.a) Adrese virtuale în proces

b) Adrese virtuale în sistemul de operare

Partea rezidentă a sistemului de operare ocupă zona începând de la adresa 1536, până la care se întind vectorii de întrerupere utilizaţi de MS-DOS. În partea rezidentă este inclusă şi o porţiune din interpretorul de comenzi, restul acestuia aflându-se în partea superioară a memoriei RAM fizic prezente în sistem. Partea tranzitorie a interpretorului de comenzi poate acoperită de programele de aplicaţii.

Spaţiul de adrese al unui program este limitat de arhitectura microprocesorului Intel 8086 la cel mult 4 segmente a câte 64 Ko fiecare, dintre acestea unul fiind rezervat pentru cod, unul pentru stivă şi două pentru date. Frecvent se foloseşte un singur segment pentru stivă şi date. Din segmentul de program, primii 256 de octeţi formează o zonă de comunicaţii, asemănătoare cu cea întâlnită în spaţiul sistemului la CP/M. O situaţie interesantă este cea întâlnită în sistemul de operare UNIX (figura 9). Harta fizică a memoriei nu este prezentată, pentru că fiecare implementare trebuie să ţină cont de caracteristicile arhitecturale ale calculatorului gazdă, astfel încât să se păstreze în memoria fizică în fiecare moment informaţia necesară. Se utilizează atât pentru componentele sistemului de operare cât şi pentru programele utilizator tehnici de swapping şi/sau de memorie virtuală dacă e posibil.

Din spaţiul virtual de adrese al unui proces nu este vizibilă nici o porţiune a sistemului de operare. De asemenea, în majoritatea implementărilor procesele nu au posibilitatea să utilizeze în comun o zonă de memorie, deci UNIX nu permite comunicarea între procese prin memorie comună. Spaţiul de adrese virtuale al nucleului sistemului UNIX constă numai din nucleu. Procedurile acestuia sunt executate la cerere, în urma unor apeluri sistem din programe sau a unor întreruperi.

18

Date

Programe aplicatie

Stivamax

0

a)

Sistem de operare rezident

max

0

b)

Page 5: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

Figura 10: Hărţi de memorie în sistemele IBM

În sistemul de operare VAX/VMS spaţiul de adrese de 4 Gocteţi este divizat în 4 porţiuni de câte 1 Goctet gestionate independent: una dintre acestea este atribuită procesului curent, a doua este folosită de sistem pentru a păstra diferite informaţii de comandă pentru proces iar a treia este folosită pentru sistemul de operare (a patra porţiune este nefolosită). Prin urmare sistemului de operare îi este accesibil întregul spaţiu de adrese iar în mod normal un proces utilizator are acces doar la programul şi datele proprii.

Structuri mai "tradiţionale" sunt întâlnite în sistemele OS/MVT şi chiar OS/MVS, prezentate în figura 10. Sistemul OS/MVT, pentru calculatoarele IBM System/360 este un sistem multiprogramat, fără memorie virtuală, cu spaţiul maxim de adresare de 16 Mocteţi.

Porţiunile de la începutul şi sfârşitul memoriei fizice sunt alocate sistemului de operare, în zonele tranzitorii încărcându-se rutine nerezidente ale sistemului. Fiecare task (de sistem sau de aplicaţie) are alocată o zonă contiguă de memorie, în care se află programul, datele şi informaţiile de comandă ale taskului. Întregul spaţiu de memorie este vizibil fiecărui proces, dar există o schemă simplă de protecţie (cu suport hardware) prin care se interzice ca procesele să facă acces la locaţii din afara regiunii rezervate lor.

Sistemul de operare OS/MVS este specific arhitecturii IBM System/370, în care oricărui proces îi este vizibil întregul spaţiu de adrese virtuale de 16 Mocteţi. Din acest spaţiu sistemul de operare ocupă porţiunile de la extremităţi, fiind utilizat în comun de toate procesele. Restul spaţiului este privat fiecărui proces şi conţine programul, datele şi informaţiile de comandă ale procesului. O

19

2 (16) M

0a) OS/MVT

Zona tranzitorie

Task aplicatie

Task aplicatie

Task aplicatieTask sistem

Task sistem

Zona tranzitorie

Nucleu

Info control sistem

b) OS/MVS

Info comanda sistem

Info comanda aplicatie

Program + date

aplicatie

Zona tranzitorie

Nucleu

Zona tranzitorie

0

16 M

Page 6: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

porţiune a spaţiului comun este considerată ca zonă de comunicaţii, sistemul admiţând deci comunicarea între procese prin această zonă de memorie. Gestionarea memoriei fizice este responsabilitatea sistemului de operare.

2.2 Structuri de execuţie

Codul unui sistem de operare constă din mai multe unităţi executabile, execuţia fiecărei unităţi fiind declanşată de evenimente specifice.

În organizarea tradiţională a sistemelor de operare sistemul poate fi privit ca o colecţie de rutine invocate prin apeluri sistem sau ca urmare a unor întreruperi. Trebuie remarcat că apelurile sistem diferă de apelurile normale de rutine prin aceea că duc la creşterea nivelului de privilegii în timpul execuţiei. Rutinele sistemului pot folosi toate instrucţiunile, au acces la toate registrele şi la toate locaţiile de memorie.

"Intrarea" în sistemul de operare are loc efectiv numai prin câteva puncte controlate (figura 11), de unde apoi se selectează rutinele de serviciu corespunzătoare. De regulă apelurile sistem trec toate printr-un dispecer în care se selectează rutinele de serviciu, dar dacă sistemul de calcul este prevăzut cu un număr mare de nivele de întrerupere ar fi posibil să se rezerve câte un nivel de întrerupere pentru fiecare sursă de întreruperi. În acest caz legătura cu rutinele se face direct, aşa cum se ilustrează în figura 11.

Rutinele care servesc ca puncte de intrare în sistem trebuie să fie rezidente. În timpul execuţiei acestora sau a altor rutine rezidente apelate de ele poate apare necesitatea încărcării în memorie a unor rutine nerezidente ale sistemului de operare. Şi acestea vor fi executate cu aceleaşi privilegii ca restul sistemului de operare.

Multe dintre rutinele sistemului de operare revin la programul apelant numai după satisfacerea completă a serviciilor solicitate. Unele însă vor declanşa activităţi (de exemplu operaţii de I/O) care se vor desfăşura simultan cu execuţia programelor. În astfel de cazuri programul care a făcut apelul este de regulă pus în aşteptare până la terminarea serviciului solicitat, dar alte programe pot continua.

La terminarea serviciilor se declanşează o întrerupere. Procesorul suspendă programul care era momentan activ şi trece la execuţia rutinei de tratare a întreruperii. Ca urmare se pot modifica diferite structuri de date şi, printre altele, programului pus în aşteptare i se poate permite continuarea execuţiei.

În sistemele de operare mai complexe apar activităţi ale sistemului care trebuie să continue pe o perioadă mai lungă în paralel cu execuţia programelor utilizator (de exemplu tipărirea unor fişiere la imprimantă, controlul unei linii de comunicaţii, activităţi periodice ca salvarea tampoanelor din memorie pe disc la UNIX). Aceste activităţi sunt organizate ca procese distincte, numite procese sistem, nu necesită de regulă privilegii deosebite şi sunt tratate aproape la fel ca procesele utilizator. Procesele sistem au însă prioritate de planificare mai mare

20

Page 7: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

decât procesele utilizator şi ar putea fi exceptate de la swapping dacă sistemul foloseşte această tehnică în gestionarea memoriei.

Figura 11: Declanşarea execuţiei rutinelor sistemului de operare

Organizarea unei părţi a codului sistemului de operare în procese sistem este şi o cale de reducere a erorilor în proiectarea şi implementarea sistemului, permiţând o gestionare mai sistematică a activităţilor. Deoarece procesele sistem nu vor avea privilegii mai mari decât este necesar eventualele erori în cadrul lor vor conduce la pierderi mai mici în sistem.

O parte a codului sistemului de operare, în orice formă de proiectare, va rămâne întotdeauna în afara proceselor sistem, ea cuprinzând o serie de servicii esenţiale, între care şi planificarea proceselor.

2.3 Interacţiunea componentelor

Într-o structură fără restricţii, orice procedură a unui sistem de operare ar putea apela orice altă procedură sau face acces la orice structură de date. Un astfel de sistem ar fi însă puţin fiabil pentru că ar fi extrem de dificil să se determine efectele oricărei schimbări într-una din proceduri sau din structurile de date.

Restricţii asupra interacţiunii componentelor se pot impune atât în procesul de proiectare a unui sistem de operare, cât şi la execuţie. La proiectare se pot realiza restricţii prin intermediul compilatoarelor dacă sistemul este scris într-un limbaj cu suport adecvat. La execuţie este însă nevoie de suport din partea hardware-ului, ceea ce nu este oferit în toate arhitecturile la un nivel adecvat.

Primul sistem de operare proiectat structurat este THE, realizat de E. Dijkstra la Universitatea Tehnică din Eindhoven. Componentele principale ale acestui sistem (figura 12) sunt structurate pe cinci nivele. Fiecare nivel foloseşte resursele puse la dispoziţie de nivelul inferior pentru a implementa astfel o serie de maşini abstracte tot mai puternice. Fiecare maşină abstractă adaugă noi

21

Dispecerat Rutine de

serviciu

Apel sistem

întreruperi

Page 8: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

facilităţi dar interzice accesul direct al rutinelor din nivelele superioare la unele sau la toate facilităţile nivelelor inferioare.

Structura pe nivele este avantajoasă pentru realizarea de sisteme de operare fiabile deoarece fiecare nivel poate fi dezvoltat şi testat separat, începând cu nivelul cel mai apropiat de hardware. Odată ce un nivel a fost validat, facilităţile sale pot fi folosite la construcţia nivelelor superioare cu un grad mare de încredere că erorile întâlnite nu provin de la nivelele validate.

Figura 12: Sistemul de operare THE

În cazul sistemului THE, nivelul 0 realizează virtualizarea procesorului şi constituie nucleul sistemului de operare. Deasupra acestui nivel fiecare proces are propriul său procesor virtual şi nu trebuie să mai ia în considerare faptul că în sistem există un singur procesor fizic. Pe nivelul 1 se găseşte un singur proces, administratorul memoriei virtuale. Deasupra acestui nivel fiecare proces dispune de propria sa memorie virtuală. Următorul nivel al sistemului constă dintr-u alt proces, administratorul consolei utilizator şi face ca fiecare din procesele din nivelele superioare să dispună de o consolă virtuală proprie. Urmează nivelul pe care se găsesc procesele pentru controlul perifericelor, câte un proces pentru fiecare periferic (cu excepţia consolei şi a unui tambur magnetic suport al memoriei virtuale, tratate de procesele din nivelele anterioare). În fine, ultimul nivel al sistemului constă dintr-un număr de procese, fiecare capabil să citească şi să interpreteze ordine date în limbajul de comandă al sistemului şi să controleze execuţia unui program utilizator.

Un alt avantaj al structurării pe nivele este posibilitatea de a izola porţiunile critice ale sistemului de operare în nivelele inferioare. Aceste nivele trebuie construite şi testate cu cea mai mare grijă şi, dacă sunt suficient de mici, pot fi verificate cu mai multă rigoare, inclusiv prin procedee formale de demonstrare a corectitudinii.

Alegerea funcţiilor care se repartizează în fiecare nivel este un pas esenţial în obţinerea unui sistem satisfăcător. Nu există reguli generale în acest sens, dar sarcinile critice cum fi planificarea proceselor, gestionarea memoriei, protecţia, trebuie să apară mai jos decât sarcini ca gestionarea fişierelor şi interfaţa cu utilizatorul.

Numărul de nivele în structurarea sistemului este un alt element care nu poate fi prescris prin reguli precise. Se prezintă în figura 13 o propunere de

22

4 programe de aplicatie3 Intrare/iesire

2 consola utilizator

1 memoria virtuală

0 planif. procese, întreruperi

Page 9: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

structurare făcută de Brown, Denning şi Tichy care are 11 nivele pentru sistemul de operare, conceput a fi utilizată în sisteme de calcul distribuite.

Un caz deosebit de virtualizare prin nivele distincte în sistemul de operare îl reprezintă maşinile virtuale realizate în mai multe sisteme de operare, dar cunoscute mai ales datorită sistemului VM/370 pentru IBM System/370. În acestea nivelul rezervat pentru virtualizare realizează posibilitatea ca deasupra lui sisteme de operare distincte să pornească de la imagini abstracte (virtuale) ale unor seturi complete de resurse. Nivelul de virtualizare asigură punerea în corespondenţă a resurselor virtuale cu resursele reale ale unei anumite instalaţii.

2.4 Adaptabilitatea la configuraţiile hardware

Sistemele de operare depind în măsură destul de mare de hardware-ul calculatorului pe care rulează, aceasta fiind una dintre deosebirile între sistemele de operare şi alte sisteme software.

Este de dorit ca un sistem de operare să fie proiectat având în vedere portabilitatea, astfel încât să fie adaptabil la diferite tipuri de calculatoare. De altfel, sunt frecvente cazurile când calculatoare din aceeaşi familie apar foarte diferite din punctul de vedere al sistemului de operare.

Dacă asemenea considerente sunt mai puţin importante pentru inginerul de sistem, de importanţă directă este faptul că orice instalaţie de calcul, chiar pentru calculatoare de acelaşi tip, are caracteristici proprii: cantitatea de memorie, tipul şi numărul perifericelor, prezenţa sau absenţa anumitor opţiuni ale procesorului. Sistemul de operare trebuie adaptat la configuraţie, ceea ce ar putea implica unele modificări în codul sursă al sistemului sau doar specificarea anumitor parametri la iniţializarea sistemului. Sistemele de operare mai recente sunt astfel realizate încât să poată detecta automat caracteristicile hardware-ului şi deci să se "autoconfigureze".

15: Shell (interfata prin comenzi)

14: Serviciu de nume13: Procese utilizator12: Canal I/E tip "flux de octeti"11: Echipamente periferice10: Sistemul de fisiere9: Comunicatii interprocese

8: Capabilitati (protectie)

23

Reţea

Calculator local

Page 10: Capitol Ul 2

Capitolul 2 – Structura sistemelor de operare

7: Memoria virtuala6: Memoria secundara locala5: Procese elementare4: Intreruperi

3: Mecanisme pentru proceduri2: Setul de intructiuni1: Circuite electronice

Figura 13: Nivele ierarhice într-un sistem de calcul

24

Hardware