OPERATIVNI SISTEMI

1. 3. DEO OPERATIVNI SISTEMI Prof. dr Milorad K. Banjanin

2. Struktura operativnog sistema U dosadašnjem izlaganju je predstavljeno kako operativni sistemi izgledaju spolja (tj., programerov interfejs). Ova prezentacija daje pregled “iznutra”, tj. pruža uvid u dizajne koji su testirani u praksi. Biće predstavljeni sledeći dizajni: 1. monolitni sistemi 2. slojeviti sistem 3. virtuelne mašine 4. egzojezgra 5. klijent-server sistemi

3. 1.Monolitni sistemi Ovaj pristup bi se mogao nazvati '‘veliki nered'‘, jer predstavlja strukturu bez strukture. Da bi se konstruisao stvaran objektni program operativnog sistema pomoću ovog pristupa, prvo se prevode sve pojedinačne procedure, ili datoteke koje sadrže te procedure, a zatim se sve zajedno povezuju u jednu objektnu datoteku koristeći sistemski povezivač. Pri tome, mogućnost skrivanja informacija ne postoji jer je svaka procedura vidljiva za svaku proceduru. Operativni sistem je napisan kao kolekcija procedura, od kojih svaka može pozivati svaku drugu kada god želi. Kada se ova tehnika koristi, svaka procedura u sistemu ima dobro definisan interfejs u pogledu parametara i rezultata, i svaki je slobodan da poziva jedan drugog.

4. Monolitni sistemi Osnovna struktura za operativni sistem: Čak i kod monolitih sistema, moguće je imati bar malo strukture. Servisi (sistemski pozivi)koje obezbeđuje operativni sistem se zahtevaju postavljanjem parametara na dobro definisana mesta, kao što su registri ili stek, a zatim se vrši specijalna instrukcija zamke poznata kao poziv jezgra(engl. kernel call) ili poziv supervizora. 1 Glavni program koji pokreće traženu proceduru servisa. Set procedura servisa koje sprovode sistemske pozive. 2 Ova instrukcija pomera mašinu sa korisničkog moda na mod jezgra i prebacuje kontrolu na operativni sistem. Set uslužnih procedura koje pomažu servisnim procedurama. 3 Većina CPU-ova ima dva moda: mod jezgra, za operativni sistem, u kom su sve instrukcije dozvoljene; mod korisnika, za programe, u kom I/O i određene druge instrukcije nisu dozvoljene.

5. 2. Slojeviti sistemi Prvi sistem konstruisan na principu hijerarhije slojeva je bio THE sistem napravljen na Technische Hogeschool Eindhoven u Holandiji, od strane E.W.Dijkstra (1968.) i njegovih studenata. Struktura THE operativnog sistema THE sistem je bio jednostavan paketni sistem za holandski kompjuter Electrologica X8, koji je imao 32K 27-bitnih reči (biti su bili tada skupi). Sloj Funkcija Sloj 4 je bio gde se korisnički programi nalaze. Oni nisu morali da brinu o procesima, memoriji, konzoli, ili I/O menadžmentu. Proces operatera sistema je bio zaključan u sloj 5. Operater 5. Sloj 3 je upravljao I/O uređajima. Iznad sloja 3 svaki proces je mogao da radi sa apstraktnim I/O uređajima sa dobrim svojstvima, umesto sa stvarnim uređajima sa mnogo grešaka. Korisnički programi 4. Input/Output menadžment 3. Komunikacija operater-proces 2. Menadžment memorije 1. Raspoređivanje procesa i multiprogramiranje 0. Sloj 1 je radio menadžment memorije. On je raspoređivao prostor za procese u glavnoj memoriji i na 512K smeštaja reči za držanje delova procesa (stranica) za koje nije bilo prostora u glavnoj memoriji. Iznad sloja 1, procesi nisu morali da brinu o tome da li su u memoriji ili u smeštaju; softver sloja 1 je obezbeđivao da se stranice unesu u memoriju kada su potrebne. Sloj 0 je radio sa rasporedom procesora, preciavanjem između procesa kada se desi prekid ili isteknu tajmeri. Iznad sloja 0, sistem se sastojao od sekvencijalnih procesa, od kojih se svaki mogao programirati bez brige o činjenici da je više procesa pokretano na jednom procesoru. Drugim rečima, sloj 0 je obezbeđivao osnovno multiprogramiranje CPU-a. Sloj 2 je održavao komunikaciju između svakog procesa i konzole operatera. Iznad ovog sloja svaki proces je efektivno imao svoju konzolu operatera.

