Structura Sistemelor de Operare

Sistemele de Operare sunt sisteme de complexitate mare, care pentru a fi intelese si stapanite trebuie divizate in subsisteme. O cale de divizare functionala a S.O. ar fi considerarea diverselor responsabilitati ale sistemului ca module separate. Exista si alti factori cu importanta in stabilirea structurii unui S.O., cum ar fi : caracteristicile hardware ale sistemului, limbajul de implementare folosit, domeniile de aplicatie etc. Din cauza complexitatii un S.O. va apare diferit cand este examinat din puncte de vedere diferite.

Posibile puncte de vedere ar fi :

organizarea codului sursa al sistemului

organizarea memoriei

structura de executie

interactiunea dintre componente

adaptabilitatea la configuratii hardware

Organizarea memoriei.

Intotdeauna o parte a unui S.O. trebuie sa se gaseasca in memorie in timpul functionarii sistemului. Acesta este partea rezidenta a S.O. si consta din cod care trateaza servicii critice :

planificarea proceselor

tratarea erorilor

tratarea initiala a apelurilor sistem

Componentele utilizate cu frecventa redusa cum ar fi parti din sistemul de gestionare a sistemului sau interpretorul de comenzi, nu raman in permanenta in memorie ci se incarca la cerere de pe un suport extern. Acestea se numesc componente tranzitorii ale S.O..

Pentru partea rezidenta a S.O. se rezerva o zona fixa a memoriei. De obicei inceputul si sfarsitul memoriei fizice.

Pentru componentele tranzitorii ale sistemului poate fi rezervata o zona denumita sau acestea pot fi tratate la fel ca si programele utilizatorului, fiind incarcate in orice portiune de memorie disponibila.

In zona inferioara a memoriei gasim detalii despre intreruperi. Zona superioara a memoriei este uneori utilizata pentru comunicare cu perifericele iar in alte arhitecturi se foloseste pentru S.O. din motive de simplificarea scrierii programelor.

Organizarea memoriei in S.O. este prezentata prin harti de memorie, unde de regula apar 3 aspecte distincte :

continutul spatiului virtual de adrese al unui program utilizator

continutul spatiului virtual de adrese al unui program sistem

continutul memoriei fizice

In CP/M nu se face distinctie intre cele 3 aspecte, deci harta va reprezenta continutul memoriei fizice (Fig. 2.1-1).

Fig. 1.1-

In MS-DOS deosebim o harta a memoriei fizice si una a spatiului virtual de adrese a programelor (Fig. 2.1-2 si Fig. 2.1-3).

Fig. 1.1-

Din punctul de vedere al unui program spatiul virtual de adrese se compune din 1 4 segmente de 64 Kocteti. In figura Fig. 2.1-3 se prezinta cazul tipic : modelul de memorie small.

Fig. 1.1-

In UNIX harta fizica a memoriei va depinde de arhitectura calculatorului pe care este implementat sistemul.

Exista o separare totala intre spatiul de adrese al unui program utilizator si spatiul de adrese al unui program sistem (Fig. 2.1-4). Orice comunicare intre programele utilizator si sistem se face prin apeluri sistem (deci nu prin memorire comuna).

Fig. 1.1-

Obs.: Comparativ, partea rezidenta a celor trei S.O. prezentate necesita urmatoarele cantitati de memorie :

CP/M 10Kb

MS-DOS 100Kb

UNIX 1Mo

Structuri de executie.

Codul unui S.O. consta din mai multe unitati executabile, executia fiecarei unitati fiind declansata de evenimente specifice.

In organizarea traditionala S.O. pot fi privite ca o colectie de rutine, activate fiecare prin apeluri sistem din programe utilizator, sau ca urmare a unor intreruperi.

Fig. 1.2-

Rutinele care servesc ca puncte de intrerupere in S.O. trebuie sa fie in partea rezidenta a sistemului de operare.

Obs.: Majoritatea S.O. prevad un singur punct de intrare in sistem, acesta fiind un dispecer care va rezolva apelurile.

In timpul executiei acestor rutine sau altora pot apare solicitari de incarcare a unor parti nerezidente. Aduse in memorie ele vor avea acelasi nivel de privilegiu cu rutinele rezidente (exista si exceptii). Un apel sistem apare in programe cu aceeasi sintaxa ca si apelul obisnuit de rutine. Traducerea lor in cod executabil este insa diferita, prevazandu-se operatiile necesare pentru schimbarea regimului de executie (se trece din regim neprivilegiat, specific programelor utilizator, in regim privilegiat, specific S.O., adica nu mai sunt aplicate toate elementele de protectie aplicate programului utilizator).

Multe din rutinele S.O. revin la programul apelant numai dupa satisfacerea completa a serviciilor solicitate.

Exista apeluri sistem (si deci rutine din S.O.) care declanseaza activitati ce se vor desfasura simultan cu desfasurarea activitatilor U.C. fara a avea nevoie de U.C. (de exemplu operatiile de I/O). In aceste cazuri, programul care a facut apelul, e de regula suspendat pana la terminarea serviciului, iar U.C. poate fi folosit de alte programe (vezi multiprogramarea). La terminarea unui serviciu de durata, solicitat de un program, se declanseaza o intrerupere ce va face ca U.C. sa suspende executia programului in curs si sa treaca la executia rutinei de tratare a intreruperii. Ca urmare a executiei acestei rutine se vor modifica diferite structuri de date si este posibil ca programul care a fost blocat pentru efectuarea serviciului sa devina gata de executie. La terminarea rutinei de tratare a intreruperii, o componenta a S.O., numita planificator decide daca se reia executia programului care a fost suspendat in momentul aparitiei intreruperii sau se alege un alt program.

