Aritoni Ovidiu Sisteme de operare 1 Introducere

B.Sisteme stratificate

O generalizare a mamierei din fig. 1.17 este a organiza sistemele de operare ca o ierarhie de straturi, fiecare strat constuit pe cel de sub el.

Primul sistem construit în acest fel a fost sistemul THE construit la Technische Hogeschool Eindhoven în Olanda de E:W: Dijkshra (1968) şi studenţii lui. Sistemul THE a fost un simplu sistem teanc pentru un computer olandez, Electrologica x8 care a avut 32 Kbytes şi 27-bit words (biţi erau cu mult înapoiaţi).

Sistemul avea 6 nivele aşa cum este arătat în figura 1.18. Nivelul O abordează (tratează) repartizarea procesorului, schimbul dintre procese când au loc întreruperii şi expiră timpii. Deasupra stratului O sistemul conţinea procese secvenţiale, fiecare putând fi programat fără a trebui să te îngrijorezi de faptul că mai multe procese rulau pe un singur procesor. În alte situatii stratul O permitea multiprogramarea procesorului.

fig 1-18. Structura sistemului de operare THE
Stratul 1 realiza administrarea memoriei aloca spaţiu pentru procesele din memoria principală şi pe un cuvânt de 512 K folosit pentru a ţine părţi din procesele pentru care nu era spaţiu în memoria principală. Deasupra nivelului 1, procesele nu erau nevoite să se îngrijoreze dacă erau în memorie principală sau în memoria auxiliară (cuvânt 512 K). Softul de pe stratul 1 se asigura că paginile erau aduse în memorie oricând era nevoie de ele.

Stratul 2 asigura comunicarea dintre fiecare proces şi consola operator. Deasupra acestui nivel fiecare proces avea efectiv propria lui consolă. Stratul 3 avea grijă de administrarea dispozitivelor de I/O şi bufflerizarea streamurilor de informaţii către şi dinspre ele. Deasupra stratului 3 fiecare proces putea trata dispozitivele abstracte de I/O cu prprietăţi drăguţe în loc de dispozitive reale cu multe curiozităţi. Stratul 4 era locul unde se găseau programele user. Ele nu trebuiau să se îngrijoreze de proces, memorie, consolă, administrare I/O. Procesele sistemelor de operare erau localizate în stratul 5.

O generalizare mai amplă a conceptului de stratificare era sistemul MULTICS. În loc de straturi MULTICS era organizat într-o serie de inele concentrice, cele din interior fiind mai privilegiate decât cele din exterior. Când o procedură dintr-un inel exterior vroia să apeleze o procedură dintr-un inel interior trebuia să facă echivalentul unui apel sistem care este o instrucţiune-capcană (instrucţiune-trap) ai căror parametrii erau cu atenţie verificaţi pentru validare înainte de a permite începerea apelului. Deşi întregul sistem de operare era parte a spaţiului adresă a fiecărei proces user în MULTICS hardul făcea posibil desemnarea procedurilor individuale, memorie, segmente (momentan protejate împotriva I/O sau executării).

În timp ce schema stratificării sistemului THE era doar un desen ajutător deoarece toate părţile sistemului erau în cele din urmă legate împreună într-un singur program-obiect în MULTICS mecanismul inelelor era foarte mult prezent la rulare şi constrâns de hard-ware. Avantajul mecanismului inelelor este că poate fi uşor extins la o structură de subsisteme user. De exemplu un profesor putea să scrie un program ca să testeze programele studenţilor şi să ruleze acest program în nivelul N iar programele studenţilor să ruleze în inelul N + 1 astfel încât să nu-şi poată schimba rangul.

C. Maşini virtuale

Sistemele generate din OS/360 erau în mod strict în sisteme stratificate. Totuşi, mulţi utilizatori ai OS 360 vroiau să aibă un time-sharing aşa că multe grupuri atât din interiorul cât şi din exteriorul IBM-ului s-au decis să realizeze sisteme cu time-sharing. Sistemul time-sharing oficial al IBM, TSS/360 a fost scos pe piaţă târziu şi când în cele din urmă a ajuns era atât de mare şi încet incat puţine pieţe s-au convertit la el. În cele din urmă a fost abandonat după ce dezvoltarea lui a costat 50 milioane de $ (Graham 1970). Dar un grup de la centrul ştinţific al IBM-ului în Cambridge Massachusetts, a produs un sistem radical diferit pe care în cele din urmă IBM l-a acceptat ca şi produs şi care este acum mult folosit pe schema lui principală.

Sistemul original numit CP/CMS şi mai târziu renumit VM 370 (1979) era bazat pe o şireată observaţie: un sistem time-sharing oferă multiprogramare şi o maşină extinsă cu o mult mai convenabilă interfaţă decât hardul gol. Esenţa lui VM 360 este de a separa complet aceste 2 funcţii.

Inima sistemului, cunoscută ca monitorul maşinii virtuale rulează pe hardul gol şi face multiprogramarea, să furnizeze nu unul ci mai multe maşinii virtuale aşa cum este arătat în figura 1.19. Oricum,spre deosebire de majoritatea sistemelor, aceste maşini virtuale nu sunt maşini extinse, cu fişiere şi alte proprietăţi drăguţe. În schimb ele sunt copii exacte ale hardului “dezgolit” incluzând modul Kernel, modul user, dispozitivele I/O, întreruperi şi orice altceva ce are maşina reală.

fig 1-19. Structura VM/370 cu CMS

