OPERÁCIÓS RENDSZEREK OS fogalom, struktúrák

Az előadások a következő témára: "OPERÁCIÓS RENDSZEREK OS fogalom, struktúrák"— Előadás másolata:

1 OPERÁCIÓS RENDSZEREK OS fogalom, struktúrák
Miskolci Egyetem Általános informatikai tanszék . OPERÁCIÓS RENDSZEREK OS fogalom, struktúrák 2006/2007. tanév I. félév Dr. Vadász Dénes The GOTO statement is considered harmful!

2 Célkitűzések, tárgyfelépítés
Miskolci Egyetem Általános informatikai tanszék Célkitűzések, tárgyfelépítés . Alapfogalmak, koncepciók, struktúrák, működés megismerése OS példák: Unix, Linux, W (a közös kiemelve) Témakörök: OS fogalom, történet, struktúrák, Felületek a kernelhez (burok és API) processzek és menedzsmentjük, memóriamendzsment, I/O, eszköz és fájlmenedzsment. Az OS-ek fejlesztése, működése és működtetése során felmerülő alapfogalmak, koncepciók, filozófiák, megfontolások, megoldások megismerése. OS-ek belső szerkezetének, működésének megértése. Nem cél OS írása. Sokféle OS létezik. Mi főleg a Unix és NT koncepcióival foglalkozunk: ezek állnak rendelkezésünkre. Érintett absztrakciók: a processz fogalom. A virtuális memória fogalom. A fájl rendszer fogalom. Az eszköz fogalom. a felhasználói kapcsolattartó fogalma. Vadász

3 Miskolci Egyetem Általános informatikai tanszék
Módszerek . Előadások: lényegkiemelés, összefoglalások Gyakorlatok: a tanszéki laborokban, teljesítendő feladatok minden gyakorlaton Teljesítés aláírás feltétele: gyakorlatokon aktív részvétel, legalább 8 gyakorlat elismertetése. Évközi zárthelyi. Aláírás pótlás a vizsgaidőszakban nincs. Vizsga: írásbeli + szóbeli. Vizsgatételek az év végén. Évközi zárthelyi beszámít. A tárgy anyaga szigorlati tananyag is! Előadásokon ismeretátadás mellett a lényeg kiemelése. Írott jegyzet a szokásos helyen. Mintaprogramok a honlapról kiinduló link segítségével elérhetők. A gyakorlatokon eleinte sh programozási, majd processz kontroll, ütemezés befolyásolás, szignálozás, IPC, a kölcsönös kizárás rendszerhívásait begyakorló programozási feladatokat kell készíteniük. Lesz fájlkezelés is, végül egyszerű rendszermenedzseri feladatok. Számonkérés: Aláírás feltétele 8 gyakorlat elismertetése. Szóbeli vizsga. A tárgy szigorlati tananyag is. Vadász

4 A gyakorlatok, gyakorlatvezetők
Miskolci Egyetem Általános informatikai tanszék A gyakorlatok, gyakorlatvezetők . IN 104 labor Répási Tibor Kedd 8: MMI Kedd 9:00 2In Kedd 12:00 2FP Kedd 15:00 3In Szerda 13:00 2EP A 102-es laborban MS W gépek. Putty terminálemulációval ssh bejelentkezés a linuxos, Aix-os, Solaris-os gépekre … Vadász

5 Miskolci Egyetem Általános informatikai tanszék
Irodalom . Tannenbaum: Modern Operating Systems, Prentice Hall, 1992. Silberschach, Galvin: Operating Systems Concepts, Addison-Wesley, 1994. Kóczy, Kondorossi szerk: Operációs rendszerek mérnöki megközelítésben, Panem, 2000. Bach: The Unix System, Prentice Hall, 1985. Vahalia: UNIX Internals: the new frontiers, Prentice Hall, 1996 Vadász: Operációs rendszerek, ME, Unix on-line manual lapok, helps stb. Tudni kell angolul olvasni! Vadász

6 Miskolci Egyetem Általános informatikai tanszék
Az ütemterv . Lásd a hirdetőtáblán! Vadász

7 Számítógéprendszer fő komponensei
Miskolci Egyetem Általános informatikai tanszék Számítógéprendszer fő komponensei . A HW fő részei: CPU, memória, eszközök, buszok A működtető rendszer: OS Az alkalmazások: segédprogramok, fejlesztők, AB rendszer, üzleti programok stb. A felhasználó: alkalmazás használó, fejlesztő stb. Emlékezzünk a Számítógép architektúrák tárgyban tanultakra! Vadász

