3. ARHITECTURA SO

Arhitectura unui sistem software, deci şi a sistemului de operare, descrie componentele sistemului software şi relaţiile dintre acestea.

Există mai multe variante de structurare a sistemelor de operare, plecând de la sistemele de operare monolitice, nestructurate, până la SO moderne caracterizate de arhitecturi complexe.

3.1 Sisteme monolitice

SO monolitice sunt formate din module cu interfeţe bine definite care specifică parametrii de apel, rezultatul şi se pot apela una pe alta fără restricţii. SO este construit prin asamblarea tuturor acestor module (proceduri) şi legarea lor într-un sigur fişier obiect.

Apelul unui serviciu se face pregătind în prealabil parametrii de apel care precizează serviciul şi operaţiile solicitate acestuia. Se execută apoi o instrucţiune specială a procesorului: TRAP care realizează comutare procesorului din mod utilizator în mod protejat (kernel-nucleu). Această comutare lansează automat modul principal care examinează parametrii pentru a determina serviciul solicitat şi apelează apoi procedura corespunzătoare lansării serviciului respectiv.

Chiar şi sistemele considerate monolitice au o structură internă simplă pe trei nivele. Primul nivel este cel care conţine modulul principal, al doilea nivel este format din procedurile care implementează serviciile SO. Un serviciu poate folosi proceduri comune cu alte servicii din sistem, astfel încât al treilea nivel conţine procedurile partajate de procedurile de pe nivelul doi.

Se constată că este realizat un prim obiectiv important, cel al separării implementării

de interfaţă. La interfaţă se oferă posibilitatea de a solicita serviciile într-o formă unitară, indicând numele serviciului şi parametrii de apel. Implementările serviciilor sunt pe nivelele inferioare şi pot fi modificate fără a modifica forma de apel a serviciului. Importanţa acestui obiectiv constă în asigurarea portabilităţii SO pe maşini fizice diferite prin realizarea de modificări minime în implementarea acestuia şi fără a afecta interfaţa cu nivelele superioare (software şi utilizator).

proceduri utilitare

proceduri servicii

Modulul principal

TRAP + param. pregătiţi

Fig.x.x Structura internă a unui sistem monolitic

3.2 Arhitectura multinivel

Modulele SO sunt organizate pe nivele multiple suprapuse vertical. Această structură are la bază separarea funcţiilor SO şi plasarea lor pe nivele diferite.

Un nivel tipic oferă un set de operaţii ce pot fi invocate de nivelul superior şi poate invoca la rândul lui operaţii ale nivelului inferior.

O perspectivă mai detaliată a relaţiei dintre două nivele adiacente ilustrează faptul că

fiecare nivel oferă în general operaţii noi, realizate prin utilizarea celor ale nivelului inferior, dar poate oferi şi acces direct la operaţii oferite de nivelul inferior.

Caracteristicile acestei arhitecturi sunt modularitatea şi invocarea de operaţii într-un

singur sens, de la nivelul superior către cel inferior. Problema care trebuie soluţionată este amplasarea corectă a nivelelor în funcţie de

relaţiile dintre ele. De exemplu, având în vedere faptul că memoria virtuală utilizează un spaţiu de pe disc, este necesar ca ea să acceseze discul prin intermediul driver-ului corespunzător. De aceea trebuie să-i poată apela funcţiile, deci trebuie ca driver-ul să fie plasat pe un nivel inferior.

nivel M

nivel M-1

operaţii noi

operaţii ascunse ale nivelului M-1

operaţii vizibile ale nivelului M-1

Interfaţa nivelului k

Niv. 0 - hardware

. . .

. . .. . .

Niv. N – interfaţa utilizator

Nivel k Nivel intermediar, cu module ale SO

Interfaţa nivelului k-1

Sistemul de operare

Manager memorie

Driver disk

Primul SO organizat pe nivele multiple a fost SO, cu prelucrare în loturi de lucrări, numit THE1. Nivelele erau dispuse conform figurii de mai jos.

Un alt exemplu este SO MULTICS care era organizat pe o structură inelară în care

nivelele sunt organizate ca inele concentrice. Operaţiile se pot face în ambele sensuri, dar pe fiecare sens există anumite restricţii de acces funcţie de privilegiile pe care le are nivelul respectiv. Inelul interior are privilegii maxime.

Această arhitectură inelară poate fi extinsă şi la nivelele software superioare,

permiţând evoluţia diferitelor componente ale unei aplicaţii pe nivele de privilegiu diferite. Această structurare pe nivele multiple are avantajul modularităţii, dar o eficienţă