6. Slojeviti sistemi Dok je slojevita struktura THE sistema bila samo dizajn, jer su svi delovi sistema na kraju bili povezani zajedno u jedan objektni program, u MULTICS-u, mehanizam prstenova je bio vrlo prisutan u vreme pokretanja i iznuđen od strane hardvera. Dalja generalizacija koncepta slojeva je bila prisutna u MULTICS sistemu. Umesto slojeva, MULTICS je bio organizovan kao serija koncentričnih prstenova, gde su unutrašnji privilegovaniji od spoljašnjih. Kada procedura u spoljnjem prstenu želi da pozove proceduru u unutrašnjem prstenu, mora da izvrši ekvivalent sistemskom pozivu, odnosno, TRAP instrukciju čiji su parametri bili pažljivo provereni, osnosno njihova validnost, pre nego što se dozvoli da se poziv nastavi. Iako je čitav operativni sistem bio deo adresnog mesta svakog korisničkog procesa u MULTICS-u, hardver je omogućavao da se označe individualne procedure (segmenti memorije, u stvari) kao zaštićene od čitanja, pisanja, ili izvršenja. Pentium hardver podržava MULTICS strukturu prstenova, ali ni jedan veći operativni sistem je ne koristi danas. Prednost mehanizma prstena je što se lako može proširiti na strukturu korisničkih podsistema. Na primer, profesor može napisati program za testiranje i ocenjivanje studentskih programa i pokrenuti taj program u prstenu n, gde studentski programi rade u prstenu n+1 tako da ne mogu promeniti svoje ocene.

7. 3.Virtuelne mašine Prva izdanja OS/360 su bila striktno paketni sistemi. Ipak, mnogi 360 korisnici su hteli da imaju deljenje vremena, pa su razne grupe, i unutar i izvan IBM-a, odlučile da napišu sisteme sa deljenjem znanja. Kada se pojavio zvanični IBM sistem sa deljenjem znanja, ZSS/360, bio je veliki i spor. Na kraju je napušten nakon što je potrošeno 50 miliona dolara na razvoj (Graham, 1970). • Grupa u IBM-ovom naučnom centru u Kembridžu , Masačusets, je napravila radikalno drugačiji sistem koji je IBM na kraju prihvatio i koji se sada koristi na njihovim mejnfrejmovima. Ovaj sistem, poznat kao VM/370 (originalni naziv je bio CP/CMS), je bio zasnovan na dva važnom opažanju da sistem deljenja vremena obezbeđuje • multiprogramiranje i • proširenu mašinu sa pogodnijim interfejsom od samog hardvera. • Suština kod VM/370 je da se potpuno odvoje ove dve funkcije.

8. Virtuelne mašine Virtuelne 370 Srce sistema, poznatog kao monitor virtuelne mašine, se pokreće na golom hardveru i radi multiprogramiranje, obezbeđujući ne jednu, nego nekoliko virtuelnih mašina do sledećeg sloja na gore. Sistemski poziv ovde Slika: struktura VM/370 sa CMS CMS CMS CMS I/O instrukcje ovde Zamka ovde Zamka ovde VM/370 370 goli hardver Međutim, za razliku od svih drugih operativnih sistema, ove virtuelne mašinenisu proširene mašine, sa datotekama i ostalim finim karakteristikama. Umesto toga, one su tačne kopije golog hardvera, uključujući mod jezgra/korisnika, I/O, prekide i sve ostalo što stvarna mašina ima.

9. Virtuelne mašine Svaka virtuelna mašina je identična pravom hardveru, pa iz tog razloga svaka može pokretati bilo koji operativni sistem koji će se direktno pokretati na golom hardveru.Različite virtuelne mašine mogu (i često to i rade) pokretati različite operativne sisteme. Neke pokreću naslednike OS/360 za paketnu ili transakcionu obradu, dok drugi pokreću interaktivni sistem za jednog korisnika nazvan CMS (engl. Conversational Monitor System)za korisnike deljenja vremena. Kada CMS program izvršava sistemski poziv, poziv se zaustavlja u operativnom sistemu u njegovoj virtuelnoj mašini, , ne u VM/370. CMS zatim izdaje normalne hardverske I/O instrukcije za čitanje njegovog virtuelnog diska i slične zadatke. Ove I/O instrukcije “hvata” VM/370, koji ih zatim izvršava kao deo svoje simulacije stvarnog hardvera..