In S.O. simple toate serviciile sunt duse pana la capat fara a se reveni la programul de aplicatie sau altele.

In S.O. mai complexe, apar activitati ale S.O. care trebuie sa continuie pe o perioada mai lunga in paralel cu executia proceselor utilizator (tiparirea unor fisiere la imprimanta, controlul unor linii de telecomunicatie, o serie de activitati periodice cum ar fi la UNIX salvarea tampoanelor din memorie pe disc). Ele sunt organizate ca procese distincte, numite taskuri sistem si sunt tratate asemanator cu procesele utilizator, avand insa prioritate de planificare mai mari.

Organizarea unei parti din S.O. ca procese este o cale de reducere a erorilor in realizarea S.O. (pentru ca trebuie controlat un volum mai mic de cod). Exista o parte a codului de S.O. care ramane in afara proceselor sistem si cuprinde servicii esentiale, intre ele fiind inclusa si planificarea proceselor, comunicarea intre procese, rutine pentru gestionarea memoriei etc.

Interactiunea componentelor.

Intr-o structura fara restrictii, orice rutina a unui S.O. ar putea apela orice alta rutina sau ar putea face acces la orice structuri de date ale sistemului. Un astfel de S.O. ar fi foarte putin fiabil pentru ca ar fi extrem de dificil sa se controleze efectele unei schimbari intr-o rutina sau intr-o structura de date. Restrictii asupra interactiunilor componentelor pot fi impuse atat in procesul de proiectare a S.O. cat si in timpul executiei rutinelor sistem. La proiectare restrictiile se pot realiza prin intermediul compilatorului, daca se foloseste un limbaj adecvat pentru implementare. La executie este necesar un sprijin din partea hardware-ului, ceea ce in cele mai multe arhitecturi nu este intalnit.

Primul S.O. proiectat structurat a fost sistemul T.H.E. (Technische Hocheschool Eindhard), realizat de un grup condus de Dıkstra. A fost experimental, a aparut inainte de 1968 si a fost scris pentru minicalculatoarele Philips. Era organizat pe mai multe nivele (Fig. 2.3-1) :

Fig. 1.3-

Fiecare nivel gestioneaza o categorie de resurse, vitualizeaza resursele respective. Se realizeaza astfel o secventa de masini abstracte (sau virtuale), fiecare bazata pe masina de la nivelul inferior si fiecare oferind noi functii pentru nivelul inferior :

La nivelul 0 exista o colectie de rutine, ce realizeaza virtualizarea procesorului. deasupra acestui nivel este asigurat faptul ca fiecare proces are propriul sau procesor virtual.

La nivelul 1 exista un proces sistem care realizeaza virtualizarea memoriei. In nivelele urmatoare fiecare proces are propriul spatiu de memorie virtuala. Resursele gestionate la nivelul 1 sunt memoria interna si un tambur magnetic, care serveste ca suport extern al memoriei virtuale (precursorul discului magnetic).

Nivelul 2 contine un proces care gestioneaza consola calculatorului. Prin virtualizarea acesteia fiecare proces din nivelele superioare are propria consola utilizator, la care poate emite mesaje.

La nivelul 3 se gaseste cate un proces pentru fiecare periferic, altul decat consola sau tamburul prezent in configuratia sistemului de calcul.

Nivelul 4 contine un numar oarecare de procese care functioneaza ca interpretoare de comenzi si deci pot controla executia programelor utilizatorilor.

Structurarea pe nivele a S.O. permite ca portiunile critice ale sistemului sa fie izolate in nivelele inferioare care se construiesc si se testeaza cu foarte multa rigurozitate. Numarul de nivele din structura unui sistem nu este fix, depinde de deciziile luate de proiectanti, functie de domeniul de aplicatie, de experienta proiectantilor etc.

O extindere a modelului este prezentata in figura Fig. 2.3-2.

Fig. 1.3-

Adaptabilitatea la configuratii hardware.

S.O. depinde in mare masura de hardware-ul calculatorului, aceasta fiind una din principalele deosebiri ale S.O. fata de alte componente software. Este de dorit ca un S.O. sa fie proiectat avandu-se in vedere si portabilitatea. in cazul cel mai simplu este necesar ca un S.O. sa poata fi usor adaptat la sisteme de calcul cu configuratii diferite dar din aceeasi familie. Adica sa se poata usor specifica un numar diferit de periferice, cantitate diferita de memorie etc. In cazul extrem pentru adaptarea la o noua configuratie ar trebui facute modificari in codul sursa al S.O. Modalitatea uzuala intalnita insa este ca la initializarea S.O. sa fie consultata o serie de fisiere de configurare din care se culeg informatii specifice unui sistem de calcul dat. La MS-DOS acest fisier este config.sys, in UNIX exista mai multe fisiere de configurare pe mai multe zone functionale ale sistemului. Mai trebuie prevazuta si modalitatea de a adauga simplu la sistem portiuni de program numite drivere care controleaza functionarea unor periferice noi adaugate in configuratia hardware.