Beágyazott operációs rendszerek

ZV kérdések
1. Mutassa be a μCOS-II operációs rendszer felépítését és főbb szolgáltatásait!
μCOS-II operációs rendszer felépítése:
-16 fájlból áll
- 3 fő csport:
1. Port fájlok: processzro függő fájlok  lehetővé válik ezen felül platform
független
2. Platform független kód: ez az oprendszer magja
3. Konfig fájlok: alkalmazás függő konfigurációs fájlok

μCOS-II főbb szolgáltatásai

 preemptív ütemező
 taszkok kezelése
 időzítés
 esemény jelző flagek, szemaforok, mutexek, postaláda, várakozási sorok, memória
menedzsment (ezek kiegészítő szolgáltatások)
 determinisztikus futási idő
 jól konfigurálható → a feladat és a rendelkezésre álló hardver szempontjából
optimális memóriafoglalás
 C nyelven írt forráskód szintjén is elérhető

2. Ismertesse a μCOS-II operációs rendszerben a taszkok nyilvántartásához

használt struktúrákat és használatukat! Mutassa be, hogy a nyilvántartásban
hogyan lehet egytaszkot futásra késszé tenni, törölni a futásra készek közül,
valamint megtalálni a legnagyobb prioritású futásra kész taszkot!
Taszkok kezelése:
 memória függvényében maximális taszkok számának meghatározása
 Task Control Block – TCB  taszki nyilvántartása
 TCBláncolt listába kerül a legelső elemet veszi ki az OSTaskCreate
 TCB adatai:
o taszk prioritása
o verem pointer
o taszk akt állapota
o változók
Ütemezés:
 a taszkok nyilvántartása kulcsfontosságú az ütemezőben → gyors keresés
 OSRdyTb - a futásra kész taszkok nyilvántartásához tartozó táblázat
o 8 oszlop, 8 sor → maximális 64 prioritási szint, 0 a legmagasabb, 63 a
legalacsonyabb
o minden cellához egy taszk van rendelve, a taszk prioritásának alsó 3 bitje az
oszlop indexet, a következő 3 bit a sorindexet határozza meg

o 1-t írunk a táblázatba, ha a taszk futásra kész, amúgy 0-t

 OSRdyGrp - mely sorokban (prioritás csoportokban) található futásra kész taszk
o az első bit 1, ha a táblázat sorában van egyes, a második bit 1, ha a második
sorában van 1…
  összesen 9 bájtnyi helyet foglalunk, egyszerűen vezethető, gyorsan kereshető

Taszk futásra késszé tétele

 Post jellegű rendszerhívások (végrehajtják az objektumra jellemző műveletet, futásra
késszé teszik a taszkot, majd meghívják az ütemezőt)
 a taszk prioritásának megfelelő bitet kell az OSRdyTbl-ben és az OSRdyGrp-ben 1-re
állítani: 
o OSRdyGrp |= OSMapTbl[prio>>3];
OSRdyTbl[prio>>3] |= OSMapTbl[prio & 0x07];
 OSMapTbl elemeiben az indexnek megfelelő sorszámú bit 1-es:

Taszk törlése a futásra készek közül

 Pend jellegű rendszerhívások (végrehajtják az objektumra jellemző műveletet, törlik a
taszkot a futásra kész taszkok közül, majd meghívják az ütemezőt)
 a táblázatban a taszk prioritása által meghatározott bitet 0-ba kell állítani
 ha az adott sorban nem maradt egyetlen bit sem 1-ben, akkor az OSRdyGrp-ben is
törölni kell a sornak megfelelő bitet
o if ((OSRdyTbl[prio>>3] &= ~OSMapTbl[prio & 0x07]) == 0x00)
OSRdyGrp &= ~OSMapTbl[prio>>3];
Legnagyobb prioritású futásra kész taszk megtalálása
 Ütemező feladata
 OSRdyGrp változó értékéből meghatározható, hogy a táblázat melyik sorában
található a legmagasabb prioritású futásra kész taszk
o venni kell az OSRdyGrp-ből annak a bitnek a sorszámát, melyben a
legalacsonyabb helyiértékű 1-es található
 az oszlopindex meghatározásához a táblázat sorában meg kell találnunk a legkisebb
helyiértékű bitet, melyben 1-es található, ehhez segédtáblázatot használhatunk
(megadja az adott számhoz a legkisebb helyiértékű egyes értékét)
o Y = OSUnMapTbl[OSRdyGrp];
X = OSUnMapTbl[OSRdyTbl[Y]];
prio = (Y << 3) + X;
 táblázat indexelésekkel és néhány bitművelettel megoldható
3. Mintapéldán keresztül mutassa be a prioritás inverzió jelenségét és a prioritás
öröklés protokollt!
Prioritás inverzió
 nemkívánatos jelenség

 tfh. 3 taszkunk van, 1 alacsony, 1 közepes, 1 magas prioritású

 A jelenség során felborulhat a prioritási sorrend mivel a magas prioritású taszk azt az
erőforrást szeretné használni melyet egy alacsonyabb prioritású már lefoglalt. 
Nem tud a magas prioritású indulni de közte van egy közepes prio taszk amely el tud
indulni  mindkét taszk megelőzi a magas prioritásút ebben az
esetebenmegoldás: prioritás öröklés

Prioritás öröklés
 alapelve, hogy amennyiben egy taszk elkezd várakozni egy szemaforra, amelyet egy
alacsonyabb prioritású taszk birtokol, akkor az alacsonyabb prioritású taszk
prioritását időlegesen megemeljük a magasabb prioritású taszkkal megegyező szintre

 a korábbi példa mentén amikor a magas prioritású taszk elkezd várakozni a

szemaforra, az alacsony prioritású taszk prioritását megemeljük, ezzel elérjük, hogy a
közepes prioritású taszk ne előzze meg a magas prioritásút
 az alacsony mindenképp megelőzi, hiszen az birtokolja a szemafort

4. Mutassa be a μCOS-II operációs rendszeren keresztül a leggyakrabban

használt szinkronizációs objektumokat!
 szemafor
o védett globális jelzőváltozó elvén működnek
o 2 atomi művelet végezhető rajtuk (elnevezés oprendszerenként más lehet)
 P - vizsgálat és lefoglalás
 V - felszabadítás
o problémák:
 holtpont: az első taszk arra vár, hogy a második taszk felszabadítsa
az erőforrást, míg a második taszk arra vár, hogy az első felszabadítsa
az erőforrást
  megoldás: minden szemafor lefoglalása a függvény elején,
vagy nem fix várakozási idő
 prioritás inverzió
 megoldás prioritás öröklés
Használatuk:
o taszkok közötti kommunikáció
o taszkok szinkronizálása
o 1 bitnyi információ átadására alkalmas (taszk → taszk, ISR → taszk)
 ez az egyirányú kommunikáció az egyoldalú randevú
o két szemafor használatával szinkronizálni lehet 2 taszk működését
 ez a kétoldalú randevú
o az eddigi bináris szemaforon kívül van számláló jellegű, ilyenkor nem csak két
állapot lehet, hanem több is
Megvalósítása a szemafornak:
 létrehozni  Create függvénnyel
 küldés Post
 a várakozás Pend
 értékvizsgálat Accept

 eseményjelző flagek
o több bitnyi információ átvitelére szolgálnak
o bitek csoportja, amely az esemény bekövetkeztekor az eseménynek
megfelelő bit bebillen
o a taszkok az események tetszőleges kombinációjára várakozhatnak, egy
eseményre több taszk is
o az eseményeket törölni kell várakozás után
o hasonló a megvalósítása a szemaforhoz
 mutex
o olyan bináris szemafor, amelyek védettek a prioritás inverzió jelenségével
szemben (jelen esetben prioritás örökléssel)
 postaláda
o általában egy pointer méretű tároló
o több taszk is elhelyezhet benne üzenetet és több taszk is várakozhat rá
o a legnagyobb prioritású veheti ki az üzenetet vagy FIFO szabály is lehet
o hasonló a megvalósítása a szemaforhoz

 várakozási sor
o többrekeszes postaláda
o a rekeszekben pointereket lehet tárolni
o tetszőleges számú taszk helyezhet el üzenetet, kivenni a várakozó taszkok
közül a legmagasabb prioritásúnak van joga
o üzenetek kivétele lehet FIFO, LIFO
o hasonló a megvalósítása a szemaforhoz

 pipe (csővezeték) támogatás nincs ebben az oprendszerben

