Upload
albert-hajdu
View
15
Download
2
Embed Size (px)
DESCRIPTION
Or 2013osz 02ea Leadott
Citation preview
Operációs Rendszerek II.
2. előadás
Első verzió: 2004/2005. I. szemeszterEz a verzió: 2013/2014. I. szemeszter 1
Monday, September 23,
A „minimál OS” világán túlMultiprogramozott rendszerek
• A rendszer egyetlen program általi kisajátítása nem „szerencsés”– Régen: drága a számítógép idő
• Kötegelt: egyetlen program ált. nem tudja folyamatosan kihasználni a rendszer erőforrásait (pl. I/O-ra vár)
• Időosztásos: a számítógépek túl drágák voltak ahhoz, hogy egy időben egyetlen ember használja őket
– Ma: hatékonyság• A PC felhasználók szeretnek egyszerre több dologgal foglalkozni
(ugye Önök is)• A szerverek egy időben több kliens kérését is ki kell, hogy szolgálják
(ezért szerverek)
Monday, September 23,
A „minimál OS” világán túlMultiprogramozott rendszerek
• Egy időben több kód fut (látszólag vagy valóban)
• A programok versenyeznek a számítógép erőforrásaiért (processzor, memória, I/O)
• Kódok az operációs rendszerre, egymásra és önmagukra is veszélyt jelenthetnek
Monday, September 23,
Több program egyidejű futtatása
• Kötegelt rendszerek esetén a rendszer terhelését maximalizáljuk
• Interaktív rendszerek esetén a válaszidőt kell kordában tartani, a programok között periodikusan kell váltani (a felhasználók egymást nem akadályozhatják)– Szerverek: itt is fontos a válaszidő, de nem
közvetlen felhasználói interakcióban, hanem gép-gép szolgáltatásban
– PC-k: egy felhasználó több programjára igaz
Monday, September 23,
Váltás programok között
• Programok közötti váltás: „ki birtokolja” a processzort? ⇒ ütemezés
• A (vissza) váltás után a program a futását ott folytassa, ahol korábban abbahagyta (hasonlót már láttunk – megszakítások)
• A processzor birtoklásán túl egyéb problémák is adódnak:– Memóriakezelés– I/O kezelés
Monday, September 23,
Memóriakezelés
• A processzor csak a központi memóriában található kódhoz/adathoz fér közvetlenül hozzá
• Programok (adatok) folyamatos mozgatása a másodlagos tárolóról/ra jelentős erőforrás és idő igényt je lentene, ezalat t a processzor semmittevésre kényszerül
• Egy időben több programot kell a memóriában tartani ⇒ egyetlen program sem sajátíthatja ki a memóriát
• A memóriamenedzsment az operációs rendszer feladata, meglehetősen összetett probléma (foglalási módok, relokáicó)
Monday, September 23,
I/O kezelés
• Minden programnak úgy kell „éreznie”, hogy csak „övé a gép” – interferencia nem lehetséges
• Az operációs rendszernek kell felügyelnie az I/O kezelést úgy, hogy a programoknak ne kelljen egymással törődniük– Megosztható és nem megosztható erőforrások– Nem megosztható erőforrás megoszthatóvá tétele
• Ha az operációs rendszer nem eléggé „szigorú” egész rendszer hatékonysága múlhat egyes programok „jólneveltségén”
Monday, September 23,
Védelem
• Az operációs rendszer védje meg magát és a programokat „egymástól”– Memória védelme– Kontroll memória műveletek (címek) alapján– Bizonyos utasítások letiltása a programnak (pl. amivel a
memória védelmet lehet befolyásolni vagy perifériához hozzáférni)
– Hardver támogatás nélkül nem lehet hatékonyan megoldani (esetleg emulációval, lassú)
• Memória védelmi rendszer • Legalább kétféle CPU üzemmód: privilegizált az OS és „normál” a
user kód számára (korlátozott)• Átjárás a két mód között: szoftver megszakítások
Monday, September 23,
Operációs rendszeri szolgáltatások
• Virtualizáció, az eredeti utasításkészlet kibővítése
• Elsődlegesen I/O menedzsment (most)– Logikai perifériák
• Másodlagos tároló: fájlok, fájlrendszerek• Humán interfész: csatornák (input, output)• Gép-gép kapcsolat: csatornák
– Absztrakciós szint eltérő lehet
Monday, September 23,
Multiprogramozott OS – értékelés
• Processzor, memória, I/O kezelése– Virtualizált környezet
• Védekezés hibás, rosszindulatú kódoktól– A folyamatok csak a saját címterükben futhatnak (önmagukat igen,
másokat nem károsíthatnak)– Az élet nem ennyire egyszerű L
• Nem megfelelő (védelmi) rendszerbeállítások• Hibák, hibák, hibák
• Környezet változására való érzékenység– Alapvetően az operációs rendszer szintjén jelentkezik– Valós és virtuális erőforrások minél teljesebb szétválasztása– Ha az OS nem kezeli a változást, alkalmazás szintről nem (vagy
nagyon nehezen) lehet rajta segíteni
Monday, September 23,
Miért hibás, késik?• A funkciók bővülése, a támogatandó hardverek körének bővülése az
operációs rendszerek komplexitásának jelentős növekedését eredményezte– Az egyik első időosztásos rendszer, a CTSS (1963, MIT) 32 000 utasításból állt– Az egy évvel később bemutatott OS/360 (IBM) mérete már 1 millió+ sort
tartalmazott– 1975-re a Multics rendszer mérete meghaladta a 20 millió programsort– Az NT 4 mérete 16 millió+ sor, a Windows 2000 ennek több, mint kétszerese volt– Ettől a kezdetben kicsi és egyszerű Unix mai mérete sem marad el– A Linux mérete is jelentősen növekedett a kezdetekhez képest
Monday, September 23,
A méret következményei
• Nehezen menedzselhető fejlesztés– A kiadások jellemzően késnek– A rendszerben mindig vannak hibák, a javítások
(bizonyos hibák megszüntetésén túl) nem egyszer újabb hibákat generálnak
– A teljesítmény sokszor nem éri el az elvárt szintet– A rendszer sérülékeny (biztonsági fenyegetések)
• A rendszer struktúrája fontos kérdés!
Monday, September 23,
Változás mozgatórugói
Meglévő kód javításán, optimalizálásán túl...
ØFunkcionalitás– Fájlrendszer funkciók (locking, quota, ACL)– Hálózati szolgáltatások– Snapshot (fájlrendszer)
Monday, September 23,
Változás mozgatórugói
ØFunkcionalitás
ØTeljesítmény, hardver fejlődése– Új hardver-technológiák (RAID, SMP)– Új hardver eszközök, családok támogatása– Teljesítmény jellemzők változása (pl. SSD)– Eszközök egymáshoz képesti teljesítmé-nyének
változása
Monday, September 23,
Változás mozgatórugói
ØFunkcionalitás
ØTeljesítmény, hardver fejlődése
ØMinőségi elvárások, megbízhatóság– Adatvesztés rendszerösszeomlás esetén– Helyreállási idő (hiba után)– Működés hibák során
Monday, September 23,
Változás mozgatórugói
ØFunkcionalitás
ØTeljesítmény, hardver fejlődése
ØMinőségi elvárások, megbízhatóság
ØParadigmaváltás, új alkalmazások– Kliens-szerver alkalmazások – Szálak– Real-time elvárások (pl. média szerverek)
Monday, September 23,
Változás mozgatórugói
ØFunkcionalitás
ØTeljesítmény, hardver fejlődése
ØMinőségi elvárások, megbízhatóság
ØParadigmaváltás, új alkalmazások
ØFelhasználói élmény
Monday, September 23,
Példa operációs rendszerekRövid ismertetés
• A szemeszterben példaként megemlített operációs rendszerek – Unix– Linux– Windows
• Miért pont ezek? Miért nem más?• Szempontok
– Történet, háttér (csak röviden)– Struktúra, felépítés áttekintése (a részletekről
szól a szemeszter)18
Monday, September 23,
„Hol a helyük”?
Mini Comp.(~60)
UNIX (~70)
MainframeMicro Comp.(~80)
19
Monday, September 23,
„Hol a helyük”?
Mini Comp.(~60)
UNIX (~70)
MainframeMicro Comp.(~80)
PC SzerverLow-end Midrange High-end
Mainframe
Windows (~93)Linux (~91) 19
Monday, September 23,
Van még tovább?
PC Szerver Mainfr.
• Van, mindkét irányban
• Nagyjából out-of-scope
20
Monday, September 23,
Unix – a kezdetek
• 1969, AT&T Bell labs: alig használt PDP-7 „a sarokban” – Multics projekt leállta utáni űr…– Space travel játék (Thompson)– A PDP-7 gépen nem volt fejlesztő környezet
(cross compilert kellett használni)– Thompson, Ritchie és mások elkezdtek írni
egyet (először a fájlrendszert, majd jött a process alrendszer és egy egyszerű shell)
21
Monday, September 23,
Unix – a kezdetek
• 1969, AT&T Bell labs: alig használt PDP-7 „a sarokban” – Multics projekt leállta utáni űr…– Space travel játék (Thompson)– A PDP-7 gépen nem volt fejlesztő környezet
(cross compilert kellett használni)– Thompson, Ritchie és mások elkezdtek írni
egyet (először a fájlrendszert, majd jött a process alrendszer és egy egyszerű shell)
21
Monday, September 23,
Unix – a kezdetek
• 1969, AT&T Bell labs: alig használt PDP-7 „a sarokban” – Multics projekt leállta utáni űr…– Space travel játék (Thompson)– A PDP-7 gépen nem volt fejlesztő környezet
(cross compilert kellett használni)– Thompson, Ritchie és mások elkezdtek írni
egyet (először a fájlrendszert, majd jött a process alrendszer és egy egyszerű shell)
21
Monday, September 23,
Unix – a kezdetek
• 1969, AT&T Bell labs: alig használt PDP-7 „a sarokban” – Multics projekt leállta utáni űr…– Space travel játék (Thompson)– A PDP-7 gépen nem volt fejlesztő környezet
(cross compilert kellett használni)– Thompson, Ritchie és mások elkezdtek írni
egyet (először a fájlrendszert, majd jött a process alrendszer és egy egyszerű shell)
21
Monday, September 23,
A történet folytatódik• Thompson, Ritchie és Ossanna meggyőzi a
BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre
• A Unix portolásra kerül, megszületnek az első egyszerű kiadvány szerkesztő programok
• Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet
• Ennek alapján – Ritchie által – megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű – és viszont
22
Monday, September 23,
A történet folytatódik• Thompson, Ritchie és Ossanna meggyőzi a
BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre
• A Unix portolásra kerül, megszületnek az első egyszerű kiadvány szerkesztő programok
• Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet
• Ennek alapján – Ritchie által – megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű – és viszont
22
Monday, September 23,
A történet folytatódik• Thompson, Ritchie és Ossanna meggyőzi a
BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre
• A Unix portolásra kerül, megszületnek az első egyszerű kiadvány szerkesztő programok
• Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet
• Ennek alapján – Ritchie által – megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű – és viszont
22
Monday, September 23,
A történet folytatódik• Thompson, Ritchie és Ossanna meggyőzi a
BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre
• A Unix portolásra kerül, megszületnek az első egyszerű kiadvány szerkesztő programok
• Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet
• Ennek alapján – Ritchie által – megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű – és viszont
22
Monday, September 23,
A történet folytatódik• Thompson, Ritchie és Ossanna meggyőzi a
BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre
• A Unix portolásra kerül, megszületnek az első egyszerű kiadvány szerkesztő programok
• Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet
• Ennek alapján – Ritchie által – megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű – és viszont
22
Monday, September 23,
A történet folytatódik• Thompson, Ritchie és Ossanna meggyőzi a
BTL-t hogy vegyenek egy PDP-11 gépet szövegszerkesztésre
• A Unix portolásra kerül, megszületnek az első egyszerű kiadvány szerkesztő programok
• Thompson a BCPL nyelvből kiindulva kifejleszti az interpretált B nyelvet
• Ennek alapján – Ritchie által – megyszületik a C nyelv. A Unix diadalútja C nélkül nem valószínű – és viszont
22
Monday, September 23,
Egy zárt világ
• A rendszer a BTL-en belül közkedveltté válik, de házon kívül nem ismerik
• 1973-ban kiadott (belső) verzió már tartalmazza a „cc” C fordítót
• Ugyanebben az évben az egész rendszert újraírják C-ben – ez a lépés alapozza meg a későbbi sikert
23
Monday, September 23,
Úton az ismertség felé• 1973: a Unix bemutatása egy ACM konferencián
(1974, első írott publikáció)• 1956-os antitröszt határozat miatt az AT&T nem
kereskedhetett számítástechnikai termékkel (sem) → az ACM konferenciát követő nagy számú megkeresés hatására az AT&T a rendszert kutatási és (egyetemi) oktatási célokra jogdíj nélkül átadta (forráskóddal együtt)
• 1975-ben már telepített Unix-ot találunk Kanadában, Izraelben és Ausztráliában is
• A Berkeley egyetem az elsők között kap Unix licencet (1974 decemberben)
24
Monday, September 23,
A sokszínűség
• A gyors terjedés mellett megkezdődnek a módosítások (forráskód elérhető)
• Az eredményeket sokszor a BTL is beépíti saját fejlesztéseibe
• A Berkeley-en különösen aktív fejlesztés folyik, az eredeti rendszert jelentősen jobbító programokat külön csomagban, pénzért (USD50) kezdik forgalmazni
25
Monday, September 23,
A BSD Unix• Először itt készül virtuális memóriakezelés Unix-hoz (32
bites VAX gépre)• 1979-ben megjelenik az első saját OS verzió (3BSD) –
ez már teljes csomag• A DARPA támogatja a Unix továbbfejlesztését (VM és
TCP/IP fejlesztés)• Fentieken túl még több jelentős újítás innen származik• 1993-ban megjelenik az utolsó (4.4BSD) verzió, a
fejlesztés befejeződik• A rendszert a BSDI viszi tovább, a történet rögtön egy
AT&T perrel indul – 1994-től érhető el a 4.4BSD-lite
26
Monday, September 23,
Az „eredeti”
• A fejlesztés a Bell berkein belül sem áll le• 1982-ben az AT&T beléphet a piacra• Időközben a Unix Support Group nevű
csapat kiadja a System III verziót (1982), majd 1983-ban a sokkal agresszívebben marketingelt System V-t. Sok kommerciális Unix alapul valamelyik System V verzión
• Jelenlei verzió az SVR4
27
Monday, September 23,
Az üzleti rendszerek• Több cég is foglalkozott saját hardverére portolt
(és kibővített) Unix forgalmazásával (ezek forrása vagy a BTL vonal, vagy a BSD volt)
• Első cég (1977) Ineractive Systems, de a Microsoft (az SCO-val együttműködve) is az elsők között van
• 1982-ben Bill Joy kilép a Berkeley-ről és m á s o k k a l e g y ü t t m e g a l a k í t j a a S u n Microsystems céget. Rendszerük a SunOS a 4.2BSD-n alapul
28
Monday, September 23,
Azok a 80-as évek
• A 80-as években több gyártó (IBM, HP, DEC és mások) is előrukkol saját új gépeivel és ehhez saját Unix verziót adnak ki
• Minden cég megpróbál egyre több extra szolgáltatást beépíteni a rendszerébe, ez gyors fejlődést eredményez.
• Ugyanakkor a különféle Unix verziók többé-kevésbé inkompatibilisek.
29
Monday, September 23,
Mach• A Unix születéskori erősségei – kis méret és
egyszerűség – az egyre több és több szolgáltatás beleintegrálásával tovatűntek
• A 80-as évek elején a pittsburgi Carnegie-Mellon egyetemen megkezdődött egy új, mikrokernel alapú operációs rendszer – a Mach – fejlesztése
• A rendszer „kívülről” BSD interfésszel bírt, ugyanakkor AT&T kódtól teljesen mentes volt.
• A 2.5-ös (még monolitikus kernelű) verzió több piaci rendszer (OSF/1 és NextStep) alapja lett, az első mikrokerneles verzió a 3.0 volt
30
Monday, September 23,
A Unix háború
• 1987-ben az AT&T szövetkezett a Sun-nal a következő System V verzió (SVR4) kidolgozására (a Sun korábban BSD vonalat használt). Megjelenik a Solaris 2.
• Ez a lépés az iparban komoly nemtetszést váltott ki, kezdetét vette a Unix háború.
• Szövetségek alakultak és szűntek meg, de egy új fenyegetés – a Windows NT – mindent megváltoztatott…
31
Monday, September 23,
A közelmúlt• A Unix név és kód a Novell-hez kerül• 1993-ban a Novell a Unix márkanevet és a
minősítés jogát átadja az X/Open konzorciumnak• A kódot a Novell eladja az SCO-nak, 2000-ben az
üzletág a Caldera-hoz kerül, neve SCO Group lesz– Az SCO a L inux szá l l í t óka t ( IBM) és
fe lhasználókat támad szel lemi tu la jdon megsértéséért (a perbe a Novell is belép, végül az SCO nem jár sikerrel)
• A gyakorlatilag csak papíron létező SCO később (2011) az unXis kezébe kerül
32
Monday, September 23,
A közelmúlt• Sok, a 80-as években virágzó gyártó eltűnik, a
megmaradtak (IBM, HP) viszont továbbra is fejlődnek – a Unix él és virul
• A Sun, mint egyik meghatározó szereplő 2009-ben az Oracle kezébe került, de ennek hosszabb távú kihatásai ma még nem láthatók. – A Solaris továbbra is fejlődik...
• Linux
33
Monday, September 23,
Szabványok• A sokféle verzió megkeserítette a fejlesztők
életét• Szabványosítási törekvések kezdődtek, de
szabványból is sok, különböző alakult ki (ezek nem a belső működést, hanem az interfészeket írják le)
• Egyik legjelentősebb szabvány az IEEE POSIX specifikáció
• A szabványos kód nem tartalmazhatja az adott platformra jellemző többlet funkciókat!
34
Monday, September 23,
Összefoglalva...• Kezdetben az akadémiai szektorban sikeres• Forráskód elérhető (feltételekkel), sok változat,
ami visszahat a „fő” kódra is• Sok neves gyártó jelentet meg saját, üzleti alapú
verziót• Az inkompatibilitás elleni harc eszközei a
különféle szabványok (pl. POSIX)• Léteznek olyan rendszerek, amelyek csak
interfész szinten Unix-ok (Mach, Mac OS, Linux)• Az idők során a Unix forrás is jelentősen
átalakult (SVR4)35
Monday, September 23,
Klasszikus (pre. SVR4) kernel
36
Monday, September 23,
Solaris – példa az „új” Unix-ra„A Solaris előtt”
• 1982: SunOS 1.0 – BSD 4.1 alapú, még Motorola 68000 alapú Sun gépre
• Hálózati technológiák komoly fejlesztése, több széles körben elterjedt (NFS, RPC). Az implementálásuk jelentős módosítást igényelt, a SunOS 2.0 már tartalmazza VFS-t (1984)
• Új VM, dinamikus linkelés (SunOS 4, 1988 – első SPARC alapú rendszer)
• Multiprocesszoros rendszerek támogatása, a SunOS 4.1 esetén még aszimmetrikus módon
• A szimmetrikus multiprocesszing nagyon más…37
Monday, September 23,
Solaris – példa az „új” Unix-ra„Solaris 2 és azon túl”
• Az AT&T szövetség hatására a Sun System V alapon teljesen új rendszerrel ál elő
• 1992, Solaris 2.0 – még csak uniprocesszoros (ezután a korábbi verziók: Solaris 1.x).
• Még ebben az évben multiprocesszoros támogatás (2.1)
• 1993-tól x86 platform támogatás• 1996-ban már 64 utas SMP (2.5.1) , ugyanekkor
fájlméret max. átlépi a 2GB-t (2.6) – FS 2.2 óta nagyobb
• Következő nagy lépés a Solaris 7 (nem 2.7), ami már 64 bites processzorokat is támogatja 38
Monday, September 23,
Solaris – példa az „új” Unix-ra„Solaris 2 és azon túl”
• Következő nagy lépés a Solaris 7 (nem 2.7), ami már 64 bites processzorokat is támogatja
• Minden verzió hoz újításokat (RBAC, újabb ütemezők, zónák és x64 támogatás), Jelenlegi verzió az Oracle Solaris 11
• OpenSolaris (Oracle felvásárlás hatásai???)• Támogatott platormok
– Sun UltraSPARC-based systems – Fujitsu SPARC64 platform-based systems – 32 and 64 bit systems based on AMD– Intel and VIA x86 CPUs
39
Monday, September 23,
A Solaris 2 kernel
40
Monday, September 23,
Konszolidáció, virtualizáció
• Solaris 10 Containers (2005 óta)• LDoms (csak T sorozat szerverein)• xVM, Domains
41
Monday, September 23,
Konszolidáció, virtualizáció
• Solaris 10 Containers (2005 óta)• LDoms (csak T sorozat szerverein)• xVM, Domains
41
Monday, September 23,
Konszolidáció, virtualizáció
• Solaris 10 Containers (2005 óta)• LDoms (csak T sorozat szerverein)• xVM, Domains
41
Monday, September 23,
Konszolidáció, virtualizáció
• Solaris 10 Containers (2005 óta)• LDoms (csak T sorozat szerverein)• xVM, Domains
41
Monday, September 23,
ZFS (zettabyte file system)
• 2004-ben jelent meg, 2006 óta a Solaris 10 része
• Storage pool-ok• Fájlrendszer és
fájlok maximális mérete: 16 EIB (264 bytes)
• stb.42
Monday, September 23,
Linux• Születése Linus Torvalds nevéhez kötődik, aki 1991-
ben fejlesztette ki 80386 alapú gépre (az University of Helsinki hallgatójaként)
• A fejlesztés egy terminál emulátor szoftverrel kezdődött (Unix-os nagygépekhez való csatlakozás megoldására), de ez lett belőle...
• A korai verziót Linus az interneten is közzétette, hamarosan meglehetősen komoly felhasználói tábort szerezve. A fejlesztés közösségi projektté vált
• Ma sokféle disztribúció, egyes esetekben modifikált kernellel (aktuális „stabil” verzió: 3.2.6)
43
Monday, September 23,
Linux• Születése Linus Torvalds nevéhez kötődik, aki 1991-
ben fejlesztette ki 80386 alapú gépre (az University of Helsinki hallgatójaként)
• A fejlesztés egy terminál emulátor szoftverrel kezdődött (Unix-os nagygépekhez való csatlakozás megoldására), de ez lett belőle...
• A korai verziót Linus az interneten is közzétette, hamarosan meglehetősen komoly felhasználói tábort szerezve. A fejlesztés közösségi projektté vált
• Ma sokféle disztribúció, egyes esetekben modifikált kernellel (aktuális „stabil” verzió: 3.2.6)
43
Monday, September 23,
Linux - verziók• Idővel különféle, egymással többé-kevésbé
kompatibilis disztribúciók alakultak ki, ezek közül „kinőtt” néhány kifejezetten üzleti megoldás is
• Az üzleti sikerekhez robosztusság, megfelelő funkcionalitás és gyártói támogatás szükséges– A támogatás nagy hardver és szoftver szállítóktól
megvan (IBM, HP, Oracle, SAP)– „Fizetős” disztribúciók: RedHat, SuSe
• Ingyenes: Debian, Fedora és „sokan mások”
44
Monday, September 23,
Linux timeline (2006-ig)
45
Monday, September 23,
Linux timeline (2006-ig)1991
45
Monday, September 23,
Linux timeline (2006-ig)1991
1993
45
Monday, September 23,
Linux timeline (2006-ig)1991
1993 2004
45
Monday, September 23,
Linux timeline (2006-ig)1991
1994
1993 2004
45
Monday, September 23,
Linux - Jellemzők
• POSIX kompatibilis felületek (felhasználói és programozói is)
• Felhasználói felületen új szabványt teremtett
• Moduláris felépítésű kernel– Dynamic linking– Stackable modules
• Virtuális fájlrendszer támogatás• Valós idejű ütemezés
46
Monday, September 23,
Linux kernel• Moduláris kernel (de nem mikrokernel, hanem
monolitikus)• Fogalmi szinten sok ponton rokonságban van a Unix
kernellel, de vannak különbségek (pl. szálak kialakítása)
• Linux esetében is kétféle mód: user és kernel mód, eltérő hozzáférési szinttel
• A kernel funkciók rendszerhívásokon keresztül érhetők el
47
Monday, September 23,
Linux kernel• Moduláris kernel (de nem mikrokernel, hanem
monolitikus)• Fogalmi szinten sok ponton rokonságban van a Unix
kernellel, de vannak különbségek (pl. szálak kialakítása)
• Linux esetében is kétféle mód: user és kernel mód, eltérő hozzáférési szinttel
• A kernel funkciók rendszerhívásokon keresztül érhetők el
47
Monday, September 23,
Linux kernel• Moduláris kernel (de nem mikrokernel, hanem
monolitikus)• Fogalmi szinten sok ponton rokonságban van a Unix
kernellel, de vannak különbségek (pl. szálak kialakítása)
• Linux esetében is kétféle mód: user és kernel mód, eltérő hozzáférési szinttel
• A kernel funkciók rendszerhívásokon keresztül érhetők el
47
Monday, September 23,
Szabványos felületek• Hordozhatóság (bináris vs. forráskód szinten)• Unix/Linux:
– különféle gyártói megoldások között (Unix)– különféle disztribúciók között (Linux)
• Linux: több helyen az „eredeti” Unixtól élesen különböző megoldás,de az interfészek szabányosak– POSIX (Portable Operating System Interface for uniX)– Single UNIX Specification (The Open Group)
• Linux Standard Base (LSB)– A különféle Linux disztribúciók által minimálisan
támogatandó API-k készlete 48
Monday, September 23,
A Microsoft „korai” operációs rendszerei
• 1981: PC-DOS 1.0 (flat FS)• 1983: DOS 2.0, XT, HDD támogatás• 1984: DOS 3.0, IBM AT• 1990: Microsoft Windows 3.0• 386 alapú rendszerek támogatására IBM
és MS közös fejlesztés (OS/2)– Összeveszés, NT fejlesztés indul– IBM viszi tovább az OS/2-t, ami soha nem lett
átütő siker (okok…)
49
Monday, September 23,
Windows - roadmap
• A Microsoft „nulláról” fejleszti a saját rendszerét, amely csak felületeiben (GUI, API) hasonlít a Windows 3-ra (okok…)
• 1993: Első Windows NT, a 3.1• 1996: NT 4.0 – Win 95 felület (kernel GUI)• 2000: Win 2000 (plug-n-play, pwr m., AD)• 2001: Win XP (csak desktop)• 2003: Win 2003 server, 64 bit (kezd. IA64)• Kurrens rendszerek: Windows 2008, Win 750
Monday, September 23,
Windows – elvárások: 1989• 32 bites, preemptive, VM támogatás• Többplatformos működés• Jó SMP skálázhatóság• Kliens-szerver környezet támogatása• MS-DOS és Win 3.x alkalmazások futtatása (de
nem minden áron…)• Kormányzati POSIX 1003.1 elvárás• Kormányzati biztonsági elvárások• Unicode támogatás
51
Monday, September 23,
Windows – célok és jellemzők• Fejlesztési célok
– Bővíthetőség – piaci elvárások– Hordozhatóság– Mezbízhatóság és robosztusság– Kompatibilitás– Teljesítmény
• Jellemzők– Valós (preemptive) multitasking– Kliens-szerver modell– SMP és szálak támogatása– Objektum alapú megközelítés– Nagyrészt C nyelvű kód
52
Monday, September 23,
Windows – Kernel
53
Monday, September 23,
Windows – Kernel
54
Monday, September 23,