8 Működtető rendszerek fejlődése
Miskolci Egyetem Általános informatikai tanszék Működtető rendszerek fejlődése . Direkt futtatás a hardveren Monitor Futtatható rutinok gyűjteménye, ROM. Ismeri a konzolt Konzol terminálon parancsok examine mem-cell set mem-cell go mem-cell etc. Esetleg primitív fájl-rendszer, load, store parancsok Operációs rendszer Van-e ma még direkt futtatás a hardveren? Használnak-e ma még monitor működtető rendszert? Vadász

9 Az operációs rendszer fogalma
Miskolci Egyetem Általános informatikai tanszék Az operációs rendszer fogalma . Kiterjesztett gép (Extended Machine). Kényelmessé, "felhasználóbarát" jellegűvé teszi a géphasználatot. Erőforrás menedzser. Hatékonnyá, biztonságossá, igazságossá teszi a géphasználatot. Válaszoló gép (Veszély: burok (kezelő, UI) - kernel összetévesztés) Szoftver, rendszerszoftver, amit adnak a géppel, meg sok-sok doksi …. Kiterjesztett, extended, virtuális gép …. Absztrakt instrukciókat biztosít … Már a felhasználónak is (igaz, nem az OS, hanem a burok …), pl. open a file, copy it, De „absztrakt instrukciók” a programozó számára biztosított rendszerhívás készlet is! Amikkel szolgáltatásokat kérhet a programozó a processze számára. Erőforrás menedzser: kiosztja, védi, ütemezi az erőforrásokat. Pl. a CPU-t ütemezi, megvalósítva a multiprogramozást. Válaszol is! UI parancsokra a visszatérési érték, az stdin kimenet, az eredmény; syscall-ra a szolgáltatás és annak hibakódja …. Érthető az elgondolás, de nem szeretem. Vadász

10 Miskolci Egyetem Általános informatikai tanszék
Történetük . Kapcsolódik a hardver fejlődéshez, a számítógép használók munkamegosztása történetéhez (hardveresek, rendszerprogramozók, rendszer-menedzserek, operátorok, programozók, felhasználók.) a programozási módszerek fejlődéséhez stb. Tanenbaum 4 generációt említ … Ezt az anyagrészt a Tannenbaum könyvéből jól megtanulhatjuk. Vadász

11 Miskolci Egyetem Általános informatikai tanszék
I. generáció: . (Prelingual Stage) Csövek, dugaszoló táblák, lyukkártyák Nincs munkamegosztás: egybeesik a számítógépépítő, működtető, programozó, felhasználó szerepkör Gépi nyelvű programozás Nincs operációs rendszer Vadász

12 Miskolci Egyetem Általános informatikai tanszék
II. generáció: . (Exploiting Machine Power) Tranzisztorok. Kötegelt rendszerek. Karakterorientált (1401) és szószervezésű (7094) gépek. Tervezők és építők; karbantartók; operátorok; programozók, felhasználók (Increasing the Expressive Power) FORTRAN nyelv A JOB fogalom: load-translate-load-exec szekvencia, eleinte “kézzel“, később “automatizálva“. nem_rezidens “loader“ = monitor jellegű OS. Végül: ütemező is. Tipikus a kötegelt (batch) feldolgozás Az OS fő feladata ekkor: - menedzseli az I/O eszközöket, ezekből különösen érdekes a másodlagos tárolás menedzselése és a fájlrendszer biztosítás Vadász

13 Miskolci Egyetem Általános informatikai tanszék
III. generáció: . (Reducing the Machine Dependency) Egységesítés a karakter- és szófeldolgozásban (360) Integrált áramkörök Időosztásos multiprogramozás, memória particionálás, spooling (Simultaneuos Peripheral Operation On-Line) Interaktivitás igény: kifejlődnek a parancsnyelvi értelmezők “Kis“ gépek (PDP-11, VAX 780 stb.) Sok operációs rendszer (OS360, MULTICS, RSX, Unix stb.) Hardveresek; operátorok; rendszerprogramozók; programozók; felhasználók Imperatív, funkcionális, logikai nyelvek. Szoftverkrízis (Algol, PL1, APL, LISP, PROLOG, C stb.) Az OS menedzseli már a memóriát is, eleinte single user mód. Később time sharing, és multi user mód, védelem és kölcsönös kizárási problémák megoldása. Kialakul a processz koncepció. Később interaktivitás, session létesítés. Megjelenik a real time: idő kritikus processzek, megbízhatóság és rendelkezésre állás igény. Vadász

14 Miskolci Egyetem Általános informatikai tanszék
IV. generáció: . (Reducing the Complexity) LSI, VLSI; Személyi számítógépek, munkaállomások, szuperszámítógépek Visszaesés a védelemben Interaktivitás, felhasználóbarát kapcsolattartás. GUI is! MS DOS, Unix, VAX/VMS, Novell stb. Hálózati operációs rendszerek, osztott feldolgozás Teljes a munkamegosztás Objektumorientált programozás, párhuzamos programozás, szoftvertechnológiák, CASE Vadász