o olyan várakozási sor, ahol az üzenetek mérete nem fix
 nem lehetséges a több kommunikációs objektumra történő egyidejű várakozás

5. Milyen komponensekből épül fel a GNU/Linux rendszer? Ismertesse az

elindulás folyamatát!
Komponensek a GNU/Linux rendszerben
  Kernel (modulokkal)
 Fejlesztői könyvtárak
 Segédprogramok
 Shell(ek)
 Shell scriptek
 Alacsony szintű grafika (framebuffer)
o directfb, SDL
 X Window (Xorg, KDrive) (windowing system for bitmap displays)
o widget library: Xlib, Qt, Gtk++
o Desktop Environment: KDE, GNOME

Elindulás folyamata
Linux betöltése:
1. kernelbetöltő végzi el: LILO (The Linux Loader), Grub, uBoot, LOADLIN…
2. Hardveres segitség kernebetöltönek x86 bios armnál bootstrap
3. kernelbetöltő kernel programot indítja el (kitömörít elindít)
4. Hw incializálás majd első c kód start_kernel() hívása
5. init kernel szál:
o fájl rendszer csatolása
o konzol
o getyy process->user login

Initrd és initramfs:
 olyan állományok egy összetömörített állományrendszert tartalmaznak pl: live
disztribúciók

SysV init:
 a kernel a kezdeti feladatainak végrehajtása után és a root állományrendszer
csatolása után elindítja az init programot, ami a további rendszer inicializálási
lépéseket teszi meg
o hálózati eszközök beállítása
o konzol konfigurálása
o USB eszközök inicializálása
o állományrendszerek ellenőrzése és felcsatolása
 ezután következik a különböző szolgáltatások elindítása, virtuális konzolok és X
felület létrehozása
o ezeket /etc/inittab állomány alapján végzi el
 az init program több futás szintet definiál
o futási szint egy konfigurációs összeállítás, amelyben összeállíthajtuk, hogy a
rendszer egyes állapotaiban milyen szolgáltatások fussanak és melyek nem

6. Ismertesse a Linux rendszerek által használt állományrendszereket! (Más

operációs rendszerek által használt állományrendszerek támogatása nem része a
kérdésnek.)
1. Minix
o első változat volt egy osztot meoria volt minix rnedsezr és linux közöt

2. Extended filesytems (ext, ext2, ext3, ext4)

o elsősorban a Linux számára lettek kifejlesztve
o ext3 journaling (naplózó) fájl rendszer volt már
3. Journaling állományrendszerek
o működés: mielőtt a valódi műveleteket végrehajtaná elsőként a napló fájlokat
készíti el majd ha ez elkészült akkor ez alapján végre hajtja a fájl művelteket.
o előnye: üzembiztos  minidig konzisztens állapotban van a fájl rendszer vagy
a log
o hátránya: lassabb mint a naplózás nélküli fájlrendszer
4. Journaling Flash File System (JFFS)
o naplózás jellegű állományrendszer, amely az állományok új verzióit
cirkulárisan írja fel az eszközre, mintha egy naplóállományt írnánk a
módosításokról ez segit eloszlatni a NOR flash memóriák terhelését
o üres hely a napló eleje és vége közötti terület
o előnye: egy lépésben megvalósul a tárolás és a naplózás
o hátrányai:
 lassú felcsatolás( aktuális verzió pozíció datokkal is dolgozik)
 a nem módosítót állományokat is át kell helyezze feleslegesen
5. JFFS2
o a JFFS2 nem egy cirkuláris napló állományként kezeli az eszközt, hanem
blokkokra osztja, amelyekből mindig egyet tölt fel, amíg az meg nem telik és
át nem vált egy másikra
o a módosításokat nem a korábbi pozícióra írja vissza, hanem az éppen aktuális
blokkba
o a blokknak három állapota lehet:
o Tiszta blokk: Csak aktuális információkat tartalmaz.
o Piszkos blokk: Tartalmaz aktuális + elavult állományokat
o Szabad blokk: Nem tartalmaz adatot.

o statikus állományokra előnyösebb

o hátrányai:
 továbbra is lassú felcsatolás, mivel végig kell vizsgálni az
állományrendszert az információk összegyűjtéséhez
 memória igény is megmaradt, illetve kicsit tovább nőtt
6. Unsorted Block Image File System (UBIFS)
o JFFS2 továbbfejlesztése
o gyorsítótárat használ az írásnál
o pesszimista algoritmust használ a szabad terület megbecsüléséhez (sosem
becsül többet)
o gyorsult a felcsatolás, a nagy állományok elérése és az írás művelet
o jobb a visszaállíthatósága és a tápfeszültség hiba tűrése mint a JFFS2
esetében

7. Speciális állományrendszerek (virtuális állományrendszerek)

o Proc
 a kernel belső állapotáról szolgáltat információkat
 lehetőséget nyújt a beállítások menet közbeni módosítására
 /proc könyvtárban láthatjuk
o Sysfs
 a rendszerben található eszközöket teszi elérhetővé fa struktúrába
szervezve
 megnézhetjük az eszköz állapotát, kontrolálhatjuk az eszközvezérlő
beállításait 
 /sys könyvtárban találhatjuk
o Tmpfs
 ramdisk eszközt valósít meg, tényleges tárolás nem történik, az
újraindítás után az állományok nem elérhetők
  gyakran használjuk átmeneti állományok tárolására, vagy a folyamatok
közötti kommunikációra, mivel gyors és nem terheli a háttértárként
használt eszköz

7. Milyen állománytípusokat különböztetünk meg a Linux

állományrendszerében? Az állományoknak milyen jogosultságokat állíthatunk
be?
Állománytípusok
 Egyszerű állomány
o bájtok sorozata, adatok, program, stb.
o a Linux minden állományt egyszerűen byte-ok véletlenszerűen címezhető
szekvenciájának tekinti
o a rendszer eltakarja az állományt tároló fizikai eszköz tulajdonságait
 Könyvtár
o speciális állomány, amely olyan információkat tartalmaz, amire a rendszernek
szüksége van az állomány elérésére
o pl. ext(2,3,4) állományrendszerek esetén tartalmazza az állomány nevét és a
hozzá tartozó i-node indexet
 Eszközök
o a legtöbb fizikai eszköz a Linux rendszerben állományként jelenik meg
 ugyanúgy kezelhetjük, mint a közönséges állományokat
 ezeket a műveleteket az adott eszközre értelmezhető műveletre
képezi le a kernel (pl. hangkártya eszköz olvasása a hang
bedigitalizálását jelenti, az írása pedig a hang állomány lejátszását)
o 2 eszköztípust különböztetünk meg:
 blokk
 nem olvashatunk bájtonként, csak bájtok blokkjaiként
 leggyakrabban háttértárak ls fájlrendszert tartalmaznak
 karakter
 bájtonként olvasható
 modemek, terminálok, printerek, hangkártyák és az egér mind
karakteres eszköz
o /dev könyvtárban találhatók az eszköz leíró speciális állományok
 Szimbolikus link
o symlink, speciális állomány, egy másik állomány elérési információit
tartalmazza
o amikor megnyitjuk a rendszer érzékeli, hogy szimbolikus link, kiolvassa az
értékét és megnyitja a hivatkozott állományt → szimbolikus link követés
 Csővezeték (pipe) és socket állományok
o a Linux két egyszerű IPC (Inter Process Communication, folyamatok közötti
kommunikáció) mechanizmusát alkotják
o spec. állományok, amelyek kommunikációs csatornát írnak le a memóriában

Jogosultságok az állományoknak
 minden felhasználó rendelkezik egy egyedi azonosító számmal (uid) és
 egy vagy több csoport azonosító számmal (gid) → /etc/passwd állományban van a
többi csoportazonosító az /etc/group állomány alapján rendelődik hozzá a
felhasználóhoz
 rendszergazda (uid 0)  mindenek fellett áll
 Állományok 1 tulajdonos(állomány létrehozó) és 1 csoport(létrehozó csoportja)
azonosítóval rendelkeznek
  Felhasználó és állomány között 3 féle kapcsolat lehet:
o owner (ő hozta létre  hozzá fér)
o group (azonos csoportban van  hozzá fér)
o others (eltér felhasználó és csoport azonosító  nem fér hozzá)
 minden relációra 3 féle jogosultsági engedélyt állíthatunk be
o olvasás
o írás
o végrehajtás (könyvtárak esetén ez a keresési jog)
 ls –l : az állományokat és hozzájuk tartozó jogokat mutatja meg
o pl: drwxr-xr-x 2 root root 4096 Sep 23 23:24 dir1

 a lista sorainak első mezője tartalmazza az adott állományra/könyvtárra érvényes

jogokat a következők szerint:
o drwxrwxrwx
o az első karakter az állomány típusa:
 b → a bejegyzés egy blokk-orientált spec. állomány
 c → karakter-orientált spec. állomány
 d → katalógus
 l → szimbolikus link
 - → egyszerű állomány
o a következő 9 karakter hármas csoportokra osztható
 az első 3 az owner
 a második 3 a group
 a harmadik 3 az other jogai
o a hármas csoporton belül 3 karakter sorrendben a következő lehet:
 r → olvasás/read
 w → írás/write
 x → végrehajtás/execution
 - → a fentiek hiánya
 szimbolikus linkek esetén a jogok nem értelmezettek, az eredeti állomány jogai az
irányadóak
 a jogokat a chmod segítségével módosíthatjuk: chmod <mód> <fájlnév>

8. A Linux parancsértelmezők (shell) milyen szolgáltatásokat nyújtanak?

 közönséges felhasználói program
o nem integráns része az oprendszernek
o lecsrélehtő msára is
o a UNIX shell-ek nem csupán parancsértelmezők, hanem programozási
nyelvek is egyben
o rendszerbetöltéskor azonosítás után elindul a beállított shell
 parancsértelmező
o beolvassa a begépelt sorokat és azt más programok végrehajtását előíró
kérésekként értelmezi
o a parancssor legegyszerűbb esetben egy parancsból és hozzá tartozó,
szóközökkel elválasztott paraméterekből áll: parancs argl arg2 ... argn
o felbontja a parancsot-> majd PATH –ban megadott állományokban megkeresi
végrehajtja  befejezését prompt kiírásával jelzi
o az egyszerű argumentumokat a program string tömbjeként kapja meg
 Shell beépített parancsai / szolgáltatása
o a shell beépített parancsai a shell működésével szorosan összefüggők
 o  tartalmazza a legszükségesebb programok egyszerűsített változatait
o állománynév-helyettesítés
 állománynevekből álló egyszerű argumentumok sorozatára
cserélődnek le
o standard input/output átirányítás
 a shell által végrehajtott programok 3 megnyitott állománnyal indulnak
 0 (állományleíró) → standard input
 1 → standard output
 2 → error output
 ezek alapértelmezetten a felhasználó termináljához vannak rendelve,
de átirányíthatjuk őket
 “>” vagy “>>” jellel a standard output-ot
 “>>” az adott állomány végére fűzi a kimenetet
 a hiba kimenet a “2>” jelöléssel irányítható át
 a standard input is átirányítható a “<” jellel
o csővezeték
 egyik program kimenetét szeretnénk egy másik program
bemeneteként használni (pl. kimenet szűrés, tördelés, rendezés)
 olyan spec. állomány, ami egy FIFO-t valósít meg
 nincs szükség ideiglenes fájlokra
 “párhuzamosan” folynak a folyamatok, nem kell nagy FIFo
o parancshelyettesítés
 az egyik program kimenetét a másik program paraméter listájaként
használjuk
o szinkron és aszinkron folyamatok
 ha egy parancsot “&” jel követ háttérben fut promptot visszakapjuk
o csoportosítás
 a parancsokat csoportosíthajtuk zárójelekkel: pl (date; ls) > lista & →
kiírja a dátumot és állományok listáját a “lista” állományba háttérbe
o Bash scriptek futtatása

9. Ismertesse a Yocto Project fejlesztői keretrendszer funkcióját, felépítését,

működését!
Fejlesztői keretrendszer funkciója
 Ez egy automatizált bulid rendszer  könnyen lehet vele egyedi disztribúciót
létrehozni a cél targetre
 Bitbake receptek segítésével írja le rendszer paramétereit
 recept - sw csomag előállítási recept tartalmazza:
o Adminisztratív adatok a telepítő csomaghoz
o Függőségek
o Forrás állományok (URL → letölti), előkészítésük, konfigurálásuk
o Fordítás
o Telepítés, telepítő csomagok összeállítása
o Esetlegesen a csomag fordító környezetbe való telepítése
o Architektúra függő kiegészítések, egyes lépések felüldefiniálása
 használatához linux rendszer kell
Felépítése
 a rendszer könyvtára az alábbi alkönyvtárakat tartalmazza:
o bitbake – A program, ami a recepteket végrehajtja
o build* – A könyvtár, amit a munkához létrehozunk
o documentation – Dokumentációk
 o Rétegek: meta, meta-yocto, meta-yocto-bsp
 classes – BBClass állományok, amelyek receptekben felhasználható
műveleteket implementálnak
 conf – Konfigurációs állományok
 bitbake.conf – A BitBake fő konfigurációs állománya
 distro – Disztribúciók
 machine – Architektúrák
 files – Egyéb állományok
 recipes-* – Receptek
 site – Operációs rendszer függő beállítások
o scripts – Szkriptek a műveletek egyszerűsítéséhez

 a recipes könyvtár sw csomagonként 1-1 könyvtárat tartalmaz:

 saját receptjeinket, kiegészítéseinket új réteg létrehozásával adhatjuk a rendszerhez
o yocto-bsp create <bsp-name> <karch>
o elsősorban bsp jellegű rétegek létrehozására szolgál

Működése
 valós idejű rendszer készítése
o yocto project-tel valósidejű Linux rendszert is készíthetünk
o ez a normál rendszertől csak a kernelben tér el, illetve hozzáadhatunk néhány
sw eszközt a valósidejű használathoz
 létrehozott könyvtárak
o fordítás során a “build” egy tmp könyvtárat hoz létre:
 cache: átmeneti állomány, amely gyorsítja a receptek elindítását
 deploy: telepíthető csomagok és image állományok
 pkgdata: a csomagok adatai
 rootfs: teljes beágy rendszer esetén a root állományrendszer
 stamps: elvégzett műveletek üres állományok létrehozásával könyveli
 sysroots: keresztfordító körny. állományai, library+header fordításhoz
 work: egyes csomagok lefordításához külön könyvtárak létrehozása
o fordításáhozés telepítő csomagok  work könyvtáron :
 temp: a scriptek (minden lépéshez) mellett a műveletek log állományai
 forrás könyvtár: patch-elés, konfigurálás, fordítás ebben könyvtárban
 image: fordítás végén a telepítést itt végzi el + telepítő csomag
összeválogatása
 packages-split: minden telepítő csomaghoz létrehoz egy alkönyvtárat,
belemásolja az image könyvtárból a csomaghoz tartozó állományokat
 staging-pkg: fejlesztői könyvtár fordításkor a keresztfordítói körny.ben
is szükség van mind a library, mind a header állományokra, ebben a
könyvtárban rendezi össze egy telepítő csomaggá
 telepítés
o A beágyazott rendszer telepítéséhez az alábbi lépések:
 A cél tároló eszközt partícionálnunk kell. Tipikusan egy partíciót kell
létrehoznunk rajta és be kell állítanunk Linux típusúra.
 El kell készítenünk az állományrendszert a partíción.
 Fel kell csatolnunk a partíciót.
 A deploy/images könyvtárban található tömörített állományrendszer
állományt ki kell tömörítenünk a felcsatolt partícióra.
 A konfig esetleges módosítása, majd a partíció lecsatolása.
o a kernel telepítése függ az architektúrától
 keresztfordítás
o recept nélkül is lefordítható saját program, kézzel elvégezve a keresztfordítást
 o sysroots könyvtár tartalmazza a programokat és a keresztfordító körny.:
 Keresztfordító programok, Segédprogramok
 Fejlesztői könyvtárak (library), Header állományok
 Konfigurációs állományok a fordításhoz