Deaoarece fiecare maşină virtuală este identică cu hardul adevărat fiecare poate rula orice SO care va rula direct de pe hardul “dezgolit”. Diferite maşini virtuale pot şi fac asta frecvent, să ruleze diferite sisteme de operare. Unele rulează unul din descendenţii lui OS/360 pentru procesare de tip stratificată sau de tip tranzacţie, în timp ce altele rulează un singur sistem interactiv user numit CMS (Conversational Monytor System) pentru utilizatorii.

Când un program CMS execută un pel sistem, apelul este blocat la sistemul de operare în propria sa maşină virtuală, nu la VM 370, cum ar trebui dacă ar rula pe o maşină reală în loc de una virtuală. CMS editează instrucţiuni hardware de I/O pentru a citi discul lui virtual sau pentru orice este necesar efectuării apelului. Aceste instrucţiuni de I/O sunt blocate de VM/370 care apoi le execută ca parte a simulării hardului real. Făcând o separare completă a funcţiilor multiprogramării şi furnizând o maşină extinsă fiecare din piese poate fi mult mai simplă, mai flexibilă şi mai uşor de menţinut. Ideea de maşină virtuală este mult folosită în zilele noastre într-un contact diferit: rularea vechilor programe MS-DOS pe un Pentium (sau pe un alt procesor Intel pe 32 de biţi.) Când au fost concepute Pentiumul şi softul său atât Intel cât şi Microsoft credeau că va fi o cerere mare de rulare a vehicului soft pe noul hardware. Din acest motiv Intel a furnizat un model 8086. În acest mod maşina se comportă ca un 8086 (care este identic cu 8088 din punct de vedere al softului) incluzând adresarea pe 16 biţi cu limită de 1 MB.

Acest model este folosit de Windows OS/” şi alte sisteme de operare pentru rularea programelor MS-DOS. Aceste programe sunt pornite în modul virtual 8086. Atâta timp cât programele execută instrucţiuni normale rulează pe un hardware dezgolit. Oricum când un program încearcă să se deblocheze în sistemul de operare, să facă un apel sistem, sau încearcă să facă direct dispozitive I/O protejate, se declanşează o deblocare în monitorul maşini virtuale.

Două variante sunt posibile. La prima MS-Dosul este încărcat pe spaţiul de adresă al lui 8086 virtual, astfel că monitorul maşină virtuale doar reflectă deblocarea înapoi la MS-DOS aşa cum s-ar întâmpla pe un 8086 real. Când mai târziu MS-DOS încearcă să facă singur dispozitivele de I/O acea operaţie este prinsă şi efectuată de monitorul maşinii virtuale.

În altă variantă monitorul maşinii virtuale prinde prima deblocare şi face singur dispozitivele de I/O, din moment ce ştie ce sunt toate apelurile sistem MS-DOS şi astfel ştie ce trebuie să facă fiecare deblocare. Această variantă este mai puţin pură decât prima din moment ce doar emulează în mod corect din MS-DOS şi nu din alte sisteme de operare aşa cum face primul. Pe de altă parte este mult mai rapid din moment ce elimină problema pornirii MS-DOS ului să facă dispozitivele de I/O. Un alt dezavantaj al rulării MS-DOS ului în modul virtual 8086 este acela că „se joacă” cu bitul de întrerupere 0/1 destul de mult.

Nu a meritat efortul conceperii unui 8086 din moment ce maşina fiind rezultată din Pentium nu este un Pentium complet. Cu un sistem VM 370 este posibil să rulezi UM 370 de unul singur într-o maşină virtuală. Cu Pentium nu este posibil să rulezi un Windows într-o maşină virtuală 8086 deoarece nici o versiune a Windows-ului nu poate rula pe un 8086. Un 186 este minim chiar pentru o versiune veche şi emulaţia 286 nu este pusă la dispoziţie.

Cu VM 370 fiecare proces utilizator obţine o copie exactă a computerului actual. Cu o maşină virtuală 8086 pe Pentium, fiecare proces utilizator obţine o copie exactă a unui computer diferit. Mergând un pas mai departe, cercetătorii de la M.I.T. au construit un sistem care dă fiecărui utilizator o clonă a computerului actual dar cu un subset de resurse. Astfel o singură maşină virtuală obtine blocuri pe disc de la 1023, următoarea poate obţine blocuri de la 1024 la 2047, ş.a.m.d. La baza stratului care rulează în modul Kernel este un program (numit EXOKERNEL). Funcţia lui este să aloce resurse maşinilor virtuale şi apoi să verifice încercările de a le folosi pentru a se asigura că nici o maşină nu încearcă să folosească resursele altcuiva. Fiecare maşină virtuală utilizator pe minele poate rula propriul său sisteme de operare ca şi pe UM) 370 şi pe Pentium-urile virtuale 8086 numai că fiecare este constrânsă să folosească doar resursele pe care le-a cerut şi care i-au fost alocate. Avantajul schemei exoKernel este acela că economiseşte un nivel din proiect. În alte proiecte fiecare maşină virtuală crede că are propriul său disc cu blocuri rulând de la 0 la maxim, aşa că monitorul maşinii virtuale trebuie să menţină tabele, să redefinească adresele discului. (şi toate celelalte resurse). Cu exoKernel această redefinire nu este necesară. ExoKernelul trebuie doar să contabilizeze cărei resurse a fost atribuită maşina virtuală. Această metodă încă are avantajul de a separa multiprogramarea (în exoKernel) de codul sistemului de operare user (în spaţiul user) astfel încât maşinile virtuale să fie separate dar totuşi apropiate.