15 Miskolci Egyetem Általános informatikai tanszék
És ma? . Személyi számítógépek (kliensek), szerverek, grafikus munkaállomások, különleges architektúrák, az Internet, grid Mikrokernelek Unix, MS W, Linux, mach Internet és WEB technológiák, OOP, Java, CORBA, DCOM, SW reengineering Teljes munkamegosztás, mindenki felhasználó Diagramokban a Unix és Winows fejlődéstörténete: Vadász

16 Az utóbbi évtizedek … 1985 – 95: olcsó processzálás
: olcsó sávszélesség A jövő: olcsó érzékelők … Egy másik áttekintés … Két lapot mutatok … Vadász

17 Az utóbbi évtizedek a számítástechnikában
Miskolci Egyetem Általános informatikai tanszék Az utóbbi évtizedek a számítástechnikában . Az évek 60-as 70-es 80-as 90-es A paradigma Kötegelt feldolgozás Időosztás Asztali gépek Hálózatok Hol? Számító-központban Terminál-szobában Íróasztalon Mobil Az adatok Numerikus adatok Szövegek + számok … + rajzok Multimédia Fő cél Számítások Hozzáférés Megjelení-tés Kommuni-káció Mit jelent a paradigma kifejezés? A paradigma váltás? Angolul is tanulják meg a paradigmák neveit! Vadász

18 Az utóbbi évtizedek a számítástechnikában 2
Az évek 60-as 70-es 80-as 90-es A paradigma Batch Time sharing Desktop Network Az interfész Lyuk-kártya Billentyű-zet + CRT Lásd és kattints Kérdezd és mondd Kapcsoló-dás Nincs Terminál vonalak LAN Internet Tulajdonos Intézeti sz.központ Osztályok Osztályok dolgozói Mindenki Vadász

19 OS osztályozási szempontok
Miskolci Egyetem Általános informatikai tanszék OS osztályozási szempontok . Hardver függőség szerint Személyi, kis, nagy gépek OS-e (?), architektúra független Cél szerint Általános, vagy speciális célú Processzek, processzorok, felhasználók száma szerint Single, vagy multi tasking, multi processing, multi threading Single, vagy multi user Distributed Időkiosztás szerint Szekvenciális, kooperatív, vagy beavatkozó; time sharing, real time Memóriakezelés szerint Valós címzésű, vagy virtuális címzésű I/O és fájlrendszer megvalósítás szerint Szeretünk (szeretek) osztályozni, de ezek a szempontok nem igazán „tiszták”. Erőltetettek néha … Figyeljünk a terminológiára! Multi tasking – multi processing szóhasználat! Ma már többszálúság is! Vadász

20 A számítógép architektúrában az OS
Miskolci Egyetem Általános informatikai tanszék A számítógép architektúrában az OS . Az OS rendszerszoftver, 2 fő céllal kényelmet biztosít, hatékonyságot, védelmet biztosít. Elválasztja az alkalmazásokat a hardvertől Lehetne-e struktúrálni? Alkalmazás1 Alkalmazás2 OS kernel Hardver OS – operációs rendszer rövidítése nálam. Először merül fel a kernel kifejezés. Az OS magja a kernel … Szinonimaként is fogom használni: OS - kernel Vadász

21 Egy később tovább részletezett fogalom: a folyamat (processz)
A folyamat (processz) egy (párhuzamos szerkezetet nem tartalmazó) program futó példánya Önálló entitás, azonosítható Megkülönböztetem a programtól Ugyanannak a programnak több futó példánya is lehet A processz kontextus fogalmat is fogjuk tárgyalni Az „alkalmazás” kifejezést itt „felhasználói processz” értelemben fogom használni A taszk – fonál fogalmat is tárgyaljuk majd Vadász

22 Kernel struktúrák Funkcionális szerkezetek (szolgáltatások szerinti komponensek) Implementációs szerkezetek (hogyan programozzák az egyes komponenseket). Vadász

23 Szolgáltatások szerinti komponensek
Miskolci Egyetem Általános informatikai tanszék . Szolgáltatások szerinti komponensek Processz (taszk, fonál) menedzsment komponensek CPU ütemezés, eseménykezelés, szignálozás, kölcsönös kizárás, szinkronizáció, processz-közti kommunikáció Memória menedzselő komponensek I/O menedzsment device driver interface szabad terület (blokk) menedzselése blokk allokáció, diszk blokk scheduling pufferezés Fájl-rendszert megvalósító komponensek jegyzék (directory) megvalósítás (fájl attribútumok kezelése) fájlkezelés, biztonsági komponensek Védelmi komponens(ek) Hálózatkezelő komponensek Felhasználói felület (nem feltétlenül OS komponens) Ez funkcionális struktúra. Architektúra, a legfontosabb funkciókkal, és sokszor, ezek kapcsolódásával. Ha csak felsoroljuk a funkciókat, specifikációs jellegű. Ha a kapcsolódásokat is említjük, az architektúra másik értelmében beszélünk … Itt felsoroltuk a legfontosabb szolgáltatásokat (funkciókat). Nem érdekes, hogy hogyan implementálják ezeket, és azzal sem foglalkozunk, milyenek az interfészek feléjük. Persze, ezeket a fő funkciókat lehet tovább részletezni! Vadász