o a fordító programok könyvtárneve függ a hoszt és a cél architektúrától
o egyszerűsíthető “environment” állományok legenerálásával, amelyek
tartalmazzák a szükséges környezeti beállításokat
 tmp könyvtárban “environment-setup-...”
 SDK készítése
o önálló, telepíthető SDK csomag létrehozására van lehetőség
o telepítés után képesek lesznek a keresztfordítások elvégzésére a teljes
rendszer nélkül
o generálás eredménye egy önállóan futtatható shell script a „tmp/deploy/sdk/”
könyvtárban: tartalmazza tömörítve a teljes csomagot is, önkitömörítő telepítő

 virtuális gép generálása

o rendszer image-ből egy virtuális gép imaget lehet előállítani
o a virtuális gép x86-os gépnek számít → csomagok újrafordításával jár
o valódi rendszerünkkel megegyező rendszert futtat, CPU architektúrális eltérés
o lehetőség “vmdk” állomány generálására, v. gép háttértáraként funkcionálhat
o egyszerűsödhet az alkalmazásfejlesztés, gyorsulhat a hibakeresés

10. Ismertesse a Makefile szintaktikai elemeit!

 make program lehetővé teszi programunk fordításának leírását és automatizálását
 make funkciót Makefile-ban írjuk le(programfordítás menete+forrásállományok leírás)
 általánosan ötféle dolgot tartalmazhatnak:
o megjegyzések
o explicit szabályok, implicit szabályok
o változódefiníciók
o direktívák
 explicit szabályok
o a szabály (rule) határozza meg, hogy mikor és hogyan kell újrafordítani egy
vagy több állományt (létrejön a szabály célja/tárgya/target, szükség van
függőségi listára, feltételekre, vagy előkövetelményekre)
 Hamis tárgy
o ha vmilyen műveletre egy szabályt készítünk, amelynek a recept része
tartalmazza a végrehajtandó parancsokat, a szabály célja ilyenkor nem egy
előállítandó állomány, hanem csak egy névként funkcionál, amellyel a
szabályra hivatkozunk → ezek a hamis tárgyak
 változódefiníciók
o ha egy állomány több helyen is szerepel változókat használunk
o VALTOZO = ERTEK (az érték típusa mindig szöveg)
o hivatkozni az értékadás után: $(VALTOZO) vagy ${VALTOZO}
 változó értékadásának speciális esetei
o := → egyszerű kiértékelés, a definiálás helyén
o += → a változó értékéhez hozzáadjuk a további szövegeket
o ?= → feltételes értékadás, csak akkor adunk értéket ha még nincs definiálva
 több soros változók definiálása
o define ket-sor = (define direktíva, változónak értékadás, név után művelet (=,
+=), a műveleti jel után mást már nem írhatunk az első sorban)
echo $(a) (hivatkozhatunk más változókra is)
 echo ketto
endef (a blokkot endef zárja)
o szükség esetén meg is szüntethetjük: undefine ket-sor
 változó hivatkozásának speciális esetei
o helyettesítő hivatkozás, változóra való hivatkozás során az értékét módosítva
helyettesítsük be, konverziós szabályt definiálva: $(valtozo:a=b) vagy $
{valtozo:a=b}
 a művelet minden szó végén lecseréli az “a” szövegrészletet “b”re
o számított változónevek (hivatkozott változó nevét másik változó tartalmazza): 
 a=b
b=c
eredm := $($(a)) (az eredmény c lesz, kombinálhatjuk helyettesítő
hivatkozásokkal is)
 automatikus változók
o az állományok nevét a szabály céljából és feltételeiből generálhatjuk
o általános szabályok definiálásához használjuk:
 $@ → a cél állomány neve
 $< → függőségi lista első elemének neve
 $? → összes olyan feltétel fájl neve (sorban, szóközzel elválasztva),
amely frissebb a célállománynál
 $^ → összes feltétel fájlnév szóközzel elválasztva
 $+ → jelentése nagyrészt egyezik az előzővel, azonban ha a feltételek
közt többször szerepel a fájl, akkor azt több példányban tartalmazza
 $* → a célfájl nevének utótag nélküli része
 többszörös cél
o egy szabály megadásakor nem csak egy tárgyat, hanem tárgyak listáját is
megadhatjuk, szóközökkel elválasztva
o minden tárgyra külön-külön végrehajtódik a szabály (automatikus változókkal
eltérő parancsokat tudunk generálni azonos recept esetében)
 minta szabályok
o statikus minta szabályok, a cél állományok nevéből generáljuk a feltételeket
o TÁRGYAK: TÁRGY-MINTA: ELŐKÖVETELMÉNYEK-MINTÁJA; RECEPT
RECEPT
 a tárgyak listájánál használhatunk helyettesítő karaktereket
 a minta megadja, hogy hogyan számítható a név
 a tárgy nevére illesztve a tárgy mintáját a “%” helyére eső szöveget a
rendszer az előkövetelmény mintájának “%” karakterrel jelölt helyére
illeszti és így előállít egy új feltételt
o általánosított forma a minta szbályok
 alapértelmezett szabályt alkotunk
 csak akkor érvényes, ha a rendszer nem talál egy specifikus szabályt
az adott cél állomány előállítására
 TÁRGY-MINTA: ELŐKÖVETELMÉNYEK-MINTÁJA; RECEPT
RECEPT
 klasszikus ragozási szabályok
o minta szabályok elődje, már háttérbe szorult
o megadható az utótagok listája, ill. hogy az egyik utótaggal rendelkező
állományból hogyan állítható elő egy másik utótaggal rendelkező állomány
o utótagokat a .SUFFIXES után kell felsorolni
o FsCs: (Fs a forrás utótag, Cs a cél utótag)
RECEPT
.SUFFIXES
o nem lehetnek további előkövetelményei, csak az az egy, ami generálódik
 implicit szabályok
 o a tipikus parancsok és szabályok beépítése más forrásállományokból
o make program állomány előállításakor, vagy szabály feltételeinek
vizsgálatakor megpróbálja megkeresni a rá vonatkozó szabályt
 ha nem szerepel az állomány egyetlen szabály tárgyaként sem, akkor
megpróbál alapértelmezett szabályt találni rá → implicit szabályok
o nagy része előre adott ragozási szabály / minta szabály, de mi is írhatunk
o %.o: %.c
$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $(OUTPUT_OPTION)
$<
 speciális tárgyak
o .PHONY → Ennek a célnak az előfeltételei hamis céloknak minősülnek.
Vagyis a célhoz tartozó szabályt időbélyeg ellenőrzés nélkül mindenképpen
lefuttatja a make.
o .SUFFIXES → A cél előfeltételei állománynév kiterjesztések, amelyeket a
make a ragozási szabályok keresésénél használ.
o .DEFAULT → Ehhez a célhoz megadott recept fut le azokban az esetekben,
ha egy adott célhoz sem explicit, sem implicit szabályt nem talál a rendszer.
o .SILENT → Ha megadunk előfeltételt ehhez a szabályhoz, akkor az azok
előállításánál végrehajtott parancsokat nem írja ki a make. Ha nem adunk
meg előfeltételt, akkor minden recept végrehajtása „csendes” lesz.
o .ONESHELL → Korábban láthattuk, hogy a recept végrehajtása során minden
sor külön shell példányban hívódik meg. Ennek a speciális célnak a
használatával ezt módosíthatjuk. Ebben az esetben a teljes recept egy shell
példány hajtódik végre.
 direktívák
o arra utasítják a make programot, hogy vmilyen speciális műveletet végezzen
 más Makefile-ok beolvasása
 feltételek alapján a Makefile egyes részeinek használata vagy
figyelmen kívül hagyása
 változók definiálása
o ifeq ($(CC),gcc)
libs := $(gcc_libs)
else
libs := $(normal_libs)
endif

11.Ismertesse a C/C++ Linux alkalmazások hibakeresésének főbb eszközeit!

Hibakeresés:
 általános nyelv a C, de vannak nehezen felderíthető hibái
o memória szivárgás (memory leak)
o túlírás (buffer overrun)
 a legfőbb hibakereső a gdb, de a memória kezelési hibák csak egy kis részét deríti fel
→ ElectricFence vagy valgrind erre, AddressSanitizer
 strace → diagnosztikai, hibakereső eszköz, lefuttatja a programot, majd monitorozza