scăzută datorită lanţului de apeluri. O operaţie de I/E implică un lanţ de apeluri de la fiecare nivel la următorul, fiecare apel necesitând pregătirea parametrilor specifici şi adăugând operaţii suplimentare2 operaţiei globale. De exemplu, Windows NT care utilizează o astfel de arhitectură are performanţe mai slabe decât Win 95. Totuşi, prin restructurarea nivelelor, printr-o mai bună integrare şi prin transferarea lor în spaţiul Kernel, s-a obţinut o creştere considerabilă a performanţelor la versiunile ulterioare.

3.3 Arhitectura cu maşini virtuale (în sens IBM)

Un SO în regim de timesharing oferă multiprogramare şi o maşină extinsă cu o interfaţă de programare mai simplă decât interfaţa hardware. Plecând de la ideea separării acestor două funcţii a fost implementat conceptul de maşină virtuală. Se permite astfel

1 Propus de Djikstra. 2 overhead

Nivelul cu privilegii maxime

operator

Programe utilizator

Manager de I/E

Manager comunicare

Manager memorie

Planificator procese

reproducerea identică a resursei hardware în instanţe multiple, astfel că pentru un anume hardware, un astfel de SO oferă maşini virtuale multiple.

Maşina virtuală este realizată prin soft specializat în gestiunea timpului procesor (divizat în cuante) şi pe implementarea memoriei virtuale (spaţii suficiente şi independente de memorare). Utilizând planificarea proceselor şi implementarea memoriei virtuale, un SO crează iluzia că fiecare proces are la dispoziţie un procesor propriu şi o memorie proprie, deci o maşină de calcul proprie.

Conceptul de maşină virtuală a fost introdus de sistemele IBM în forma în care maşina virtuală oferă o interfaţă identică cu nivelul hardware inferior, fără a introduce funcţionalitate suplimentară, adică fiecare proces primeşte o copie virtuală a resurselor hardware.

Procesele din sistem partajează de fapt aceleaşi resurse fizice, alocate şi gestionate în mod transparent de către software-ul de gestiune a maşinilor virtuale. Sisiemul de operare instalat pe o maşină virtuală poate fi chiar diferit de cel instalat pe o altă maşină virtuală.

La sistemul IBM de maşini virtuale, fiecare utilizator execută un SO interactiv monoutilizator numit CSM (Conversational Monitor System). Componenta software ce reprezintă implementarea conceptului de maşină virtuală este responsabilă doar cu multiprogramarea maşinilor virtuale multiple peste o maşină fizică unică.

3.4 Maşina virtuală Java (JVM)

Arhitectura JVM este oarecum diferită de modelul maşinii virtuale în sens IBM care reproduce identic resursele hardware. JVM este o specificaţie pentru un calculator abstract. Gestiunea memoriei este realizată conform unui model corespunzător lucrului cu obiecte. Alocarea memoriei se face conform acestui model, iar eliberarea se face automat, utilizând un mecanism pentru colectarea spaţiilor eliberate, numit “garbage collector”.

Structura JVM este reprezentată în figura următoare.

(a) (b)

Hardware

Soft gestiune maşini virtuale

MV1

SO1

MV2

SO2

MVk

SOk

procese proceseprocese

API API API

Hardware

SO

Procese

API

Fig. X.x Modele de sisteme fără (a) şi cu (b) implementarea conceptului de maşină virtuală în sens IBM

Modulul încărcător încarcă în sistemul gazdă fişierele ce conţin cod Java executabil

(*.class) ale aplicaţiei şi ale bibliotecilor utilizate de aceasta. Modulul de verificare este responsabil cu corectitudinea codului din fişierele încărcate,

verificând totodată şi faptul că nu se depăşeşte capacitatea stivei. Interpretorul este modulul care execută codul. El poate fi un modul software care

interpretează instrucţiune cu instrucţiune acest cod, sau poate fi un compilator JIT (“just in time”) care transformă codul în limbajul nativ al maşinii gazdă şi care asigură astfel o creştere a performanţei. Cele mai performante execuţii de cod Java au loc pe procesoarele fizice care implementează hardware interpretorul Java.

Ansamblul acestor module realizează adaptarea codului executabil Java (bytecode) la diferite sisteme gazdă, asigurând astfel independenţa şi portabilitatea sa. Pentru aceasta există implementări ale JVM pentru diferite platforme hard-soft. O platformă hard-soft este caracterizată de procesor şi de sistemul de operare instalat. JVM oferă programelor Java o interfaţă independentă de arhitectura platformei.

În concluzie, JVM oferă o maşină virtuală pentru limbajul Java. Aceasta este un context de execuţie a programelor Java care le oferă securitate, eficienţă, orientare obiect, portabilitate şi independenţă de platformă.

3.5 Arhitectura microkernel