24 Processz (taszk, fonál) menedzsment komponensek
Miskolci Egyetem Általános informatikai tanszék . Processz (taszk, fonál) menedzsment komponensek Ad Funkcionális struktúra Processzek kreációját és terminálódását biztosító funkciók Processz/taszk/fonál kontroll, ütemezés Állapotok nyilvántartása, CPU ütemezés, kiosztás; felfüggesztés, elvétel, processz szinkronizációs mechanizmusok (beleértve a holtpont elkerülését is biztosító kölcsönös kizárási mechanizmusokat), processzek közti kommunikációs mechanizmusok. Már most is elgondolkodhatunk azon, vajon mely funkciókat lehet kérni (syscall-lal), melyeket nem! Pl. a processzek állapotának nyilvántartását nem kell kérni. Igaz, egy-egy processz állapotáról érdeklődhetünk, de az már más funkció! Vadász

25 Memória menedzselő komponensek
Miskolci Egyetem Általános informatikai tanszék Memória menedzselő komponensek . Ad Funkcionális struktúra Memória használatának nyilvántartása Memória allokálás/felszabadítás a processzek számára Címleképzés: logikai (virtuális) címek leképzése valós (buszra kiadható) címekre) közben ki/be söprés, vagy ki/be lapozás. Utóbbiakhoz kapcsolat a másodlagos tároló menedzsmenttel. Itt is vannak kérhető és nem kérhető szolgáltatások (funkciók). Vadász

26 I/O és másodlagos tároló menedzsment
Miskolci Egyetem Általános informatikai tanszék I/O és másodlagos tároló menedzsment . Ad Funkcionális struktúra Eszközmeghajtó szoftverek (device drivers) biztosítása blokkorientált eszközökhöz (diszkekhez), karakterorientált eszközökhöz (terminálok, nyomtatók, portok stb.), speciális eszközökhöz (óra, hálózat(?)) Szabad blokk menedzselés (diszkeken) Blokk allokálás/deallokálás (fájlokhoz, virtuális memóriához) Diszk-blokk buffer cashing Kérhető – nem kérhető funkciók itt is … Nézhetjük a harmadik „struktúrálási” szempontot is: vajon hogyan implementálnak (programoznak) egy-egy funkciót? Pl egy device drivert? Vagy az előző dián említett címleképző komponenst? A virtuális memóriamenedzelést segítő ki-besöprőt? Vagy a mégelőbb említett ütemezőt? Úgye, ezek más szempontok! Vadász

27 Fájl-rendszert megvalósító komponensek
Miskolci Egyetem Általános informatikai tanszék Fájl-rendszert megvalósító komponensek . Ad Funkcionális struktúra Jegyzék (directory) struktúra biztosítása Jegyzék implementáció, fájl-attribútumok rögzítése Blokkhozzárendelés módszerei Fájlok kreálása/törlése Jegyzékek kreálása/törlése Fájlok írása/olvasása Fájlrendszer létrehozásának, helyreállításának segédprogramjai Mentések és visszaállítások segédprogramjai Még mindig a funkcionális struktúránál tartunk. Itt a restore-backup segédprogramok: nem rutinok a kernelben, hanem önálló processzek … Vadász

28 Esettanulmányok A VAX/VMS, a W NT és a UNIX funkcionális struktúrája.
6 lapot mutatunk … Vadász

29 Miskolci Egyetem Általános informatikai tanszék
A VAX/VMS struktúrája . A VAX CPU négy futási módja: User, Supervisor, Executive, Kernel. Áttérés: trap mechanizmussal. Lásd: $ MONITOR MODES U mode: alkalmazások, segédprogramok, fejlesztők S mode: a DCL (A DCL szoros kapcsolatban a VMS-sel) E mode: RMS rutinok: felelősek a fájl szervezésért; ACP-k: felelősek az elhelyezkedésért, méretekért. K mode: System Services: I/O alrendszer Memória menedzsment Processz és időkezelés Vegyes szolgáltatások (nincs az ábrán): logikai név kezelés, lock menedzsment stb. Most esettanulmányokat veszünk! Az előző „szempontjaink” vegyesen láthatók majd! VAX/VMS: Virtual Memory System ra. Miért VAX/VMS? Volt ilyen rendszerünk, ma már nincs. Sajnos, már nem tudjuk bemutatni, nem gyakorolhatnak rajta! Sajnálhatják, mert keresettek a VMS szakemberek! Mo-on pl. bankok, a MOL dolgozik VMS-ekkel, nem rossz fizető cégek ezek! Vadász