a processz rendszerhívásait, jelzéseket
 lint → vizsgálja a kód helyességét, gyanús részeket (pl. nem inicializált változók,
tömbök túlindexelése, értékadás az egyenlőség helyett, stb)
gdb:
 hibakereső, futás közbeni hibakeresés
 funkciói 4 csoportba oszthatók:
 o A program elindítása.
o A program megállítása meghatározott feltételek esetén.
o A program megálláskori állapotának vizsgálata.
o A program egyes részeinek megváltoztatása, hatásának vizsgálata a hibára.
 C, C++ támogatása teljesen, többi részlegesen

 töréspontok:
o a watchpoint olyan spec. töréspont, amely akkor állítja meg a programot, ha a
megadott kifejezés értéke változik
 olvasás → awatch
 módosítás → rwatch
o a catchpoint egy másik spec. töréspont, amely akkor állítja meg a program
futását, ha egy meghatározott esemény következik be, pl. exception:
Valgrind:
 parancssoros program, eszközkészlet a következőkre:
o Memóriakezelési hibák felderítése
o Szálkezelési hibák felderítése
o Teljesítmény analízis
 a programot egy virtuális processzoron futtatja
 a virtuális processzor számos hibaellenőrzést végez
AddressSanitizer:
 memóriakezelési hiba érzékelő C/C++ alkalmazásokhoz
 valgrind-hez képest nagy előnye, hogy sokkal gyorsabb
 nem virtuális processzoron futtatja, hanem programkódot egészíti ki hibakereső
algoritmusokkal
 fordításkor „-fsanitize=address” paraméter szükséges
o nagyobb, speciális változat készül el, csak hibakereséshez célszerű

12.Ismertesse a Linux rendszerben használatos inode fogalmát, olvasásának és

állításának rendszerhívásait és függvényeit!
Inode fogalma
 az állomány egyetlen egyedi azonosítója az inode-ja (information node)
 tartalmaz minden infót az állományról (jogokat, méretét, hivatkozások számát)
 2 fajta inode van:
o in-core inode: minden megnyitott állományhoz tartozik 1, a kernel a
memóriában tartja, minden állománytípushoz egyforma
o on-disk inode: a lemezen tárolódik, minden állomány rendelkezik eggyel, a
tárolása és struktúrája a fájlrendszer függvénye
 amikor egy processz megnyitja az állományt, az on-disk inode betöltődik a
memóriába és in-core inode-ra konvertálódik
 amikor az in-core inode módosul, visszakonvertálódik on-disk inode-ra és tárolódik a
fájlrendszeren
 a két inode-típus szinkronizálását a kernel végzi, a legtöbb rendszerhívás azzal
végződik, h mindkettőt frissíti
 az állománynév egy adott könyvtárban csak hivatkozás az on-disk inode-ra
Inode információk kiolvasása
 3 függvény támogatásra az inode információk eléréséhez:
o int stat(const char *file_name, struct stat *buf);
int lstat(const char *file_name, struct stat *buf);(nem követ szimbolikus hivatkozást)
int fstat(int fd, struct stat *buf); (megnyitott állományok inode infóinak elérése)
Jogok lekérdezése
  egyszerű rendszerhívással lekérdezhetjük a jogokat: int access(const char
*pathname, int mode);
 ls –l  kilistázza az állományokat és jogokat
Jogok állítása
 az állományok hozzáférési jogai a chmod() rendszerhívással módosíthatók:
o int chmod(const char *path, mode_t mode);
int fchmod(int fd, mode_t mode);
Tulajdonos és csoport állítása
 az állomány tulajdonosa és csoportja is inode struktúrában
 egy rendszerhívás szolgál mindkettő állítására
o int chown(const char *path, uid_t owner, gid_t group);
o int lchown(const char *path, uid_t owner, gid_t group);
o int fchown(int fd, uid_t owner, gid_t group);

13.Ismertesse az I/O-multiplexelés lehetőségeit a Linux alkalmazásokban!

I/O-multiplexelés
 kliens/szerver programoknak szüksége van párhuzamosan több, spec. állomány
olvasására, írására
 a nem blokkolt I/O kezelés megadja a lehetőségét, hogy egyes állományleírók között
gyorsan váltogassunk, de ilyenkor a program folyamatosan olvasgatná mindkét leírót
és sosem függesztené fel a futást → fölösleges terhelés
 ezeknek megoldására és hatékony multiplexelésre használatos select()+poll()
Select
 hatékony multiplexelés, lehetővé teszi hogy párhuzamosan blokkolódjon és több
állományra várakozzon a processz
 amennyiben vmely állomány tartalmaz rendelkezésre álló adatot, vagy képes fogadni
új adatokat a select() visszatér és az alkalmazás olvashatja/írhatja azokat a fájlokat
blokkolódás veszélye nélkül
 ezek után egy újabb select() hívással várakozhatunk az újabb adatokra
 readfds, writefds, és exceptfds azt adja meg, h mely állományleírókra vagyunk
kíváncsiak
Poll
 a select()-hez hasonlóan működik, funkciójában megegyezik, csak
paraméterezésben tér el
 a poll() egy tömböt vár, amelynek elemei pollfd struktúrák
 a poll() addig várakozik, amíg legalább egy megadott esemény bekövetkezik, vagy
lejár a timeout

14. Hogyan hozhatunk létre folyamatokat a Linux alkalmazásokban és milyen

eszközeink vannak a folyamatok közötti kommunikációra?
Folyamat: Elszeparált virtuális memóriaterüelten, egymással futó alkalmazások, csak IPC vel
képesek egymással kommunikálni.

Folyamat létrehozása:

 fork() függvénnyel, visszatérési értéke a sikeresség

 sikeres végrehajtás esetén létrehoz egy új folyamatot ami másolata lesz az előző
folyamatnak
 A másolat teljesen egyezik az eredetivel, csak az process-azonosítóban különbözik
 Ha később módosítunk a belső változókon, akkor az a másik processzeknél nem érvényesül.
 megszüntetés: kill()
  várakozás wait()
Folyamatok közötti kommunikáció (IPC):

 Signal: jelző függvények, változást jelzik a folyamatoknak

 Csővezeték (pipe)
 Socket kommunikáció
 System V IPC
o Folyamatok között globális erőforrások:
 Szemaforok (ipc -s): folyamatok szinkronizálására használatos
 megosztott memória esetén
 szemafor tömb.
 Létrehozás semget(),
 konfigurálás semctl(),
 használat semop(),
 törlés semctl(id,0)
 Üzenetsorok (ipc -q): Összetett üzenetek kerülnek a listába, másik oldalon
ki tudjuk venni
 FIFO mechanizmus,
 létrehozás msgget(),
 küldést msgsnd(),
 fogadás msdgrcv(),
 konfig mscgctl(),
 törlés msgctl(id,0)
 Osztott memória (ipc -m):Egy vagy több memórialap egyszerre több
folyamat címterébe fog leképződni, ezáltal látni fogják memória
hivatkozásokként.
 leggyorsabb, szinkronizálás kell hozzá
 létrehozás shmget()
 felcsatolás shmat()
 lecsatolás shmdt()
 konfig shmctl()
 törlés shmctl(id,0)

15. A Linux rendszer milyen POSIX szálkezelő eszközöket implementál?

Hogyan hozhatunk létre szálakat és milyen szinkronizációs eszközök állnak
rendelkezésre?
Szálak: Könnyűsúlyú folyamatok, egy folyamaton belül több szál lehetséges, ezek a folyamat
erőforrásain osztoznak.
Szálak létrehozása:

 Létrehozása a clone() rendszerhíváson alapul, de közvetlenül nem használjuk

 #include pthread.h szálkezelő könyvtár szükséges
 Létrehozás pthread_create(szál leírása, pointer, attríbutumok, öröklődés..), paranccsal,
visszatérési értéke a sikeresség
Szál típusa:

 Joinable: phtread_join szál befejezése megvárható, visszatérési értékét szülő átveheti

 Detached: Önálló szál, a szülő nem menedzselheti
Szinkronizálási eszközök:

1. Mutex
2. Feltételes változó
3. POSIX Szemafor
 Mutex:
o Kölcsönös kizárás megvalósítására
o Szemafor 1 kezdő értékkel, egy szál foglalhatja egyszerre
o Ha lefoglalt akkor más nem foglalhatja le
o Kritikus szakaszokban a memória bizonyos részeihez csak egy szál férhet hozzá.
o Fajtái: Gyors, Rekurzív, Hibakereső: lefoglalás utáni újbol lefoglaláskor a
viselkedésük eltérő.
o Létrehozás: pthread_mutex_init
o Felszabadítás: pthread_mutex_destroy
o Lefoglalás pthread_mutex_lock
o Elengedés: pthread_mutex_unlock
 Feltételes változó:
o Ha bekövetkezik egy esemény arról tudunk jelzést küldeni a többi szálnak
o Szálak várakozhatnak a jelzésre
o Szinkronizálni kell őket Mutexel.
o Létrehozás: pthread_cond_init
o Felszabadítás: pthread_cond_destroy
o Jelzés küldés:
 1 szálnak pthread_cond_signal
 Több szálnak pthread_cond_broadcast
o Fogadás pthread_cond_wait
 POSIX szemafor:
o Szálak és folyamatok között is tud múködni
o Névtelen: létrehozás sem_init, törlés sem_destroy
o Megnevezett: létrehozás sem_open zárás sem_close törlés sem_unlink
o Lefoglalás sem_wait
o Felszabadítás sem_post
16. A Linux alkalmazások determinisztikus futásidejének érdekében milyen
óvintézkedéseket kell megtennünk az alkalmazásunkban?

A valósidejű alkalmazások esetén alapvetően ugyanaz az API használható, kivéve, hogy a egy
valósidejű RT kernel lesz. A valósidejű működés alapfeltétele a determinisztikus (kiszámítható)
működés.

A determinisztikus működés biztosítása:

 Ütemezés: Valós idejű ütemezés beállítása a valós idejű prioritások növelésével
 Memória előre lefoglalása: Memóriahasználat során a fizikai memóriát használjuk, ügyelni
kell a memóriaterületen belüli használatra, mert ha megtelik akkor a memóriafelszabadítás
nem determinisztikus működéshez vezet.
 A stack laphibák megakadályozása: Előre legeneráljuk a laphibákat, ami alapján
megtörténik a lapfoglalás.
Ütemezés:

 Ütemezés policy beállítása: SCHED_RR (round-robin) vagy SCHED_FIFO

 Valósidejű prioritások beállítása: 1-99 ig, kivéve kernel megszakítások és taskletek (50)
 Folyamatokra: SCHED_setscheduler (folyamat pid, policy)
 Szálakra: PTHREAD_setschedparam(szál, policy)
Fizikai memóriában tartás (lapok):

 Zárolás : mlockALL(aktiális, jövőbeli foglalás)

 Memória véges, memory leakre vigyázni kell
Stack terület laphibák megakadályozása:

 Induláskor legeneráljuk a laphibákat, így allokálhatunk fizikai lapokat a process-hez

 Ehhez allokálni kell a stacken egy akkora tömböt, amibe belefér minden későbbi allokáció,
stack_prefault(MAX_STACK) függvénnyel
 Ne allokáljunk többet, mint a beállított maximum
Időzítő függvények:

 Nélkülözhetőek, nagyon pontos várokozások létrehozására alkalmas (pl nanosleep)

17. Hogyan valósítunk meg a Linux alkalmazásunkban összeköttetés alapú
kommunikációt?
Hálózat alapú kommunikáció felépítése:

Socket:


A kommunikáció alapja (Berkely API)

Létrehozása a socket() fgv-el

Meghatározza a kommunikációs protokollt (UNIX,INET) és típust
(STREAM,RAW,SEQPACKET)
Cím megadása:

 sockaddr struktúrába: címcsalád azonosító és címadat

Port megadás:

 Különböző architektúrájú processzorok (Little-Big Endian) nem egységesen kezelik

a címeket, ezért a portban átalakító függvényeket használunk
Kapcsolat alapú kommunikáció:

 Asszimetrikus kommunikáció, külön kliens és szerver rész:

o Server:
 Szükséges egy socket, ezen keresztül fogadjuk a kapcsolódást,
létrehozás socket() fgv-el
 A socketet hozzárendeljük bind()-al egy címhez és porthoz
 Várakozás a kapcsolódásokra listen()
 Meghívjuk az accept() függvényt, ami blokkolódik. Addig alszik a
processz amig nem jön kapcsolódási kérés
 Ha befut a kapcsolódási kérés accept() visszatér a kliens sockettel
amivel tudunk kommunikálni a klienssel
o Kliens:
 Szükséges socket, ez kommunikációra használható
 Összeállítjuk a célszerver címét
 A szerver címét átadjuk a connect()-nek, amivel kapcsolódik a
címhez.
 Connect blokkolva lesz amíg nem épül fel a kapcsolat
 Amikor visszatér használható a kommunikációs csatorna
Kommunikáció:

 A kommunikáció történhet a read és write állománykezelő függvényekkel

 Speciális függvényekkel send, receive melyek visszatérési értékéből a sikeresen
elküldött/fogadott byteok számát és a kapcsolat állapotát kapjuk
18. Hogyan valósítunk meg a Linux alkalmazásunkban összeköttetés nélküli
kommunikációt?
Összeköttetés nélküli kommunikácó felépítése:

 Szimmetrikus kommunikáció: mindkét oldal egyforma, küldhet, fogadhat (nincs külön

szerver-kliens)
 Létre kell hozni a socketet, majd címhez kell kötni (hogy tudjuk címezni a küldeményt)
 Kommunikáció
Kommunikáció:

 sendto és recvfrom függvényekkel végezzük

 sendto:
o socket beállítása,
o buffer pointer és méret megadás,
o flag
o struktúrába hova menjen a csomag: túloldal címe és hossza
 recvfrom:
o buffer megadása
o bufer mérete
o flag
o struktúra: megadja honnan jött a csomag
Gyakorlatban:

Szimmetrikus kommunikációnál nem server és client van, mindkét fél lehet küldő és fogadó
is.

 Fogadás:
1. Socket létrehozása socket() fgv-el
2. Lokális cím megadása
3. Bind-olás
4. recvfrom al egyből fogadás, és megnézni ki küldte: recvfrom visszaadja hány byte
csomagot kapott, eltárolja a bufferbe és megadja honnan jött az információ
 Küldés:
1. Socket lérehozása
2. Célgép cím összeállítása, hova kell küldeni a csomagot (ip címből lekérdezéssel)
3. Bind nem szükséges ha csak küldeni akarunk (Bind fogadásra)
4. UDP csomagként sendto-val adat elküldése
19. Milyen különbségek vannak a Linux kernel modulok és alkalmazások
között? (felépítés, fordítás, hibakezelés, további megkötések)

 Kernel:
o Csak C vagy assembly nyelven készülhet (általában C, gyors rész assembly)
o esemény vezérelt, (nem szekvenciális) futás eseményekre lesz kész lekezelés. Main
fgv. helyett callback fgv.
o A kernelmodulok a kernelhez linkelődnek, így nincs hozzárendelve libc (stdio stb.)
ezért ezek a függvények nem használhatók, de hasonló szimbólumok vannak pl
printk.
o Include: csak linux vagy asm könyvtárak használhatók (libc: stdio stb nem!)
o névütközés: Szimbólumok exportálásánál figyelni kell a név megadására mert egy
függvény/változó név csak egyszer szerepelhet
o Kernelmodulok a fizikai memóriát használják, allokációval vigyázni (memory leak)
o Lebegőpontos számításokat ne használjunk
 Különbségek:
o Hibakezelés: A kernelmodulban elkövetett hibák sokkal súlyosabbak, mint
alkalmazások esetén, a teljes rendszer is összeomolhat, alkalmazás esetén csak az
alkalmazás omlik össze
o Kernelben nincs korlátozás, alkalmazás korlátolt
o Kernel: Konkurencia problémák megszakítások vagy több processzor esetén
20. Hogyan implementálhatjuk a paraméter átadást a Linux kernel modulban?
Hogyan használhatjuk a mechanizmust?
A kernelmodul paraméterek az alkalmazásokkal ellentétben nem egyszerűen definiálhatók, külön
létre kell hozni őket.

Modul paraméter létrehozása:

 Létrehozni statikus globális változót, megadni alapértelmezett értékét

 Paraméterek definiálása module_param fgv-el, ebben kell megadni a paraméter
