or 2013osz 02ea leadott

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)


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


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


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


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ó)


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”


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


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


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


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


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!


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)



Ø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



Ø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



ØFunkcionalitás


Ø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)



ØFunkcionalitás


ØMinőségi elvárások, megbízhatóság

ØParadigmaváltás, új alkalmazások

ØFelhasználói élmény


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


„Hol a helyük”?

Mini Comp.(~60)

UNIX (~70)

MainframeMicro Comp.(~80)

19


„Hol a helyük”?

Mini Comp.(~60)

UNIX (~70)

MainframeMicro Comp.(~80)

PC SzerverLow-end Midrange High-end

Mainframe

Windows (~93)Linux (~91) 19


Van még tovább?

PC Szerver Mainfr.

• Van, mindkét irányban

• Nagyjából out-of-scope

20


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


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


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


Ú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


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


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


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


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


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


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


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


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


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


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


Ö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


Klasszikus (pre. SVR4) kernel

36


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


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


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


A Solaris 2 kernel

40


Konszolidáció, virtualizáció

• Solaris 10 Containers (2005 óta)• LDoms (csak T sorozat szerverein)• xVM, Domains

41


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


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


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


Linux timeline (2006-ig)

45


Linux timeline (2006-ig)1991

45



1993

45



1993 2004

45



1994

1993 2004

45


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


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


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


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


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


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


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


Windows – Kernel

53


Windows – Kernel

54


or 2013osz 02ea leadott

Documents