30 A VMS struktúra Vadász System-wide data structures Memory Management
I/O Subsystem Process and time management System services Kernel Record Management Service (RMS) Executive Command Language Interpreter (CLI) Supervisor Platform-Adaptation Layer (PAL) - Alpha Support Libraries Utilities Program Development Tools Layered Products (Apps) User Vadász

31 Az NT struktúra, magas szinten
OS/2 Windows POSIX Environment Subsystems User Application Subsystem DLL User/GDI Device Driver Executive Device Drivers Kernel Hardware Abstraction Layer (HAL) Mode System & Service Processes Vadász

32 Miskolci Egyetem Általános informatikai tanszék
Az NT struktúra . HAL: csatoló a HW és a mikrokernel között. A HW különbözőségeket (processzor architektúra, processzorok száma stb.) küszöböli ki. A HW gyártók készítik, szállítják. Mikrokernel: IT kezelés, ütemezés a szálakra, CPU szinkronizáció stb. Szolgáltatások: Objektum menedzser: objektum elnevezések, biztonsági tényezők kezelése. “Handle“ készítés az objektumokhoz. Folyamat menedzser: taszkok létrehozása, törlése, szálak létrehozása, törlése. Együttműködik a biztonsági rendszerrel, a memória menedzserrel. Helyi elj. hívás: (hasonlít az RPC-hez) egy alkalmazáshoz a rendszerkörnyezetet létrehozó alrendszer (kliens-szerver) létrehozáshoz hívás. Az NT (New Technology) történethez 1988/89 fordulóján kezdik, Dave Cutler és csapata a Digital-tól a MS-hoz (hasonlóság az ütemezésben, a memória menedzselésben, az I/O driver modellekben) Eredetileg az OS/2 lecserélésére, később a W 3.0 cseréjére fejlesztik Na, ez híres, érdemes nézni! Itt a HAL: ez egy réteg (rétegezettség), ha úgy tetszik: egy mikrokernel (nem nagy, az biztos). De fölötte az „igazi” mikrokernel réteg is megvan (ez már az NT „része”!) Feladata: IT kezelés, ütemezés a szálakra, CPU szinkronizáció stb. Elég „szűk” feladatokkal. Valóban mikro! Vadász

33 Miskolci Egyetem Általános informatikai tanszék
. Na, nézzük, persze, „funkcionális szempontból”! A szolgáltatások (nézd a téglalapokat): Objektum menedzser: objektum elnevezések, biztonsági tényezők kezelése. “Handle“ készítés az objektumokhoz. (A handle leginkább a Unix descriptorhoz hasonlít) Folyamat menedzser: taszkok létrehozása, törlése, szálak létrehozása, törlése. Együttműködik a biztonsági rendszerrel, a memória menedzserrel. Helyi elj. hívás: (hasonlít az RPC-hez) egy alkalmazáshoz a rendszerkörnyezetet létrehozó alrendszer (kliens-szerver) létrehozáshoz hívás. I/O menedzser: Cache funkciókat, fájl-rendszereket (FAT, NTFS, CDFS), eszköz meghajtókat (NET+diszkes) biztosít. Virtuális memória menedzser (ld. később). Megjelenítő rendszer: Win32K ablak menedzser: kezeli az ablakokat, képernyőt; a bejövő jeleket (eljuttatja az alkalmazásokhoz). GDI (Graphics Device Interface): grafikus csatoló: képernyő rajzoló eszköz (primitívek) gyűjtemény. Grafikus eszközmeghajtók (drivers): vezérlik a HW-t. A konzol (ez felhasználói szintű, csak a teljesség kedvéért itt!): szöveges ablak támogatást biztosít. Biztonsági figyelő. Windows NT Kernel Vadász