10. Virtuelne mašine Nijedan od ovih pristupa nije baš isti kao VM/370, jer mašina koja se oponaša nije potpun Pentium, nego samo 8086. Sa VM/370 sistemom, moguće je pokretati VM/370, samog, u virtuelnoj mašini. Čak i ranije verzije Windows-a zahtevaju bar 286-u i ne mogu se pokretati na virtuelnom 8086. Ideja virtuelne mašine se danas koristi u različitim kontekstima. Jedna od najznačajnijih njegovih primena je pokretanje starih MS-DOS programa na Pentiumu. Zbog velike potražnje za pokretanje starog softvera na novom hardveru, Intel je obezbedio virtuelni 8086 mod na Pentiumu. 8086 mod koriste Windows i drugi operativni sistemi za pokretanje MS-DOS programa. Sve dok izvršavaju normalne instrukcije, oni se pokreću na golom hardveru. Međutim, kada program pokuša da uđe (trap) u operativni sistem i izvrši sistemski poziv,ili pokuša da uradi zaštićen I/O direktno, pojavljuje se zamka na monitoru virtuelne mašine. 1. 2. Monitor virtuelne mašine jednostavno “hvata” prvu zamku i sam radi I/O, jer zna koji su sve MS-DOS sistemski pozivi i tako zna šta svaka zamka treba da radi. Ova varijanata je manje jasna nego prva, jer oponaša pravilno samo MS-DOS, a ne i druge operativne sisteme. S druge strane, mnogo je brža, jer nema pokretanja MS-DOS da uradi I/O. Sledeća mana stvarnog pokretanja MS-DOS-a u virtuelnom 8086 modu je što MS-DOS troši bespotrebno vreme sa prekidnim omogućiti/onemogućiti bitom. MS-DOS se sam učitava u virtuelno adresno mesto 8086-ce, tako da monitor virtuelne mašine samo reflektuje zamku nazad do MS-DOS-a, kao što bi se desilo na stvarnom 8086. Kada MS-DOS kasnije pokuša da sam uradi I/O, ta operacija se “hvata”i sprovodi od strane monitora virtuelne mašine. Moguće su dve varijatne ovog dizajna.

11. Virtuelne mašine Postoji i nekoliko komercijalnih primena virtuelnih mašina. Za kompanije koje obezbeđuju usluge web hostinga, ekonomičnije je pokretati višestruke virtuelne mašine na jednom brzom serveru nego pokretati mnogo malih kompjutera, gde svaki hostuje jedan Web sajt. VMWare i Microsoft-ov Virtual PC su takve instalacije. Ovi programi koriste velike datoteke na host sistemu kao simulirane diskove za svoje gostinske sisteme. Da bi se postigla efikasnost oni analiziraju binarnosti programa gostinskog sistema i omogućavaju da se sigurnosni kod pokreće direktno na host hardveru, hvatajući instrukcije koje vrše pozive operativnog sistema. Još jedno područje gde se koriste virtuelne mašine je pokretanje Java programa. Sun Microsystemsjeizumeo virtuelnu mašinu (tj. kompjutersku arhitekturu) nazvanu JVM (engl. Java Virtual Machine).Java kompajler proizvodi kodza JVM, koji se zatim obično izvršava softverskim JVM interpreterom. Prednost ovog pristupa je što se JVM kod može poslati poslati preko Inerneta do bilo kog kompjutera koji ima JVM interpreter i tamo pokrenuti.. Još jedna prednost korištenja JVM je ako se interpreter implementira pravilno (što nije trivijalno) JVM programima se može proveriti bezbednost i zatim izvršiti u zaštićenom okruženju tako da ne mogu ukrasti podatke ili načiniti neku štetu.