nevét ,típusát és jogosultságot.
 Paraméter lehet még tömb vagy string alakú
 modulparam.h header szükséges
 MODULE_PARM_DESC makróval szöveges leírást adhatunk a paraméternek
 modinfo paranccsal lehet lekérdezni
 létrehozás modul betöltésekor insmod, vagy modprobe
 eltávolítás modul eltávolításakor rmmod
Paraméterek használata:

 Létrehozás után egyszerűen használható, változóként használjuk

 insmod segítségével betöltjük, dmesg-el visszanézhetjük a paraméterek értékeit
 Egyszerű betöltésnél alapértelmezett paramértékek lesznek
 Betöltésnél paraméter változóhoz új értéket rendelhetünk: param1=3
Automatikus meghívás, modprobe:

 Ha automatikusan hívódik meg a modul mint Modprobe-nál, akkor nem parancssorba

adjuk meg a paramétereket, hanem a konfigurációs fájlokba
 A konfigba az „options” parancsot használva megadhatjuk a paraméterek értékét
Paraméterek elérhetősége:

 A kernel modul betöltése után virtuális könyvtár jön létre hozzá

 sys/module/parameters könyvtárban találhatók a paraméterek aktuális értékei
 megfelelő jogosultságokkal itt is lehet módosítani az értékét
 modinfo paranccsal ellenőrizhető a paraméterek típusa és szöveges leírásuk (DESC
makró!)

○
21. Ismertesse az eszközvezérlő modellt a Linux rendszerben!
Eszközvezérlő modell

● A modern eszközvezérlők az eszközvezérlő modellt implementálják

● A modell a buszok és a rajtuk levő eszközök leírására szolgál, adatstruktúra formájában
● Az adatstruktúra hozzáférhető, pontos képet kapunk a rendszerben található eszközökről
A busz

● Eszközök kapcsolódnak hozzá, kommunikációs csatorna

● Lehet PCI, USB, I2C, SPI
● Platform busz: minden olyan eszközkezelő, ami nem tényleges buszhoz kapcsolódó hvt
kezel
● Busz-leíró struktúra általános attributumokat és függvények mutatóit tartalmazza
I2C

● használathoz be kell illeszteni az i2c.h állományt

● a driver regisztrációjához egy struct i2c_driver struktúrát kell kitölteni és az adott makróval
regisztrálni
Eszköz és eszközvezérlő lista

● eszközvezérlő adatstruktúra tartalmazza:

○ name - Az eszközvezérlő neve.
○ bus - A busz, amelyhez az eszközvezérlő tartozik.
○ owner - A kernelmodul, amelyhez tartozik
○ probe - egy új eszközt teszteljük vele, hogy az eszközt kezeli-e az eszközvezérlő
○ remove - Az eszköz eltávolítása
● minimum a name és a bus mezőket ki kell tölteni regisztráláshoz: int driver_register(struct
device_driver *drv);
Az eszköz

● általános leíró struktúra:

○ parent - Az eszköz szülője, többnyire egy busz, vagy vezérlő.
○ init_name - Az eszköz neve.
○ type - Az eszköz típusa.
○ mutex - Az eszközhöz rendelt mutex
○ bus - A busz amire csatlakoztatva van.
○ driver - A driver amelyik allokálta ezt a struktúrát.
● a busz eszközvezérlője érzékeli az eszköz csatlakozását, ennek hatására létrehoz egy
példányt a device struktúrából és meghívja a megfelelő eszközvezérlő probe() fvt
Eszköz attribútumok

● eszközök attribútumait kiexportálhatjuk a sysfs állományrendszeren keresztül

● alakja az attribútum leíró struktúrájában található:
○ attribute tartalmazza a nevet és a jogosultság-beállításokat
○ a show() az attribútum olvasásakor hívódik meg
○ a store() fv az állomány írásakor hívódik meg
● kiexportáláshoz használt makró: DEVICE_ATTR(név, mód, showfv, storefv)
22. Ismertesse a párhuzamosság kezelésének eszközeit a Linux kernelben!
Párhuzamosság kezelés szükséges, ha:

 ha megszakításkezelőben használunk olyan változókat, ami máshol is hozzáférhető

● ha többprocesszoros rendszert használunk
Atomi műveletek

● legegyszerűbb szinkronizáció,
● gépi kód szinten egy utasításban valósul meg
● nincs veszély, hogy a művelet végrehajtása közben egy másik processzoron futó másik kód
hatással lesz a műveletünkre
● egyszerű műveletek, csak egész számokon értelmezett érték növelő/csökkentő/tesztelő és
bit műveleteket tartalmazhat
Ciklikus zárolás (spinlock)

● CPU-t terhelő ciklusban kísérletezik a zárolás megszerzésével mindaddig, amíg meg nem
szerezte
● csak rövid kritikus szakaszok esetén használjuk
● a ciklikus zárolással védett kritikus szakasz ne tartalmazzon sleep() fvt. holtponthoz
vezethet, rendszer lefagyáshoz
● a létrehozás és init egy lépésben egy makróval is lehet: static DEFINE_SPINLOCK(lock);
● lefoglalás: spin_lock
● felszabadítás: spin_unlock
Szemafor (semaphore)

● a ciklikus zárolásnál összetettebb, több erőforrást igényel

● komolyabb esetekben, vagy ha a ciklikus zárolás a megkötései miatt nem használható, akkor
inkább szemafor
● várakozáshoz sleep() fvt használ, nem használhatjuk így olyan helyen, ahol a sleep() fvek
tiltottak (megszakításkezelő, ciklikus zárolás által védett szakaszok)
● létrehozás: struct semaphore sem;
● létrehozás+init makró: static DEFINE_SEMPHORE(sem);
● attól függően h mi szakíthatja meg a várakozást több fv is használható lefoglalásra:
○ egyszerű lefoglalás, amikor csak a szemafor felszabadulása vet véget a várakozásnak
○ ha egy jelzés megszakíthatja
○ ha kritikus szignál szakíthatja csak meg:
○ ha időkorlátos várakozást szeretnénk
Mutex

● a szemafort 1 kezdő értékkel mutexként kölcsönös kizárás megvalósítására

● a mutex azokban az esetekben használható, ahol egyébként szemafort használnánk
kölcsönös kizárásra
● a megkötések:
○ Csak a lefoglaló szabadíthatja fel.
○ Rekurzív foglalás, vagy többszörös felszabadítás nem engedélyezett.
○ Nem használható megszakítás kontextusában.
● A létrehozás és az inicializálás a következő makróval történhet: DEFINE_MUTEX(mutex);
● A mutex lefoglalása: void mutex_lock
 ● A mutex felszabadítása: void mutex_unlock
● A mutex foglaltságának ellenőrzése: int mutex_is_locked
23. Ismertesse a megszakítás kezelés implementációját a Linux kernelben!
Térjen ki a "Bottom Half" mechanizmus bemutatására is!
Megszakításkezelés

○ Létre kell hoznunk egy megszakítás kezelő függvényt.

○ Regisztrálnunk kell a megszakítás kezelő függvényt az adott megszakításhoz.
○ A driver eltávolításakor a megszakítás kezelő regisztrációját is el kell távolítanunk.
● Megszakításkezelő fv alakja: typedef irqreturn_t (*irq_handler_t)(int irq, void *devid);
● a megszakításkezelőnket az alábbi fvel regisztrálhatjuk: int request_irq(irq, handler, flags,
*devname, *devid);
○ irq a megszakítás száma, handler a megszakításkezelő fv, flags az opciók, devname
az eszközvezérlő neve, devid a megosztott megszakítás egyedi azonosító
○ flags mező értékei az alábbiak lehetnek:
■ IRQF_DISABLED (SA_INTERRUPT): A gyors interrupt jelzése. Az
implementációt gyorsra kell készítenünk, mert a megszakítás kezelő futása
alatt a megszakítás le van tiltva.
■ IRQF_SHARED (SA_SHIRQ): Annak jelzése, hogy az interruptot megosztjuk
más megszakítás kezelőkkel. Ilyenkor általában több hardver használja
ugyanazt a megszakítás vonalat.
■ IRQF_SAMPLE_RANDOM (SA_SAMPLE_RANDOM): A megszakítás
felhasználható a véletlen szám generáláshoz.
■ IRQF_TIMER: A megszakítás timer interrupt.
○ a visszatérési érték:
■ IRQ_HANDLED: A megszakítást lekezelte a függvény.
■ IRQ_NONE: A megszakítást nem kezelte a függvény.
● regisztráció törlése a köv fvel: void free_irq(irq, void *devid);
Megszakítások megosztása