34 Az NT struktúra (folyt.)
Miskolci Egyetem Általános informatikai tanszék Az NT struktúra (folyt.) . Szolgáltatások (folyt.): I/O menedzser: Cache funkciókat, fájl-rendszereket (FAT, NTFS, CDFS), eszköz meghajtókat (NET+diszkes) biztosít. Virtuális memória menedzser (ld. később). Megjelenítő rendszer: Win32K ablak menedzser: kezeli az ablakokat, képernyőt; a bejövő jeleket (eljuttatja az alkalmazásokhoz). GDI (Graphics Device Interface): grafikus csatoló: képernyő rajzoló eszköz (primitívek) gyűjtemény. Grafikus eszközmeghajtók (drivers): vezérlik a HW-t. A konzol (ez felhasználói szintű, csak a teljesség kedvéért itt!): szöveges ablak támogatást biztosít. Biztonsági figyelő. Kérdés: mikrokerneles struktúrájú-e a Wndows? Válasz: a klasszikus mikrokernel koncepció szerint nem. A klasszikus koncepció szerint a memóriamenedzselés, a I/O és fájlrendszer, és a processz menedzselés jó része önálló processzekben van megoldva, azaz nem része a kernelnek. Itt viszont az ún. executive részei ezek a funkciók. Vadász

35 A Unix funkcionális felépítése
Miskolci Egyetem Általános informatikai tanszék . Felhasználói processz Felhasználói mód (trap) Kernel mód Programozói felület, rendszerhívás diszpécser Fájlrendszer Folyamat vezérlő alrendszer Folyamatok közti kommunikáció I/O alrendszer Buffer cache Ütemező Device drivers Memória menedzser Ez a Bach szerinti struktúra. Az ős Unix funkcionális szerkezete. Bár kevesebb téglalap van, minden fontos funkció megvan azért (pl. időkiosztó a folyamatvezérlő alrendszer részeként) Mindenesetre, egyszerű … Hardver szint Hardver, vezérlők Vadász

36 Implementációs struktúrák
Miskolci Egyetem Általános informatikai tanszék Implementációs struktúrák . Hogyan programozzák a komponenseket … Funkciókhoz rutinok … „Call” jelleggel hívható rutinok Argumentumok – visszatérési érték Megszakítással hívható rutinok (IT kezelők) Az IT típusa – Iret Eseménykezelő rutinok (esemény kezelők) Az esemény jellemzői – visszatérési érték, ha egyáltalán …) Hol lehetnek ezek a rutinok? A betöltődő kernelbe linkelve … Futtatható programba linkelve … Veszünk először néhány alap-szerkezetet. Archeo típusok. Lássuk be, az egyes alap-szerkezetek „keveredni” fognak! Elvileg sincs tiszta szerkezet! Aztán visszatérünk, mi is ennek a strukturáltságnak a lényege! Vadász

37 Lehetséges archeo típusok
Monolitikus rendszer Réteges struktúrák Az ügyfél – szolgáltató (kliens – szerver) modell A módváltás – a trap A szolgáltató rutinok (sokszor) kernel módban futnak! Akár a kernelbe vannak linkelve, Akár futtaható program rutinjai. Vadász

38 Miskolci Egyetem Általános informatikai tanszék
Monolitikus rendszer . Ad Implementációs struktúra Egyszerű szerkezet A kernel (mag): egy betölthető modulba összelinkelt, szolgáltató rutinok összessége A kernel a rendszer indításkor (teljes egészében) betöltődik A szolgáltató rutinok hívása: rendszerhívással (system call), megszakítással (IT), vagy kivételes eseményre való reagálással. Futási mód váltás (user mód - kernel mód: trap) Tipikus példa: korai Unix-ok Az OS kernel „strukturálatlan”, mondjuk. Persze, ez nem egészen igaz: van a rutinokra osztás struktúra! Az is belejátszik, hogy hogyan igénylődik (hívódik) egy-egy szolgáltatás! De az már a másik „strukturálási szempont”! (Lám, keveredik!) Ez egy alaptípus. Vadász

39 Miskolci Egyetem Általános informatikai tanszék
Réteges struktúra . Ad Implementációs struktúra A szolgáltató rutinok rétegekbe szervezettek. A rétegezés előnye Egy rétegben jól meghatározott, összetartozó funkciók Egy réteg elrejti az alatta lévő komponensek részleteit Magasabb absztrakciós szintű szolgáltatásokat biztosít: virtuális gépet A rétegeket külön-külön betölthető fájlokba linkelik A betöltés akár dinamikusan is történhet (DLL) Már a monolitikusban is lehet diszpécser réteg Lehetséges: a rétegekhez egyre privilegizáltabb futási módok. Tipikus példa: a The OS Ez egy másik alaptípus. Az ”igazi rétegesben” a rétegek külön-külön összelinkelt és betölthető (loadable) rutinok … Akár le is „cserélhetők”. Miért említjük a THE-t? Tipikus példa, híres, megérthetjük a mögöttes gondolatot. Vadász