Extinzând ideea de separare a funcţiilor sistemului de operare, arhitectura microkernel se bazează pe separarea funcţiilor în servicii specializate ale SO, cu preluarea lor ca procese în spaţiul utilizator, şi în funcţii minimale ce implementează mecanismele utilizate de aceste servicii, implementate într-un nucleu redus al SO (microkernel). Altfel spus, nucleul SO este modularizat şi o parte din aceste module sunt transferate spre executare ca şi procese de tip server în spaţiul utilizator. Nucleul este redus astfel la funcţii de gestiune minimală a proceselor, memoriei şi facilităţilor de comunicare.

Această arhitectură este bazată pe paradigma client-server şi este reprezentată în fig.Xx.

Fişiere cu cod Java executabil (bytecode)

Încărcător (class loader)

Verificator (verifier)

Interpretor (java interpreter)

Sistem gazdă

Fig.x.x Maşina virtuală Java

Apelul unui serviciu din spaţiul utilizator de către un proces client se face prin

intermediul componentei microkernel, având la bază un mecanism pentru transfer de mesaje.

Această arhitectură asigură sistemului de operare extensibilitate cu noi servicii

adăugate în spaţiul utilizator, actualizări mai puţin laborioase la nivelul unui nucleu minimal, deci o adaptare mai uşoară la diferite arhitecturi hardware, portabilitate mai bună, securitatea serviciilor şi disponibilitatea lor prin posibilităţi de implementare tolerante la erori (ex. replicare).

Sistemul de operare Apple MacOS Server este bazat pe microkernel, ca şi sistemul de operare pentru timp real QNX. La acesta din urmă microkernel-ul asigură transferul de mesaje, planificarea proceselor, gestiunea comunicării în reţea şi a întreruperilor hardware.

Sistemul de operare Windows are o structură hibridă şi poate rula aplicaţii scrise pentru diferite interfeţe de programare (API), anume Win32 pentru aplicaţii Windows native), OS/2 sau POSIX. Pentru fiecare API, SO oferă un serviciu specializat accesibil prin microkernel.

microKernel spaţiul nucleu

spaţiul utilizator

procese client

proces server terminal proces server memorie proces server fişiere

Fig.x.x Separarea şi repartizarea funcţiilor SO îmtr-o arhitectură cu microkernel

Proces client Serviciu SO în spaţiul utilizator

microkernel

Fig.x.x Apelul unui serviciu SO, în arhitectura microkernel

Aplicaţie Win32 Aplicaţie POSIX Aplicaţie POSIX

kernel

Client aplicaţie Win32

Server Win32 Server OS/2 Server POSIX

Fig.x.x Arhitectura unui sistem de calcul cu sistem de operare Windows

În fig. anterioară este ilustrată arhitectura unui sistem software compus din SO Windows, aplicaţii instalate pe acesta şi clienţi ai acestor aplicaţii. Fiecare tip de aplicaţie utilizează un server corespunzător tipului său, server ce se execută în spaţiul utilizator şi care este accesat prin intermediarea nivelului kernel al SO.

Un alt avataj major al arhitecturilor cu microkernel este acela al extensibilităţii acestora la sistemele distribuite. În acest caz modulul microkernel include şi funcţia de transfer în reţea, iar mecanismul de comunicare între componente este acelaşi mecanism de transfer de mesaje. În figura de mai jos se observă utilizarea mai multor calculatoare legate în reţea pentru a asigura funcţiile unui sistem distribuit. Pe fiecare maşină se instalează componenente microkernel identice pentru a se crea un sistem unitar.

3.6 Exemple

3.6.1 Structura unui sistem de tip UNIX

Maşina 1

Client

microkernel

Maşina k

Server fişiere

microkernel

Maşina k+1

Server procesare

microkernel

Maşina n

Server terminal

microkernel

Spaţiul utilizator

Spaţiul kernel

SHELL Proces utilizator Proces utilizator

Interfaţă apeluri sistem

Sistemul de fişeiere

Bloc memorie intermediară

Driver-e dispozitive

Gestiunea proceselor

IPC Planificare

Semnale Gestiunea memoriei

Hardware

3.6.1 Structura unui sistem de tip Windows

4. PROIECTAREA, IMPLEMENTAREA ŞI GENERAREA SO

4.1 Cerinţele de proiectare

Ca pentru orice sistem software, prima etapă în proiectarea unui sistem de operare este definirea cerinţelor şi specificaţiilor acestuia. Prima influenţă majoră în proiectarea unui SO o are alegerea componentelor hardware şi a tipului de sistem (cu loturi de lucrări sau cu partajare timp, mono/multi utilizator, distribuit, de timp real, etc.). Cerinţele de proiectare impuse unui sistem de operare pot fi împărţite în două categorii: cerinţe utilizator şi cerinţe sistem. Între cerinţele utilizator se află uşurinţa în utilizare, simplitate, disponibilitate, siguranţă şi răspuns cât mai rapid. În aceeaşi categorie se consideră şi cerinţele impuse de dezvoltatori, cum ar fi uşurinţa de a realiza proiectarea, implementarea şi întreţinerea sistemului, flexibilitatea acestuia, eficienţa şi lipsa erorilor. Aceste cerinţe sunt destul de generale şi există soluţii multiple pentru îndeplinirea lor.

