VIK Wiki - Felhasználó közreműködései [hu]

Rendszermodellezés (régi)

2015-12-01T22:17:48Z

Bolla Dávid:

{{Tantárgy|nev=Rendszermodellezés|tárgykód=VIMIA405|régitárgykód=VIMIA401|kredit=5|felev=7|nagyzh=1|kereszt=változó|kiszh=0|vizsga=nincs|hf=2 db|szak=info|tad=https://www.vik.bme.hu/kepzes/targyak/VIMIA401/|targyhonlap=https://www.inf.mit.bme.hu/edu/courses/remo/|levlista=remoATsch.bme.hu }}

{{Régi tárgy|Rendszermodellezés}}

== Követelmények ==

A tárgy átalakult. Már félévközis.

* Egy darab HF (2 részből áll - 2 leadási határidővel) - bármelyiket nem adod be időben pótolhatod, cserébe nincs konzulens + egy darab ZH
* Heti 2 előadás van, kötelező jelenléti ív nincs.
* A gyakorlatok a 3. héttől a 10. hétig tartanak, kötelező jelenléti ív nincs.
* Ajánlott rövidítések: '''ReMo'''
== Segédanyagok ==

*[[Média: ReMo röviden.pdf|Összefoglaló a diák alapján]]
*[https://docs.google.com/document/d/1_1W1hkHEn2ixJykilgPm99XxWJatmq7hu57ktJw2Wss/edit Gyak feladatok szerkeszthető doksi]
*[https://docs.google.com/document/d/1Mf_n4LuLEN5Efx7S_LDPrS26AiPdhkonmtlSAlKuL_8/edit ZH és gyak feladatok vegyesen]

== Gyakorlatok ==

1. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/1-gyakorlat-modellez%C3%A9s-alapok modellezés alapok]

2. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/2-gyakorlat-%C3%A1llapot-alap%C3%BA-modellez%C3%A9s állapot alapú modellezés]

3. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/3-gyakorlat-felt%C3%A1r%C3%B3-adatelemz%C3%A9s feltáró adatelemzés]

4. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/4-gyakorlat-teljes%C3%ADtm%C3%A9nyelemz%C3%A9s teljesítményelemzés]

5. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/5-gyakorlat-k%C3%ADs%C3%A9rlettervez%C3%A9s-%C3%A9s-adatfolyamh%C3%A1l%C3%B3k kísérlettervezés és adatfolyamhálók]

6. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/6-gyarkorlat-hibamodellez%C3%A9s hibamodellezés]

Van táltos gyakorlat is, Dr. Pataricza András tartja.

== Házi ==
Egy "e-Business" rendszer modellezése az IBM WebSphere programmal.
A házi feladatot a MIT tanszék VCL cloudban kell megoldani. Érdemes időben nekilátni, mert a beadás környékén a rendszer túlterhelődhet.
Pontos házi feladat feltételek [https://www.inf.mit.bme.hu/edu/courses/remo/hazi-feltetelek itt megtalálhatóak]
Házi feladat tanácsok pedig [https://www.inf.mit.bme.hu/edu/courses/remo/hazi-tanacsok itt találhatóak]

=== 1. Házi ===
Kezdeti modell (6. hét)
* Kiadott feladat/Önálló ötlet alapján egy üzleti folyamat specifikációja
* Folyamattal kapcsolatos minimális követelmények a weboldalon
* Erőforrások+elemzésszempontjai
* Elkészített folyamatmodell + erőforráshozzárendelés

=== 2. Házi ===
Végleges modell (13. hét)
* Analízisvégrehajtása
* Eredmények értékelése jegyzőkönyvben
* Szóbeli védés a 14. héten

=== Szorgalmi házi ===

Kétféle szorgalmi házi is létezik, [https://www.inf.mit.bme.hu/edu/courses/materials/rendszermodellezés/2012-ősz/szorgalmi-feladat-ki%C3%ADrás itt megtalálható a pontos leírása]

== ZH ==
Egy darab ZH van a kb. október végen. Elméleti kérdésekből, illetve két gyakorlati feladatból áll.

=== Elméleti kérdések ===
Pár mondatban megválaszolható kérdések, ha jól emlékszem 5-6 darab volt belőle. Ezekhez hasonlóak:
* Little törvény mit mond ki és mikor érvényes
* nyílt/zárt világ modell fogalma
* taxonómia/ontológia fogalma
* lineáris/exponenciális regresszió fogalma, példák
* benchmark, fajtái

=== Feladatok ===
Gyakorlaton megoldott példák szoktak szerepelni:
* Ontológia készítése. (1. gyakorlathoz hasonlóak)
* Diagramok felismerése, azok értelmezése. (2. gyakorlathoz hasonlóak)
* Teljesítménymodellezési számolós feladatok (3. gyakorlathoz hasonlóak)
* Kísérlettervezési számolós feladatok (4. gyakorlathoz hasonlóak)

== Vizsga ==
Őszi félévben decemberben két vizsga van és januárban is kettő. A decemberi első vizsga élővizsga, bárki mehet rá. (Elsősorban a záróvizsgások érdekében van így)
A vizsga elméleti kérdésekből, illetve három gyakorlati feladatból áll.

=== Elméleti kérdések ===
Pár mondatban megválaszolható kérdések, ha jól emlékszem 6-7 darab volt belőle. A ZH-n szereplő kérdések is elöfordulhatnak, illetve a ZH utáni anyagból is természetesen.

=== Feladatok ===
Gyakorlaton megoldott példák szoktak szerepelni:
* Ontológia készítése. (1. gyakorlathoz hasonlóak)
* Diagramok felismerése, azok értelmezése. (2. gyakorlathoz hasonlóak)
* Teljesítménymodellezési számolós feladatok (4. gyakorlathoz hasonlóak)
* Kísérlettervezési számolós feladatok (5. gyakorlathoz hasonlóak)
* Adatfolyamhálók rajzolása (5. gyakorlathoz hasonlóak)
* Szolgáltatásbiztonság számolós feladatok (6. gyakorlathoz hasonlóak)

== Hasznos linkek ==
* Meghibásodási adatok egyenesen a tanszéktől: https://wiki.inf.mit.bme.hu/twiki/pub/InfInf/RelModel/meghibasodasi_adatok.pdf

== Tippek ==

Előadásokra érdemes bemenni, de anélkül is megtanulható, csak nem érted meg annyira az anyagot csak a diákból. Gyakorlatokra nagyon érdemes bemenni, mert az ott megoldott példákhoz hasonló feladatok lesznek ZH-n és vizsgán. Házi kiadó órára mindenképp érdemes bemenni, ott mutatják be az IBM WebSphere szoftver használatát, illetve ott kapjuk meg a szoftver image-et.

== Kedvcsináló ==

Szerintem a legjobb/korrektebb/könnyebb tárgy a három elágazó közül. Ha informatikai technológiák szakirányon vagy, akkor pedig van is átfedés szakirányos tárggyal, így pláne nem nehéz. A zh-ra érdemes felkészülni mert 4-es zh-val szorgalmi feladatot lehet írni, a szorgalmi feladat pedig egyáltalán nem vészes, ellenben megajánlott ötöst ér.

--[[Szerkesztő:Ferrero|Szabó Csaba]] ([[Szerkesztővita:Ferrero|vita]]) 2013. január 3., 19:15 (CET)

{{Lábléc_-_Mérnök_informatikus_alapszak}}

Rendszermodellezés (régi)

2015-11-23T09:54:01Z

Bolla Dávid: /* Szorgalmi házi */

{{Tantárgy|nev=Rendszermodellezés|tárgykód=VIMIA405|régitárgykód=VIMIA401|kredit=5|felev=7|nagyzh=1|kereszt=változó|kiszh=0|vizsga=nincs|hf=2 db|szak=info|tad=https://www.vik.bme.hu/kepzes/targyak/VIMIA401/|targyhonlap=https://www.inf.mit.bme.hu/edu/courses/remo/|levlista=remoATsch.bme.hu }}

{{Régi tárgy|Rendszermodellezés}}

== Követelmények ==

A tárgy átalakult. Már félévközis.

* Egy darab HF (2 részből áll - 2 leadási határidővel) - bármelyiket nem adod be időben pótolhatod, cserébe nincs konzulens + egy darab ZH
* Heti 2 előadás van, kötelező jelenléti ív nincs.
* A gyakorlatok a 3. héttől a 10. hétig tartanak, kötelező jelenléti ív nincs.
* Ajánlott rövidítések: '''ReMo'''

== Gyakorlatok ==

1. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/1-gyakorlat-modellez%C3%A9s-alapok modellezés alapok]

2. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/2-gyakorlat-%C3%A1llapot-alap%C3%BA-modellez%C3%A9s állapot alapú modellezés]

3. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/3-gyakorlat-felt%C3%A1r%C3%B3-adatelemz%C3%A9s feltáró adatelemzés]

4. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/4-gyakorlat-teljes%C3%ADtm%C3%A9nyelemz%C3%A9s teljesítményelemzés]

5. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/5-gyakorlat-k%C3%ADs%C3%A9rlettervez%C3%A9s-%C3%A9s-adatfolyamh%C3%A1l%C3%B3k kísérlettervezés és adatfolyamhálók]

6. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/6-gyarkorlat-hibamodellez%C3%A9s hibamodellezés]

Van táltos gyakorlat is, Dr. Pataricza András tartja.

== Házi ==
Egy "e-Business" rendszer modellezése az IBM WebSphere programmal.
A házi feladatot a MIT tanszék VCL cloudban kell megoldani. Érdemes időben nekilátni, mert a beadás környékén a rendszer túlterhelődhet.
Pontos házi feladat feltételek [https://www.inf.mit.bme.hu/edu/courses/remo/hazi-feltetelek itt megtalálhatóak]
Házi feladat tanácsok pedig [https://www.inf.mit.bme.hu/edu/courses/remo/hazi-tanacsok itt találhatóak]

=== 1. Házi ===
Kezdeti modell (6. hét)
* Kiadott feladat/Önálló ötlet alapján egy üzleti folyamat specifikációja
* Folyamattal kapcsolatos minimális követelmények a weboldalon
* Erőforrások+elemzésszempontjai
* Elkészített folyamatmodell + erőforráshozzárendelés

=== 2. Házi ===
Végleges modell (13. hét)
* Analízisvégrehajtása
* Eredmények értékelése jegyzőkönyvben
* Szóbeli védés a 14. héten

=== Szorgalmi házi ===

Eltörölték.

== ZH ==
Egy darab ZH van a kb. október végen. Elméleti kérdésekből, illetve két gyakorlati feladatból áll.

=== Elméleti kérdések ===
Pár mondatban megválaszolható kérdések, ha jól emlékszem 5-6 darab volt belőle. Ezekhez hasonlóak:
* Little törvény mit mond ki és mikor érvényes
* nyílt/zárt világ modell fogalma
* taxonómia/ontológia fogalma
* lineáris/exponenciális regresszió fogalma, példák
* benchmark, fajtái

=== Feladatok ===
Gyakorlaton megoldott példák szoktak szerepelni:
* Ontológia készítése. (1. gyakorlathoz hasonlóak)
* Diagramok felismerése, azok értelmezése. (2. gyakorlathoz hasonlóak)
* Teljesítménymodellezési számolós feladatok (3. gyakorlathoz hasonlóak)
* Kísérlettervezési számolós feladatok (4. gyakorlathoz hasonlóak)

== Vizsga ==
Őszi félévben decemberben két vizsga van és januárban is kettő. A decemberi első vizsga élővizsga, bárki mehet rá. (Elsősorban a záróvizsgások érdekében van így)
A vizsga elméleti kérdésekből, illetve három gyakorlati feladatból áll.

=== Elméleti kérdések ===
Pár mondatban megválaszolható kérdések, ha jól emlékszem 6-7 darab volt belőle. A ZH-n szereplő kérdések is elöfordulhatnak, illetve a ZH utáni anyagból is természetesen.

=== Feladatok ===
Gyakorlaton megoldott példák szoktak szerepelni:
* Ontológia készítése. (1. gyakorlathoz hasonlóak)
* Diagramok felismerése, azok értelmezése. (2. gyakorlathoz hasonlóak)
* Teljesítménymodellezési számolós feladatok (4. gyakorlathoz hasonlóak)
* Kísérlettervezési számolós feladatok (5. gyakorlathoz hasonlóak)
* Adatfolyamhálók rajzolása (5. gyakorlathoz hasonlóak)
* Szolgáltatásbiztonság számolós feladatok (6. gyakorlathoz hasonlóak)

== Hasznos linkek ==
* Meghibásodási adatok egyenesen a tanszéktől: https://wiki.inf.mit.bme.hu/twiki/pub/InfInf/RelModel/meghibasodasi_adatok.pdf

== Tippek ==

Előadásokra érdemes bemenni, de anélkül is megtanulható, csak nem érted meg annyira az anyagot csak a diákból. Gyakorlatokra nagyon érdemes bemenni, mert az ott megoldott példákhoz hasonló feladatok lesznek ZH-n és vizsgán. Házi kiadó órára mindenképp érdemes bemenni, ott mutatják be az IBM WebSphere szoftver használatát, illetve ott kapjuk meg a szoftver image-et.

== Kedvcsináló ==

Szerintem a legjobb/korrektebb/könnyebb tárgy a három elágazó közül. Ha informatikai technológiák szakirányon vagy, akkor pedig van is átfedés szakirányos tárggyal, így pláne nem nehéz. A zh-ra érdemes felkészülni mert 4-es zh-val szorgalmi feladatot lehet írni, a szorgalmi feladat pedig egyáltalán nem vészes, ellenben megajánlott ötöst ér.

--[[Szerkesztő:Ferrero|Szabó Csaba]] ([[Szerkesztővita:Ferrero|vita]]) 2013. január 3., 19:15 (CET)

{{Lábléc_-_Mérnök_informatikus_alapszak}}

Rendszermodellezés (régi)

2015-11-23T09:52:51Z

Bolla Dávid: /* Követelmények */

{{Tantárgy|nev=Rendszermodellezés|tárgykód=VIMIA405|régitárgykód=VIMIA401|kredit=5|felev=7|nagyzh=1|kereszt=változó|kiszh=0|vizsga=nincs|hf=2 db|szak=info|tad=https://www.vik.bme.hu/kepzes/targyak/VIMIA401/|targyhonlap=https://www.inf.mit.bme.hu/edu/courses/remo/|levlista=remoATsch.bme.hu }}

{{Régi tárgy|Rendszermodellezés}}

== Követelmények ==

A tárgy átalakult. Már félévközis.

* Egy darab HF (2 részből áll - 2 leadási határidővel) - bármelyiket nem adod be időben pótolhatod, cserébe nincs konzulens + egy darab ZH
* Heti 2 előadás van, kötelező jelenléti ív nincs.
* A gyakorlatok a 3. héttől a 10. hétig tartanak, kötelező jelenléti ív nincs.
* Ajánlott rövidítések: '''ReMo'''

== Gyakorlatok ==

1. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/1-gyakorlat-modellez%C3%A9s-alapok modellezés alapok]

2. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/2-gyakorlat-%C3%A1llapot-alap%C3%BA-modellez%C3%A9s állapot alapú modellezés]

3. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/3-gyakorlat-felt%C3%A1r%C3%B3-adatelemz%C3%A9s feltáró adatelemzés]

4. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/4-gyakorlat-teljes%C3%ADtm%C3%A9nyelemz%C3%A9s teljesítményelemzés]

5. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/5-gyakorlat-k%C3%ADs%C3%A9rlettervez%C3%A9s-%C3%A9s-adatfolyamh%C3%A1l%C3%B3k kísérlettervezés és adatfolyamhálók]

6. gyakorlat: [https://inf.mit.bme.hu/edu/courses/materials/rendszermodellez%C3%A9s/2014-%C5%91sz/6-gyarkorlat-hibamodellez%C3%A9s hibamodellezés]

Van táltos gyakorlat is, Dr. Pataricza András tartja.

== Házi ==
Egy "e-Business" rendszer modellezése az IBM WebSphere programmal.
A házi feladatot a MIT tanszék VCL cloudban kell megoldani. Érdemes időben nekilátni, mert a beadás környékén a rendszer túlterhelődhet.
Pontos házi feladat feltételek [https://www.inf.mit.bme.hu/edu/courses/remo/hazi-feltetelek itt megtalálhatóak]
Házi feladat tanácsok pedig [https://www.inf.mit.bme.hu/edu/courses/remo/hazi-tanacsok itt találhatóak]

=== 1. Házi ===
Kezdeti modell (6. hét)
* Kiadott feladat/Önálló ötlet alapján egy üzleti folyamat specifikációja
* Folyamattal kapcsolatos minimális követelmények a weboldalon
* Erőforrások+elemzésszempontjai
* Elkészített folyamatmodell + erőforráshozzárendelés

=== 2. Házi ===
Végleges modell (13. hét)
* Analízisvégrehajtása
* Eredmények értékelése jegyzőkönyvben
* Szóbeli védés a 14. héten

=== Szorgalmi házi ===
Kétféle szorgalmi házi is létezik, [https://www.inf.mit.bme.hu/edu/courses/materials/rendszermodellezés/2012-ősz/szorgalmi-feladat-ki%C3%ADrás itt megtalálható a pontos leírása]

== ZH ==
Egy darab ZH van a kb. október végen. Elméleti kérdésekből, illetve két gyakorlati feladatból áll.

=== Elméleti kérdések ===
Pár mondatban megválaszolható kérdések, ha jól emlékszem 5-6 darab volt belőle. Ezekhez hasonlóak:
* Little törvény mit mond ki és mikor érvényes
* nyílt/zárt világ modell fogalma
* taxonómia/ontológia fogalma
* lineáris/exponenciális regresszió fogalma, példák
* benchmark, fajtái

=== Feladatok ===
Gyakorlaton megoldott példák szoktak szerepelni:
* Ontológia készítése. (1. gyakorlathoz hasonlóak)
* Diagramok felismerése, azok értelmezése. (2. gyakorlathoz hasonlóak)
* Teljesítménymodellezési számolós feladatok (3. gyakorlathoz hasonlóak)
* Kísérlettervezési számolós feladatok (4. gyakorlathoz hasonlóak)

== Vizsga ==
Őszi félévben decemberben két vizsga van és januárban is kettő. A decemberi első vizsga élővizsga, bárki mehet rá. (Elsősorban a záróvizsgások érdekében van így)
A vizsga elméleti kérdésekből, illetve három gyakorlati feladatból áll.

=== Elméleti kérdések ===
Pár mondatban megválaszolható kérdések, ha jól emlékszem 6-7 darab volt belőle. A ZH-n szereplő kérdések is elöfordulhatnak, illetve a ZH utáni anyagból is természetesen.

=== Feladatok ===
Gyakorlaton megoldott példák szoktak szerepelni:
* Ontológia készítése. (1. gyakorlathoz hasonlóak)
* Diagramok felismerése, azok értelmezése. (2. gyakorlathoz hasonlóak)
* Teljesítménymodellezési számolós feladatok (4. gyakorlathoz hasonlóak)
* Kísérlettervezési számolós feladatok (5. gyakorlathoz hasonlóak)
* Adatfolyamhálók rajzolása (5. gyakorlathoz hasonlóak)
* Szolgáltatásbiztonság számolós feladatok (6. gyakorlathoz hasonlóak)

== Hasznos linkek ==
* Meghibásodási adatok egyenesen a tanszéktől: https://wiki.inf.mit.bme.hu/twiki/pub/InfInf/RelModel/meghibasodasi_adatok.pdf

== Tippek ==

Előadásokra érdemes bemenni, de anélkül is megtanulható, csak nem érted meg annyira az anyagot csak a diákból. Gyakorlatokra nagyon érdemes bemenni, mert az ott megoldott példákhoz hasonló feladatok lesznek ZH-n és vizsgán. Házi kiadó órára mindenképp érdemes bemenni, ott mutatják be az IBM WebSphere szoftver használatát, illetve ott kapjuk meg a szoftver image-et.

== Kedvcsináló ==

Szerintem a legjobb/korrektebb/könnyebb tárgy a három elágazó közül. Ha informatikai technológiák szakirányon vagy, akkor pedig van is átfedés szakirányos tárggyal, így pláne nem nehéz. A zh-ra érdemes felkészülni mert 4-es zh-val szorgalmi feladatot lehet írni, a szorgalmi feladat pedig egyáltalán nem vészes, ellenben megajánlott ötöst ér.

--[[Szerkesztő:Ferrero|Szabó Csaba]] ([[Szerkesztővita:Ferrero|vita]]) 2013. január 3., 19:15 (CET)

{{Lábléc_-_Mérnök_informatikus_alapszak}}

Operációs rendszerek kidolgozott beugrókérdések vizsgára ABC-sorrendben

2015-06-10T11:14:42Z

Bolla Dávid: /* Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a felhasználókat és a csoportokat? */

==Bevezető==
Korábbi Wiki-n és InfoSite-on szereplő kidolgozott és kidolgozatlan anyagok, számtalan forrásból összeszedve - előadásdiákból, video.bme.hu-n lévő felvett anyagokból, Wikipédiás és egyéb, Google segítségével fellelhető anyagokból kiegészítve.
Hibák előfordulhatnak! TODO-val azokat a részeket jelöltem, amik átnézendők, rendbe szedendők, hiányosak, stb., ezeket is kérlek javítsátok, ha tudjátok! Köszi!
Ami fontos: ABC-sorrendbe rendezve szerepelnek a kérdések, így könnyebben megtalálható, tartsuk is meg ezt a tendenciát!
Remélem hasznát veszitek! -- [[PeteHaro|Pete]] - 2011.06.19.
Valamilyen szintű kategorizálást is beleraktam. A kérdések elejére odaírtam magának a kérdésnek a lényegét is, hogy könnyebben megtalálhatóak legyenek az azonos kérdéskörbe tartozóak.

==Beugrókérdések megoldással==
===Általános jellegű OS-ekkel kapcsolatos kérdések===

====Indulás: Hasonlítsa össze az általános célú (asztali) és a beágyazott operációs rendszereket az indulás szempontjából!====
<div class="answer">
A beágyazottnál először indul az alkalmazás, és az indítja az operációs rendszert, az asztalinál az operációs rendszer indítja az alkalmazásokat.
</div>

====Inkrementális mentés: Mit jelent az inkrementális mentés?====
<div class="answer">
Csak a változtatásokat mentjük az előző mentéshez képest -> kisebb helyet foglal, hamarabb végez a mentés.
</div>

====Kemény valós idejű rendszer: Adja meg a kemény valós idejű (hard real-time) rendszer definícióját!====
<div class="answer">
A rendszer adott eseményekre adott időn belül 1 valószínűséggel válaszol (egyébként hibás, hiába funkcionálisan jó a válasz). A rendszer NEM késhet!
</div>

====Lazán csatolt rendszer: Milyen szinkronizációs kényszereket jelent, ha egy lazán csatolt rendszer kommunikációja során véges kapacitású csatornát alkalmazunk?====
<div class="answer">
ha a küldő folyamat túl gyorsan küldözget, akkor a csatorna megtelik, úgyhogy túlcsordulás lesz, ami miatt a küldőnek várnia kell mielőtt újra küld.
</div>

====Rendszerhívások: Milyen előnnyel jár a rendszerhívások valamilyen magas szintű programnyelvvel történő megadása?====
<div class="answer">

Az API elrejti a rendszerhívások részleteit, bonyolultságát a programozó elől, lényegében egy wrapper réteggel fedi be a rendszerhívásokat.

</div>

====RPC: Milyen részekből áll az RPC technológia?====
<div class="answer">
* RPC: Remote Procedure Call, távoli eljáráshívás. Magas szintű folyamatok közti kommunikációt tesz lehetővé. Részei:
* a hívható eljárások és típusaik (interfész) leírása
* programgenerátor - rpcgen: a leírásból C programkódot generáló program
* kommunikációs infrastruktúra - portmapper: a programazonosítók és a hálózati portok összerendelése
</div>

====Statikus/dinamikus OS: Mikor nevezünk statikusnak, illetve dinamikusnak egy operációs rendszert?====
<div class="answer">
statikus: azok a rendszerek, amelyeknek muködése során - a felépülés és inicializálás kezdeti szakaszától eltekintve - nem jönnek létre és nem szűnnek meg folyamatok. dinamikus: működés közben bármikor születhetnek illetve megszünhetnek folyamatok.
</div>

====Szorosan csatolt rendszerek: Milyen rendszereket nevezünk "szorosan csatolt" rendszereknek?====
<div class="answer">
Ahol több CPU közös óra és közös memória segítségével működik együtt. Általában egyetlen operációs rendszer van, de az bonyolult. (Megjegyzés: az architektúrákból megtanult "közös erőforrást használnak" definícióra csak fél pontot adtak.)
</div>

===Erőforrás-hozzáférés===

====Elosztott rendszerek: Elosztott rendszerekben milyen konzisztencia kérdésekkel kell foglalkozni?====
<div class="answer">
* frissítés konzisztencia
* másolat konzisztencia
* cache konzisztencia
* hiba konzisztencia
* óra konzisztencia
* felhasználói interfész konzisztencia
</div>

====Erőforrás-gazdálkodás: Mi a különbség a hierarchikus és a globális erőforrás-gazdálkodás között?====
<div class="answer">
hierarchikus: a gyermek folyamatok csak a szülő erőforrásaiból részesülhetnek, és nem létezhetnek önállóan, csak amíg a szülőjük is létezik. globális: a rendszer valamennyi folyamata létrejötte után egyenrangú, önálló szereplő, és versenyezhet a teljes erőforráskészletből való részesedésért.
</div>

====Éhezés: Mi az az éhezés?====
<div class="answer">
A folyamatnak megvan mindene, ami a futásához kellene (ezért nem holtpont), de az erőforrásokat, amiket használni akar, más folyamatok kapják meg (ezért nem tud futni).
</div>

====Graceful degradation: Mit jelent a "graceful degradation" fogalma? ====
<div class="answer">
Fokozatos leromlás/összeomlás: Ha a rendszer terhelése eléri az ún. könyökkapacitást, akkor utána viselkedése megváltozik, a tovább növekvő terhelésre már egyre rosszabb működéssel reagál (overhead). Elvárható, hogy ezt fokozatosan tegye (ne omoljon össze).
</div>

====Kölcsönös kizárás====
<div class="answer">
Annak biztosítása, hogy a közös erőforrást egy időben csak annyi magában szekvenciális feladat használja, amely mellett a helyes működése garantálható.
A kölcsönös kizárást meg kell oldanunk a programban. Többnyire a használt erőforrást lock-oljuk (elzárjuk): nem engedjük hozzáférni a többi részfeladatot.
</div>

====Kritikus szakasz: Mit jelent a kritikus szakasz?====
<div class="answer">
A magában szekvenciális feladatok azon kódrészletei, amely során a kölcsönös kizárást egy bizonyos közös erőforrásra biztosítjuk. A kritikus szakasz a kérdéses közös erőforráshoz tartozik. A kritikus szakaszt a hozzá tartozó erőforrásra atomi műveletként (nem megszakítható módon) kell végrehajtanunk.
</div>

====Monitor: Mi a monitor alkalmazásának lényege? (Kölcsönös kizárás)====
<div class="answer">
A lockolás nem szétszórva történik a programban, hanem egyetlen, a közös erőforráshoz szorosan tartozó programrészletben.
</div>

====Prioritás öröklés: Mi a prioritás öröklés (Priority Inheritance, Pl) protokoll lényege? (prioritás inverzió témakör)====
<div class="answer">
Az alacsony prioritású feladat megörökli az általa kölcsönös kizárással feltartott feladat prioritását a kritikus szakaszából való kilépéséig. Csak részben oldja meg a prioritás inverzió problémáját.
</div>

====Test-and-set: Hogyan lehet Test_and_Set utasítással kritikus szakaszba lépést (entry) és kilépés (exit) megvalósítani?====
<div class="answer">
* Belépésnél csökkentjük a value értékét ezzel jelezve hogy használni akarjuk a kritikus szakaszt
* Kilépésnél növeljük a value értékét
Egy változót kijelölünk "lock object"-nek; ha ennek a tartalma 0, nincs senki a kritikus szakaszban. A kritikus szakasz elején egy ciklusban test-and-set-et hajtunk végre rá (az utasítást a ciklus feltételébe téve); ha valaki van a szakaszban már, a ciklusban fogunk keringeni, amíg ki nem lép belőle a másik. Amikor kilépett, a test-and-set következő végrehajtása beállítja a változót, és továbbengedi az egyik várakozó ciklust. A szakaszból kilépéskor pedig simán (nem test-and-set-tel) 0-ba állítjuk.
</div>

====Test-and-set: Hogyan működik a test_and_set?====
<div class="answer">
Visszaadja egy bit értékét, és ha 0 volt, 1-re állítja. Mindezt oszthatatlanul, vagyis ha 0 volt ott, és többen egyszerre hívtak rá test-and-set-et, akkor az egyiké teljesen lefut, 1-be állítja és nullát ad vissza, mielőtt a többi elkezdene futni (így ők mind 1-et fognak visszaadni)
</div>

====Újrahívhatóság: Mit jelent az újrahívhatóság (reentrancy) fogalma?====
<div class="answer">
A közös erőforrás problémájának egyfajta kiterjesztett esete egy függvényen/objektumon belül, mely akkor léphet fel, amennyiben ezt a függvényt/metódust egyszerre többen is meghívhatják. Előfordulhat akkor, ha ugyanazt a függvényt hívjuk egy taszkból és egy megszakítás-rutinból is, vagy ha preemptív ütemezés esetén ugyanazt a függvényt hívjuk két taszkból is.
</div>

===Holtpont===

====Definíció: Adja meg a holtpont definícióját!====
<div class="answer">
Egy rendszer folyamatainak egy H halmaza holtponton van, ha a H halmazba tartozó valamennyi folyamat olyan eseményre vár, amelyet csak egy másik, H halmazba tartozó folyamat tudna előidézni. Másként: A közös erőforrások hibás beállítása vagy használata miatt a rendszerben a részfeladatok egymásra várnak » nincs futásra kész folyamat; » nem jöhet létre belső esemény; » A rendszer nem tud előrelépni.
</div>

====Foglalva várakozás: Holtpont megelőzése (prevention) esetén milyen módszerrel lehet a foglalva várakozás előfordulását kizárni?====
<div class="answer">
* Az erőforrást birtokló feladat kér újabb erőforrást.
* Minden szükséges erőforrást egyben kell lefoglalni, egyetlen rendszerhívással.
* Alkalmazástól függ a használhatósága.
* Erőforrás-kihasználás romlik.
* A foglalva várakozás elkerülhető, ha minden folyamat betartja azt a szabályt, hogy az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el. A szabály betartásával megelőzhető a holtpont, de ára az erőforrás-kihasználás jelentős romlása.
* Ha a folyamatokat kötelezzük arra, hogy minden erőforrásukat egyszerre kérjék el. Ha meg akarjuk engedni a rákérést, akkor menthető állapotú erőforrások esetén megtehetjük, hogy a várakozó folyamatoktól elvesszük az erőforrásaikat.
</div>

====Kezelése: Az operációs rendszer milyen általános eljárásokat használhat a holtpont kezelésére?====
<div class="answer">
* strucc algoritmus (nem vesz róla tudomást)
* holtpont feloldása - melyik holtpontban érintett folyamatot számoljuk fel?
* menthető állapotú erőforrások elvétele,
* minél kevesebb folyamat felszámolása,
* folyamatok prioritása,
* már elvégzett munka,
* folyamatok visszaállíthatóságának biztosítása
* holtpont megelőzése
</div>

====Kialakulás szükséges feltételei: Sorolja fel a holtpont kialakulásának szükséges feltételeit!====
<div class="answer">
* Kölcsönös kizárás: Vannak olyan erőforrások a rendszerben, melyeket a folyamatok csak kizárólagosan használhatnak.
* Foglalva várakozás: legyen olyan folyamat mely lefoglalva tart erőforrásokat, miközben más erőforrásokra várakozik.
* Nincs erőszakos erőforrás-elvétel: a folyamatok addig birtokolják az erőforrást, míg saját jószántukból fel nem szabadítják azokat.
* Körkörös várakozás: Létezik a rendszerben egy olyan folyamatsorozat, melyben minden folyamat az utána következő folyamat által foglalt erőforrásra vár, a sorozat utolsó tagja pedig a sorozat első tagjára.
</div>

====Megelőzés, elkerülés: Mi a különbség a holtpont megelőzése (prevention) és holtpont elkerülése (avoidance) között?====
<div class="answer">
* megelőzése: olyan rendszert tervezünk, ahol nem teljesülnek a holtpont feltételei, így elvileg sem lehet holtpont.
* elkerülése (pl. bankár algoritmus): A rendszer minden erőforrásigény kielégítése előtt mérlegeli, hogy nem vezet-e holtpontveszélyre a kérés teljesítése, más szóval fennmarad-e a biztonságos állapot.

* ( Kölcsönös kizárás minimálisra csökkentése: lehetőleg többpéldányos erőforrásokat alkalmazunk, ahol ez nem lehetséges, ott a hozzáférést megpróbáljuk oszthatatlan műveletté tenni.
* Foglalva várakoztatás megszüntetése: Ha minden folyamat betartja a szabályt, miszerint az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el, akkor elkerülhető a foglalva várakoztatás. Ennek ára van: az erőforrás-kihasználtság romlása.
* Nincs erőszakos erőforrás-elvétel kiküszöbölése: Ha menthető állapotú erőforrásaink vannak, akkor megtehetjük, hogy elvesszük egy adott folyamat erőforrását és egy másiknak adjuk, majd annak lefutása után visszaadjuk a régi állapotában az erőforrást az első folyamatnak.
* Körkörös várakozás megakadályozása: A folyamatok megegyeznek az erőforrások sorszámozásában, minden folyamat csak nagyobb sorszámú erőforrást igényelhet azoknál az erőforrásoknál melyeket birtokol. Ekkor biztosan nem alakulhat ki kör.)
</div>

===Fájlrendszerek===

====Fájl: Mi a fájl az operációs rendszer szempontjából? (háttértár-kezelés)====
<div class="answer">
* a fájl a permanens táron az adattárolás logikai egysége, az operációs rendszer feladata a logikai egységek (fájlok) leképzése valódi fizikai egységekre, ez az OS-ben egy többszintü réteges rendszer
* Absztrakt adattípus (objektum, fájl mutató).
* Adat, név (name - elnev. konvenciók), típus (type - kezelés módja) tulajdonságok (attributes). Tulajdonosok, jogosultságok. Hozzáférési időpontok
* Kölcsönös kizárás (file locking)
* TODO
</div>

====Háttértáron lévő lapok: Milyen részidőkből áll össze a háttértáron levő lapokhoz való tényleges hozzáférési idő? Kis vagy nagy lapok használata esetén kapunk "jobb" byte hozzáférést?====
<div class="answer">
* adatátviteli sebesség + fejmozgás sebessége + lemezek forgási sebessége
* nagy lapok esetén ( mert így közvetlenül egymás után helyezkednek el az összetartőző adatok így nem kell a fejnek "ugrálnia" )
* Először a laptáblából kell kikeresni a lap bejegyzését, és konstatálni, hogy nincs hozzá fizikai lap rendelve. Majd, ki kell választani egy szabad fizikai lapot (ha nincs, ki kell vinni egyet háttértárra), a szabad helyre beolvasni a lapot, majd újraindítani a laphibát okozó utasítást. Ezek közül a háttértárról olvasás nagyságrendekkel lassabb a többinél, ezért lényegében ez határozza meg a teljes hozzáférési időt.
* Ha csak a háttértáron lévő lapokat nézzük, akkor, mivel kisebb lapot gyorsabban lehet beolvasni, ezért kisebb lapoknál gyorsabb a hozzáférés. Ha egy folyamat teljes munkahalmazát nézzük, akkor viszont a kisebb lapok több adminisztrációs költséggel járnak (gyakrabban kell háttértárhoz fordulni), és átlagban a nagyobb lapok adnak jobb eredményt.
</div>

====Indexelt tárolás: Sorolja fel az indexelt tárolás (indexed allocation) előnyeit és hátrányait! (Fájlrendszer-leképzés)====
<div class="answer">
* Szekvenciális és indexelt elérésre is alkalmas.
* Sérülékeny (az index blokkok sérülése a fájlt elérhetetlenné teszi).
* Az index blokkokat viszont könnyű többszörözni (replikálni).
* Sok fejmozgást okoz (seek), a blokkok el vannak szórva a diszken.
* Itt is lehet a láncolt listás töredezettség mentesítéshez hasonló algoritmusokat használni a fejmozgás minimalizálására.
</div>

====RAID: Sorolja fel a RAID technika leglényegesebb elemeit!====
<div class="answer">
* Használjunk több merevlemezt egyszerre.
* Több redundáns alkalmazása növeli a megbízhatóságot.
* Több párhuzamos használata növeli a sebességet.
* Hozzunk létre egy virtuális diszket a fizikai diszkekből.
* Redundant Array of Inexpensive Disks: több lemez összekapcsolása.
* A RAID-0 esetében két lemezre vannak szétosztva az adatok, így egyetlen fájlt kétszer akkora sebességgel lehet írni (a két felét parhuzamosan).
* A RAID-1 esetében ugyanazt az adatot tároljuk le a két lemezen, így gyorsabb nem lesz, de az egyik lemez hibája esetén visszanyerhetőek az adatok.
* Megjegyzés: ez csak példa, több lemezzel is lehet csinálni, a sebesség/tárhely/hibatűrés között különböző kompromisszumokat elérve.
</div>

====RAID0 vs. RAID1: Hasonlítsa össze két azonos diszkből álló RAID0 és RAID1 tömb tulajdonságait! Hogyan alakul a hozzáférési idő, az adatátviteli sebesség és a megbízhatóság egyetlen diszkhez képest a két esetben?====
<div class="answer">
RAID 0-1 szabványok általában SW implementációval és kevés (2db) diszkkel
* RAID 0 (striped disks):
** Több diszk párhuzamos használata;
** file részei N diszkre kerülnek;
** Az egyes részek egymástól függetlenül elérhetők
** A diszkek tárolókapacitása összeadódik
** N azonos diszk esetén a RAID 0 virtuális diszk olvasásai és írási adatátviteli sebessége maximum N-szeres közelébe nő.
** A hozzáférési idő közel eléri egy diszk hozzáférési idejét.
** Bármelyik diszk meghibásodása esetén az adat elveszik
* RAID 1 (mirroring):
** Több diszk redundáns használata.
** A file minden része minden (N) diszkre kikerül.
** Azonos diszkeket feltételezve a tárolóterület egy diszk tárolóterületével azonos.
** Az adatátviteli sebesség lassabb, mint egy diszk sebessége.
** A hozzáférési idő nő.
** Speciális esetben az olvasási sebesség N-szeresre nőhet, feltételezve a diszk meghibásodásának más módon történő észlelését (nem kell az azonosságot ellenőrizni többségi szavazással).
** Egy működőképes diszk esetén az adat elérhető.
</div>

====RAID5: Adja meg az M (M pozitív egész szám) diszket tartalmazó RAID5 tömb tulajdonságait! (hibatűrés és sebesség)====
<div class="answer">
* RAID 5 (block interleaved distributed parity).
* Több diszk redundáns és párhuzamos használata
* Adat és paritás elosztása N+1 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 1 diszk meghibásodása esetén az adat elérhető.
** 2 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error). A 2. meghibásodás észlelése a tömb újraépítése során)
</div>

====RAID5: Miért előnyös és miért hátrányos RAID5 használata?====
<div class="answer">
* + N azonos diszk esetén az olvasási és írási adatátviteli sebessége maximum N-szeres közelébe nő.
* + 1 diszk meghibásodása esetén az adat elérhető.
* - 2 vagy több diszk meghibásodása esetén az adat elveszik.
* - Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error).
* -Bonyolultabb, mint a Raid 0/1, ezért hardveresen valósítják meg, ami viszont drága
</div>

====RAID6: Adja meg a 8 darab 1 Tbyte-os HDD-ből álló RAID6 tömb tárolókapacitását!====
<div class="answer">
6 TB. (Adat és paritás elosztása N+2 diszkre. A kapacitása N diszk tároló kapacitásával egyenlő.)
</div>

====RAID6: N db azonos diszkből álló RAID6 tömb esetén a tömb tárolókapacitása és sebessége (nagy fájlok írása/olvasása során elérhető adatátviteli sebesség) hogyan viszonyul az egyetlen diszk azonos adataihoz?====
<div class="answer">
* RAID 6 (block interleaved dual distributed parity)
* Több diszk redundáns és párhuzamos használata.
* Adat és paritás elosztása N+2 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 2 diszk meghibásodása esetén az adat elérhető.
** 3 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nagyobb valószínűséggel állítható helyre a RAID 5-höz képest
* Minimum négy lemezre van szükség a RAID 6 működéséhez. The capacity of the array is (N-2) times the size of the smallest member disk for the array of N disks.
* Az olvasási sebesség (N-2)-szerese egy lemez olvasási sebességének - two disks in the row hold a parity which is useless to read. Such read speed values are roughly the same as in RAID 5.
</div>

====Tárolás egysége: Mi a logikai és mi a fizikai tárolás egysége a permanens táron?====
<div class="answer">
* logikai egység: fájl (file)
* fizikai egység: adatblokkok (cilinder, sáv és szektor együtt azonosítja az írható/olvasható adatblokkot; OS képzi le a logikaiakat fizikaiakra)
</div>

===Folyamatok, szálak===

====Bernstein feltétele: Mikor lehet két tevékenységet (utasítássorozatot) párhuzamosan végrehajtani (Bernstein)?====
<div class="answer">
Bernstein feltétele:
* Legyen <math> P_i </math> és <math> P_j </math> két darabja egy programnak.
* A <math> P_i </math> összes bemeneti változója <math> I_i </math>, és az összes kimeneti változója <math> O_i </math>, ugyanez <math> P_j </math> -re <math> I_j </math> és <math> O_j </math>.
* A két program párhuzamosan végrehajtható (vagyis független), ha: <math> I_j \bigcap O_i = 0 </math>, <math> I_i \bigcap O_j = 0 </math> és <math> O_i \bigcap O_j = 0 </math>
</div>

====Feladatok (task) együttműködése: Hasonlítsa össze a közös memórián illetve az üzenetváltáson alapuló folyamatok közti együttműködést!====
<div class="answer">
Közös memórián keresztül történő adatcsere esetén az együttműködő folyamatok mindegyike saját címtartományában lát egy közös memóriát. A közös memória elérését valamilyen adatátviteli rendszer teszi lehetővé. Üzenetváltásos adatcsere esetén a folyamatoknak nincs közös memóriája. Az adatátviteli rendszer most a logikai processzorokat kapcsolja össze. Rajta keresztül a folyamatok üzeneteket tudnak küldeni, illetve fogadni. Az üzenetküldésre a folyamatok logikai processzorainak utasításkészletében megfelelő utasítások állnak rendelkezésre. Ezek a Küld (Send) és a Fogad (Receive) műveletek.
</div>

====Folyamat: Definiálja a "folyamat" (process) fogalmát!====
<div class="answer">
* Egy program futás alatt álló példánya a folyamat.
* saját kód, adat, halom, verem
* A folyamatok nem férnek hozzá egymás lapjaihoz (védettek más folyamatoktól)

* végrehajtás alatt álló program (program maga a végrehajtható kód), amely folyamat virtuális címterébe van leképezve
* folyamat egy szála az, ami éppen fut egy CPU-n, és nem maga a folyamat
* minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát
* privát virtuális címtér (virtuális memóriacímek készlete, amiket a folyamat használhat)
* tartozik hozzá egy egyedi folyamatazonosító (process ID)
* rendszererőforrások listája, melyekhez a folyamat összes szála hozzáfér
* a folyamat virtuálisan összefüggő memóriát lát (virtuális memória) (valójában az összefüggő memóriaterület ritka)
* háttértárolóra is kiírható (swapping)
* A folyamat által látott logikai címtartomány, és a ténylegesen használt fizikai címtartományok teljesen elkülönülnek
* Folyamatok megoszthatnak memóriaterületeket olvasás- vagy akár írás- és olvasás-hozzáféréssel (Az ilyen memória területek több folyamat virtuális címtartományába vannak belapozva)
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 IPC (Inter-process communication) megoldást!====
<div class="answer">
* '''Jelzés''': rendszerüzenetek küldése és fogadása a folyamatok között, jellemzően utasítások továbbítása egyik folyamattól a másiknak
* '''Üzenetsor''': aszinkron kommunikációs forma, mely során a küldő és fogadó közvetlen interakciója nem szükséges, az üzenetek addig tárolódnak a sorban amíg a címzett fel nem dolgozza azokat vagy a sor meg nem telik
* '''Szemafor''': absztrakt struktúra amely a folyamatok közötti közös erőforrásokért való hozzáférést vezérli
* '''Közös memória''': ugyan az a memóriaterület kerül kiosztásra több különböző folyamatnak, írási és olvasási joggal egyaránt

''Forrás'': http://en.wikipedia.org/wiki/Inter-process_communication
</div>

====Folyamatok vs. szálak: Mi az eltérés a folyamatok illetve a szálak között, és milyen előnnyel jár a szálak alkalmazása?====
<div class="answer">
A szálak lényegében párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
</div>

====Java-szálak: Milyen módokon képezheti le a JAVA virtuális gép a JAVA natív szálakat a hoszt operációs rendszer folyamataira/szálaira?====
<div class="answer">
A JAVA virtuális gép egy folyamat a hoszt operációs rendszeren belül. A JAVA szálak feleltethetők meg a hoszt operációs rendszer szálainak, ez többnyire one-to-one (JAVA szál egyben OS szál is) napjainkban. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/20100507_ZH_megoldas.pdf)
Kovácsházy Tamás válasza:
7. fólia, 11. fólia:
JAVA (VM a folyamat, VM-en belül szál):
* Thread osztályból származtatva
* Runnable interface megvalósítása
* A JAVA platform-specifikusan valósítja meg a szálat:
* Natív OS specifikus szál (one-to-one, tipikus).
* JAVA specifikus szálak (many-to-one) egy natív OS szálra vagy folyamatra leképezve.
* many-to-many leképzés (erőforrás szempontok miatt, egyre ritkább).

</div>

====PRAM: Mi történik a PRAM modellben írás-írás ütközés esetén?====
<div class="answer">
Az írás-írás ütközésekor valamelyik művelet hatása érvényesül, a két beírni szándékozott érték valamelyike írja felül a rekesz tartalmát (versenyhelyzet), harmadik érték nem alakulhat ki.
</div>

====Processzor-affinitás: Mit állítunk be, ha egy szálnak beállítjuk a processzor affinitását, és miért lehet arra szükség?====
<div class="answer">
* processzoraffinitás: minden szál rendelkezik egy maszkkal, amely kijelöli, hogy a szál mely processzorokon képes futni
* szerepe: ez alapján dől el, hogy a szál mely processzoron fog futni
* ütemezésnél: multiprocesszoros esetben a processzor kiválasztása a processzor-affinitás alapján történik
* A feladat más processzorra, vagy processzormagra kerülése csökkenti a végrehajtás sebességét (pl. cache-elésnél) >> Cél: A feladatot ugyanazon a végrehajtó egységen tartani - Laza vagy kemény processzor affinitás (soft or hard processor affinity).
** Laza: Nincs garancia, de törekszik rá az OS (többnyire alapeset)
** Kemény: Biztosan ugyanazon a CPU-n marad (rendszerhívással)
</div>

====Szál: Definiálja a "szál" (thread) fogalmát!====
<div class="answer">
* párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk és saját vermük van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak, vagyis egymás adatait olvashatják és írhatják. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
* A folyamat egy szála az, ami éppen fut egy CPU-n (ami ütemezésre kerül), és nem maga a folyamat.
* Minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát (szál nélkül a folyamat programja nem futhat).
* szálak még véletlenül sem hivatkozhatnak más folyamatok címterére, hacsak a másik folyamat nem teszi elérhetővé privát virtuális címterének egy részét megosztott memóriaszakaszként (file mapping object a Windows API-ban), vagy - Windows-nál - hacsak egyik folyamatnak nincs joga megnyitni más folyamatot, hogy olyan folyamatok közti memóriafüggvényeket használjon, mint a ReadProcessMemory vagy WriteProcessMemory
* A szál önmagában szekvenciális kód, a végrehajtás legkisebb egysége. Egy adott folyamat szálainak közös az adat- és kódszegmensük, a halmuk (heap), és az egyéb erőforrásokat is közösen használják, de saját virtuális CPU-t látnak, és saját veremmel rendelkeznek.
* TODO
</div>

====Védelmi tartományok: Mi a különbség a statikus és a dinamikus védelmi tartományok között?====
<div class="answer">
Statikus védelmi tartományok esetén az egy folyamathoz tartozó védelmi tartomány a folyamat végrehajtása során nem változik, míg dinamikus védelmi tartományok esetén igen.
</div>

====Virtuális gép: Mi a virtuális gép koncepció lényege?====
<div class="answer">
* A programok elől az operációs rendszer elfedi a hardver implementációs részleteit, és kibővíti azt plusz funkciókkal.
* Az op.rendszer egy olyan réteget képez a hardver fölött, mely elrejti annak körülményességét és bonyolultságát a programozó elől és kibővíti a hardver szolgáltatását. A felhasználó így egy sokkal kellemesebb virtuális gépet (virtual machine, extended machine) lát.
* Az operációs rendszer egy kényelmesen kezelhető virtuális gépet jelenít meg a felhasználói és a programozói felületen.
</div>

===Jogosultságok===

====Belső biztonság: Mi a belső biztonság?====
<div class="answer">
Belső biztonság = védelem. Védelemnek nevezzük az eljárásoknak és módszereknek azon rendszerét, amely lehetőséget teremt a számítógép erőforrásainak programok, folyamatok illetve felhasználók által történő elérésének szabályozására.
</div>

====Engedélyezés: Definiálja az engedélyezés (authorization) fogalmát!====
<div class="answer">
* jogosultság ellenőrzése: milyen adatokat és szolgáltatásokat érhet el ez a személy?
* Hozzáférés-szabályozási listák (Access Control List, ACL)
* Alapelv: mindig csoportnak osztunk jogot
* Pl. biztonsági házirend, fájl ACL

TODO!!!
</div>

====Jogosultság + engedélyezési sémák: Mi a jogosultság fogalma, mi a kapcsolata az engedélyezési sémák többi alapfogalmával?====
<div class="answer">
* A jogosultság egy reláció a szereplők és védett objektumok között.
* engedélyezés ált. sémáinál: szereplő>>>szereplőt leíró adatszerkezet>>>biztonsági szabályzat (policy), JOGOSULTSÁG>>>védett objektumok TODO
* Jogosultságkezelés alapjai: A rendszer működése során
** A szereplők műveleteket kezdeményeznek
** A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját
** A jogosultsági döntő komponens kiértékeli kontextust és engedélyezi vagy megtiltja a műveletet
** A jogosultsági végrehajtó komponens biztosítja, hogy a döntő által hozott döntés érvényre jusson
* NT: SMR (Secure Reference Monitor) - objektumok elérési jogosultságainak ellenőrzése
* NT: Az LSA a SAM segítségével azonosítja a felhasználót és jogosultságait. Ha a felhasználó jogosult bejelentkezni, a logon elindítja a számára kijelölt shellt
* UNIX: hozzáférési jogosultságok (owner, group, others, read, write, execute)
* Engedélyezés általános sémái: >>Szerep alapú hozzáférés-vezérlés >>Hozzáférési jogosultság listák
* TODO
</div>

====Külső biztonság: Mit takar a külső biztonság fogalma?====
<div class="answer">
Annak mértéke, hogy mennyire lehetünk biztosak a számítógépes rendszer, illetve a rendszerben tárolt adatok sérthetetlenségében.
</div>

====Művelet kontextusa: Engedélyezési rendszerekben mit tartalmaz egy művelet kontextusa? (Felhasználó- és jogosultságkezelés)====
<div class="answer">
A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját.
</div>

===Hibakeresés===

====DTrace: Mi a Solaris DTrace megoldás célja?====
<div class="answer">
dinamikus hibakereső rendszer, nyomkövető eszköz, amivel a rendszer és a programok működését futási időben lehet megfigyelni.
</div>

===Memória===

====32 bit: 32 bites kliens Windows operációs rendszer maximum mennyi fizikai memóriát kezelhet, és miért?====
<div class="answer">
Legfeljebb 4 GB-ot (bár néha kevesebbet lát az OS, mert a memóriatartomány felső részére I/O eszközöket szoktak berakni, ld. pl. videókártya-memória...): ''"kliens Windowsok nem használják a gépben lévő PAE támogatást, mert az a tapasztalat, hogy a kliensekben lévő eszközök meghajtói nem kezelik le rendesen a 4 GB-nál több fizikai memóriát"''.
(https://wiki.sch.bme.hu/pub/Infoalap/OpRe/02-opre-windows-memoria.pptx)
(nem támogatják a PAE-t eleve, csak patch-csel)
(_"However, "client" versions of 32-bit Windows (Windows XP SP1 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility and licensing reasons, even though these versions do run in PAE mode if NX support is enabled."_ - http://en.wikipedia.org/wiki/Physical_Address_Extension)
</div>

====32 bit: 32 bites szerver Windows képes-e 4 GB-nál több fizikai memória kezelésére? Válaszát indokolja!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével (ezzel lehet 32 bites címbuszú CPU-val is 64 GB memóriát kezelni a maximális 4 GB helyett).
</div>

====32 bit: 32 bites Windows használata esetén egy felhasználói folyamat maximum mekkora virtuális címteret használhat?====
<div class="answer">
Alapból 2GB felhasználói módú címterületet használhat, ez a /3GB kapcsolóval 3 GB felhasználói címterületre bővíthető.
</div>

====32 bit: 32 bites Windows szerver operációs rendszerek képesek-e 4 GB-nál több fizikai memória kezelésére? Indokolja válaszát!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével.
</div>

====32 bit: 32 bites x86-os (Windows) esetén mekkora a felhasználói és a rendszer mód címtartomány mérete?====
<div class="answer">
Alapból 2GB felhasználói módú és 2GB kernel címterület van, ezt a /3GB kapcsolóval 3GB felhasználói és 1GB kernelre lehet módosítani.
</div>

====Bélády-anomália: Mit nevezünk Bélády-anomáliának?====
<div class="answer">
FIFO algoritmusnál egyes esetekben, ha a munkahalmaz méretét növeljük, a várakozásokkal ellentétben a laphibák száma is nő.
</div>

====Címfordítás: Hogyan történnek a címfordítások, ha az OS szegmens- és lapszervezést is használ a memóriánál?====
<div class="answer">
CPU --> Segmentation unit --> Paging unit --> Physical memory
</div>

====Címfordítás: Milyen címtranszformációk történnek együttes szegmens- és lapszervezésű memória használata során?====
<div class="answer">
* CPU >>>[Logical Address]>>> '''Segmentation Unit''' >>>[Linear Address]>>> '''Paging Unit''' >>>[Physical Address]>>> Physical Memory (http://portal.mit.bme.hu/?l=oktatas%2Ftargyak%2Fvimia219%2Fjegyzet%2F2011%2Fslides_17_memory.pdf)
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/oprewiki1.pdf, 48. oldaltól.
* Változó méretű szegmensek fix méretű lapokat tartalmaznak. Kicsi mind a belső, mind a külső tördelődés. A cím felépítése: (szegmens szám, lapszám, lapon belüli eltolás)
* Hasonlít a szegmensszervezéshez és a kétszintű lapszervezéshez: A memóriában szegmensek vannak ugyan, de ezek lapokból épülnek föl. Van szegmenstábla, és minden bejegyzéséhez tartozik egy laptábla is. Külső töredeződés nincs, belső töredeződés minimális (szegmensenként átlag fél lap); ez a kombinált módszer egyesíti a két módszer előnyeit
* TODO
</div>

====Lapszervezés, keret tábla: Lapszervezés esetén mit tartunk nyilván a keret táblában (frame table)?====
<div class="answer">
Az üres kereteket (frames).
</div>

====Logikai vs. fizikai memória: Mi a különbség a logikai és a fizikai memória között?====
<div class="answer">
A logikai memória a fizikai tár leképezve, ráadásul a leképezés a végrehajtás során változhat is.
</div>

====MMU: Mi a processzor Memory Management Unit (MMU) komponensének a feladata?====
<div class="answer">
* Speciális HW a CPU-ban
* Memória állapotának nyilvántartása
** Tulajdonos folyamat azonosítója
** Hozzáférési jogosultságok (ACL)
** cache-elhetőség, ha van cache (pl. DMA)
* Virtuális memória leképzése fizikai memóriára
** Pl. Translation Lookaside Buffer (TLB)
** Kontextusváltásnál ezt is kezelni kell (ha van)
** Pagefile vagy SWAP (HDD)
* Memóriavédelem
** Tiltott memória hozzáférés megakadályozása vagy legalább jelzése (ACL alapján)
** General Protection Fault (GPF) a Windows-ban
</div>

====Modified/dirty bit, referenced/used bit: Mi a modified/dirty bit és a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* laptáblában:
* Módosítás nyilvántartása (modified/dirty bit): minden memórialaphoz tartozik egy HW által kezelt bit (pl. a laptáblában) - betöltéskor törlik, módosításkor beállítják. Ha a dirty bit 1, akkor erre a lapra történt írási művelet, mióta a ﬁzikai memóriába került. Ezt a bitet a CPU tartja karban (automatikusan), ezzel az operációs rendszer munkáját segítve. 0 érték esetén a lapokat nem kell a diszkre kiírni, ha kiszorulnak a ﬁzikai memóriából (hiszen a tartalmuk a ﬁzikai memóriába helyezés óta változatlan, a diszk-en tárolt változat tehát továbbra is aktuális).

* Hivatkozások nyilvántartása (referenced/used bit): Ha a refernced bit 1, akkor volt "mostanában" hivatkozás erre a lapra. Ezt is a CPU tartja karban. Ez a bit segít az operációs rendszernek, amikor el kell döntenie, hogy melyik lapot dobja ki a ﬁzikai memóriából, ha egy új lapnak nincs helye. A referenced=0 lapokból fog válogatni.
</div>

====Page locking: Mit jelent és miért van szükség arra, hogy a virtuális tárkezelésnél egyes lapokat ideiglenesen a tárba lehessen "fagyasztani" (page locking)?====
<div class="answer">
* Azt jelenti, hogy a lapcsere algoritmus nem lapozhatja ki a háttértárra az adott lapot. Ok: periféria-művelet van az adott lappal kapcsolatban.
* Azt jelenti, hogy bizonyos lapokat a memóriában tartunk, mert I/O műveletek hivatkozhatnak rá, és ilyenkor a memóriában kell lenniük, mert az I/O műveletek fizikai memóriacímeket használnak.
</div>

====Referenced/used bit: Mi a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* Bizonyos algoritmusok igénylik a lapra történő hivatkozások figyelését is, ami ugyancsak hardvertámogatással hatékony. A laptáblában erre a célra is fenntarthatunk egy bitet. Ezt a hivatkozott bitet (referenced bit, used bit, R bit) a címképző hardver állítja be minden esetben, amikor az adott lapon belüli címre történik hivatkozás. A bitet az operációs rendszer törli adott időnként, vagy eseményhez (például laphiba) kötötten.
* Hivatkozások nyilvántartása (referenced/used bit): OS adott időnként és/vagy adott eseményekre törli - használat esetén beállítják.
</div>

====TLB: Mi az a Translation Lookaside Buffer, fizikai címcsatolásnál mi a szerepe?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.
</div>

====TLB: Mire szolgál a Translation Lookaside Buffer és mi a szerepe a fizikai cím kiszámításánál (virtuális címképzés)?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.

(Szerintem előbb a TLB-ben keresi, aztán ha ott nincs, csak utána nézi a laptáblát.)
</div>

====Tördelődés (külső vs. belső): Mi a különbség a külső és belső tördelődés között? (Memória foglalás)====
<div class="answer">
A tördelődött memóriaterületet külső tördelődés esetén az operációs rendszer szabadon hagyja, míg belső tördelődés esetén pedig odaadja egy olyan folyamatnak, aminek nincs igazából rá szüksége.
</div>

====Vergődés: Adja meg a vergődés (trashing) definícióját!====
<div class="answer">
A gyakori laphibák okozta teljesítménycsökkenést vergődésnek (thrashing) nevezzük. Az ellene való védekezés a munkahalmaz méretének jó megválasztása. Célszerű egy folyamatnak annyi lapot adni, amennyi szükséges az egyensúlyhoz, azaz ahány lapra hivatkozik a laphiba kiszolgálás ideje alatt (ugyanakkor nem sokkal többet, mert ekkor leromlik a multiprogramozás foka).
</div>

====Vergődés: Mi az a vergődés, és hogyan védekezzünk ellene?====
<div class="answer">
* Ha több memóriára lenne szüksége a folyamatoknak, mint amennyi rendelkezésre áll, ezért túl gyakran keletkezik laphiba, és a processzor idejének nagy része haszontalan lapcserékkel telik.
* Védekezni ellene például azzal lehet, ha a laphiba-gyakoriság függvényében az ütemező változtatja a multiprogramozás fokát: ha kevés a memória, folyamatokat függeszt fel, és swappel ki; ha van elég, akkor épp ellenkezőleg.
</div>

===uc/OS-II===

====Prioritás: A uC/OS-II-ben hány taszk tartózkodhat egy prioritási szinten és miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk.
</div>

====Prioritás: Egy prioritási szinten hány szál futtatását teszi lehetővé a uC/OS-II, miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk. Egy taszk = egy szál.

(Magyarázat: egy taszk = egy szál; lásd http://video.bme.hu/media/video/Operacios_Rendszerek_08ea_20110301.wmv, 01:09:18 környékén
Röviden: a beágyazott rendszerek, kis OS-ek esetén (uC/OS-II, FreeRTOS, stb.) lényegében csakis szálakban gondolkozunk. Nincs MMU, csak egyetlen összefüggő fizikai memória van, nincs virtuális memória koncepció, a processzoron futó teljes alkalmazás (az egyetlen alkalmazás) egy nagy folyamat - nincs más folyamat! Ezenbelül tudunk threadeket futtatni. Single Address Space.)
</div>

===Ütemezés===

====Átbocsátó képesség: Adja meg az átbocsátó képesség definícióját és mértékegységét!====
<div class="answer">
* (throughput) Mértékegység: munka/s, vagy 1/s
* Adott időegység alatt elvégzett feladatok száma. <math>\frac{\sum \textrm{elvegzett munkak}}{\textrm{ido}}</math>
* A rendszerfeladatokat nem számoljuk.
</div>

====Hosszú távú ütemezés: Adja meg a hosszú távú ütemezés célját!====
<div class="answer">
Tipikusan a BATCH rendszerekben van jelen, és uj jobok végrehajtasának megkezdéseről (új folyamatok indítasárol) dönt. Az elvégzesre váro munkák közül a választas szempontja, hogy a rendszerben a CPU-intenzív es I/O-intenzív folyamatok aránya optimális legyen (optimalis job-mix fenntartasa).
</div>

====Hosszú távú ütemezés: Definiálja a hosszú távú ütemezés fogalmát!====
<div class="answer">
A hosszútávú ütemező feladata az elindított feladatok rendszerbe, illetve a "futásra kész" várakozási sorba való beengedését szabályozni. Igyekszik a CPU-t és a perifériákat terhelő folyamatokat egyensúlyban tartani. Batch rendszerekre jellemző; a PC-k oprendszere általában azonnal indítja a folyamatokat, mikor azt a felhasználó kéri.
* feladata: A háttértáron várakozó feladatok közül kiválasztja azt, amelyiket el kell indítani.
</div>

====Konvoj hatás: Mi a konvoj hatás, és a tanult ütemező algoritmusok közül melyekben jelentkezhet?====
<div class="answer">
* igen nagy lehet az átlagos várakozási idő, mivel egy-egy hosszú CPU-löketű folyamat feltartja a mögötte várakozókat
* FCFS-nél (First-come, first-served) tapasztalható (pl. SJF (Shortest Job First) és RR algoritmus küszöböli ki)
</div>

====Középtávú ütemezés: Adja meg a középtávú ütemezés célját!====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.
</div>

====Középtávú ütemezés: Mi a középtávú ütemező feladata?====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.

Szerintem inkább ez:
A rendszerben lévő feladatok memóriájának egyes éppen nem használt részeinek kiírása háttértárra.
</div>

====Körülfordulási idő: Mi az a körülfordulási idő?====
<div class="answer">
* TAT (Turnaround Time) -> Egy feladatra vonatkozóan a rendszerbe helyezéstől a teljesítésig eltelt idő.
* Mértékegység: s,
* t_(CPU,végrehajtási idő)+t_várakozás (Magában foglalja a ténylegesen munkával töltött időt és a várakozást is.)
* felhasználó minél előbb szeretné látni a végeredményt
</div>

====Megszakítás: Az éppen futó taszkot megszakítja egy IT. Preemptív OS esetén mindig a megszakított taszk fogja-e visszakapni a futási jogot? Miért?====
<div class="answer">
* Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
* Másik: Nem, mert akitől elvették a futás jogát az futásra kész állapotba fog kerülni és az ütemező dönti el, hogy melyik folyamat fogja megint megkapni a futást.
</div>

====Megszakítás: Egy futó taszkra IT érkezik. Preemptív OS esetén az interrupt után mindenképpen 'ide' térünk vissza?====
<div class="answer">
Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
</div>

====Preemptív ütemező: Mikor nevezünk egy ütemezőt preemptívnek? ====
<div class="answer">
Ha az OS elveheti a futásjogot (a CPU-t) egy folyamattól/futó feladattól (interrupt).
</div>

====Rövid távú ütemezés: Mi a rövidtávú ütemezés, mikor jár környezetváltással?====
<div class="answer">
* Rövidtávú ütemezés: futó folyamat kiválasztása a futásra kész feladatok közül
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Rövid távú ütemezés: Mikor fut a rövidtávú ütemező és mikor jár környezetváltással?====
<div class="answer">
* Ütemezés következhet be, ha
** a futó folyamat befejeződik,
** egy folyamat felébred, futásra késszé válik,
** a futó folyamat várakozni kényszerül (valamilyen esemény bekövetkezésére), illetve,
** a futó folyamat önként lemond a futás jogáról vagy pedig elveszik tőle.
* Az első és a harmadik esetben az ütemezés mindig környezetváltással jár, hiszen a következő futó folyamat egészen biztosan nem a korábban futott lesz. A másik két esetben előfordulhat, hogy az ütemezőnek nem kell másik folyamatot kiválasztania.
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Terhelés-végrehajtó egységek közötti megosztás: Sorolja fel a terhelés-végrehajtó egységek közötti megosztásának megoldásait! (Többprocesszoros rendszerek)====
<div class="answer">
* Master and slaves (egy CPU osztja ki a feladatokat)
* Self-scheduling / peering (minden CPU ütemez)
* Globális futásra kész sor
* Processzoronkénti futásra kész sor
** Push alapú: OS kernel folyamat mozgatja a sorok között a feladatokat.
** Pull alapú: Az idle állapotban (idle feladatot végrehajtó) CPU próbál a többi sorából feladatot kapni.
* Kettő kombinációja
** Összefüggő, párhuzamosan futtatható feladatok optimalizálása (pl. Gang scheduler)
</div>

===Virtualizáció===

====Hardveres virtualizáció: Mit jelent az, ha egy x86-os processzor hardveres virtualizáció támogatással rendelkezik?====
<div class="answer">
A CPU utasításkészletének és üzemmódjainak olyan kiegészítése, amely lehetővé teszi a vendég operációs
rendszer kódjának módosítás nélküli futtatását. [?]

(Speciális utasításokkal látják el a processzort, amit szoftveresen akár több 100 utasításon keresztül lehetne csak megoldani. ROSSZ(MZ))

Elrejti a gep fizikai tulajdonsagait a felhasznalok elol.

Miert erdemes virtualizalni?

-Lehet futtatni a gazda OS el nem kompatibilis alkalmazast.

-Lehet biztonsaggal rendszergazda jogot adni mindennek, mert ugy se tud a gazda os-be kart tenni.

-Konnyen at lehet masolni a virtualis gepet egy masik gepre.
</div>

====Hosted vs. bare-metal: Miben különbözik egy hosted egy bare-metal típusú virtualizációs megoldástól?====
<div class="answer">
Bare-metal esetén a VMM kezeli a HW erőforrásokat, míg hosted típusú esetén ezt a host OS végzi.

videó:
http://video.bme.hu/media/video/Operacios_Rendszerek_20ea_20110418.wmv
00:16:45 körül

Kétféle megközelítés:

# Hosted: az operációs rendszerre telepítek egy virtualizációs szoftvert, ez beépül az operációs rendszerbe tipikusan kernel modulként, innentől a virtualizációs szoftver teszi lehetővé, hogy virtuális gépeket futtassak. Tipikusan a desktop megoldások (VMware Player, VirtualBox, Virtual PC, stb.)
# Bare-metal: a virtualizációs szoftver valós OS-szerű funkciókat valósít meg. Lényegében egy minimális funkciókészlettel rendelkező OS. A hardvert nem egy általános célú operációs rendszer kezeli, hanem a virtualizációs szoftver feladata az, hogy a hardver-erőforrásokkal gazdálkodjon, ő dönt az ütemezésről, ő dönt a memória-hozzáférésekről. Tipikusan szokott hozzá tartozni egy menedzsment operációs rendszer, egy menedzsment konzol, ami a távoli hozzáférést, virtuális gépek elindítását lehetővé teszi, és ott is ott tudom futtatni a vendég operációs rendszereket. Tipikusan szervermegoldások (VMware ESX Server, Xen Enterprise, MS Hyper-V).

Fontos különbség: ki dönt a CPU-erőforrásról?
# van az OS-nek egy ütemezője, ő dönt arról, mikor, ki kapja meg a CPU-t. Dönthet úgy, hogy az időszeletet az alkalmazás kapja meg, a köv. időszeletet a virtualizációs szoftver/modul, ő magán belül pedig eldöntheti, melyik virtuális gépnek osztja a processzort, de alapvetően a host OS dönt arról, mi dönt az erőforrásról.
# arról, hogy ki kapja a CPU-t, a közvetlenül a hardver réteg felett lévő virtualizációs szoftver dönti el. Dönthet úgy, hogy a menedzsment OS kapja, dönthet úgy, hogy valamelyik virtuális gép kapja meg.

</div>

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
<div class="answer">
Módosítjuk a vendég OS forráskódját, hogy ne is akarjon "problémás" utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. (Ezzel egyszerűsödik a hypervisor implementálása, viszont csak úgy működik a módszer, ha módosítják a vendég OS forrását.)
</div>

====Trap-and-emulate: Trap & emulate virtualizációs módszer használata esetén mi történik a vendég gép által kiadott nem privilegizált utasítással?====
<div class="answer">
* nem privilegizált utasítások közvetlenül a valós CPU-n hajtódnak végre (no VMM intervention)
</div>

===UNIX===

====Adminisztratív adatok: hol helyezzük el azokat az adminisztratív adatokat, amelyekre mindig szükség van, akkor is, ha a folyamatnak egyetlen lapja sincs a memóriában?====
<div class="answer">
A proc struktúrában.
</div>

====Adminisztratív adatok: UNIX-ban a folyamatokkal kapcsolatos adminisztratív adatok hogyan épülnek fel?====
<div class="answer">
TODO: rövidíteni.

# adatok, melyek elsősorban akkor szükségesek, amikor a folyamat ténylegesen fut - bent van egy v. több lapja a memóriában, éppen ezekkel kapcsolatos utasításokat hajtunk végre. >> az u-területen található kontextusadatok. A folyamat címtér része. A folyamat nem férhet hozzá, de a folyamat saját címterében találhatók. Amikor a folyamatnak egyetlen lapja sincs a memóriában, hanem minden a háttértáron található, a folyamat nem fut, akkor az itt található adatokhoz a kernel sem tud hozzáférni, mivel ide csak azok az adatok kerülnek, melyek a folyamat futásakor kellenek! Pl. hozzáférés-szabályozási adatok: a folyamat szeretne valamilyen tevékenységet végrehajtani, szabad-e neki vagy sem? Másik példa: rendszerhívások állapotai: végrehajt egy rendszerhívást, amiben éppen tartózkodik, ezzel kapcsolatos állapotadatok, stb. Vagy: nyitott fájl adatok, fájlkezeléssel kapcsolatos adatok. UNIX-ban a fájlkezelést nagyon általánosan kell érteni. Minden, ami a fájlrendszer-interfészen keresztül zajlik, ahhoz tartozik egy nyitott fájl objektum, ami ennek adminisztrálására szolgál, ezek is az u-területen találhatók. Ezenkívül: számlázási, statisztikai adatok.

# adatok, melyek elsősorban a folyamatok kezeléséhez szükségesek (amire a kernelnek bármikor szüksége lehet). Pl. folyamat alapvető azonosító adatai. Folyamat PID-je, szülőazonosító, stb. Folyamat ütemezésével kapcsolatos adatok, mi a folyamat aktuális futási állapota, mennyi a prioritása, prioritás kiszámolásához szükséges adatai, stb. Memóriakezelési adatok: folyamat memórialapjai bent vannak a memóriában, vagy épp kint vannak a háttértáron. Az u-terület címe, stb. >>> proc struktúra adatai: a process tábla egy eleme (ez a klasszikus rendszereknél ténylegesen egy tábla volt, ma bonyolultabb, pl. láncolt listás megvalósítás). A kernel címterének része. A kernel bármikor elérheti őket.
</div>

====Adminisztratív adatok: Milyen adatstruktúrá(k)ban és milyen címter(ek)ben található(k) a folyamatok adminisztratív adata(i)?====
<div class="answer">
A folyamat futása során szükséges adatok az u-területen, mely a folyamat címterének része, illetve a folyamatok kezeléséhez szükséges adatok a proc struktúrában, mely a kernel címtér része.
</div>

====Adminisztratív adatok: Sorolja fel a UNIX folyamatok legalább 4 alapvető adminisztratív adatát!====
<div class="answer">
* PID (Process ID): egyedi, a folyamatot azonosító szám (PPID: szülő folyamat azonosítója)
* A folyamat állapota (fut, alszik, stb.; ütemezési információk (prioritás, CPU használat, nice érték) )
* Hitelesítők (UID, GID: a kapcsolódó felhasználó adatai)
* Memória-kezelési adatok (címleképezési térkép)
* Kommunikációs adatok (fájlleírók, jelzés információk)
* Statisztikák (erőforrás használat (számlázáshoz) )
</div>

====Alvási prioritás: UNIX alvási prioritásának ütemezését mi végzi?====
<div class="answer">
Az alvási prioritást is az ütemező határozza meg, az alapján, hogy mire várakozik a folyamat, vagyis miért hajtott végre sleep() rendszerhívást. Kernel módban az ütemező nem veheti el a futási jogot, ezért amíg nem hajt végre sleep() hívást, addig nincs is szükség a prioritásának meghatározására.
</div>

====Android: Az Androidban mikor és miért (adjon jellegzetes példát) terminálható egy alkalmazás?====
<div class="answer">
Az alkalmazás erőforráshiány miatt bármikor terminálható, ezt az operációs rendszer automatikusan meg is teszi. Példa: ha nincs elég memória.
</div>

====Belső szerkezeti elemek: Sorolja fel a UNIX operációs rendszer főbb belső szerkezeti elemeit!====
<div class="answer">
* betöltő
* virtuálismemória-kezelő
* állományrendszer
* blokkos berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: lemezegység, szalagos meghajtó)
* karakteres berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: hálózat, nyomtató)
</div>

====Csővezeték (pipe): Írjon le egy olyan konkrét UNIX shell parancssort, amely csővezetéket alkalmaz!====
<div class="answer">
ls -la | more
</div>

====exec(): Mire szolgál a UNIX exec() rendszerhívás?====
<div class="answer">
exec(): új programkód betöltése egy folyamat címterébe
Azaz a fork() paranccsal létrehozunk egy új folyamatot, exec() paranccsal pedig betöltjük a folyamatba a kódot.
</div>

====Fájl-attribútumok: Sorolja fel a fontosabb UNIX fájl-attribútumokat!====
<div class="answer">
* Típus
* Linkek
* Eszköz, inode, méret...
* Időbélyegek
* Azonosítási és hozzáférés-szabályozási adatok
</div>

====Fájlrendszeri bejegyzések: Sorolja fel a UNIX fájlrendszeri bejegyzések alapvető tulajdonságait (legalább hármat, ls -l oszlopok)!====
<div class="answer">
* pl.: drwxr-xr-x 2 root root 4096 dec 22 12.27 txt
* sorrendben: I. UNIX-fájltípusok (pl. közönséges fájl (-), katalógus (d), szimbolikus link (l), stb.), II. hozzáférési jogosultságok (3*3-as bontásban - 1. hármas csoport a tulajdonos, a 2. a csoport, a 3. a többiek jogosultságait; 'r' az olvasás (read), a 'w' az írás (write), az 'x' pedig a végrehajtás (execute) jele), III. jogosultságok után egy szám áll (ez könyvtárak esetén azt mondja meg, hogy az adott könyvtár hány elemet tartalmaz, fájlok esetén azt tudhatjuk meg, hogy az adott fájlra hány hardlink mutat), IV. tulajdonos, V. méret (bájtokban), VI. utolsó módosítás dátuma, VII. fájl neve
</div>

====Felfüggesztett állapotok: Mik azok a felfüggesztett állapotok, mi a szerepük a UNIX-ban?====
<div class="answer">
felfüggesztve futásra kész, felfüggesztve alszik állapot A UNIX-ban egyfajta hosszú távú, felhasználói ütemezést jelentenek - a felhasználónak lehetősége van arra, hogy bizonyos folyamatokat a többi állapotból kiemeljen. Pl. Ctrl+Z billentyűkombinációval felfüggesztem a folyamatok futását. Innen valamikor visszahelyezzük futó állapotba.
</div>

====Felhasználói mód, kernel kontextus: UNIX esetén milyen tevékenység zajlik felhasználói módban, kernel kontextusban?====
<div class="answer">
Semmilyen!!
Megj.: Kernel kontextusban, felhasználói módban a program saját utasításait hajtjuk végre, a program saját adataival dolgozunk. Ennél fogva itt nincs értelme beszélni semmiről, mert a folyamat a kernel kontextusában nem hajthat végre semmit.
</div>

====Felhasználói módból kernel módba váltás: Hogyan vált egy UNIX folyamat felhasználói (user) módból kernel módba?====
<div class="answer">
Rendszerhívásokon keresztül.
</div>

====Felhasználói módú prioritás: Sorolja fel milyen tényezők határozzák meg egy UNIX folyamat felhasználói módú prioritását (tradicionális UNIX ütemező esetén)!====
<div class="answer">
* Korábbi CPU-használat
* Futásra kész folyamatok száma (p_cpu "öregítésével")
* nice érték (nice és renice parancsok)
</div>

====Folyamatok állapotai: Milyen állapotai vannak a UNIX-folyamatoknak?====
<div class="answer">
# kiinduló állapot
# futásra kész
# kernel módban futó állapot
# felhasználói módban futó állapot
# alvó állapot
# zombi állapot
# felfüggesztve alszik
# felfüggesztve futásra kész

Ctrl+Z-vel felfüggesztett állapotba helyezem a folyamatot.
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 UNIX folyamatok között kommunikációs megoldást!====
<div class="answer">
* System V IPC: szemafor, osztott memória, üzenetsor
* Csővezeték és nevesített csővezeték
* Jelzések
* RPC
* Folyamat-nyomkövetés
* Szemaforok
* Üzenetsorok
* Osztott memória
* Hálózati, socketeken keresztüli kommunikáció
</div>

====Folyamatok közötti kommunikáció: Soroljon fel UNIX folyamatok közötti adatátviteli eszközöket (legalább hármat)!====
<div class="answer">
* System V IPC: - szemaforok, - üzenetsorok, - osztott memória
* Jelzések: - aszinkron események keltése és kezelése
* Csővezetékek, nevesített csővezetékek: - FIFO kommunikáció a "rokonságban"
* Szemaforok: - a korábban megismert szinkronizációs megoldások
* Üzenetsorok: - diszkrét, típusos üzenetek folyamatok között
* Osztott memória: - azonos fizikai memóriaterület használata több folyamatban
* "hálózati" (socket) kommunikáció: - címzéssel és protokollokkal támogatott kommunikáció
* TODO
</div>

====fork(): Mire szolgál a fork() rendszerhívás?====
TODO: rövidíteni.

Új folyamat létrehozására. A fork() hívásakor az aktuális folyamat, amely kiadta a rendszerhívást, megduplázódik (minden adata, verme, memórialapja, stb.), onnantól két példányban fog továbbélni, amelyek egymással szinte tökéletesen megegyeznek, kvázi klónozva van a folyamat, néhány apró különbség van csupán. De valójában a memóriaszervezés ügyes trükkje: semmit nem csinál azonkívül, hogy bizonyos adminisztratív adatokat megdupláz, ténylegesen nem másol semmit (memórialapokat)! Az így megduplázott folyamat memórialapjaihoz hozzárendel még egy folyamatot, és megjegyzi azt, hogy amíg ezek a folyamatok békésen tudnak egymás mellett dolgozni, addig dolgozzanak ugyanazon, de ha konfliktus van, akkor majd lemásoljuk ezeket a memórialapokat.

Ha a fork() hívás 0-val tér vissza: a gyerek folyamat kódja fut tovább. Ha egy negatív számmal tér vissza, fork() hiba történt, nem tudtuk létrehozni az új folyamatot, le kell kezelni. Ha pozitív számot adott vissza, akkor az eredményben a gyerekfolyamat azonosítója található, itt a szülőfolyamat fut tovább.

Gyerek folyamat fut: az exec() az aktuális folyamat helyére betölt egy másik binárist. Az exec()-et meghívó folyamatnak az exec() kitörli a saját kontextusát, stb., betölt egy új programkódot, amit elkezd végrehajtani. (Kvázi mintha elindítana egy új folyamatot, de a folyamat már fut.) Ha nem sikerült betölteni a binárist (pl. nincs ilyen fájl), akkor hiba, visszatér az exec() is, egyébként nem: az új programkód utasításait hajtjuk végre.
Tehát folyamat létrehozása UNIX-ban két lépésben:
# fork() rendszerhívás = folyamatduplázás, majd
# a gyerekfolyamat helyére az új programkód betöltése exec() hívással.
Modern UNIX-okban fork() már nem igazán (más rendszerhívásokat használ).

====fork(): Miért van szükség a fork() rendszerhívásnál a folyamat megduplázására?====
<div class="answer">
TODO
</div>

====Futási/végrehajtási mód: Mi az a futási mód?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv, 00:17:00 környéke alapján
TODO - rövidíteni
A folyamatok a kerneltől teljesen különválasztva működnek (rendszerhívás interfészen keresztül kommunikálnak a kernellel). A végrehajtási mód azt határozza meg, hogy a kernel vagy a folyamat feladatait hajtja végre az OS.
Két mód: kernel ("privilegizált, védett") mód, valamint felhasználói ("szabad") mód.
Kernel módban a védett (kernel) tevékenységeket, felhasználói módban a folyamat programkódját hajtja végre az OS.
Példa: egy webböngésző a tevékenysége egy részében a saját feladatát hajtja végre, pl. HTML-kódot értelmez és jelenít meg, valamint vannak olyan tevékenységek, amelyek ahhoz kellenek, hogy ezt a feladatát végrehajtsa: hálózati kommunikáció, fájlrendszer-műveletek, stb. - ezek kernel tevékenységek.
Kernel módban privilegizált utasítások hajtódnak végre, pl. egy eszközt kezelünk, vagy hozzányúlunk a háttértárhoz, onnan valamit beolvasunk, oda valamit kiírunk. Ilyen utasításokat egy felhasználói módban futó folyamat nem hajthat végre, hiszen ha közvetlenül hozzáférne a hardverekhez, akkor akár adott esetben a teljes rendszer működését felboríthatná.
Felhasználói módból kernel módba átlépéskor átlépünk egy védett módba, így olyan feladatokat is végrehajthatunk, amit egyébként tilos.
</div>

====inode: Mi a UNIX inode?====
<div class="answer">
* A fizikai állományokhoz tartozó leíró, azonosító
* minden file-hoz tartozik egy inode állomány amiben a file minden tulajdonsága megtalálható (azonosító,leíró)
</div>

====Kernel mód, folyamat kontextus: Milyen tevékenység zajlik kernel módban, folyamat kontextusban?====
<div class="answer">
Kivételek, rendszerhívások kezelése, rendszerhívások végrehajtása.
Amikor a folyamat végrehajt egy rendszerhívást, a felhasználói módból átlép kernel módba, hiszen a rendszerhívás belsejében olyan tevékenységeket szeretne végrehajtani (beolvasni vmit egy fizikai eszközről, hálózatról, más folyamattal kommunikálni, elindítani másik folyamatot, stb.), amelyhez kernel utasítások végrehajtása tartozik.
</div>

====Kernel mód, kernel kontextus: Milyen tevékenység zajlik kernel módban, kernel kontextusban?====
<div class="answer">
Rendszerfeladatok, megszakítások kezelése. Kernelfolyamatok.
</div>

====Kernel módú prioritás: Mi határozza meg a UNIX folyamatok kernel módú prioritását a tradicionális UNIX ütemezésben?====
<div class="answer">
A kernel módban futó folyamat prioritása statikus, nem függ attól, hogy a folyamat mennyit használta a CPUt, vagyis mennyi ideig futott. A prioritás attól függ, hogy a folyamat milyen ok miatt hajtott végre sleep rendszerhívást, vagyis, hogy milyen eseményre várakozik. Emiatt a kernel prioritást szokták alvási prioritásnak is nevezni.
</div>

====Kernelszolgáltatások elérése: Milyen interfészen keresztül érhetők el a UNIX kernel szolgáltatásai?====
<div class="answer">
* System Call Interface
* Az alkalmazások a rendszerkönyvtárakat hívják meg, amelyek szükség szerint meghívják az operációs rendszer szolgáltatásait ??
</div>

====Kontextus: Mi az a kontextus?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv alapján.
TODO: rövidíteni.
Az a környezet, amiben végrehajtjuk az utasításokat. Ez is különbözik a kernelek és folyamatok esetén: folyamat kontextusban azokkal az adatokkal és utasításokkal dolgozunk, amelyek alapvetően a folyamat célját szolgálják, kernel (rendszer vagy megszakítás) kontextusban pedig kernel feladatokat hajtunk végre, és az ezekhez a feladatokhoz szükséges adatokkal dolgozunk.
Kernel kontextus: érkezik egy hardveres megszakítás, ennek kezelése itt zajlik.
Folyamat kontextus: a folyamattal kapcsolatban hajtunk végre tevékenységeket.
Nem uaz, mint a végrehajtási mód, mert lehetséges az, hogy bizonyos tevékenységeket kernel módban hajtunk végre, de folyamat kontextusban. Amikor hozzá kell férnünk egy folyamat futási adataihoz, veremhez, virtuális memóriájához, stb., a programnak az adminisztratív adatait kezeljük, ezek folyamat kontextusban találhatóak.
</div>

====Környezeti adatok: Mik azok a környezeti adatok egy UNIX-folyamatnál?====
<div class="answer">
A folyamat indításakor megörökölt tulajdonságok. Tulajdonság-érték párok. Pl. a felhasználó bejelentkezik; mi az ő neve. A felhasználó milyen terminált használ, annak milyen képességei vannak. Mi a felhasználó shellje. Az épp futó folyamat néhány tulajdonsága. Olyan tulajdonság, amely egyes folyamatok számára értéket jelentenek. A felhasználók ezeket a set, setenv, export parancsokkal tudják ezeket állítani (és le is kérdezhetik őket). Megörökli az őt elindító folyamat környezetét (hogy melyiket kell épp használni, UNIX-variánstól függ). Amikor a felhasználó bejelentkezik, akkor a környezeti változók beállítódnak, a folyamatok induláskor ezeket a beállításokat megöröklik.
</div>

====libc: A libc-nek mi a feladata rendszerhívások kezelésében?====
<div class="answer">
A felhasználói mód és kernel mód közötti átmenet lebonyolítása.
A folyamat csak meghív egy open(), read(), write(), stb. függvényt, valójában a háttérben bonyolultabb tevékenység zajlik >> meghív egy rendszerhívást a rendszerhívás interfészen keresztül. A rendszerkönyvtárak egyike a libc, a standard C library, ez felel azért, hogy az adott függvényhívásokat (mint a read()) leképezze arra a mechanizmusra, amin keresztül átlépünk kernel módba.
Az implementáció belsejében van egy SYSCALL utasítás (ez hardverfüggő), ez ténylegesen elvégzi az üzemmódváltást egy speciális megszakítás generálásával, aminek eredményeként a CPU átlép védett módba. A kernel pedig kezeli ezt a megszakítást. Ekkor a kernel a CPU regisztereit elmenti, azért, hogy a folyamat futása visszaállhasson a megfelelő állapotba. A feladat végeztével a kernel visszatér a megszakításból (erre is hardverfüggő a megvalósítás), a CPU visszavált felhasználói módba, a libc pedig visszatér a függvényhívásból, amit a folyamat kiadott.
</div>

====/proc: Mi a /proc?====
<div class="answer">
Speciális fájlrendszer-interfész a kernel-adatstruktúrákhoz való hozzáféréshez.
</div>

====Prioritás: Hogyan számítható ki egy kernel módban futó UNIX folyamat prioritása?====
<div class="answer">
* a prioritást a folyamat elalvásának oka határozza meg, tehát a prioritás attól függ, milyen sleep utasítással ment át alvó állapotba
* alvási prioritás pl: 20 - diszk I/O-ra vár; 28 - inputra vár a karakteres terminálról
* kernel módú folyamatoknak (amelyek rendszerhívásokat intéznek) negatív prioritásértékeik vannak, ezeknek van a legmagasabb prioritása ........... (http://home.mit.bme.hu/~meszaros/edu/oprendszerek/segedlet/unix/2_folyamatok_es_utemezes/unix_processes.pdf)
* Több szinten, több időléptékben zajlik. Óraütésenként a prioritási sorok ellenőrzése. 10 óraütésenként RR ütemezés egy soron belül. 100 óraütésenként a prioritások újraszámítása.
</div>

====Rendszerhívások: Igaz-e, hogy a rendszerhívások megszakítással járnak együtt?====
<div class="answer">
Igen, ennek hatására vált védelmi szintet a processzor.
</div>

====Rendszerhívások kontextusa: Milyen kontextusban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
folyamat kontextusban
</div>

====Rendszerhívások módja: Milyen módban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
kernel módban
</div>

====Rendszerhívások módja, kontextusa: Milyen futási módban és kontextusban zajlik a UNIX rendszerhívások kiszolgálása?====
<div class="answer">
Kernel módban fut a kód, és a rendszert hívó folyamat kontextusában. ((az ehhez tartozó ábra jobb felső része))
</div>

====Rendszerhívások programindításkor: UNIX alatt milyen rendszerhívásokra van szükség, ha a felhasználó elindít egy programot (folyamat létrehozása és programkód betöltése)?====
<div class="answer">
* Folyamatot létrehozni a fork() hívással, majd a programkódot betölteni az exec() hívással lehet.
</div>

====rpcgen: Mi az rpcgen program feladata?====
<div class="answer">
* RPC nyelven készült leírásból C programkódot generál. [?]

* Az RPC nyelv alkalmas a szerver interfészének formális leírására. A formális leírásból az rpcgen program képes a szerver és a kliens programok megfelelő részeit, valamint a szükséges XDR konverziós függvényeket elkészíteni C nyelven. Az így kapott C forráskódú modulokat a kliens és szerver alkalmazással kibővítve kapjuk a teljes kommunikáló rendszert.
* XDR (Extended Data Representation, kiterjesztett adatreprezentáció): Többféle egyszerű adattípust definiál, illetve szabályokat határoz meg bonyolultabb adatstruktúrák létrehozására. Az adatstruktúrák meghatározásán kívül az XDR egy formális nyelvet is bevezet az adatok leírására. Az RPC rendszer is ezen nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
* RPC (remote procedure call, távoli eljáráshívás): Az RPC-rendszer egy protokoll-leírást és egy programozói interfészt tartalmaz. Az XDR által definiált formális nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
</div>

====System V IPC: Sorolja fel a UNIX System V IPC elemek közös alapjának részeit!====
<div class="answer">
Minden IPC erőforrás rendelkezik a következő azonosítókkal: kulcs (key), létrehozó (creator), tulajdonos (owner), hozzáférési jogok (permissions)
</div>
====System V: Adja meg a System V üzenetsorok főbb jellemzőit (tömör felsorolást kérünk)!====
<div class="answer">
* diszkrét, tipizált üzenetek
* nincs címzés, üzenetszórás
</div>

====System V: Miért tud az s5fs (System V File System) gyorsabban írni, mint olvasni (az előadás példája alapján)?====
<div class="answer">
* az írás gyors, főleg kis fájlok esetén (több szintű leképzés a kisebb blokkkok miatt), az olvasás azért lassabb (csak a nagy fájlokra), mert azoknak a részeit össze kell vadászni a szétszórtság miatt
* TODO
</div>

====u-terület: milyen jellegű adminisztratív adatok vannak az u-területen?====
<div class="answer">
Azok az adatok, melyek a folyamatok futásakor kellenek. Több infó: lásd adminisztratív adatoknál.
</div>

====UNIX-fajták: Soroljon fel fő UNIX-fajtákat!====
<div class="answer">
Linux, Solaris, BSD, System V, HP/UX, ...
</div>

====UNIX-szabványok: Soroljon fel UNIX-hoz köthető szabványokat (legalább kettőt)!====
<div class="answer">
* POSIX.1 (teljes nevén: POSIX1003.1): C nyelvű szabványos rendszerhívás-interfész
* System V Interface Definition
* X/Open Portability Guide
* - AT&T SVID (pl. SVR4), - IEEE POSIX, - Open Group X/Open, Unix95, Unix98, ... ????
* http://linux.die.net/man/7/standards
</div>

====UNIX-típusok: Soroljon fel UNIX típusokat (a családfa jellemző ágait)!====
<div class="answer">
* System V (AT&T változat; Solaris, SCO),
* BSD (Berkeley változat; SunOS, OpenBSD)
</div>

====Ütemezés: Adja meg a tradicionális UNIX ütemező három legjellemzőbb tulajdonságát!====
<div class="answer">
* preemptív, prioritásos és időosztásos
(Néhány kiegészítés a UNIX-ütemezőhöz:
* nem preemptív kernel módban (a kernel módot végrehajtó folyamatot (pl. rendszerhívás, megszakítás-kezelés) nem lehet kényszeríteni, hogy a CPU használatáról lemondjon egy nagyobb prioritású folyamat javára)
* újraütemezés csak akkor következik be, ha egy folyamat önként lemond a CPU-ról és sleep rendszerhívást hajt végre, vagy a folyamat kernel módból visszatér user módba Nem méretezhető megfelelően. Az algoritmus nem képes rugalmasan alkalmazkodni a folyamatok számának növekedése esetén. A korrekciós faktor nem elég hatékony eszköz.
* A CPU-t adott esetben nem lehet "kiosztani" adott folyamat számára. Nem garantálható fix válaszidő. Nagy rendszerterhelés esetén a válaszidő megnőhet. A UNIX ütemezés épp ezért nem alkalmazható real-time rendszerekben.
* A kernel nem preemptív, ezért az egész rendszert feltarthatja. A felhasználó nem tudja megfelelő módon befolyásolni folyamatai prioritását - a nice szám nem megfelelő eszköz erre a célra.)

</div>

====vfs: Mondjon legalább egy, UNIX VFS-alapú "fájlrendszert", amelynek a célja nem fájlok tárolása!====
<div class="answer">
/dev, /proc, stb.
</div>

====vfs: Soroljon fel UNIX VFS-alapú fájlrendszereket (legalább négyet)!====
<div class="answer">
xfs, zfs, brtfs, nfs
</div>

====Virtuális rendszerhívás: Mi az a virtuális rendszerhívás, miért van rá szükség?====
<div class="answer">
(Klasszikus UNIX-ban nincs, Linux 2.5.x-től felfelé, mai Linux kernelek aktívan használják.)
Vannak bizonyos egyszerű feladatok, amelyek a feladat egyszerűsége ellenére túl sok felesleges művelettel járnak: rendszerhívás intterrupt, kontextusváltás, stb., ezen a helyzeten szeretnénk javítani - próbáljuk lerövidíteni ezt az utat.
Pl. a pontos idő lekérdezése csupán egy megfelelő hardver kiolvasása (egyszerű numerikus érték), mégis sok művelettel jár: gettimeofday(): libc > SYSCALL > kontextusváltás > ..., majd ugyanezen a lépcsőn visszasétálunk a felhasználói folyamatba.
Persze nem mindig lehet leegyszerűsíteni ezt az utat, csak egyszerűbb és biztonságos esetekben, pl. ha egyszerű numerikus értékek, azonosítók kiolvasásáról van szó: pl. folyamatnak mi az azonosítója, processzor lekérdezése, pontos idő lekérdezése...Tehát a felhasználói módból kernel módba történő hosszas váltást szeretnénk elkerülni. Ha nincs ilyen módváltás, akkor a felhasználói címtérben elérünk egyes kernelterületeket > így tényleg egyszerű függvényhívás lesz. Megfelelő előfeltételekkel: csak kockázatmentes feladatokra. Időlekérdezés tipikusan ilyen, ott megtehetjük.A felhasználói címtérben az a tevékenység, amelyet szeretnénk végrehajtani, elérhető legyen. Ezt oldják meg a virtuális rendszerhívások!
A folyamat címterébe a kernel rendszerinduláskor speciális "kernellapot" allokál - ezen a biztonságosnak tekinthető rendszerhívások vannak. Terminálból példa: ldd /bin/bash
</div>

====vnode/vfs: Mi a UNIX vnode/vfs?====
<div class="answer">
* Implementáció-független fájlrendszer absztrakció
* vnode: virtuális csomópont, vfs: virtuális állományrendszer
* inode --> vnode
* fs --> vfs
* Új absztrakció: annak felismerése, hogy több állományrendszernek számos előnye van, szükségessé vette a virtuális csomópont (vnode) és a virtuális állományrendszer (vfs) leíró adatszerkezetek bevezetését. Követelmények, elvárások az állományrendszerrel kapcsolatban:
** egyszerre támogasson több - UNIX, nem UNIX - állományrendszert
** különböző diszk partíciók különböző állományrendszereket is tartalmazhatnak, de mountolás esetén egységet képet kell, hogy mutassanak
** támogassa a hálózati állományok osztott használatát
** modulárisan bővíthető legyen.
</div>

====Zombi állapot: Mi a zombi állapot szerepe egy UNIX rendszerben?====
<div class="answer">
A folyamat már felszabadította a foglalt memóriát, lezárta az állományokat, minden erőforrását visszaadta a rendszernek, csak a proc struktúráját tartja fogva, amiben visszatérési és statisztikai információt tárol a szülő számára. A folyamat szülő wait hívása után szűnik meg.

Megjegyzés: bővebben magyarázattal, előadás alapján:
A folyamat megáll, a UNIX-ban a kernel szeretné ezt a szülőjének is tudomására hozni.
A folyamat már leállt, nem fog tovább futni, de a szülőjét még nem értesítették arról, hogy ez a folyamat megszűnt, esetleg gondoskodjon az újraindításáról, stb.
Pl. egy webszerver: beérkező kérések kiszolgálása --> kliens folyamat indítása, ez megkapja a kérés kiszolgálásának feladatát, a kliens pedig valamikor megáll, a webszerver nem árt, ha értesül róla, hogy hiba vagy normál működés folytán állt le.
Tehát amíg a szülő nem értesült a leállásról, a folyamat zombi állapotban marad. Ha a szülőt nem érdekli, mi történt a gyerekfolyamattal, a zombi állapot hamar megszűnik.
A zombi állapotban a folyamatnak semmilyen saját adatát nem tároljuk, a folyamat összes működéshez szükséges adata megszűnik, kizárólag a kernel adatstruktúrákban, tehát a proc struktúrában marad meg a folyamatnak néhány adminisztratív adata. A ps kilistázhat pl. zombi állapotban lévő feladatokat, mert ezeknet a folyamatoknak az adminisztratív adatai a kernel címterében még megtalálhatóak. De a folyamatok saját címtere, u-terület, stb. már nem létezik. Miután a szülő értesült róla, hogy a gyerekfolyamat meghalt, a kernel törölni fogja a folyamatot a process táblából is, a folyamat kilép a zombi állapotból.
</div>

====Zombi állapot: Igaz-e az, hogy egy zombi állapotban lévő folyamat még memóriaterületet foglal?====
<div class="answer">
Igen, mert a kernel processz táblában még ott vannak az adatai, és az memóriaterületet foglal. (A NEM választ is meg lehet indokolni...) [Indoklás nélkül 0 pont!!!]
</div>

===Windows===

====Alrendszer: Melyik az az alrendszere a Windowsnak, ami nélkül nem tud futni?====
<div class="answer">
A Windows alrendszer, avagy Client/Server Runtime [[SubSystem]] (csrss.exe). Ennek kilövése kékhalált eredményez.
</div>

====API-k: Hogyan oldották meg, hogy az alkalmazások többféle API-n (Win32, POSIX) keresztül is meg tudják hívni a Windows operációs rendszer funkcióit?====
<div class="answer">
* Megoldás: környezeti alrendszerek (environment subsystems): a felhasználónak vagy programozónak nyújtott környezet, személyiség egy részét a környezeti alrendszer folyamatok valósítják meg, minden egyes környezet külön API-t mutat (Windows, POSIX, ...), az operációs rendszer rendszerhívásainak egy részét kínálja a felhasználói alkalmazások számára. (Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx)
* a kernelnek egy definiált interfésze van, ami nem publikus (hivatalos dokumentációja nincsen): NT API >> az ebben lévő függvényeket a fejlesztő ne hívhassa meg közvetlenül. Ehelyett erre két alrendszer épül, ők mutatnak egy API-t az alkalmazások felé: Windows API és POSIX API. (ezek teljesen dokumentáltak!). Az alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni.
* A két alrendszer feladata az, hogy az általuk definiált hívásokat átfordítsák.
* Nem pusztán szintaktikai, hanem szemantikai eltérések is vannak.

(Megjegyzés: Exetype segédeszköz segítségével megnézhető, melyik alrendszert használja egy adott alkalmazás.)

Forrás: http://video.bme.hu/media/video/Operacios_Rendszerek_04ea_20110215.wmv (00:28:29 körül)

(Korábbi:
* Alkalmazás 1>>>Windows API (Windows alrendszer)>>>NT API (NT Kernel)<<<Posix API (Posix alrendszer)<<<Alkalmazás 2 TODO(ehelyett 1 épkézláb mondat kéne)
* alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni
)

</div>

====Executive réteg: Executive (Windows)====
<div class="answer">
Az operációs rendszer magasabb szintű funkcióit szolgáltató rétege (memóriakezelés, biztonság, stb.). Az adatokat objektumokban tárolja, melyeket leírókkal (handle) lehet csak elérni, jól definiált interfészeken keresztül. Bár a kernel funkcióit csak a kernel interfészén keresztül éri el, szintén az ntoskrnl.exe tartalmazza. A legtöbb rendszerhívás itt van megvalósítva.
Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx

(Korábbi: Ez a réteg tartalmazza az NTDLL.DLL által definiált függvények hívásainak megvalósítását, valamint a rendszer külső objektumai közti kommunikáció. Legfontosabb szolgáltató funkciója a lokális eljárás hívás - LPC (Local Procedure Call) megvalósítása. TODO[MZ])
</div>

====Fájlhozzáférések: Mivel azonosítja a Windows a felhasználókat és csoportokat a fájlhozzáférési listákban?====
<div class="answer">
* objektum (SecurableObject) → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* SecurityDescriptor (biztonsági leíró, összefogja a többi elemet) >> Owner (Tulajdonos, megváltoztathatja az objektum engedélyeit, akkor is ha nincs explicit joga), Discretionary Access Control List (DACL, belátás szerinti, erőforrás szintű, hozzáférési lista - hozzáférés szabályozása), SACL (biztonsági naplózás szabályozása - kinek milyen művelete esetén kell naplózni az adott műveletet)
* AccessControlEntry:
** Típus: megengedő, tiltó, audit
** Flag: Pl. öröklődés
** SID: kire vonatkozik
** Maszk: végrehajtás | törlés tulajdonos írása...
* elérési lista (ACL), melyben megadható, hogy mely folyamatok jogosultak az adott section object elérésére ???
* minden objektumhoz tároljuk a hozzá tartozó <tartomány, műveletvégzési jog> párokat ????
* TODO - bőven elég annyi, hogy Security Identifier (SID) segítségével azonosítja
</div>

====Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a felhasználókat és a csoportokat?====
<div class="answer">
SID - Security Identifier
</div>

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
<div class="answer">
Paravirtualizáció esetén fel kell készíteni a vendég OS-t a forráskódjának módosításával, hogy ne is akarjon problémás utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. Ezzel egyszerűsödik a hypervisor implementálása.
</div>

====Felhasználó- és csoportazonosító: Mivel azonosítja a Windows a felhasználókat és csoportokat a hozzáférések ellenőrzése során?====
<div class="answer">
* <Gép SID>-<RID> (SID security identifier - gépspecifikus, RID: relative identifier)
* Jól ismert SID-ek: Everyone: S-1-1-0, Administrator: S-1-5-domain-500
* Vista: szolgáltatások is kapnak SID-et
* objektum → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* TODO
</div>

====HAL: Mi a HAL (Windows)?====
<div class="answer">
* "HAL" - Hardware Abstraction Layer
* A felsőbb rétegek a HAL-on keresztül érik el az alap HW szolgáltatásokat, a HAL szerepe, hogy elfedje a HW megvalósítás részleteit, és egy egységes, platformfüggetlen felületet biztosítson.
* hal.dll fájlban megvalósítva (pl. timer interrupt kezelését, alaplap alapvető felépítését (milyen chipsetek vannak rajta), stb. elfedi a felette lévő rétegektől)
</div>

====Hardverfüggő részek: Melyek a Windows hardverfüggő részei?====
<div class="answer">
* A kernel egyes részei és a HAL.
* Megjegyzés: én ide a drivereket is beírtam, nem vontak le érte pontot, de azt mondták, azokat nem mindig szokás a rendszer részének tekinteni.
</div>

====Jogosultságok szerepe: Mik a jogosultságok (privilege) szerepe a Windows-ban?====
<div class="answer">
* operációs rendszer szintű jog
* meghatározzák azokat a rendszerműveleteket, amelyeket egy felhasználói azonosító elvégezhet. Egy rendszergazda jogosultságokat felhasználóknak és csoportazonosítóknak oszt (http://msdn.microsoft.com/en-us/library/bb530716(VS.85).aspx)
* pl. számítógép leállítása, eszközmeghajtó betöltése
* név: SeShutDownPrivilege, SeLoadDriverPrivilege
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens/Képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerülése: Mi a fő oka, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerültek? Elméleti megfontolások alapján hol lenne a helyük?====
<div class="answer">
Windows NT 4.0-ban került le kernel szintre ez a komponens, hogy kevesebb folyamat- és módváltás legyen (Ne kelljen mindig visszaváltani a csrss.exe-be, majd onnan átváltani kernel módba, utasítani a hardvert, visszaváltani felhasználói módba, majd visszaváltani a felhasználói folyamatba, aki kezdeményezte a változtatást.) (A felhasználói módú folyamatban (csrss.exe) csak a konzol kezelés maradt.) Elméletileg felhasználói szinten kéne lennie.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Windows-ban miért került le az ablakkezelő kernel módba?====
<div class="answer">
Hogy kevesebb kontextus- és módváltás legyen, mivel a Windows szerves része az ablakkezelés, ezért rengeteg user-kernel mód váltás lenne ha a csrss.exe-en keresztül használnánk. Tehát teljesítménybeli okokból.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens előnyei: A Windows OS grafikus komponensének mik az előnyei, hátrányai?====
<div class="answer">
A grafikus komponens kernel módban fut. Emiatt a hibái az egész rendszert magával ránthatják, viszont gyorsabb, mert kevesebb CPU-mód váltás kell a rajzoláshoz.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Mi volt a fő oka annak, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító komponens kernel módba került?====
<div class="answer">
Mert ezek a folyamatok intenzíven használják a hardvert, és futásuk gyorsaságára az egész rendszer teljesítménye érzékeny. A user módban történő megvalósítás a rendszert lelassítaná a gyakori környezetváltás miatt.
</div>

====Kernel: Mi a kernel (Windows)?====
<div class="answer">
A rendszer állandóan memóriában lévő, védett módban futó része. Az NT egyetlen HW függő része, szerepe a HW elfedése a felette található eszközök elől, ezáltal a felette lévő részek már teljesen HW függetlenek. Megvalósítja a szálütemezést, multiprocesszor ütemezést és a TRAP kezelést.
</div>

====Kliens-szerver-modell: Nevezzen meg egy kliens-szerver-modell alapján működő komponenst az NT-ben!====
<div class="answer">
* csrss.exe - Client/Server Run-Time Subsystems (környezeti alrendszerek)
* TODO
</div>

====Memóriafoglalás: Mely utasításokkal és miért történik a memóriafoglalás két lépésben Windows alatt?====
<div class="answer">
* A két lépés: Reserve és Commit. Az első csak címtartományt foglal, amögött nem lesz ténylegesen használható memóriaterület; a másik a már lefoglalt címtartományhoz rendel (virtuális) memóriát.
* A folyamatok címtartományának töredezettsége csökkenthető azzal, ha a címtartományt már akkor előre foglalja, mikor a memóriára még nincs szüksége, és ez nem jár olyan memóriapocsékolással, mintha fizikai memóriát is foglalna ugyanakkor.
</div>

====Munkakészlet (working set): Mit jelent a Windows-ban az egy folyamathoz tartozó munkakészlet (working set) fogalma?====
<div class="answer">
Azon fizikai lapok halmaza, amelyekre a folyamat laphiba nélkül hivatkozhat.
</div>

====NT hardverfüggő rétegei: Sorolja fel az NT hardverfüggő rétegeit!====
<div class="answer">
HAL (Hardware Abstraction Level), kernel
</div>

====NTDLL.DLL: Mi az NTDLL.DLL fő funkciója?====
<div class="answer">
Összeköti a User és Kernel módot. Az Executive függvényeknek megfelelő függvénycsonkok vannak benne.
</div>

====Quantum: Mi a szerepe a quantumnak a Windows ütemezőjében?====
<div class="answer">
* A szálak adott ideig futnak (quantum)
* RR ütemezésnél az időszelet
* Óramegszakításban mérik (clock interval, clock tick) 1 clock tick = ~ 10-15 ms (HALtól függ)
* Quantum hossza: időegység, amíg egy szál fut
* Kliensek esetén a quantum hossza 2 clock tick a háttérben futó folyamatoknak, az előtérben futó folyamatoknak 6 clock tick jut. Így egy CPU-intenzív folyamatról való ablakváltáskor az új, előtérben lévő folyamat arányosan több CPU-időt kap (azonos prioritásokat feltételezve).
* Szervereknél: mindenkinek 12 clock tick a kontextusváltások minimalizálása érdekében. Szervereknél így a kliensek kéréseinek eredményeként felébredő alkalmazásoknak több esélye van befejezni a kérést, és várakozó állapotba kerülni, mielőtt az időszelet véget érne.
* esély annak a folyamatnak, amelynek épp most ért véget a várakozása: a várakozás végén megnöveljük a prioritást, de a quantum eggyel csökken; a quantum végén a prioritást az eredetire csökkenti.
* éhezés elkerülése: az OS másodpercenként megnézni a futásra kész szálakat, és annak, aki nem futott már 300 óraütés óta, 15-ös prioritást ad, megnöveli a quantumját egy quantumnyi futásig
* TODO, hogy a forrás feldolgozása jó-e: http://mit.bme.hu/~micskeiz/opre/files/01-opre-windows-utemezes.pptx

</div>

====Rendszeridő megváltoztatása: A rendszeridő megváltoztatására kinek van joga Windows alatt?====
<div class="answer">
* SeSystemTimePrivilege joggal rendelkező felhasználóknak / azoknak a felhasználóknak, amelyek olyan csoportba tartoznak, amelyekhez hozzá van rendelve a SeSystemtimePrivilege.
* Alapértelmezett beállításként csak az Administrators és Power Users group rendelkezik vele.
* http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx
</div>

====Standby memórialapok listája: Mire szolgál a standby memória lap lista a Windows-ban (miért nem szabad lapként vannak ezek nyilvántartva)?====
<div class="answer">
A lap egy munkahalmaz része volt, de már nem az, elvették tőle. A lap nem módosult, mióta kiírták a merevlemezre, vagy mióta beolvasták. Egy nem Valid laptábla bejegyzés még mutat rá, azaz ha kell, még könnyen életre lehet kelteni a lapot.
</div>

====Szabad (free) és nullázott (zeroed) lapok: Miért van a Windows-ban külön szabad és nullázott (freed és zeroed) memórialap-lista?====
<div class="answer">
Biztonsági okokból. Nem nullázott memóriaterületet odaadni más folyamatnak biztonsági kockázatot jelent.
Tehát a free lapok szabad lapok, de még nem adhatók oda felhasználói folyamatnak, mert "szemetet" vagy érzékeny adatot tartalmazhatnak: nincs nullákkal felülírva a tartalma. A zeroed lapok szabadok, és nullákkal vannak felülírva, tehát odaadhatók felhasználói folyamatnak, amennyiben igény van rá.

TODO: ez így már megfelelő indoklás?

(Korábban:
*Free*: a lap szabad, de nincs 0-kkal felülírva a tartalma, szemét vagy egy előző processz által használt tartalom van benne. Ezt nem adhatja ki közvetlenül a memóriakezelő más processzeknek, mert biztonsági szempontból aggályos adatokat találhatna rajta.
*Zeroed*: szabad és nullákkal felülírt lap, kiadható, ha valakinek kell.
TODO(ez így igaz, csak ebben a formában nem a kérdésre válaszol))
</div>

====Mik a szerepük a szolgáltatásoknak a Windowsban? ====
<div class="answer">
Olyan folyamatok, amik a felhasználói felülettől és belépéstől függetlenül a háttérben futnak, és kibővítik az operációs rendszer alap szolgáltatásait.
TODO?
</div>

====Újrahívhatóság (reentrancy): Mit jelent az, hogy a Windows-ban a rendszerhívások újrahívhatóak?====
<div class="answer">
A rendszerhívásokat több alkalmazás is meghívhatja egyszerre, nem blokkolódnak, ha már valakit éppen kiszolgál az adott rendszerhívás.
</div>

====Védett objektum tulajdonosának speciális joga: Milyen speciális joga van egy védett objektum tulajdonosának az adott objektumra a Windows-ban?====
<div class="answer">
Megváltoztathatja az objektum engedélyeit, akkor is, ha erre nincs explicit joga. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/03-opre-windows-biztonsag.pptx)
</div>

====Verzióleírás: Mit jelentenek a számok és szavak a következő verzióleírásban: "Microsoft (R) Windows (R) 5.01.2006 Service Pack 2 Uniprocessor Free"?====
<div class="answer">
* (MZ) 5.01.2006 a verziószám, major.minor.build formában, 5.1 a Windows XP verzója, 2006 az SP2-es verzió build száma. Uniprocessor = egy processzoros kernel verzió, Free = debug szimbólumok nélküli verzió.
*(MZ) 2011-től kezdve ez már nem része a tananyagnak
* Most computers run a "uniprocessor free" version of Windows, which is a version that runs on a single CPU and does not contain extra errorchecking.
</div>



==Tartalomjegyzék==
<div class="table_of_contents">
__TOC__
</div>

==Források (teljesség igénye nélkül)==
<div class="docs_sources">
Ez előadás diáin, Wikipédiás és egyéb, Google-lel található cikkeken kívül ezek voltak a források, és MÉG ÍGY SEM tartalmazza az összes beugrókérdést (volt olyan, amit rengeteg idő lett volna átszerkeszteni, vagy kevésbé sanszos, hogy olyan hosszúságú beugrókérdést tennének fel, ami ott szerepelt):

* Hivatalos előadásjegyzetek: http://portal.mit.bme.hu/?l=oktatas/targyak/vimia219/jegyzet/index.html
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaBeugrok
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaKisKerdesek
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2007junius12megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008majus20megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008junius11megoldas
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/pelda_beugro_megoldas.pdf
----
* https://vir.sch.bme.hu/dokumentumok/InfoSite/4.%20f%C3%A9l%C3%A9v/Oper%C3%A1ci%C3%B3s%20rendszerek/
* https://vir.sch.bme.hu/document/targyak/opre/opre_beugro.zip (HOSSZÚ)
* https://vir.sch.bme.hu/document/targyak/opre/oprendszkidolg.zip
* Wikipédia
* Google segítségével fellelhető rengeteg forrás
* stb.

-- [[PeteHaro|Pete]] - 2011.06.19.
* [[Media:opre_beugro_ABC.docx|Operációs rendszerek vizsgabeugrók megoldással DOCX-formátumban (szerkeszthető, javítható!)]]
* [[Media:opre_beugro_ABC.pdf|Operációs rendszerek vizsgabeugrók megoldással PDF-formátumban]]

[[Category:Infoalap]]

Operációs rendszerek kidolgozott beugrókérdések vizsgára ABC-sorrendben

2015-06-10T11:13:12Z

Bolla Dávid: /* Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához? */

==Bevezető==
Korábbi Wiki-n és InfoSite-on szereplő kidolgozott és kidolgozatlan anyagok, számtalan forrásból összeszedve - előadásdiákból, video.bme.hu-n lévő felvett anyagokból, Wikipédiás és egyéb, Google segítségével fellelhető anyagokból kiegészítve.
Hibák előfordulhatnak! TODO-val azokat a részeket jelöltem, amik átnézendők, rendbe szedendők, hiányosak, stb., ezeket is kérlek javítsátok, ha tudjátok! Köszi!
Ami fontos: ABC-sorrendbe rendezve szerepelnek a kérdések, így könnyebben megtalálható, tartsuk is meg ezt a tendenciát!
Remélem hasznát veszitek! -- [[PeteHaro|Pete]] - 2011.06.19.
Valamilyen szintű kategorizálást is beleraktam. A kérdések elejére odaírtam magának a kérdésnek a lényegét is, hogy könnyebben megtalálhatóak legyenek az azonos kérdéskörbe tartozóak.

==Beugrókérdések megoldással==
===Általános jellegű OS-ekkel kapcsolatos kérdések===

====Indulás: Hasonlítsa össze az általános célú (asztali) és a beágyazott operációs rendszereket az indulás szempontjából!====
<div class="answer">
A beágyazottnál először indul az alkalmazás, és az indítja az operációs rendszert, az asztalinál az operációs rendszer indítja az alkalmazásokat.
</div>

====Inkrementális mentés: Mit jelent az inkrementális mentés?====
<div class="answer">
Csak a változtatásokat mentjük az előző mentéshez képest -> kisebb helyet foglal, hamarabb végez a mentés.
</div>

====Kemény valós idejű rendszer: Adja meg a kemény valós idejű (hard real-time) rendszer definícióját!====
<div class="answer">
A rendszer adott eseményekre adott időn belül 1 valószínűséggel válaszol (egyébként hibás, hiába funkcionálisan jó a válasz). A rendszer NEM késhet!
</div>

====Lazán csatolt rendszer: Milyen szinkronizációs kényszereket jelent, ha egy lazán csatolt rendszer kommunikációja során véges kapacitású csatornát alkalmazunk?====
<div class="answer">
ha a küldő folyamat túl gyorsan küldözget, akkor a csatorna megtelik, úgyhogy túlcsordulás lesz, ami miatt a küldőnek várnia kell mielőtt újra küld.
</div>

====Rendszerhívások: Milyen előnnyel jár a rendszerhívások valamilyen magas szintű programnyelvvel történő megadása?====
<div class="answer">

Az API elrejti a rendszerhívások részleteit, bonyolultságát a programozó elől, lényegében egy wrapper réteggel fedi be a rendszerhívásokat.

</div>

====RPC: Milyen részekből áll az RPC technológia?====
<div class="answer">
* RPC: Remote Procedure Call, távoli eljáráshívás. Magas szintű folyamatok közti kommunikációt tesz lehetővé. Részei:
* a hívható eljárások és típusaik (interfész) leírása
* programgenerátor - rpcgen: a leírásból C programkódot generáló program
* kommunikációs infrastruktúra - portmapper: a programazonosítók és a hálózati portok összerendelése
</div>

====Statikus/dinamikus OS: Mikor nevezünk statikusnak, illetve dinamikusnak egy operációs rendszert?====
<div class="answer">
statikus: azok a rendszerek, amelyeknek muködése során - a felépülés és inicializálás kezdeti szakaszától eltekintve - nem jönnek létre és nem szűnnek meg folyamatok. dinamikus: működés közben bármikor születhetnek illetve megszünhetnek folyamatok.
</div>

====Szorosan csatolt rendszerek: Milyen rendszereket nevezünk "szorosan csatolt" rendszereknek?====
<div class="answer">
Ahol több CPU közös óra és közös memória segítségével működik együtt. Általában egyetlen operációs rendszer van, de az bonyolult. (Megjegyzés: az architektúrákból megtanult "közös erőforrást használnak" definícióra csak fél pontot adtak.)
</div>

===Erőforrás-hozzáférés===

====Elosztott rendszerek: Elosztott rendszerekben milyen konzisztencia kérdésekkel kell foglalkozni?====
<div class="answer">
* frissítés konzisztencia
* másolat konzisztencia
* cache konzisztencia
* hiba konzisztencia
* óra konzisztencia
* felhasználói interfész konzisztencia
</div>

====Erőforrás-gazdálkodás: Mi a különbség a hierarchikus és a globális erőforrás-gazdálkodás között?====
<div class="answer">
hierarchikus: a gyermek folyamatok csak a szülő erőforrásaiból részesülhetnek, és nem létezhetnek önállóan, csak amíg a szülőjük is létezik. globális: a rendszer valamennyi folyamata létrejötte után egyenrangú, önálló szereplő, és versenyezhet a teljes erőforráskészletből való részesedésért.
</div>

====Éhezés: Mi az az éhezés?====
<div class="answer">
A folyamatnak megvan mindene, ami a futásához kellene (ezért nem holtpont), de az erőforrásokat, amiket használni akar, más folyamatok kapják meg (ezért nem tud futni).
</div>

====Graceful degradation: Mit jelent a "graceful degradation" fogalma? ====
<div class="answer">
Fokozatos leromlás/összeomlás: Ha a rendszer terhelése eléri az ún. könyökkapacitást, akkor utána viselkedése megváltozik, a tovább növekvő terhelésre már egyre rosszabb működéssel reagál (overhead). Elvárható, hogy ezt fokozatosan tegye (ne omoljon össze).
</div>

====Kölcsönös kizárás====
<div class="answer">
Annak biztosítása, hogy a közös erőforrást egy időben csak annyi magában szekvenciális feladat használja, amely mellett a helyes működése garantálható.
A kölcsönös kizárást meg kell oldanunk a programban. Többnyire a használt erőforrást lock-oljuk (elzárjuk): nem engedjük hozzáférni a többi részfeladatot.
</div>

====Kritikus szakasz: Mit jelent a kritikus szakasz?====
<div class="answer">
A magában szekvenciális feladatok azon kódrészletei, amely során a kölcsönös kizárást egy bizonyos közös erőforrásra biztosítjuk. A kritikus szakasz a kérdéses közös erőforráshoz tartozik. A kritikus szakaszt a hozzá tartozó erőforrásra atomi műveletként (nem megszakítható módon) kell végrehajtanunk.
</div>

====Monitor: Mi a monitor alkalmazásának lényege? (Kölcsönös kizárás)====
<div class="answer">
A lockolás nem szétszórva történik a programban, hanem egyetlen, a közös erőforráshoz szorosan tartozó programrészletben.
</div>

====Prioritás öröklés: Mi a prioritás öröklés (Priority Inheritance, Pl) protokoll lényege? (prioritás inverzió témakör)====
<div class="answer">
Az alacsony prioritású feladat megörökli az általa kölcsönös kizárással feltartott feladat prioritását a kritikus szakaszából való kilépéséig. Csak részben oldja meg a prioritás inverzió problémáját.
</div>

====Test-and-set: Hogyan lehet Test_and_Set utasítással kritikus szakaszba lépést (entry) és kilépés (exit) megvalósítani?====
<div class="answer">
* Belépésnél csökkentjük a value értékét ezzel jelezve hogy használni akarjuk a kritikus szakaszt
* Kilépésnél növeljük a value értékét
Egy változót kijelölünk "lock object"-nek; ha ennek a tartalma 0, nincs senki a kritikus szakaszban. A kritikus szakasz elején egy ciklusban test-and-set-et hajtunk végre rá (az utasítást a ciklus feltételébe téve); ha valaki van a szakaszban már, a ciklusban fogunk keringeni, amíg ki nem lép belőle a másik. Amikor kilépett, a test-and-set következő végrehajtása beállítja a változót, és továbbengedi az egyik várakozó ciklust. A szakaszból kilépéskor pedig simán (nem test-and-set-tel) 0-ba állítjuk.
</div>

====Test-and-set: Hogyan működik a test_and_set?====
<div class="answer">
Visszaadja egy bit értékét, és ha 0 volt, 1-re állítja. Mindezt oszthatatlanul, vagyis ha 0 volt ott, és többen egyszerre hívtak rá test-and-set-et, akkor az egyiké teljesen lefut, 1-be állítja és nullát ad vissza, mielőtt a többi elkezdene futni (így ők mind 1-et fognak visszaadni)
</div>

====Újrahívhatóság: Mit jelent az újrahívhatóság (reentrancy) fogalma?====
<div class="answer">
A közös erőforrás problémájának egyfajta kiterjesztett esete egy függvényen/objektumon belül, mely akkor léphet fel, amennyiben ezt a függvényt/metódust egyszerre többen is meghívhatják. Előfordulhat akkor, ha ugyanazt a függvényt hívjuk egy taszkból és egy megszakítás-rutinból is, vagy ha preemptív ütemezés esetén ugyanazt a függvényt hívjuk két taszkból is.
</div>

===Holtpont===

====Definíció: Adja meg a holtpont definícióját!====
<div class="answer">
Egy rendszer folyamatainak egy H halmaza holtponton van, ha a H halmazba tartozó valamennyi folyamat olyan eseményre vár, amelyet csak egy másik, H halmazba tartozó folyamat tudna előidézni. Másként: A közös erőforrások hibás beállítása vagy használata miatt a rendszerben a részfeladatok egymásra várnak » nincs futásra kész folyamat; » nem jöhet létre belső esemény; » A rendszer nem tud előrelépni.
</div>

====Foglalva várakozás: Holtpont megelőzése (prevention) esetén milyen módszerrel lehet a foglalva várakozás előfordulását kizárni?====
<div class="answer">
* Az erőforrást birtokló feladat kér újabb erőforrást.
* Minden szükséges erőforrást egyben kell lefoglalni, egyetlen rendszerhívással.
* Alkalmazástól függ a használhatósága.
* Erőforrás-kihasználás romlik.
* A foglalva várakozás elkerülhető, ha minden folyamat betartja azt a szabályt, hogy az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el. A szabály betartásával megelőzhető a holtpont, de ára az erőforrás-kihasználás jelentős romlása.
* Ha a folyamatokat kötelezzük arra, hogy minden erőforrásukat egyszerre kérjék el. Ha meg akarjuk engedni a rákérést, akkor menthető állapotú erőforrások esetén megtehetjük, hogy a várakozó folyamatoktól elvesszük az erőforrásaikat.
</div>

====Kezelése: Az operációs rendszer milyen általános eljárásokat használhat a holtpont kezelésére?====
<div class="answer">
* strucc algoritmus (nem vesz róla tudomást)
* holtpont feloldása - melyik holtpontban érintett folyamatot számoljuk fel?
* menthető állapotú erőforrások elvétele,
* minél kevesebb folyamat felszámolása,
* folyamatok prioritása,
* már elvégzett munka,
* folyamatok visszaállíthatóságának biztosítása
* holtpont megelőzése
</div>

====Kialakulás szükséges feltételei: Sorolja fel a holtpont kialakulásának szükséges feltételeit!====
<div class="answer">
* Kölcsönös kizárás: Vannak olyan erőforrások a rendszerben, melyeket a folyamatok csak kizárólagosan használhatnak.
* Foglalva várakozás: legyen olyan folyamat mely lefoglalva tart erőforrásokat, miközben más erőforrásokra várakozik.
* Nincs erőszakos erőforrás-elvétel: a folyamatok addig birtokolják az erőforrást, míg saját jószántukból fel nem szabadítják azokat.
* Körkörös várakozás: Létezik a rendszerben egy olyan folyamatsorozat, melyben minden folyamat az utána következő folyamat által foglalt erőforrásra vár, a sorozat utolsó tagja pedig a sorozat első tagjára.
</div>

====Megelőzés, elkerülés: Mi a különbség a holtpont megelőzése (prevention) és holtpont elkerülése (avoidance) között?====
<div class="answer">
* megelőzése: olyan rendszert tervezünk, ahol nem teljesülnek a holtpont feltételei, így elvileg sem lehet holtpont.
* elkerülése (pl. bankár algoritmus): A rendszer minden erőforrásigény kielégítése előtt mérlegeli, hogy nem vezet-e holtpontveszélyre a kérés teljesítése, más szóval fennmarad-e a biztonságos állapot.

* ( Kölcsönös kizárás minimálisra csökkentése: lehetőleg többpéldányos erőforrásokat alkalmazunk, ahol ez nem lehetséges, ott a hozzáférést megpróbáljuk oszthatatlan műveletté tenni.
* Foglalva várakoztatás megszüntetése: Ha minden folyamat betartja a szabályt, miszerint az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el, akkor elkerülhető a foglalva várakoztatás. Ennek ára van: az erőforrás-kihasználtság romlása.
* Nincs erőszakos erőforrás-elvétel kiküszöbölése: Ha menthető állapotú erőforrásaink vannak, akkor megtehetjük, hogy elvesszük egy adott folyamat erőforrását és egy másiknak adjuk, majd annak lefutása után visszaadjuk a régi állapotában az erőforrást az első folyamatnak.
* Körkörös várakozás megakadályozása: A folyamatok megegyeznek az erőforrások sorszámozásában, minden folyamat csak nagyobb sorszámú erőforrást igényelhet azoknál az erőforrásoknál melyeket birtokol. Ekkor biztosan nem alakulhat ki kör.)
</div>

===Fájlrendszerek===

====Fájl: Mi a fájl az operációs rendszer szempontjából? (háttértár-kezelés)====
<div class="answer">
* a fájl a permanens táron az adattárolás logikai egysége, az operációs rendszer feladata a logikai egységek (fájlok) leképzése valódi fizikai egységekre, ez az OS-ben egy többszintü réteges rendszer
* Absztrakt adattípus (objektum, fájl mutató).
* Adat, név (name - elnev. konvenciók), típus (type - kezelés módja) tulajdonságok (attributes). Tulajdonosok, jogosultságok. Hozzáférési időpontok
* Kölcsönös kizárás (file locking)
* TODO
</div>

====Háttértáron lévő lapok: Milyen részidőkből áll össze a háttértáron levő lapokhoz való tényleges hozzáférési idő? Kis vagy nagy lapok használata esetén kapunk "jobb" byte hozzáférést?====
<div class="answer">
* adatátviteli sebesség + fejmozgás sebessége + lemezek forgási sebessége
* nagy lapok esetén ( mert így közvetlenül egymás után helyezkednek el az összetartőző adatok így nem kell a fejnek "ugrálnia" )
* Először a laptáblából kell kikeresni a lap bejegyzését, és konstatálni, hogy nincs hozzá fizikai lap rendelve. Majd, ki kell választani egy szabad fizikai lapot (ha nincs, ki kell vinni egyet háttértárra), a szabad helyre beolvasni a lapot, majd újraindítani a laphibát okozó utasítást. Ezek közül a háttértárról olvasás nagyságrendekkel lassabb a többinél, ezért lényegében ez határozza meg a teljes hozzáférési időt.
* Ha csak a háttértáron lévő lapokat nézzük, akkor, mivel kisebb lapot gyorsabban lehet beolvasni, ezért kisebb lapoknál gyorsabb a hozzáférés. Ha egy folyamat teljes munkahalmazát nézzük, akkor viszont a kisebb lapok több adminisztrációs költséggel járnak (gyakrabban kell háttértárhoz fordulni), és átlagban a nagyobb lapok adnak jobb eredményt.
</div>

====Indexelt tárolás: Sorolja fel az indexelt tárolás (indexed allocation) előnyeit és hátrányait! (Fájlrendszer-leképzés)====
<div class="answer">
* Szekvenciális és indexelt elérésre is alkalmas.
* Sérülékeny (az index blokkok sérülése a fájlt elérhetetlenné teszi).
* Az index blokkokat viszont könnyű többszörözni (replikálni).
* Sok fejmozgást okoz (seek), a blokkok el vannak szórva a diszken.
* Itt is lehet a láncolt listás töredezettség mentesítéshez hasonló algoritmusokat használni a fejmozgás minimalizálására.
</div>

====RAID: Sorolja fel a RAID technika leglényegesebb elemeit!====
<div class="answer">
* Használjunk több merevlemezt egyszerre.
* Több redundáns alkalmazása növeli a megbízhatóságot.
* Több párhuzamos használata növeli a sebességet.
* Hozzunk létre egy virtuális diszket a fizikai diszkekből.
* Redundant Array of Inexpensive Disks: több lemez összekapcsolása.
* A RAID-0 esetében két lemezre vannak szétosztva az adatok, így egyetlen fájlt kétszer akkora sebességgel lehet írni (a két felét parhuzamosan).
* A RAID-1 esetében ugyanazt az adatot tároljuk le a két lemezen, így gyorsabb nem lesz, de az egyik lemez hibája esetén visszanyerhetőek az adatok.
* Megjegyzés: ez csak példa, több lemezzel is lehet csinálni, a sebesség/tárhely/hibatűrés között különböző kompromisszumokat elérve.
</div>

====RAID0 vs. RAID1: Hasonlítsa össze két azonos diszkből álló RAID0 és RAID1 tömb tulajdonságait! Hogyan alakul a hozzáférési idő, az adatátviteli sebesség és a megbízhatóság egyetlen diszkhez képest a két esetben?====
<div class="answer">
RAID 0-1 szabványok általában SW implementációval és kevés (2db) diszkkel
* RAID 0 (striped disks):
** Több diszk párhuzamos használata;
** file részei N diszkre kerülnek;
** Az egyes részek egymástól függetlenül elérhetők
** A diszkek tárolókapacitása összeadódik
** N azonos diszk esetén a RAID 0 virtuális diszk olvasásai és írási adatátviteli sebessége maximum N-szeres közelébe nő.
** A hozzáférési idő közel eléri egy diszk hozzáférési idejét.
** Bármelyik diszk meghibásodása esetén az adat elveszik
* RAID 1 (mirroring):
** Több diszk redundáns használata.
** A file minden része minden (N) diszkre kikerül.
** Azonos diszkeket feltételezve a tárolóterület egy diszk tárolóterületével azonos.
** Az adatátviteli sebesség lassabb, mint egy diszk sebessége.
** A hozzáférési idő nő.
** Speciális esetben az olvasási sebesség N-szeresre nőhet, feltételezve a diszk meghibásodásának más módon történő észlelését (nem kell az azonosságot ellenőrizni többségi szavazással).
** Egy működőképes diszk esetén az adat elérhető.
</div>

====RAID5: Adja meg az M (M pozitív egész szám) diszket tartalmazó RAID5 tömb tulajdonságait! (hibatűrés és sebesség)====
<div class="answer">
* RAID 5 (block interleaved distributed parity).
* Több diszk redundáns és párhuzamos használata
* Adat és paritás elosztása N+1 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 1 diszk meghibásodása esetén az adat elérhető.
** 2 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error). A 2. meghibásodás észlelése a tömb újraépítése során)
</div>

====RAID5: Miért előnyös és miért hátrányos RAID5 használata?====
<div class="answer">
* + N azonos diszk esetén az olvasási és írási adatátviteli sebessége maximum N-szeres közelébe nő.
* + 1 diszk meghibásodása esetén az adat elérhető.
* - 2 vagy több diszk meghibásodása esetén az adat elveszik.
* - Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error).
* -Bonyolultabb, mint a Raid 0/1, ezért hardveresen valósítják meg, ami viszont drága
</div>

====RAID6: Adja meg a 8 darab 1 Tbyte-os HDD-ből álló RAID6 tömb tárolókapacitását!====
<div class="answer">
6 TB. (Adat és paritás elosztása N+2 diszkre. A kapacitása N diszk tároló kapacitásával egyenlő.)
</div>

====RAID6: N db azonos diszkből álló RAID6 tömb esetén a tömb tárolókapacitása és sebessége (nagy fájlok írása/olvasása során elérhető adatátviteli sebesség) hogyan viszonyul az egyetlen diszk azonos adataihoz?====
<div class="answer">
* RAID 6 (block interleaved dual distributed parity)
* Több diszk redundáns és párhuzamos használata.
* Adat és paritás elosztása N+2 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 2 diszk meghibásodása esetén az adat elérhető.
** 3 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nagyobb valószínűséggel állítható helyre a RAID 5-höz képest
* Minimum négy lemezre van szükség a RAID 6 működéséhez. The capacity of the array is (N-2) times the size of the smallest member disk for the array of N disks.
* Az olvasási sebesség (N-2)-szerese egy lemez olvasási sebességének - two disks in the row hold a parity which is useless to read. Such read speed values are roughly the same as in RAID 5.
</div>

====Tárolás egysége: Mi a logikai és mi a fizikai tárolás egysége a permanens táron?====
<div class="answer">
* logikai egység: fájl (file)
* fizikai egység: adatblokkok (cilinder, sáv és szektor együtt azonosítja az írható/olvasható adatblokkot; OS képzi le a logikaiakat fizikaiakra)
</div>

===Folyamatok, szálak===

====Bernstein feltétele: Mikor lehet két tevékenységet (utasítássorozatot) párhuzamosan végrehajtani (Bernstein)?====
<div class="answer">
Bernstein feltétele:
* Legyen <math> P_i </math> és <math> P_j </math> két darabja egy programnak.
* A <math> P_i </math> összes bemeneti változója <math> I_i </math>, és az összes kimeneti változója <math> O_i </math>, ugyanez <math> P_j </math> -re <math> I_j </math> és <math> O_j </math>.
* A két program párhuzamosan végrehajtható (vagyis független), ha: <math> I_j \bigcap O_i = 0 </math>, <math> I_i \bigcap O_j = 0 </math> és <math> O_i \bigcap O_j = 0 </math>
</div>

====Feladatok (task) együttműködése: Hasonlítsa össze a közös memórián illetve az üzenetváltáson alapuló folyamatok közti együttműködést!====
<div class="answer">
Közös memórián keresztül történő adatcsere esetén az együttműködő folyamatok mindegyike saját címtartományában lát egy közös memóriát. A közös memória elérését valamilyen adatátviteli rendszer teszi lehetővé. Üzenetváltásos adatcsere esetén a folyamatoknak nincs közös memóriája. Az adatátviteli rendszer most a logikai processzorokat kapcsolja össze. Rajta keresztül a folyamatok üzeneteket tudnak küldeni, illetve fogadni. Az üzenetküldésre a folyamatok logikai processzorainak utasításkészletében megfelelő utasítások állnak rendelkezésre. Ezek a Küld (Send) és a Fogad (Receive) műveletek.
</div>

====Folyamat: Definiálja a "folyamat" (process) fogalmát!====
<div class="answer">
* Egy program futás alatt álló példánya a folyamat.
* saját kód, adat, halom, verem
* A folyamatok nem férnek hozzá egymás lapjaihoz (védettek más folyamatoktól)

* végrehajtás alatt álló program (program maga a végrehajtható kód), amely folyamat virtuális címterébe van leképezve
* folyamat egy szála az, ami éppen fut egy CPU-n, és nem maga a folyamat
* minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát
* privát virtuális címtér (virtuális memóriacímek készlete, amiket a folyamat használhat)
* tartozik hozzá egy egyedi folyamatazonosító (process ID)
* rendszererőforrások listája, melyekhez a folyamat összes szála hozzáfér
* a folyamat virtuálisan összefüggő memóriát lát (virtuális memória) (valójában az összefüggő memóriaterület ritka)
* háttértárolóra is kiírható (swapping)
* A folyamat által látott logikai címtartomány, és a ténylegesen használt fizikai címtartományok teljesen elkülönülnek
* Folyamatok megoszthatnak memóriaterületeket olvasás- vagy akár írás- és olvasás-hozzáféréssel (Az ilyen memória területek több folyamat virtuális címtartományába vannak belapozva)
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 IPC (Inter-process communication) megoldást!====
<div class="answer">
* '''Jelzés''': rendszerüzenetek küldése és fogadása a folyamatok között, jellemzően utasítások továbbítása egyik folyamattól a másiknak
* '''Üzenetsor''': aszinkron kommunikációs forma, mely során a küldő és fogadó közvetlen interakciója nem szükséges, az üzenetek addig tárolódnak a sorban amíg a címzett fel nem dolgozza azokat vagy a sor meg nem telik
* '''Szemafor''': absztrakt struktúra amely a folyamatok közötti közös erőforrásokért való hozzáférést vezérli
* '''Közös memória''': ugyan az a memóriaterület kerül kiosztásra több különböző folyamatnak, írási és olvasási joggal egyaránt

''Forrás'': http://en.wikipedia.org/wiki/Inter-process_communication
</div>

====Folyamatok vs. szálak: Mi az eltérés a folyamatok illetve a szálak között, és milyen előnnyel jár a szálak alkalmazása?====
<div class="answer">
A szálak lényegében párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
</div>

====Java-szálak: Milyen módokon képezheti le a JAVA virtuális gép a JAVA natív szálakat a hoszt operációs rendszer folyamataira/szálaira?====
<div class="answer">
A JAVA virtuális gép egy folyamat a hoszt operációs rendszeren belül. A JAVA szálak feleltethetők meg a hoszt operációs rendszer szálainak, ez többnyire one-to-one (JAVA szál egyben OS szál is) napjainkban. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/20100507_ZH_megoldas.pdf)
Kovácsházy Tamás válasza:
7. fólia, 11. fólia:
JAVA (VM a folyamat, VM-en belül szál):
* Thread osztályból származtatva
* Runnable interface megvalósítása
* A JAVA platform-specifikusan valósítja meg a szálat:
* Natív OS specifikus szál (one-to-one, tipikus).
* JAVA specifikus szálak (many-to-one) egy natív OS szálra vagy folyamatra leképezve.
* many-to-many leképzés (erőforrás szempontok miatt, egyre ritkább).

</div>

====PRAM: Mi történik a PRAM modellben írás-írás ütközés esetén?====
<div class="answer">
Az írás-írás ütközésekor valamelyik művelet hatása érvényesül, a két beírni szándékozott érték valamelyike írja felül a rekesz tartalmát (versenyhelyzet), harmadik érték nem alakulhat ki.
</div>

====Processzor-affinitás: Mit állítunk be, ha egy szálnak beállítjuk a processzor affinitását, és miért lehet arra szükség?====
<div class="answer">
* processzoraffinitás: minden szál rendelkezik egy maszkkal, amely kijelöli, hogy a szál mely processzorokon képes futni
* szerepe: ez alapján dől el, hogy a szál mely processzoron fog futni
* ütemezésnél: multiprocesszoros esetben a processzor kiválasztása a processzor-affinitás alapján történik
* A feladat más processzorra, vagy processzormagra kerülése csökkenti a végrehajtás sebességét (pl. cache-elésnél) >> Cél: A feladatot ugyanazon a végrehajtó egységen tartani - Laza vagy kemény processzor affinitás (soft or hard processor affinity).
** Laza: Nincs garancia, de törekszik rá az OS (többnyire alapeset)
** Kemény: Biztosan ugyanazon a CPU-n marad (rendszerhívással)
</div>

====Szál: Definiálja a "szál" (thread) fogalmát!====
<div class="answer">
* párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk és saját vermük van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak, vagyis egymás adatait olvashatják és írhatják. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
* A folyamat egy szála az, ami éppen fut egy CPU-n (ami ütemezésre kerül), és nem maga a folyamat.
* Minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát (szál nélkül a folyamat programja nem futhat).
* szálak még véletlenül sem hivatkozhatnak más folyamatok címterére, hacsak a másik folyamat nem teszi elérhetővé privát virtuális címterének egy részét megosztott memóriaszakaszként (file mapping object a Windows API-ban), vagy - Windows-nál - hacsak egyik folyamatnak nincs joga megnyitni más folyamatot, hogy olyan folyamatok közti memóriafüggvényeket használjon, mint a ReadProcessMemory vagy WriteProcessMemory
* A szál önmagában szekvenciális kód, a végrehajtás legkisebb egysége. Egy adott folyamat szálainak közös az adat- és kódszegmensük, a halmuk (heap), és az egyéb erőforrásokat is közösen használják, de saját virtuális CPU-t látnak, és saját veremmel rendelkeznek.
* TODO
</div>

====Védelmi tartományok: Mi a különbség a statikus és a dinamikus védelmi tartományok között?====
<div class="answer">
Statikus védelmi tartományok esetén az egy folyamathoz tartozó védelmi tartomány a folyamat végrehajtása során nem változik, míg dinamikus védelmi tartományok esetén igen.
</div>

====Virtuális gép: Mi a virtuális gép koncepció lényege?====
<div class="answer">
* A programok elől az operációs rendszer elfedi a hardver implementációs részleteit, és kibővíti azt plusz funkciókkal.
* Az op.rendszer egy olyan réteget képez a hardver fölött, mely elrejti annak körülményességét és bonyolultságát a programozó elől és kibővíti a hardver szolgáltatását. A felhasználó így egy sokkal kellemesebb virtuális gépet (virtual machine, extended machine) lát.
* Az operációs rendszer egy kényelmesen kezelhető virtuális gépet jelenít meg a felhasználói és a programozói felületen.
</div>

===Jogosultságok===

====Belső biztonság: Mi a belső biztonság?====
<div class="answer">
Belső biztonság = védelem. Védelemnek nevezzük az eljárásoknak és módszereknek azon rendszerét, amely lehetőséget teremt a számítógép erőforrásainak programok, folyamatok illetve felhasználók által történő elérésének szabályozására.
</div>

====Engedélyezés: Definiálja az engedélyezés (authorization) fogalmát!====
<div class="answer">
* jogosultság ellenőrzése: milyen adatokat és szolgáltatásokat érhet el ez a személy?
* Hozzáférés-szabályozási listák (Access Control List, ACL)
* Alapelv: mindig csoportnak osztunk jogot
* Pl. biztonsági házirend, fájl ACL

TODO!!!
</div>

====Jogosultság + engedélyezési sémák: Mi a jogosultság fogalma, mi a kapcsolata az engedélyezési sémák többi alapfogalmával?====
<div class="answer">
* A jogosultság egy reláció a szereplők és védett objektumok között.
* engedélyezés ált. sémáinál: szereplő>>>szereplőt leíró adatszerkezet>>>biztonsági szabályzat (policy), JOGOSULTSÁG>>>védett objektumok TODO
* Jogosultságkezelés alapjai: A rendszer működése során
** A szereplők műveleteket kezdeményeznek
** A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját
** A jogosultsági döntő komponens kiértékeli kontextust és engedélyezi vagy megtiltja a műveletet
** A jogosultsági végrehajtó komponens biztosítja, hogy a döntő által hozott döntés érvényre jusson
* NT: SMR (Secure Reference Monitor) - objektumok elérési jogosultságainak ellenőrzése
* NT: Az LSA a SAM segítségével azonosítja a felhasználót és jogosultságait. Ha a felhasználó jogosult bejelentkezni, a logon elindítja a számára kijelölt shellt
* UNIX: hozzáférési jogosultságok (owner, group, others, read, write, execute)
* Engedélyezés általános sémái: >>Szerep alapú hozzáférés-vezérlés >>Hozzáférési jogosultság listák
* TODO
</div>

====Külső biztonság: Mit takar a külső biztonság fogalma?====
<div class="answer">
Annak mértéke, hogy mennyire lehetünk biztosak a számítógépes rendszer, illetve a rendszerben tárolt adatok sérthetetlenségében.
</div>

====Művelet kontextusa: Engedélyezési rendszerekben mit tartalmaz egy művelet kontextusa? (Felhasználó- és jogosultságkezelés)====
<div class="answer">
A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját.
</div>

===Hibakeresés===

====DTrace: Mi a Solaris DTrace megoldás célja?====
<div class="answer">
dinamikus hibakereső rendszer, nyomkövető eszköz, amivel a rendszer és a programok működését futási időben lehet megfigyelni.
</div>

===Memória===

====32 bit: 32 bites kliens Windows operációs rendszer maximum mennyi fizikai memóriát kezelhet, és miért?====
<div class="answer">
Legfeljebb 4 GB-ot (bár néha kevesebbet lát az OS, mert a memóriatartomány felső részére I/O eszközöket szoktak berakni, ld. pl. videókártya-memória...): ''"kliens Windowsok nem használják a gépben lévő PAE támogatást, mert az a tapasztalat, hogy a kliensekben lévő eszközök meghajtói nem kezelik le rendesen a 4 GB-nál több fizikai memóriát"''.
(https://wiki.sch.bme.hu/pub/Infoalap/OpRe/02-opre-windows-memoria.pptx)
(nem támogatják a PAE-t eleve, csak patch-csel)
(_"However, "client" versions of 32-bit Windows (Windows XP SP1 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility and licensing reasons, even though these versions do run in PAE mode if NX support is enabled."_ - http://en.wikipedia.org/wiki/Physical_Address_Extension)
</div>

====32 bit: 32 bites szerver Windows képes-e 4 GB-nál több fizikai memória kezelésére? Válaszát indokolja!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével (ezzel lehet 32 bites címbuszú CPU-val is 64 GB memóriát kezelni a maximális 4 GB helyett).
</div>

====32 bit: 32 bites Windows használata esetén egy felhasználói folyamat maximum mekkora virtuális címteret használhat?====
<div class="answer">
Alapból 2GB felhasználói módú címterületet használhat, ez a /3GB kapcsolóval 3 GB felhasználói címterületre bővíthető.
</div>

====32 bit: 32 bites Windows szerver operációs rendszerek képesek-e 4 GB-nál több fizikai memória kezelésére? Indokolja válaszát!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével.
</div>

====32 bit: 32 bites x86-os (Windows) esetén mekkora a felhasználói és a rendszer mód címtartomány mérete?====
<div class="answer">
Alapból 2GB felhasználói módú és 2GB kernel címterület van, ezt a /3GB kapcsolóval 3GB felhasználói és 1GB kernelre lehet módosítani.
</div>

====Bélády-anomália: Mit nevezünk Bélády-anomáliának?====
<div class="answer">
FIFO algoritmusnál egyes esetekben, ha a munkahalmaz méretét növeljük, a várakozásokkal ellentétben a laphibák száma is nő.
</div>

====Címfordítás: Hogyan történnek a címfordítások, ha az OS szegmens- és lapszervezést is használ a memóriánál?====
<div class="answer">
CPU --> Segmentation unit --> Paging unit --> Physical memory
</div>

====Címfordítás: Milyen címtranszformációk történnek együttes szegmens- és lapszervezésű memória használata során?====
<div class="answer">
* CPU >>>[Logical Address]>>> '''Segmentation Unit''' >>>[Linear Address]>>> '''Paging Unit''' >>>[Physical Address]>>> Physical Memory (http://portal.mit.bme.hu/?l=oktatas%2Ftargyak%2Fvimia219%2Fjegyzet%2F2011%2Fslides_17_memory.pdf)
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/oprewiki1.pdf, 48. oldaltól.
* Változó méretű szegmensek fix méretű lapokat tartalmaznak. Kicsi mind a belső, mind a külső tördelődés. A cím felépítése: (szegmens szám, lapszám, lapon belüli eltolás)
* Hasonlít a szegmensszervezéshez és a kétszintű lapszervezéshez: A memóriában szegmensek vannak ugyan, de ezek lapokból épülnek föl. Van szegmenstábla, és minden bejegyzéséhez tartozik egy laptábla is. Külső töredeződés nincs, belső töredeződés minimális (szegmensenként átlag fél lap); ez a kombinált módszer egyesíti a két módszer előnyeit
* TODO
</div>

====Lapszervezés, keret tábla: Lapszervezés esetén mit tartunk nyilván a keret táblában (frame table)?====
<div class="answer">
Az üres kereteket (frames).
</div>

====Logikai vs. fizikai memória: Mi a különbség a logikai és a fizikai memória között?====
<div class="answer">
A logikai memória a fizikai tár leképezve, ráadásul a leképezés a végrehajtás során változhat is.
</div>

====MMU: Mi a processzor Memory Management Unit (MMU) komponensének a feladata?====
<div class="answer">
* Speciális HW a CPU-ban
* Memória állapotának nyilvántartása
** Tulajdonos folyamat azonosítója
** Hozzáférési jogosultságok (ACL)
** cache-elhetőség, ha van cache (pl. DMA)
* Virtuális memória leképzése fizikai memóriára
** Pl. Translation Lookaside Buffer (TLB)
** Kontextusváltásnál ezt is kezelni kell (ha van)
** Pagefile vagy SWAP (HDD)
* Memóriavédelem
** Tiltott memória hozzáférés megakadályozása vagy legalább jelzése (ACL alapján)
** General Protection Fault (GPF) a Windows-ban
</div>

====Modified/dirty bit, referenced/used bit: Mi a modified/dirty bit és a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* laptáblában:
* Módosítás nyilvántartása (modified/dirty bit): minden memórialaphoz tartozik egy HW által kezelt bit (pl. a laptáblában) - betöltéskor törlik, módosításkor beállítják. Ha a dirty bit 1, akkor erre a lapra történt írási művelet, mióta a ﬁzikai memóriába került. Ezt a bitet a CPU tartja karban (automatikusan), ezzel az operációs rendszer munkáját segítve. 0 érték esetén a lapokat nem kell a diszkre kiírni, ha kiszorulnak a ﬁzikai memóriából (hiszen a tartalmuk a ﬁzikai memóriába helyezés óta változatlan, a diszk-en tárolt változat tehát továbbra is aktuális).

* Hivatkozások nyilvántartása (referenced/used bit): Ha a refernced bit 1, akkor volt "mostanában" hivatkozás erre a lapra. Ezt is a CPU tartja karban. Ez a bit segít az operációs rendszernek, amikor el kell döntenie, hogy melyik lapot dobja ki a ﬁzikai memóriából, ha egy új lapnak nincs helye. A referenced=0 lapokból fog válogatni.
</div>

====Page locking: Mit jelent és miért van szükség arra, hogy a virtuális tárkezelésnél egyes lapokat ideiglenesen a tárba lehessen "fagyasztani" (page locking)?====
<div class="answer">
* Azt jelenti, hogy a lapcsere algoritmus nem lapozhatja ki a háttértárra az adott lapot. Ok: periféria-művelet van az adott lappal kapcsolatban.
* Azt jelenti, hogy bizonyos lapokat a memóriában tartunk, mert I/O műveletek hivatkozhatnak rá, és ilyenkor a memóriában kell lenniük, mert az I/O műveletek fizikai memóriacímeket használnak.
</div>

====Referenced/used bit: Mi a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* Bizonyos algoritmusok igénylik a lapra történő hivatkozások figyelését is, ami ugyancsak hardvertámogatással hatékony. A laptáblában erre a célra is fenntarthatunk egy bitet. Ezt a hivatkozott bitet (referenced bit, used bit, R bit) a címképző hardver állítja be minden esetben, amikor az adott lapon belüli címre történik hivatkozás. A bitet az operációs rendszer törli adott időnként, vagy eseményhez (például laphiba) kötötten.
* Hivatkozások nyilvántartása (referenced/used bit): OS adott időnként és/vagy adott eseményekre törli - használat esetén beállítják.
</div>

====TLB: Mi az a Translation Lookaside Buffer, fizikai címcsatolásnál mi a szerepe?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.
</div>

====TLB: Mire szolgál a Translation Lookaside Buffer és mi a szerepe a fizikai cím kiszámításánál (virtuális címképzés)?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.

(Szerintem előbb a TLB-ben keresi, aztán ha ott nincs, csak utána nézi a laptáblát.)
</div>

====Tördelődés (külső vs. belső): Mi a különbség a külső és belső tördelődés között? (Memória foglalás)====
<div class="answer">
A tördelődött memóriaterületet külső tördelődés esetén az operációs rendszer szabadon hagyja, míg belső tördelődés esetén pedig odaadja egy olyan folyamatnak, aminek nincs igazából rá szüksége.
</div>

====Vergődés: Adja meg a vergődés (trashing) definícióját!====
<div class="answer">
A gyakori laphibák okozta teljesítménycsökkenést vergődésnek (thrashing) nevezzük. Az ellene való védekezés a munkahalmaz méretének jó megválasztása. Célszerű egy folyamatnak annyi lapot adni, amennyi szükséges az egyensúlyhoz, azaz ahány lapra hivatkozik a laphiba kiszolgálás ideje alatt (ugyanakkor nem sokkal többet, mert ekkor leromlik a multiprogramozás foka).
</div>

====Vergődés: Mi az a vergődés, és hogyan védekezzünk ellene?====
<div class="answer">
* Ha több memóriára lenne szüksége a folyamatoknak, mint amennyi rendelkezésre áll, ezért túl gyakran keletkezik laphiba, és a processzor idejének nagy része haszontalan lapcserékkel telik.
* Védekezni ellene például azzal lehet, ha a laphiba-gyakoriság függvényében az ütemező változtatja a multiprogramozás fokát: ha kevés a memória, folyamatokat függeszt fel, és swappel ki; ha van elég, akkor épp ellenkezőleg.
</div>

===uc/OS-II===

====Prioritás: A uC/OS-II-ben hány taszk tartózkodhat egy prioritási szinten és miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk.
</div>

====Prioritás: Egy prioritási szinten hány szál futtatását teszi lehetővé a uC/OS-II, miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk. Egy taszk = egy szál.

(Magyarázat: egy taszk = egy szál; lásd http://video.bme.hu/media/video/Operacios_Rendszerek_08ea_20110301.wmv, 01:09:18 környékén
Röviden: a beágyazott rendszerek, kis OS-ek esetén (uC/OS-II, FreeRTOS, stb.) lényegében csakis szálakban gondolkozunk. Nincs MMU, csak egyetlen összefüggő fizikai memória van, nincs virtuális memória koncepció, a processzoron futó teljes alkalmazás (az egyetlen alkalmazás) egy nagy folyamat - nincs más folyamat! Ezenbelül tudunk threadeket futtatni. Single Address Space.)
</div>

===Ütemezés===

====Átbocsátó képesség: Adja meg az átbocsátó képesség definícióját és mértékegységét!====
<div class="answer">
* (throughput) Mértékegység: munka/s, vagy 1/s
* Adott időegység alatt elvégzett feladatok száma. <math>\frac{\sum \textrm{elvegzett munkak}}{\textrm{ido}}</math>
* A rendszerfeladatokat nem számoljuk.
</div>

====Hosszú távú ütemezés: Adja meg a hosszú távú ütemezés célját!====
<div class="answer">
Tipikusan a BATCH rendszerekben van jelen, és uj jobok végrehajtasának megkezdéseről (új folyamatok indítasárol) dönt. Az elvégzesre váro munkák közül a választas szempontja, hogy a rendszerben a CPU-intenzív es I/O-intenzív folyamatok aránya optimális legyen (optimalis job-mix fenntartasa).
</div>

====Hosszú távú ütemezés: Definiálja a hosszú távú ütemezés fogalmát!====
<div class="answer">
A hosszútávú ütemező feladata az elindított feladatok rendszerbe, illetve a "futásra kész" várakozási sorba való beengedését szabályozni. Igyekszik a CPU-t és a perifériákat terhelő folyamatokat egyensúlyban tartani. Batch rendszerekre jellemző; a PC-k oprendszere általában azonnal indítja a folyamatokat, mikor azt a felhasználó kéri.
* feladata: A háttértáron várakozó feladatok közül kiválasztja azt, amelyiket el kell indítani.
</div>

====Konvoj hatás: Mi a konvoj hatás, és a tanult ütemező algoritmusok közül melyekben jelentkezhet?====
<div class="answer">
* igen nagy lehet az átlagos várakozási idő, mivel egy-egy hosszú CPU-löketű folyamat feltartja a mögötte várakozókat
* FCFS-nél (First-come, first-served) tapasztalható (pl. SJF (Shortest Job First) és RR algoritmus küszöböli ki)
</div>

====Középtávú ütemezés: Adja meg a középtávú ütemezés célját!====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.
</div>

====Középtávú ütemezés: Mi a középtávú ütemező feladata?====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.

Szerintem inkább ez:
A rendszerben lévő feladatok memóriájának egyes éppen nem használt részeinek kiírása háttértárra.
</div>

====Körülfordulási idő: Mi az a körülfordulási idő?====
<div class="answer">
* TAT (Turnaround Time) -> Egy feladatra vonatkozóan a rendszerbe helyezéstől a teljesítésig eltelt idő.
* Mértékegység: s,
* t_(CPU,végrehajtási idő)+t_várakozás (Magában foglalja a ténylegesen munkával töltött időt és a várakozást is.)
* felhasználó minél előbb szeretné látni a végeredményt
</div>

====Megszakítás: Az éppen futó taszkot megszakítja egy IT. Preemptív OS esetén mindig a megszakított taszk fogja-e visszakapni a futási jogot? Miért?====
<div class="answer">
* Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
* Másik: Nem, mert akitől elvették a futás jogát az futásra kész állapotba fog kerülni és az ütemező dönti el, hogy melyik folyamat fogja megint megkapni a futást.
</div>

====Megszakítás: Egy futó taszkra IT érkezik. Preemptív OS esetén az interrupt után mindenképpen 'ide' térünk vissza?====
<div class="answer">
Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
</div>

====Preemptív ütemező: Mikor nevezünk egy ütemezőt preemptívnek? ====
<div class="answer">
Ha az OS elveheti a futásjogot (a CPU-t) egy folyamattól/futó feladattól (interrupt).
</div>

====Rövid távú ütemezés: Mi a rövidtávú ütemezés, mikor jár környezetváltással?====
<div class="answer">
* Rövidtávú ütemezés: futó folyamat kiválasztása a futásra kész feladatok közül
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Rövid távú ütemezés: Mikor fut a rövidtávú ütemező és mikor jár környezetváltással?====
<div class="answer">
* Ütemezés következhet be, ha
** a futó folyamat befejeződik,
** egy folyamat felébred, futásra késszé válik,
** a futó folyamat várakozni kényszerül (valamilyen esemény bekövetkezésére), illetve,
** a futó folyamat önként lemond a futás jogáról vagy pedig elveszik tőle.
* Az első és a harmadik esetben az ütemezés mindig környezetváltással jár, hiszen a következő futó folyamat egészen biztosan nem a korábban futott lesz. A másik két esetben előfordulhat, hogy az ütemezőnek nem kell másik folyamatot kiválasztania.
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Terhelés-végrehajtó egységek közötti megosztás: Sorolja fel a terhelés-végrehajtó egységek közötti megosztásának megoldásait! (Többprocesszoros rendszerek)====
<div class="answer">
* Master and slaves (egy CPU osztja ki a feladatokat)
* Self-scheduling / peering (minden CPU ütemez)
* Globális futásra kész sor
* Processzoronkénti futásra kész sor
** Push alapú: OS kernel folyamat mozgatja a sorok között a feladatokat.
** Pull alapú: Az idle állapotban (idle feladatot végrehajtó) CPU próbál a többi sorából feladatot kapni.
* Kettő kombinációja
** Összefüggő, párhuzamosan futtatható feladatok optimalizálása (pl. Gang scheduler)
</div>

===Virtualizáció===

====Hardveres virtualizáció: Mit jelent az, ha egy x86-os processzor hardveres virtualizáció támogatással rendelkezik?====
<div class="answer">
A CPU utasításkészletének és üzemmódjainak olyan kiegészítése, amely lehetővé teszi a vendég operációs
rendszer kódjának módosítás nélküli futtatását. [?]

(Speciális utasításokkal látják el a processzort, amit szoftveresen akár több 100 utasításon keresztül lehetne csak megoldani. ROSSZ(MZ))

Elrejti a gep fizikai tulajdonsagait a felhasznalok elol.

Miert erdemes virtualizalni?

-Lehet futtatni a gazda OS el nem kompatibilis alkalmazast.

-Lehet biztonsaggal rendszergazda jogot adni mindennek, mert ugy se tud a gazda os-be kart tenni.

-Konnyen at lehet masolni a virtualis gepet egy masik gepre.
</div>

====Hosted vs. bare-metal: Miben különbözik egy hosted egy bare-metal típusú virtualizációs megoldástól?====
<div class="answer">
Bare-metal esetén a VMM kezeli a HW erőforrásokat, míg hosted típusú esetén ezt a host OS végzi.

videó:
http://video.bme.hu/media/video/Operacios_Rendszerek_20ea_20110418.wmv
00:16:45 körül

Kétféle megközelítés:

# Hosted: az operációs rendszerre telepítek egy virtualizációs szoftvert, ez beépül az operációs rendszerbe tipikusan kernel modulként, innentől a virtualizációs szoftver teszi lehetővé, hogy virtuális gépeket futtassak. Tipikusan a desktop megoldások (VMware Player, VirtualBox, Virtual PC, stb.)
# Bare-metal: a virtualizációs szoftver valós OS-szerű funkciókat valósít meg. Lényegében egy minimális funkciókészlettel rendelkező OS. A hardvert nem egy általános célú operációs rendszer kezeli, hanem a virtualizációs szoftver feladata az, hogy a hardver-erőforrásokkal gazdálkodjon, ő dönt az ütemezésről, ő dönt a memória-hozzáférésekről. Tipikusan szokott hozzá tartozni egy menedzsment operációs rendszer, egy menedzsment konzol, ami a távoli hozzáférést, virtuális gépek elindítását lehetővé teszi, és ott is ott tudom futtatni a vendég operációs rendszereket. Tipikusan szervermegoldások (VMware ESX Server, Xen Enterprise, MS Hyper-V).

Fontos különbség: ki dönt a CPU-erőforrásról?
# van az OS-nek egy ütemezője, ő dönt arról, mikor, ki kapja meg a CPU-t. Dönthet úgy, hogy az időszeletet az alkalmazás kapja meg, a köv. időszeletet a virtualizációs szoftver/modul, ő magán belül pedig eldöntheti, melyik virtuális gépnek osztja a processzort, de alapvetően a host OS dönt arról, mi dönt az erőforrásról.
# arról, hogy ki kapja a CPU-t, a közvetlenül a hardver réteg felett lévő virtualizációs szoftver dönti el. Dönthet úgy, hogy a menedzsment OS kapja, dönthet úgy, hogy valamelyik virtuális gép kapja meg.

</div>

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
<div class="answer">
Módosítjuk a vendég OS forráskódját, hogy ne is akarjon "problémás" utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. (Ezzel egyszerűsödik a hypervisor implementálása, viszont csak úgy működik a módszer, ha módosítják a vendég OS forrását.)
</div>

====Trap-and-emulate: Trap & emulate virtualizációs módszer használata esetén mi történik a vendég gép által kiadott nem privilegizált utasítással?====
<div class="answer">
* nem privilegizált utasítások közvetlenül a valós CPU-n hajtódnak végre (no VMM intervention)
</div>

===UNIX===

====Adminisztratív adatok: hol helyezzük el azokat az adminisztratív adatokat, amelyekre mindig szükség van, akkor is, ha a folyamatnak egyetlen lapja sincs a memóriában?====
<div class="answer">
A proc struktúrában.
</div>

====Adminisztratív adatok: UNIX-ban a folyamatokkal kapcsolatos adminisztratív adatok hogyan épülnek fel?====
<div class="answer">
TODO: rövidíteni.

# adatok, melyek elsősorban akkor szükségesek, amikor a folyamat ténylegesen fut - bent van egy v. több lapja a memóriában, éppen ezekkel kapcsolatos utasításokat hajtunk végre. >> az u-területen található kontextusadatok. A folyamat címtér része. A folyamat nem férhet hozzá, de a folyamat saját címterében találhatók. Amikor a folyamatnak egyetlen lapja sincs a memóriában, hanem minden a háttértáron található, a folyamat nem fut, akkor az itt található adatokhoz a kernel sem tud hozzáférni, mivel ide csak azok az adatok kerülnek, melyek a folyamat futásakor kellenek! Pl. hozzáférés-szabályozási adatok: a folyamat szeretne valamilyen tevékenységet végrehajtani, szabad-e neki vagy sem? Másik példa: rendszerhívások állapotai: végrehajt egy rendszerhívást, amiben éppen tartózkodik, ezzel kapcsolatos állapotadatok, stb. Vagy: nyitott fájl adatok, fájlkezeléssel kapcsolatos adatok. UNIX-ban a fájlkezelést nagyon általánosan kell érteni. Minden, ami a fájlrendszer-interfészen keresztül zajlik, ahhoz tartozik egy nyitott fájl objektum, ami ennek adminisztrálására szolgál, ezek is az u-területen találhatók. Ezenkívül: számlázási, statisztikai adatok.

# adatok, melyek elsősorban a folyamatok kezeléséhez szükségesek (amire a kernelnek bármikor szüksége lehet). Pl. folyamat alapvető azonosító adatai. Folyamat PID-je, szülőazonosító, stb. Folyamat ütemezésével kapcsolatos adatok, mi a folyamat aktuális futási állapota, mennyi a prioritása, prioritás kiszámolásához szükséges adatai, stb. Memóriakezelési adatok: folyamat memórialapjai bent vannak a memóriában, vagy épp kint vannak a háttértáron. Az u-terület címe, stb. >>> proc struktúra adatai: a process tábla egy eleme (ez a klasszikus rendszereknél ténylegesen egy tábla volt, ma bonyolultabb, pl. láncolt listás megvalósítás). A kernel címterének része. A kernel bármikor elérheti őket.
</div>

====Adminisztratív adatok: Milyen adatstruktúrá(k)ban és milyen címter(ek)ben található(k) a folyamatok adminisztratív adata(i)?====
<div class="answer">
A folyamat futása során szükséges adatok az u-területen, mely a folyamat címterének része, illetve a folyamatok kezeléséhez szükséges adatok a proc struktúrában, mely a kernel címtér része.
</div>

====Adminisztratív adatok: Sorolja fel a UNIX folyamatok legalább 4 alapvető adminisztratív adatát!====
<div class="answer">
* PID (Process ID): egyedi, a folyamatot azonosító szám (PPID: szülő folyamat azonosítója)
* A folyamat állapota (fut, alszik, stb.; ütemezési információk (prioritás, CPU használat, nice érték) )
* Hitelesítők (UID, GID: a kapcsolódó felhasználó adatai)
* Memória-kezelési adatok (címleképezési térkép)
* Kommunikációs adatok (fájlleírók, jelzés információk)
* Statisztikák (erőforrás használat (számlázáshoz) )
</div>

====Alvási prioritás: UNIX alvási prioritásának ütemezését mi végzi?====
<div class="answer">
Az alvási prioritást is az ütemező határozza meg, az alapján, hogy mire várakozik a folyamat, vagyis miért hajtott végre sleep() rendszerhívást. Kernel módban az ütemező nem veheti el a futási jogot, ezért amíg nem hajt végre sleep() hívást, addig nincs is szükség a prioritásának meghatározására.
</div>

====Android: Az Androidban mikor és miért (adjon jellegzetes példát) terminálható egy alkalmazás?====
<div class="answer">
Az alkalmazás erőforráshiány miatt bármikor terminálható, ezt az operációs rendszer automatikusan meg is teszi. Példa: ha nincs elég memória.
</div>

====Belső szerkezeti elemek: Sorolja fel a UNIX operációs rendszer főbb belső szerkezeti elemeit!====
<div class="answer">
* betöltő
* virtuálismemória-kezelő
* állományrendszer
* blokkos berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: lemezegység, szalagos meghajtó)
* karakteres berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: hálózat, nyomtató)
</div>

====Csővezeték (pipe): Írjon le egy olyan konkrét UNIX shell parancssort, amely csővezetéket alkalmaz!====
<div class="answer">
ls -la | more
</div>

====exec(): Mire szolgál a UNIX exec() rendszerhívás?====
<div class="answer">
exec(): új programkód betöltése egy folyamat címterébe
Azaz a fork() paranccsal létrehozunk egy új folyamatot, exec() paranccsal pedig betöltjük a folyamatba a kódot.
</div>

====Fájl-attribútumok: Sorolja fel a fontosabb UNIX fájl-attribútumokat!====
<div class="answer">
* Típus
* Linkek
* Eszköz, inode, méret...
* Időbélyegek
* Azonosítási és hozzáférés-szabályozási adatok
</div>

====Fájlrendszeri bejegyzések: Sorolja fel a UNIX fájlrendszeri bejegyzések alapvető tulajdonságait (legalább hármat, ls -l oszlopok)!====
<div class="answer">
* pl.: drwxr-xr-x 2 root root 4096 dec 22 12.27 txt
* sorrendben: I. UNIX-fájltípusok (pl. közönséges fájl (-), katalógus (d), szimbolikus link (l), stb.), II. hozzáférési jogosultságok (3*3-as bontásban - 1. hármas csoport a tulajdonos, a 2. a csoport, a 3. a többiek jogosultságait; 'r' az olvasás (read), a 'w' az írás (write), az 'x' pedig a végrehajtás (execute) jele), III. jogosultságok után egy szám áll (ez könyvtárak esetén azt mondja meg, hogy az adott könyvtár hány elemet tartalmaz, fájlok esetén azt tudhatjuk meg, hogy az adott fájlra hány hardlink mutat), IV. tulajdonos, V. méret (bájtokban), VI. utolsó módosítás dátuma, VII. fájl neve
</div>

====Felfüggesztett állapotok: Mik azok a felfüggesztett állapotok, mi a szerepük a UNIX-ban?====
<div class="answer">
felfüggesztve futásra kész, felfüggesztve alszik állapot A UNIX-ban egyfajta hosszú távú, felhasználói ütemezést jelentenek - a felhasználónak lehetősége van arra, hogy bizonyos folyamatokat a többi állapotból kiemeljen. Pl. Ctrl+Z billentyűkombinációval felfüggesztem a folyamatok futását. Innen valamikor visszahelyezzük futó állapotba.
</div>

====Felhasználói mód, kernel kontextus: UNIX esetén milyen tevékenység zajlik felhasználói módban, kernel kontextusban?====
<div class="answer">
Semmilyen!!
Megj.: Kernel kontextusban, felhasználói módban a program saját utasításait hajtjuk végre, a program saját adataival dolgozunk. Ennél fogva itt nincs értelme beszélni semmiről, mert a folyamat a kernel kontextusában nem hajthat végre semmit.
</div>

====Felhasználói módból kernel módba váltás: Hogyan vált egy UNIX folyamat felhasználói (user) módból kernel módba?====
<div class="answer">
Rendszerhívásokon keresztül.
</div>

====Felhasználói módú prioritás: Sorolja fel milyen tényezők határozzák meg egy UNIX folyamat felhasználói módú prioritását (tradicionális UNIX ütemező esetén)!====
<div class="answer">
* Korábbi CPU-használat
* Futásra kész folyamatok száma (p_cpu "öregítésével")
* nice érték (nice és renice parancsok)
</div>

====Folyamatok állapotai: Milyen állapotai vannak a UNIX-folyamatoknak?====
<div class="answer">
# kiinduló állapot
# futásra kész
# kernel módban futó állapot
# felhasználói módban futó állapot
# alvó állapot
# zombi állapot
# felfüggesztve alszik
# felfüggesztve futásra kész

Ctrl+Z-vel felfüggesztett állapotba helyezem a folyamatot.
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 UNIX folyamatok között kommunikációs megoldást!====
<div class="answer">
* System V IPC: szemafor, osztott memória, üzenetsor
* Csővezeték és nevesített csővezeték
* Jelzések
* RPC
* Folyamat-nyomkövetés
* Szemaforok
* Üzenetsorok
* Osztott memória
* Hálózati, socketeken keresztüli kommunikáció
</div>

====Folyamatok közötti kommunikáció: Soroljon fel UNIX folyamatok közötti adatátviteli eszközöket (legalább hármat)!====
<div class="answer">
* System V IPC: - szemaforok, - üzenetsorok, - osztott memória
* Jelzések: - aszinkron események keltése és kezelése
* Csővezetékek, nevesített csővezetékek: - FIFO kommunikáció a "rokonságban"
* Szemaforok: - a korábban megismert szinkronizációs megoldások
* Üzenetsorok: - diszkrét, típusos üzenetek folyamatok között
* Osztott memória: - azonos fizikai memóriaterület használata több folyamatban
* "hálózati" (socket) kommunikáció: - címzéssel és protokollokkal támogatott kommunikáció
* TODO
</div>

====fork(): Mire szolgál a fork() rendszerhívás?====
TODO: rövidíteni.

Új folyamat létrehozására. A fork() hívásakor az aktuális folyamat, amely kiadta a rendszerhívást, megduplázódik (minden adata, verme, memórialapja, stb.), onnantól két példányban fog továbbélni, amelyek egymással szinte tökéletesen megegyeznek, kvázi klónozva van a folyamat, néhány apró különbség van csupán. De valójában a memóriaszervezés ügyes trükkje: semmit nem csinál azonkívül, hogy bizonyos adminisztratív adatokat megdupláz, ténylegesen nem másol semmit (memórialapokat)! Az így megduplázott folyamat memórialapjaihoz hozzárendel még egy folyamatot, és megjegyzi azt, hogy amíg ezek a folyamatok békésen tudnak egymás mellett dolgozni, addig dolgozzanak ugyanazon, de ha konfliktus van, akkor majd lemásoljuk ezeket a memórialapokat.

Ha a fork() hívás 0-val tér vissza: a gyerek folyamat kódja fut tovább. Ha egy negatív számmal tér vissza, fork() hiba történt, nem tudtuk létrehozni az új folyamatot, le kell kezelni. Ha pozitív számot adott vissza, akkor az eredményben a gyerekfolyamat azonosítója található, itt a szülőfolyamat fut tovább.

Gyerek folyamat fut: az exec() az aktuális folyamat helyére betölt egy másik binárist. Az exec()-et meghívó folyamatnak az exec() kitörli a saját kontextusát, stb., betölt egy új programkódot, amit elkezd végrehajtani. (Kvázi mintha elindítana egy új folyamatot, de a folyamat már fut.) Ha nem sikerült betölteni a binárist (pl. nincs ilyen fájl), akkor hiba, visszatér az exec() is, egyébként nem: az új programkód utasításait hajtjuk végre.
Tehát folyamat létrehozása UNIX-ban két lépésben:
# fork() rendszerhívás = folyamatduplázás, majd
# a gyerekfolyamat helyére az új programkód betöltése exec() hívással.
Modern UNIX-okban fork() már nem igazán (más rendszerhívásokat használ).

====fork(): Miért van szükség a fork() rendszerhívásnál a folyamat megduplázására?====
<div class="answer">
TODO
</div>

====Futási/végrehajtási mód: Mi az a futási mód?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv, 00:17:00 környéke alapján
TODO - rövidíteni
A folyamatok a kerneltől teljesen különválasztva működnek (rendszerhívás interfészen keresztül kommunikálnak a kernellel). A végrehajtási mód azt határozza meg, hogy a kernel vagy a folyamat feladatait hajtja végre az OS.
Két mód: kernel ("privilegizált, védett") mód, valamint felhasználói ("szabad") mód.
Kernel módban a védett (kernel) tevékenységeket, felhasználói módban a folyamat programkódját hajtja végre az OS.
Példa: egy webböngésző a tevékenysége egy részében a saját feladatát hajtja végre, pl. HTML-kódot értelmez és jelenít meg, valamint vannak olyan tevékenységek, amelyek ahhoz kellenek, hogy ezt a feladatát végrehajtsa: hálózati kommunikáció, fájlrendszer-műveletek, stb. - ezek kernel tevékenységek.
Kernel módban privilegizált utasítások hajtódnak végre, pl. egy eszközt kezelünk, vagy hozzányúlunk a háttértárhoz, onnan valamit beolvasunk, oda valamit kiírunk. Ilyen utasításokat egy felhasználói módban futó folyamat nem hajthat végre, hiszen ha közvetlenül hozzáférne a hardverekhez, akkor akár adott esetben a teljes rendszer működését felboríthatná.
Felhasználói módból kernel módba átlépéskor átlépünk egy védett módba, így olyan feladatokat is végrehajthatunk, amit egyébként tilos.
</div>

====inode: Mi a UNIX inode?====
<div class="answer">
* A fizikai állományokhoz tartozó leíró, azonosító
* minden file-hoz tartozik egy inode állomány amiben a file minden tulajdonsága megtalálható (azonosító,leíró)
</div>

====Kernel mód, folyamat kontextus: Milyen tevékenység zajlik kernel módban, folyamat kontextusban?====
<div class="answer">
Kivételek, rendszerhívások kezelése, rendszerhívások végrehajtása.
Amikor a folyamat végrehajt egy rendszerhívást, a felhasználói módból átlép kernel módba, hiszen a rendszerhívás belsejében olyan tevékenységeket szeretne végrehajtani (beolvasni vmit egy fizikai eszközről, hálózatról, más folyamattal kommunikálni, elindítani másik folyamatot, stb.), amelyhez kernel utasítások végrehajtása tartozik.
</div>

====Kernel mód, kernel kontextus: Milyen tevékenység zajlik kernel módban, kernel kontextusban?====
<div class="answer">
Rendszerfeladatok, megszakítások kezelése. Kernelfolyamatok.
</div>

====Kernel módú prioritás: Mi határozza meg a UNIX folyamatok kernel módú prioritását a tradicionális UNIX ütemezésben?====
<div class="answer">
A kernel módban futó folyamat prioritása statikus, nem függ attól, hogy a folyamat mennyit használta a CPUt, vagyis mennyi ideig futott. A prioritás attól függ, hogy a folyamat milyen ok miatt hajtott végre sleep rendszerhívást, vagyis, hogy milyen eseményre várakozik. Emiatt a kernel prioritást szokták alvási prioritásnak is nevezni.
</div>

====Kernelszolgáltatások elérése: Milyen interfészen keresztül érhetők el a UNIX kernel szolgáltatásai?====
<div class="answer">
* System Call Interface
* Az alkalmazások a rendszerkönyvtárakat hívják meg, amelyek szükség szerint meghívják az operációs rendszer szolgáltatásait ??
</div>

====Kontextus: Mi az a kontextus?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv alapján.
TODO: rövidíteni.
Az a környezet, amiben végrehajtjuk az utasításokat. Ez is különbözik a kernelek és folyamatok esetén: folyamat kontextusban azokkal az adatokkal és utasításokkal dolgozunk, amelyek alapvetően a folyamat célját szolgálják, kernel (rendszer vagy megszakítás) kontextusban pedig kernel feladatokat hajtunk végre, és az ezekhez a feladatokhoz szükséges adatokkal dolgozunk.
Kernel kontextus: érkezik egy hardveres megszakítás, ennek kezelése itt zajlik.
Folyamat kontextus: a folyamattal kapcsolatban hajtunk végre tevékenységeket.
Nem uaz, mint a végrehajtási mód, mert lehetséges az, hogy bizonyos tevékenységeket kernel módban hajtunk végre, de folyamat kontextusban. Amikor hozzá kell férnünk egy folyamat futási adataihoz, veremhez, virtuális memóriájához, stb., a programnak az adminisztratív adatait kezeljük, ezek folyamat kontextusban találhatóak.
</div>

====Környezeti adatok: Mik azok a környezeti adatok egy UNIX-folyamatnál?====
<div class="answer">
A folyamat indításakor megörökölt tulajdonságok. Tulajdonság-érték párok. Pl. a felhasználó bejelentkezik; mi az ő neve. A felhasználó milyen terminált használ, annak milyen képességei vannak. Mi a felhasználó shellje. Az épp futó folyamat néhány tulajdonsága. Olyan tulajdonság, amely egyes folyamatok számára értéket jelentenek. A felhasználók ezeket a set, setenv, export parancsokkal tudják ezeket állítani (és le is kérdezhetik őket). Megörökli az őt elindító folyamat környezetét (hogy melyiket kell épp használni, UNIX-variánstól függ). Amikor a felhasználó bejelentkezik, akkor a környezeti változók beállítódnak, a folyamatok induláskor ezeket a beállításokat megöröklik.
</div>

====libc: A libc-nek mi a feladata rendszerhívások kezelésében?====
<div class="answer">
A felhasználói mód és kernel mód közötti átmenet lebonyolítása.
A folyamat csak meghív egy open(), read(), write(), stb. függvényt, valójában a háttérben bonyolultabb tevékenység zajlik >> meghív egy rendszerhívást a rendszerhívás interfészen keresztül. A rendszerkönyvtárak egyike a libc, a standard C library, ez felel azért, hogy az adott függvényhívásokat (mint a read()) leképezze arra a mechanizmusra, amin keresztül átlépünk kernel módba.
Az implementáció belsejében van egy SYSCALL utasítás (ez hardverfüggő), ez ténylegesen elvégzi az üzemmódváltást egy speciális megszakítás generálásával, aminek eredményeként a CPU átlép védett módba. A kernel pedig kezeli ezt a megszakítást. Ekkor a kernel a CPU regisztereit elmenti, azért, hogy a folyamat futása visszaállhasson a megfelelő állapotba. A feladat végeztével a kernel visszatér a megszakításból (erre is hardverfüggő a megvalósítás), a CPU visszavált felhasználói módba, a libc pedig visszatér a függvényhívásból, amit a folyamat kiadott.
</div>

====/proc: Mi a /proc?====
<div class="answer">
Speciális fájlrendszer-interfész a kernel-adatstruktúrákhoz való hozzáféréshez.
</div>

====Prioritás: Hogyan számítható ki egy kernel módban futó UNIX folyamat prioritása?====
<div class="answer">
* a prioritást a folyamat elalvásának oka határozza meg, tehát a prioritás attól függ, milyen sleep utasítással ment át alvó állapotba
* alvási prioritás pl: 20 - diszk I/O-ra vár; 28 - inputra vár a karakteres terminálról
* kernel módú folyamatoknak (amelyek rendszerhívásokat intéznek) negatív prioritásértékeik vannak, ezeknek van a legmagasabb prioritása ........... (http://home.mit.bme.hu/~meszaros/edu/oprendszerek/segedlet/unix/2_folyamatok_es_utemezes/unix_processes.pdf)
* Több szinten, több időléptékben zajlik. Óraütésenként a prioritási sorok ellenőrzése. 10 óraütésenként RR ütemezés egy soron belül. 100 óraütésenként a prioritások újraszámítása.
</div>

====Rendszerhívások: Igaz-e, hogy a rendszerhívások megszakítással járnak együtt?====
<div class="answer">
Igen, ennek hatására vált védelmi szintet a processzor.
</div>

====Rendszerhívások kontextusa: Milyen kontextusban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
folyamat kontextusban
</div>

====Rendszerhívások módja: Milyen módban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
kernel módban
</div>

====Rendszerhívások módja, kontextusa: Milyen futási módban és kontextusban zajlik a UNIX rendszerhívások kiszolgálása?====
<div class="answer">
Kernel módban fut a kód, és a rendszert hívó folyamat kontextusában. ((az ehhez tartozó ábra jobb felső része))
</div>

====Rendszerhívások programindításkor: UNIX alatt milyen rendszerhívásokra van szükség, ha a felhasználó elindít egy programot (folyamat létrehozása és programkód betöltése)?====
<div class="answer">
* Folyamatot létrehozni a fork() hívással, majd a programkódot betölteni az exec() hívással lehet.
</div>

====rpcgen: Mi az rpcgen program feladata?====
<div class="answer">
* RPC nyelven készült leírásból C programkódot generál. [?]

* Az RPC nyelv alkalmas a szerver interfészének formális leírására. A formális leírásból az rpcgen program képes a szerver és a kliens programok megfelelő részeit, valamint a szükséges XDR konverziós függvényeket elkészíteni C nyelven. Az így kapott C forráskódú modulokat a kliens és szerver alkalmazással kibővítve kapjuk a teljes kommunikáló rendszert.
* XDR (Extended Data Representation, kiterjesztett adatreprezentáció): Többféle egyszerű adattípust definiál, illetve szabályokat határoz meg bonyolultabb adatstruktúrák létrehozására. Az adatstruktúrák meghatározásán kívül az XDR egy formális nyelvet is bevezet az adatok leírására. Az RPC rendszer is ezen nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
* RPC (remote procedure call, távoli eljáráshívás): Az RPC-rendszer egy protokoll-leírást és egy programozói interfészt tartalmaz. Az XDR által definiált formális nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
</div>

====System V IPC: Sorolja fel a UNIX System V IPC elemek közös alapjának részeit!====
<div class="answer">
Minden IPC erőforrás rendelkezik a következő azonosítókkal: kulcs (key), létrehozó (creator), tulajdonos (owner), hozzáférési jogok (permissions)
</div>
====System V: Adja meg a System V üzenetsorok főbb jellemzőit (tömör felsorolást kérünk)!====
<div class="answer">
* diszkrét, tipizált üzenetek
* nincs címzés, üzenetszórás
</div>

====System V: Miért tud az s5fs (System V File System) gyorsabban írni, mint olvasni (az előadás példája alapján)?====
<div class="answer">
* az írás gyors, főleg kis fájlok esetén (több szintű leképzés a kisebb blokkkok miatt), az olvasás azért lassabb (csak a nagy fájlokra), mert azoknak a részeit össze kell vadászni a szétszórtság miatt
* TODO
</div>

====u-terület: milyen jellegű adminisztratív adatok vannak az u-területen?====
<div class="answer">
Azok az adatok, melyek a folyamatok futásakor kellenek. Több infó: lásd adminisztratív adatoknál.
</div>

====UNIX-fajták: Soroljon fel fő UNIX-fajtákat!====
<div class="answer">
Linux, Solaris, BSD, System V, HP/UX, ...
</div>

====UNIX-szabványok: Soroljon fel UNIX-hoz köthető szabványokat (legalább kettőt)!====
<div class="answer">
* POSIX.1 (teljes nevén: POSIX1003.1): C nyelvű szabványos rendszerhívás-interfész
* System V Interface Definition
* X/Open Portability Guide
* - AT&T SVID (pl. SVR4), - IEEE POSIX, - Open Group X/Open, Unix95, Unix98, ... ????
* http://linux.die.net/man/7/standards
</div>

====UNIX-típusok: Soroljon fel UNIX típusokat (a családfa jellemző ágait)!====
<div class="answer">
* System V (AT&T változat; Solaris, SCO),
* BSD (Berkeley változat; SunOS, OpenBSD)
</div>

====Ütemezés: Adja meg a tradicionális UNIX ütemező három legjellemzőbb tulajdonságát!====
<div class="answer">
* preemptív, prioritásos és időosztásos
(Néhány kiegészítés a UNIX-ütemezőhöz:
* nem preemptív kernel módban (a kernel módot végrehajtó folyamatot (pl. rendszerhívás, megszakítás-kezelés) nem lehet kényszeríteni, hogy a CPU használatáról lemondjon egy nagyobb prioritású folyamat javára)
* újraütemezés csak akkor következik be, ha egy folyamat önként lemond a CPU-ról és sleep rendszerhívást hajt végre, vagy a folyamat kernel módból visszatér user módba Nem méretezhető megfelelően. Az algoritmus nem képes rugalmasan alkalmazkodni a folyamatok számának növekedése esetén. A korrekciós faktor nem elég hatékony eszköz.
* A CPU-t adott esetben nem lehet "kiosztani" adott folyamat számára. Nem garantálható fix válaszidő. Nagy rendszerterhelés esetén a válaszidő megnőhet. A UNIX ütemezés épp ezért nem alkalmazható real-time rendszerekben.
* A kernel nem preemptív, ezért az egész rendszert feltarthatja. A felhasználó nem tudja megfelelő módon befolyásolni folyamatai prioritását - a nice szám nem megfelelő eszköz erre a célra.)

</div>

====vfs: Mondjon legalább egy, UNIX VFS-alapú "fájlrendszert", amelynek a célja nem fájlok tárolása!====
<div class="answer">
/dev, /proc, stb.
</div>

====vfs: Soroljon fel UNIX VFS-alapú fájlrendszereket (legalább négyet)!====
<div class="answer">
xfs, zfs, brtfs, nfs
</div>

====Virtuális rendszerhívás: Mi az a virtuális rendszerhívás, miért van rá szükség?====
<div class="answer">
(Klasszikus UNIX-ban nincs, Linux 2.5.x-től felfelé, mai Linux kernelek aktívan használják.)
Vannak bizonyos egyszerű feladatok, amelyek a feladat egyszerűsége ellenére túl sok felesleges művelettel járnak: rendszerhívás intterrupt, kontextusváltás, stb., ezen a helyzeten szeretnénk javítani - próbáljuk lerövidíteni ezt az utat.
Pl. a pontos idő lekérdezése csupán egy megfelelő hardver kiolvasása (egyszerű numerikus érték), mégis sok művelettel jár: gettimeofday(): libc > SYSCALL > kontextusváltás > ..., majd ugyanezen a lépcsőn visszasétálunk a felhasználói folyamatba.
Persze nem mindig lehet leegyszerűsíteni ezt az utat, csak egyszerűbb és biztonságos esetekben, pl. ha egyszerű numerikus értékek, azonosítók kiolvasásáról van szó: pl. folyamatnak mi az azonosítója, processzor lekérdezése, pontos idő lekérdezése...Tehát a felhasználói módból kernel módba történő hosszas váltást szeretnénk elkerülni. Ha nincs ilyen módváltás, akkor a felhasználói címtérben elérünk egyes kernelterületeket > így tényleg egyszerű függvényhívás lesz. Megfelelő előfeltételekkel: csak kockázatmentes feladatokra. Időlekérdezés tipikusan ilyen, ott megtehetjük.A felhasználói címtérben az a tevékenység, amelyet szeretnénk végrehajtani, elérhető legyen. Ezt oldják meg a virtuális rendszerhívások!
A folyamat címterébe a kernel rendszerinduláskor speciális "kernellapot" allokál - ezen a biztonságosnak tekinthető rendszerhívások vannak. Terminálból példa: ldd /bin/bash
</div>

====vnode/vfs: Mi a UNIX vnode/vfs?====
<div class="answer">
* Implementáció-független fájlrendszer absztrakció
* vnode: virtuális csomópont, vfs: virtuális állományrendszer
* inode --> vnode
* fs --> vfs
* Új absztrakció: annak felismerése, hogy több állományrendszernek számos előnye van, szükségessé vette a virtuális csomópont (vnode) és a virtuális állományrendszer (vfs) leíró adatszerkezetek bevezetését. Követelmények, elvárások az állományrendszerrel kapcsolatban:
** egyszerre támogasson több - UNIX, nem UNIX - állományrendszert
** különböző diszk partíciók különböző állományrendszereket is tartalmazhatnak, de mountolás esetén egységet képet kell, hogy mutassanak
** támogassa a hálózati állományok osztott használatát
** modulárisan bővíthető legyen.
</div>

====Zombi állapot: Mi a zombi állapot szerepe egy UNIX rendszerben?====
<div class="answer">
A folyamat már felszabadította a foglalt memóriát, lezárta az állományokat, minden erőforrását visszaadta a rendszernek, csak a proc struktúráját tartja fogva, amiben visszatérési és statisztikai információt tárol a szülő számára. A folyamat szülő wait hívása után szűnik meg.

Megjegyzés: bővebben magyarázattal, előadás alapján:
A folyamat megáll, a UNIX-ban a kernel szeretné ezt a szülőjének is tudomására hozni.
A folyamat már leállt, nem fog tovább futni, de a szülőjét még nem értesítették arról, hogy ez a folyamat megszűnt, esetleg gondoskodjon az újraindításáról, stb.
Pl. egy webszerver: beérkező kérések kiszolgálása --> kliens folyamat indítása, ez megkapja a kérés kiszolgálásának feladatát, a kliens pedig valamikor megáll, a webszerver nem árt, ha értesül róla, hogy hiba vagy normál működés folytán állt le.
Tehát amíg a szülő nem értesült a leállásról, a folyamat zombi állapotban marad. Ha a szülőt nem érdekli, mi történt a gyerekfolyamattal, a zombi állapot hamar megszűnik.
A zombi állapotban a folyamatnak semmilyen saját adatát nem tároljuk, a folyamat összes működéshez szükséges adata megszűnik, kizárólag a kernel adatstruktúrákban, tehát a proc struktúrában marad meg a folyamatnak néhány adminisztratív adata. A ps kilistázhat pl. zombi állapotban lévő feladatokat, mert ezeknet a folyamatoknak az adminisztratív adatai a kernel címterében még megtalálhatóak. De a folyamatok saját címtere, u-terület, stb. már nem létezik. Miután a szülő értesült róla, hogy a gyerekfolyamat meghalt, a kernel törölni fogja a folyamatot a process táblából is, a folyamat kilép a zombi állapotból.
</div>

====Zombi állapot: Igaz-e az, hogy egy zombi állapotban lévő folyamat még memóriaterületet foglal?====
<div class="answer">
Igen, mert a kernel processz táblában még ott vannak az adatai, és az memóriaterületet foglal. (A NEM választ is meg lehet indokolni...) [Indoklás nélkül 0 pont!!!]
</div>

===Windows===

====Alrendszer: Melyik az az alrendszere a Windowsnak, ami nélkül nem tud futni?====
<div class="answer">
A Windows alrendszer, avagy Client/Server Runtime [[SubSystem]] (csrss.exe). Ennek kilövése kékhalált eredményez.
</div>

====API-k: Hogyan oldották meg, hogy az alkalmazások többféle API-n (Win32, POSIX) keresztül is meg tudják hívni a Windows operációs rendszer funkcióit?====
<div class="answer">
* Megoldás: környezeti alrendszerek (environment subsystems): a felhasználónak vagy programozónak nyújtott környezet, személyiség egy részét a környezeti alrendszer folyamatok valósítják meg, minden egyes környezet külön API-t mutat (Windows, POSIX, ...), az operációs rendszer rendszerhívásainak egy részét kínálja a felhasználói alkalmazások számára. (Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx)
* a kernelnek egy definiált interfésze van, ami nem publikus (hivatalos dokumentációja nincsen): NT API >> az ebben lévő függvényeket a fejlesztő ne hívhassa meg közvetlenül. Ehelyett erre két alrendszer épül, ők mutatnak egy API-t az alkalmazások felé: Windows API és POSIX API. (ezek teljesen dokumentáltak!). Az alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni.
* A két alrendszer feladata az, hogy az általuk definiált hívásokat átfordítsák.
* Nem pusztán szintaktikai, hanem szemantikai eltérések is vannak.

(Megjegyzés: Exetype segédeszköz segítségével megnézhető, melyik alrendszert használja egy adott alkalmazás.)

Forrás: http://video.bme.hu/media/video/Operacios_Rendszerek_04ea_20110215.wmv (00:28:29 körül)

(Korábbi:
* Alkalmazás 1>>>Windows API (Windows alrendszer)>>>NT API (NT Kernel)<<<Posix API (Posix alrendszer)<<<Alkalmazás 2 TODO(ehelyett 1 épkézláb mondat kéne)
* alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni
)

</div>

====Executive réteg: Executive (Windows)====
<div class="answer">
Az operációs rendszer magasabb szintű funkcióit szolgáltató rétege (memóriakezelés, biztonság, stb.). Az adatokat objektumokban tárolja, melyeket leírókkal (handle) lehet csak elérni, jól definiált interfészeken keresztül. Bár a kernel funkcióit csak a kernel interfészén keresztül éri el, szintén az ntoskrnl.exe tartalmazza. A legtöbb rendszerhívás itt van megvalósítva.
Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx

(Korábbi: Ez a réteg tartalmazza az NTDLL.DLL által definiált függvények hívásainak megvalósítását, valamint a rendszer külső objektumai közti kommunikáció. Legfontosabb szolgáltató funkciója a lokális eljárás hívás - LPC (Local Procedure Call) megvalósítása. TODO[MZ])
</div>

====Fájlhozzáférések: Mivel azonosítja a Windows a felhasználókat és csoportokat a fájlhozzáférési listákban?====
<div class="answer">
* objektum (SecurableObject) → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* SecurityDescriptor (biztonsági leíró, összefogja a többi elemet) >> Owner (Tulajdonos, megváltoztathatja az objektum engedélyeit, akkor is ha nincs explicit joga), Discretionary Access Control List (DACL, belátás szerinti, erőforrás szintű, hozzáférési lista - hozzáférés szabályozása), SACL (biztonsági naplózás szabályozása - kinek milyen művelete esetén kell naplózni az adott műveletet)
* AccessControlEntry:
** Típus: megengedő, tiltó, audit
** Flag: Pl. öröklődés
** SID: kire vonatkozik
** Maszk: végrehajtás | törlés tulajdonos írása...
* elérési lista (ACL), melyben megadható, hogy mely folyamatok jogosultak az adott section object elérésére ???
* minden objektumhoz tároljuk a hozzá tartozó <tartomány, műveletvégzési jog> párokat ????
* TODO - bőven elég annyi, hogy Security Identifier (SID) segítségével azonosítja
</div>

====Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a felhasználókat és a csoportokat?====
SID - Security Identifier

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
<div class="answer">
Paravirtualizáció esetén fel kell készíteni a vendég OS-t a forráskódjának módosításával, hogy ne is akarjon problémás utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. Ezzel egyszerűsödik a hypervisor implementálása.
</div>

====Felhasználó- és csoportazonosító: Mivel azonosítja a Windows a felhasználókat és csoportokat a hozzáférések ellenőrzése során?====
<div class="answer">
* <Gép SID>-<RID> (SID security identifier - gépspecifikus, RID: relative identifier)
* Jól ismert SID-ek: Everyone: S-1-1-0, Administrator: S-1-5-domain-500
* Vista: szolgáltatások is kapnak SID-et
* objektum → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* TODO
</div>

====HAL: Mi a HAL (Windows)?====
<div class="answer">
* "HAL" - Hardware Abstraction Layer
* A felsőbb rétegek a HAL-on keresztül érik el az alap HW szolgáltatásokat, a HAL szerepe, hogy elfedje a HW megvalósítás részleteit, és egy egységes, platformfüggetlen felületet biztosítson.
* hal.dll fájlban megvalósítva (pl. timer interrupt kezelését, alaplap alapvető felépítését (milyen chipsetek vannak rajta), stb. elfedi a felette lévő rétegektől)
</div>

====Hardverfüggő részek: Melyek a Windows hardverfüggő részei?====
<div class="answer">
* A kernel egyes részei és a HAL.
* Megjegyzés: én ide a drivereket is beírtam, nem vontak le érte pontot, de azt mondták, azokat nem mindig szokás a rendszer részének tekinteni.
</div>

====Jogosultságok szerepe: Mik a jogosultságok (privilege) szerepe a Windows-ban?====
<div class="answer">
* operációs rendszer szintű jog
* meghatározzák azokat a rendszerműveleteket, amelyeket egy felhasználói azonosító elvégezhet. Egy rendszergazda jogosultságokat felhasználóknak és csoportazonosítóknak oszt (http://msdn.microsoft.com/en-us/library/bb530716(VS.85).aspx)
* pl. számítógép leállítása, eszközmeghajtó betöltése
* név: SeShutDownPrivilege, SeLoadDriverPrivilege
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens/Képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerülése: Mi a fő oka, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerültek? Elméleti megfontolások alapján hol lenne a helyük?====
<div class="answer">
Windows NT 4.0-ban került le kernel szintre ez a komponens, hogy kevesebb folyamat- és módváltás legyen (Ne kelljen mindig visszaváltani a csrss.exe-be, majd onnan átváltani kernel módba, utasítani a hardvert, visszaváltani felhasználói módba, majd visszaváltani a felhasználói folyamatba, aki kezdeményezte a változtatást.) (A felhasználói módú folyamatban (csrss.exe) csak a konzol kezelés maradt.) Elméletileg felhasználói szinten kéne lennie.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Windows-ban miért került le az ablakkezelő kernel módba?====
<div class="answer">
Hogy kevesebb kontextus- és módváltás legyen, mivel a Windows szerves része az ablakkezelés, ezért rengeteg user-kernel mód váltás lenne ha a csrss.exe-en keresztül használnánk. Tehát teljesítménybeli okokból.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens előnyei: A Windows OS grafikus komponensének mik az előnyei, hátrányai?====
<div class="answer">
A grafikus komponens kernel módban fut. Emiatt a hibái az egész rendszert magával ránthatják, viszont gyorsabb, mert kevesebb CPU-mód váltás kell a rajzoláshoz.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Mi volt a fő oka annak, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító komponens kernel módba került?====
<div class="answer">
Mert ezek a folyamatok intenzíven használják a hardvert, és futásuk gyorsaságára az egész rendszer teljesítménye érzékeny. A user módban történő megvalósítás a rendszert lelassítaná a gyakori környezetváltás miatt.
</div>

====Kernel: Mi a kernel (Windows)?====
<div class="answer">
A rendszer állandóan memóriában lévő, védett módban futó része. Az NT egyetlen HW függő része, szerepe a HW elfedése a felette található eszközök elől, ezáltal a felette lévő részek már teljesen HW függetlenek. Megvalósítja a szálütemezést, multiprocesszor ütemezést és a TRAP kezelést.
</div>

====Kliens-szerver-modell: Nevezzen meg egy kliens-szerver-modell alapján működő komponenst az NT-ben!====
<div class="answer">
* csrss.exe - Client/Server Run-Time Subsystems (környezeti alrendszerek)
* TODO
</div>

====Memóriafoglalás: Mely utasításokkal és miért történik a memóriafoglalás két lépésben Windows alatt?====
<div class="answer">
* A két lépés: Reserve és Commit. Az első csak címtartományt foglal, amögött nem lesz ténylegesen használható memóriaterület; a másik a már lefoglalt címtartományhoz rendel (virtuális) memóriát.
* A folyamatok címtartományának töredezettsége csökkenthető azzal, ha a címtartományt már akkor előre foglalja, mikor a memóriára még nincs szüksége, és ez nem jár olyan memóriapocsékolással, mintha fizikai memóriát is foglalna ugyanakkor.
</div>

====Munkakészlet (working set): Mit jelent a Windows-ban az egy folyamathoz tartozó munkakészlet (working set) fogalma?====
<div class="answer">
Azon fizikai lapok halmaza, amelyekre a folyamat laphiba nélkül hivatkozhat.
</div>

====NT hardverfüggő rétegei: Sorolja fel az NT hardverfüggő rétegeit!====
<div class="answer">
HAL (Hardware Abstraction Level), kernel
</div>

====NTDLL.DLL: Mi az NTDLL.DLL fő funkciója?====
<div class="answer">
Összeköti a User és Kernel módot. Az Executive függvényeknek megfelelő függvénycsonkok vannak benne.
</div>

====Quantum: Mi a szerepe a quantumnak a Windows ütemezőjében?====
<div class="answer">
* A szálak adott ideig futnak (quantum)
* RR ütemezésnél az időszelet
* Óramegszakításban mérik (clock interval, clock tick) 1 clock tick = ~ 10-15 ms (HALtól függ)
* Quantum hossza: időegység, amíg egy szál fut
* Kliensek esetén a quantum hossza 2 clock tick a háttérben futó folyamatoknak, az előtérben futó folyamatoknak 6 clock tick jut. Így egy CPU-intenzív folyamatról való ablakváltáskor az új, előtérben lévő folyamat arányosan több CPU-időt kap (azonos prioritásokat feltételezve).
* Szervereknél: mindenkinek 12 clock tick a kontextusváltások minimalizálása érdekében. Szervereknél így a kliensek kéréseinek eredményeként felébredő alkalmazásoknak több esélye van befejezni a kérést, és várakozó állapotba kerülni, mielőtt az időszelet véget érne.
* esély annak a folyamatnak, amelynek épp most ért véget a várakozása: a várakozás végén megnöveljük a prioritást, de a quantum eggyel csökken; a quantum végén a prioritást az eredetire csökkenti.
* éhezés elkerülése: az OS másodpercenként megnézni a futásra kész szálakat, és annak, aki nem futott már 300 óraütés óta, 15-ös prioritást ad, megnöveli a quantumját egy quantumnyi futásig
* TODO, hogy a forrás feldolgozása jó-e: http://mit.bme.hu/~micskeiz/opre/files/01-opre-windows-utemezes.pptx

</div>

====Rendszeridő megváltoztatása: A rendszeridő megváltoztatására kinek van joga Windows alatt?====
<div class="answer">
* SeSystemTimePrivilege joggal rendelkező felhasználóknak / azoknak a felhasználóknak, amelyek olyan csoportba tartoznak, amelyekhez hozzá van rendelve a SeSystemtimePrivilege.
* Alapértelmezett beállításként csak az Administrators és Power Users group rendelkezik vele.
* http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx
</div>

====Standby memórialapok listája: Mire szolgál a standby memória lap lista a Windows-ban (miért nem szabad lapként vannak ezek nyilvántartva)?====
<div class="answer">
A lap egy munkahalmaz része volt, de már nem az, elvették tőle. A lap nem módosult, mióta kiírták a merevlemezre, vagy mióta beolvasták. Egy nem Valid laptábla bejegyzés még mutat rá, azaz ha kell, még könnyen életre lehet kelteni a lapot.
</div>

====Szabad (free) és nullázott (zeroed) lapok: Miért van a Windows-ban külön szabad és nullázott (freed és zeroed) memórialap-lista?====
<div class="answer">
Biztonsági okokból. Nem nullázott memóriaterületet odaadni más folyamatnak biztonsági kockázatot jelent.
Tehát a free lapok szabad lapok, de még nem adhatók oda felhasználói folyamatnak, mert "szemetet" vagy érzékeny adatot tartalmazhatnak: nincs nullákkal felülírva a tartalma. A zeroed lapok szabadok, és nullákkal vannak felülírva, tehát odaadhatók felhasználói folyamatnak, amennyiben igény van rá.

TODO: ez így már megfelelő indoklás?

(Korábban:
*Free*: a lap szabad, de nincs 0-kkal felülírva a tartalma, szemét vagy egy előző processz által használt tartalom van benne. Ezt nem adhatja ki közvetlenül a memóriakezelő más processzeknek, mert biztonsági szempontból aggályos adatokat találhatna rajta.
*Zeroed*: szabad és nullákkal felülírt lap, kiadható, ha valakinek kell.
TODO(ez így igaz, csak ebben a formában nem a kérdésre válaszol))
</div>

====Mik a szerepük a szolgáltatásoknak a Windowsban? ====
<div class="answer">
Olyan folyamatok, amik a felhasználói felülettől és belépéstől függetlenül a háttérben futnak, és kibővítik az operációs rendszer alap szolgáltatásait.
TODO?
</div>

====Újrahívhatóság (reentrancy): Mit jelent az, hogy a Windows-ban a rendszerhívások újrahívhatóak?====
<div class="answer">
A rendszerhívásokat több alkalmazás is meghívhatja egyszerre, nem blokkolódnak, ha már valakit éppen kiszolgál az adott rendszerhívás.
</div>

====Védett objektum tulajdonosának speciális joga: Milyen speciális joga van egy védett objektum tulajdonosának az adott objektumra a Windows-ban?====
<div class="answer">
Megváltoztathatja az objektum engedélyeit, akkor is, ha erre nincs explicit joga. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/03-opre-windows-biztonsag.pptx)
</div>

====Verzióleírás: Mit jelentenek a számok és szavak a következő verzióleírásban: "Microsoft (R) Windows (R) 5.01.2006 Service Pack 2 Uniprocessor Free"?====
<div class="answer">
* (MZ) 5.01.2006 a verziószám, major.minor.build formában, 5.1 a Windows XP verzója, 2006 az SP2-es verzió build száma. Uniprocessor = egy processzoros kernel verzió, Free = debug szimbólumok nélküli verzió.
*(MZ) 2011-től kezdve ez már nem része a tananyagnak
* Most computers run a "uniprocessor free" version of Windows, which is a version that runs on a single CPU and does not contain extra errorchecking.
</div>



==Tartalomjegyzék==
<div class="table_of_contents">
__TOC__
</div>

==Források (teljesség igénye nélkül)==
<div class="docs_sources">
Ez előadás diáin, Wikipédiás és egyéb, Google-lel található cikkeken kívül ezek voltak a források, és MÉG ÍGY SEM tartalmazza az összes beugrókérdést (volt olyan, amit rengeteg idő lett volna átszerkeszteni, vagy kevésbé sanszos, hogy olyan hosszúságú beugrókérdést tennének fel, ami ott szerepelt):

* Hivatalos előadásjegyzetek: http://portal.mit.bme.hu/?l=oktatas/targyak/vimia219/jegyzet/index.html
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaBeugrok
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaKisKerdesek
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2007junius12megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008majus20megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008junius11megoldas
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/pelda_beugro_megoldas.pdf
----
* https://vir.sch.bme.hu/dokumentumok/InfoSite/4.%20f%C3%A9l%C3%A9v/Oper%C3%A1ci%C3%B3s%20rendszerek/
* https://vir.sch.bme.hu/document/targyak/opre/opre_beugro.zip (HOSSZÚ)
* https://vir.sch.bme.hu/document/targyak/opre/oprendszkidolg.zip
* Wikipédia
* Google segítségével fellelhető rengeteg forrás
* stb.

-- [[PeteHaro|Pete]] - 2011.06.19.
* [[Media:opre_beugro_ABC.docx|Operációs rendszerek vizsgabeugrók megoldással DOCX-formátumban (szerkeszthető, javítható!)]]
* [[Media:opre_beugro_ABC.pdf|Operációs rendszerek vizsgabeugrók megoldással PDF-formátumban]]

[[Category:Infoalap]]

Operációs rendszerek kidolgozott beugrókérdések vizsgára ABC-sorrendben

2015-06-10T11:12:14Z

Bolla Dávid: /* Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához? */

==Bevezető==
Korábbi Wiki-n és InfoSite-on szereplő kidolgozott és kidolgozatlan anyagok, számtalan forrásból összeszedve - előadásdiákból, video.bme.hu-n lévő felvett anyagokból, Wikipédiás és egyéb, Google segítségével fellelhető anyagokból kiegészítve.
Hibák előfordulhatnak! TODO-val azokat a részeket jelöltem, amik átnézendők, rendbe szedendők, hiányosak, stb., ezeket is kérlek javítsátok, ha tudjátok! Köszi!
Ami fontos: ABC-sorrendbe rendezve szerepelnek a kérdések, így könnyebben megtalálható, tartsuk is meg ezt a tendenciát!
Remélem hasznát veszitek! -- [[PeteHaro|Pete]] - 2011.06.19.
Valamilyen szintű kategorizálást is beleraktam. A kérdések elejére odaírtam magának a kérdésnek a lényegét is, hogy könnyebben megtalálhatóak legyenek az azonos kérdéskörbe tartozóak.

==Beugrókérdések megoldással==
===Általános jellegű OS-ekkel kapcsolatos kérdések===

====Indulás: Hasonlítsa össze az általános célú (asztali) és a beágyazott operációs rendszereket az indulás szempontjából!====
<div class="answer">
A beágyazottnál először indul az alkalmazás, és az indítja az operációs rendszert, az asztalinál az operációs rendszer indítja az alkalmazásokat.
</div>

====Inkrementális mentés: Mit jelent az inkrementális mentés?====
<div class="answer">
Csak a változtatásokat mentjük az előző mentéshez képest -> kisebb helyet foglal, hamarabb végez a mentés.
</div>

====Kemény valós idejű rendszer: Adja meg a kemény valós idejű (hard real-time) rendszer definícióját!====
<div class="answer">
A rendszer adott eseményekre adott időn belül 1 valószínűséggel válaszol (egyébként hibás, hiába funkcionálisan jó a válasz). A rendszer NEM késhet!
</div>

====Lazán csatolt rendszer: Milyen szinkronizációs kényszereket jelent, ha egy lazán csatolt rendszer kommunikációja során véges kapacitású csatornát alkalmazunk?====
<div class="answer">
ha a küldő folyamat túl gyorsan küldözget, akkor a csatorna megtelik, úgyhogy túlcsordulás lesz, ami miatt a küldőnek várnia kell mielőtt újra küld.
</div>

====Rendszerhívások: Milyen előnnyel jár a rendszerhívások valamilyen magas szintű programnyelvvel történő megadása?====
<div class="answer">

Az API elrejti a rendszerhívások részleteit, bonyolultságát a programozó elől, lényegében egy wrapper réteggel fedi be a rendszerhívásokat.

</div>

====RPC: Milyen részekből áll az RPC technológia?====
<div class="answer">
* RPC: Remote Procedure Call, távoli eljáráshívás. Magas szintű folyamatok közti kommunikációt tesz lehetővé. Részei:
* a hívható eljárások és típusaik (interfész) leírása
* programgenerátor - rpcgen: a leírásból C programkódot generáló program
* kommunikációs infrastruktúra - portmapper: a programazonosítók és a hálózati portok összerendelése
</div>

====Statikus/dinamikus OS: Mikor nevezünk statikusnak, illetve dinamikusnak egy operációs rendszert?====
<div class="answer">
statikus: azok a rendszerek, amelyeknek muködése során - a felépülés és inicializálás kezdeti szakaszától eltekintve - nem jönnek létre és nem szűnnek meg folyamatok. dinamikus: működés közben bármikor születhetnek illetve megszünhetnek folyamatok.
</div>

====Szorosan csatolt rendszerek: Milyen rendszereket nevezünk "szorosan csatolt" rendszereknek?====
<div class="answer">
Ahol több CPU közös óra és közös memória segítségével működik együtt. Általában egyetlen operációs rendszer van, de az bonyolult. (Megjegyzés: az architektúrákból megtanult "közös erőforrást használnak" definícióra csak fél pontot adtak.)
</div>

===Erőforrás-hozzáférés===

====Elosztott rendszerek: Elosztott rendszerekben milyen konzisztencia kérdésekkel kell foglalkozni?====
<div class="answer">
* frissítés konzisztencia
* másolat konzisztencia
* cache konzisztencia
* hiba konzisztencia
* óra konzisztencia
* felhasználói interfész konzisztencia
</div>

====Erőforrás-gazdálkodás: Mi a különbség a hierarchikus és a globális erőforrás-gazdálkodás között?====
<div class="answer">
hierarchikus: a gyermek folyamatok csak a szülő erőforrásaiból részesülhetnek, és nem létezhetnek önállóan, csak amíg a szülőjük is létezik. globális: a rendszer valamennyi folyamata létrejötte után egyenrangú, önálló szereplő, és versenyezhet a teljes erőforráskészletből való részesedésért.
</div>

====Éhezés: Mi az az éhezés?====
<div class="answer">
A folyamatnak megvan mindene, ami a futásához kellene (ezért nem holtpont), de az erőforrásokat, amiket használni akar, más folyamatok kapják meg (ezért nem tud futni).
</div>

====Graceful degradation: Mit jelent a "graceful degradation" fogalma? ====
<div class="answer">
Fokozatos leromlás/összeomlás: Ha a rendszer terhelése eléri az ún. könyökkapacitást, akkor utána viselkedése megváltozik, a tovább növekvő terhelésre már egyre rosszabb működéssel reagál (overhead). Elvárható, hogy ezt fokozatosan tegye (ne omoljon össze).
</div>

====Kölcsönös kizárás====
<div class="answer">
Annak biztosítása, hogy a közös erőforrást egy időben csak annyi magában szekvenciális feladat használja, amely mellett a helyes működése garantálható.
A kölcsönös kizárást meg kell oldanunk a programban. Többnyire a használt erőforrást lock-oljuk (elzárjuk): nem engedjük hozzáférni a többi részfeladatot.
</div>

====Kritikus szakasz: Mit jelent a kritikus szakasz?====
<div class="answer">
A magában szekvenciális feladatok azon kódrészletei, amely során a kölcsönös kizárást egy bizonyos közös erőforrásra biztosítjuk. A kritikus szakasz a kérdéses közös erőforráshoz tartozik. A kritikus szakaszt a hozzá tartozó erőforrásra atomi műveletként (nem megszakítható módon) kell végrehajtanunk.
</div>

====Monitor: Mi a monitor alkalmazásának lényege? (Kölcsönös kizárás)====
<div class="answer">
A lockolás nem szétszórva történik a programban, hanem egyetlen, a közös erőforráshoz szorosan tartozó programrészletben.
</div>

====Prioritás öröklés: Mi a prioritás öröklés (Priority Inheritance, Pl) protokoll lényege? (prioritás inverzió témakör)====
<div class="answer">
Az alacsony prioritású feladat megörökli az általa kölcsönös kizárással feltartott feladat prioritását a kritikus szakaszából való kilépéséig. Csak részben oldja meg a prioritás inverzió problémáját.
</div>

====Test-and-set: Hogyan lehet Test_and_Set utasítással kritikus szakaszba lépést (entry) és kilépés (exit) megvalósítani?====
<div class="answer">
* Belépésnél csökkentjük a value értékét ezzel jelezve hogy használni akarjuk a kritikus szakaszt
* Kilépésnél növeljük a value értékét
Egy változót kijelölünk "lock object"-nek; ha ennek a tartalma 0, nincs senki a kritikus szakaszban. A kritikus szakasz elején egy ciklusban test-and-set-et hajtunk végre rá (az utasítást a ciklus feltételébe téve); ha valaki van a szakaszban már, a ciklusban fogunk keringeni, amíg ki nem lép belőle a másik. Amikor kilépett, a test-and-set következő végrehajtása beállítja a változót, és továbbengedi az egyik várakozó ciklust. A szakaszból kilépéskor pedig simán (nem test-and-set-tel) 0-ba állítjuk.
</div>

====Test-and-set: Hogyan működik a test_and_set?====
<div class="answer">
Visszaadja egy bit értékét, és ha 0 volt, 1-re állítja. Mindezt oszthatatlanul, vagyis ha 0 volt ott, és többen egyszerre hívtak rá test-and-set-et, akkor az egyiké teljesen lefut, 1-be állítja és nullát ad vissza, mielőtt a többi elkezdene futni (így ők mind 1-et fognak visszaadni)
</div>

====Újrahívhatóság: Mit jelent az újrahívhatóság (reentrancy) fogalma?====
<div class="answer">
A közös erőforrás problémájának egyfajta kiterjesztett esete egy függvényen/objektumon belül, mely akkor léphet fel, amennyiben ezt a függvényt/metódust egyszerre többen is meghívhatják. Előfordulhat akkor, ha ugyanazt a függvényt hívjuk egy taszkból és egy megszakítás-rutinból is, vagy ha preemptív ütemezés esetén ugyanazt a függvényt hívjuk két taszkból is.
</div>

===Holtpont===

====Definíció: Adja meg a holtpont definícióját!====
<div class="answer">
Egy rendszer folyamatainak egy H halmaza holtponton van, ha a H halmazba tartozó valamennyi folyamat olyan eseményre vár, amelyet csak egy másik, H halmazba tartozó folyamat tudna előidézni. Másként: A közös erőforrások hibás beállítása vagy használata miatt a rendszerben a részfeladatok egymásra várnak » nincs futásra kész folyamat; » nem jöhet létre belső esemény; » A rendszer nem tud előrelépni.
</div>

====Foglalva várakozás: Holtpont megelőzése (prevention) esetén milyen módszerrel lehet a foglalva várakozás előfordulását kizárni?====
<div class="answer">
* Az erőforrást birtokló feladat kér újabb erőforrást.
* Minden szükséges erőforrást egyben kell lefoglalni, egyetlen rendszerhívással.
* Alkalmazástól függ a használhatósága.
* Erőforrás-kihasználás romlik.
* A foglalva várakozás elkerülhető, ha minden folyamat betartja azt a szabályt, hogy az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el. A szabály betartásával megelőzhető a holtpont, de ára az erőforrás-kihasználás jelentős romlása.
* Ha a folyamatokat kötelezzük arra, hogy minden erőforrásukat egyszerre kérjék el. Ha meg akarjuk engedni a rákérést, akkor menthető állapotú erőforrások esetén megtehetjük, hogy a várakozó folyamatoktól elvesszük az erőforrásaikat.
</div>

====Kezelése: Az operációs rendszer milyen általános eljárásokat használhat a holtpont kezelésére?====
<div class="answer">
* strucc algoritmus (nem vesz róla tudomást)
* holtpont feloldása - melyik holtpontban érintett folyamatot számoljuk fel?
* menthető állapotú erőforrások elvétele,
* minél kevesebb folyamat felszámolása,
* folyamatok prioritása,
* már elvégzett munka,
* folyamatok visszaállíthatóságának biztosítása
* holtpont megelőzése
</div>

====Kialakulás szükséges feltételei: Sorolja fel a holtpont kialakulásának szükséges feltételeit!====
<div class="answer">
* Kölcsönös kizárás: Vannak olyan erőforrások a rendszerben, melyeket a folyamatok csak kizárólagosan használhatnak.
* Foglalva várakozás: legyen olyan folyamat mely lefoglalva tart erőforrásokat, miközben más erőforrásokra várakozik.
* Nincs erőszakos erőforrás-elvétel: a folyamatok addig birtokolják az erőforrást, míg saját jószántukból fel nem szabadítják azokat.
* Körkörös várakozás: Létezik a rendszerben egy olyan folyamatsorozat, melyben minden folyamat az utána következő folyamat által foglalt erőforrásra vár, a sorozat utolsó tagja pedig a sorozat első tagjára.
</div>

====Megelőzés, elkerülés: Mi a különbség a holtpont megelőzése (prevention) és holtpont elkerülése (avoidance) között?====
<div class="answer">
* megelőzése: olyan rendszert tervezünk, ahol nem teljesülnek a holtpont feltételei, így elvileg sem lehet holtpont.
* elkerülése (pl. bankár algoritmus): A rendszer minden erőforrásigény kielégítése előtt mérlegeli, hogy nem vezet-e holtpontveszélyre a kérés teljesítése, más szóval fennmarad-e a biztonságos állapot.

* ( Kölcsönös kizárás minimálisra csökkentése: lehetőleg többpéldányos erőforrásokat alkalmazunk, ahol ez nem lehetséges, ott a hozzáférést megpróbáljuk oszthatatlan műveletté tenni.
* Foglalva várakoztatás megszüntetése: Ha minden folyamat betartja a szabályt, miszerint az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el, akkor elkerülhető a foglalva várakoztatás. Ennek ára van: az erőforrás-kihasználtság romlása.
* Nincs erőszakos erőforrás-elvétel kiküszöbölése: Ha menthető állapotú erőforrásaink vannak, akkor megtehetjük, hogy elvesszük egy adott folyamat erőforrását és egy másiknak adjuk, majd annak lefutása után visszaadjuk a régi állapotában az erőforrást az első folyamatnak.
* Körkörös várakozás megakadályozása: A folyamatok megegyeznek az erőforrások sorszámozásában, minden folyamat csak nagyobb sorszámú erőforrást igényelhet azoknál az erőforrásoknál melyeket birtokol. Ekkor biztosan nem alakulhat ki kör.)
</div>

===Fájlrendszerek===

====Fájl: Mi a fájl az operációs rendszer szempontjából? (háttértár-kezelés)====
<div class="answer">
* a fájl a permanens táron az adattárolás logikai egysége, az operációs rendszer feladata a logikai egységek (fájlok) leképzése valódi fizikai egységekre, ez az OS-ben egy többszintü réteges rendszer
* Absztrakt adattípus (objektum, fájl mutató).
* Adat, név (name - elnev. konvenciók), típus (type - kezelés módja) tulajdonságok (attributes). Tulajdonosok, jogosultságok. Hozzáférési időpontok
* Kölcsönös kizárás (file locking)
* TODO
</div>

====Háttértáron lévő lapok: Milyen részidőkből áll össze a háttértáron levő lapokhoz való tényleges hozzáférési idő? Kis vagy nagy lapok használata esetén kapunk "jobb" byte hozzáférést?====
<div class="answer">
* adatátviteli sebesség + fejmozgás sebessége + lemezek forgási sebessége
* nagy lapok esetén ( mert így közvetlenül egymás után helyezkednek el az összetartőző adatok így nem kell a fejnek "ugrálnia" )
* Először a laptáblából kell kikeresni a lap bejegyzését, és konstatálni, hogy nincs hozzá fizikai lap rendelve. Majd, ki kell választani egy szabad fizikai lapot (ha nincs, ki kell vinni egyet háttértárra), a szabad helyre beolvasni a lapot, majd újraindítani a laphibát okozó utasítást. Ezek közül a háttértárról olvasás nagyságrendekkel lassabb a többinél, ezért lényegében ez határozza meg a teljes hozzáférési időt.
* Ha csak a háttértáron lévő lapokat nézzük, akkor, mivel kisebb lapot gyorsabban lehet beolvasni, ezért kisebb lapoknál gyorsabb a hozzáférés. Ha egy folyamat teljes munkahalmazát nézzük, akkor viszont a kisebb lapok több adminisztrációs költséggel járnak (gyakrabban kell háttértárhoz fordulni), és átlagban a nagyobb lapok adnak jobb eredményt.
</div>

====Indexelt tárolás: Sorolja fel az indexelt tárolás (indexed allocation) előnyeit és hátrányait! (Fájlrendszer-leképzés)====
<div class="answer">
* Szekvenciális és indexelt elérésre is alkalmas.
* Sérülékeny (az index blokkok sérülése a fájlt elérhetetlenné teszi).
* Az index blokkokat viszont könnyű többszörözni (replikálni).
* Sok fejmozgást okoz (seek), a blokkok el vannak szórva a diszken.
* Itt is lehet a láncolt listás töredezettség mentesítéshez hasonló algoritmusokat használni a fejmozgás minimalizálására.
</div>

====RAID: Sorolja fel a RAID technika leglényegesebb elemeit!====
<div class="answer">
* Használjunk több merevlemezt egyszerre.
* Több redundáns alkalmazása növeli a megbízhatóságot.
* Több párhuzamos használata növeli a sebességet.
* Hozzunk létre egy virtuális diszket a fizikai diszkekből.
* Redundant Array of Inexpensive Disks: több lemez összekapcsolása.
* A RAID-0 esetében két lemezre vannak szétosztva az adatok, így egyetlen fájlt kétszer akkora sebességgel lehet írni (a két felét parhuzamosan).
* A RAID-1 esetében ugyanazt az adatot tároljuk le a két lemezen, így gyorsabb nem lesz, de az egyik lemez hibája esetén visszanyerhetőek az adatok.
* Megjegyzés: ez csak példa, több lemezzel is lehet csinálni, a sebesség/tárhely/hibatűrés között különböző kompromisszumokat elérve.
</div>

====RAID0 vs. RAID1: Hasonlítsa össze két azonos diszkből álló RAID0 és RAID1 tömb tulajdonságait! Hogyan alakul a hozzáférési idő, az adatátviteli sebesség és a megbízhatóság egyetlen diszkhez képest a két esetben?====
<div class="answer">
RAID 0-1 szabványok általában SW implementációval és kevés (2db) diszkkel
* RAID 0 (striped disks):
** Több diszk párhuzamos használata;
** file részei N diszkre kerülnek;
** Az egyes részek egymástól függetlenül elérhetők
** A diszkek tárolókapacitása összeadódik
** N azonos diszk esetén a RAID 0 virtuális diszk olvasásai és írási adatátviteli sebessége maximum N-szeres közelébe nő.
** A hozzáférési idő közel eléri egy diszk hozzáférési idejét.
** Bármelyik diszk meghibásodása esetén az adat elveszik
* RAID 1 (mirroring):
** Több diszk redundáns használata.
** A file minden része minden (N) diszkre kikerül.
** Azonos diszkeket feltételezve a tárolóterület egy diszk tárolóterületével azonos.
** Az adatátviteli sebesség lassabb, mint egy diszk sebessége.
** A hozzáférési idő nő.
** Speciális esetben az olvasási sebesség N-szeresre nőhet, feltételezve a diszk meghibásodásának más módon történő észlelését (nem kell az azonosságot ellenőrizni többségi szavazással).
** Egy működőképes diszk esetén az adat elérhető.
</div>

====RAID5: Adja meg az M (M pozitív egész szám) diszket tartalmazó RAID5 tömb tulajdonságait! (hibatűrés és sebesség)====
<div class="answer">
* RAID 5 (block interleaved distributed parity).
* Több diszk redundáns és párhuzamos használata
* Adat és paritás elosztása N+1 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 1 diszk meghibásodása esetén az adat elérhető.
** 2 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error). A 2. meghibásodás észlelése a tömb újraépítése során)
</div>

====RAID5: Miért előnyös és miért hátrányos RAID5 használata?====
<div class="answer">
* + N azonos diszk esetén az olvasási és írási adatátviteli sebessége maximum N-szeres közelébe nő.
* + 1 diszk meghibásodása esetén az adat elérhető.
* - 2 vagy több diszk meghibásodása esetén az adat elveszik.
* - Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error).
* -Bonyolultabb, mint a Raid 0/1, ezért hardveresen valósítják meg, ami viszont drága
</div>

====RAID6: Adja meg a 8 darab 1 Tbyte-os HDD-ből álló RAID6 tömb tárolókapacitását!====
<div class="answer">
6 TB. (Adat és paritás elosztása N+2 diszkre. A kapacitása N diszk tároló kapacitásával egyenlő.)
</div>

====RAID6: N db azonos diszkből álló RAID6 tömb esetén a tömb tárolókapacitása és sebessége (nagy fájlok írása/olvasása során elérhető adatátviteli sebesség) hogyan viszonyul az egyetlen diszk azonos adataihoz?====
<div class="answer">
* RAID 6 (block interleaved dual distributed parity)
* Több diszk redundáns és párhuzamos használata.
* Adat és paritás elosztása N+2 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 2 diszk meghibásodása esetén az adat elérhető.
** 3 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nagyobb valószínűséggel állítható helyre a RAID 5-höz képest
* Minimum négy lemezre van szükség a RAID 6 működéséhez. The capacity of the array is (N-2) times the size of the smallest member disk for the array of N disks.
* Az olvasási sebesség (N-2)-szerese egy lemez olvasási sebességének - two disks in the row hold a parity which is useless to read. Such read speed values are roughly the same as in RAID 5.
</div>

====Tárolás egysége: Mi a logikai és mi a fizikai tárolás egysége a permanens táron?====
<div class="answer">
* logikai egység: fájl (file)
* fizikai egység: adatblokkok (cilinder, sáv és szektor együtt azonosítja az írható/olvasható adatblokkot; OS képzi le a logikaiakat fizikaiakra)
</div>

===Folyamatok, szálak===

====Bernstein feltétele: Mikor lehet két tevékenységet (utasítássorozatot) párhuzamosan végrehajtani (Bernstein)?====
<div class="answer">
Bernstein feltétele:
* Legyen <math> P_i </math> és <math> P_j </math> két darabja egy programnak.
* A <math> P_i </math> összes bemeneti változója <math> I_i </math>, és az összes kimeneti változója <math> O_i </math>, ugyanez <math> P_j </math> -re <math> I_j </math> és <math> O_j </math>.
* A két program párhuzamosan végrehajtható (vagyis független), ha: <math> I_j \bigcap O_i = 0 </math>, <math> I_i \bigcap O_j = 0 </math> és <math> O_i \bigcap O_j = 0 </math>
</div>

====Feladatok (task) együttműködése: Hasonlítsa össze a közös memórián illetve az üzenetváltáson alapuló folyamatok közti együttműködést!====
<div class="answer">
Közös memórián keresztül történő adatcsere esetén az együttműködő folyamatok mindegyike saját címtartományában lát egy közös memóriát. A közös memória elérését valamilyen adatátviteli rendszer teszi lehetővé. Üzenetváltásos adatcsere esetén a folyamatoknak nincs közös memóriája. Az adatátviteli rendszer most a logikai processzorokat kapcsolja össze. Rajta keresztül a folyamatok üzeneteket tudnak küldeni, illetve fogadni. Az üzenetküldésre a folyamatok logikai processzorainak utasításkészletében megfelelő utasítások állnak rendelkezésre. Ezek a Küld (Send) és a Fogad (Receive) műveletek.
</div>

====Folyamat: Definiálja a "folyamat" (process) fogalmát!====
<div class="answer">
* Egy program futás alatt álló példánya a folyamat.
* saját kód, adat, halom, verem
* A folyamatok nem férnek hozzá egymás lapjaihoz (védettek más folyamatoktól)

* végrehajtás alatt álló program (program maga a végrehajtható kód), amely folyamat virtuális címterébe van leképezve
* folyamat egy szála az, ami éppen fut egy CPU-n, és nem maga a folyamat
* minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát
* privát virtuális címtér (virtuális memóriacímek készlete, amiket a folyamat használhat)
* tartozik hozzá egy egyedi folyamatazonosító (process ID)
* rendszererőforrások listája, melyekhez a folyamat összes szála hozzáfér
* a folyamat virtuálisan összefüggő memóriát lát (virtuális memória) (valójában az összefüggő memóriaterület ritka)
* háttértárolóra is kiírható (swapping)
* A folyamat által látott logikai címtartomány, és a ténylegesen használt fizikai címtartományok teljesen elkülönülnek
* Folyamatok megoszthatnak memóriaterületeket olvasás- vagy akár írás- és olvasás-hozzáféréssel (Az ilyen memória területek több folyamat virtuális címtartományába vannak belapozva)
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 IPC (Inter-process communication) megoldást!====
<div class="answer">
* '''Jelzés''': rendszerüzenetek küldése és fogadása a folyamatok között, jellemzően utasítások továbbítása egyik folyamattól a másiknak
* '''Üzenetsor''': aszinkron kommunikációs forma, mely során a küldő és fogadó közvetlen interakciója nem szükséges, az üzenetek addig tárolódnak a sorban amíg a címzett fel nem dolgozza azokat vagy a sor meg nem telik
* '''Szemafor''': absztrakt struktúra amely a folyamatok közötti közös erőforrásokért való hozzáférést vezérli
* '''Közös memória''': ugyan az a memóriaterület kerül kiosztásra több különböző folyamatnak, írási és olvasási joggal egyaránt

''Forrás'': http://en.wikipedia.org/wiki/Inter-process_communication
</div>

====Folyamatok vs. szálak: Mi az eltérés a folyamatok illetve a szálak között, és milyen előnnyel jár a szálak alkalmazása?====
<div class="answer">
A szálak lényegében párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
</div>

====Java-szálak: Milyen módokon képezheti le a JAVA virtuális gép a JAVA natív szálakat a hoszt operációs rendszer folyamataira/szálaira?====
<div class="answer">
A JAVA virtuális gép egy folyamat a hoszt operációs rendszeren belül. A JAVA szálak feleltethetők meg a hoszt operációs rendszer szálainak, ez többnyire one-to-one (JAVA szál egyben OS szál is) napjainkban. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/20100507_ZH_megoldas.pdf)
Kovácsházy Tamás válasza:
7. fólia, 11. fólia:
JAVA (VM a folyamat, VM-en belül szál):
* Thread osztályból származtatva
* Runnable interface megvalósítása
* A JAVA platform-specifikusan valósítja meg a szálat:
* Natív OS specifikus szál (one-to-one, tipikus).
* JAVA specifikus szálak (many-to-one) egy natív OS szálra vagy folyamatra leképezve.
* many-to-many leképzés (erőforrás szempontok miatt, egyre ritkább).

</div>

====PRAM: Mi történik a PRAM modellben írás-írás ütközés esetén?====
<div class="answer">
Az írás-írás ütközésekor valamelyik művelet hatása érvényesül, a két beírni szándékozott érték valamelyike írja felül a rekesz tartalmát (versenyhelyzet), harmadik érték nem alakulhat ki.
</div>

====Processzor-affinitás: Mit állítunk be, ha egy szálnak beállítjuk a processzor affinitását, és miért lehet arra szükség?====
<div class="answer">
* processzoraffinitás: minden szál rendelkezik egy maszkkal, amely kijelöli, hogy a szál mely processzorokon képes futni
* szerepe: ez alapján dől el, hogy a szál mely processzoron fog futni
* ütemezésnél: multiprocesszoros esetben a processzor kiválasztása a processzor-affinitás alapján történik
* A feladat más processzorra, vagy processzormagra kerülése csökkenti a végrehajtás sebességét (pl. cache-elésnél) >> Cél: A feladatot ugyanazon a végrehajtó egységen tartani - Laza vagy kemény processzor affinitás (soft or hard processor affinity).
** Laza: Nincs garancia, de törekszik rá az OS (többnyire alapeset)
** Kemény: Biztosan ugyanazon a CPU-n marad (rendszerhívással)
</div>

====Szál: Definiálja a "szál" (thread) fogalmát!====
<div class="answer">
* párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk és saját vermük van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak, vagyis egymás adatait olvashatják és írhatják. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
* A folyamat egy szála az, ami éppen fut egy CPU-n (ami ütemezésre kerül), és nem maga a folyamat.
* Minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát (szál nélkül a folyamat programja nem futhat).
* szálak még véletlenül sem hivatkozhatnak más folyamatok címterére, hacsak a másik folyamat nem teszi elérhetővé privát virtuális címterének egy részét megosztott memóriaszakaszként (file mapping object a Windows API-ban), vagy - Windows-nál - hacsak egyik folyamatnak nincs joga megnyitni más folyamatot, hogy olyan folyamatok közti memóriafüggvényeket használjon, mint a ReadProcessMemory vagy WriteProcessMemory
* A szál önmagában szekvenciális kód, a végrehajtás legkisebb egysége. Egy adott folyamat szálainak közös az adat- és kódszegmensük, a halmuk (heap), és az egyéb erőforrásokat is közösen használják, de saját virtuális CPU-t látnak, és saját veremmel rendelkeznek.
* TODO
</div>

====Védelmi tartományok: Mi a különbség a statikus és a dinamikus védelmi tartományok között?====
<div class="answer">
Statikus védelmi tartományok esetén az egy folyamathoz tartozó védelmi tartomány a folyamat végrehajtása során nem változik, míg dinamikus védelmi tartományok esetén igen.
</div>

====Virtuális gép: Mi a virtuális gép koncepció lényege?====
<div class="answer">
* A programok elől az operációs rendszer elfedi a hardver implementációs részleteit, és kibővíti azt plusz funkciókkal.
* Az op.rendszer egy olyan réteget képez a hardver fölött, mely elrejti annak körülményességét és bonyolultságát a programozó elől és kibővíti a hardver szolgáltatását. A felhasználó így egy sokkal kellemesebb virtuális gépet (virtual machine, extended machine) lát.
* Az operációs rendszer egy kényelmesen kezelhető virtuális gépet jelenít meg a felhasználói és a programozói felületen.
</div>

===Jogosultságok===

====Belső biztonság: Mi a belső biztonság?====
<div class="answer">
Belső biztonság = védelem. Védelemnek nevezzük az eljárásoknak és módszereknek azon rendszerét, amely lehetőséget teremt a számítógép erőforrásainak programok, folyamatok illetve felhasználók által történő elérésének szabályozására.
</div>

====Engedélyezés: Definiálja az engedélyezés (authorization) fogalmát!====
<div class="answer">
* jogosultság ellenőrzése: milyen adatokat és szolgáltatásokat érhet el ez a személy?
* Hozzáférés-szabályozási listák (Access Control List, ACL)
* Alapelv: mindig csoportnak osztunk jogot
* Pl. biztonsági házirend, fájl ACL

TODO!!!
</div>

====Jogosultság + engedélyezési sémák: Mi a jogosultság fogalma, mi a kapcsolata az engedélyezési sémák többi alapfogalmával?====
<div class="answer">
* A jogosultság egy reláció a szereplők és védett objektumok között.
* engedélyezés ált. sémáinál: szereplő>>>szereplőt leíró adatszerkezet>>>biztonsági szabályzat (policy), JOGOSULTSÁG>>>védett objektumok TODO
* Jogosultságkezelés alapjai: A rendszer működése során
** A szereplők műveleteket kezdeményeznek
** A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját
** A jogosultsági döntő komponens kiértékeli kontextust és engedélyezi vagy megtiltja a műveletet
** A jogosultsági végrehajtó komponens biztosítja, hogy a döntő által hozott döntés érvényre jusson
* NT: SMR (Secure Reference Monitor) - objektumok elérési jogosultságainak ellenőrzése
* NT: Az LSA a SAM segítségével azonosítja a felhasználót és jogosultságait. Ha a felhasználó jogosult bejelentkezni, a logon elindítja a számára kijelölt shellt
* UNIX: hozzáférési jogosultságok (owner, group, others, read, write, execute)
* Engedélyezés általános sémái: >>Szerep alapú hozzáférés-vezérlés >>Hozzáférési jogosultság listák
* TODO
</div>

====Külső biztonság: Mit takar a külső biztonság fogalma?====
<div class="answer">
Annak mértéke, hogy mennyire lehetünk biztosak a számítógépes rendszer, illetve a rendszerben tárolt adatok sérthetetlenségében.
</div>

====Művelet kontextusa: Engedélyezési rendszerekben mit tartalmaz egy művelet kontextusa? (Felhasználó- és jogosultságkezelés)====
<div class="answer">
A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját.
</div>

===Hibakeresés===

====DTrace: Mi a Solaris DTrace megoldás célja?====
<div class="answer">
dinamikus hibakereső rendszer, nyomkövető eszköz, amivel a rendszer és a programok működését futási időben lehet megfigyelni.
</div>

===Memória===

====32 bit: 32 bites kliens Windows operációs rendszer maximum mennyi fizikai memóriát kezelhet, és miért?====
<div class="answer">
Legfeljebb 4 GB-ot (bár néha kevesebbet lát az OS, mert a memóriatartomány felső részére I/O eszközöket szoktak berakni, ld. pl. videókártya-memória...): ''"kliens Windowsok nem használják a gépben lévő PAE támogatást, mert az a tapasztalat, hogy a kliensekben lévő eszközök meghajtói nem kezelik le rendesen a 4 GB-nál több fizikai memóriát"''.
(https://wiki.sch.bme.hu/pub/Infoalap/OpRe/02-opre-windows-memoria.pptx)
(nem támogatják a PAE-t eleve, csak patch-csel)
(_"However, "client" versions of 32-bit Windows (Windows XP SP1 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility and licensing reasons, even though these versions do run in PAE mode if NX support is enabled."_ - http://en.wikipedia.org/wiki/Physical_Address_Extension)
</div>

====32 bit: 32 bites szerver Windows képes-e 4 GB-nál több fizikai memória kezelésére? Válaszát indokolja!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével (ezzel lehet 32 bites címbuszú CPU-val is 64 GB memóriát kezelni a maximális 4 GB helyett).
</div>

====32 bit: 32 bites Windows használata esetén egy felhasználói folyamat maximum mekkora virtuális címteret használhat?====
<div class="answer">
Alapból 2GB felhasználói módú címterületet használhat, ez a /3GB kapcsolóval 3 GB felhasználói címterületre bővíthető.
</div>

====32 bit: 32 bites Windows szerver operációs rendszerek képesek-e 4 GB-nál több fizikai memória kezelésére? Indokolja válaszát!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével.
</div>

====32 bit: 32 bites x86-os (Windows) esetén mekkora a felhasználói és a rendszer mód címtartomány mérete?====
<div class="answer">
Alapból 2GB felhasználói módú és 2GB kernel címterület van, ezt a /3GB kapcsolóval 3GB felhasználói és 1GB kernelre lehet módosítani.
</div>

====Bélády-anomália: Mit nevezünk Bélády-anomáliának?====
<div class="answer">
FIFO algoritmusnál egyes esetekben, ha a munkahalmaz méretét növeljük, a várakozásokkal ellentétben a laphibák száma is nő.
</div>

====Címfordítás: Hogyan történnek a címfordítások, ha az OS szegmens- és lapszervezést is használ a memóriánál?====
<div class="answer">
CPU --> Segmentation unit --> Paging unit --> Physical memory
</div>

====Címfordítás: Milyen címtranszformációk történnek együttes szegmens- és lapszervezésű memória használata során?====
<div class="answer">
* CPU >>>[Logical Address]>>> '''Segmentation Unit''' >>>[Linear Address]>>> '''Paging Unit''' >>>[Physical Address]>>> Physical Memory (http://portal.mit.bme.hu/?l=oktatas%2Ftargyak%2Fvimia219%2Fjegyzet%2F2011%2Fslides_17_memory.pdf)
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/oprewiki1.pdf, 48. oldaltól.
* Változó méretű szegmensek fix méretű lapokat tartalmaznak. Kicsi mind a belső, mind a külső tördelődés. A cím felépítése: (szegmens szám, lapszám, lapon belüli eltolás)
* Hasonlít a szegmensszervezéshez és a kétszintű lapszervezéshez: A memóriában szegmensek vannak ugyan, de ezek lapokból épülnek föl. Van szegmenstábla, és minden bejegyzéséhez tartozik egy laptábla is. Külső töredeződés nincs, belső töredeződés minimális (szegmensenként átlag fél lap); ez a kombinált módszer egyesíti a két módszer előnyeit
* TODO
</div>

====Lapszervezés, keret tábla: Lapszervezés esetén mit tartunk nyilván a keret táblában (frame table)?====
<div class="answer">
Az üres kereteket (frames).
</div>

====Logikai vs. fizikai memória: Mi a különbség a logikai és a fizikai memória között?====
<div class="answer">
A logikai memória a fizikai tár leképezve, ráadásul a leképezés a végrehajtás során változhat is.
</div>

====MMU: Mi a processzor Memory Management Unit (MMU) komponensének a feladata?====
<div class="answer">
* Speciális HW a CPU-ban
* Memória állapotának nyilvántartása
** Tulajdonos folyamat azonosítója
** Hozzáférési jogosultságok (ACL)
** cache-elhetőség, ha van cache (pl. DMA)
* Virtuális memória leképzése fizikai memóriára
** Pl. Translation Lookaside Buffer (TLB)
** Kontextusváltásnál ezt is kezelni kell (ha van)
** Pagefile vagy SWAP (HDD)
* Memóriavédelem
** Tiltott memória hozzáférés megakadályozása vagy legalább jelzése (ACL alapján)
** General Protection Fault (GPF) a Windows-ban
</div>

====Modified/dirty bit, referenced/used bit: Mi a modified/dirty bit és a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* laptáblában:
* Módosítás nyilvántartása (modified/dirty bit): minden memórialaphoz tartozik egy HW által kezelt bit (pl. a laptáblában) - betöltéskor törlik, módosításkor beállítják. Ha a dirty bit 1, akkor erre a lapra történt írási művelet, mióta a ﬁzikai memóriába került. Ezt a bitet a CPU tartja karban (automatikusan), ezzel az operációs rendszer munkáját segítve. 0 érték esetén a lapokat nem kell a diszkre kiírni, ha kiszorulnak a ﬁzikai memóriából (hiszen a tartalmuk a ﬁzikai memóriába helyezés óta változatlan, a diszk-en tárolt változat tehát továbbra is aktuális).

* Hivatkozások nyilvántartása (referenced/used bit): Ha a refernced bit 1, akkor volt "mostanában" hivatkozás erre a lapra. Ezt is a CPU tartja karban. Ez a bit segít az operációs rendszernek, amikor el kell döntenie, hogy melyik lapot dobja ki a ﬁzikai memóriából, ha egy új lapnak nincs helye. A referenced=0 lapokból fog válogatni.
</div>

====Page locking: Mit jelent és miért van szükség arra, hogy a virtuális tárkezelésnél egyes lapokat ideiglenesen a tárba lehessen "fagyasztani" (page locking)?====
<div class="answer">
* Azt jelenti, hogy a lapcsere algoritmus nem lapozhatja ki a háttértárra az adott lapot. Ok: periféria-művelet van az adott lappal kapcsolatban.
* Azt jelenti, hogy bizonyos lapokat a memóriában tartunk, mert I/O műveletek hivatkozhatnak rá, és ilyenkor a memóriában kell lenniük, mert az I/O műveletek fizikai memóriacímeket használnak.
</div>

====Referenced/used bit: Mi a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* Bizonyos algoritmusok igénylik a lapra történő hivatkozások figyelését is, ami ugyancsak hardvertámogatással hatékony. A laptáblában erre a célra is fenntarthatunk egy bitet. Ezt a hivatkozott bitet (referenced bit, used bit, R bit) a címképző hardver állítja be minden esetben, amikor az adott lapon belüli címre történik hivatkozás. A bitet az operációs rendszer törli adott időnként, vagy eseményhez (például laphiba) kötötten.
* Hivatkozások nyilvántartása (referenced/used bit): OS adott időnként és/vagy adott eseményekre törli - használat esetén beállítják.
</div>

====TLB: Mi az a Translation Lookaside Buffer, fizikai címcsatolásnál mi a szerepe?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.
</div>

====TLB: Mire szolgál a Translation Lookaside Buffer és mi a szerepe a fizikai cím kiszámításánál (virtuális címképzés)?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.

(Szerintem előbb a TLB-ben keresi, aztán ha ott nincs, csak utána nézi a laptáblát.)
</div>

====Tördelődés (külső vs. belső): Mi a különbség a külső és belső tördelődés között? (Memória foglalás)====
<div class="answer">
A tördelődött memóriaterületet külső tördelődés esetén az operációs rendszer szabadon hagyja, míg belső tördelődés esetén pedig odaadja egy olyan folyamatnak, aminek nincs igazából rá szüksége.
</div>

====Vergődés: Adja meg a vergődés (trashing) definícióját!====
<div class="answer">
A gyakori laphibák okozta teljesítménycsökkenést vergődésnek (thrashing) nevezzük. Az ellene való védekezés a munkahalmaz méretének jó megválasztása. Célszerű egy folyamatnak annyi lapot adni, amennyi szükséges az egyensúlyhoz, azaz ahány lapra hivatkozik a laphiba kiszolgálás ideje alatt (ugyanakkor nem sokkal többet, mert ekkor leromlik a multiprogramozás foka).
</div>

====Vergődés: Mi az a vergődés, és hogyan védekezzünk ellene?====
<div class="answer">
* Ha több memóriára lenne szüksége a folyamatoknak, mint amennyi rendelkezésre áll, ezért túl gyakran keletkezik laphiba, és a processzor idejének nagy része haszontalan lapcserékkel telik.
* Védekezni ellene például azzal lehet, ha a laphiba-gyakoriság függvényében az ütemező változtatja a multiprogramozás fokát: ha kevés a memória, folyamatokat függeszt fel, és swappel ki; ha van elég, akkor épp ellenkezőleg.
</div>

===uc/OS-II===

====Prioritás: A uC/OS-II-ben hány taszk tartózkodhat egy prioritási szinten és miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk.
</div>

====Prioritás: Egy prioritási szinten hány szál futtatását teszi lehetővé a uC/OS-II, miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk. Egy taszk = egy szál.

(Magyarázat: egy taszk = egy szál; lásd http://video.bme.hu/media/video/Operacios_Rendszerek_08ea_20110301.wmv, 01:09:18 környékén
Röviden: a beágyazott rendszerek, kis OS-ek esetén (uC/OS-II, FreeRTOS, stb.) lényegében csakis szálakban gondolkozunk. Nincs MMU, csak egyetlen összefüggő fizikai memória van, nincs virtuális memória koncepció, a processzoron futó teljes alkalmazás (az egyetlen alkalmazás) egy nagy folyamat - nincs más folyamat! Ezenbelül tudunk threadeket futtatni. Single Address Space.)
</div>

===Ütemezés===

====Átbocsátó képesség: Adja meg az átbocsátó képesség definícióját és mértékegységét!====
<div class="answer">
* (throughput) Mértékegység: munka/s, vagy 1/s
* Adott időegység alatt elvégzett feladatok száma. <math>\frac{\sum \textrm{elvegzett munkak}}{\textrm{ido}}</math>
* A rendszerfeladatokat nem számoljuk.
</div>

====Hosszú távú ütemezés: Adja meg a hosszú távú ütemezés célját!====
<div class="answer">
Tipikusan a BATCH rendszerekben van jelen, és uj jobok végrehajtasának megkezdéseről (új folyamatok indítasárol) dönt. Az elvégzesre váro munkák közül a választas szempontja, hogy a rendszerben a CPU-intenzív es I/O-intenzív folyamatok aránya optimális legyen (optimalis job-mix fenntartasa).
</div>

====Hosszú távú ütemezés: Definiálja a hosszú távú ütemezés fogalmát!====
<div class="answer">
A hosszútávú ütemező feladata az elindított feladatok rendszerbe, illetve a "futásra kész" várakozási sorba való beengedését szabályozni. Igyekszik a CPU-t és a perifériákat terhelő folyamatokat egyensúlyban tartani. Batch rendszerekre jellemző; a PC-k oprendszere általában azonnal indítja a folyamatokat, mikor azt a felhasználó kéri.
* feladata: A háttértáron várakozó feladatok közül kiválasztja azt, amelyiket el kell indítani.
</div>

====Konvoj hatás: Mi a konvoj hatás, és a tanult ütemező algoritmusok közül melyekben jelentkezhet?====
<div class="answer">
* igen nagy lehet az átlagos várakozási idő, mivel egy-egy hosszú CPU-löketű folyamat feltartja a mögötte várakozókat
* FCFS-nél (First-come, first-served) tapasztalható (pl. SJF (Shortest Job First) és RR algoritmus küszöböli ki)
</div>

====Középtávú ütemezés: Adja meg a középtávú ütemezés célját!====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.
</div>

====Középtávú ütemezés: Mi a középtávú ütemező feladata?====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.

Szerintem inkább ez:
A rendszerben lévő feladatok memóriájának egyes éppen nem használt részeinek kiírása háttértárra.
</div>

====Körülfordulási idő: Mi az a körülfordulási idő?====
<div class="answer">
* TAT (Turnaround Time) -> Egy feladatra vonatkozóan a rendszerbe helyezéstől a teljesítésig eltelt idő.
* Mértékegység: s,
* t_(CPU,végrehajtási idő)+t_várakozás (Magában foglalja a ténylegesen munkával töltött időt és a várakozást is.)
* felhasználó minél előbb szeretné látni a végeredményt
</div>

====Megszakítás: Az éppen futó taszkot megszakítja egy IT. Preemptív OS esetén mindig a megszakított taszk fogja-e visszakapni a futási jogot? Miért?====
<div class="answer">
* Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
* Másik: Nem, mert akitől elvették a futás jogát az futásra kész állapotba fog kerülni és az ütemező dönti el, hogy melyik folyamat fogja megint megkapni a futást.
</div>

====Megszakítás: Egy futó taszkra IT érkezik. Preemptív OS esetén az interrupt után mindenképpen 'ide' térünk vissza?====
<div class="answer">
Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
</div>

====Preemptív ütemező: Mikor nevezünk egy ütemezőt preemptívnek? ====
<div class="answer">
Ha az OS elveheti a futásjogot (a CPU-t) egy folyamattól/futó feladattól (interrupt).
</div>

====Rövid távú ütemezés: Mi a rövidtávú ütemezés, mikor jár környezetváltással?====
<div class="answer">
* Rövidtávú ütemezés: futó folyamat kiválasztása a futásra kész feladatok közül
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Rövid távú ütemezés: Mikor fut a rövidtávú ütemező és mikor jár környezetváltással?====
<div class="answer">
* Ütemezés következhet be, ha
** a futó folyamat befejeződik,
** egy folyamat felébred, futásra késszé válik,
** a futó folyamat várakozni kényszerül (valamilyen esemény bekövetkezésére), illetve,
** a futó folyamat önként lemond a futás jogáról vagy pedig elveszik tőle.
* Az első és a harmadik esetben az ütemezés mindig környezetváltással jár, hiszen a következő futó folyamat egészen biztosan nem a korábban futott lesz. A másik két esetben előfordulhat, hogy az ütemezőnek nem kell másik folyamatot kiválasztania.
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Terhelés-végrehajtó egységek közötti megosztás: Sorolja fel a terhelés-végrehajtó egységek közötti megosztásának megoldásait! (Többprocesszoros rendszerek)====
<div class="answer">
* Master and slaves (egy CPU osztja ki a feladatokat)
* Self-scheduling / peering (minden CPU ütemez)
* Globális futásra kész sor
* Processzoronkénti futásra kész sor
** Push alapú: OS kernel folyamat mozgatja a sorok között a feladatokat.
** Pull alapú: Az idle állapotban (idle feladatot végrehajtó) CPU próbál a többi sorából feladatot kapni.
* Kettő kombinációja
** Összefüggő, párhuzamosan futtatható feladatok optimalizálása (pl. Gang scheduler)
</div>

===Virtualizáció===

====Hardveres virtualizáció: Mit jelent az, ha egy x86-os processzor hardveres virtualizáció támogatással rendelkezik?====
<div class="answer">
A CPU utasításkészletének és üzemmódjainak olyan kiegészítése, amely lehetővé teszi a vendég operációs
rendszer kódjának módosítás nélküli futtatását. [?]

(Speciális utasításokkal látják el a processzort, amit szoftveresen akár több 100 utasításon keresztül lehetne csak megoldani. ROSSZ(MZ))

Elrejti a gep fizikai tulajdonsagait a felhasznalok elol.

Miert erdemes virtualizalni?

-Lehet futtatni a gazda OS el nem kompatibilis alkalmazast.

-Lehet biztonsaggal rendszergazda jogot adni mindennek, mert ugy se tud a gazda os-be kart tenni.

-Konnyen at lehet masolni a virtualis gepet egy masik gepre.
</div>

====Hosted vs. bare-metal: Miben különbözik egy hosted egy bare-metal típusú virtualizációs megoldástól?====
<div class="answer">
Bare-metal esetén a VMM kezeli a HW erőforrásokat, míg hosted típusú esetén ezt a host OS végzi.

videó:
http://video.bme.hu/media/video/Operacios_Rendszerek_20ea_20110418.wmv
00:16:45 körül

Kétféle megközelítés:

# Hosted: az operációs rendszerre telepítek egy virtualizációs szoftvert, ez beépül az operációs rendszerbe tipikusan kernel modulként, innentől a virtualizációs szoftver teszi lehetővé, hogy virtuális gépeket futtassak. Tipikusan a desktop megoldások (VMware Player, VirtualBox, Virtual PC, stb.)
# Bare-metal: a virtualizációs szoftver valós OS-szerű funkciókat valósít meg. Lényegében egy minimális funkciókészlettel rendelkező OS. A hardvert nem egy általános célú operációs rendszer kezeli, hanem a virtualizációs szoftver feladata az, hogy a hardver-erőforrásokkal gazdálkodjon, ő dönt az ütemezésről, ő dönt a memória-hozzáférésekről. Tipikusan szokott hozzá tartozni egy menedzsment operációs rendszer, egy menedzsment konzol, ami a távoli hozzáférést, virtuális gépek elindítását lehetővé teszi, és ott is ott tudom futtatni a vendég operációs rendszereket. Tipikusan szervermegoldások (VMware ESX Server, Xen Enterprise, MS Hyper-V).

Fontos különbség: ki dönt a CPU-erőforrásról?
# van az OS-nek egy ütemezője, ő dönt arról, mikor, ki kapja meg a CPU-t. Dönthet úgy, hogy az időszeletet az alkalmazás kapja meg, a köv. időszeletet a virtualizációs szoftver/modul, ő magán belül pedig eldöntheti, melyik virtuális gépnek osztja a processzort, de alapvetően a host OS dönt arról, mi dönt az erőforrásról.
# arról, hogy ki kapja a CPU-t, a közvetlenül a hardver réteg felett lévő virtualizációs szoftver dönti el. Dönthet úgy, hogy a menedzsment OS kapja, dönthet úgy, hogy valamelyik virtuális gép kapja meg.

</div>

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
<div class="answer">
Módosítjuk a vendég OS forráskódját, hogy ne is akarjon "problémás" utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. (Ezzel egyszerűsödik a hypervisor implementálása, viszont csak úgy működik a módszer, ha módosítják a vendég OS forrását.)
</div>

====Trap-and-emulate: Trap & emulate virtualizációs módszer használata esetén mi történik a vendég gép által kiadott nem privilegizált utasítással?====
<div class="answer">
* nem privilegizált utasítások közvetlenül a valós CPU-n hajtódnak végre (no VMM intervention)
</div>

===UNIX===

====Adminisztratív adatok: hol helyezzük el azokat az adminisztratív adatokat, amelyekre mindig szükség van, akkor is, ha a folyamatnak egyetlen lapja sincs a memóriában?====
<div class="answer">
A proc struktúrában.
</div>

====Adminisztratív adatok: UNIX-ban a folyamatokkal kapcsolatos adminisztratív adatok hogyan épülnek fel?====
<div class="answer">
TODO: rövidíteni.

# adatok, melyek elsősorban akkor szükségesek, amikor a folyamat ténylegesen fut - bent van egy v. több lapja a memóriában, éppen ezekkel kapcsolatos utasításokat hajtunk végre. >> az u-területen található kontextusadatok. A folyamat címtér része. A folyamat nem férhet hozzá, de a folyamat saját címterében találhatók. Amikor a folyamatnak egyetlen lapja sincs a memóriában, hanem minden a háttértáron található, a folyamat nem fut, akkor az itt található adatokhoz a kernel sem tud hozzáférni, mivel ide csak azok az adatok kerülnek, melyek a folyamat futásakor kellenek! Pl. hozzáférés-szabályozási adatok: a folyamat szeretne valamilyen tevékenységet végrehajtani, szabad-e neki vagy sem? Másik példa: rendszerhívások állapotai: végrehajt egy rendszerhívást, amiben éppen tartózkodik, ezzel kapcsolatos állapotadatok, stb. Vagy: nyitott fájl adatok, fájlkezeléssel kapcsolatos adatok. UNIX-ban a fájlkezelést nagyon általánosan kell érteni. Minden, ami a fájlrendszer-interfészen keresztül zajlik, ahhoz tartozik egy nyitott fájl objektum, ami ennek adminisztrálására szolgál, ezek is az u-területen találhatók. Ezenkívül: számlázási, statisztikai adatok.

# adatok, melyek elsősorban a folyamatok kezeléséhez szükségesek (amire a kernelnek bármikor szüksége lehet). Pl. folyamat alapvető azonosító adatai. Folyamat PID-je, szülőazonosító, stb. Folyamat ütemezésével kapcsolatos adatok, mi a folyamat aktuális futási állapota, mennyi a prioritása, prioritás kiszámolásához szükséges adatai, stb. Memóriakezelési adatok: folyamat memórialapjai bent vannak a memóriában, vagy épp kint vannak a háttértáron. Az u-terület címe, stb. >>> proc struktúra adatai: a process tábla egy eleme (ez a klasszikus rendszereknél ténylegesen egy tábla volt, ma bonyolultabb, pl. láncolt listás megvalósítás). A kernel címterének része. A kernel bármikor elérheti őket.
</div>

====Adminisztratív adatok: Milyen adatstruktúrá(k)ban és milyen címter(ek)ben található(k) a folyamatok adminisztratív adata(i)?====
<div class="answer">
A folyamat futása során szükséges adatok az u-területen, mely a folyamat címterének része, illetve a folyamatok kezeléséhez szükséges adatok a proc struktúrában, mely a kernel címtér része.
</div>

====Adminisztratív adatok: Sorolja fel a UNIX folyamatok legalább 4 alapvető adminisztratív adatát!====
<div class="answer">
* PID (Process ID): egyedi, a folyamatot azonosító szám (PPID: szülő folyamat azonosítója)
* A folyamat állapota (fut, alszik, stb.; ütemezési információk (prioritás, CPU használat, nice érték) )
* Hitelesítők (UID, GID: a kapcsolódó felhasználó adatai)
* Memória-kezelési adatok (címleképezési térkép)
* Kommunikációs adatok (fájlleírók, jelzés információk)
* Statisztikák (erőforrás használat (számlázáshoz) )
</div>

====Alvási prioritás: UNIX alvási prioritásának ütemezését mi végzi?====
<div class="answer">
Az alvási prioritást is az ütemező határozza meg, az alapján, hogy mire várakozik a folyamat, vagyis miért hajtott végre sleep() rendszerhívást. Kernel módban az ütemező nem veheti el a futási jogot, ezért amíg nem hajt végre sleep() hívást, addig nincs is szükség a prioritásának meghatározására.
</div>

====Android: Az Androidban mikor és miért (adjon jellegzetes példát) terminálható egy alkalmazás?====
<div class="answer">
Az alkalmazás erőforráshiány miatt bármikor terminálható, ezt az operációs rendszer automatikusan meg is teszi. Példa: ha nincs elég memória.
</div>

====Belső szerkezeti elemek: Sorolja fel a UNIX operációs rendszer főbb belső szerkezeti elemeit!====
<div class="answer">
* betöltő
* virtuálismemória-kezelő
* állományrendszer
* blokkos berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: lemezegység, szalagos meghajtó)
* karakteres berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: hálózat, nyomtató)
</div>

====Csővezeték (pipe): Írjon le egy olyan konkrét UNIX shell parancssort, amely csővezetéket alkalmaz!====
<div class="answer">
ls -la | more
</div>

====exec(): Mire szolgál a UNIX exec() rendszerhívás?====
<div class="answer">
exec(): új programkód betöltése egy folyamat címterébe
Azaz a fork() paranccsal létrehozunk egy új folyamatot, exec() paranccsal pedig betöltjük a folyamatba a kódot.
</div>

====Fájl-attribútumok: Sorolja fel a fontosabb UNIX fájl-attribútumokat!====
<div class="answer">
* Típus
* Linkek
* Eszköz, inode, méret...
* Időbélyegek
* Azonosítási és hozzáférés-szabályozási adatok
</div>

====Fájlrendszeri bejegyzések: Sorolja fel a UNIX fájlrendszeri bejegyzések alapvető tulajdonságait (legalább hármat, ls -l oszlopok)!====
<div class="answer">
* pl.: drwxr-xr-x 2 root root 4096 dec 22 12.27 txt
* sorrendben: I. UNIX-fájltípusok (pl. közönséges fájl (-), katalógus (d), szimbolikus link (l), stb.), II. hozzáférési jogosultságok (3*3-as bontásban - 1. hármas csoport a tulajdonos, a 2. a csoport, a 3. a többiek jogosultságait; 'r' az olvasás (read), a 'w' az írás (write), az 'x' pedig a végrehajtás (execute) jele), III. jogosultságok után egy szám áll (ez könyvtárak esetén azt mondja meg, hogy az adott könyvtár hány elemet tartalmaz, fájlok esetén azt tudhatjuk meg, hogy az adott fájlra hány hardlink mutat), IV. tulajdonos, V. méret (bájtokban), VI. utolsó módosítás dátuma, VII. fájl neve
</div>

====Felfüggesztett állapotok: Mik azok a felfüggesztett állapotok, mi a szerepük a UNIX-ban?====
<div class="answer">
felfüggesztve futásra kész, felfüggesztve alszik állapot A UNIX-ban egyfajta hosszú távú, felhasználói ütemezést jelentenek - a felhasználónak lehetősége van arra, hogy bizonyos folyamatokat a többi állapotból kiemeljen. Pl. Ctrl+Z billentyűkombinációval felfüggesztem a folyamatok futását. Innen valamikor visszahelyezzük futó állapotba.
</div>

====Felhasználói mód, kernel kontextus: UNIX esetén milyen tevékenység zajlik felhasználói módban, kernel kontextusban?====
<div class="answer">
Semmilyen!!
Megj.: Kernel kontextusban, felhasználói módban a program saját utasításait hajtjuk végre, a program saját adataival dolgozunk. Ennél fogva itt nincs értelme beszélni semmiről, mert a folyamat a kernel kontextusában nem hajthat végre semmit.
</div>

====Felhasználói módból kernel módba váltás: Hogyan vált egy UNIX folyamat felhasználói (user) módból kernel módba?====
<div class="answer">
Rendszerhívásokon keresztül.
</div>

====Felhasználói módú prioritás: Sorolja fel milyen tényezők határozzák meg egy UNIX folyamat felhasználói módú prioritását (tradicionális UNIX ütemező esetén)!====
<div class="answer">
* Korábbi CPU-használat
* Futásra kész folyamatok száma (p_cpu "öregítésével")
* nice érték (nice és renice parancsok)
</div>

====Folyamatok állapotai: Milyen állapotai vannak a UNIX-folyamatoknak?====
<div class="answer">
# kiinduló állapot
# futásra kész
# kernel módban futó állapot
# felhasználói módban futó állapot
# alvó állapot
# zombi állapot
# felfüggesztve alszik
# felfüggesztve futásra kész

Ctrl+Z-vel felfüggesztett állapotba helyezem a folyamatot.
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 UNIX folyamatok között kommunikációs megoldást!====
<div class="answer">
* System V IPC: szemafor, osztott memória, üzenetsor
* Csővezeték és nevesített csővezeték
* Jelzések
* RPC
* Folyamat-nyomkövetés
* Szemaforok
* Üzenetsorok
* Osztott memória
* Hálózati, socketeken keresztüli kommunikáció
</div>

====Folyamatok közötti kommunikáció: Soroljon fel UNIX folyamatok közötti adatátviteli eszközöket (legalább hármat)!====
<div class="answer">
* System V IPC: - szemaforok, - üzenetsorok, - osztott memória
* Jelzések: - aszinkron események keltése és kezelése
* Csővezetékek, nevesített csővezetékek: - FIFO kommunikáció a "rokonságban"
* Szemaforok: - a korábban megismert szinkronizációs megoldások
* Üzenetsorok: - diszkrét, típusos üzenetek folyamatok között
* Osztott memória: - azonos fizikai memóriaterület használata több folyamatban
* "hálózati" (socket) kommunikáció: - címzéssel és protokollokkal támogatott kommunikáció
* TODO
</div>

====fork(): Mire szolgál a fork() rendszerhívás?====
TODO: rövidíteni.

Új folyamat létrehozására. A fork() hívásakor az aktuális folyamat, amely kiadta a rendszerhívást, megduplázódik (minden adata, verme, memórialapja, stb.), onnantól két példányban fog továbbélni, amelyek egymással szinte tökéletesen megegyeznek, kvázi klónozva van a folyamat, néhány apró különbség van csupán. De valójában a memóriaszervezés ügyes trükkje: semmit nem csinál azonkívül, hogy bizonyos adminisztratív adatokat megdupláz, ténylegesen nem másol semmit (memórialapokat)! Az így megduplázott folyamat memórialapjaihoz hozzárendel még egy folyamatot, és megjegyzi azt, hogy amíg ezek a folyamatok békésen tudnak egymás mellett dolgozni, addig dolgozzanak ugyanazon, de ha konfliktus van, akkor majd lemásoljuk ezeket a memórialapokat.

Ha a fork() hívás 0-val tér vissza: a gyerek folyamat kódja fut tovább. Ha egy negatív számmal tér vissza, fork() hiba történt, nem tudtuk létrehozni az új folyamatot, le kell kezelni. Ha pozitív számot adott vissza, akkor az eredményben a gyerekfolyamat azonosítója található, itt a szülőfolyamat fut tovább.

Gyerek folyamat fut: az exec() az aktuális folyamat helyére betölt egy másik binárist. Az exec()-et meghívó folyamatnak az exec() kitörli a saját kontextusát, stb., betölt egy új programkódot, amit elkezd végrehajtani. (Kvázi mintha elindítana egy új folyamatot, de a folyamat már fut.) Ha nem sikerült betölteni a binárist (pl. nincs ilyen fájl), akkor hiba, visszatér az exec() is, egyébként nem: az új programkód utasításait hajtjuk végre.
Tehát folyamat létrehozása UNIX-ban két lépésben:
# fork() rendszerhívás = folyamatduplázás, majd
# a gyerekfolyamat helyére az új programkód betöltése exec() hívással.
Modern UNIX-okban fork() már nem igazán (más rendszerhívásokat használ).

====fork(): Miért van szükség a fork() rendszerhívásnál a folyamat megduplázására?====
<div class="answer">
TODO
</div>

====Futási/végrehajtási mód: Mi az a futási mód?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv, 00:17:00 környéke alapján
TODO - rövidíteni
A folyamatok a kerneltől teljesen különválasztva működnek (rendszerhívás interfészen keresztül kommunikálnak a kernellel). A végrehajtási mód azt határozza meg, hogy a kernel vagy a folyamat feladatait hajtja végre az OS.
Két mód: kernel ("privilegizált, védett") mód, valamint felhasználói ("szabad") mód.
Kernel módban a védett (kernel) tevékenységeket, felhasználói módban a folyamat programkódját hajtja végre az OS.
Példa: egy webböngésző a tevékenysége egy részében a saját feladatát hajtja végre, pl. HTML-kódot értelmez és jelenít meg, valamint vannak olyan tevékenységek, amelyek ahhoz kellenek, hogy ezt a feladatát végrehajtsa: hálózati kommunikáció, fájlrendszer-műveletek, stb. - ezek kernel tevékenységek.
Kernel módban privilegizált utasítások hajtódnak végre, pl. egy eszközt kezelünk, vagy hozzányúlunk a háttértárhoz, onnan valamit beolvasunk, oda valamit kiírunk. Ilyen utasításokat egy felhasználói módban futó folyamat nem hajthat végre, hiszen ha közvetlenül hozzáférne a hardverekhez, akkor akár adott esetben a teljes rendszer működését felboríthatná.
Felhasználói módból kernel módba átlépéskor átlépünk egy védett módba, így olyan feladatokat is végrehajthatunk, amit egyébként tilos.
</div>

====inode: Mi a UNIX inode?====
<div class="answer">
* A fizikai állományokhoz tartozó leíró, azonosító
* minden file-hoz tartozik egy inode állomány amiben a file minden tulajdonsága megtalálható (azonosító,leíró)
</div>

====Kernel mód, folyamat kontextus: Milyen tevékenység zajlik kernel módban, folyamat kontextusban?====
<div class="answer">
Kivételek, rendszerhívások kezelése, rendszerhívások végrehajtása.
Amikor a folyamat végrehajt egy rendszerhívást, a felhasználói módból átlép kernel módba, hiszen a rendszerhívás belsejében olyan tevékenységeket szeretne végrehajtani (beolvasni vmit egy fizikai eszközről, hálózatról, más folyamattal kommunikálni, elindítani másik folyamatot, stb.), amelyhez kernel utasítások végrehajtása tartozik.
</div>

====Kernel mód, kernel kontextus: Milyen tevékenység zajlik kernel módban, kernel kontextusban?====
<div class="answer">
Rendszerfeladatok, megszakítások kezelése. Kernelfolyamatok.
</div>

====Kernel módú prioritás: Mi határozza meg a UNIX folyamatok kernel módú prioritását a tradicionális UNIX ütemezésben?====
<div class="answer">
A kernel módban futó folyamat prioritása statikus, nem függ attól, hogy a folyamat mennyit használta a CPUt, vagyis mennyi ideig futott. A prioritás attól függ, hogy a folyamat milyen ok miatt hajtott végre sleep rendszerhívást, vagyis, hogy milyen eseményre várakozik. Emiatt a kernel prioritást szokták alvási prioritásnak is nevezni.
</div>

====Kernelszolgáltatások elérése: Milyen interfészen keresztül érhetők el a UNIX kernel szolgáltatásai?====
<div class="answer">
* System Call Interface
* Az alkalmazások a rendszerkönyvtárakat hívják meg, amelyek szükség szerint meghívják az operációs rendszer szolgáltatásait ??
</div>

====Kontextus: Mi az a kontextus?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv alapján.
TODO: rövidíteni.
Az a környezet, amiben végrehajtjuk az utasításokat. Ez is különbözik a kernelek és folyamatok esetén: folyamat kontextusban azokkal az adatokkal és utasításokkal dolgozunk, amelyek alapvetően a folyamat célját szolgálják, kernel (rendszer vagy megszakítás) kontextusban pedig kernel feladatokat hajtunk végre, és az ezekhez a feladatokhoz szükséges adatokkal dolgozunk.
Kernel kontextus: érkezik egy hardveres megszakítás, ennek kezelése itt zajlik.
Folyamat kontextus: a folyamattal kapcsolatban hajtunk végre tevékenységeket.
Nem uaz, mint a végrehajtási mód, mert lehetséges az, hogy bizonyos tevékenységeket kernel módban hajtunk végre, de folyamat kontextusban. Amikor hozzá kell férnünk egy folyamat futási adataihoz, veremhez, virtuális memóriájához, stb., a programnak az adminisztratív adatait kezeljük, ezek folyamat kontextusban találhatóak.
</div>

====Környezeti adatok: Mik azok a környezeti adatok egy UNIX-folyamatnál?====
<div class="answer">
A folyamat indításakor megörökölt tulajdonságok. Tulajdonság-érték párok. Pl. a felhasználó bejelentkezik; mi az ő neve. A felhasználó milyen terminált használ, annak milyen képességei vannak. Mi a felhasználó shellje. Az épp futó folyamat néhány tulajdonsága. Olyan tulajdonság, amely egyes folyamatok számára értéket jelentenek. A felhasználók ezeket a set, setenv, export parancsokkal tudják ezeket állítani (és le is kérdezhetik őket). Megörökli az őt elindító folyamat környezetét (hogy melyiket kell épp használni, UNIX-variánstól függ). Amikor a felhasználó bejelentkezik, akkor a környezeti változók beállítódnak, a folyamatok induláskor ezeket a beállításokat megöröklik.
</div>

====libc: A libc-nek mi a feladata rendszerhívások kezelésében?====
<div class="answer">
A felhasználói mód és kernel mód közötti átmenet lebonyolítása.
A folyamat csak meghív egy open(), read(), write(), stb. függvényt, valójában a háttérben bonyolultabb tevékenység zajlik >> meghív egy rendszerhívást a rendszerhívás interfészen keresztül. A rendszerkönyvtárak egyike a libc, a standard C library, ez felel azért, hogy az adott függvényhívásokat (mint a read()) leképezze arra a mechanizmusra, amin keresztül átlépünk kernel módba.
Az implementáció belsejében van egy SYSCALL utasítás (ez hardverfüggő), ez ténylegesen elvégzi az üzemmódváltást egy speciális megszakítás generálásával, aminek eredményeként a CPU átlép védett módba. A kernel pedig kezeli ezt a megszakítást. Ekkor a kernel a CPU regisztereit elmenti, azért, hogy a folyamat futása visszaállhasson a megfelelő állapotba. A feladat végeztével a kernel visszatér a megszakításból (erre is hardverfüggő a megvalósítás), a CPU visszavált felhasználói módba, a libc pedig visszatér a függvényhívásból, amit a folyamat kiadott.
</div>

====/proc: Mi a /proc?====
<div class="answer">
Speciális fájlrendszer-interfész a kernel-adatstruktúrákhoz való hozzáféréshez.
</div>

====Prioritás: Hogyan számítható ki egy kernel módban futó UNIX folyamat prioritása?====
<div class="answer">
* a prioritást a folyamat elalvásának oka határozza meg, tehát a prioritás attól függ, milyen sleep utasítással ment át alvó állapotba
* alvási prioritás pl: 20 - diszk I/O-ra vár; 28 - inputra vár a karakteres terminálról
* kernel módú folyamatoknak (amelyek rendszerhívásokat intéznek) negatív prioritásértékeik vannak, ezeknek van a legmagasabb prioritása ........... (http://home.mit.bme.hu/~meszaros/edu/oprendszerek/segedlet/unix/2_folyamatok_es_utemezes/unix_processes.pdf)
* Több szinten, több időléptékben zajlik. Óraütésenként a prioritási sorok ellenőrzése. 10 óraütésenként RR ütemezés egy soron belül. 100 óraütésenként a prioritások újraszámítása.
</div>

====Rendszerhívások: Igaz-e, hogy a rendszerhívások megszakítással járnak együtt?====
<div class="answer">
Igen, ennek hatására vált védelmi szintet a processzor.
</div>

====Rendszerhívások kontextusa: Milyen kontextusban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
folyamat kontextusban
</div>

====Rendszerhívások módja: Milyen módban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
kernel módban
</div>

====Rendszerhívások módja, kontextusa: Milyen futási módban és kontextusban zajlik a UNIX rendszerhívások kiszolgálása?====
<div class="answer">
Kernel módban fut a kód, és a rendszert hívó folyamat kontextusában. ((az ehhez tartozó ábra jobb felső része))
</div>

====Rendszerhívások programindításkor: UNIX alatt milyen rendszerhívásokra van szükség, ha a felhasználó elindít egy programot (folyamat létrehozása és programkód betöltése)?====
<div class="answer">
* Folyamatot létrehozni a fork() hívással, majd a programkódot betölteni az exec() hívással lehet.
</div>

====rpcgen: Mi az rpcgen program feladata?====
<div class="answer">
* RPC nyelven készült leírásból C programkódot generál. [?]

* Az RPC nyelv alkalmas a szerver interfészének formális leírására. A formális leírásból az rpcgen program képes a szerver és a kliens programok megfelelő részeit, valamint a szükséges XDR konverziós függvényeket elkészíteni C nyelven. Az így kapott C forráskódú modulokat a kliens és szerver alkalmazással kibővítve kapjuk a teljes kommunikáló rendszert.
* XDR (Extended Data Representation, kiterjesztett adatreprezentáció): Többféle egyszerű adattípust definiál, illetve szabályokat határoz meg bonyolultabb adatstruktúrák létrehozására. Az adatstruktúrák meghatározásán kívül az XDR egy formális nyelvet is bevezet az adatok leírására. Az RPC rendszer is ezen nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
* RPC (remote procedure call, távoli eljáráshívás): Az RPC-rendszer egy protokoll-leírást és egy programozói interfészt tartalmaz. Az XDR által definiált formális nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
</div>

====System V IPC: Sorolja fel a UNIX System V IPC elemek közös alapjának részeit!====
<div class="answer">
Minden IPC erőforrás rendelkezik a következő azonosítókkal: kulcs (key), létrehozó (creator), tulajdonos (owner), hozzáférési jogok (permissions)
</div>
====System V: Adja meg a System V üzenetsorok főbb jellemzőit (tömör felsorolást kérünk)!====
<div class="answer">
* diszkrét, tipizált üzenetek
* nincs címzés, üzenetszórás
</div>

====System V: Miért tud az s5fs (System V File System) gyorsabban írni, mint olvasni (az előadás példája alapján)?====
<div class="answer">
* az írás gyors, főleg kis fájlok esetén (több szintű leképzés a kisebb blokkkok miatt), az olvasás azért lassabb (csak a nagy fájlokra), mert azoknak a részeit össze kell vadászni a szétszórtság miatt
* TODO
</div>

====u-terület: milyen jellegű adminisztratív adatok vannak az u-területen?====
<div class="answer">
Azok az adatok, melyek a folyamatok futásakor kellenek. Több infó: lásd adminisztratív adatoknál.
</div>

====UNIX-fajták: Soroljon fel fő UNIX-fajtákat!====
<div class="answer">
Linux, Solaris, BSD, System V, HP/UX, ...
</div>

====UNIX-szabványok: Soroljon fel UNIX-hoz köthető szabványokat (legalább kettőt)!====
<div class="answer">
* POSIX.1 (teljes nevén: POSIX1003.1): C nyelvű szabványos rendszerhívás-interfész
* System V Interface Definition
* X/Open Portability Guide
* - AT&T SVID (pl. SVR4), - IEEE POSIX, - Open Group X/Open, Unix95, Unix98, ... ????
* http://linux.die.net/man/7/standards
</div>

====UNIX-típusok: Soroljon fel UNIX típusokat (a családfa jellemző ágait)!====
<div class="answer">
* System V (AT&T változat; Solaris, SCO),
* BSD (Berkeley változat; SunOS, OpenBSD)
</div>

====Ütemezés: Adja meg a tradicionális UNIX ütemező három legjellemzőbb tulajdonságát!====
<div class="answer">
* preemptív, prioritásos és időosztásos
(Néhány kiegészítés a UNIX-ütemezőhöz:
* nem preemptív kernel módban (a kernel módot végrehajtó folyamatot (pl. rendszerhívás, megszakítás-kezelés) nem lehet kényszeríteni, hogy a CPU használatáról lemondjon egy nagyobb prioritású folyamat javára)
* újraütemezés csak akkor következik be, ha egy folyamat önként lemond a CPU-ról és sleep rendszerhívást hajt végre, vagy a folyamat kernel módból visszatér user módba Nem méretezhető megfelelően. Az algoritmus nem képes rugalmasan alkalmazkodni a folyamatok számának növekedése esetén. A korrekciós faktor nem elég hatékony eszköz.
* A CPU-t adott esetben nem lehet "kiosztani" adott folyamat számára. Nem garantálható fix válaszidő. Nagy rendszerterhelés esetén a válaszidő megnőhet. A UNIX ütemezés épp ezért nem alkalmazható real-time rendszerekben.
* A kernel nem preemptív, ezért az egész rendszert feltarthatja. A felhasználó nem tudja megfelelő módon befolyásolni folyamatai prioritását - a nice szám nem megfelelő eszköz erre a célra.)

</div>

====vfs: Mondjon legalább egy, UNIX VFS-alapú "fájlrendszert", amelynek a célja nem fájlok tárolása!====
<div class="answer">
/dev, /proc, stb.
</div>

====vfs: Soroljon fel UNIX VFS-alapú fájlrendszereket (legalább négyet)!====
<div class="answer">
xfs, zfs, brtfs, nfs
</div>

====Virtuális rendszerhívás: Mi az a virtuális rendszerhívás, miért van rá szükség?====
<div class="answer">
(Klasszikus UNIX-ban nincs, Linux 2.5.x-től felfelé, mai Linux kernelek aktívan használják.)
Vannak bizonyos egyszerű feladatok, amelyek a feladat egyszerűsége ellenére túl sok felesleges művelettel járnak: rendszerhívás intterrupt, kontextusváltás, stb., ezen a helyzeten szeretnénk javítani - próbáljuk lerövidíteni ezt az utat.
Pl. a pontos idő lekérdezése csupán egy megfelelő hardver kiolvasása (egyszerű numerikus érték), mégis sok művelettel jár: gettimeofday(): libc > SYSCALL > kontextusváltás > ..., majd ugyanezen a lépcsőn visszasétálunk a felhasználói folyamatba.
Persze nem mindig lehet leegyszerűsíteni ezt az utat, csak egyszerűbb és biztonságos esetekben, pl. ha egyszerű numerikus értékek, azonosítók kiolvasásáról van szó: pl. folyamatnak mi az azonosítója, processzor lekérdezése, pontos idő lekérdezése...Tehát a felhasználói módból kernel módba történő hosszas váltást szeretnénk elkerülni. Ha nincs ilyen módváltás, akkor a felhasználói címtérben elérünk egyes kernelterületeket > így tényleg egyszerű függvényhívás lesz. Megfelelő előfeltételekkel: csak kockázatmentes feladatokra. Időlekérdezés tipikusan ilyen, ott megtehetjük.A felhasználói címtérben az a tevékenység, amelyet szeretnénk végrehajtani, elérhető legyen. Ezt oldják meg a virtuális rendszerhívások!
A folyamat címterébe a kernel rendszerinduláskor speciális "kernellapot" allokál - ezen a biztonságosnak tekinthető rendszerhívások vannak. Terminálból példa: ldd /bin/bash
</div>

====vnode/vfs: Mi a UNIX vnode/vfs?====
<div class="answer">
* Implementáció-független fájlrendszer absztrakció
* vnode: virtuális csomópont, vfs: virtuális állományrendszer
* inode --> vnode
* fs --> vfs
* Új absztrakció: annak felismerése, hogy több állományrendszernek számos előnye van, szükségessé vette a virtuális csomópont (vnode) és a virtuális állományrendszer (vfs) leíró adatszerkezetek bevezetését. Követelmények, elvárások az állományrendszerrel kapcsolatban:
** egyszerre támogasson több - UNIX, nem UNIX - állományrendszert
** különböző diszk partíciók különböző állományrendszereket is tartalmazhatnak, de mountolás esetén egységet képet kell, hogy mutassanak
** támogassa a hálózati állományok osztott használatát
** modulárisan bővíthető legyen.
</div>

====Zombi állapot: Mi a zombi állapot szerepe egy UNIX rendszerben?====
<div class="answer">
A folyamat már felszabadította a foglalt memóriát, lezárta az állományokat, minden erőforrását visszaadta a rendszernek, csak a proc struktúráját tartja fogva, amiben visszatérési és statisztikai információt tárol a szülő számára. A folyamat szülő wait hívása után szűnik meg.

Megjegyzés: bővebben magyarázattal, előadás alapján:
A folyamat megáll, a UNIX-ban a kernel szeretné ezt a szülőjének is tudomására hozni.
A folyamat már leállt, nem fog tovább futni, de a szülőjét még nem értesítették arról, hogy ez a folyamat megszűnt, esetleg gondoskodjon az újraindításáról, stb.
Pl. egy webszerver: beérkező kérések kiszolgálása --> kliens folyamat indítása, ez megkapja a kérés kiszolgálásának feladatát, a kliens pedig valamikor megáll, a webszerver nem árt, ha értesül róla, hogy hiba vagy normál működés folytán állt le.
Tehát amíg a szülő nem értesült a leállásról, a folyamat zombi állapotban marad. Ha a szülőt nem érdekli, mi történt a gyerekfolyamattal, a zombi állapot hamar megszűnik.
A zombi állapotban a folyamatnak semmilyen saját adatát nem tároljuk, a folyamat összes működéshez szükséges adata megszűnik, kizárólag a kernel adatstruktúrákban, tehát a proc struktúrában marad meg a folyamatnak néhány adminisztratív adata. A ps kilistázhat pl. zombi állapotban lévő feladatokat, mert ezeknet a folyamatoknak az adminisztratív adatai a kernel címterében még megtalálhatóak. De a folyamatok saját címtere, u-terület, stb. már nem létezik. Miután a szülő értesült róla, hogy a gyerekfolyamat meghalt, a kernel törölni fogja a folyamatot a process táblából is, a folyamat kilép a zombi állapotból.
</div>

====Zombi állapot: Igaz-e az, hogy egy zombi állapotban lévő folyamat még memóriaterületet foglal?====
<div class="answer">
Igen, mert a kernel processz táblában még ott vannak az adatai, és az memóriaterületet foglal. (A NEM választ is meg lehet indokolni...) [Indoklás nélkül 0 pont!!!]
</div>

===Windows===

====Alrendszer: Melyik az az alrendszere a Windowsnak, ami nélkül nem tud futni?====
<div class="answer">
A Windows alrendszer, avagy Client/Server Runtime [[SubSystem]] (csrss.exe). Ennek kilövése kékhalált eredményez.
</div>

====API-k: Hogyan oldották meg, hogy az alkalmazások többféle API-n (Win32, POSIX) keresztül is meg tudják hívni a Windows operációs rendszer funkcióit?====
<div class="answer">
* Megoldás: környezeti alrendszerek (environment subsystems): a felhasználónak vagy programozónak nyújtott környezet, személyiség egy részét a környezeti alrendszer folyamatok valósítják meg, minden egyes környezet külön API-t mutat (Windows, POSIX, ...), az operációs rendszer rendszerhívásainak egy részét kínálja a felhasználói alkalmazások számára. (Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx)
* a kernelnek egy definiált interfésze van, ami nem publikus (hivatalos dokumentációja nincsen): NT API >> az ebben lévő függvényeket a fejlesztő ne hívhassa meg közvetlenül. Ehelyett erre két alrendszer épül, ők mutatnak egy API-t az alkalmazások felé: Windows API és POSIX API. (ezek teljesen dokumentáltak!). Az alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni.
* A két alrendszer feladata az, hogy az általuk definiált hívásokat átfordítsák.
* Nem pusztán szintaktikai, hanem szemantikai eltérések is vannak.

(Megjegyzés: Exetype segédeszköz segítségével megnézhető, melyik alrendszert használja egy adott alkalmazás.)

Forrás: http://video.bme.hu/media/video/Operacios_Rendszerek_04ea_20110215.wmv (00:28:29 körül)

(Korábbi:
* Alkalmazás 1>>>Windows API (Windows alrendszer)>>>NT API (NT Kernel)<<<Posix API (Posix alrendszer)<<<Alkalmazás 2 TODO(ehelyett 1 épkézláb mondat kéne)
* alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni
)

</div>

====Executive réteg: Executive (Windows)====
<div class="answer">
Az operációs rendszer magasabb szintű funkcióit szolgáltató rétege (memóriakezelés, biztonság, stb.). Az adatokat objektumokban tárolja, melyeket leírókkal (handle) lehet csak elérni, jól definiált interfészeken keresztül. Bár a kernel funkcióit csak a kernel interfészén keresztül éri el, szintén az ntoskrnl.exe tartalmazza. A legtöbb rendszerhívás itt van megvalósítva.
Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx

(Korábbi: Ez a réteg tartalmazza az NTDLL.DLL által definiált függvények hívásainak megvalósítását, valamint a rendszer külső objektumai közti kommunikáció. Legfontosabb szolgáltató funkciója a lokális eljárás hívás - LPC (Local Procedure Call) megvalósítása. TODO[MZ])
</div>

====Fájlhozzáférések: Mivel azonosítja a Windows a felhasználókat és csoportokat a fájlhozzáférési listákban?====
<div class="answer">
* objektum (SecurableObject) → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* SecurityDescriptor (biztonsági leíró, összefogja a többi elemet) >> Owner (Tulajdonos, megváltoztathatja az objektum engedélyeit, akkor is ha nincs explicit joga), Discretionary Access Control List (DACL, belátás szerinti, erőforrás szintű, hozzáférési lista - hozzáférés szabályozása), SACL (biztonsági naplózás szabályozása - kinek milyen művelete esetén kell naplózni az adott műveletet)
* AccessControlEntry:
** Típus: megengedő, tiltó, audit
** Flag: Pl. öröklődés
** SID: kire vonatkozik
** Maszk: végrehajtás | törlés tulajdonos írása...
* elérési lista (ACL), melyben megadható, hogy mely folyamatok jogosultak az adott section object elérésére ???
* minden objektumhoz tároljuk a hozzá tartozó <tartomány, műveletvégzési jog> párokat ????
* TODO - bőven elég annyi, hogy Security Identifier (SID) segítségével azonosítja
</div>

====Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a felhasználókat és a csoportokat?====
SID - Security Identifier

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
felhasználókat és a csoportokat?
<div class="answer">
Paravirtualizáció esetén fel kell készíteni a vendég OS-t a forráskódjának módosításával, hogy ne is akarjon problémás utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. Ezzel egyszerűsödik a hypervisor implementálása.
</div>

====Felhasználó- és csoportazonosító: Mivel azonosítja a Windows a felhasználókat és csoportokat a hozzáférések ellenőrzése során?====
<div class="answer">
* <Gép SID>-<RID> (SID security identifier - gépspecifikus, RID: relative identifier)
* Jól ismert SID-ek: Everyone: S-1-1-0, Administrator: S-1-5-domain-500
* Vista: szolgáltatások is kapnak SID-et
* objektum → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* TODO
</div>

====HAL: Mi a HAL (Windows)?====
<div class="answer">
* "HAL" - Hardware Abstraction Layer
* A felsőbb rétegek a HAL-on keresztül érik el az alap HW szolgáltatásokat, a HAL szerepe, hogy elfedje a HW megvalósítás részleteit, és egy egységes, platformfüggetlen felületet biztosítson.
* hal.dll fájlban megvalósítva (pl. timer interrupt kezelését, alaplap alapvető felépítését (milyen chipsetek vannak rajta), stb. elfedi a felette lévő rétegektől)
</div>

====Hardverfüggő részek: Melyek a Windows hardverfüggő részei?====
<div class="answer">
* A kernel egyes részei és a HAL.
* Megjegyzés: én ide a drivereket is beírtam, nem vontak le érte pontot, de azt mondták, azokat nem mindig szokás a rendszer részének tekinteni.
</div>

====Jogosultságok szerepe: Mik a jogosultságok (privilege) szerepe a Windows-ban?====
<div class="answer">
* operációs rendszer szintű jog
* meghatározzák azokat a rendszerműveleteket, amelyeket egy felhasználói azonosító elvégezhet. Egy rendszergazda jogosultságokat felhasználóknak és csoportazonosítóknak oszt (http://msdn.microsoft.com/en-us/library/bb530716(VS.85).aspx)
* pl. számítógép leállítása, eszközmeghajtó betöltése
* név: SeShutDownPrivilege, SeLoadDriverPrivilege
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens/Képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerülése: Mi a fő oka, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerültek? Elméleti megfontolások alapján hol lenne a helyük?====
<div class="answer">
Windows NT 4.0-ban került le kernel szintre ez a komponens, hogy kevesebb folyamat- és módváltás legyen (Ne kelljen mindig visszaváltani a csrss.exe-be, majd onnan átváltani kernel módba, utasítani a hardvert, visszaváltani felhasználói módba, majd visszaváltani a felhasználói folyamatba, aki kezdeményezte a változtatást.) (A felhasználói módú folyamatban (csrss.exe) csak a konzol kezelés maradt.) Elméletileg felhasználói szinten kéne lennie.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Windows-ban miért került le az ablakkezelő kernel módba?====
<div class="answer">
Hogy kevesebb kontextus- és módváltás legyen, mivel a Windows szerves része az ablakkezelés, ezért rengeteg user-kernel mód váltás lenne ha a csrss.exe-en keresztül használnánk. Tehát teljesítménybeli okokból.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens előnyei: A Windows OS grafikus komponensének mik az előnyei, hátrányai?====
<div class="answer">
A grafikus komponens kernel módban fut. Emiatt a hibái az egész rendszert magával ránthatják, viszont gyorsabb, mert kevesebb CPU-mód váltás kell a rajzoláshoz.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Mi volt a fő oka annak, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító komponens kernel módba került?====
<div class="answer">
Mert ezek a folyamatok intenzíven használják a hardvert, és futásuk gyorsaságára az egész rendszer teljesítménye érzékeny. A user módban történő megvalósítás a rendszert lelassítaná a gyakori környezetváltás miatt.
</div>

====Kernel: Mi a kernel (Windows)?====
<div class="answer">
A rendszer állandóan memóriában lévő, védett módban futó része. Az NT egyetlen HW függő része, szerepe a HW elfedése a felette található eszközök elől, ezáltal a felette lévő részek már teljesen HW függetlenek. Megvalósítja a szálütemezést, multiprocesszor ütemezést és a TRAP kezelést.
</div>

====Kliens-szerver-modell: Nevezzen meg egy kliens-szerver-modell alapján működő komponenst az NT-ben!====
<div class="answer">
* csrss.exe - Client/Server Run-Time Subsystems (környezeti alrendszerek)
* TODO
</div>

====Memóriafoglalás: Mely utasításokkal és miért történik a memóriafoglalás két lépésben Windows alatt?====
<div class="answer">
* A két lépés: Reserve és Commit. Az első csak címtartományt foglal, amögött nem lesz ténylegesen használható memóriaterület; a másik a már lefoglalt címtartományhoz rendel (virtuális) memóriát.
* A folyamatok címtartományának töredezettsége csökkenthető azzal, ha a címtartományt már akkor előre foglalja, mikor a memóriára még nincs szüksége, és ez nem jár olyan memóriapocsékolással, mintha fizikai memóriát is foglalna ugyanakkor.
</div>

====Munkakészlet (working set): Mit jelent a Windows-ban az egy folyamathoz tartozó munkakészlet (working set) fogalma?====
<div class="answer">
Azon fizikai lapok halmaza, amelyekre a folyamat laphiba nélkül hivatkozhat.
</div>

====NT hardverfüggő rétegei: Sorolja fel az NT hardverfüggő rétegeit!====
<div class="answer">
HAL (Hardware Abstraction Level), kernel
</div>

====NTDLL.DLL: Mi az NTDLL.DLL fő funkciója?====
<div class="answer">
Összeköti a User és Kernel módot. Az Executive függvényeknek megfelelő függvénycsonkok vannak benne.
</div>

====Quantum: Mi a szerepe a quantumnak a Windows ütemezőjében?====
<div class="answer">
* A szálak adott ideig futnak (quantum)
* RR ütemezésnél az időszelet
* Óramegszakításban mérik (clock interval, clock tick) 1 clock tick = ~ 10-15 ms (HALtól függ)
* Quantum hossza: időegység, amíg egy szál fut
* Kliensek esetén a quantum hossza 2 clock tick a háttérben futó folyamatoknak, az előtérben futó folyamatoknak 6 clock tick jut. Így egy CPU-intenzív folyamatról való ablakváltáskor az új, előtérben lévő folyamat arányosan több CPU-időt kap (azonos prioritásokat feltételezve).
* Szervereknél: mindenkinek 12 clock tick a kontextusváltások minimalizálása érdekében. Szervereknél így a kliensek kéréseinek eredményeként felébredő alkalmazásoknak több esélye van befejezni a kérést, és várakozó állapotba kerülni, mielőtt az időszelet véget érne.
* esély annak a folyamatnak, amelynek épp most ért véget a várakozása: a várakozás végén megnöveljük a prioritást, de a quantum eggyel csökken; a quantum végén a prioritást az eredetire csökkenti.
* éhezés elkerülése: az OS másodpercenként megnézni a futásra kész szálakat, és annak, aki nem futott már 300 óraütés óta, 15-ös prioritást ad, megnöveli a quantumját egy quantumnyi futásig
* TODO, hogy a forrás feldolgozása jó-e: http://mit.bme.hu/~micskeiz/opre/files/01-opre-windows-utemezes.pptx

</div>

====Rendszeridő megváltoztatása: A rendszeridő megváltoztatására kinek van joga Windows alatt?====
<div class="answer">
* SeSystemTimePrivilege joggal rendelkező felhasználóknak / azoknak a felhasználóknak, amelyek olyan csoportba tartoznak, amelyekhez hozzá van rendelve a SeSystemtimePrivilege.
* Alapértelmezett beállításként csak az Administrators és Power Users group rendelkezik vele.
* http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx
</div>

====Standby memórialapok listája: Mire szolgál a standby memória lap lista a Windows-ban (miért nem szabad lapként vannak ezek nyilvántartva)?====
<div class="answer">
A lap egy munkahalmaz része volt, de már nem az, elvették tőle. A lap nem módosult, mióta kiírták a merevlemezre, vagy mióta beolvasták. Egy nem Valid laptábla bejegyzés még mutat rá, azaz ha kell, még könnyen életre lehet kelteni a lapot.
</div>

====Szabad (free) és nullázott (zeroed) lapok: Miért van a Windows-ban külön szabad és nullázott (freed és zeroed) memórialap-lista?====
<div class="answer">
Biztonsági okokból. Nem nullázott memóriaterületet odaadni más folyamatnak biztonsági kockázatot jelent.
Tehát a free lapok szabad lapok, de még nem adhatók oda felhasználói folyamatnak, mert "szemetet" vagy érzékeny adatot tartalmazhatnak: nincs nullákkal felülírva a tartalma. A zeroed lapok szabadok, és nullákkal vannak felülírva, tehát odaadhatók felhasználói folyamatnak, amennyiben igény van rá.

TODO: ez így már megfelelő indoklás?

(Korábban:
*Free*: a lap szabad, de nincs 0-kkal felülírva a tartalma, szemét vagy egy előző processz által használt tartalom van benne. Ezt nem adhatja ki közvetlenül a memóriakezelő más processzeknek, mert biztonsági szempontból aggályos adatokat találhatna rajta.
*Zeroed*: szabad és nullákkal felülírt lap, kiadható, ha valakinek kell.
TODO(ez így igaz, csak ebben a formában nem a kérdésre válaszol))
</div>

====Mik a szerepük a szolgáltatásoknak a Windowsban? ====
<div class="answer">
Olyan folyamatok, amik a felhasználói felülettől és belépéstől függetlenül a háttérben futnak, és kibővítik az operációs rendszer alap szolgáltatásait.
TODO?
</div>

====Újrahívhatóság (reentrancy): Mit jelent az, hogy a Windows-ban a rendszerhívások újrahívhatóak?====
<div class="answer">
A rendszerhívásokat több alkalmazás is meghívhatja egyszerre, nem blokkolódnak, ha már valakit éppen kiszolgál az adott rendszerhívás.
</div>

====Védett objektum tulajdonosának speciális joga: Milyen speciális joga van egy védett objektum tulajdonosának az adott objektumra a Windows-ban?====
<div class="answer">
Megváltoztathatja az objektum engedélyeit, akkor is, ha erre nincs explicit joga. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/03-opre-windows-biztonsag.pptx)
</div>

====Verzióleírás: Mit jelentenek a számok és szavak a következő verzióleírásban: "Microsoft (R) Windows (R) 5.01.2006 Service Pack 2 Uniprocessor Free"?====
<div class="answer">
* (MZ) 5.01.2006 a verziószám, major.minor.build formában, 5.1 a Windows XP verzója, 2006 az SP2-es verzió build száma. Uniprocessor = egy processzoros kernel verzió, Free = debug szimbólumok nélküli verzió.
*(MZ) 2011-től kezdve ez már nem része a tananyagnak
* Most computers run a "uniprocessor free" version of Windows, which is a version that runs on a single CPU and does not contain extra errorchecking.
</div>



==Tartalomjegyzék==
<div class="table_of_contents">
__TOC__
</div>

==Források (teljesség igénye nélkül)==
<div class="docs_sources">
Ez előadás diáin, Wikipédiás és egyéb, Google-lel található cikkeken kívül ezek voltak a források, és MÉG ÍGY SEM tartalmazza az összes beugrókérdést (volt olyan, amit rengeteg idő lett volna átszerkeszteni, vagy kevésbé sanszos, hogy olyan hosszúságú beugrókérdést tennének fel, ami ott szerepelt):

* Hivatalos előadásjegyzetek: http://portal.mit.bme.hu/?l=oktatas/targyak/vimia219/jegyzet/index.html
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaBeugrok
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaKisKerdesek
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2007junius12megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008majus20megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008junius11megoldas
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/pelda_beugro_megoldas.pdf
----
* https://vir.sch.bme.hu/dokumentumok/InfoSite/4.%20f%C3%A9l%C3%A9v/Oper%C3%A1ci%C3%B3s%20rendszerek/
* https://vir.sch.bme.hu/document/targyak/opre/opre_beugro.zip (HOSSZÚ)
* https://vir.sch.bme.hu/document/targyak/opre/oprendszkidolg.zip
* Wikipédia
* Google segítségével fellelhető rengeteg forrás
* stb.

-- [[PeteHaro|Pete]] - 2011.06.19.
* [[Media:opre_beugro_ABC.docx|Operációs rendszerek vizsgabeugrók megoldással DOCX-formátumban (szerkeszthető, javítható!)]]
* [[Media:opre_beugro_ABC.pdf|Operációs rendszerek vizsgabeugrók megoldással PDF-formátumban]]

[[Category:Infoalap]]

Operációs rendszerek kidolgozott beugrókérdések vizsgára ABC-sorrendben

2015-06-10T11:00:30Z

Bolla Dávid: /* Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a felhasználókat és a csoportokat? */

==Bevezető==
Korábbi Wiki-n és InfoSite-on szereplő kidolgozott és kidolgozatlan anyagok, számtalan forrásból összeszedve - előadásdiákból, video.bme.hu-n lévő felvett anyagokból, Wikipédiás és egyéb, Google segítségével fellelhető anyagokból kiegészítve.
Hibák előfordulhatnak! TODO-val azokat a részeket jelöltem, amik átnézendők, rendbe szedendők, hiányosak, stb., ezeket is kérlek javítsátok, ha tudjátok! Köszi!
Ami fontos: ABC-sorrendbe rendezve szerepelnek a kérdések, így könnyebben megtalálható, tartsuk is meg ezt a tendenciát!
Remélem hasznát veszitek! -- [[PeteHaro|Pete]] - 2011.06.19.
Valamilyen szintű kategorizálást is beleraktam. A kérdések elejére odaírtam magának a kérdésnek a lényegét is, hogy könnyebben megtalálhatóak legyenek az azonos kérdéskörbe tartozóak.

==Beugrókérdések megoldással==
===Általános jellegű OS-ekkel kapcsolatos kérdések===

====Indulás: Hasonlítsa össze az általános célú (asztali) és a beágyazott operációs rendszereket az indulás szempontjából!====
<div class="answer">
A beágyazottnál először indul az alkalmazás, és az indítja az operációs rendszert, az asztalinál az operációs rendszer indítja az alkalmazásokat.
</div>

====Inkrementális mentés: Mit jelent az inkrementális mentés?====
<div class="answer">
Csak a változtatásokat mentjük az előző mentéshez képest -> kisebb helyet foglal, hamarabb végez a mentés.
</div>

====Kemény valós idejű rendszer: Adja meg a kemény valós idejű (hard real-time) rendszer definícióját!====
<div class="answer">
A rendszer adott eseményekre adott időn belül 1 valószínűséggel válaszol (egyébként hibás, hiába funkcionálisan jó a válasz). A rendszer NEM késhet!
</div>

====Lazán csatolt rendszer: Milyen szinkronizációs kényszereket jelent, ha egy lazán csatolt rendszer kommunikációja során véges kapacitású csatornát alkalmazunk?====
<div class="answer">
ha a küldő folyamat túl gyorsan küldözget, akkor a csatorna megtelik, úgyhogy túlcsordulás lesz, ami miatt a küldőnek várnia kell mielőtt újra küld.
</div>

====Rendszerhívások: Milyen előnnyel jár a rendszerhívások valamilyen magas szintű programnyelvvel történő megadása?====
<div class="answer">

Az API elrejti a rendszerhívások részleteit, bonyolultságát a programozó elől, lényegében egy wrapper réteggel fedi be a rendszerhívásokat.

</div>

====RPC: Milyen részekből áll az RPC technológia?====
<div class="answer">
* RPC: Remote Procedure Call, távoli eljáráshívás. Magas szintű folyamatok közti kommunikációt tesz lehetővé. Részei:
* a hívható eljárások és típusaik (interfész) leírása
* programgenerátor - rpcgen: a leírásból C programkódot generáló program
* kommunikációs infrastruktúra - portmapper: a programazonosítók és a hálózati portok összerendelése
</div>

====Statikus/dinamikus OS: Mikor nevezünk statikusnak, illetve dinamikusnak egy operációs rendszert?====
<div class="answer">
statikus: azok a rendszerek, amelyeknek muködése során - a felépülés és inicializálás kezdeti szakaszától eltekintve - nem jönnek létre és nem szűnnek meg folyamatok. dinamikus: működés közben bármikor születhetnek illetve megszünhetnek folyamatok.
</div>

====Szorosan csatolt rendszerek: Milyen rendszereket nevezünk "szorosan csatolt" rendszereknek?====
<div class="answer">
Ahol több CPU közös óra és közös memória segítségével működik együtt. Általában egyetlen operációs rendszer van, de az bonyolult. (Megjegyzés: az architektúrákból megtanult "közös erőforrást használnak" definícióra csak fél pontot adtak.)
</div>

===Erőforrás-hozzáférés===

====Elosztott rendszerek: Elosztott rendszerekben milyen konzisztencia kérdésekkel kell foglalkozni?====
<div class="answer">
* frissítés konzisztencia
* másolat konzisztencia
* cache konzisztencia
* hiba konzisztencia
* óra konzisztencia
* felhasználói interfész konzisztencia
</div>

====Erőforrás-gazdálkodás: Mi a különbség a hierarchikus és a globális erőforrás-gazdálkodás között?====
<div class="answer">
hierarchikus: a gyermek folyamatok csak a szülő erőforrásaiból részesülhetnek, és nem létezhetnek önállóan, csak amíg a szülőjük is létezik. globális: a rendszer valamennyi folyamata létrejötte után egyenrangú, önálló szereplő, és versenyezhet a teljes erőforráskészletből való részesedésért.
</div>

====Éhezés: Mi az az éhezés?====
<div class="answer">
A folyamatnak megvan mindene, ami a futásához kellene (ezért nem holtpont), de az erőforrásokat, amiket használni akar, más folyamatok kapják meg (ezért nem tud futni).
</div>

====Graceful degradation: Mit jelent a "graceful degradation" fogalma? ====
<div class="answer">
Fokozatos leromlás/összeomlás: Ha a rendszer terhelése eléri az ún. könyökkapacitást, akkor utána viselkedése megváltozik, a tovább növekvő terhelésre már egyre rosszabb működéssel reagál (overhead). Elvárható, hogy ezt fokozatosan tegye (ne omoljon össze).
</div>

====Kölcsönös kizárás====
<div class="answer">
Annak biztosítása, hogy a közös erőforrást egy időben csak annyi magában szekvenciális feladat használja, amely mellett a helyes működése garantálható.
A kölcsönös kizárást meg kell oldanunk a programban. Többnyire a használt erőforrást lock-oljuk (elzárjuk): nem engedjük hozzáférni a többi részfeladatot.
</div>

====Kritikus szakasz: Mit jelent a kritikus szakasz?====
<div class="answer">
A magában szekvenciális feladatok azon kódrészletei, amely során a kölcsönös kizárást egy bizonyos közös erőforrásra biztosítjuk. A kritikus szakasz a kérdéses közös erőforráshoz tartozik. A kritikus szakaszt a hozzá tartozó erőforrásra atomi műveletként (nem megszakítható módon) kell végrehajtanunk.
</div>

====Monitor: Mi a monitor alkalmazásának lényege? (Kölcsönös kizárás)====
<div class="answer">
A lockolás nem szétszórva történik a programban, hanem egyetlen, a közös erőforráshoz szorosan tartozó programrészletben.
</div>

====Prioritás öröklés: Mi a prioritás öröklés (Priority Inheritance, Pl) protokoll lényege? (prioritás inverzió témakör)====
<div class="answer">
Az alacsony prioritású feladat megörökli az általa kölcsönös kizárással feltartott feladat prioritását a kritikus szakaszából való kilépéséig. Csak részben oldja meg a prioritás inverzió problémáját.
</div>

====Test-and-set: Hogyan lehet Test_and_Set utasítással kritikus szakaszba lépést (entry) és kilépés (exit) megvalósítani?====
<div class="answer">
* Belépésnél csökkentjük a value értékét ezzel jelezve hogy használni akarjuk a kritikus szakaszt
* Kilépésnél növeljük a value értékét
Egy változót kijelölünk "lock object"-nek; ha ennek a tartalma 0, nincs senki a kritikus szakaszban. A kritikus szakasz elején egy ciklusban test-and-set-et hajtunk végre rá (az utasítást a ciklus feltételébe téve); ha valaki van a szakaszban már, a ciklusban fogunk keringeni, amíg ki nem lép belőle a másik. Amikor kilépett, a test-and-set következő végrehajtása beállítja a változót, és továbbengedi az egyik várakozó ciklust. A szakaszból kilépéskor pedig simán (nem test-and-set-tel) 0-ba állítjuk.
</div>

====Test-and-set: Hogyan működik a test_and_set?====
<div class="answer">
Visszaadja egy bit értékét, és ha 0 volt, 1-re állítja. Mindezt oszthatatlanul, vagyis ha 0 volt ott, és többen egyszerre hívtak rá test-and-set-et, akkor az egyiké teljesen lefut, 1-be állítja és nullát ad vissza, mielőtt a többi elkezdene futni (így ők mind 1-et fognak visszaadni)
</div>

====Újrahívhatóság: Mit jelent az újrahívhatóság (reentrancy) fogalma?====
<div class="answer">
A közös erőforrás problémájának egyfajta kiterjesztett esete egy függvényen/objektumon belül, mely akkor léphet fel, amennyiben ezt a függvényt/metódust egyszerre többen is meghívhatják. Előfordulhat akkor, ha ugyanazt a függvényt hívjuk egy taszkból és egy megszakítás-rutinból is, vagy ha preemptív ütemezés esetén ugyanazt a függvényt hívjuk két taszkból is.
</div>

===Holtpont===

====Definíció: Adja meg a holtpont definícióját!====
<div class="answer">
Egy rendszer folyamatainak egy H halmaza holtponton van, ha a H halmazba tartozó valamennyi folyamat olyan eseményre vár, amelyet csak egy másik, H halmazba tartozó folyamat tudna előidézni. Másként: A közös erőforrások hibás beállítása vagy használata miatt a rendszerben a részfeladatok egymásra várnak » nincs futásra kész folyamat; » nem jöhet létre belső esemény; » A rendszer nem tud előrelépni.
</div>

====Foglalva várakozás: Holtpont megelőzése (prevention) esetén milyen módszerrel lehet a foglalva várakozás előfordulását kizárni?====
<div class="answer">
* Az erőforrást birtokló feladat kér újabb erőforrást.
* Minden szükséges erőforrást egyben kell lefoglalni, egyetlen rendszerhívással.
* Alkalmazástól függ a használhatósága.
* Erőforrás-kihasználás romlik.
* A foglalva várakozás elkerülhető, ha minden folyamat betartja azt a szabályt, hogy az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el. A szabály betartásával megelőzhető a holtpont, de ára az erőforrás-kihasználás jelentős romlása.
* Ha a folyamatokat kötelezzük arra, hogy minden erőforrásukat egyszerre kérjék el. Ha meg akarjuk engedni a rákérést, akkor menthető állapotú erőforrások esetén megtehetjük, hogy a várakozó folyamatoktól elvesszük az erőforrásaikat.
</div>

====Kezelése: Az operációs rendszer milyen általános eljárásokat használhat a holtpont kezelésére?====
<div class="answer">
* strucc algoritmus (nem vesz róla tudomást)
* holtpont feloldása - melyik holtpontban érintett folyamatot számoljuk fel?
* menthető állapotú erőforrások elvétele,
* minél kevesebb folyamat felszámolása,
* folyamatok prioritása,
* már elvégzett munka,
* folyamatok visszaállíthatóságának biztosítása
* holtpont megelőzése
</div>

====Kialakulás szükséges feltételei: Sorolja fel a holtpont kialakulásának szükséges feltételeit!====
<div class="answer">
* Kölcsönös kizárás: Vannak olyan erőforrások a rendszerben, melyeket a folyamatok csak kizárólagosan használhatnak.
* Foglalva várakozás: legyen olyan folyamat mely lefoglalva tart erőforrásokat, miközben más erőforrásokra várakozik.
* Nincs erőszakos erőforrás-elvétel: a folyamatok addig birtokolják az erőforrást, míg saját jószántukból fel nem szabadítják azokat.
* Körkörös várakozás: Létezik a rendszerben egy olyan folyamatsorozat, melyben minden folyamat az utána következő folyamat által foglalt erőforrásra vár, a sorozat utolsó tagja pedig a sorozat első tagjára.
</div>

====Megelőzés, elkerülés: Mi a különbség a holtpont megelőzése (prevention) és holtpont elkerülése (avoidance) között?====
<div class="answer">
* megelőzése: olyan rendszert tervezünk, ahol nem teljesülnek a holtpont feltételei, így elvileg sem lehet holtpont.
* elkerülése (pl. bankár algoritmus): A rendszer minden erőforrásigény kielégítése előtt mérlegeli, hogy nem vezet-e holtpontveszélyre a kérés teljesítése, más szóval fennmarad-e a biztonságos állapot.

* ( Kölcsönös kizárás minimálisra csökkentése: lehetőleg többpéldányos erőforrásokat alkalmazunk, ahol ez nem lehetséges, ott a hozzáférést megpróbáljuk oszthatatlan műveletté tenni.
* Foglalva várakoztatás megszüntetése: Ha minden folyamat betartja a szabályt, miszerint az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el, akkor elkerülhető a foglalva várakoztatás. Ennek ára van: az erőforrás-kihasználtság romlása.
* Nincs erőszakos erőforrás-elvétel kiküszöbölése: Ha menthető állapotú erőforrásaink vannak, akkor megtehetjük, hogy elvesszük egy adott folyamat erőforrását és egy másiknak adjuk, majd annak lefutása után visszaadjuk a régi állapotában az erőforrást az első folyamatnak.
* Körkörös várakozás megakadályozása: A folyamatok megegyeznek az erőforrások sorszámozásában, minden folyamat csak nagyobb sorszámú erőforrást igényelhet azoknál az erőforrásoknál melyeket birtokol. Ekkor biztosan nem alakulhat ki kör.)
</div>

===Fájlrendszerek===

====Fájl: Mi a fájl az operációs rendszer szempontjából? (háttértár-kezelés)====
<div class="answer">
* a fájl a permanens táron az adattárolás logikai egysége, az operációs rendszer feladata a logikai egységek (fájlok) leképzése valódi fizikai egységekre, ez az OS-ben egy többszintü réteges rendszer
* Absztrakt adattípus (objektum, fájl mutató).
* Adat, név (name - elnev. konvenciók), típus (type - kezelés módja) tulajdonságok (attributes). Tulajdonosok, jogosultságok. Hozzáférési időpontok
* Kölcsönös kizárás (file locking)
* TODO
</div>

====Háttértáron lévő lapok: Milyen részidőkből áll össze a háttértáron levő lapokhoz való tényleges hozzáférési idő? Kis vagy nagy lapok használata esetén kapunk "jobb" byte hozzáférést?====
<div class="answer">
* adatátviteli sebesség + fejmozgás sebessége + lemezek forgási sebessége
* nagy lapok esetén ( mert így közvetlenül egymás után helyezkednek el az összetartőző adatok így nem kell a fejnek "ugrálnia" )
* Először a laptáblából kell kikeresni a lap bejegyzését, és konstatálni, hogy nincs hozzá fizikai lap rendelve. Majd, ki kell választani egy szabad fizikai lapot (ha nincs, ki kell vinni egyet háttértárra), a szabad helyre beolvasni a lapot, majd újraindítani a laphibát okozó utasítást. Ezek közül a háttértárról olvasás nagyságrendekkel lassabb a többinél, ezért lényegében ez határozza meg a teljes hozzáférési időt.
* Ha csak a háttértáron lévő lapokat nézzük, akkor, mivel kisebb lapot gyorsabban lehet beolvasni, ezért kisebb lapoknál gyorsabb a hozzáférés. Ha egy folyamat teljes munkahalmazát nézzük, akkor viszont a kisebb lapok több adminisztrációs költséggel járnak (gyakrabban kell háttértárhoz fordulni), és átlagban a nagyobb lapok adnak jobb eredményt.
</div>

====Indexelt tárolás: Sorolja fel az indexelt tárolás (indexed allocation) előnyeit és hátrányait! (Fájlrendszer-leképzés)====
<div class="answer">
* Szekvenciális és indexelt elérésre is alkalmas.
* Sérülékeny (az index blokkok sérülése a fájlt elérhetetlenné teszi).
* Az index blokkokat viszont könnyű többszörözni (replikálni).
* Sok fejmozgást okoz (seek), a blokkok el vannak szórva a diszken.
* Itt is lehet a láncolt listás töredezettség mentesítéshez hasonló algoritmusokat használni a fejmozgás minimalizálására.
</div>

====RAID: Sorolja fel a RAID technika leglényegesebb elemeit!====
<div class="answer">
* Használjunk több merevlemezt egyszerre.
* Több redundáns alkalmazása növeli a megbízhatóságot.
* Több párhuzamos használata növeli a sebességet.
* Hozzunk létre egy virtuális diszket a fizikai diszkekből.
* Redundant Array of Inexpensive Disks: több lemez összekapcsolása.
* A RAID-0 esetében két lemezre vannak szétosztva az adatok, így egyetlen fájlt kétszer akkora sebességgel lehet írni (a két felét parhuzamosan).
* A RAID-1 esetében ugyanazt az adatot tároljuk le a két lemezen, így gyorsabb nem lesz, de az egyik lemez hibája esetén visszanyerhetőek az adatok.
* Megjegyzés: ez csak példa, több lemezzel is lehet csinálni, a sebesség/tárhely/hibatűrés között különböző kompromisszumokat elérve.
</div>

====RAID0 vs. RAID1: Hasonlítsa össze két azonos diszkből álló RAID0 és RAID1 tömb tulajdonságait! Hogyan alakul a hozzáférési idő, az adatátviteli sebesség és a megbízhatóság egyetlen diszkhez képest a két esetben?====
<div class="answer">
RAID 0-1 szabványok általában SW implementációval és kevés (2db) diszkkel
* RAID 0 (striped disks):
** Több diszk párhuzamos használata;
** file részei N diszkre kerülnek;
** Az egyes részek egymástól függetlenül elérhetők
** A diszkek tárolókapacitása összeadódik
** N azonos diszk esetén a RAID 0 virtuális diszk olvasásai és írási adatátviteli sebessége maximum N-szeres közelébe nő.
** A hozzáférési idő közel eléri egy diszk hozzáférési idejét.
** Bármelyik diszk meghibásodása esetén az adat elveszik
* RAID 1 (mirroring):
** Több diszk redundáns használata.
** A file minden része minden (N) diszkre kikerül.
** Azonos diszkeket feltételezve a tárolóterület egy diszk tárolóterületével azonos.
** Az adatátviteli sebesség lassabb, mint egy diszk sebessége.
** A hozzáférési idő nő.
** Speciális esetben az olvasási sebesség N-szeresre nőhet, feltételezve a diszk meghibásodásának más módon történő észlelését (nem kell az azonosságot ellenőrizni többségi szavazással).
** Egy működőképes diszk esetén az adat elérhető.
</div>

====RAID5: Adja meg az M (M pozitív egész szám) diszket tartalmazó RAID5 tömb tulajdonságait! (hibatűrés és sebesség)====
<div class="answer">
* RAID 5 (block interleaved distributed parity).
* Több diszk redundáns és párhuzamos használata
* Adat és paritás elosztása N+1 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 1 diszk meghibásodása esetén az adat elérhető.
** 2 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error). A 2. meghibásodás észlelése a tömb újraépítése során)
</div>

====RAID5: Miért előnyös és miért hátrányos RAID5 használata?====
<div class="answer">
* + N azonos diszk esetén az olvasási és írási adatátviteli sebessége maximum N-szeres közelébe nő.
* + 1 diszk meghibásodása esetén az adat elérhető.
* - 2 vagy több diszk meghibásodása esetén az adat elveszik.
* - Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error).
* -Bonyolultabb, mint a Raid 0/1, ezért hardveresen valósítják meg, ami viszont drága
</div>

====RAID6: Adja meg a 8 darab 1 Tbyte-os HDD-ből álló RAID6 tömb tárolókapacitását!====
<div class="answer">
6 TB. (Adat és paritás elosztása N+2 diszkre. A kapacitása N diszk tároló kapacitásával egyenlő.)
</div>

====RAID6: N db azonos diszkből álló RAID6 tömb esetén a tömb tárolókapacitása és sebessége (nagy fájlok írása/olvasása során elérhető adatátviteli sebesség) hogyan viszonyul az egyetlen diszk azonos adataihoz?====
<div class="answer">
* RAID 6 (block interleaved dual distributed parity)
* Több diszk redundáns és párhuzamos használata.
* Adat és paritás elosztása N+2 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 2 diszk meghibásodása esetén az adat elérhető.
** 3 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nagyobb valószínűséggel állítható helyre a RAID 5-höz képest
* Minimum négy lemezre van szükség a RAID 6 működéséhez. The capacity of the array is (N-2) times the size of the smallest member disk for the array of N disks.
* Az olvasási sebesség (N-2)-szerese egy lemez olvasási sebességének - two disks in the row hold a parity which is useless to read. Such read speed values are roughly the same as in RAID 5.
</div>

====Tárolás egysége: Mi a logikai és mi a fizikai tárolás egysége a permanens táron?====
<div class="answer">
* logikai egység: fájl (file)
* fizikai egység: adatblokkok (cilinder, sáv és szektor együtt azonosítja az írható/olvasható adatblokkot; OS képzi le a logikaiakat fizikaiakra)
</div>

===Folyamatok, szálak===

====Bernstein feltétele: Mikor lehet két tevékenységet (utasítássorozatot) párhuzamosan végrehajtani (Bernstein)?====
<div class="answer">
Bernstein feltétele:
* Legyen <math> P_i </math> és <math> P_j </math> két darabja egy programnak.
* A <math> P_i </math> összes bemeneti változója <math> I_i </math>, és az összes kimeneti változója <math> O_i </math>, ugyanez <math> P_j </math> -re <math> I_j </math> és <math> O_j </math>.
* A két program párhuzamosan végrehajtható (vagyis független), ha: <math> I_j \bigcap O_i = 0 </math>, <math> I_i \bigcap O_j = 0 </math> és <math> O_i \bigcap O_j = 0 </math>
</div>

====Feladatok (task) együttműködése: Hasonlítsa össze a közös memórián illetve az üzenetváltáson alapuló folyamatok közti együttműködést!====
<div class="answer">
Közös memórián keresztül történő adatcsere esetén az együttműködő folyamatok mindegyike saját címtartományában lát egy közös memóriát. A közös memória elérését valamilyen adatátviteli rendszer teszi lehetővé. Üzenetváltásos adatcsere esetén a folyamatoknak nincs közös memóriája. Az adatátviteli rendszer most a logikai processzorokat kapcsolja össze. Rajta keresztül a folyamatok üzeneteket tudnak küldeni, illetve fogadni. Az üzenetküldésre a folyamatok logikai processzorainak utasításkészletében megfelelő utasítások állnak rendelkezésre. Ezek a Küld (Send) és a Fogad (Receive) műveletek.
</div>

====Folyamat: Definiálja a "folyamat" (process) fogalmát!====
<div class="answer">
* Egy program futás alatt álló példánya a folyamat.
* saját kód, adat, halom, verem
* A folyamatok nem férnek hozzá egymás lapjaihoz (védettek más folyamatoktól)

* végrehajtás alatt álló program (program maga a végrehajtható kód), amely folyamat virtuális címterébe van leképezve
* folyamat egy szála az, ami éppen fut egy CPU-n, és nem maga a folyamat
* minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát
* privát virtuális címtér (virtuális memóriacímek készlete, amiket a folyamat használhat)
* tartozik hozzá egy egyedi folyamatazonosító (process ID)
* rendszererőforrások listája, melyekhez a folyamat összes szála hozzáfér
* a folyamat virtuálisan összefüggő memóriát lát (virtuális memória) (valójában az összefüggő memóriaterület ritka)
* háttértárolóra is kiírható (swapping)
* A folyamat által látott logikai címtartomány, és a ténylegesen használt fizikai címtartományok teljesen elkülönülnek
* Folyamatok megoszthatnak memóriaterületeket olvasás- vagy akár írás- és olvasás-hozzáféréssel (Az ilyen memória területek több folyamat virtuális címtartományába vannak belapozva)
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 IPC (Inter-process communication) megoldást!====
<div class="answer">
* '''Jelzés''': rendszerüzenetek küldése és fogadása a folyamatok között, jellemzően utasítások továbbítása egyik folyamattól a másiknak
* '''Üzenetsor''': aszinkron kommunikációs forma, mely során a küldő és fogadó közvetlen interakciója nem szükséges, az üzenetek addig tárolódnak a sorban amíg a címzett fel nem dolgozza azokat vagy a sor meg nem telik
* '''Szemafor''': absztrakt struktúra amely a folyamatok közötti közös erőforrásokért való hozzáférést vezérli
* '''Közös memória''': ugyan az a memóriaterület kerül kiosztásra több különböző folyamatnak, írási és olvasási joggal egyaránt

''Forrás'': http://en.wikipedia.org/wiki/Inter-process_communication
</div>

====Folyamatok vs. szálak: Mi az eltérés a folyamatok illetve a szálak között, és milyen előnnyel jár a szálak alkalmazása?====
<div class="answer">
A szálak lényegében párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
</div>

====Java-szálak: Milyen módokon képezheti le a JAVA virtuális gép a JAVA natív szálakat a hoszt operációs rendszer folyamataira/szálaira?====
<div class="answer">
A JAVA virtuális gép egy folyamat a hoszt operációs rendszeren belül. A JAVA szálak feleltethetők meg a hoszt operációs rendszer szálainak, ez többnyire one-to-one (JAVA szál egyben OS szál is) napjainkban. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/20100507_ZH_megoldas.pdf)
Kovácsházy Tamás válasza:
7. fólia, 11. fólia:
JAVA (VM a folyamat, VM-en belül szál):
* Thread osztályból származtatva
* Runnable interface megvalósítása
* A JAVA platform-specifikusan valósítja meg a szálat:
* Natív OS specifikus szál (one-to-one, tipikus).
* JAVA specifikus szálak (many-to-one) egy natív OS szálra vagy folyamatra leképezve.
* many-to-many leképzés (erőforrás szempontok miatt, egyre ritkább).

</div>

====PRAM: Mi történik a PRAM modellben írás-írás ütközés esetén?====
<div class="answer">
Az írás-írás ütközésekor valamelyik művelet hatása érvényesül, a két beírni szándékozott érték valamelyike írja felül a rekesz tartalmát (versenyhelyzet), harmadik érték nem alakulhat ki.
</div>

====Processzor-affinitás: Mit állítunk be, ha egy szálnak beállítjuk a processzor affinitását, és miért lehet arra szükség?====
<div class="answer">
* processzoraffinitás: minden szál rendelkezik egy maszkkal, amely kijelöli, hogy a szál mely processzorokon képes futni
* szerepe: ez alapján dől el, hogy a szál mely processzoron fog futni
* ütemezésnél: multiprocesszoros esetben a processzor kiválasztása a processzor-affinitás alapján történik
* A feladat más processzorra, vagy processzormagra kerülése csökkenti a végrehajtás sebességét (pl. cache-elésnél) >> Cél: A feladatot ugyanazon a végrehajtó egységen tartani - Laza vagy kemény processzor affinitás (soft or hard processor affinity).
** Laza: Nincs garancia, de törekszik rá az OS (többnyire alapeset)
** Kemény: Biztosan ugyanazon a CPU-n marad (rendszerhívással)
</div>

====Szál: Definiálja a "szál" (thread) fogalmát!====
<div class="answer">
* párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk és saját vermük van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak, vagyis egymás adatait olvashatják és írhatják. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
* A folyamat egy szála az, ami éppen fut egy CPU-n (ami ütemezésre kerül), és nem maga a folyamat.
* Minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát (szál nélkül a folyamat programja nem futhat).
* szálak még véletlenül sem hivatkozhatnak más folyamatok címterére, hacsak a másik folyamat nem teszi elérhetővé privát virtuális címterének egy részét megosztott memóriaszakaszként (file mapping object a Windows API-ban), vagy - Windows-nál - hacsak egyik folyamatnak nincs joga megnyitni más folyamatot, hogy olyan folyamatok közti memóriafüggvényeket használjon, mint a ReadProcessMemory vagy WriteProcessMemory
* A szál önmagában szekvenciális kód, a végrehajtás legkisebb egysége. Egy adott folyamat szálainak közös az adat- és kódszegmensük, a halmuk (heap), és az egyéb erőforrásokat is közösen használják, de saját virtuális CPU-t látnak, és saját veremmel rendelkeznek.
* TODO
</div>

====Védelmi tartományok: Mi a különbség a statikus és a dinamikus védelmi tartományok között?====
<div class="answer">
Statikus védelmi tartományok esetén az egy folyamathoz tartozó védelmi tartomány a folyamat végrehajtása során nem változik, míg dinamikus védelmi tartományok esetén igen.
</div>

====Virtuális gép: Mi a virtuális gép koncepció lényege?====
<div class="answer">
* A programok elől az operációs rendszer elfedi a hardver implementációs részleteit, és kibővíti azt plusz funkciókkal.
* Az op.rendszer egy olyan réteget képez a hardver fölött, mely elrejti annak körülményességét és bonyolultságát a programozó elől és kibővíti a hardver szolgáltatását. A felhasználó így egy sokkal kellemesebb virtuális gépet (virtual machine, extended machine) lát.
* Az operációs rendszer egy kényelmesen kezelhető virtuális gépet jelenít meg a felhasználói és a programozói felületen.
</div>

===Jogosultságok===

====Belső biztonság: Mi a belső biztonság?====
<div class="answer">
Belső biztonság = védelem. Védelemnek nevezzük az eljárásoknak és módszereknek azon rendszerét, amely lehetőséget teremt a számítógép erőforrásainak programok, folyamatok illetve felhasználók által történő elérésének szabályozására.
</div>

====Engedélyezés: Definiálja az engedélyezés (authorization) fogalmát!====
<div class="answer">
* jogosultság ellenőrzése: milyen adatokat és szolgáltatásokat érhet el ez a személy?
* Hozzáférés-szabályozási listák (Access Control List, ACL)
* Alapelv: mindig csoportnak osztunk jogot
* Pl. biztonsági házirend, fájl ACL

TODO!!!
</div>

====Jogosultság + engedélyezési sémák: Mi a jogosultság fogalma, mi a kapcsolata az engedélyezési sémák többi alapfogalmával?====
<div class="answer">
* A jogosultság egy reláció a szereplők és védett objektumok között.
* engedélyezés ált. sémáinál: szereplő>>>szereplőt leíró adatszerkezet>>>biztonsági szabályzat (policy), JOGOSULTSÁG>>>védett objektumok TODO
* Jogosultságkezelés alapjai: A rendszer működése során
** A szereplők műveleteket kezdeményeznek
** A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját
** A jogosultsági döntő komponens kiértékeli kontextust és engedélyezi vagy megtiltja a műveletet
** A jogosultsági végrehajtó komponens biztosítja, hogy a döntő által hozott döntés érvényre jusson
* NT: SMR (Secure Reference Monitor) - objektumok elérési jogosultságainak ellenőrzése
* NT: Az LSA a SAM segítségével azonosítja a felhasználót és jogosultságait. Ha a felhasználó jogosult bejelentkezni, a logon elindítja a számára kijelölt shellt
* UNIX: hozzáférési jogosultságok (owner, group, others, read, write, execute)
* Engedélyezés általános sémái: >>Szerep alapú hozzáférés-vezérlés >>Hozzáférési jogosultság listák
* TODO
</div>

====Külső biztonság: Mit takar a külső biztonság fogalma?====
<div class="answer">
Annak mértéke, hogy mennyire lehetünk biztosak a számítógépes rendszer, illetve a rendszerben tárolt adatok sérthetetlenségében.
</div>

====Művelet kontextusa: Engedélyezési rendszerekben mit tartalmaz egy művelet kontextusa? (Felhasználó- és jogosultságkezelés)====
<div class="answer">
A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját.
</div>

===Hibakeresés===

====DTrace: Mi a Solaris DTrace megoldás célja?====
<div class="answer">
dinamikus hibakereső rendszer, nyomkövető eszköz, amivel a rendszer és a programok működését futási időben lehet megfigyelni.
</div>

===Memória===

====32 bit: 32 bites kliens Windows operációs rendszer maximum mennyi fizikai memóriát kezelhet, és miért?====
<div class="answer">
Legfeljebb 4 GB-ot (bár néha kevesebbet lát az OS, mert a memóriatartomány felső részére I/O eszközöket szoktak berakni, ld. pl. videókártya-memória...): ''"kliens Windowsok nem használják a gépben lévő PAE támogatást, mert az a tapasztalat, hogy a kliensekben lévő eszközök meghajtói nem kezelik le rendesen a 4 GB-nál több fizikai memóriát"''.
(https://wiki.sch.bme.hu/pub/Infoalap/OpRe/02-opre-windows-memoria.pptx)
(nem támogatják a PAE-t eleve, csak patch-csel)
(_"However, "client" versions of 32-bit Windows (Windows XP SP1 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility and licensing reasons, even though these versions do run in PAE mode if NX support is enabled."_ - http://en.wikipedia.org/wiki/Physical_Address_Extension)
</div>

====32 bit: 32 bites szerver Windows képes-e 4 GB-nál több fizikai memória kezelésére? Válaszát indokolja!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével (ezzel lehet 32 bites címbuszú CPU-val is 64 GB memóriát kezelni a maximális 4 GB helyett).
</div>

====32 bit: 32 bites Windows használata esetén egy felhasználói folyamat maximum mekkora virtuális címteret használhat?====
<div class="answer">
Alapból 2GB felhasználói módú címterületet használhat, ez a /3GB kapcsolóval 3 GB felhasználói címterületre bővíthető.
</div>

====32 bit: 32 bites Windows szerver operációs rendszerek képesek-e 4 GB-nál több fizikai memória kezelésére? Indokolja válaszát!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével.
</div>

====32 bit: 32 bites x86-os (Windows) esetén mekkora a felhasználói és a rendszer mód címtartomány mérete?====
<div class="answer">
Alapból 2GB felhasználói módú és 2GB kernel címterület van, ezt a /3GB kapcsolóval 3GB felhasználói és 1GB kernelre lehet módosítani.
</div>

====Bélády-anomália: Mit nevezünk Bélády-anomáliának?====
<div class="answer">
FIFO algoritmusnál egyes esetekben, ha a munkahalmaz méretét növeljük, a várakozásokkal ellentétben a laphibák száma is nő.
</div>

====Címfordítás: Hogyan történnek a címfordítások, ha az OS szegmens- és lapszervezést is használ a memóriánál?====
<div class="answer">
CPU --> Segmentation unit --> Paging unit --> Physical memory
</div>

====Címfordítás: Milyen címtranszformációk történnek együttes szegmens- és lapszervezésű memória használata során?====
<div class="answer">
* CPU >>>[Logical Address]>>> '''Segmentation Unit''' >>>[Linear Address]>>> '''Paging Unit''' >>>[Physical Address]>>> Physical Memory (http://portal.mit.bme.hu/?l=oktatas%2Ftargyak%2Fvimia219%2Fjegyzet%2F2011%2Fslides_17_memory.pdf)
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/oprewiki1.pdf, 48. oldaltól.
* Változó méretű szegmensek fix méretű lapokat tartalmaznak. Kicsi mind a belső, mind a külső tördelődés. A cím felépítése: (szegmens szám, lapszám, lapon belüli eltolás)
* Hasonlít a szegmensszervezéshez és a kétszintű lapszervezéshez: A memóriában szegmensek vannak ugyan, de ezek lapokból épülnek föl. Van szegmenstábla, és minden bejegyzéséhez tartozik egy laptábla is. Külső töredeződés nincs, belső töredeződés minimális (szegmensenként átlag fél lap); ez a kombinált módszer egyesíti a két módszer előnyeit
* TODO
</div>

====Lapszervezés, keret tábla: Lapszervezés esetén mit tartunk nyilván a keret táblában (frame table)?====
<div class="answer">
Az üres kereteket (frames).
</div>

====Logikai vs. fizikai memória: Mi a különbség a logikai és a fizikai memória között?====
<div class="answer">
A logikai memória a fizikai tár leképezve, ráadásul a leképezés a végrehajtás során változhat is.
</div>

====MMU: Mi a processzor Memory Management Unit (MMU) komponensének a feladata?====
<div class="answer">
* Speciális HW a CPU-ban
* Memória állapotának nyilvántartása
** Tulajdonos folyamat azonosítója
** Hozzáférési jogosultságok (ACL)
** cache-elhetőség, ha van cache (pl. DMA)
* Virtuális memória leképzése fizikai memóriára
** Pl. Translation Lookaside Buffer (TLB)
** Kontextusváltásnál ezt is kezelni kell (ha van)
** Pagefile vagy SWAP (HDD)
* Memóriavédelem
** Tiltott memória hozzáférés megakadályozása vagy legalább jelzése (ACL alapján)
** General Protection Fault (GPF) a Windows-ban
</div>

====Modified/dirty bit, referenced/used bit: Mi a modified/dirty bit és a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* laptáblában:
* Módosítás nyilvántartása (modified/dirty bit): minden memórialaphoz tartozik egy HW által kezelt bit (pl. a laptáblában) - betöltéskor törlik, módosításkor beállítják. Ha a dirty bit 1, akkor erre a lapra történt írási művelet, mióta a ﬁzikai memóriába került. Ezt a bitet a CPU tartja karban (automatikusan), ezzel az operációs rendszer munkáját segítve. 0 érték esetén a lapokat nem kell a diszkre kiírni, ha kiszorulnak a ﬁzikai memóriából (hiszen a tartalmuk a ﬁzikai memóriába helyezés óta változatlan, a diszk-en tárolt változat tehát továbbra is aktuális).

* Hivatkozások nyilvántartása (referenced/used bit): Ha a refernced bit 1, akkor volt "mostanában" hivatkozás erre a lapra. Ezt is a CPU tartja karban. Ez a bit segít az operációs rendszernek, amikor el kell döntenie, hogy melyik lapot dobja ki a ﬁzikai memóriából, ha egy új lapnak nincs helye. A referenced=0 lapokból fog válogatni.
</div>

====Page locking: Mit jelent és miért van szükség arra, hogy a virtuális tárkezelésnél egyes lapokat ideiglenesen a tárba lehessen "fagyasztani" (page locking)?====
<div class="answer">
* Azt jelenti, hogy a lapcsere algoritmus nem lapozhatja ki a háttértárra az adott lapot. Ok: periféria-művelet van az adott lappal kapcsolatban.
* Azt jelenti, hogy bizonyos lapokat a memóriában tartunk, mert I/O műveletek hivatkozhatnak rá, és ilyenkor a memóriában kell lenniük, mert az I/O műveletek fizikai memóriacímeket használnak.
</div>

====Referenced/used bit: Mi a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* Bizonyos algoritmusok igénylik a lapra történő hivatkozások figyelését is, ami ugyancsak hardvertámogatással hatékony. A laptáblában erre a célra is fenntarthatunk egy bitet. Ezt a hivatkozott bitet (referenced bit, used bit, R bit) a címképző hardver állítja be minden esetben, amikor az adott lapon belüli címre történik hivatkozás. A bitet az operációs rendszer törli adott időnként, vagy eseményhez (például laphiba) kötötten.
* Hivatkozások nyilvántartása (referenced/used bit): OS adott időnként és/vagy adott eseményekre törli - használat esetén beállítják.
</div>

====TLB: Mi az a Translation Lookaside Buffer, fizikai címcsatolásnál mi a szerepe?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.
</div>

====TLB: Mire szolgál a Translation Lookaside Buffer és mi a szerepe a fizikai cím kiszámításánál (virtuális címképzés)?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.

(Szerintem előbb a TLB-ben keresi, aztán ha ott nincs, csak utána nézi a laptáblát.)
</div>

====Tördelődés (külső vs. belső): Mi a különbség a külső és belső tördelődés között? (Memória foglalás)====
<div class="answer">
A tördelődött memóriaterületet külső tördelődés esetén az operációs rendszer szabadon hagyja, míg belső tördelődés esetén pedig odaadja egy olyan folyamatnak, aminek nincs igazából rá szüksége.
</div>

====Vergődés: Adja meg a vergődés (trashing) definícióját!====
<div class="answer">
A gyakori laphibák okozta teljesítménycsökkenést vergődésnek (thrashing) nevezzük. Az ellene való védekezés a munkahalmaz méretének jó megválasztása. Célszerű egy folyamatnak annyi lapot adni, amennyi szükséges az egyensúlyhoz, azaz ahány lapra hivatkozik a laphiba kiszolgálás ideje alatt (ugyanakkor nem sokkal többet, mert ekkor leromlik a multiprogramozás foka).
</div>

====Vergődés: Mi az a vergődés, és hogyan védekezzünk ellene?====
<div class="answer">
* Ha több memóriára lenne szüksége a folyamatoknak, mint amennyi rendelkezésre áll, ezért túl gyakran keletkezik laphiba, és a processzor idejének nagy része haszontalan lapcserékkel telik.
* Védekezni ellene például azzal lehet, ha a laphiba-gyakoriság függvényében az ütemező változtatja a multiprogramozás fokát: ha kevés a memória, folyamatokat függeszt fel, és swappel ki; ha van elég, akkor épp ellenkezőleg.
</div>

===uc/OS-II===

====Prioritás: A uC/OS-II-ben hány taszk tartózkodhat egy prioritási szinten és miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk.
</div>

====Prioritás: Egy prioritási szinten hány szál futtatását teszi lehetővé a uC/OS-II, miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk. Egy taszk = egy szál.

(Magyarázat: egy taszk = egy szál; lásd http://video.bme.hu/media/video/Operacios_Rendszerek_08ea_20110301.wmv, 01:09:18 környékén
Röviden: a beágyazott rendszerek, kis OS-ek esetén (uC/OS-II, FreeRTOS, stb.) lényegében csakis szálakban gondolkozunk. Nincs MMU, csak egyetlen összefüggő fizikai memória van, nincs virtuális memória koncepció, a processzoron futó teljes alkalmazás (az egyetlen alkalmazás) egy nagy folyamat - nincs más folyamat! Ezenbelül tudunk threadeket futtatni. Single Address Space.)
</div>

===Ütemezés===

====Átbocsátó képesség: Adja meg az átbocsátó képesség definícióját és mértékegységét!====
<div class="answer">
* (throughput) Mértékegység: munka/s, vagy 1/s
* Adott időegység alatt elvégzett feladatok száma. <math>\frac{\sum \textrm{elvegzett munkak}}{\textrm{ido}}</math>
* A rendszerfeladatokat nem számoljuk.
</div>

====Hosszú távú ütemezés: Adja meg a hosszú távú ütemezés célját!====
<div class="answer">
Tipikusan a BATCH rendszerekben van jelen, és uj jobok végrehajtasának megkezdéseről (új folyamatok indítasárol) dönt. Az elvégzesre váro munkák közül a választas szempontja, hogy a rendszerben a CPU-intenzív es I/O-intenzív folyamatok aránya optimális legyen (optimalis job-mix fenntartasa).
</div>

====Hosszú távú ütemezés: Definiálja a hosszú távú ütemezés fogalmát!====
<div class="answer">
A hosszútávú ütemező feladata az elindított feladatok rendszerbe, illetve a "futásra kész" várakozási sorba való beengedését szabályozni. Igyekszik a CPU-t és a perifériákat terhelő folyamatokat egyensúlyban tartani. Batch rendszerekre jellemző; a PC-k oprendszere általában azonnal indítja a folyamatokat, mikor azt a felhasználó kéri.
* feladata: A háttértáron várakozó feladatok közül kiválasztja azt, amelyiket el kell indítani.
</div>

====Konvoj hatás: Mi a konvoj hatás, és a tanult ütemező algoritmusok közül melyekben jelentkezhet?====
<div class="answer">
* igen nagy lehet az átlagos várakozási idő, mivel egy-egy hosszú CPU-löketű folyamat feltartja a mögötte várakozókat
* FCFS-nél (First-come, first-served) tapasztalható (pl. SJF (Shortest Job First) és RR algoritmus küszöböli ki)
</div>

====Középtávú ütemezés: Adja meg a középtávú ütemezés célját!====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.
</div>

====Középtávú ütemezés: Mi a középtávú ütemező feladata?====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.

Szerintem inkább ez:
A rendszerben lévő feladatok memóriájának egyes éppen nem használt részeinek kiírása háttértárra.
</div>

====Körülfordulási idő: Mi az a körülfordulási idő?====
<div class="answer">
* TAT (Turnaround Time) -> Egy feladatra vonatkozóan a rendszerbe helyezéstől a teljesítésig eltelt idő.
* Mértékegység: s,
* t_(CPU,végrehajtási idő)+t_várakozás (Magában foglalja a ténylegesen munkával töltött időt és a várakozást is.)
* felhasználó minél előbb szeretné látni a végeredményt
</div>

====Megszakítás: Az éppen futó taszkot megszakítja egy IT. Preemptív OS esetén mindig a megszakított taszk fogja-e visszakapni a futási jogot? Miért?====
<div class="answer">
* Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
* Másik: Nem, mert akitől elvették a futás jogát az futásra kész állapotba fog kerülni és az ütemező dönti el, hogy melyik folyamat fogja megint megkapni a futást.
</div>

====Megszakítás: Egy futó taszkra IT érkezik. Preemptív OS esetén az interrupt után mindenképpen 'ide' térünk vissza?====
<div class="answer">
Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
</div>

====Preemptív ütemező: Mikor nevezünk egy ütemezőt preemptívnek? ====
<div class="answer">
Ha az OS elveheti a futásjogot (a CPU-t) egy folyamattól/futó feladattól (interrupt).
</div>

====Rövid távú ütemezés: Mi a rövidtávú ütemezés, mikor jár környezetváltással?====
<div class="answer">
* Rövidtávú ütemezés: futó folyamat kiválasztása a futásra kész feladatok közül
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Rövid távú ütemezés: Mikor fut a rövidtávú ütemező és mikor jár környezetváltással?====
<div class="answer">
* Ütemezés következhet be, ha
** a futó folyamat befejeződik,
** egy folyamat felébred, futásra késszé válik,
** a futó folyamat várakozni kényszerül (valamilyen esemény bekövetkezésére), illetve,
** a futó folyamat önként lemond a futás jogáról vagy pedig elveszik tőle.
* Az első és a harmadik esetben az ütemezés mindig környezetváltással jár, hiszen a következő futó folyamat egészen biztosan nem a korábban futott lesz. A másik két esetben előfordulhat, hogy az ütemezőnek nem kell másik folyamatot kiválasztania.
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Terhelés-végrehajtó egységek közötti megosztás: Sorolja fel a terhelés-végrehajtó egységek közötti megosztásának megoldásait! (Többprocesszoros rendszerek)====
<div class="answer">
* Master and slaves (egy CPU osztja ki a feladatokat)
* Self-scheduling / peering (minden CPU ütemez)
* Globális futásra kész sor
* Processzoronkénti futásra kész sor
** Push alapú: OS kernel folyamat mozgatja a sorok között a feladatokat.
** Pull alapú: Az idle állapotban (idle feladatot végrehajtó) CPU próbál a többi sorából feladatot kapni.
* Kettő kombinációja
** Összefüggő, párhuzamosan futtatható feladatok optimalizálása (pl. Gang scheduler)
</div>

===Virtualizáció===

====Hardveres virtualizáció: Mit jelent az, ha egy x86-os processzor hardveres virtualizáció támogatással rendelkezik?====
<div class="answer">
A CPU utasításkészletének és üzemmódjainak olyan kiegészítése, amely lehetővé teszi a vendég operációs
rendszer kódjának módosítás nélküli futtatását. [?]

(Speciális utasításokkal látják el a processzort, amit szoftveresen akár több 100 utasításon keresztül lehetne csak megoldani. ROSSZ(MZ))

Elrejti a gep fizikai tulajdonsagait a felhasznalok elol.

Miert erdemes virtualizalni?

-Lehet futtatni a gazda OS el nem kompatibilis alkalmazast.

-Lehet biztonsaggal rendszergazda jogot adni mindennek, mert ugy se tud a gazda os-be kart tenni.

-Konnyen at lehet masolni a virtualis gepet egy masik gepre.
</div>

====Hosted vs. bare-metal: Miben különbözik egy hosted egy bare-metal típusú virtualizációs megoldástól?====
<div class="answer">
Bare-metal esetén a VMM kezeli a HW erőforrásokat, míg hosted típusú esetén ezt a host OS végzi.

videó:
http://video.bme.hu/media/video/Operacios_Rendszerek_20ea_20110418.wmv
00:16:45 körül

Kétféle megközelítés:

# Hosted: az operációs rendszerre telepítek egy virtualizációs szoftvert, ez beépül az operációs rendszerbe tipikusan kernel modulként, innentől a virtualizációs szoftver teszi lehetővé, hogy virtuális gépeket futtassak. Tipikusan a desktop megoldások (VMware Player, VirtualBox, Virtual PC, stb.)
# Bare-metal: a virtualizációs szoftver valós OS-szerű funkciókat valósít meg. Lényegében egy minimális funkciókészlettel rendelkező OS. A hardvert nem egy általános célú operációs rendszer kezeli, hanem a virtualizációs szoftver feladata az, hogy a hardver-erőforrásokkal gazdálkodjon, ő dönt az ütemezésről, ő dönt a memória-hozzáférésekről. Tipikusan szokott hozzá tartozni egy menedzsment operációs rendszer, egy menedzsment konzol, ami a távoli hozzáférést, virtuális gépek elindítását lehetővé teszi, és ott is ott tudom futtatni a vendég operációs rendszereket. Tipikusan szervermegoldások (VMware ESX Server, Xen Enterprise, MS Hyper-V).

Fontos különbség: ki dönt a CPU-erőforrásról?
# van az OS-nek egy ütemezője, ő dönt arról, mikor, ki kapja meg a CPU-t. Dönthet úgy, hogy az időszeletet az alkalmazás kapja meg, a köv. időszeletet a virtualizációs szoftver/modul, ő magán belül pedig eldöntheti, melyik virtuális gépnek osztja a processzort, de alapvetően a host OS dönt arról, mi dönt az erőforrásról.
# arról, hogy ki kapja a CPU-t, a közvetlenül a hardver réteg felett lévő virtualizációs szoftver dönti el. Dönthet úgy, hogy a menedzsment OS kapja, dönthet úgy, hogy valamelyik virtuális gép kapja meg.

</div>

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
<div class="answer">
Módosítjuk a vendég OS forráskódját, hogy ne is akarjon "problémás" utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. (Ezzel egyszerűsödik a hypervisor implementálása, viszont csak úgy működik a módszer, ha módosítják a vendég OS forrását.)
</div>

====Trap-and-emulate: Trap & emulate virtualizációs módszer használata esetén mi történik a vendég gép által kiadott nem privilegizált utasítással?====
<div class="answer">
* nem privilegizált utasítások közvetlenül a valós CPU-n hajtódnak végre (no VMM intervention)
</div>

===UNIX===

====Adminisztratív adatok: hol helyezzük el azokat az adminisztratív adatokat, amelyekre mindig szükség van, akkor is, ha a folyamatnak egyetlen lapja sincs a memóriában?====
<div class="answer">
A proc struktúrában.
</div>

====Adminisztratív adatok: UNIX-ban a folyamatokkal kapcsolatos adminisztratív adatok hogyan épülnek fel?====
<div class="answer">
TODO: rövidíteni.

# adatok, melyek elsősorban akkor szükségesek, amikor a folyamat ténylegesen fut - bent van egy v. több lapja a memóriában, éppen ezekkel kapcsolatos utasításokat hajtunk végre. >> az u-területen található kontextusadatok. A folyamat címtér része. A folyamat nem férhet hozzá, de a folyamat saját címterében találhatók. Amikor a folyamatnak egyetlen lapja sincs a memóriában, hanem minden a háttértáron található, a folyamat nem fut, akkor az itt található adatokhoz a kernel sem tud hozzáférni, mivel ide csak azok az adatok kerülnek, melyek a folyamat futásakor kellenek! Pl. hozzáférés-szabályozási adatok: a folyamat szeretne valamilyen tevékenységet végrehajtani, szabad-e neki vagy sem? Másik példa: rendszerhívások állapotai: végrehajt egy rendszerhívást, amiben éppen tartózkodik, ezzel kapcsolatos állapotadatok, stb. Vagy: nyitott fájl adatok, fájlkezeléssel kapcsolatos adatok. UNIX-ban a fájlkezelést nagyon általánosan kell érteni. Minden, ami a fájlrendszer-interfészen keresztül zajlik, ahhoz tartozik egy nyitott fájl objektum, ami ennek adminisztrálására szolgál, ezek is az u-területen találhatók. Ezenkívül: számlázási, statisztikai adatok.

# adatok, melyek elsősorban a folyamatok kezeléséhez szükségesek (amire a kernelnek bármikor szüksége lehet). Pl. folyamat alapvető azonosító adatai. Folyamat PID-je, szülőazonosító, stb. Folyamat ütemezésével kapcsolatos adatok, mi a folyamat aktuális futási állapota, mennyi a prioritása, prioritás kiszámolásához szükséges adatai, stb. Memóriakezelési adatok: folyamat memórialapjai bent vannak a memóriában, vagy épp kint vannak a háttértáron. Az u-terület címe, stb. >>> proc struktúra adatai: a process tábla egy eleme (ez a klasszikus rendszereknél ténylegesen egy tábla volt, ma bonyolultabb, pl. láncolt listás megvalósítás). A kernel címterének része. A kernel bármikor elérheti őket.
</div>

====Adminisztratív adatok: Milyen adatstruktúrá(k)ban és milyen címter(ek)ben található(k) a folyamatok adminisztratív adata(i)?====
<div class="answer">
A folyamat futása során szükséges adatok az u-területen, mely a folyamat címterének része, illetve a folyamatok kezeléséhez szükséges adatok a proc struktúrában, mely a kernel címtér része.
</div>

====Adminisztratív adatok: Sorolja fel a UNIX folyamatok legalább 4 alapvető adminisztratív adatát!====
<div class="answer">
* PID (Process ID): egyedi, a folyamatot azonosító szám (PPID: szülő folyamat azonosítója)
* A folyamat állapota (fut, alszik, stb.; ütemezési információk (prioritás, CPU használat, nice érték) )
* Hitelesítők (UID, GID: a kapcsolódó felhasználó adatai)
* Memória-kezelési adatok (címleképezési térkép)
* Kommunikációs adatok (fájlleírók, jelzés információk)
* Statisztikák (erőforrás használat (számlázáshoz) )
</div>

====Alvási prioritás: UNIX alvási prioritásának ütemezését mi végzi?====
<div class="answer">
Az alvási prioritást is az ütemező határozza meg, az alapján, hogy mire várakozik a folyamat, vagyis miért hajtott végre sleep() rendszerhívást. Kernel módban az ütemező nem veheti el a futási jogot, ezért amíg nem hajt végre sleep() hívást, addig nincs is szükség a prioritásának meghatározására.
</div>

====Android: Az Androidban mikor és miért (adjon jellegzetes példát) terminálható egy alkalmazás?====
<div class="answer">
Az alkalmazás erőforráshiány miatt bármikor terminálható, ezt az operációs rendszer automatikusan meg is teszi. Példa: ha nincs elég memória.
</div>

====Belső szerkezeti elemek: Sorolja fel a UNIX operációs rendszer főbb belső szerkezeti elemeit!====
<div class="answer">
* betöltő
* virtuálismemória-kezelő
* állományrendszer
* blokkos berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: lemezegység, szalagos meghajtó)
* karakteres berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: hálózat, nyomtató)
</div>

====Csővezeték (pipe): Írjon le egy olyan konkrét UNIX shell parancssort, amely csővezetéket alkalmaz!====
<div class="answer">
ls -la | more
</div>

====exec(): Mire szolgál a UNIX exec() rendszerhívás?====
<div class="answer">
exec(): új programkód betöltése egy folyamat címterébe
Azaz a fork() paranccsal létrehozunk egy új folyamatot, exec() paranccsal pedig betöltjük a folyamatba a kódot.
</div>

====Fájl-attribútumok: Sorolja fel a fontosabb UNIX fájl-attribútumokat!====
<div class="answer">
* Típus
* Linkek
* Eszköz, inode, méret...
* Időbélyegek
* Azonosítási és hozzáférés-szabályozási adatok
</div>

====Fájlrendszeri bejegyzések: Sorolja fel a UNIX fájlrendszeri bejegyzések alapvető tulajdonságait (legalább hármat, ls -l oszlopok)!====
<div class="answer">
* pl.: drwxr-xr-x 2 root root 4096 dec 22 12.27 txt
* sorrendben: I. UNIX-fájltípusok (pl. közönséges fájl (-), katalógus (d), szimbolikus link (l), stb.), II. hozzáférési jogosultságok (3*3-as bontásban - 1. hármas csoport a tulajdonos, a 2. a csoport, a 3. a többiek jogosultságait; 'r' az olvasás (read), a 'w' az írás (write), az 'x' pedig a végrehajtás (execute) jele), III. jogosultságok után egy szám áll (ez könyvtárak esetén azt mondja meg, hogy az adott könyvtár hány elemet tartalmaz, fájlok esetén azt tudhatjuk meg, hogy az adott fájlra hány hardlink mutat), IV. tulajdonos, V. méret (bájtokban), VI. utolsó módosítás dátuma, VII. fájl neve
</div>

====Felfüggesztett állapotok: Mik azok a felfüggesztett állapotok, mi a szerepük a UNIX-ban?====
<div class="answer">
felfüggesztve futásra kész, felfüggesztve alszik állapot A UNIX-ban egyfajta hosszú távú, felhasználói ütemezést jelentenek - a felhasználónak lehetősége van arra, hogy bizonyos folyamatokat a többi állapotból kiemeljen. Pl. Ctrl+Z billentyűkombinációval felfüggesztem a folyamatok futását. Innen valamikor visszahelyezzük futó állapotba.
</div>

====Felhasználói mód, kernel kontextus: UNIX esetén milyen tevékenység zajlik felhasználói módban, kernel kontextusban?====
<div class="answer">
Semmilyen!!
Megj.: Kernel kontextusban, felhasználói módban a program saját utasításait hajtjuk végre, a program saját adataival dolgozunk. Ennél fogva itt nincs értelme beszélni semmiről, mert a folyamat a kernel kontextusában nem hajthat végre semmit.
</div>

====Felhasználói módból kernel módba váltás: Hogyan vált egy UNIX folyamat felhasználói (user) módból kernel módba?====
<div class="answer">
Rendszerhívásokon keresztül.
</div>

====Felhasználói módú prioritás: Sorolja fel milyen tényezők határozzák meg egy UNIX folyamat felhasználói módú prioritását (tradicionális UNIX ütemező esetén)!====
<div class="answer">
* Korábbi CPU-használat
* Futásra kész folyamatok száma (p_cpu "öregítésével")
* nice érték (nice és renice parancsok)
</div>

====Folyamatok állapotai: Milyen állapotai vannak a UNIX-folyamatoknak?====
<div class="answer">
# kiinduló állapot
# futásra kész
# kernel módban futó állapot
# felhasználói módban futó állapot
# alvó állapot
# zombi állapot
# felfüggesztve alszik
# felfüggesztve futásra kész

Ctrl+Z-vel felfüggesztett állapotba helyezem a folyamatot.
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 UNIX folyamatok között kommunikációs megoldást!====
<div class="answer">
* System V IPC: szemafor, osztott memória, üzenetsor
* Csővezeték és nevesített csővezeték
* Jelzések
* RPC
* Folyamat-nyomkövetés
* Szemaforok
* Üzenetsorok
* Osztott memória
* Hálózati, socketeken keresztüli kommunikáció
</div>

====Folyamatok közötti kommunikáció: Soroljon fel UNIX folyamatok közötti adatátviteli eszközöket (legalább hármat)!====
<div class="answer">
* System V IPC: - szemaforok, - üzenetsorok, - osztott memória
* Jelzések: - aszinkron események keltése és kezelése
* Csővezetékek, nevesített csővezetékek: - FIFO kommunikáció a "rokonságban"
* Szemaforok: - a korábban megismert szinkronizációs megoldások
* Üzenetsorok: - diszkrét, típusos üzenetek folyamatok között
* Osztott memória: - azonos fizikai memóriaterület használata több folyamatban
* "hálózati" (socket) kommunikáció: - címzéssel és protokollokkal támogatott kommunikáció
* TODO
</div>

====fork(): Mire szolgál a fork() rendszerhívás?====
TODO: rövidíteni.

Új folyamat létrehozására. A fork() hívásakor az aktuális folyamat, amely kiadta a rendszerhívást, megduplázódik (minden adata, verme, memórialapja, stb.), onnantól két példányban fog továbbélni, amelyek egymással szinte tökéletesen megegyeznek, kvázi klónozva van a folyamat, néhány apró különbség van csupán. De valójában a memóriaszervezés ügyes trükkje: semmit nem csinál azonkívül, hogy bizonyos adminisztratív adatokat megdupláz, ténylegesen nem másol semmit (memórialapokat)! Az így megduplázott folyamat memórialapjaihoz hozzárendel még egy folyamatot, és megjegyzi azt, hogy amíg ezek a folyamatok békésen tudnak egymás mellett dolgozni, addig dolgozzanak ugyanazon, de ha konfliktus van, akkor majd lemásoljuk ezeket a memórialapokat.

Ha a fork() hívás 0-val tér vissza: a gyerek folyamat kódja fut tovább. Ha egy negatív számmal tér vissza, fork() hiba történt, nem tudtuk létrehozni az új folyamatot, le kell kezelni. Ha pozitív számot adott vissza, akkor az eredményben a gyerekfolyamat azonosítója található, itt a szülőfolyamat fut tovább.

Gyerek folyamat fut: az exec() az aktuális folyamat helyére betölt egy másik binárist. Az exec()-et meghívó folyamatnak az exec() kitörli a saját kontextusát, stb., betölt egy új programkódot, amit elkezd végrehajtani. (Kvázi mintha elindítana egy új folyamatot, de a folyamat már fut.) Ha nem sikerült betölteni a binárist (pl. nincs ilyen fájl), akkor hiba, visszatér az exec() is, egyébként nem: az új programkód utasításait hajtjuk végre.
Tehát folyamat létrehozása UNIX-ban két lépésben:
# fork() rendszerhívás = folyamatduplázás, majd
# a gyerekfolyamat helyére az új programkód betöltése exec() hívással.
Modern UNIX-okban fork() már nem igazán (más rendszerhívásokat használ).

====fork(): Miért van szükség a fork() rendszerhívásnál a folyamat megduplázására?====
<div class="answer">
TODO
</div>

====Futási/végrehajtási mód: Mi az a futási mód?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv, 00:17:00 környéke alapján
TODO - rövidíteni
A folyamatok a kerneltől teljesen különválasztva működnek (rendszerhívás interfészen keresztül kommunikálnak a kernellel). A végrehajtási mód azt határozza meg, hogy a kernel vagy a folyamat feladatait hajtja végre az OS.
Két mód: kernel ("privilegizált, védett") mód, valamint felhasználói ("szabad") mód.
Kernel módban a védett (kernel) tevékenységeket, felhasználói módban a folyamat programkódját hajtja végre az OS.
Példa: egy webböngésző a tevékenysége egy részében a saját feladatát hajtja végre, pl. HTML-kódot értelmez és jelenít meg, valamint vannak olyan tevékenységek, amelyek ahhoz kellenek, hogy ezt a feladatát végrehajtsa: hálózati kommunikáció, fájlrendszer-műveletek, stb. - ezek kernel tevékenységek.
Kernel módban privilegizált utasítások hajtódnak végre, pl. egy eszközt kezelünk, vagy hozzányúlunk a háttértárhoz, onnan valamit beolvasunk, oda valamit kiírunk. Ilyen utasításokat egy felhasználói módban futó folyamat nem hajthat végre, hiszen ha közvetlenül hozzáférne a hardverekhez, akkor akár adott esetben a teljes rendszer működését felboríthatná.
Felhasználói módból kernel módba átlépéskor átlépünk egy védett módba, így olyan feladatokat is végrehajthatunk, amit egyébként tilos.
</div>

====inode: Mi a UNIX inode?====
<div class="answer">
* A fizikai állományokhoz tartozó leíró, azonosító
* minden file-hoz tartozik egy inode állomány amiben a file minden tulajdonsága megtalálható (azonosító,leíró)
</div>

====Kernel mód, folyamat kontextus: Milyen tevékenység zajlik kernel módban, folyamat kontextusban?====
<div class="answer">
Kivételek, rendszerhívások kezelése, rendszerhívások végrehajtása.
Amikor a folyamat végrehajt egy rendszerhívást, a felhasználói módból átlép kernel módba, hiszen a rendszerhívás belsejében olyan tevékenységeket szeretne végrehajtani (beolvasni vmit egy fizikai eszközről, hálózatról, más folyamattal kommunikálni, elindítani másik folyamatot, stb.), amelyhez kernel utasítások végrehajtása tartozik.
</div>

====Kernel mód, kernel kontextus: Milyen tevékenység zajlik kernel módban, kernel kontextusban?====
<div class="answer">
Rendszerfeladatok, megszakítások kezelése. Kernelfolyamatok.
</div>

====Kernel módú prioritás: Mi határozza meg a UNIX folyamatok kernel módú prioritását a tradicionális UNIX ütemezésben?====
<div class="answer">
A kernel módban futó folyamat prioritása statikus, nem függ attól, hogy a folyamat mennyit használta a CPUt, vagyis mennyi ideig futott. A prioritás attól függ, hogy a folyamat milyen ok miatt hajtott végre sleep rendszerhívást, vagyis, hogy milyen eseményre várakozik. Emiatt a kernel prioritást szokták alvási prioritásnak is nevezni.
</div>

====Kernelszolgáltatások elérése: Milyen interfészen keresztül érhetők el a UNIX kernel szolgáltatásai?====
<div class="answer">
* System Call Interface
* Az alkalmazások a rendszerkönyvtárakat hívják meg, amelyek szükség szerint meghívják az operációs rendszer szolgáltatásait ??
</div>

====Kontextus: Mi az a kontextus?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv alapján.
TODO: rövidíteni.
Az a környezet, amiben végrehajtjuk az utasításokat. Ez is különbözik a kernelek és folyamatok esetén: folyamat kontextusban azokkal az adatokkal és utasításokkal dolgozunk, amelyek alapvetően a folyamat célját szolgálják, kernel (rendszer vagy megszakítás) kontextusban pedig kernel feladatokat hajtunk végre, és az ezekhez a feladatokhoz szükséges adatokkal dolgozunk.
Kernel kontextus: érkezik egy hardveres megszakítás, ennek kezelése itt zajlik.
Folyamat kontextus: a folyamattal kapcsolatban hajtunk végre tevékenységeket.
Nem uaz, mint a végrehajtási mód, mert lehetséges az, hogy bizonyos tevékenységeket kernel módban hajtunk végre, de folyamat kontextusban. Amikor hozzá kell férnünk egy folyamat futási adataihoz, veremhez, virtuális memóriájához, stb., a programnak az adminisztratív adatait kezeljük, ezek folyamat kontextusban találhatóak.
</div>

====Környezeti adatok: Mik azok a környezeti adatok egy UNIX-folyamatnál?====
<div class="answer">
A folyamat indításakor megörökölt tulajdonságok. Tulajdonság-érték párok. Pl. a felhasználó bejelentkezik; mi az ő neve. A felhasználó milyen terminált használ, annak milyen képességei vannak. Mi a felhasználó shellje. Az épp futó folyamat néhány tulajdonsága. Olyan tulajdonság, amely egyes folyamatok számára értéket jelentenek. A felhasználók ezeket a set, setenv, export parancsokkal tudják ezeket állítani (és le is kérdezhetik őket). Megörökli az őt elindító folyamat környezetét (hogy melyiket kell épp használni, UNIX-variánstól függ). Amikor a felhasználó bejelentkezik, akkor a környezeti változók beállítódnak, a folyamatok induláskor ezeket a beállításokat megöröklik.
</div>

====libc: A libc-nek mi a feladata rendszerhívások kezelésében?====
<div class="answer">
A felhasználói mód és kernel mód közötti átmenet lebonyolítása.
A folyamat csak meghív egy open(), read(), write(), stb. függvényt, valójában a háttérben bonyolultabb tevékenység zajlik >> meghív egy rendszerhívást a rendszerhívás interfészen keresztül. A rendszerkönyvtárak egyike a libc, a standard C library, ez felel azért, hogy az adott függvényhívásokat (mint a read()) leképezze arra a mechanizmusra, amin keresztül átlépünk kernel módba.
Az implementáció belsejében van egy SYSCALL utasítás (ez hardverfüggő), ez ténylegesen elvégzi az üzemmódváltást egy speciális megszakítás generálásával, aminek eredményeként a CPU átlép védett módba. A kernel pedig kezeli ezt a megszakítást. Ekkor a kernel a CPU regisztereit elmenti, azért, hogy a folyamat futása visszaállhasson a megfelelő állapotba. A feladat végeztével a kernel visszatér a megszakításból (erre is hardverfüggő a megvalósítás), a CPU visszavált felhasználói módba, a libc pedig visszatér a függvényhívásból, amit a folyamat kiadott.
</div>

====/proc: Mi a /proc?====
<div class="answer">
Speciális fájlrendszer-interfész a kernel-adatstruktúrákhoz való hozzáféréshez.
</div>

====Prioritás: Hogyan számítható ki egy kernel módban futó UNIX folyamat prioritása?====
<div class="answer">
* a prioritást a folyamat elalvásának oka határozza meg, tehát a prioritás attól függ, milyen sleep utasítással ment át alvó állapotba
* alvási prioritás pl: 20 - diszk I/O-ra vár; 28 - inputra vár a karakteres terminálról
* kernel módú folyamatoknak (amelyek rendszerhívásokat intéznek) negatív prioritásértékeik vannak, ezeknek van a legmagasabb prioritása ........... (http://home.mit.bme.hu/~meszaros/edu/oprendszerek/segedlet/unix/2_folyamatok_es_utemezes/unix_processes.pdf)
* Több szinten, több időléptékben zajlik. Óraütésenként a prioritási sorok ellenőrzése. 10 óraütésenként RR ütemezés egy soron belül. 100 óraütésenként a prioritások újraszámítása.
</div>

====Rendszerhívások: Igaz-e, hogy a rendszerhívások megszakítással járnak együtt?====
<div class="answer">
Igen, ennek hatására vált védelmi szintet a processzor.
</div>

====Rendszerhívások kontextusa: Milyen kontextusban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
folyamat kontextusban
</div>

====Rendszerhívások módja: Milyen módban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
kernel módban
</div>

====Rendszerhívások módja, kontextusa: Milyen futási módban és kontextusban zajlik a UNIX rendszerhívások kiszolgálása?====
<div class="answer">
Kernel módban fut a kód, és a rendszert hívó folyamat kontextusában. ((az ehhez tartozó ábra jobb felső része))
</div>

====Rendszerhívások programindításkor: UNIX alatt milyen rendszerhívásokra van szükség, ha a felhasználó elindít egy programot (folyamat létrehozása és programkód betöltése)?====
<div class="answer">
* Folyamatot létrehozni a fork() hívással, majd a programkódot betölteni az exec() hívással lehet.
</div>

====rpcgen: Mi az rpcgen program feladata?====
<div class="answer">
* RPC nyelven készült leírásból C programkódot generál. [?]

* Az RPC nyelv alkalmas a szerver interfészének formális leírására. A formális leírásból az rpcgen program képes a szerver és a kliens programok megfelelő részeit, valamint a szükséges XDR konverziós függvényeket elkészíteni C nyelven. Az így kapott C forráskódú modulokat a kliens és szerver alkalmazással kibővítve kapjuk a teljes kommunikáló rendszert.
* XDR (Extended Data Representation, kiterjesztett adatreprezentáció): Többféle egyszerű adattípust definiál, illetve szabályokat határoz meg bonyolultabb adatstruktúrák létrehozására. Az adatstruktúrák meghatározásán kívül az XDR egy formális nyelvet is bevezet az adatok leírására. Az RPC rendszer is ezen nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
* RPC (remote procedure call, távoli eljáráshívás): Az RPC-rendszer egy protokoll-leírást és egy programozói interfészt tartalmaz. Az XDR által definiált formális nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
</div>

====System V IPC: Sorolja fel a UNIX System V IPC elemek közös alapjának részeit!====
<div class="answer">
Minden IPC erőforrás rendelkezik a következő azonosítókkal: kulcs (key), létrehozó (creator), tulajdonos (owner), hozzáférési jogok (permissions)
</div>
====System V: Adja meg a System V üzenetsorok főbb jellemzőit (tömör felsorolást kérünk)!====
<div class="answer">
* diszkrét, tipizált üzenetek
* nincs címzés, üzenetszórás
</div>

====System V: Miért tud az s5fs (System V File System) gyorsabban írni, mint olvasni (az előadás példája alapján)?====
<div class="answer">
* az írás gyors, főleg kis fájlok esetén (több szintű leképzés a kisebb blokkkok miatt), az olvasás azért lassabb (csak a nagy fájlokra), mert azoknak a részeit össze kell vadászni a szétszórtság miatt
* TODO
</div>

====u-terület: milyen jellegű adminisztratív adatok vannak az u-területen?====
<div class="answer">
Azok az adatok, melyek a folyamatok futásakor kellenek. Több infó: lásd adminisztratív adatoknál.
</div>

====UNIX-fajták: Soroljon fel fő UNIX-fajtákat!====
<div class="answer">
Linux, Solaris, BSD, System V, HP/UX, ...
</div>

====UNIX-szabványok: Soroljon fel UNIX-hoz köthető szabványokat (legalább kettőt)!====
<div class="answer">
* POSIX.1 (teljes nevén: POSIX1003.1): C nyelvű szabványos rendszerhívás-interfész
* System V Interface Definition
* X/Open Portability Guide
* - AT&T SVID (pl. SVR4), - IEEE POSIX, - Open Group X/Open, Unix95, Unix98, ... ????
* http://linux.die.net/man/7/standards
</div>

====UNIX-típusok: Soroljon fel UNIX típusokat (a családfa jellemző ágait)!====
<div class="answer">
* System V (AT&T változat; Solaris, SCO),
* BSD (Berkeley változat; SunOS, OpenBSD)
</div>

====Ütemezés: Adja meg a tradicionális UNIX ütemező három legjellemzőbb tulajdonságát!====
<div class="answer">
* preemptív, prioritásos és időosztásos
(Néhány kiegészítés a UNIX-ütemezőhöz:
* nem preemptív kernel módban (a kernel módot végrehajtó folyamatot (pl. rendszerhívás, megszakítás-kezelés) nem lehet kényszeríteni, hogy a CPU használatáról lemondjon egy nagyobb prioritású folyamat javára)
* újraütemezés csak akkor következik be, ha egy folyamat önként lemond a CPU-ról és sleep rendszerhívást hajt végre, vagy a folyamat kernel módból visszatér user módba Nem méretezhető megfelelően. Az algoritmus nem képes rugalmasan alkalmazkodni a folyamatok számának növekedése esetén. A korrekciós faktor nem elég hatékony eszköz.
* A CPU-t adott esetben nem lehet "kiosztani" adott folyamat számára. Nem garantálható fix válaszidő. Nagy rendszerterhelés esetén a válaszidő megnőhet. A UNIX ütemezés épp ezért nem alkalmazható real-time rendszerekben.
* A kernel nem preemptív, ezért az egész rendszert feltarthatja. A felhasználó nem tudja megfelelő módon befolyásolni folyamatai prioritását - a nice szám nem megfelelő eszköz erre a célra.)

</div>

====vfs: Mondjon legalább egy, UNIX VFS-alapú "fájlrendszert", amelynek a célja nem fájlok tárolása!====
<div class="answer">
/dev, /proc, stb.
</div>

====vfs: Soroljon fel UNIX VFS-alapú fájlrendszereket (legalább négyet)!====
<div class="answer">
xfs, zfs, brtfs, nfs
</div>

====Virtuális rendszerhívás: Mi az a virtuális rendszerhívás, miért van rá szükség?====
<div class="answer">
(Klasszikus UNIX-ban nincs, Linux 2.5.x-től felfelé, mai Linux kernelek aktívan használják.)
Vannak bizonyos egyszerű feladatok, amelyek a feladat egyszerűsége ellenére túl sok felesleges művelettel járnak: rendszerhívás intterrupt, kontextusváltás, stb., ezen a helyzeten szeretnénk javítani - próbáljuk lerövidíteni ezt az utat.
Pl. a pontos idő lekérdezése csupán egy megfelelő hardver kiolvasása (egyszerű numerikus érték), mégis sok művelettel jár: gettimeofday(): libc > SYSCALL > kontextusváltás > ..., majd ugyanezen a lépcsőn visszasétálunk a felhasználói folyamatba.
Persze nem mindig lehet leegyszerűsíteni ezt az utat, csak egyszerűbb és biztonságos esetekben, pl. ha egyszerű numerikus értékek, azonosítók kiolvasásáról van szó: pl. folyamatnak mi az azonosítója, processzor lekérdezése, pontos idő lekérdezése...Tehát a felhasználói módból kernel módba történő hosszas váltást szeretnénk elkerülni. Ha nincs ilyen módváltás, akkor a felhasználói címtérben elérünk egyes kernelterületeket > így tényleg egyszerű függvényhívás lesz. Megfelelő előfeltételekkel: csak kockázatmentes feladatokra. Időlekérdezés tipikusan ilyen, ott megtehetjük.A felhasználói címtérben az a tevékenység, amelyet szeretnénk végrehajtani, elérhető legyen. Ezt oldják meg a virtuális rendszerhívások!
A folyamat címterébe a kernel rendszerinduláskor speciális "kernellapot" allokál - ezen a biztonságosnak tekinthető rendszerhívások vannak. Terminálból példa: ldd /bin/bash
</div>

====vnode/vfs: Mi a UNIX vnode/vfs?====
<div class="answer">
* Implementáció-független fájlrendszer absztrakció
* vnode: virtuális csomópont, vfs: virtuális állományrendszer
* inode --> vnode
* fs --> vfs
* Új absztrakció: annak felismerése, hogy több állományrendszernek számos előnye van, szükségessé vette a virtuális csomópont (vnode) és a virtuális állományrendszer (vfs) leíró adatszerkezetek bevezetését. Követelmények, elvárások az állományrendszerrel kapcsolatban:
** egyszerre támogasson több - UNIX, nem UNIX - állományrendszert
** különböző diszk partíciók különböző állományrendszereket is tartalmazhatnak, de mountolás esetén egységet képet kell, hogy mutassanak
** támogassa a hálózati állományok osztott használatát
** modulárisan bővíthető legyen.
</div>

====Zombi állapot: Mi a zombi állapot szerepe egy UNIX rendszerben?====
<div class="answer">
A folyamat már felszabadította a foglalt memóriát, lezárta az állományokat, minden erőforrását visszaadta a rendszernek, csak a proc struktúráját tartja fogva, amiben visszatérési és statisztikai információt tárol a szülő számára. A folyamat szülő wait hívása után szűnik meg.

Megjegyzés: bővebben magyarázattal, előadás alapján:
A folyamat megáll, a UNIX-ban a kernel szeretné ezt a szülőjének is tudomására hozni.
A folyamat már leállt, nem fog tovább futni, de a szülőjét még nem értesítették arról, hogy ez a folyamat megszűnt, esetleg gondoskodjon az újraindításáról, stb.
Pl. egy webszerver: beérkező kérések kiszolgálása --> kliens folyamat indítása, ez megkapja a kérés kiszolgálásának feladatát, a kliens pedig valamikor megáll, a webszerver nem árt, ha értesül róla, hogy hiba vagy normál működés folytán állt le.
Tehát amíg a szülő nem értesült a leállásról, a folyamat zombi állapotban marad. Ha a szülőt nem érdekli, mi történt a gyerekfolyamattal, a zombi állapot hamar megszűnik.
A zombi állapotban a folyamatnak semmilyen saját adatát nem tároljuk, a folyamat összes működéshez szükséges adata megszűnik, kizárólag a kernel adatstruktúrákban, tehát a proc struktúrában marad meg a folyamatnak néhány adminisztratív adata. A ps kilistázhat pl. zombi állapotban lévő feladatokat, mert ezeknet a folyamatoknak az adminisztratív adatai a kernel címterében még megtalálhatóak. De a folyamatok saját címtere, u-terület, stb. már nem létezik. Miután a szülő értesült róla, hogy a gyerekfolyamat meghalt, a kernel törölni fogja a folyamatot a process táblából is, a folyamat kilép a zombi állapotból.
</div>

====Zombi állapot: Igaz-e az, hogy egy zombi állapotban lévő folyamat még memóriaterületet foglal?====
<div class="answer">
Igen, mert a kernel processz táblában még ott vannak az adatai, és az memóriaterületet foglal. (A NEM választ is meg lehet indokolni...) [Indoklás nélkül 0 pont!!!]
</div>

===Windows===

====Alrendszer: Melyik az az alrendszere a Windowsnak, ami nélkül nem tud futni?====
<div class="answer">
A Windows alrendszer, avagy Client/Server Runtime [[SubSystem]] (csrss.exe). Ennek kilövése kékhalált eredményez.
</div>

====API-k: Hogyan oldották meg, hogy az alkalmazások többféle API-n (Win32, POSIX) keresztül is meg tudják hívni a Windows operációs rendszer funkcióit?====
<div class="answer">
* Megoldás: környezeti alrendszerek (environment subsystems): a felhasználónak vagy programozónak nyújtott környezet, személyiség egy részét a környezeti alrendszer folyamatok valósítják meg, minden egyes környezet külön API-t mutat (Windows, POSIX, ...), az operációs rendszer rendszerhívásainak egy részét kínálja a felhasználói alkalmazások számára. (Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx)
* a kernelnek egy definiált interfésze van, ami nem publikus (hivatalos dokumentációja nincsen): NT API >> az ebben lévő függvényeket a fejlesztő ne hívhassa meg közvetlenül. Ehelyett erre két alrendszer épül, ők mutatnak egy API-t az alkalmazások felé: Windows API és POSIX API. (ezek teljesen dokumentáltak!). Az alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni.
* A két alrendszer feladata az, hogy az általuk definiált hívásokat átfordítsák.
* Nem pusztán szintaktikai, hanem szemantikai eltérések is vannak.

(Megjegyzés: Exetype segédeszköz segítségével megnézhető, melyik alrendszert használja egy adott alkalmazás.)

Forrás: http://video.bme.hu/media/video/Operacios_Rendszerek_04ea_20110215.wmv (00:28:29 körül)

(Korábbi:
* Alkalmazás 1>>>Windows API (Windows alrendszer)>>>NT API (NT Kernel)<<<Posix API (Posix alrendszer)<<<Alkalmazás 2 TODO(ehelyett 1 épkézláb mondat kéne)
* alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni
)

</div>

====Executive réteg: Executive (Windows)====
<div class="answer">
Az operációs rendszer magasabb szintű funkcióit szolgáltató rétege (memóriakezelés, biztonság, stb.). Az adatokat objektumokban tárolja, melyeket leírókkal (handle) lehet csak elérni, jól definiált interfészeken keresztül. Bár a kernel funkcióit csak a kernel interfészén keresztül éri el, szintén az ntoskrnl.exe tartalmazza. A legtöbb rendszerhívás itt van megvalósítva.
Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx

(Korábbi: Ez a réteg tartalmazza az NTDLL.DLL által definiált függvények hívásainak megvalósítását, valamint a rendszer külső objektumai közti kommunikáció. Legfontosabb szolgáltató funkciója a lokális eljárás hívás - LPC (Local Procedure Call) megvalósítása. TODO[MZ])
</div>

====Fájlhozzáférések: Mivel azonosítja a Windows a felhasználókat és csoportokat a fájlhozzáférési listákban?====
<div class="answer">
* objektum (SecurableObject) → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* SecurityDescriptor (biztonsági leíró, összefogja a többi elemet) >> Owner (Tulajdonos, megváltoztathatja az objektum engedélyeit, akkor is ha nincs explicit joga), Discretionary Access Control List (DACL, belátás szerinti, erőforrás szintű, hozzáférési lista - hozzáférés szabályozása), SACL (biztonsági naplózás szabályozása - kinek milyen művelete esetén kell naplózni az adott műveletet)
* AccessControlEntry:
** Típus: megengedő, tiltó, audit
** Flag: Pl. öröklődés
** SID: kire vonatkozik
** Maszk: végrehajtás | törlés tulajdonos írása...
* elérési lista (ACL), melyben megadható, hogy mely folyamatok jogosultak az adott section object elérésére ???
* minden objektumhoz tároljuk a hozzá tartozó <tartomány, műveletvégzési jog> párokat ????
* TODO - bőven elég annyi, hogy Security Identifier (SID) segítségével azonosítja
</div>

====Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a felhasználókat és a csoportokat?====
SID - Security Identifier

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
felhasználókat és a csoportokat?
<div class="answer">
SID - Security Identifier
</div>

====Felhasználó- és csoportazonosító: Mivel azonosítja a Windows a felhasználókat és csoportokat a hozzáférések ellenőrzése során?====
<div class="answer">
* <Gép SID>-<RID> (SID security identifier - gépspecifikus, RID: relative identifier)
* Jól ismert SID-ek: Everyone: S-1-1-0, Administrator: S-1-5-domain-500
* Vista: szolgáltatások is kapnak SID-et
* objektum → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* TODO
</div>

====HAL: Mi a HAL (Windows)?====
<div class="answer">
* "HAL" - Hardware Abstraction Layer
* A felsőbb rétegek a HAL-on keresztül érik el az alap HW szolgáltatásokat, a HAL szerepe, hogy elfedje a HW megvalósítás részleteit, és egy egységes, platformfüggetlen felületet biztosítson.
* hal.dll fájlban megvalósítva (pl. timer interrupt kezelését, alaplap alapvető felépítését (milyen chipsetek vannak rajta), stb. elfedi a felette lévő rétegektől)
</div>

====Hardverfüggő részek: Melyek a Windows hardverfüggő részei?====
<div class="answer">
* A kernel egyes részei és a HAL.
* Megjegyzés: én ide a drivereket is beírtam, nem vontak le érte pontot, de azt mondták, azokat nem mindig szokás a rendszer részének tekinteni.
</div>

====Jogosultságok szerepe: Mik a jogosultságok (privilege) szerepe a Windows-ban?====
<div class="answer">
* operációs rendszer szintű jog
* meghatározzák azokat a rendszerműveleteket, amelyeket egy felhasználói azonosító elvégezhet. Egy rendszergazda jogosultságokat felhasználóknak és csoportazonosítóknak oszt (http://msdn.microsoft.com/en-us/library/bb530716(VS.85).aspx)
* pl. számítógép leállítása, eszközmeghajtó betöltése
* név: SeShutDownPrivilege, SeLoadDriverPrivilege
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens/Képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerülése: Mi a fő oka, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerültek? Elméleti megfontolások alapján hol lenne a helyük?====
<div class="answer">
Windows NT 4.0-ban került le kernel szintre ez a komponens, hogy kevesebb folyamat- és módváltás legyen (Ne kelljen mindig visszaváltani a csrss.exe-be, majd onnan átváltani kernel módba, utasítani a hardvert, visszaváltani felhasználói módba, majd visszaváltani a felhasználói folyamatba, aki kezdeményezte a változtatást.) (A felhasználói módú folyamatban (csrss.exe) csak a konzol kezelés maradt.) Elméletileg felhasználói szinten kéne lennie.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Windows-ban miért került le az ablakkezelő kernel módba?====
<div class="answer">
Hogy kevesebb kontextus- és módváltás legyen, mivel a Windows szerves része az ablakkezelés, ezért rengeteg user-kernel mód váltás lenne ha a csrss.exe-en keresztül használnánk. Tehát teljesítménybeli okokból.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens előnyei: A Windows OS grafikus komponensének mik az előnyei, hátrányai?====
<div class="answer">
A grafikus komponens kernel módban fut. Emiatt a hibái az egész rendszert magával ránthatják, viszont gyorsabb, mert kevesebb CPU-mód váltás kell a rajzoláshoz.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Mi volt a fő oka annak, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító komponens kernel módba került?====
<div class="answer">
Mert ezek a folyamatok intenzíven használják a hardvert, és futásuk gyorsaságára az egész rendszer teljesítménye érzékeny. A user módban történő megvalósítás a rendszert lelassítaná a gyakori környezetváltás miatt.
</div>

====Kernel: Mi a kernel (Windows)?====
<div class="answer">
A rendszer állandóan memóriában lévő, védett módban futó része. Az NT egyetlen HW függő része, szerepe a HW elfedése a felette található eszközök elől, ezáltal a felette lévő részek már teljesen HW függetlenek. Megvalósítja a szálütemezést, multiprocesszor ütemezést és a TRAP kezelést.
</div>

====Kliens-szerver-modell: Nevezzen meg egy kliens-szerver-modell alapján működő komponenst az NT-ben!====
<div class="answer">
* csrss.exe - Client/Server Run-Time Subsystems (környezeti alrendszerek)
* TODO
</div>

====Memóriafoglalás: Mely utasításokkal és miért történik a memóriafoglalás két lépésben Windows alatt?====
<div class="answer">
* A két lépés: Reserve és Commit. Az első csak címtartományt foglal, amögött nem lesz ténylegesen használható memóriaterület; a másik a már lefoglalt címtartományhoz rendel (virtuális) memóriát.
* A folyamatok címtartományának töredezettsége csökkenthető azzal, ha a címtartományt már akkor előre foglalja, mikor a memóriára még nincs szüksége, és ez nem jár olyan memóriapocsékolással, mintha fizikai memóriát is foglalna ugyanakkor.
</div>

====Munkakészlet (working set): Mit jelent a Windows-ban az egy folyamathoz tartozó munkakészlet (working set) fogalma?====
<div class="answer">
Azon fizikai lapok halmaza, amelyekre a folyamat laphiba nélkül hivatkozhat.
</div>

====NT hardverfüggő rétegei: Sorolja fel az NT hardverfüggő rétegeit!====
<div class="answer">
HAL (Hardware Abstraction Level), kernel
</div>

====NTDLL.DLL: Mi az NTDLL.DLL fő funkciója?====
<div class="answer">
Összeköti a User és Kernel módot. Az Executive függvényeknek megfelelő függvénycsonkok vannak benne.
</div>

====Quantum: Mi a szerepe a quantumnak a Windows ütemezőjében?====
<div class="answer">
* A szálak adott ideig futnak (quantum)
* RR ütemezésnél az időszelet
* Óramegszakításban mérik (clock interval, clock tick) 1 clock tick = ~ 10-15 ms (HALtól függ)
* Quantum hossza: időegység, amíg egy szál fut
* Kliensek esetén a quantum hossza 2 clock tick a háttérben futó folyamatoknak, az előtérben futó folyamatoknak 6 clock tick jut. Így egy CPU-intenzív folyamatról való ablakváltáskor az új, előtérben lévő folyamat arányosan több CPU-időt kap (azonos prioritásokat feltételezve).
* Szervereknél: mindenkinek 12 clock tick a kontextusváltások minimalizálása érdekében. Szervereknél így a kliensek kéréseinek eredményeként felébredő alkalmazásoknak több esélye van befejezni a kérést, és várakozó állapotba kerülni, mielőtt az időszelet véget érne.
* esély annak a folyamatnak, amelynek épp most ért véget a várakozása: a várakozás végén megnöveljük a prioritást, de a quantum eggyel csökken; a quantum végén a prioritást az eredetire csökkenti.
* éhezés elkerülése: az OS másodpercenként megnézni a futásra kész szálakat, és annak, aki nem futott már 300 óraütés óta, 15-ös prioritást ad, megnöveli a quantumját egy quantumnyi futásig
* TODO, hogy a forrás feldolgozása jó-e: http://mit.bme.hu/~micskeiz/opre/files/01-opre-windows-utemezes.pptx

</div>

====Rendszeridő megváltoztatása: A rendszeridő megváltoztatására kinek van joga Windows alatt?====
<div class="answer">
* SeSystemTimePrivilege joggal rendelkező felhasználóknak / azoknak a felhasználóknak, amelyek olyan csoportba tartoznak, amelyekhez hozzá van rendelve a SeSystemtimePrivilege.
* Alapértelmezett beállításként csak az Administrators és Power Users group rendelkezik vele.
* http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx
</div>

====Standby memórialapok listája: Mire szolgál a standby memória lap lista a Windows-ban (miért nem szabad lapként vannak ezek nyilvántartva)?====
<div class="answer">
A lap egy munkahalmaz része volt, de már nem az, elvették tőle. A lap nem módosult, mióta kiírták a merevlemezre, vagy mióta beolvasták. Egy nem Valid laptábla bejegyzés még mutat rá, azaz ha kell, még könnyen életre lehet kelteni a lapot.
</div>

====Szabad (free) és nullázott (zeroed) lapok: Miért van a Windows-ban külön szabad és nullázott (freed és zeroed) memórialap-lista?====
<div class="answer">
Biztonsági okokból. Nem nullázott memóriaterületet odaadni más folyamatnak biztonsági kockázatot jelent.
Tehát a free lapok szabad lapok, de még nem adhatók oda felhasználói folyamatnak, mert "szemetet" vagy érzékeny adatot tartalmazhatnak: nincs nullákkal felülírva a tartalma. A zeroed lapok szabadok, és nullákkal vannak felülírva, tehát odaadhatók felhasználói folyamatnak, amennyiben igény van rá.

TODO: ez így már megfelelő indoklás?

(Korábban:
*Free*: a lap szabad, de nincs 0-kkal felülírva a tartalma, szemét vagy egy előző processz által használt tartalom van benne. Ezt nem adhatja ki közvetlenül a memóriakezelő más processzeknek, mert biztonsági szempontból aggályos adatokat találhatna rajta.
*Zeroed*: szabad és nullákkal felülírt lap, kiadható, ha valakinek kell.
TODO(ez így igaz, csak ebben a formában nem a kérdésre válaszol))
</div>

====Mik a szerepük a szolgáltatásoknak a Windowsban? ====
<div class="answer">
Olyan folyamatok, amik a felhasználói felülettől és belépéstől függetlenül a háttérben futnak, és kibővítik az operációs rendszer alap szolgáltatásait.
TODO?
</div>

====Újrahívhatóság (reentrancy): Mit jelent az, hogy a Windows-ban a rendszerhívások újrahívhatóak?====
<div class="answer">
A rendszerhívásokat több alkalmazás is meghívhatja egyszerre, nem blokkolódnak, ha már valakit éppen kiszolgál az adott rendszerhívás.
</div>

====Védett objektum tulajdonosának speciális joga: Milyen speciális joga van egy védett objektum tulajdonosának az adott objektumra a Windows-ban?====
<div class="answer">
Megváltoztathatja az objektum engedélyeit, akkor is, ha erre nincs explicit joga. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/03-opre-windows-biztonsag.pptx)
</div>

====Verzióleírás: Mit jelentenek a számok és szavak a következő verzióleírásban: "Microsoft (R) Windows (R) 5.01.2006 Service Pack 2 Uniprocessor Free"?====
<div class="answer">
* (MZ) 5.01.2006 a verziószám, major.minor.build formában, 5.1 a Windows XP verzója, 2006 az SP2-es verzió build száma. Uniprocessor = egy processzoros kernel verzió, Free = debug szimbólumok nélküli verzió.
*(MZ) 2011-től kezdve ez már nem része a tananyagnak
* Most computers run a "uniprocessor free" version of Windows, which is a version that runs on a single CPU and does not contain extra errorchecking.
</div>



==Tartalomjegyzék==
<div class="table_of_contents">
__TOC__
</div>

==Források (teljesség igénye nélkül)==
<div class="docs_sources">
Ez előadás diáin, Wikipédiás és egyéb, Google-lel található cikkeken kívül ezek voltak a források, és MÉG ÍGY SEM tartalmazza az összes beugrókérdést (volt olyan, amit rengeteg idő lett volna átszerkeszteni, vagy kevésbé sanszos, hogy olyan hosszúságú beugrókérdést tennének fel, ami ott szerepelt):

* Hivatalos előadásjegyzetek: http://portal.mit.bme.hu/?l=oktatas/targyak/vimia219/jegyzet/index.html
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaBeugrok
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaKisKerdesek
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2007junius12megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008majus20megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008junius11megoldas
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/pelda_beugro_megoldas.pdf
----
* https://vir.sch.bme.hu/dokumentumok/InfoSite/4.%20f%C3%A9l%C3%A9v/Oper%C3%A1ci%C3%B3s%20rendszerek/
* https://vir.sch.bme.hu/document/targyak/opre/opre_beugro.zip (HOSSZÚ)
* https://vir.sch.bme.hu/document/targyak/opre/oprendszkidolg.zip
* Wikipédia
* Google segítségével fellelhető rengeteg forrás
* stb.

-- [[PeteHaro|Pete]] - 2011.06.19.
* [[Media:opre_beugro_ABC.docx|Operációs rendszerek vizsgabeugrók megoldással DOCX-formátumban (szerkeszthető, javítható!)]]
* [[Media:opre_beugro_ABC.pdf|Operációs rendszerek vizsgabeugrók megoldással PDF-formátumban]]

[[Category:Infoalap]]

Operációs rendszerek kidolgozott beugrókérdések vizsgára ABC-sorrendben

2015-06-10T11:00:11Z

Bolla Dávid: /* Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a */

==Bevezető==
Korábbi Wiki-n és InfoSite-on szereplő kidolgozott és kidolgozatlan anyagok, számtalan forrásból összeszedve - előadásdiákból, video.bme.hu-n lévő felvett anyagokból, Wikipédiás és egyéb, Google segítségével fellelhető anyagokból kiegészítve.
Hibák előfordulhatnak! TODO-val azokat a részeket jelöltem, amik átnézendők, rendbe szedendők, hiányosak, stb., ezeket is kérlek javítsátok, ha tudjátok! Köszi!
Ami fontos: ABC-sorrendbe rendezve szerepelnek a kérdések, így könnyebben megtalálható, tartsuk is meg ezt a tendenciát!
Remélem hasznát veszitek! -- [[PeteHaro|Pete]] - 2011.06.19.
Valamilyen szintű kategorizálást is beleraktam. A kérdések elejére odaírtam magának a kérdésnek a lényegét is, hogy könnyebben megtalálhatóak legyenek az azonos kérdéskörbe tartozóak.

==Beugrókérdések megoldással==
===Általános jellegű OS-ekkel kapcsolatos kérdések===

====Indulás: Hasonlítsa össze az általános célú (asztali) és a beágyazott operációs rendszereket az indulás szempontjából!====
<div class="answer">
A beágyazottnál először indul az alkalmazás, és az indítja az operációs rendszert, az asztalinál az operációs rendszer indítja az alkalmazásokat.
</div>

====Inkrementális mentés: Mit jelent az inkrementális mentés?====
<div class="answer">
Csak a változtatásokat mentjük az előző mentéshez képest -> kisebb helyet foglal, hamarabb végez a mentés.
</div>

====Kemény valós idejű rendszer: Adja meg a kemény valós idejű (hard real-time) rendszer definícióját!====
<div class="answer">
A rendszer adott eseményekre adott időn belül 1 valószínűséggel válaszol (egyébként hibás, hiába funkcionálisan jó a válasz). A rendszer NEM késhet!
</div>

====Lazán csatolt rendszer: Milyen szinkronizációs kényszereket jelent, ha egy lazán csatolt rendszer kommunikációja során véges kapacitású csatornát alkalmazunk?====
<div class="answer">
ha a küldő folyamat túl gyorsan küldözget, akkor a csatorna megtelik, úgyhogy túlcsordulás lesz, ami miatt a küldőnek várnia kell mielőtt újra küld.
</div>

====Rendszerhívások: Milyen előnnyel jár a rendszerhívások valamilyen magas szintű programnyelvvel történő megadása?====
<div class="answer">

Az API elrejti a rendszerhívások részleteit, bonyolultságát a programozó elől, lényegében egy wrapper réteggel fedi be a rendszerhívásokat.

</div>

====RPC: Milyen részekből áll az RPC technológia?====
<div class="answer">
* RPC: Remote Procedure Call, távoli eljáráshívás. Magas szintű folyamatok közti kommunikációt tesz lehetővé. Részei:
* a hívható eljárások és típusaik (interfész) leírása
* programgenerátor - rpcgen: a leírásból C programkódot generáló program
* kommunikációs infrastruktúra - portmapper: a programazonosítók és a hálózati portok összerendelése
</div>

====Statikus/dinamikus OS: Mikor nevezünk statikusnak, illetve dinamikusnak egy operációs rendszert?====
<div class="answer">
statikus: azok a rendszerek, amelyeknek muködése során - a felépülés és inicializálás kezdeti szakaszától eltekintve - nem jönnek létre és nem szűnnek meg folyamatok. dinamikus: működés közben bármikor születhetnek illetve megszünhetnek folyamatok.
</div>

====Szorosan csatolt rendszerek: Milyen rendszereket nevezünk "szorosan csatolt" rendszereknek?====
<div class="answer">
Ahol több CPU közös óra és közös memória segítségével működik együtt. Általában egyetlen operációs rendszer van, de az bonyolult. (Megjegyzés: az architektúrákból megtanult "közös erőforrást használnak" definícióra csak fél pontot adtak.)
</div>

===Erőforrás-hozzáférés===

====Elosztott rendszerek: Elosztott rendszerekben milyen konzisztencia kérdésekkel kell foglalkozni?====
<div class="answer">
* frissítés konzisztencia
* másolat konzisztencia
* cache konzisztencia
* hiba konzisztencia
* óra konzisztencia
* felhasználói interfész konzisztencia
</div>

====Erőforrás-gazdálkodás: Mi a különbség a hierarchikus és a globális erőforrás-gazdálkodás között?====
<div class="answer">
hierarchikus: a gyermek folyamatok csak a szülő erőforrásaiból részesülhetnek, és nem létezhetnek önállóan, csak amíg a szülőjük is létezik. globális: a rendszer valamennyi folyamata létrejötte után egyenrangú, önálló szereplő, és versenyezhet a teljes erőforráskészletből való részesedésért.
</div>

====Éhezés: Mi az az éhezés?====
<div class="answer">
A folyamatnak megvan mindene, ami a futásához kellene (ezért nem holtpont), de az erőforrásokat, amiket használni akar, más folyamatok kapják meg (ezért nem tud futni).
</div>

====Graceful degradation: Mit jelent a "graceful degradation" fogalma? ====
<div class="answer">
Fokozatos leromlás/összeomlás: Ha a rendszer terhelése eléri az ún. könyökkapacitást, akkor utána viselkedése megváltozik, a tovább növekvő terhelésre már egyre rosszabb működéssel reagál (overhead). Elvárható, hogy ezt fokozatosan tegye (ne omoljon össze).
</div>

====Kölcsönös kizárás====
<div class="answer">
Annak biztosítása, hogy a közös erőforrást egy időben csak annyi magában szekvenciális feladat használja, amely mellett a helyes működése garantálható.
A kölcsönös kizárást meg kell oldanunk a programban. Többnyire a használt erőforrást lock-oljuk (elzárjuk): nem engedjük hozzáférni a többi részfeladatot.
</div>

====Kritikus szakasz: Mit jelent a kritikus szakasz?====
<div class="answer">
A magában szekvenciális feladatok azon kódrészletei, amely során a kölcsönös kizárást egy bizonyos közös erőforrásra biztosítjuk. A kritikus szakasz a kérdéses közös erőforráshoz tartozik. A kritikus szakaszt a hozzá tartozó erőforrásra atomi műveletként (nem megszakítható módon) kell végrehajtanunk.
</div>

====Monitor: Mi a monitor alkalmazásának lényege? (Kölcsönös kizárás)====
<div class="answer">
A lockolás nem szétszórva történik a programban, hanem egyetlen, a közös erőforráshoz szorosan tartozó programrészletben.
</div>

====Prioritás öröklés: Mi a prioritás öröklés (Priority Inheritance, Pl) protokoll lényege? (prioritás inverzió témakör)====
<div class="answer">
Az alacsony prioritású feladat megörökli az általa kölcsönös kizárással feltartott feladat prioritását a kritikus szakaszából való kilépéséig. Csak részben oldja meg a prioritás inverzió problémáját.
</div>

====Test-and-set: Hogyan lehet Test_and_Set utasítással kritikus szakaszba lépést (entry) és kilépés (exit) megvalósítani?====
<div class="answer">
* Belépésnél csökkentjük a value értékét ezzel jelezve hogy használni akarjuk a kritikus szakaszt
* Kilépésnél növeljük a value értékét
Egy változót kijelölünk "lock object"-nek; ha ennek a tartalma 0, nincs senki a kritikus szakaszban. A kritikus szakasz elején egy ciklusban test-and-set-et hajtunk végre rá (az utasítást a ciklus feltételébe téve); ha valaki van a szakaszban már, a ciklusban fogunk keringeni, amíg ki nem lép belőle a másik. Amikor kilépett, a test-and-set következő végrehajtása beállítja a változót, és továbbengedi az egyik várakozó ciklust. A szakaszból kilépéskor pedig simán (nem test-and-set-tel) 0-ba állítjuk.
</div>

====Test-and-set: Hogyan működik a test_and_set?====
<div class="answer">
Visszaadja egy bit értékét, és ha 0 volt, 1-re állítja. Mindezt oszthatatlanul, vagyis ha 0 volt ott, és többen egyszerre hívtak rá test-and-set-et, akkor az egyiké teljesen lefut, 1-be állítja és nullát ad vissza, mielőtt a többi elkezdene futni (így ők mind 1-et fognak visszaadni)
</div>

====Újrahívhatóság: Mit jelent az újrahívhatóság (reentrancy) fogalma?====
<div class="answer">
A közös erőforrás problémájának egyfajta kiterjesztett esete egy függvényen/objektumon belül, mely akkor léphet fel, amennyiben ezt a függvényt/metódust egyszerre többen is meghívhatják. Előfordulhat akkor, ha ugyanazt a függvényt hívjuk egy taszkból és egy megszakítás-rutinból is, vagy ha preemptív ütemezés esetén ugyanazt a függvényt hívjuk két taszkból is.
</div>

===Holtpont===

====Definíció: Adja meg a holtpont definícióját!====
<div class="answer">
Egy rendszer folyamatainak egy H halmaza holtponton van, ha a H halmazba tartozó valamennyi folyamat olyan eseményre vár, amelyet csak egy másik, H halmazba tartozó folyamat tudna előidézni. Másként: A közös erőforrások hibás beállítása vagy használata miatt a rendszerben a részfeladatok egymásra várnak » nincs futásra kész folyamat; » nem jöhet létre belső esemény; » A rendszer nem tud előrelépni.
</div>

====Foglalva várakozás: Holtpont megelőzése (prevention) esetén milyen módszerrel lehet a foglalva várakozás előfordulását kizárni?====
<div class="answer">
* Az erőforrást birtokló feladat kér újabb erőforrást.
* Minden szükséges erőforrást egyben kell lefoglalni, egyetlen rendszerhívással.
* Alkalmazástól függ a használhatósága.
* Erőforrás-kihasználás romlik.
* A foglalva várakozás elkerülhető, ha minden folyamat betartja azt a szabályt, hogy az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el. A szabály betartásával megelőzhető a holtpont, de ára az erőforrás-kihasználás jelentős romlása.
* Ha a folyamatokat kötelezzük arra, hogy minden erőforrásukat egyszerre kérjék el. Ha meg akarjuk engedni a rákérést, akkor menthető állapotú erőforrások esetén megtehetjük, hogy a várakozó folyamatoktól elvesszük az erőforrásaikat.
</div>

====Kezelése: Az operációs rendszer milyen általános eljárásokat használhat a holtpont kezelésére?====
<div class="answer">
* strucc algoritmus (nem vesz róla tudomást)
* holtpont feloldása - melyik holtpontban érintett folyamatot számoljuk fel?
* menthető állapotú erőforrások elvétele,
* minél kevesebb folyamat felszámolása,
* folyamatok prioritása,
* már elvégzett munka,
* folyamatok visszaállíthatóságának biztosítása
* holtpont megelőzése
</div>

====Kialakulás szükséges feltételei: Sorolja fel a holtpont kialakulásának szükséges feltételeit!====
<div class="answer">
* Kölcsönös kizárás: Vannak olyan erőforrások a rendszerben, melyeket a folyamatok csak kizárólagosan használhatnak.
* Foglalva várakozás: legyen olyan folyamat mely lefoglalva tart erőforrásokat, miközben más erőforrásokra várakozik.
* Nincs erőszakos erőforrás-elvétel: a folyamatok addig birtokolják az erőforrást, míg saját jószántukból fel nem szabadítják azokat.
* Körkörös várakozás: Létezik a rendszerben egy olyan folyamatsorozat, melyben minden folyamat az utána következő folyamat által foglalt erőforrásra vár, a sorozat utolsó tagja pedig a sorozat első tagjára.
</div>

====Megelőzés, elkerülés: Mi a különbség a holtpont megelőzése (prevention) és holtpont elkerülése (avoidance) között?====
<div class="answer">
* megelőzése: olyan rendszert tervezünk, ahol nem teljesülnek a holtpont feltételei, így elvileg sem lehet holtpont.
* elkerülése (pl. bankár algoritmus): A rendszer minden erőforrásigény kielégítése előtt mérlegeli, hogy nem vezet-e holtpontveszélyre a kérés teljesítése, más szóval fennmarad-e a biztonságos állapot.

* ( Kölcsönös kizárás minimálisra csökkentése: lehetőleg többpéldányos erőforrásokat alkalmazunk, ahol ez nem lehetséges, ott a hozzáférést megpróbáljuk oszthatatlan műveletté tenni.
* Foglalva várakoztatás megszüntetése: Ha minden folyamat betartja a szabályt, miszerint az egyidejűleg szükséges valamennyi erőforrását egyetlen rendszerhívással kéri el, akkor elkerülhető a foglalva várakoztatás. Ennek ára van: az erőforrás-kihasználtság romlása.
* Nincs erőszakos erőforrás-elvétel kiküszöbölése: Ha menthető állapotú erőforrásaink vannak, akkor megtehetjük, hogy elvesszük egy adott folyamat erőforrását és egy másiknak adjuk, majd annak lefutása után visszaadjuk a régi állapotában az erőforrást az első folyamatnak.
* Körkörös várakozás megakadályozása: A folyamatok megegyeznek az erőforrások sorszámozásában, minden folyamat csak nagyobb sorszámú erőforrást igényelhet azoknál az erőforrásoknál melyeket birtokol. Ekkor biztosan nem alakulhat ki kör.)
</div>

===Fájlrendszerek===

====Fájl: Mi a fájl az operációs rendszer szempontjából? (háttértár-kezelés)====
<div class="answer">
* a fájl a permanens táron az adattárolás logikai egysége, az operációs rendszer feladata a logikai egységek (fájlok) leképzése valódi fizikai egységekre, ez az OS-ben egy többszintü réteges rendszer
* Absztrakt adattípus (objektum, fájl mutató).
* Adat, név (name - elnev. konvenciók), típus (type - kezelés módja) tulajdonságok (attributes). Tulajdonosok, jogosultságok. Hozzáférési időpontok
* Kölcsönös kizárás (file locking)
* TODO
</div>

====Háttértáron lévő lapok: Milyen részidőkből áll össze a háttértáron levő lapokhoz való tényleges hozzáférési idő? Kis vagy nagy lapok használata esetén kapunk "jobb" byte hozzáférést?====
<div class="answer">
* adatátviteli sebesség + fejmozgás sebessége + lemezek forgási sebessége
* nagy lapok esetén ( mert így közvetlenül egymás után helyezkednek el az összetartőző adatok így nem kell a fejnek "ugrálnia" )
* Először a laptáblából kell kikeresni a lap bejegyzését, és konstatálni, hogy nincs hozzá fizikai lap rendelve. Majd, ki kell választani egy szabad fizikai lapot (ha nincs, ki kell vinni egyet háttértárra), a szabad helyre beolvasni a lapot, majd újraindítani a laphibát okozó utasítást. Ezek közül a háttértárról olvasás nagyságrendekkel lassabb a többinél, ezért lényegében ez határozza meg a teljes hozzáférési időt.
* Ha csak a háttértáron lévő lapokat nézzük, akkor, mivel kisebb lapot gyorsabban lehet beolvasni, ezért kisebb lapoknál gyorsabb a hozzáférés. Ha egy folyamat teljes munkahalmazát nézzük, akkor viszont a kisebb lapok több adminisztrációs költséggel járnak (gyakrabban kell háttértárhoz fordulni), és átlagban a nagyobb lapok adnak jobb eredményt.
</div>

====Indexelt tárolás: Sorolja fel az indexelt tárolás (indexed allocation) előnyeit és hátrányait! (Fájlrendszer-leképzés)====
<div class="answer">
* Szekvenciális és indexelt elérésre is alkalmas.
* Sérülékeny (az index blokkok sérülése a fájlt elérhetetlenné teszi).
* Az index blokkokat viszont könnyű többszörözni (replikálni).
* Sok fejmozgást okoz (seek), a blokkok el vannak szórva a diszken.
* Itt is lehet a láncolt listás töredezettség mentesítéshez hasonló algoritmusokat használni a fejmozgás minimalizálására.
</div>

====RAID: Sorolja fel a RAID technika leglényegesebb elemeit!====
<div class="answer">
* Használjunk több merevlemezt egyszerre.
* Több redundáns alkalmazása növeli a megbízhatóságot.
* Több párhuzamos használata növeli a sebességet.
* Hozzunk létre egy virtuális diszket a fizikai diszkekből.
* Redundant Array of Inexpensive Disks: több lemez összekapcsolása.
* A RAID-0 esetében két lemezre vannak szétosztva az adatok, így egyetlen fájlt kétszer akkora sebességgel lehet írni (a két felét parhuzamosan).
* A RAID-1 esetében ugyanazt az adatot tároljuk le a két lemezen, így gyorsabb nem lesz, de az egyik lemez hibája esetén visszanyerhetőek az adatok.
* Megjegyzés: ez csak példa, több lemezzel is lehet csinálni, a sebesség/tárhely/hibatűrés között különböző kompromisszumokat elérve.
</div>

====RAID0 vs. RAID1: Hasonlítsa össze két azonos diszkből álló RAID0 és RAID1 tömb tulajdonságait! Hogyan alakul a hozzáférési idő, az adatátviteli sebesség és a megbízhatóság egyetlen diszkhez képest a két esetben?====
<div class="answer">
RAID 0-1 szabványok általában SW implementációval és kevés (2db) diszkkel
* RAID 0 (striped disks):
** Több diszk párhuzamos használata;
** file részei N diszkre kerülnek;
** Az egyes részek egymástól függetlenül elérhetők
** A diszkek tárolókapacitása összeadódik
** N azonos diszk esetén a RAID 0 virtuális diszk olvasásai és írási adatátviteli sebessége maximum N-szeres közelébe nő.
** A hozzáférési idő közel eléri egy diszk hozzáférési idejét.
** Bármelyik diszk meghibásodása esetén az adat elveszik
* RAID 1 (mirroring):
** Több diszk redundáns használata.
** A file minden része minden (N) diszkre kikerül.
** Azonos diszkeket feltételezve a tárolóterület egy diszk tárolóterületével azonos.
** Az adatátviteli sebesség lassabb, mint egy diszk sebessége.
** A hozzáférési idő nő.
** Speciális esetben az olvasási sebesség N-szeresre nőhet, feltételezve a diszk meghibásodásának más módon történő észlelését (nem kell az azonosságot ellenőrizni többségi szavazással).
** Egy működőképes diszk esetén az adat elérhető.
</div>

====RAID5: Adja meg az M (M pozitív egész szám) diszket tartalmazó RAID5 tömb tulajdonságait! (hibatűrés és sebesség)====
<div class="answer">
* RAID 5 (block interleaved distributed parity).
* Több diszk redundáns és párhuzamos használata
* Adat és paritás elosztása N+1 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 1 diszk meghibásodása esetén az adat elérhető.
** 2 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error). A 2. meghibásodás észlelése a tömb újraépítése során)
</div>

====RAID5: Miért előnyös és miért hátrányos RAID5 használata?====
<div class="answer">
* + N azonos diszk esetén az olvasási és írási adatátviteli sebessége maximum N-szeres közelébe nő.
* + 1 diszk meghibásodása esetén az adat elérhető.
* - 2 vagy több diszk meghibásodása esetén az adat elveszik.
* - Az adat nem feltétlenül állítható helyre. (Csendes/néma hibák (silent error).
* -Bonyolultabb, mint a Raid 0/1, ezért hardveresen valósítják meg, ami viszont drága
</div>

====RAID6: Adja meg a 8 darab 1 Tbyte-os HDD-ből álló RAID6 tömb tárolókapacitását!====
<div class="answer">
6 TB. (Adat és paritás elosztása N+2 diszkre. A kapacitása N diszk tároló kapacitásával egyenlő.)
</div>

====RAID6: N db azonos diszkből álló RAID6 tömb esetén a tömb tárolókapacitása és sebessége (nagy fájlok írása/olvasása során elérhető adatátviteli sebesség) hogyan viszonyul az egyetlen diszk azonos adataihoz?====
<div class="answer">
* RAID 6 (block interleaved dual distributed parity)
* Több diszk redundáns és párhuzamos használata.
* Adat és paritás elosztása N+2 diszkre.
** A sebesség tekintetében közel áll az N diszket használó RAID 0-hoz (HW támogatás esetén).
** 2 diszk meghibásodása esetén az adat elérhető.
** 3 vagy több diszk meghibásodása esetén az adat elveszik.
** Az adat nagyobb valószínűséggel állítható helyre a RAID 5-höz képest
* Minimum négy lemezre van szükség a RAID 6 működéséhez. The capacity of the array is (N-2) times the size of the smallest member disk for the array of N disks.
* Az olvasási sebesség (N-2)-szerese egy lemez olvasási sebességének - two disks in the row hold a parity which is useless to read. Such read speed values are roughly the same as in RAID 5.
</div>

====Tárolás egysége: Mi a logikai és mi a fizikai tárolás egysége a permanens táron?====
<div class="answer">
* logikai egység: fájl (file)
* fizikai egység: adatblokkok (cilinder, sáv és szektor együtt azonosítja az írható/olvasható adatblokkot; OS képzi le a logikaiakat fizikaiakra)
</div>

===Folyamatok, szálak===

====Bernstein feltétele: Mikor lehet két tevékenységet (utasítássorozatot) párhuzamosan végrehajtani (Bernstein)?====
<div class="answer">
Bernstein feltétele:
* Legyen <math> P_i </math> és <math> P_j </math> két darabja egy programnak.
* A <math> P_i </math> összes bemeneti változója <math> I_i </math>, és az összes kimeneti változója <math> O_i </math>, ugyanez <math> P_j </math> -re <math> I_j </math> és <math> O_j </math>.
* A két program párhuzamosan végrehajtható (vagyis független), ha: <math> I_j \bigcap O_i = 0 </math>, <math> I_i \bigcap O_j = 0 </math> és <math> O_i \bigcap O_j = 0 </math>
</div>

====Feladatok (task) együttműködése: Hasonlítsa össze a közös memórián illetve az üzenetváltáson alapuló folyamatok közti együttműködést!====
<div class="answer">
Közös memórián keresztül történő adatcsere esetén az együttműködő folyamatok mindegyike saját címtartományában lát egy közös memóriát. A közös memória elérését valamilyen adatátviteli rendszer teszi lehetővé. Üzenetváltásos adatcsere esetén a folyamatoknak nincs közös memóriája. Az adatátviteli rendszer most a logikai processzorokat kapcsolja össze. Rajta keresztül a folyamatok üzeneteket tudnak küldeni, illetve fogadni. Az üzenetküldésre a folyamatok logikai processzorainak utasításkészletében megfelelő utasítások állnak rendelkezésre. Ezek a Küld (Send) és a Fogad (Receive) műveletek.
</div>

====Folyamat: Definiálja a "folyamat" (process) fogalmát!====
<div class="answer">
* Egy program futás alatt álló példánya a folyamat.
* saját kód, adat, halom, verem
* A folyamatok nem férnek hozzá egymás lapjaihoz (védettek más folyamatoktól)

* végrehajtás alatt álló program (program maga a végrehajtható kód), amely folyamat virtuális címterébe van leképezve
* folyamat egy szála az, ami éppen fut egy CPU-n, és nem maga a folyamat
* minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát
* privát virtuális címtér (virtuális memóriacímek készlete, amiket a folyamat használhat)
* tartozik hozzá egy egyedi folyamatazonosító (process ID)
* rendszererőforrások listája, melyekhez a folyamat összes szála hozzáfér
* a folyamat virtuálisan összefüggő memóriát lát (virtuális memória) (valójában az összefüggő memóriaterület ritka)
* háttértárolóra is kiírható (swapping)
* A folyamat által látott logikai címtartomány, és a ténylegesen használt fizikai címtartományok teljesen elkülönülnek
* Folyamatok megoszthatnak memóriaterületeket olvasás- vagy akár írás- és olvasás-hozzáféréssel (Az ilyen memória területek több folyamat virtuális címtartományába vannak belapozva)
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 IPC (Inter-process communication) megoldást!====
<div class="answer">
* '''Jelzés''': rendszerüzenetek küldése és fogadása a folyamatok között, jellemzően utasítások továbbítása egyik folyamattól a másiknak
* '''Üzenetsor''': aszinkron kommunikációs forma, mely során a küldő és fogadó közvetlen interakciója nem szükséges, az üzenetek addig tárolódnak a sorban amíg a címzett fel nem dolgozza azokat vagy a sor meg nem telik
* '''Szemafor''': absztrakt struktúra amely a folyamatok közötti közös erőforrásokért való hozzáférést vezérli
* '''Közös memória''': ugyan az a memóriaterület kerül kiosztásra több különböző folyamatnak, írási és olvasási joggal egyaránt

''Forrás'': http://en.wikipedia.org/wiki/Inter-process_communication
</div>

====Folyamatok vs. szálak: Mi az eltérés a folyamatok illetve a szálak között, és milyen előnnyel jár a szálak alkalmazása?====
<div class="answer">
A szálak lényegében párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
</div>

====Java-szálak: Milyen módokon képezheti le a JAVA virtuális gép a JAVA natív szálakat a hoszt operációs rendszer folyamataira/szálaira?====
<div class="answer">
A JAVA virtuális gép egy folyamat a hoszt operációs rendszeren belül. A JAVA szálak feleltethetők meg a hoszt operációs rendszer szálainak, ez többnyire one-to-one (JAVA szál egyben OS szál is) napjainkban. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/20100507_ZH_megoldas.pdf)
Kovácsházy Tamás válasza:
7. fólia, 11. fólia:
JAVA (VM a folyamat, VM-en belül szál):
* Thread osztályból származtatva
* Runnable interface megvalósítása
* A JAVA platform-specifikusan valósítja meg a szálat:
* Natív OS specifikus szál (one-to-one, tipikus).
* JAVA specifikus szálak (many-to-one) egy natív OS szálra vagy folyamatra leképezve.
* many-to-many leképzés (erőforrás szempontok miatt, egyre ritkább).

</div>

====PRAM: Mi történik a PRAM modellben írás-írás ütközés esetén?====
<div class="answer">
Az írás-írás ütközésekor valamelyik művelet hatása érvényesül, a két beírni szándékozott érték valamelyike írja felül a rekesz tartalmát (versenyhelyzet), harmadik érték nem alakulhat ki.
</div>

====Processzor-affinitás: Mit állítunk be, ha egy szálnak beállítjuk a processzor affinitását, és miért lehet arra szükség?====
<div class="answer">
* processzoraffinitás: minden szál rendelkezik egy maszkkal, amely kijelöli, hogy a szál mely processzorokon képes futni
* szerepe: ez alapján dől el, hogy a szál mely processzoron fog futni
* ütemezésnél: multiprocesszoros esetben a processzor kiválasztása a processzor-affinitás alapján történik
* A feladat más processzorra, vagy processzormagra kerülése csökkenti a végrehajtás sebességét (pl. cache-elésnél) >> Cél: A feladatot ugyanazon a végrehajtó egységen tartani - Laza vagy kemény processzor affinitás (soft or hard processor affinity).
** Laza: Nincs garancia, de törekszik rá az OS (többnyire alapeset)
** Kemény: Biztosan ugyanazon a CPU-n marad (rendszerhívással)
</div>

====Szál: Definiálja a "szál" (thread) fogalmát!====
<div class="answer">
* párhuzamos végrehajtású, közös memóriát használó programrészek a folyamaton belül (egy program végrehajtása több szálon futhat). A szálaknak saját logikai processzoruk és saját vermük van, azonban memóriáik nincsenek elkülönítve, közös logikai memóriát használnak, azaz a kódon és a változókon osztoznak, vagyis egymás adatait olvashatják és írhatják. Emiatt az operációs rendszer lényegesen gyorsabban tud végrehajtani egy átkapcsolást a szálak között, mint a folyamatok között.
* A folyamat egy szála az, ami éppen fut egy CPU-n (ami ütemezésre kerül), és nem maga a folyamat.
* Minden folyamathoz tartozik legalább egy szál, ami elinduláskor elkezdi futtatni a program main metódusát (szál nélkül a folyamat programja nem futhat).
* szálak még véletlenül sem hivatkozhatnak más folyamatok címterére, hacsak a másik folyamat nem teszi elérhetővé privát virtuális címterének egy részét megosztott memóriaszakaszként (file mapping object a Windows API-ban), vagy - Windows-nál - hacsak egyik folyamatnak nincs joga megnyitni más folyamatot, hogy olyan folyamatok közti memóriafüggvényeket használjon, mint a ReadProcessMemory vagy WriteProcessMemory
* A szál önmagában szekvenciális kód, a végrehajtás legkisebb egysége. Egy adott folyamat szálainak közös az adat- és kódszegmensük, a halmuk (heap), és az egyéb erőforrásokat is közösen használják, de saját virtuális CPU-t látnak, és saját veremmel rendelkeznek.
* TODO
</div>

====Védelmi tartományok: Mi a különbség a statikus és a dinamikus védelmi tartományok között?====
<div class="answer">
Statikus védelmi tartományok esetén az egy folyamathoz tartozó védelmi tartomány a folyamat végrehajtása során nem változik, míg dinamikus védelmi tartományok esetén igen.
</div>

====Virtuális gép: Mi a virtuális gép koncepció lényege?====
<div class="answer">
* A programok elől az operációs rendszer elfedi a hardver implementációs részleteit, és kibővíti azt plusz funkciókkal.
* Az op.rendszer egy olyan réteget képez a hardver fölött, mely elrejti annak körülményességét és bonyolultságát a programozó elől és kibővíti a hardver szolgáltatását. A felhasználó így egy sokkal kellemesebb virtuális gépet (virtual machine, extended machine) lát.
* Az operációs rendszer egy kényelmesen kezelhető virtuális gépet jelenít meg a felhasználói és a programozói felületen.
</div>

===Jogosultságok===

====Belső biztonság: Mi a belső biztonság?====
<div class="answer">
Belső biztonság = védelem. Védelemnek nevezzük az eljárásoknak és módszereknek azon rendszerét, amely lehetőséget teremt a számítógép erőforrásainak programok, folyamatok illetve felhasználók által történő elérésének szabályozására.
</div>

====Engedélyezés: Definiálja az engedélyezés (authorization) fogalmát!====
<div class="answer">
* jogosultság ellenőrzése: milyen adatokat és szolgáltatásokat érhet el ez a személy?
* Hozzáférés-szabályozási listák (Access Control List, ACL)
* Alapelv: mindig csoportnak osztunk jogot
* Pl. biztonsági házirend, fájl ACL

TODO!!!
</div>

====Jogosultság + engedélyezési sémák: Mi a jogosultság fogalma, mi a kapcsolata az engedélyezési sémák többi alapfogalmával?====
<div class="answer">
* A jogosultság egy reláció a szereplők és védett objektumok között.
* engedélyezés ált. sémáinál: szereplő>>>szereplőt leíró adatszerkezet>>>biztonsági szabályzat (policy), JOGOSULTSÁG>>>védett objektumok TODO
* Jogosultságkezelés alapjai: A rendszer működése során
** A szereplők műveleteket kezdeményeznek
** A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját
** A jogosultsági döntő komponens kiértékeli kontextust és engedélyezi vagy megtiltja a műveletet
** A jogosultsági végrehajtó komponens biztosítja, hogy a döntő által hozott döntés érvényre jusson
* NT: SMR (Secure Reference Monitor) - objektumok elérési jogosultságainak ellenőrzése
* NT: Az LSA a SAM segítségével azonosítja a felhasználót és jogosultságait. Ha a felhasználó jogosult bejelentkezni, a logon elindítja a számára kijelölt shellt
* UNIX: hozzáférési jogosultságok (owner, group, others, read, write, execute)
* Engedélyezés általános sémái: >>Szerep alapú hozzáférés-vezérlés >>Hozzáférési jogosultság listák
* TODO
</div>

====Külső biztonság: Mit takar a külső biztonság fogalma?====
<div class="answer">
Annak mértéke, hogy mennyire lehetünk biztosak a számítógépes rendszer, illetve a rendszerben tárolt adatok sérthetetlenségében.
</div>

====Művelet kontextusa: Engedélyezési rendszerekben mit tartalmaz egy művelet kontextusa? (Felhasználó- és jogosultságkezelés)====
<div class="answer">
A műveletek kontextusa tartalmazza a szereplő azonosítóját, a célobjektumot és az elvégzendő művelet fajtáját.
</div>

===Hibakeresés===

====DTrace: Mi a Solaris DTrace megoldás célja?====
<div class="answer">
dinamikus hibakereső rendszer, nyomkövető eszköz, amivel a rendszer és a programok működését futási időben lehet megfigyelni.
</div>

===Memória===

====32 bit: 32 bites kliens Windows operációs rendszer maximum mennyi fizikai memóriát kezelhet, és miért?====
<div class="answer">
Legfeljebb 4 GB-ot (bár néha kevesebbet lát az OS, mert a memóriatartomány felső részére I/O eszközöket szoktak berakni, ld. pl. videókártya-memória...): ''"kliens Windowsok nem használják a gépben lévő PAE támogatást, mert az a tapasztalat, hogy a kliensekben lévő eszközök meghajtói nem kezelik le rendesen a 4 GB-nál több fizikai memóriát"''.
(https://wiki.sch.bme.hu/pub/Infoalap/OpRe/02-opre-windows-memoria.pptx)
(nem támogatják a PAE-t eleve, csak patch-csel)
(_"However, "client" versions of 32-bit Windows (Windows XP SP1 and later, Windows Vista, Windows 7) limit physical address space to the first 4 GB for driver compatibility and licensing reasons, even though these versions do run in PAE mode if NX support is enabled."_ - http://en.wikipedia.org/wiki/Physical_Address_Extension)
</div>

====32 bit: 32 bites szerver Windows képes-e 4 GB-nál több fizikai memória kezelésére? Válaszát indokolja!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével (ezzel lehet 32 bites címbuszú CPU-val is 64 GB memóriát kezelni a maximális 4 GB helyett).
</div>

====32 bit: 32 bites Windows használata esetén egy felhasználói folyamat maximum mekkora virtuális címteret használhat?====
<div class="answer">
Alapból 2GB felhasználói módú címterületet használhat, ez a /3GB kapcsolóval 3 GB felhasználói címterületre bővíthető.
</div>

====32 bit: 32 bites Windows szerver operációs rendszerek képesek-e 4 GB-nál több fizikai memória kezelésére? Indokolja válaszát!====
<div class="answer">
Igen, PAE (Physical Address Extension) támogatás segítségével.
</div>

====32 bit: 32 bites x86-os (Windows) esetén mekkora a felhasználói és a rendszer mód címtartomány mérete?====
<div class="answer">
Alapból 2GB felhasználói módú és 2GB kernel címterület van, ezt a /3GB kapcsolóval 3GB felhasználói és 1GB kernelre lehet módosítani.
</div>

====Bélády-anomália: Mit nevezünk Bélády-anomáliának?====
<div class="answer">
FIFO algoritmusnál egyes esetekben, ha a munkahalmaz méretét növeljük, a várakozásokkal ellentétben a laphibák száma is nő.
</div>

====Címfordítás: Hogyan történnek a címfordítások, ha az OS szegmens- és lapszervezést is használ a memóriánál?====
<div class="answer">
CPU --> Segmentation unit --> Paging unit --> Physical memory
</div>

====Címfordítás: Milyen címtranszformációk történnek együttes szegmens- és lapszervezésű memória használata során?====
<div class="answer">
* CPU >>>[Logical Address]>>> '''Segmentation Unit''' >>>[Linear Address]>>> '''Paging Unit''' >>>[Physical Address]>>> Physical Memory (http://portal.mit.bme.hu/?l=oktatas%2Ftargyak%2Fvimia219%2Fjegyzet%2F2011%2Fslides_17_memory.pdf)
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/oprewiki1.pdf, 48. oldaltól.
* Változó méretű szegmensek fix méretű lapokat tartalmaznak. Kicsi mind a belső, mind a külső tördelődés. A cím felépítése: (szegmens szám, lapszám, lapon belüli eltolás)
* Hasonlít a szegmensszervezéshez és a kétszintű lapszervezéshez: A memóriában szegmensek vannak ugyan, de ezek lapokból épülnek föl. Van szegmenstábla, és minden bejegyzéséhez tartozik egy laptábla is. Külső töredeződés nincs, belső töredeződés minimális (szegmensenként átlag fél lap); ez a kombinált módszer egyesíti a két módszer előnyeit
* TODO
</div>

====Lapszervezés, keret tábla: Lapszervezés esetén mit tartunk nyilván a keret táblában (frame table)?====
<div class="answer">
Az üres kereteket (frames).
</div>

====Logikai vs. fizikai memória: Mi a különbség a logikai és a fizikai memória között?====
<div class="answer">
A logikai memória a fizikai tár leképezve, ráadásul a leképezés a végrehajtás során változhat is.
</div>

====MMU: Mi a processzor Memory Management Unit (MMU) komponensének a feladata?====
<div class="answer">
* Speciális HW a CPU-ban
* Memória állapotának nyilvántartása
** Tulajdonos folyamat azonosítója
** Hozzáférési jogosultságok (ACL)
** cache-elhetőség, ha van cache (pl. DMA)
* Virtuális memória leképzése fizikai memóriára
** Pl. Translation Lookaside Buffer (TLB)
** Kontextusváltásnál ezt is kezelni kell (ha van)
** Pagefile vagy SWAP (HDD)
* Memóriavédelem
** Tiltott memória hozzáférés megakadályozása vagy legalább jelzése (ACL alapján)
** General Protection Fault (GPF) a Windows-ban
</div>

====Modified/dirty bit, referenced/used bit: Mi a modified/dirty bit és a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* laptáblában:
* Módosítás nyilvántartása (modified/dirty bit): minden memórialaphoz tartozik egy HW által kezelt bit (pl. a laptáblában) - betöltéskor törlik, módosításkor beállítják. Ha a dirty bit 1, akkor erre a lapra történt írási művelet, mióta a ﬁzikai memóriába került. Ezt a bitet a CPU tartja karban (automatikusan), ezzel az operációs rendszer munkáját segítve. 0 érték esetén a lapokat nem kell a diszkre kiírni, ha kiszorulnak a ﬁzikai memóriából (hiszen a tartalmuk a ﬁzikai memóriába helyezés óta változatlan, a diszk-en tárolt változat tehát továbbra is aktuális).

* Hivatkozások nyilvántartása (referenced/used bit): Ha a refernced bit 1, akkor volt "mostanában" hivatkozás erre a lapra. Ezt is a CPU tartja karban. Ez a bit segít az operációs rendszernek, amikor el kell döntenie, hogy melyik lapot dobja ki a ﬁzikai memóriából, ha egy új lapnak nincs helye. A referenced=0 lapokból fog válogatni.
</div>

====Page locking: Mit jelent és miért van szükség arra, hogy a virtuális tárkezelésnél egyes lapokat ideiglenesen a tárba lehessen "fagyasztani" (page locking)?====
<div class="answer">
* Azt jelenti, hogy a lapcsere algoritmus nem lapozhatja ki a háttértárra az adott lapot. Ok: periféria-művelet van az adott lappal kapcsolatban.
* Azt jelenti, hogy bizonyos lapokat a memóriában tartunk, mert I/O műveletek hivatkozhatnak rá, és ilyenkor a memóriában kell lenniük, mert az I/O műveletek fizikai memóriacímeket használnak.
</div>

====Referenced/used bit: Mi a referenced/used bit szerepe? (Virtuális memóriakezelés)====
<div class="answer">
* Bizonyos algoritmusok igénylik a lapra történő hivatkozások figyelését is, ami ugyancsak hardvertámogatással hatékony. A laptáblában erre a célra is fenntarthatunk egy bitet. Ezt a hivatkozott bitet (referenced bit, used bit, R bit) a címképző hardver állítja be minden esetben, amikor az adott lapon belüli címre történik hivatkozás. A bitet az operációs rendszer törli adott időnként, vagy eseményhez (például laphiba) kötötten.
* Hivatkozások nyilvántartása (referenced/used bit): OS adott időnként és/vagy adott eseményekre törli - használat esetén beállítják.
</div>

====TLB: Mi az a Translation Lookaside Buffer, fizikai címcsatolásnál mi a szerepe?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.
</div>

====TLB: Mire szolgál a Translation Lookaside Buffer és mi a szerepe a fizikai cím kiszámításánál (virtuális címképzés)?====
<div class="answer">
A virtuális címet fizikai címre a laptábla segítségével lehet fordítani; de ez lassú, plusz egy memória-hozzáférést jelent. Ezért a lapkezdőcímek egy részét egy asszociatív cache-ben eltárolják, ez a TLB. Címfordításkor párhuzamosan indul a keresés a laptáblában és a TLB-ben, ha az egyikben megtalálta, akkor kész.

(Szerintem előbb a TLB-ben keresi, aztán ha ott nincs, csak utána nézi a laptáblát.)
</div>

====Tördelődés (külső vs. belső): Mi a különbség a külső és belső tördelődés között? (Memória foglalás)====
<div class="answer">
A tördelődött memóriaterületet külső tördelődés esetén az operációs rendszer szabadon hagyja, míg belső tördelődés esetén pedig odaadja egy olyan folyamatnak, aminek nincs igazából rá szüksége.
</div>

====Vergődés: Adja meg a vergődés (trashing) definícióját!====
<div class="answer">
A gyakori laphibák okozta teljesítménycsökkenést vergődésnek (thrashing) nevezzük. Az ellene való védekezés a munkahalmaz méretének jó megválasztása. Célszerű egy folyamatnak annyi lapot adni, amennyi szükséges az egyensúlyhoz, azaz ahány lapra hivatkozik a laphiba kiszolgálás ideje alatt (ugyanakkor nem sokkal többet, mert ekkor leromlik a multiprogramozás foka).
</div>

====Vergődés: Mi az a vergődés, és hogyan védekezzünk ellene?====
<div class="answer">
* Ha több memóriára lenne szüksége a folyamatoknak, mint amennyi rendelkezésre áll, ezért túl gyakran keletkezik laphiba, és a processzor idejének nagy része haszontalan lapcserékkel telik.
* Védekezni ellene például azzal lehet, ha a laphiba-gyakoriság függvényében az ütemező változtatja a multiprogramozás fokát: ha kevés a memória, folyamatokat függeszt fel, és swappel ki; ha van elég, akkor épp ellenkezőleg.
</div>

===uc/OS-II===

====Prioritás: A uC/OS-II-ben hány taszk tartózkodhat egy prioritási szinten és miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk.
</div>

====Prioritás: Egy prioritási szinten hány szál futtatását teszi lehetővé a uC/OS-II, miért?====
<div class="answer">
1, mert így gyorsan eldönthető, hogy melyik a legmagasabb prioritású, futásra kész taszk. Egy taszk = egy szál.

(Magyarázat: egy taszk = egy szál; lásd http://video.bme.hu/media/video/Operacios_Rendszerek_08ea_20110301.wmv, 01:09:18 környékén
Röviden: a beágyazott rendszerek, kis OS-ek esetén (uC/OS-II, FreeRTOS, stb.) lényegében csakis szálakban gondolkozunk. Nincs MMU, csak egyetlen összefüggő fizikai memória van, nincs virtuális memória koncepció, a processzoron futó teljes alkalmazás (az egyetlen alkalmazás) egy nagy folyamat - nincs más folyamat! Ezenbelül tudunk threadeket futtatni. Single Address Space.)
</div>

===Ütemezés===

====Átbocsátó képesség: Adja meg az átbocsátó képesség definícióját és mértékegységét!====
<div class="answer">
* (throughput) Mértékegység: munka/s, vagy 1/s
* Adott időegység alatt elvégzett feladatok száma. <math>\frac{\sum \textrm{elvegzett munkak}}{\textrm{ido}}</math>
* A rendszerfeladatokat nem számoljuk.
</div>

====Hosszú távú ütemezés: Adja meg a hosszú távú ütemezés célját!====
<div class="answer">
Tipikusan a BATCH rendszerekben van jelen, és uj jobok végrehajtasának megkezdéseről (új folyamatok indítasárol) dönt. Az elvégzesre váro munkák közül a választas szempontja, hogy a rendszerben a CPU-intenzív es I/O-intenzív folyamatok aránya optimális legyen (optimalis job-mix fenntartasa).
</div>

====Hosszú távú ütemezés: Definiálja a hosszú távú ütemezés fogalmát!====
<div class="answer">
A hosszútávú ütemező feladata az elindított feladatok rendszerbe, illetve a "futásra kész" várakozási sorba való beengedését szabályozni. Igyekszik a CPU-t és a perifériákat terhelő folyamatokat egyensúlyban tartani. Batch rendszerekre jellemző; a PC-k oprendszere általában azonnal indítja a folyamatokat, mikor azt a felhasználó kéri.
* feladata: A háttértáron várakozó feladatok közül kiválasztja azt, amelyiket el kell indítani.
</div>

====Konvoj hatás: Mi a konvoj hatás, és a tanult ütemező algoritmusok közül melyekben jelentkezhet?====
<div class="answer">
* igen nagy lehet az átlagos várakozási idő, mivel egy-egy hosszú CPU-löketű folyamat feltartja a mögötte várakozókat
* FCFS-nél (First-come, first-served) tapasztalható (pl. SJF (Shortest Job First) és RR algoritmus küszöböli ki)
</div>

====Középtávú ütemezés: Adja meg a középtávú ütemezés célját!====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.
</div>

====Középtávú ütemezés: Mi a középtávú ütemező feladata?====
<div class="answer">
Swapping, azaz a program a fizikai memória és a háttértár közti mozgatása.

Szerintem inkább ez:
A rendszerben lévő feladatok memóriájának egyes éppen nem használt részeinek kiírása háttértárra.
</div>

====Körülfordulási idő: Mi az a körülfordulási idő?====
<div class="answer">
* TAT (Turnaround Time) -> Egy feladatra vonatkozóan a rendszerbe helyezéstől a teljesítésig eltelt idő.
* Mértékegység: s,
* t_(CPU,végrehajtási idő)+t_várakozás (Magában foglalja a ténylegesen munkával töltött időt és a várakozást is.)
* felhasználó minél előbb szeretné látni a végeredményt
</div>

====Megszakítás: Az éppen futó taszkot megszakítja egy IT. Preemptív OS esetén mindig a megszakított taszk fogja-e visszakapni a futási jogot? Miért?====
<div class="answer">
* Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
* Másik: Nem, mert akitől elvették a futás jogát az futásra kész állapotba fog kerülni és az ütemező dönti el, hogy melyik folyamat fogja megint megkapni a futást.
</div>

====Megszakítás: Egy futó taszkra IT érkezik. Preemptív OS esetén az interrupt után mindenképpen 'ide' térünk vissza?====
<div class="answer">
Nem feltétlenül; például a preemptálás maga is úgy működik, hogy egy időzítő a szál quantumjának lejártakor megszakítást generál; ilyenkor értelemszerűen az ütemező általában nem ugyanazt a folyamatot választja ki futásra.
</div>

====Preemptív ütemező: Mikor nevezünk egy ütemezőt preemptívnek? ====
<div class="answer">
Ha az OS elveheti a futásjogot (a CPU-t) egy folyamattól/futó feladattól (interrupt).
</div>

====Rövid távú ütemezés: Mi a rövidtávú ütemezés, mikor jár környezetváltással?====
<div class="answer">
* Rövidtávú ütemezés: futó folyamat kiválasztása a futásra kész feladatok közül
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Rövid távú ütemezés: Mikor fut a rövidtávú ütemező és mikor jár környezetváltással?====
<div class="answer">
* Ütemezés következhet be, ha
** a futó folyamat befejeződik,
** egy folyamat felébred, futásra késszé válik,
** a futó folyamat várakozni kényszerül (valamilyen esemény bekövetkezésére), illetve,
** a futó folyamat önként lemond a futás jogáról vagy pedig elveszik tőle.
* Az első és a harmadik esetben az ütemezés mindig környezetváltással jár, hiszen a következő futó folyamat egészen biztosan nem a korábban futott lesz. A másik két esetben előfordulhat, hogy az ütemezőnek nem kell másik folyamatot kiválasztania.
* Ha a futó folyamatnak lejár az időszelete (csak preemptívnél), önként lemond a processzorról (együttműködő folyamatok), blokkoló rendszerhívást hajt végre (pl. I/O művelet), egy másik szál futásra kész állapotba kerül (bekövetkezik, amire várt, vagy újonnan elindítanak egy szálat), egy szál prioritása megváltozik, esetleg egy szál processzor-affinitása megváltozik.
* Környezetváltással akkor jár, ha másik szál választódik ki futásra, mint ami eddig futott. Pl. Windows NT alatt, ha a legmagasabb prioritási szinten pontosan egy folyamat van, akkor megtörténhet, hogy ugyanaz a szál fut tovább, és nem történik környezetváltás.
</div>

====Terhelés-végrehajtó egységek közötti megosztás: Sorolja fel a terhelés-végrehajtó egységek közötti megosztásának megoldásait! (Többprocesszoros rendszerek)====
<div class="answer">
* Master and slaves (egy CPU osztja ki a feladatokat)
* Self-scheduling / peering (minden CPU ütemez)
* Globális futásra kész sor
* Processzoronkénti futásra kész sor
** Push alapú: OS kernel folyamat mozgatja a sorok között a feladatokat.
** Pull alapú: Az idle állapotban (idle feladatot végrehajtó) CPU próbál a többi sorából feladatot kapni.
* Kettő kombinációja
** Összefüggő, párhuzamosan futtatható feladatok optimalizálása (pl. Gang scheduler)
</div>

===Virtualizáció===

====Hardveres virtualizáció: Mit jelent az, ha egy x86-os processzor hardveres virtualizáció támogatással rendelkezik?====
<div class="answer">
A CPU utasításkészletének és üzemmódjainak olyan kiegészítése, amely lehetővé teszi a vendég operációs
rendszer kódjának módosítás nélküli futtatását. [?]

(Speciális utasításokkal látják el a processzort, amit szoftveresen akár több 100 utasításon keresztül lehetne csak megoldani. ROSSZ(MZ))

Elrejti a gep fizikai tulajdonsagait a felhasznalok elol.

Miert erdemes virtualizalni?

-Lehet futtatni a gazda OS el nem kompatibilis alkalmazast.

-Lehet biztonsaggal rendszergazda jogot adni mindennek, mert ugy se tud a gazda os-be kart tenni.

-Konnyen at lehet masolni a virtualis gepet egy masik gepre.
</div>

====Hosted vs. bare-metal: Miben különbözik egy hosted egy bare-metal típusú virtualizációs megoldástól?====
<div class="answer">
Bare-metal esetén a VMM kezeli a HW erőforrásokat, míg hosted típusú esetén ezt a host OS végzi.

videó:
http://video.bme.hu/media/video/Operacios_Rendszerek_20ea_20110418.wmv
00:16:45 körül

Kétféle megközelítés:

# Hosted: az operációs rendszerre telepítek egy virtualizációs szoftvert, ez beépül az operációs rendszerbe tipikusan kernel modulként, innentől a virtualizációs szoftver teszi lehetővé, hogy virtuális gépeket futtassak. Tipikusan a desktop megoldások (VMware Player, VirtualBox, Virtual PC, stb.)
# Bare-metal: a virtualizációs szoftver valós OS-szerű funkciókat valósít meg. Lényegében egy minimális funkciókészlettel rendelkező OS. A hardvert nem egy általános célú operációs rendszer kezeli, hanem a virtualizációs szoftver feladata az, hogy a hardver-erőforrásokkal gazdálkodjon, ő dönt az ütemezésről, ő dönt a memória-hozzáférésekről. Tipikusan szokott hozzá tartozni egy menedzsment operációs rendszer, egy menedzsment konzol, ami a távoli hozzáférést, virtuális gépek elindítását lehetővé teszi, és ott is ott tudom futtatni a vendég operációs rendszereket. Tipikusan szervermegoldások (VMware ESX Server, Xen Enterprise, MS Hyper-V).

Fontos különbség: ki dönt a CPU-erőforrásról?
# van az OS-nek egy ütemezője, ő dönt arról, mikor, ki kapja meg a CPU-t. Dönthet úgy, hogy az időszeletet az alkalmazás kapja meg, a köv. időszeletet a virtualizációs szoftver/modul, ő magán belül pedig eldöntheti, melyik virtuális gépnek osztja a processzort, de alapvetően a host OS dönt arról, mi dönt az erőforrásról.
# arról, hogy ki kapja a CPU-t, a közvetlenül a hardver réteg felett lévő virtualizációs szoftver dönti el. Dönthet úgy, hogy a menedzsment OS kapja, dönthet úgy, hogy valamelyik virtuális gép kapja meg.

</div>

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
<div class="answer">
Módosítjuk a vendég OS forráskódját, hogy ne is akarjon "problémás" utasításokat hívni, hanem azok helyett azoknak megfelelő függvényeket hívjon a hypervisorban. (Ezzel egyszerűsödik a hypervisor implementálása, viszont csak úgy működik a módszer, ha módosítják a vendég OS forrását.)
</div>

====Trap-and-emulate: Trap & emulate virtualizációs módszer használata esetén mi történik a vendég gép által kiadott nem privilegizált utasítással?====
<div class="answer">
* nem privilegizált utasítások közvetlenül a valós CPU-n hajtódnak végre (no VMM intervention)
</div>

===UNIX===

====Adminisztratív adatok: hol helyezzük el azokat az adminisztratív adatokat, amelyekre mindig szükség van, akkor is, ha a folyamatnak egyetlen lapja sincs a memóriában?====
<div class="answer">
A proc struktúrában.
</div>

====Adminisztratív adatok: UNIX-ban a folyamatokkal kapcsolatos adminisztratív adatok hogyan épülnek fel?====
<div class="answer">
TODO: rövidíteni.

# adatok, melyek elsősorban akkor szükségesek, amikor a folyamat ténylegesen fut - bent van egy v. több lapja a memóriában, éppen ezekkel kapcsolatos utasításokat hajtunk végre. >> az u-területen található kontextusadatok. A folyamat címtér része. A folyamat nem férhet hozzá, de a folyamat saját címterében találhatók. Amikor a folyamatnak egyetlen lapja sincs a memóriában, hanem minden a háttértáron található, a folyamat nem fut, akkor az itt található adatokhoz a kernel sem tud hozzáférni, mivel ide csak azok az adatok kerülnek, melyek a folyamat futásakor kellenek! Pl. hozzáférés-szabályozási adatok: a folyamat szeretne valamilyen tevékenységet végrehajtani, szabad-e neki vagy sem? Másik példa: rendszerhívások állapotai: végrehajt egy rendszerhívást, amiben éppen tartózkodik, ezzel kapcsolatos állapotadatok, stb. Vagy: nyitott fájl adatok, fájlkezeléssel kapcsolatos adatok. UNIX-ban a fájlkezelést nagyon általánosan kell érteni. Minden, ami a fájlrendszer-interfészen keresztül zajlik, ahhoz tartozik egy nyitott fájl objektum, ami ennek adminisztrálására szolgál, ezek is az u-területen találhatók. Ezenkívül: számlázási, statisztikai adatok.

# adatok, melyek elsősorban a folyamatok kezeléséhez szükségesek (amire a kernelnek bármikor szüksége lehet). Pl. folyamat alapvető azonosító adatai. Folyamat PID-je, szülőazonosító, stb. Folyamat ütemezésével kapcsolatos adatok, mi a folyamat aktuális futási állapota, mennyi a prioritása, prioritás kiszámolásához szükséges adatai, stb. Memóriakezelési adatok: folyamat memórialapjai bent vannak a memóriában, vagy épp kint vannak a háttértáron. Az u-terület címe, stb. >>> proc struktúra adatai: a process tábla egy eleme (ez a klasszikus rendszereknél ténylegesen egy tábla volt, ma bonyolultabb, pl. láncolt listás megvalósítás). A kernel címterének része. A kernel bármikor elérheti őket.
</div>

====Adminisztratív adatok: Milyen adatstruktúrá(k)ban és milyen címter(ek)ben található(k) a folyamatok adminisztratív adata(i)?====
<div class="answer">
A folyamat futása során szükséges adatok az u-területen, mely a folyamat címterének része, illetve a folyamatok kezeléséhez szükséges adatok a proc struktúrában, mely a kernel címtér része.
</div>

====Adminisztratív adatok: Sorolja fel a UNIX folyamatok legalább 4 alapvető adminisztratív adatát!====
<div class="answer">
* PID (Process ID): egyedi, a folyamatot azonosító szám (PPID: szülő folyamat azonosítója)
* A folyamat állapota (fut, alszik, stb.; ütemezési információk (prioritás, CPU használat, nice érték) )
* Hitelesítők (UID, GID: a kapcsolódó felhasználó adatai)
* Memória-kezelési adatok (címleképezési térkép)
* Kommunikációs adatok (fájlleírók, jelzés információk)
* Statisztikák (erőforrás használat (számlázáshoz) )
</div>

====Alvási prioritás: UNIX alvási prioritásának ütemezését mi végzi?====
<div class="answer">
Az alvási prioritást is az ütemező határozza meg, az alapján, hogy mire várakozik a folyamat, vagyis miért hajtott végre sleep() rendszerhívást. Kernel módban az ütemező nem veheti el a futási jogot, ezért amíg nem hajt végre sleep() hívást, addig nincs is szükség a prioritásának meghatározására.
</div>

====Android: Az Androidban mikor és miért (adjon jellegzetes példát) terminálható egy alkalmazás?====
<div class="answer">
Az alkalmazás erőforráshiány miatt bármikor terminálható, ezt az operációs rendszer automatikusan meg is teszi. Példa: ha nincs elég memória.
</div>

====Belső szerkezeti elemek: Sorolja fel a UNIX operációs rendszer főbb belső szerkezeti elemeit!====
<div class="answer">
* betöltő
* virtuálismemória-kezelő
* állományrendszer
* blokkos berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: lemezegység, szalagos meghajtó)
* karakteres berendezés-meghajtó kapcsoló (+ a hozzá kapcsolódó eszközmeghajtók, pl.: hálózat, nyomtató)
</div>

====Csővezeték (pipe): Írjon le egy olyan konkrét UNIX shell parancssort, amely csővezetéket alkalmaz!====
<div class="answer">
ls -la | more
</div>

====exec(): Mire szolgál a UNIX exec() rendszerhívás?====
<div class="answer">
exec(): új programkód betöltése egy folyamat címterébe
Azaz a fork() paranccsal létrehozunk egy új folyamatot, exec() paranccsal pedig betöltjük a folyamatba a kódot.
</div>

====Fájl-attribútumok: Sorolja fel a fontosabb UNIX fájl-attribútumokat!====
<div class="answer">
* Típus
* Linkek
* Eszköz, inode, méret...
* Időbélyegek
* Azonosítási és hozzáférés-szabályozási adatok
</div>

====Fájlrendszeri bejegyzések: Sorolja fel a UNIX fájlrendszeri bejegyzések alapvető tulajdonságait (legalább hármat, ls -l oszlopok)!====
<div class="answer">
* pl.: drwxr-xr-x 2 root root 4096 dec 22 12.27 txt
* sorrendben: I. UNIX-fájltípusok (pl. közönséges fájl (-), katalógus (d), szimbolikus link (l), stb.), II. hozzáférési jogosultságok (3*3-as bontásban - 1. hármas csoport a tulajdonos, a 2. a csoport, a 3. a többiek jogosultságait; 'r' az olvasás (read), a 'w' az írás (write), az 'x' pedig a végrehajtás (execute) jele), III. jogosultságok után egy szám áll (ez könyvtárak esetén azt mondja meg, hogy az adott könyvtár hány elemet tartalmaz, fájlok esetén azt tudhatjuk meg, hogy az adott fájlra hány hardlink mutat), IV. tulajdonos, V. méret (bájtokban), VI. utolsó módosítás dátuma, VII. fájl neve
</div>

====Felfüggesztett állapotok: Mik azok a felfüggesztett állapotok, mi a szerepük a UNIX-ban?====
<div class="answer">
felfüggesztve futásra kész, felfüggesztve alszik állapot A UNIX-ban egyfajta hosszú távú, felhasználói ütemezést jelentenek - a felhasználónak lehetősége van arra, hogy bizonyos folyamatokat a többi állapotból kiemeljen. Pl. Ctrl+Z billentyűkombinációval felfüggesztem a folyamatok futását. Innen valamikor visszahelyezzük futó állapotba.
</div>

====Felhasználói mód, kernel kontextus: UNIX esetén milyen tevékenység zajlik felhasználói módban, kernel kontextusban?====
<div class="answer">
Semmilyen!!
Megj.: Kernel kontextusban, felhasználói módban a program saját utasításait hajtjuk végre, a program saját adataival dolgozunk. Ennél fogva itt nincs értelme beszélni semmiről, mert a folyamat a kernel kontextusában nem hajthat végre semmit.
</div>

====Felhasználói módból kernel módba váltás: Hogyan vált egy UNIX folyamat felhasználói (user) módból kernel módba?====
<div class="answer">
Rendszerhívásokon keresztül.
</div>

====Felhasználói módú prioritás: Sorolja fel milyen tényezők határozzák meg egy UNIX folyamat felhasználói módú prioritását (tradicionális UNIX ütemező esetén)!====
<div class="answer">
* Korábbi CPU-használat
* Futásra kész folyamatok száma (p_cpu "öregítésével")
* nice érték (nice és renice parancsok)
</div>

====Folyamatok állapotai: Milyen állapotai vannak a UNIX-folyamatoknak?====
<div class="answer">
# kiinduló állapot
# futásra kész
# kernel módban futó állapot
# felhasználói módban futó állapot
# alvó állapot
# zombi állapot
# felfüggesztve alszik
# felfüggesztve futásra kész

Ctrl+Z-vel felfüggesztett állapotba helyezem a folyamatot.
</div>

====Folyamatok közötti kommunikáció: Soroljon fel legalább 4 UNIX folyamatok között kommunikációs megoldást!====
<div class="answer">
* System V IPC: szemafor, osztott memória, üzenetsor
* Csővezeték és nevesített csővezeték
* Jelzések
* RPC
* Folyamat-nyomkövetés
* Szemaforok
* Üzenetsorok
* Osztott memória
* Hálózati, socketeken keresztüli kommunikáció
</div>

====Folyamatok közötti kommunikáció: Soroljon fel UNIX folyamatok közötti adatátviteli eszközöket (legalább hármat)!====
<div class="answer">
* System V IPC: - szemaforok, - üzenetsorok, - osztott memória
* Jelzések: - aszinkron események keltése és kezelése
* Csővezetékek, nevesített csővezetékek: - FIFO kommunikáció a "rokonságban"
* Szemaforok: - a korábban megismert szinkronizációs megoldások
* Üzenetsorok: - diszkrét, típusos üzenetek folyamatok között
* Osztott memória: - azonos fizikai memóriaterület használata több folyamatban
* "hálózati" (socket) kommunikáció: - címzéssel és protokollokkal támogatott kommunikáció
* TODO
</div>

====fork(): Mire szolgál a fork() rendszerhívás?====
TODO: rövidíteni.

Új folyamat létrehozására. A fork() hívásakor az aktuális folyamat, amely kiadta a rendszerhívást, megduplázódik (minden adata, verme, memórialapja, stb.), onnantól két példányban fog továbbélni, amelyek egymással szinte tökéletesen megegyeznek, kvázi klónozva van a folyamat, néhány apró különbség van csupán. De valójában a memóriaszervezés ügyes trükkje: semmit nem csinál azonkívül, hogy bizonyos adminisztratív adatokat megdupláz, ténylegesen nem másol semmit (memórialapokat)! Az így megduplázott folyamat memórialapjaihoz hozzárendel még egy folyamatot, és megjegyzi azt, hogy amíg ezek a folyamatok békésen tudnak egymás mellett dolgozni, addig dolgozzanak ugyanazon, de ha konfliktus van, akkor majd lemásoljuk ezeket a memórialapokat.

Ha a fork() hívás 0-val tér vissza: a gyerek folyamat kódja fut tovább. Ha egy negatív számmal tér vissza, fork() hiba történt, nem tudtuk létrehozni az új folyamatot, le kell kezelni. Ha pozitív számot adott vissza, akkor az eredményben a gyerekfolyamat azonosítója található, itt a szülőfolyamat fut tovább.

Gyerek folyamat fut: az exec() az aktuális folyamat helyére betölt egy másik binárist. Az exec()-et meghívó folyamatnak az exec() kitörli a saját kontextusát, stb., betölt egy új programkódot, amit elkezd végrehajtani. (Kvázi mintha elindítana egy új folyamatot, de a folyamat már fut.) Ha nem sikerült betölteni a binárist (pl. nincs ilyen fájl), akkor hiba, visszatér az exec() is, egyébként nem: az új programkód utasításait hajtjuk végre.
Tehát folyamat létrehozása UNIX-ban két lépésben:
# fork() rendszerhívás = folyamatduplázás, majd
# a gyerekfolyamat helyére az új programkód betöltése exec() hívással.
Modern UNIX-okban fork() már nem igazán (más rendszerhívásokat használ).

====fork(): Miért van szükség a fork() rendszerhívásnál a folyamat megduplázására?====
<div class="answer">
TODO
</div>

====Futási/végrehajtási mód: Mi az a futási mód?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv, 00:17:00 környéke alapján
TODO - rövidíteni
A folyamatok a kerneltől teljesen különválasztva működnek (rendszerhívás interfészen keresztül kommunikálnak a kernellel). A végrehajtási mód azt határozza meg, hogy a kernel vagy a folyamat feladatait hajtja végre az OS.
Két mód: kernel ("privilegizált, védett") mód, valamint felhasználói ("szabad") mód.
Kernel módban a védett (kernel) tevékenységeket, felhasználói módban a folyamat programkódját hajtja végre az OS.
Példa: egy webböngésző a tevékenysége egy részében a saját feladatát hajtja végre, pl. HTML-kódot értelmez és jelenít meg, valamint vannak olyan tevékenységek, amelyek ahhoz kellenek, hogy ezt a feladatát végrehajtsa: hálózati kommunikáció, fájlrendszer-műveletek, stb. - ezek kernel tevékenységek.
Kernel módban privilegizált utasítások hajtódnak végre, pl. egy eszközt kezelünk, vagy hozzányúlunk a háttértárhoz, onnan valamit beolvasunk, oda valamit kiírunk. Ilyen utasításokat egy felhasználói módban futó folyamat nem hajthat végre, hiszen ha közvetlenül hozzáférne a hardverekhez, akkor akár adott esetben a teljes rendszer működését felboríthatná.
Felhasználói módból kernel módba átlépéskor átlépünk egy védett módba, így olyan feladatokat is végrehajthatunk, amit egyébként tilos.
</div>

====inode: Mi a UNIX inode?====
<div class="answer">
* A fizikai állományokhoz tartozó leíró, azonosító
* minden file-hoz tartozik egy inode állomány amiben a file minden tulajdonsága megtalálható (azonosító,leíró)
</div>

====Kernel mód, folyamat kontextus: Milyen tevékenység zajlik kernel módban, folyamat kontextusban?====
<div class="answer">
Kivételek, rendszerhívások kezelése, rendszerhívások végrehajtása.
Amikor a folyamat végrehajt egy rendszerhívást, a felhasználói módból átlép kernel módba, hiszen a rendszerhívás belsejében olyan tevékenységeket szeretne végrehajtani (beolvasni vmit egy fizikai eszközről, hálózatról, más folyamattal kommunikálni, elindítani másik folyamatot, stb.), amelyhez kernel utasítások végrehajtása tartozik.
</div>

====Kernel mód, kernel kontextus: Milyen tevékenység zajlik kernel módban, kernel kontextusban?====
<div class="answer">
Rendszerfeladatok, megszakítások kezelése. Kernelfolyamatok.
</div>

====Kernel módú prioritás: Mi határozza meg a UNIX folyamatok kernel módú prioritását a tradicionális UNIX ütemezésben?====
<div class="answer">
A kernel módban futó folyamat prioritása statikus, nem függ attól, hogy a folyamat mennyit használta a CPUt, vagyis mennyi ideig futott. A prioritás attól függ, hogy a folyamat milyen ok miatt hajtott végre sleep rendszerhívást, vagyis, hogy milyen eseményre várakozik. Emiatt a kernel prioritást szokták alvási prioritásnak is nevezni.
</div>

====Kernelszolgáltatások elérése: Milyen interfészen keresztül érhetők el a UNIX kernel szolgáltatásai?====
<div class="answer">
* System Call Interface
* Az alkalmazások a rendszerkönyvtárakat hívják meg, amelyek szükség szerint meghívják az operációs rendszer szolgáltatásait ??
</div>

====Kontextus: Mi az a kontextus?====
<div class="answer">
http://video.bme.hu/media/video/Operacios_Rendszerek_09ea_20110307.wmv alapján.
TODO: rövidíteni.
Az a környezet, amiben végrehajtjuk az utasításokat. Ez is különbözik a kernelek és folyamatok esetén: folyamat kontextusban azokkal az adatokkal és utasításokkal dolgozunk, amelyek alapvetően a folyamat célját szolgálják, kernel (rendszer vagy megszakítás) kontextusban pedig kernel feladatokat hajtunk végre, és az ezekhez a feladatokhoz szükséges adatokkal dolgozunk.
Kernel kontextus: érkezik egy hardveres megszakítás, ennek kezelése itt zajlik.
Folyamat kontextus: a folyamattal kapcsolatban hajtunk végre tevékenységeket.
Nem uaz, mint a végrehajtási mód, mert lehetséges az, hogy bizonyos tevékenységeket kernel módban hajtunk végre, de folyamat kontextusban. Amikor hozzá kell férnünk egy folyamat futási adataihoz, veremhez, virtuális memóriájához, stb., a programnak az adminisztratív adatait kezeljük, ezek folyamat kontextusban találhatóak.
</div>

====Környezeti adatok: Mik azok a környezeti adatok egy UNIX-folyamatnál?====
<div class="answer">
A folyamat indításakor megörökölt tulajdonságok. Tulajdonság-érték párok. Pl. a felhasználó bejelentkezik; mi az ő neve. A felhasználó milyen terminált használ, annak milyen képességei vannak. Mi a felhasználó shellje. Az épp futó folyamat néhány tulajdonsága. Olyan tulajdonság, amely egyes folyamatok számára értéket jelentenek. A felhasználók ezeket a set, setenv, export parancsokkal tudják ezeket állítani (és le is kérdezhetik őket). Megörökli az őt elindító folyamat környezetét (hogy melyiket kell épp használni, UNIX-variánstól függ). Amikor a felhasználó bejelentkezik, akkor a környezeti változók beállítódnak, a folyamatok induláskor ezeket a beállításokat megöröklik.
</div>

====libc: A libc-nek mi a feladata rendszerhívások kezelésében?====
<div class="answer">
A felhasználói mód és kernel mód közötti átmenet lebonyolítása.
A folyamat csak meghív egy open(), read(), write(), stb. függvényt, valójában a háttérben bonyolultabb tevékenység zajlik >> meghív egy rendszerhívást a rendszerhívás interfészen keresztül. A rendszerkönyvtárak egyike a libc, a standard C library, ez felel azért, hogy az adott függvényhívásokat (mint a read()) leképezze arra a mechanizmusra, amin keresztül átlépünk kernel módba.
Az implementáció belsejében van egy SYSCALL utasítás (ez hardverfüggő), ez ténylegesen elvégzi az üzemmódváltást egy speciális megszakítás generálásával, aminek eredményeként a CPU átlép védett módba. A kernel pedig kezeli ezt a megszakítást. Ekkor a kernel a CPU regisztereit elmenti, azért, hogy a folyamat futása visszaállhasson a megfelelő állapotba. A feladat végeztével a kernel visszatér a megszakításból (erre is hardverfüggő a megvalósítás), a CPU visszavált felhasználói módba, a libc pedig visszatér a függvényhívásból, amit a folyamat kiadott.
</div>

====/proc: Mi a /proc?====
<div class="answer">
Speciális fájlrendszer-interfész a kernel-adatstruktúrákhoz való hozzáféréshez.
</div>

====Prioritás: Hogyan számítható ki egy kernel módban futó UNIX folyamat prioritása?====
<div class="answer">
* a prioritást a folyamat elalvásának oka határozza meg, tehát a prioritás attól függ, milyen sleep utasítással ment át alvó állapotba
* alvási prioritás pl: 20 - diszk I/O-ra vár; 28 - inputra vár a karakteres terminálról
* kernel módú folyamatoknak (amelyek rendszerhívásokat intéznek) negatív prioritásértékeik vannak, ezeknek van a legmagasabb prioritása ........... (http://home.mit.bme.hu/~meszaros/edu/oprendszerek/segedlet/unix/2_folyamatok_es_utemezes/unix_processes.pdf)
* Több szinten, több időléptékben zajlik. Óraütésenként a prioritási sorok ellenőrzése. 10 óraütésenként RR ütemezés egy soron belül. 100 óraütésenként a prioritások újraszámítása.
</div>

====Rendszerhívások: Igaz-e, hogy a rendszerhívások megszakítással járnak együtt?====
<div class="answer">
Igen, ennek hatására vált védelmi szintet a processzor.
</div>

====Rendszerhívások kontextusa: Milyen kontextusban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
folyamat kontextusban
</div>

====Rendszerhívások módja: Milyen módban hajtódnak végre a UNIX rendszerhívások?====
<div class="answer">
kernel módban
</div>

====Rendszerhívások módja, kontextusa: Milyen futási módban és kontextusban zajlik a UNIX rendszerhívások kiszolgálása?====
<div class="answer">
Kernel módban fut a kód, és a rendszert hívó folyamat kontextusában. ((az ehhez tartozó ábra jobb felső része))
</div>

====Rendszerhívások programindításkor: UNIX alatt milyen rendszerhívásokra van szükség, ha a felhasználó elindít egy programot (folyamat létrehozása és programkód betöltése)?====
<div class="answer">
* Folyamatot létrehozni a fork() hívással, majd a programkódot betölteni az exec() hívással lehet.
</div>

====rpcgen: Mi az rpcgen program feladata?====
<div class="answer">
* RPC nyelven készült leírásból C programkódot generál. [?]

* Az RPC nyelv alkalmas a szerver interfészének formális leírására. A formális leírásból az rpcgen program képes a szerver és a kliens programok megfelelő részeit, valamint a szükséges XDR konverziós függvényeket elkészíteni C nyelven. Az így kapott C forráskódú modulokat a kliens és szerver alkalmazással kibővítve kapjuk a teljes kommunikáló rendszert.
* XDR (Extended Data Representation, kiterjesztett adatreprezentáció): Többféle egyszerű adattípust definiál, illetve szabályokat határoz meg bonyolultabb adatstruktúrák létrehozására. Az adatstruktúrák meghatározásán kívül az XDR egy formális nyelvet is bevezet az adatok leírására. Az RPC rendszer is ezen nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
* RPC (remote procedure call, távoli eljáráshívás): Az RPC-rendszer egy protokoll-leírást és egy programozói interfészt tartalmaz. Az XDR által definiált formális nyelv kiterjesztését használja a távoli eljáráshívás formális leírására.
</div>

====System V IPC: Sorolja fel a UNIX System V IPC elemek közös alapjának részeit!====
<div class="answer">
Minden IPC erőforrás rendelkezik a következő azonosítókkal: kulcs (key), létrehozó (creator), tulajdonos (owner), hozzáférési jogok (permissions)
</div>
====System V: Adja meg a System V üzenetsorok főbb jellemzőit (tömör felsorolást kérünk)!====
<div class="answer">
* diszkrét, tipizált üzenetek
* nincs címzés, üzenetszórás
</div>

====System V: Miért tud az s5fs (System V File System) gyorsabban írni, mint olvasni (az előadás példája alapján)?====
<div class="answer">
* az írás gyors, főleg kis fájlok esetén (több szintű leképzés a kisebb blokkkok miatt), az olvasás azért lassabb (csak a nagy fájlokra), mert azoknak a részeit össze kell vadászni a szétszórtság miatt
* TODO
</div>

====u-terület: milyen jellegű adminisztratív adatok vannak az u-területen?====
<div class="answer">
Azok az adatok, melyek a folyamatok futásakor kellenek. Több infó: lásd adminisztratív adatoknál.
</div>

====UNIX-fajták: Soroljon fel fő UNIX-fajtákat!====
<div class="answer">
Linux, Solaris, BSD, System V, HP/UX, ...
</div>

====UNIX-szabványok: Soroljon fel UNIX-hoz köthető szabványokat (legalább kettőt)!====
<div class="answer">
* POSIX.1 (teljes nevén: POSIX1003.1): C nyelvű szabványos rendszerhívás-interfész
* System V Interface Definition
* X/Open Portability Guide
* - AT&T SVID (pl. SVR4), - IEEE POSIX, - Open Group X/Open, Unix95, Unix98, ... ????
* http://linux.die.net/man/7/standards
</div>

====UNIX-típusok: Soroljon fel UNIX típusokat (a családfa jellemző ágait)!====
<div class="answer">
* System V (AT&T változat; Solaris, SCO),
* BSD (Berkeley változat; SunOS, OpenBSD)
</div>

====Ütemezés: Adja meg a tradicionális UNIX ütemező három legjellemzőbb tulajdonságát!====
<div class="answer">
* preemptív, prioritásos és időosztásos
(Néhány kiegészítés a UNIX-ütemezőhöz:
* nem preemptív kernel módban (a kernel módot végrehajtó folyamatot (pl. rendszerhívás, megszakítás-kezelés) nem lehet kényszeríteni, hogy a CPU használatáról lemondjon egy nagyobb prioritású folyamat javára)
* újraütemezés csak akkor következik be, ha egy folyamat önként lemond a CPU-ról és sleep rendszerhívást hajt végre, vagy a folyamat kernel módból visszatér user módba Nem méretezhető megfelelően. Az algoritmus nem képes rugalmasan alkalmazkodni a folyamatok számának növekedése esetén. A korrekciós faktor nem elég hatékony eszköz.
* A CPU-t adott esetben nem lehet "kiosztani" adott folyamat számára. Nem garantálható fix válaszidő. Nagy rendszerterhelés esetén a válaszidő megnőhet. A UNIX ütemezés épp ezért nem alkalmazható real-time rendszerekben.
* A kernel nem preemptív, ezért az egész rendszert feltarthatja. A felhasználó nem tudja megfelelő módon befolyásolni folyamatai prioritását - a nice szám nem megfelelő eszköz erre a célra.)

</div>

====vfs: Mondjon legalább egy, UNIX VFS-alapú "fájlrendszert", amelynek a célja nem fájlok tárolása!====
<div class="answer">
/dev, /proc, stb.
</div>

====vfs: Soroljon fel UNIX VFS-alapú fájlrendszereket (legalább négyet)!====
<div class="answer">
xfs, zfs, brtfs, nfs
</div>

====Virtuális rendszerhívás: Mi az a virtuális rendszerhívás, miért van rá szükség?====
<div class="answer">
(Klasszikus UNIX-ban nincs, Linux 2.5.x-től felfelé, mai Linux kernelek aktívan használják.)
Vannak bizonyos egyszerű feladatok, amelyek a feladat egyszerűsége ellenére túl sok felesleges művelettel járnak: rendszerhívás intterrupt, kontextusváltás, stb., ezen a helyzeten szeretnénk javítani - próbáljuk lerövidíteni ezt az utat.
Pl. a pontos idő lekérdezése csupán egy megfelelő hardver kiolvasása (egyszerű numerikus érték), mégis sok művelettel jár: gettimeofday(): libc > SYSCALL > kontextusváltás > ..., majd ugyanezen a lépcsőn visszasétálunk a felhasználói folyamatba.
Persze nem mindig lehet leegyszerűsíteni ezt az utat, csak egyszerűbb és biztonságos esetekben, pl. ha egyszerű numerikus értékek, azonosítók kiolvasásáról van szó: pl. folyamatnak mi az azonosítója, processzor lekérdezése, pontos idő lekérdezése...Tehát a felhasználói módból kernel módba történő hosszas váltást szeretnénk elkerülni. Ha nincs ilyen módváltás, akkor a felhasználói címtérben elérünk egyes kernelterületeket > így tényleg egyszerű függvényhívás lesz. Megfelelő előfeltételekkel: csak kockázatmentes feladatokra. Időlekérdezés tipikusan ilyen, ott megtehetjük.A felhasználói címtérben az a tevékenység, amelyet szeretnénk végrehajtani, elérhető legyen. Ezt oldják meg a virtuális rendszerhívások!
A folyamat címterébe a kernel rendszerinduláskor speciális "kernellapot" allokál - ezen a biztonságosnak tekinthető rendszerhívások vannak. Terminálból példa: ldd /bin/bash
</div>

====vnode/vfs: Mi a UNIX vnode/vfs?====
<div class="answer">
* Implementáció-független fájlrendszer absztrakció
* vnode: virtuális csomópont, vfs: virtuális állományrendszer
* inode --> vnode
* fs --> vfs
* Új absztrakció: annak felismerése, hogy több állományrendszernek számos előnye van, szükségessé vette a virtuális csomópont (vnode) és a virtuális állományrendszer (vfs) leíró adatszerkezetek bevezetését. Követelmények, elvárások az állományrendszerrel kapcsolatban:
** egyszerre támogasson több - UNIX, nem UNIX - állományrendszert
** különböző diszk partíciók különböző állományrendszereket is tartalmazhatnak, de mountolás esetén egységet képet kell, hogy mutassanak
** támogassa a hálózati állományok osztott használatát
** modulárisan bővíthető legyen.
</div>

====Zombi állapot: Mi a zombi állapot szerepe egy UNIX rendszerben?====
<div class="answer">
A folyamat már felszabadította a foglalt memóriát, lezárta az állományokat, minden erőforrását visszaadta a rendszernek, csak a proc struktúráját tartja fogva, amiben visszatérési és statisztikai információt tárol a szülő számára. A folyamat szülő wait hívása után szűnik meg.

Megjegyzés: bővebben magyarázattal, előadás alapján:
A folyamat megáll, a UNIX-ban a kernel szeretné ezt a szülőjének is tudomására hozni.
A folyamat már leállt, nem fog tovább futni, de a szülőjét még nem értesítették arról, hogy ez a folyamat megszűnt, esetleg gondoskodjon az újraindításáról, stb.
Pl. egy webszerver: beérkező kérések kiszolgálása --> kliens folyamat indítása, ez megkapja a kérés kiszolgálásának feladatát, a kliens pedig valamikor megáll, a webszerver nem árt, ha értesül róla, hogy hiba vagy normál működés folytán állt le.
Tehát amíg a szülő nem értesült a leállásról, a folyamat zombi állapotban marad. Ha a szülőt nem érdekli, mi történt a gyerekfolyamattal, a zombi állapot hamar megszűnik.
A zombi állapotban a folyamatnak semmilyen saját adatát nem tároljuk, a folyamat összes működéshez szükséges adata megszűnik, kizárólag a kernel adatstruktúrákban, tehát a proc struktúrában marad meg a folyamatnak néhány adminisztratív adata. A ps kilistázhat pl. zombi állapotban lévő feladatokat, mert ezeknet a folyamatoknak az adminisztratív adatai a kernel címterében még megtalálhatóak. De a folyamatok saját címtere, u-terület, stb. már nem létezik. Miután a szülő értesült róla, hogy a gyerekfolyamat meghalt, a kernel törölni fogja a folyamatot a process táblából is, a folyamat kilép a zombi állapotból.
</div>

====Zombi állapot: Igaz-e az, hogy egy zombi állapotban lévő folyamat még memóriaterületet foglal?====
<div class="answer">
Igen, mert a kernel processz táblában még ott vannak az adatai, és az memóriaterületet foglal. (A NEM választ is meg lehet indokolni...) [Indoklás nélkül 0 pont!!!]
</div>

===Windows===

====Alrendszer: Melyik az az alrendszere a Windowsnak, ami nélkül nem tud futni?====
<div class="answer">
A Windows alrendszer, avagy Client/Server Runtime [[SubSystem]] (csrss.exe). Ennek kilövése kékhalált eredményez.
</div>

====API-k: Hogyan oldották meg, hogy az alkalmazások többféle API-n (Win32, POSIX) keresztül is meg tudják hívni a Windows operációs rendszer funkcióit?====
<div class="answer">
* Megoldás: környezeti alrendszerek (environment subsystems): a felhasználónak vagy programozónak nyújtott környezet, személyiség egy részét a környezeti alrendszer folyamatok valósítják meg, minden egyes környezet külön API-t mutat (Windows, POSIX, ...), az operációs rendszer rendszerhívásainak egy részét kínálja a felhasználói alkalmazások számára. (Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx)
* a kernelnek egy definiált interfésze van, ami nem publikus (hivatalos dokumentációja nincsen): NT API >> az ebben lévő függvényeket a fejlesztő ne hívhassa meg közvetlenül. Ehelyett erre két alrendszer épül, ők mutatnak egy API-t az alkalmazások felé: Windows API és POSIX API. (ezek teljesen dokumentáltak!). Az alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni.
* A két alrendszer feladata az, hogy az általuk definiált hívásokat átfordítsák.
* Nem pusztán szintaktikai, hanem szemantikai eltérések is vannak.

(Megjegyzés: Exetype segédeszköz segítségével megnézhető, melyik alrendszert használja egy adott alkalmazás.)

Forrás: http://video.bme.hu/media/video/Operacios_Rendszerek_04ea_20110215.wmv (00:28:29 körül)

(Korábbi:
* Alkalmazás 1>>>Windows API (Windows alrendszer)>>>NT API (NT Kernel)<<<Posix API (Posix alrendszer)<<<Alkalmazás 2 TODO(ehelyett 1 épkézláb mondat kéne)
* alkalmazások viszont nem keverhetik az alrendszereket, mindegyik csak egyet használhat; ezt linkeléskor kell eldönteni
)

</div>

====Executive réteg: Executive (Windows)====
<div class="answer">
Az operációs rendszer magasabb szintű funkcióit szolgáltató rétege (memóriakezelés, biztonság, stb.). Az adatokat objektumokban tárolja, melyeket leírókkal (handle) lehet csak elérni, jól definiált interfészeken keresztül. Bár a kernel funkcióit csak a kernel interfészén keresztül éri el, szintén az ntoskrnl.exe tartalmazza. A legtöbb rendszerhívás itt van megvalósítva.
Forrás: http://mit.bme.hu/~micskeiz/opre/files/00-opre-windows-bevezeto.pptx

(Korábbi: Ez a réteg tartalmazza az NTDLL.DLL által definiált függvények hívásainak megvalósítását, valamint a rendszer külső objektumai közti kommunikáció. Legfontosabb szolgáltató funkciója a lokális eljárás hívás - LPC (Local Procedure Call) megvalósítása. TODO[MZ])
</div>

====Fájlhozzáférések: Mivel azonosítja a Windows a felhasználókat és csoportokat a fájlhozzáférési listákban?====
<div class="answer">
* objektum (SecurableObject) → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* SecurityDescriptor (biztonsági leíró, összefogja a többi elemet) >> Owner (Tulajdonos, megváltoztathatja az objektum engedélyeit, akkor is ha nincs explicit joga), Discretionary Access Control List (DACL, belátás szerinti, erőforrás szintű, hozzáférési lista - hozzáférés szabályozása), SACL (biztonsági naplózás szabályozása - kinek milyen művelete esetén kell naplózni az adott műveletet)
* AccessControlEntry:
** Típus: megengedő, tiltó, audit
** Flag: Pl. öröklődés
** SID: kire vonatkozik
** Maszk: végrehajtás | törlés tulajdonos írása...
* elérési lista (ACL), melyben megadható, hogy mely folyamatok jogosultak az adott section object elérésére ???
* minden objektumhoz tároljuk a hozzá tartozó <tartomány, műveletvégzési jog> párokat ????
* TODO - bőven elég annyi, hogy Security Identifier (SID) segítségével azonosítja
</div>

====Felhasználó- és csoportazonosító: Mi alapján azonosítja a Windows a felhasználókat és a csoportokat?====

====Paravirtualizáció: Mit jelent az, hogy egy virtualizációs megoldás paravirtualizációt használ a CPU virtualizálásához?====
felhasználókat és a csoportokat?
<div class="answer">
SID - Security Identifier
</div>

====Felhasználó- és csoportazonosító: Mivel azonosítja a Windows a felhasználókat és csoportokat a hozzáférések ellenőrzése során?====
<div class="answer">
* <Gép SID>-<RID> (SID security identifier - gépspecifikus, RID: relative identifier)
* Jól ismert SID-ek: Everyone: S-1-1-0, Administrator: S-1-5-domain-500
* Vista: szolgáltatások is kapnak SID-et
* objektum → (SID, engedélyek) ; engedély: adatok írása, attribútumok olvasása...
* TODO
</div>

====HAL: Mi a HAL (Windows)?====
<div class="answer">
* "HAL" - Hardware Abstraction Layer
* A felsőbb rétegek a HAL-on keresztül érik el az alap HW szolgáltatásokat, a HAL szerepe, hogy elfedje a HW megvalósítás részleteit, és egy egységes, platformfüggetlen felületet biztosítson.
* hal.dll fájlban megvalósítva (pl. timer interrupt kezelését, alaplap alapvető felépítését (milyen chipsetek vannak rajta), stb. elfedi a felette lévő rétegektől)
</div>

====Hardverfüggő részek: Melyek a Windows hardverfüggő részei?====
<div class="answer">
* A kernel egyes részei és a HAL.
* Megjegyzés: én ide a drivereket is beírtam, nem vontak le érte pontot, de azt mondták, azokat nem mindig szokás a rendszer részének tekinteni.
</div>

====Jogosultságok szerepe: Mik a jogosultságok (privilege) szerepe a Windows-ban?====
<div class="answer">
* operációs rendszer szintű jog
* meghatározzák azokat a rendszerműveleteket, amelyeket egy felhasználói azonosító elvégezhet. Egy rendszergazda jogosultságokat felhasználóknak és csoportazonosítóknak oszt (http://msdn.microsoft.com/en-us/library/bb530716(VS.85).aspx)
* pl. számítógép leállítása, eszközmeghajtó betöltése
* név: SeShutDownPrivilege, SeLoadDriverPrivilege
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens/Képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerülése: Mi a fő oka, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító függvények kernel módba kerültek? Elméleti megfontolások alapján hol lenne a helyük?====
<div class="answer">
Windows NT 4.0-ban került le kernel szintre ez a komponens, hogy kevesebb folyamat- és módváltás legyen (Ne kelljen mindig visszaváltani a csrss.exe-be, majd onnan átváltani kernel módba, utasítani a hardvert, visszaváltani felhasználói módba, majd visszaváltani a felhasználói folyamatba, aki kezdeményezte a változtatást.) (A felhasználói módú folyamatban (csrss.exe) csak a konzol kezelés maradt.) Elméletileg felhasználói szinten kéne lennie.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Windows-ban miért került le az ablakkezelő kernel módba?====
<div class="answer">
Hogy kevesebb kontextus- és módváltás legyen, mivel a Windows szerves része az ablakkezelés, ezért rengeteg user-kernel mód váltás lenne ha a csrss.exe-en keresztül használnánk. Tehát teljesítménybeli okokból.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens előnyei: A Windows OS grafikus komponensének mik az előnyei, hátrányai?====
<div class="answer">
A grafikus komponens kernel módban fut. Emiatt a hibái az egész rendszert magával ránthatják, viszont gyorsabb, mert kevesebb CPU-mód váltás kell a rajzoláshoz.
</div>

====Képernyőkezelő/ablakkezelő/grafikus komponens kernel módba kerülése: Mi volt a fő oka annak, hogy a Windows NT-ben a képernyőkezelő és grafikus funkciókat megvalósító komponens kernel módba került?====
<div class="answer">
Mert ezek a folyamatok intenzíven használják a hardvert, és futásuk gyorsaságára az egész rendszer teljesítménye érzékeny. A user módban történő megvalósítás a rendszert lelassítaná a gyakori környezetváltás miatt.
</div>

====Kernel: Mi a kernel (Windows)?====
<div class="answer">
A rendszer állandóan memóriában lévő, védett módban futó része. Az NT egyetlen HW függő része, szerepe a HW elfedése a felette található eszközök elől, ezáltal a felette lévő részek már teljesen HW függetlenek. Megvalósítja a szálütemezést, multiprocesszor ütemezést és a TRAP kezelést.
</div>

====Kliens-szerver-modell: Nevezzen meg egy kliens-szerver-modell alapján működő komponenst az NT-ben!====
<div class="answer">
* csrss.exe - Client/Server Run-Time Subsystems (környezeti alrendszerek)
* TODO
</div>

====Memóriafoglalás: Mely utasításokkal és miért történik a memóriafoglalás két lépésben Windows alatt?====
<div class="answer">
* A két lépés: Reserve és Commit. Az első csak címtartományt foglal, amögött nem lesz ténylegesen használható memóriaterület; a másik a már lefoglalt címtartományhoz rendel (virtuális) memóriát.
* A folyamatok címtartományának töredezettsége csökkenthető azzal, ha a címtartományt már akkor előre foglalja, mikor a memóriára még nincs szüksége, és ez nem jár olyan memóriapocsékolással, mintha fizikai memóriát is foglalna ugyanakkor.
</div>

====Munkakészlet (working set): Mit jelent a Windows-ban az egy folyamathoz tartozó munkakészlet (working set) fogalma?====
<div class="answer">
Azon fizikai lapok halmaza, amelyekre a folyamat laphiba nélkül hivatkozhat.
</div>

====NT hardverfüggő rétegei: Sorolja fel az NT hardverfüggő rétegeit!====
<div class="answer">
HAL (Hardware Abstraction Level), kernel
</div>

====NTDLL.DLL: Mi az NTDLL.DLL fő funkciója?====
<div class="answer">
Összeköti a User és Kernel módot. Az Executive függvényeknek megfelelő függvénycsonkok vannak benne.
</div>

====Quantum: Mi a szerepe a quantumnak a Windows ütemezőjében?====
<div class="answer">
* A szálak adott ideig futnak (quantum)
* RR ütemezésnél az időszelet
* Óramegszakításban mérik (clock interval, clock tick) 1 clock tick = ~ 10-15 ms (HALtól függ)
* Quantum hossza: időegység, amíg egy szál fut
* Kliensek esetén a quantum hossza 2 clock tick a háttérben futó folyamatoknak, az előtérben futó folyamatoknak 6 clock tick jut. Így egy CPU-intenzív folyamatról való ablakváltáskor az új, előtérben lévő folyamat arányosan több CPU-időt kap (azonos prioritásokat feltételezve).
* Szervereknél: mindenkinek 12 clock tick a kontextusváltások minimalizálása érdekében. Szervereknél így a kliensek kéréseinek eredményeként felébredő alkalmazásoknak több esélye van befejezni a kérést, és várakozó állapotba kerülni, mielőtt az időszelet véget érne.
* esély annak a folyamatnak, amelynek épp most ért véget a várakozása: a várakozás végén megnöveljük a prioritást, de a quantum eggyel csökken; a quantum végén a prioritást az eredetire csökkenti.
* éhezés elkerülése: az OS másodpercenként megnézni a futásra kész szálakat, és annak, aki nem futott már 300 óraütés óta, 15-ös prioritást ad, megnöveli a quantumját egy quantumnyi futásig
* TODO, hogy a forrás feldolgozása jó-e: http://mit.bme.hu/~micskeiz/opre/files/01-opre-windows-utemezes.pptx

</div>

====Rendszeridő megváltoztatása: A rendszeridő megváltoztatására kinek van joga Windows alatt?====
<div class="answer">
* SeSystemTimePrivilege joggal rendelkező felhasználóknak / azoknak a felhasználóknak, amelyek olyan csoportba tartoznak, amelyekhez hozzá van rendelve a SeSystemtimePrivilege.
* Alapértelmezett beállításként csak az Administrators és Power Users group rendelkezik vele.
* http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx
</div>

====Standby memórialapok listája: Mire szolgál a standby memória lap lista a Windows-ban (miért nem szabad lapként vannak ezek nyilvántartva)?====
<div class="answer">
A lap egy munkahalmaz része volt, de már nem az, elvették tőle. A lap nem módosult, mióta kiírták a merevlemezre, vagy mióta beolvasták. Egy nem Valid laptábla bejegyzés még mutat rá, azaz ha kell, még könnyen életre lehet kelteni a lapot.
</div>

====Szabad (free) és nullázott (zeroed) lapok: Miért van a Windows-ban külön szabad és nullázott (freed és zeroed) memórialap-lista?====
<div class="answer">
Biztonsági okokból. Nem nullázott memóriaterületet odaadni más folyamatnak biztonsági kockázatot jelent.
Tehát a free lapok szabad lapok, de még nem adhatók oda felhasználói folyamatnak, mert "szemetet" vagy érzékeny adatot tartalmazhatnak: nincs nullákkal felülírva a tartalma. A zeroed lapok szabadok, és nullákkal vannak felülírva, tehát odaadhatók felhasználói folyamatnak, amennyiben igény van rá.

TODO: ez így már megfelelő indoklás?

(Korábban:
*Free*: a lap szabad, de nincs 0-kkal felülírva a tartalma, szemét vagy egy előző processz által használt tartalom van benne. Ezt nem adhatja ki közvetlenül a memóriakezelő más processzeknek, mert biztonsági szempontból aggályos adatokat találhatna rajta.
*Zeroed*: szabad és nullákkal felülírt lap, kiadható, ha valakinek kell.
TODO(ez így igaz, csak ebben a formában nem a kérdésre válaszol))
</div>

====Mik a szerepük a szolgáltatásoknak a Windowsban? ====
<div class="answer">
Olyan folyamatok, amik a felhasználói felülettől és belépéstől függetlenül a háttérben futnak, és kibővítik az operációs rendszer alap szolgáltatásait.
TODO?
</div>

====Újrahívhatóság (reentrancy): Mit jelent az, hogy a Windows-ban a rendszerhívások újrahívhatóak?====
<div class="answer">
A rendszerhívásokat több alkalmazás is meghívhatja egyszerre, nem blokkolódnak, ha már valakit éppen kiszolgál az adott rendszerhívás.
</div>

====Védett objektum tulajdonosának speciális joga: Milyen speciális joga van egy védett objektum tulajdonosának az adott objektumra a Windows-ban?====
<div class="answer">
Megváltoztathatja az objektum engedélyeit, akkor is, ha erre nincs explicit joga. (https://wiki.sch.bme.hu/pub/Infoalap/OpRe/03-opre-windows-biztonsag.pptx)
</div>

====Verzióleírás: Mit jelentenek a számok és szavak a következő verzióleírásban: "Microsoft (R) Windows (R) 5.01.2006 Service Pack 2 Uniprocessor Free"?====
<div class="answer">
* (MZ) 5.01.2006 a verziószám, major.minor.build formában, 5.1 a Windows XP verzója, 2006 az SP2-es verzió build száma. Uniprocessor = egy processzoros kernel verzió, Free = debug szimbólumok nélküli verzió.
*(MZ) 2011-től kezdve ez már nem része a tananyagnak
* Most computers run a "uniprocessor free" version of Windows, which is a version that runs on a single CPU and does not contain extra errorchecking.
</div>



==Tartalomjegyzék==
<div class="table_of_contents">
__TOC__
</div>

==Források (teljesség igénye nélkül)==
<div class="docs_sources">
Ez előadás diáin, Wikipédiás és egyéb, Google-lel található cikkeken kívül ezek voltak a források, és MÉG ÍGY SEM tartalmazza az összes beugrókérdést (volt olyan, amit rengeteg idő lett volna átszerkeszteni, vagy kevésbé sanszos, hogy olyan hosszúságú beugrókérdést tennének fel, ami ott szerepelt):

* Hivatalos előadásjegyzetek: http://portal.mit.bme.hu/?l=oktatas/targyak/vimia219/jegyzet/index.html
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaBeugrok
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsgaKisKerdesek
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2007junius12megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008majus20megoldas
* https://wiki.sch.bme.hu/bin/view/Infoalap/OpReVizsga2008junius11megoldas
* https://wiki.sch.bme.hu/pub/Infoalap/OpRe/pelda_beugro_megoldas.pdf
----
* https://vir.sch.bme.hu/dokumentumok/InfoSite/4.%20f%C3%A9l%C3%A9v/Oper%C3%A1ci%C3%B3s%20rendszerek/
* https://vir.sch.bme.hu/document/targyak/opre/opre_beugro.zip (HOSSZÚ)
* https://vir.sch.bme.hu/document/targyak/opre/oprendszkidolg.zip
* Wikipédia
* Google segítségével fellelhető rengeteg forrás
* stb.

-- [[PeteHaro|Pete]] - 2011.06.19.
* [[Media:opre_beugro_ABC.docx|Operációs rendszerek vizsgabeugrók megoldással DOCX-formátumban (szerkeszthető, javítható!)]]
* [[Media:opre_beugro_ABC.pdf|Operációs rendszerek vizsgabeugrók megoldással PDF-formátumban]]

[[Category:Infoalap]]

Jelek és rendszerek

2014-10-17T09:33:29Z

Bolla Dávid: /* A szorgalmi időszakban */

{{Tantárgy
| név = Jelek és rendszerek
| tárgykód = VIHVA214
| szak = info
| kredit = 5
| félév = 4
| kereszt = van
| tanszék = HVT
| kiszh = nincs
| nagyzh = 2 db
| hf = 3 db
| vizsga = nincs
| levlista = jelek{{kukac}}sch.bme.hu
| tad = https://www.vik.bme.hu/kepzes/targyak/VIHVA214/
| tárgyhonlap = http://hvt.bme.hu/index.php?option=com_content&view=article&catid=1%253Absc-kepzes&id=504%253Ajr&Itemid=7&lang=hu
}}

== Követelmények ==
=== Előtanulmányi rend ===
[[Analízis_II. | Analízis 2.]] tárgyból kredit megszerzése szükséges a tárgy felvételéhez.

=== A szorgalmi időszakban ===
*A min. elégséges '''félévvégi jegy''' feltétele:
**Az '''összes begyűjthető pont ~50%-ának elérése''' a következő számonkérésekből:
***'''1. ZH''': 40 pontért.
***'''2. ZH''': 60 pontért.
***'''Házi feladatok''': három otthon megoldandó feladat, melyek közül a legjobb kettő számít, egyenként 10 pontért.
*'''Pótlási lehetőségek:'''
**A házi feladatok nem pótolhatóak illetve határidőn túl nem leadhatóak.
**A két ZH-ból az egyik a pótlási héten pótolható, illetve javítható.
*'''Kontakt órák'''
**'''Előadás:''' Kéthetente változik 1-2 - gyakorlat függvényében.
**'''Gyakorlat:''' Kéthetente 1.

=== A vizsgaidőszakban ===
*'''Vizsga:''' nincs.

=== Félévvégi jegy ===
*A számonkérések összpontszáma adja ki a jegyet.
*Ponthatárok:
:{| class="wikitable" align="center"
!Pont!!Jegy
|-
| 0 - 58 || 1
|-
|59 - 71 || 2
|-
|72 - 84 || 3
|-
|85 - 97 || 4
|-
|98 - 120|| 5
|}

== Segédanyagok ==
* Jegyzetek, összefogalók
** [[Media:Jelek_jegyzet_2008osz_kez.pdf | Kézzel írott jegyzet (2008. ősz)]]
** [[Media:Jelek_jegyzet_laplace.pdf | Laplace transzformáció ]]
** [[Media:Jelek_jegyzet_kepletek.pdf | Képletgyűjtemény ]]
** [http://www.bolyai.elte.hu/download/eloadas/szakmai/ejegyzet/Gnadig_II.pdf Mi az a diracdelta? ]
** [[Media:Jelek_jegyzet_osszefoglalo.pdf | Összefoglaló ]] (1,3,4-dik ZH-koz)
** [[Media:Jelek_jegyzet_zhkiskerdesek.pdf | 2. ZH-n előforduló kiskérdések]] (tárgyhonlapról)
** angol összefoglaló: [[Media:Jelek_jegyzet_zh1_en.pdf | ZH1]], [[Media:Jelek_jegyzet_zh2_en.pdf | ZH2]], [[Media:Jelek_jegyzet_zh3_en.pdf | ZH3]], [[Media:Jelek_jegyzet_zh4_en.doc | ZH4]]
** [[Media:Jelek_jegyzet_matlab.pdf | Matlab összefogaló ]]
** [[Media:Jelek_jegyzet_rendszerk.pdf | Frekvencia összefoglaló ]]

* Jelek könyv
** [[Media:Jelek_konyv_0targymutato.pdf | Tárgymutató]]
** [[Media:Jelek_konyv_0tartalom.pdf | Tartalomjegyzék]]
** [[Media:Jelek_konyv_1.pdf | Első fejezet]]
** [[Media:Jelek_konyv_2.pdf | Második fejezet]]
** [[Media:Jelek_konyv_3.pdf | Harmadik fejezet]]
** [[Media:Jelek_konyv_4.pdf | Negyedik fejezet]]
** [[Media:Jelek_konyv_5.pdf | Ötödik fejezet]]
** [[Media:Jelek_konyv_szie.pdf | Kuczmann könyv]]

* Tárgyhonlapról néhány link
** [http://www.mht.bme.hu/~varga/BMEVIHVA214/JR-gyak-2010.pdf Tantermi gyakorlat feladatgyűjteménye]
** [http://www.mht.bme.hu/~varga/BMEVIHVA214/JR-HP-VL-01.pdf Jelek és rendszerek példatár]
** [http://hvt.bme.hu/images/education/jr/jelek_rendszerk_frek.pdf Elméleti összefoglaló 2.ZH]

== Házi ==
A félév során 3 házi feladatot lehet elkészíteni, melyek közül a két legjobb számít bele az érdemjegybe. Én erősen ajánlom, hogy az első 2 házit csináljátok meg, később nagyon fogtok örülni annak a +15-20 pontnak!

Jófejségből a félév végére annyit variálnak, hogy 3. házi pontszámának a felét is hozzáadják még a végeredményhez, de persze semmi garancia nincs arra, hogy ezt minden félévben megteszik.

*Pár korábbi házi:
**Első:
***[[Media:Jelek_elsohazi_megoldas.pdf | Első házi megoldás]] csak egy mintamegoldás - van benne egy elvi hiba! - 1.2.3 feladat diszkrét időben teljesen rossz. /JR Gyakvez/
***[[Media:jelek_hf1_megoldas.pdf | Első házi megoldás]] Egy 10 pontos első házi ( de 1.2.c.DI-nél van valami hiba).
***[[Media:jelek_hf1.pdf | Első házi megoldás]] Szintén egy 10 pontos mintamegoldás.
***[[Media:jelek_hf1_140523.pdf | Első házi megoldás]] - 10 pontos
**Második:
***[[Media:jelek_hf2_2.pdf | Második házi megoldás]] Csak az a,b,c feladatok megoldásai vannak benne (7.6 pontos házi). Az "a" részben 3. oldalon el van rontva a determináns. A kedves feltöltő kolléga nem tud parciálisan integrálni. Az 5. oldal tetején a megmaradó integrált kivonni kell, nem hozzáadni. Így a végén (cx - 1) lesz a számlálóban az egyik tag. Ezt a hibát az író bravúrosan korrigálja egy, a semmiből mágikusan előbukkanó -1-es szorzóval az oldal alján. 2B rész DI feladatában hibásan van kiemelve a szumma elől a 4, "4*e^(-j*p*pi/3*x)"-et kellene helyette írni.
***[[Media:jelek_hf2_140523.pdf | Második házi megoldás]] - 10 pontos
***[[Media:Jelek_HF2_20140525.pdf | Második házi megoldás]] - 10 pontos
**Harmadik:
***[[Media:Jelek_HF3_20140525.pdf | Harmadik házi megoldás]] - 9 pontos. A második feladatot nem kellett megcsinálni (2013/14/II.)

==ZH==

'''Releváns ZH-k:'''

*2014 tavasz
** 2014.05.16. ZH2 [[Media:Info_jelek_zh2a_2014tavasz.pdf | A csoport]] - megoldás nélkül

*2013 tavasz
** 2013.05.17. ZH2 [[Media:Jelek_zh2_2013-05-17_a.jpg | A csoport]] | [[Media:Jelek_zh2_2013-05-17_b.jpg | B csoport]] - megoldás nélkül

*2011 ősz
** 2011.12.07 ZH2 [[Media:Jelek_zh2_2011-12-07_a.pdf | A csoport]] | [[Media:Jelek_zh2_2011-12-07_b.pdf | B csoport]] - megoldással
** 2011.10.17 ZH1 [[Media:Jelek_zh1_2011-10-17_a.pdf | A csoport]] | [[Media:Jelek_zh1_2011-10-17_b.pdf | B csoport]] - megoldással

*2010 ősz
** 2010.10.19 ZH1 [[Media:Jelek_zh1_2010-10-19_a_jav.pdf | A csoport]] | [[Media:Jelek_zh1_2010-10-19_b_jav.pdf | B csoport]] - megoldással

*2010 tavasz
** 2010.05.10 ZH2 [[Media:Jelek_zh2_2010-05-10_a_jav.pdf | A csoport]] | [[Media:Jelek_zh2_2010-05-10_b_jav.pdf | B csoport]] - megoldással
** 2010.03.29 ZH1 [[Media:Jelek_zh1_2010-03-29_a_jav.pdf | A csoport]] | [[Media:Jelek_zh1_2010-03-29_b_jav.pdf | B csoport]] - megoldással

*2009 ősz
** 2009.12.11 ZH2 [[Media:Jelek_zh2_2009-12-11_a_jav.pdf | A csoport]] | [[Media:Jelek_zh2_2009-12-11_b_jav.pdf | B csoport]] - megoldással
** 2009.10.26 ZH1 [[Media:Jelek_zh1_2009-10-26_a_jav.doc | A csoport]] | [[Media:Jelek_zh1_2009-10-26_b_jav.doc | B csoport]] - megoldással
<br/>
{{Rejtett
|mutatott='''Régebbi, "elavult" ZH-k:'''
|szöveg=
*2009 tavasz
** 2009.03.09 ZH1 [[Media:Jelek_zh1_2009-03-09_a.pdf | A csoport]] / [[Media:Jelek_zh1_2009-03-09_b.pdf | B csoport]] - megoldás nélkül
** 2009.03.30 ZH2 [[Media:Jelek_zh2_2009-03-30_a_jav.pdf | A csoport ]] / [[Media:Jelek_zh2_2009-03-30_b_jav.pdf | B csoport]] - megoldással
** 2009.04.20 ZH3 [[Media:Jelek_zh3_2009-04-20_a_jav.pdf | A csoport ]] / [[Media:Jelek_zh3_2009-04-20_b_jav.pdf | B csoport]] - megoldással
** 2009.05.10 ZH4 [[Media:Jelek_zh4_2009-05-10_a_jav.pdf | A csoport]] / [[Media:Jelek_zh4_2009-05-10_b_jav.pdf | B csoport]] - megoldással

* [[Media:Jelek_zh_2008_megoldas.pdf | 2008 ősz]] megoldással

*2008 tavasz
** 2008.03.21 ZH1 [[Media:Jelek_zh1_2008-03-21_a_jav.pdf | A csoport]] / [[Media:Jelek_zh1_2008-03-21_b_jav.pdf | B csoport]] - megoldással
** 2008.04.04 ZH2 [[Media:Jelek_zh2_2008-04-04_a_jav.pdf | A csoport]] / [[Media:Jelek_zh2_2008-04-04_b_jav.pdf | B csoport]] - megoldással
** 2008.05.16 ZH4 [[Media:Jelek_zh4_2008-05-16_a_jav.pdf | A csoport]] / [[Media:Jelek_zh4_2008-05-16_b_jav.pdf | B csoport]] - megoldással

*2007 ősz
** 2007.10.16 ZH1 [[Media:Jelek_zh1_2007-10-16_a_jav.pdf | A csoport]] / [[Media:Jelek_zh1_2007-10-16_b_jav.pdf | B csoport]] - megoldással
** 2007.11.13 ZH2 [[Media:Jelek_zh2_2007-11-13_a_jav.pdf | A csoport]] / [[Media:Jelek_zh2_2007-11-13_b_jav.pdf | B csoport]] - megoldással
** 2007.12.13 ZH3 [[Media:Jelek_zh3_2007-12-13_a_jav.pdf | A csoport]] / [[Media:Jelek_zh3_2007-12-13_b_jav.pdf | B csoport]] - megoldással
** 2007.11.09 PZH1 [[Media:Jelek_pzh1_2007-11-09_a_jav.pdf | A csoport]] / [[Media:Jelek_pzh1_2007-11-09_b_jav.pdf | B csoport]] - megoldással
** 2007.11.27 PZH2 [[Media:Jelek_pzh2_2007-11-27_a_jav.pdf | A csoport]] / [[Media:Jelek_pzh2_2007-11-27_b_jav.pdf | B csoport]] - megoldással
** 2007.12.20 PZH3 [[Media:Jelek_pzh3_2007-12-20_a_jav.pdf | A csoport]] / [[Media:Jelek_pzh3_2007-12-20_b_jav.pdf | B csoport]] - megoldással

*2007 tavasz
** 2007.03.23 ZH1 [[Media:Jelek_zh1_2007-03-23_a.pdf | A csoport]] / [[Media:Jelek_zh1_2007-03-23_b.pdf | B csoport]] - megoldás nélkül
** 2007.04.20 ZH2 (A) [[Media:Jelek_zh2_2007-04-20_a.pdf | megoldás nélkül]] / [[Media:Jelek_zh2_2007-04-20_a_jav.pdf | megoldással]]
** 2007.04.20 ZH2 (B) [[Media:Jelek_zh2_2007-04-20_b.pdf | megoldás nélkül]] / [[Media:Jelek_zh2_2007-04-20_b_jav.pdf | megoldással]]
** 2007.05.18 ZH3 [[Media:Jelek_zh3_2007-05-18_a.pdf | A csoport]] / [[Media:Jelek_zh3_2007-05-18_b.pdf | B csoport]] - megoldás nélkül
** [[Media:Jelek_pzh1_2007-05-15.pdf | 2007.05.15 PZH1]] megoldás nélkül
** [[Media:Jelek_pzh2_2007-05-15.pdf | 2007.05.15 PZH2]] megoldás nélkül
** [[Media:Jelek_pzh3_2007-05-25.pdf | 2007.05.25 PZH3]] megoldás nélkül

*2006 tavasz
**2006.04.20 ZH2 [[Jelek és rendszerek - ZH2 2006.04.20.|megoldásokkal]]
}}

== Egyéb anyagok ==
Erősen ajánlott elmenni a konzikra, vagy legalábbis '''''átnézni a konzik anyagát'''''!
* Konzi anyagok:
** 1. ZH
***[[Media:jelek_zh1_konzi_2013_tavasz.pdf | 2013 tavasz]]
** 2. ZH
*** [[Media:jelek_zh2_konz_2012_osz.pdf | 2012 ősz]]
*** [[Media:jelek_zh2_konzi_2013_tavasz.pdf | 2013 tavasz]]

== Tippek ==
Ha van lehetőségetek, inkább Gyimóthy Szabolcs és Reichardt András előadó gyakorlatvezető párost válasszátok, mint Pávó József és Horváth Zoltán párost. Gyimóthy inkább tanuláskor jól használható jegyzetet ír a táblára, míg Pávó József inkább csak az összefüggéseket. Gyimóthy óráira kötelező bejárni, ha már az órán meg akarod érteni az anyagot, s a jó eredményre pályázol. Viszont Gyimóthy kereszten tanít, és egyesen német nyelven, s Pávó viszi az egyenest magyar nyelven.

Egyik házi feladat sem kötelező, de ha nem csináltál házikat és néhány ponton múlik a félév végi jegy, akkor a fejedet fogod a falba verni, hogy miért nem csináltál legalább egy házit...

Előfordulhat olyan, hogy eselteg pár pont kell a jobb jegyhez, akkor menézik a 3. házifeladatot is, és annak a pontszámának egy részét is beleszámítják a jegybe!
by Fityusz

Zh előtti konzultációra feltétlen menjetek be, nagyon hasznos!
by Fityusz

Kis tapasztalat: póton szigorúbban osztályoznak (sokkal!) 2013 tavaszi félévben volt, ahol részpontszámot sem adtak, tehát érdemes a rendes ZH-kra tervezni az átmenetelt.

{{Lábléc_-_Mérnök_informatikus_alapszak}}