40 Miskolci Egyetem Általános informatikai tanszék
A THE struktúrája . Rétegek 5 Operátor Az operátor indít, lelő processzeket 4 Felhasználói programok Független processzek 3 I/O menedzsment, eszközök Felette virtuális (absztrakt) I/O 2 Operátor-processz kommunikáció A processzeknek saját, virtuális konzolok 1 Memória-dob menedzsment Virtuális memória, a processz látja a teljes címtartományát Processz allokálás, multiprogramozás Virtuális CPU-k, minden processztől elrejtve a többi Látható a rétegezettség előnye! De azonnal „beugrik” a virtuális gép koncepció is! Egy-egy réteg absztrakt gépet (virtuális gépet) biztosít a felette lévő rétegnek … Erősíti bennünk azt, hogy maga az OS virtuális gép … Ez csak egy példa! Nem a The a lényeg! Amit jegyezzenek meg: a réteges struktúra egy fontos alaptípus az OS implementációkban. És átvezetés a virtuális gép koncepcióhoz, struktúrához .. Dijkstra professzor és hallgatói készítették, A rétegezés tervezési koncepció volt: egyetlen modulba linkelték. Vadász

41 A réteges struktúrától a virtuális gépig
Ad Implementációs struktúra Emlékezz: az operációs rendszer virtuális gép: ezt a koncepciót erősíti a rétegezettség A rétegek virtuális (absztrakt, kiterjesztett) gépek Absztrakt (kiterjesztett, virtuális) instrukcióknak foghatók fel a rétegek közötti felületek hívásai Vadász

42 A kliens-szerver modell
Miskolci Egyetem Általános informatikai tanszék A kliens-szerver modell . Ad Implementációs struktúra Igény a kisebb kernelre: mikrokernel Bizonyos rendszerszolgáltatások kiszolgálására önálló processzeket készítenek. Ezek önállóan linkelhetők Betöltődhetnek a rendszer egész életére, vagy időlegesen (daemon processzek) Futhatnak kernel-, vagy akár felhasználói módban Processzek közti kommunikációval kérhetők a szolgáltatások. A kernel szinte csak a kommunikációt és az időosztást biztosítja. Ebből fejlődtek ki a hálózati osztott rendszerek. Kliens-szerver modellnek nevezik, de lehetne mikrokerneles modell neve is. Értsük meg az alap gondolatot: igény a kis kernelre, a szolgáltatások többségét önálló processzek adják … Ne vezessen félre a kliens-szerver elnevezés: kétségtelen, a monolitikus rendszerben is értelmezhető a kliens: az alkalmazás processz, a szolgáltató: kernel rutin. Itt kliens az alkalmazás. És szolgáltató egy processz. Vadász

43 A kliens – szerver modell
Miskolci Egyetem Általános informatikai tanszék A kliens – szerver modell . Ad Implementációs struktúra Felhasználói mód Kernel mód Kliens processz Terminál szerver Fájl szerver Memória szerver … Kérelem, válasz üzenet Mikro-kernel Nyomtató szerver Kliens processz Kernel Fájl szerver Processz szerver Üzenet Az önálló (szolgáltató) processzek futhatnak kernel módban, de akár felhasználói módban is! Miért mikrokernel modell is ez? Mert a kernel kicsi leht, végső soron csak az ütemezést (scheduling) és a processz közti kommunikációt (IPC) biztosítja … Miért olyan fontos ez a struktúra? Mert ha a szolgáltatásokat processzek biztosítják, akkor azok akár más-más CPU-kon futhatnak, a hálózat másik gépén … De ha valaki akarja, nevezheti mikrokerneles struktúrának is! De akkor figyeljen a következőkre: ha az OS mikrokerneles (mindjárt látni fogjuk az NT HAL mikrokerneljét), a mikrokernel fölött lehetnek még – akár rétegekben – szolgáltató rutinok … Ekkor még nem „kliens-szerver” struktúra! Vadász

44 Kis összefoglalás Két oldalon összefoglaljuk a programtechnikai megoldásokat, majd tárgyaljuk a kernelbe való „belépés” és „kilépés” lehetőségeit, forgatókönyveit. Vadász

45 Programtechnikai megvalósítások
Miskolci Egyetem Általános informatikai tanszék Programtechnikai megvalósítások . Szolgáltató eljárás, függvény kód; call hívással érhető el (trap) Kivételes eseményt, megszakítást kiszolgáló rutinok; elérésük: IT-vel, kivétellel Önálló processzek (felhasználói/rendszer processzek) rutinjai; elérhetők processz közti kommunikációs mechanizmusokkal. Ilyenek pl.: a swapper; a módosított lapok készletét kiíró processz; az ACP-k (Ancillary Control Process), melyek pl. a fájloknak az eszközökön való elhelyezéséért felelősek (a rekordformátumokért az RMS felelős!); mentő/visszaállító processzek stb. Eddig az esettanulmányok … Ismételjük át a lényeget! Vadász