● a megszakítás vonalak száma véges, ezért több eszköz között osztanak meg egy megszakítás
vonalat
● ebben az esetben a megszakítás kezelő fv regisztrációjánál jeleznünk kell az IRQF_SHARED
flaggel a megosztott használatot
Megszakítás kezelő fvek megkötései

● Nem használhatunk sleep()-es függvényt, mivel beláthatatlan következményekkel járna egy

taszkváltás a megszakítás kezelő kontextusban.
● A kernel és a user space között nem mozgathatunk adatokat.
● Törekedjünk a gyorsaságra.
● Processz specifikus adatok nem elérhetőek a megszakítás kezelőből.
BH mechanizmus

● a megszakítás-kezelőben gyakran kell komolyabb adatfeldolgozást is végezni, ekkor

azonban nem lesz gyors az implementáció,
● erre megoldást nyújt az alsó rész (Bottom half, BH) mechanizmus, amely a
megszakításkezelőt egy felső részre (Top half) és egy alsó részre (Bottom half) választja szét
 ● a felső rész a tényleges megszakításkezelő, feladata csak az adatok gyors letárolása és a
feldolgozó rutin
● az alsó rész rutin már nem megszakításidőben fut,
● az implementációra két mechanizmust használtak:
○ Tasklet
○ Workqueue
○ ezeket váltotta fel a Kernelszálas megszakítás kezelés
Kernelszálas megszakítás kezelés

● a regisztrációt követően a kernel létrehoz egy szálat az adott megszakítás lekezeléséhez

● amikor megszakítás érkezik, akkor a hagyományos megszakításkezelő fv ezt fogadja és
átadja a szálnak, amely a megadott szálas lekezelő fvt fogja meghívni hozzá, de már nem
megszakítás, hanem szál kontextusban
● a szálas megszakításkezelő fvre már nem vonatkoznak szigorú megkötések
Megszakítás tiltása és engedélyezése

● letiltás:
○ void disable_irq(irq);
● ismételt engedélyezés: void enable_irq(unsigned int irq);
● összes megszakítás tiltása, illetve engedélyezése:
○ void local_irq_enable();
void local_irq_disable();
○
24. Ismertesse a QNX alapvető architektúráját és az üzenetek segítségével
történő kommunikáció folyamatát!
● QNX Neutrino mikrokernel architektúrájú, sw busznak nevezi az oprendszer magját és a
hozzá kapcsolódó szolgáltatásokat
○ mikrokernel (QNX):
■ a hw felett egy vékony réteget tekint
az operációs rendszer magjának
■ központi swnek a feladata az
alapvető szolgáltatásokat biztosítsa:
memóriakezelés, processzekkel
kapcsolatos műveletek, processzek
közötti kommunikáció biztosítása
■ a rendszerszolgáltatásokat ugyanolyan swek (szerver sw-ek), mint a valódi
felhasználói programok
● QNX kernel szolgáltatásai:
○ szálakkal kapcsolatos szolgáltatások (POSIX threads)
○ jelekkel kapcsolatos szolgáltatások (POSIX signals)
○ üzenettovábbítási szolgáltatások
○ szinkronizációs szolgáltatások (POSIX thread-
synchronization)
○ ütemezési szolgáltatások (POSIX scheduling)
○ időzítő szolgáltatások (POSIX timer services)
○ folyamatok kezelésével kapcsolatos szolgáltatások
(process management)
● a kernel soha nem kerül ütemezésre, végrehajtására közvetlen
kernelhívás, kivételkezelés (exception) vagy hw megszakítás hatására kerül sor
● a teljes rendszer felépítése, alapszolgáltatásai POSIX szabvány szerint
● hasonló a UNIX-hoz, de inkább szolgáltatásokat, felületet (interface) definiál és nem a
rendszerek belső felépítését
○ előny: az alkalmazások hordozhatóak a kül. oprendszer verziók között, általános és
hasonló eszközökkel fejleszthető a rendszer, a fejlesztők tudása széles területen
hasznos, gyorsabb fejlesztési ciklus valósítható meg
Üzenetek segítségével történő kommunikáció

● a működés alapvetően üzenetek továbbítására épül

● az üzenetek bájtsorozatok, amelyekhez az oprendszer nem párosít semmilyen kül.
jelentést, csak a küldő és fogadó értelmezi azt
● az üzenetekhez kapcsolódva egyes folyamatok szinkronizálni is tudnak
● a komm. során bekövetkező állapotváltozások és az ütemezés lehetővé teszi az erőforrások
megfelelő kihasználását
● a valósidejű és egyéb kritikus alkalmazások a kommunikációs és egyéb kapcsolódó
szolgáltatások segítségével tudják biztonsággal elvégezni a feladataikat
● helyi hálózatok szolgáltatása
● a párhuzamosan futó szálak egy számítógépen belül és hálózaton keresztül is képesek
kommunikálni egymással, bármilyen erőforrást használhatnak, legyenek az akár helyi, akár
hálózaton keresztül elérhető távoli számítógépen
● QNX hálózat tekinthető egy komplex rendszernek széles körű, de egyszerűen használható
szolgáltatásokkal
25. Ismertesse a QNX Inter Process Communication lehetőségeit!
A folyamatok közötti rugalmas kommunikáció (IPC) lényege:

● Message-passing – Szinkron üzenettovábbítás:

○ Az üzenetek adatcserét biztosítanak különböző szálak
között és szinkronizálják is azokat, Kernel szolgáltatás.
○ küldő a kliens, fogadó a szerver
○ használható beolvasásra pl. soros port
○ Az üzenet memória tartalom kezdőcímmel és
hosszúsággal
○ A küldendő adatot közvetlenül a küldő memóriájából
a címzett memóriájába kerül
○ A kommunikáció szinte a memóriakezelés
sebességével zajlik
○ lépések:
■ kliens küld egy üzenetet (MsgSend()), ilyenkor
a kliens blokkolt állapotba kerül mindaddig,
amíg a választ meg nem kapja
■ a szerver fogadja az üzeneteket
(MsgReceive()) és válaszol rá (MsgReply()), a
szerver akkor kerülhet blokkolt állapotba, ha
üzenet érkezésére várakozik
● Signals – Jelek (Kernel szolgáltatás):
○ Lehetnek hagyományos (POSIX UNIXra jellemző) és valós idejű jelek
○ Szoftveres jellegű megszakításokra hasonlít, rendszerhibajelzések ilyenek például memória
megsértés.
■ Kezelés:
1. Figyelmen kívül hagyás: szál definiálhatja, hogy a kevésbé fontos jeleket
figyelmen kívül hagyhatja.
2. Kezelőfüggvény hozzákapcsolásával. A kernel közvetlenül hívja meg a
kezelőfüggvényeket, környezetre oda kell figyelni.
3. Terminálás: a process futását befejezi a rendszer, legtöbbször alapértelmezés
vagy hiba esetén az alapvető működés
● POSIX üzenet sorok (Külső folyamat szolgáltatása):
○ Nem a kernel része külön folyamat végzi a kezelést
○ Az MQUEUE (erőforrás kezelő) vagy MQ (alternatív megoldás) folyamatokat külön el kell
indítani, h rendelkezésre álljon a szolgáltatás
○ az üzenetsorok névvel rendelkeznek, állományrendszerek névterén elérhetőek
● Shared memory – Osztott memória (Process Manager szolgáltatás):
○ Egy csomóponton egy eszközön belül osztott memória használható, ez a legnagyobb
sávszélességű.
○ Érvényes területre kerülnek írásra és olvasásra az információk
○ A hozzáféréseket fontos szinkronizálni
● Pipes – Csővezetékek (Külső folyamat szolgáltatása):
○ I/O csatornaként használhatók folyamatok között
 ○ Shell használja a csővezetékeket, több parancsból álló összetett funkciók megvalósítására
○ egyirányú adatcsere
● FIFO-k (Külső folyamat szolgáltatása):
○ Név alapú azonosítás és névtérben elérhetőség