Spaţiul utilizator

Spaţiul kernel

Subsistem POSIX Subsistem Win32 Subsistem OS/2

Interfaţă sistem

I/E

Serviciile sistem

Gestiunea obiectelor

Hardware

Aplicaţie Win32

Mem

orie

cac

he

pent

ru fişi

ere

Mem

orie

vi

rtuală

Pro

cese

şi f

ire

de e

xecuţie

Sec

urita

te

Sistemul de

fişiere

Drivere dispozitive Microkernel

Nivel abstract hardware

Win32 şi interfaţare grafică

Exec

utiv

4.2 Mecanism şi politică

Pentru a susţine proiectrea unui sistem de operare există o serie de principii ale ingineriei software speciale acestui tip de sisteme.

Un principiu foarte important în acest sens este cel al separării politicii de mecanism. Mecanismele determină modul în care se realizează o anumită funcţie iar politica defineşte ceea ce va realiza acea funcţie. De exemplu, un mecanism de temoprizare va lansa întreruperi la un interval prestabilit, pe când politica asociată acestuia va preciza durata intervalului respectiv.

Aplicarea principiului separării politicii de mecanism conduce la creşterea gradului de flexibilitate a sistemului. Pentru toate problemele de alocare de resurse şi de planificare de activităţi, SO trebuie să ia decizii politice. În plus, politicile sunt supuse schimbărilor cu o dinamică neneglijabilă. Dacă se aplică acest principiu şi se generalizează un anume mecanism, politica asociată acestuia poate fi redefinită fără modificarea mecanismului ci doar prin transmiterea de parametrii cu valori diferite către acesta.

SO bazate pe microkernel duc la extrem separarea politicii de mecanism prin implementarea unui set de blocuri primitive pentru construirea sistemului. Aceste blocuri implementează doar mecanisme şi permit adăugarea de mecanisme şi politici avansate în module create de utilizator. La extrema cealaltă se află SO Apple Macintosh, în care politicile şi mecanismele sunt codificate în sistem pentru a oferi o perspectivă globală a acestuia; de exemplu, toate aplicaţiile au interfeţe similare doarece interfaţa este o componentă a SO.

4.3 Implementarea SO

SO sunt implementate în mod tradiţional în limbaj de asamblare. SO moderne sunt însă dezvoltate în limbaje de nivel superior, cum ar fi C şi C++.

Avantajele utilizării limbajelor de nivel superior sunt legate de uşurinţa crescută în programare, structurarea compactă a codului, faptul că acesta este mai uşor de înţeles şi de depanat. În plus, evoluţiile tehnologice în domeniul compilatoarelor îmbunătăţesc generarea codului pentru întreg sistemul de operare prin simplă recompilare. De asemena, un SO dezvoltat într-un limbaj independent de procesor poate fi portat, cu adaptări minime, pe diferite maşini fizice.

Dezavantajele acestei abordări se referă la o viteză de execuţie mai redusă şi la cerinţa pentru capacităţi de memorare mai mari. Aceste dezavantaje pot fi însă compensate pe de o parte de tehnicile de optimizare a execuţilor oferite de compilatoare şi de procesoare şi pe de altă parte de posibilitatea de a utiliza structuri de date şi algoritmi performanţi. În plus, se poate măsura timpul de execuţie a unor secvenţe de cod în raport cu altele. Mai genereal, tot prin măsurători asupra timpilor de execuţie se pot determina zonele în care se produc “gâtuiri” ale execuţiilor. S-a observat că în jur de 80% din timpul procesor se consumă pe aprox. 20% din codul programelor, deci se va acţiona la acele secvenţe de cod cu timpi mari de execuţie şi dimensiuni reduse ale codului în sensul rescrierii lor în limbaj de asamblare.

Prin calcularea şi afişarea rezultatelor măsurătorilor de performanţă, administratorul are la dispoziţie detalii despre comportamentul diferitelor componente ale sistemului şi poate lua decizii de modificare a acestuia în timp real.

4.4 Generarea sistemului de operare

Un sistem de operare este proiectat şi apoi implementat într-o manieră flexibilă astfel încât să poată fi executat pe diferite arhitecturi hardware. SO trebuie configurat (sau generat) pentru fiecare calculator pe care se instalează.