46 Programtechnikai megvalósítások
Statikusan betöltődő kernel rutinok (A rutinokat fordítják, összelinkelik egyetlen végrehajtható fájlba; a betöltés során betöltődik és megkapja a vezérlést) Call hívással elérhetőek (gyakran trap-pel) IT-vel elérhetőek Dinamikusan betöltődő rutinok (regisztráció -betöltés - inicializálás - szokásos hívások [call/IT] - shutdown - regisztráció megszüntetés szekvenciák) Önálló processzek (felhasználói vagy kernel szinten) Vadász

47 Hogyan juthat a vezérlés a kernelbe?
Miskolci Egyetem Általános informatikai tanszék Hogyan juthat a vezérlés a kernelbe? . A felhasználói processzekből rendszerhívással (System Call). (Ez a programozónak RTL hívásnak tűnik.) Hardverből megszakítással (Interrupt). Aszinkron. Hardverből kivételes esemény (Exeption Condition) bekövetkezésével. Váratlan, de szinkron. (Némely esetben ezt nevezik trap-nek.) Most már tudjuk, milyen is a kernel, ismerjük legfontosabb funkcióit, implementációs lehetőségeit. Tudjuk, hogy szolgáltat! Vagy maga egy kernel rutin, vagy egy önálló processz. Tudjuk (érezzük), a kernel szolgáltatásaihoz a kernel módú futás tartozik … Térjünk vissza a „felületekhez”! A kernel felületekhez. Ahhoz, hogy a kernel szolgáltasson, a vezérlés menetének be kell jutni a kernelbe! Hogyan jut be a vezérlés? Három módon … A system call: szinkron … Ahol hívódik, arról a pontról jut be a vezérlés … Természetesen, módváltással … Az IT váratlan és aszinkron. Nem lehet megmondani, hogy mely ponton … Az exeption váratlan, de szinkron. Nem lehet megmondani, bekövetkezik-e, de ha bekövetkezik, csakis adott ponton következhet (pl. túlcsordulás hiba csakis aritmetikai instrukción, de hogy lesz-e, nem tudható) Vadász

48 A kernelbe lépés eseményei (Unix)
Miskolci Egyetem Általános informatikai tanszék A kernelbe lépés eseményei (Unix) . Átkapcsolás kernel módba Push PC és PSW (már a kernel verembe!) Hívás kódja a verembe Ált. célú regiszterek lementése (assembly rutin) Hívódik syscall() : rendszerhíváshoz (ez diszpécser); trap() : kivételes eseményhez; device driver rutin : IT-hez. A diszpécser ellenőrzi, másolja a paramétereket, felkészül a megszakítására, hívja a megfelelő szolgáltató rutint. Jegyezzük meg: a syscall és kivétel kiszolgálás processz kontextusban fut, míg az IT kiszolgálás rendszer kontextusban! Az RTL-ben minden syscallhoz van egy wrapper rutin, ez hívódik. Ez a syscall kódját leteszi a user verembe … Ezután hívja a trap instrukciót (instrukciósor: HW függő!): ez kapcsol át kernel módba. Leteszik a PSLW-t (kernel verembe már) Átmásolják a syscall kódot is … lementik az általános regisztereket … A vezérlés egy dispatch tábla szerint ugrik a megfelelő szolgáltató rutinra … A processz kontextusban – rendszer kontextusban futás fogalmakat lásd később! A trap: x86-os processzoron általában INT 2E hajtódik végre. Egyes x86-on van gyorsabb SYSENTER instrukció, akkor ez. AMD-n van SYCALL instrukció, akkor az. (CRK/UnitOS-02OperatingSystemPrinciples/2.3_Win-Personalites.ppt pp12-től jó lapok a kernelbe lépésről!) Vadász

49 Visszatérés a kernelből
Miskolci Egyetem Általános informatikai tanszék Visszatérés a kernelből . Visszatérés a diszpécserhez (siker/sikertelenség jelezve); Szignál vizsgálat, szignál kiszolgálás; Ált. regiszterek visszavétele (assembly rutin); Hibakód az errno-ba, visszatérési regiszter beállítása; Return-from-interrupt instrukció (Pop PSW és PC); Visszaáll a felhasználói mód. Visszatérés egy kernel rutinból … Először a szolgáltató rutinból persze … Vadász

50 Összefoglalás. Eddig vettük:
Az OS fogalmát, OS-ek fejlődési fokozatait, OS struktúrákat különböző nézőpontok szerint: funkcionális struktúra, az implementáció szerinti struktúra. A kernelbe lépés, a kernelből való kilépés eseményeit. Ezeket később még részletezzük. Vadász

51 OPERÁCIÓS RENDSZEREK OS fogalom, struktúrák,
Miskolci Egyetem Általános informatikai tanszék . OPERÁCIÓS RENDSZEREK OS fogalom, struktúrák, Vége