12. 4.Egzojezgra Sa VM/370, svaki korisnički proces dobija tačnu kopiju stvarnog kompjutera. Sa virtuelnim 8086 modom na Pentiumu, svaki korisnički proces dobija tačnu kopiju drugačijeg kompjutera.Istraživači u M.I.T. su otišli korak dalje i izgradili sistem koji svakom korisniku daje klon stvarnog kompjutera, ali sa podsetom resursa. Na donjem sloju, pokretan u modu jezgra, je program koji se naziva egzojezgro(engl. exokernel). Egzojezro ima zadatak da rasporedi resurse na virtuelne mašine i obezbedi da ni jedna mašina ne pokušava da koristi resurse nekog drugog. Svaka virtuelna mašina na nivou korisnika može da pokreće svoj OS, kao na VM/370 i Pentium virtuelnim 8086, osim što je svaki ograničen na korištenje onih resursa koji su zahtevani i koji su mu dodeljeni. Prednost šeme egzojezgra je štočuva sloj mapiranja. U drugim dizajnima, svaka virtuelna mašina se ponaša kao da ima svoj disk, sa blokovima koji kreću od 0 do nekog maksimuma, tako da monitor virtuelne mašine mora održavati tabele da remapira adrese diska (i svih drugih resursa). Sa egzojezgrom, ovo remapiranje nije potrebno. Egzojezgru treba samo da prati kojoj virtuelnoj mašini je dodeljen koji resurs. Ovaj metod ima i prednost odvajanja multiprogramiranja (u egzojezgru) od korisničkog koda operativnog sistema, ali sa manje dodataka, jer sve što egzojezgro treba da uradi je da odvaja virtuelne mašine jedne od drugih.

13. 5.Klijent-server model U ovom modelu sve što jezgro radi je održavanje komunikacije između klijenta i servera. Trend kod modernih OS je da iskoriste ideju pomeranja tradicionalnog koda na više slojeve i otklone što je više moguće iz OS, ostavljajući minimalno jezgro. Podelom operativnog sistema na delove, od kojih svaki radi sa jednim delom sistema (kao što je servis datoteka, servis procesa, servis terminala, ili servis memorije) svaki deo postaje mali i lako upravljiv. Pored toga, pošto se svi serveri pokreću kao procesi korisničkog moda, a ne u modu jezgra, oni nemaju direktan pristup hardveru. Kao posledica, ako se pokrene greška u serveru datoteka, servis datoteka se može urušiti, ali to obično neće dovesti čitavu mašinu do urušavanja. Uobičajen pristup je da se implementira većina funkcija OS u korisničke procese. Da bi zahtevao servis (kao npr. čitanje bloka datoteke) korisnički proces (sada poznat kao klijent proces) šalje zahtev server procesu, koji zatim obavlja posao i šalje nazad odgovor. Klijent-server model

14. 1 2 • Klijent-server model Još jedna prednost klijent-server modela je njegova prilagodljivost za upotrebu u distribuiranim sistemima. Ako klijent komunicira sa serverom slanjem poruka, klijent ne mora da zna da li se porukom upravlja lokalno na njegovoj mašini, ili je poslana preko mreže do servera na udaljenoj mašini. Što se tiče servera, ista stvar se dešava u oba slučaja: zahtev se šalje i odgovor stiže. Ova slika nije potpuno realna. Neke funkacije operativnog sistema (kao što su učitavanje komandi u registre fizičkog I/O uređaja) je teško, ako ne i nemoguće, uraditi iz programa korisničkog prostora. Postoje dva načina rešavanja ovog problema. Da se neki kritični serverski procesi (npr. drajveri I/O uređaja) zaista pokreću u modu jezgra, sa kompletnim pristupom čitavom hardveru, ali da i dalje komuniciraju sa drugim procesima koristeći normalni mehanizam poruka. Drugi način je da se ugradi minimalna količinamehanizmau jezgro, ali da se odluke politike ostave serverima u korisničkom prostoru. Na primer, jezgro može prepoznati da poruka koja je poslana određenoj specijalnoj adresi znači uzeti sadržaj te poruke i učitati ga u registre I/O uređaja za neki disk, i da se počne čitanje diska. U ovom primeru, jezgro ne bi čak ni proveravalo validnost bajta u poruci, već bi ih jednostavno slepo kopiralo na registre diska. Jedna varijanta ovog mehanizma je korištena u ranijim verzijama MINIX-a gde su drajveri prevođeni u jezgro, ali pokretani kao odvojeni procesi. Klijent-server model u distribuiranom sistemu

15. Kraj  Hvala na pažnji Prof. dr Milorad K. Banjanin