Budapesti Műszaki és Gazdaságtudományi Egyetem. Villamosmérnöki és Informatikai Kar. TDK dolgozat. Hajnal Erik pit6dc. Konzulens: BME-HVT

Budapesti M˝ uszaki ´ es Gazdas´ agtudom´ anyi Egyetem Villamosm´ ern¨ oki ´ es Informatikai Kar

Sz´ eless´ av´ u H´ırk¨ ozl´ es ´ es Villamos´ agtan Tansz´ ek

TDK dolgozat Szoftverteljes´ıtm´ eny ´ es optimaliz´ aci´ o vizsg´ alata kernel m´ od´ u eszk¨ ozkezel˝ o programmal

Kész´ıtette: Hajnal Erik pit6dc

Konzulens: dr. Csurgai-Horv´ ath L´ aszl´ o BME-HVT

Budapest 2012.

Tartalomjegyz´ ek 1 Bevezet´ es 1.1 A dolgozat tém´ aj´ anak, céljának ismertetése . . . . . . . . . . . . 1.2 A mérési k¨ or¨ ulmények rövid ismertetése . . . . . . . . . . . . . .

2 2 3

2 A m´ er´ esek el˝ ok´ esz´ıt´ ese 2.1 Kernel m´ od´ u programozás - áttekintés . . . . 2.2 A driverfejlesztés alapjai, legfontosabb lépései 2.2.1 A driver szolg´ altatás elkész´ıtése . . . . 2.2.2 A driver-le´ır´ o .inf fájlok . . . . . . . . 2.2.3 Az eszk¨ ozilleszt˝ok digitális alá´ırása . . 2.3 A k´ artya API-j´ anak bemutatása . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

6 6 6 7 18 21 21

3 A m´ er´ esek bemutat´ asa 3.1 A tesztprogramok . . . . . . . . . . . . . . . 3.1.1 A keretprogram . . . . . . . . . . . . 3.1.2 ArrayCopy . . . . . . . . . . . . . . 3.1.3 Parallel . . . . . . . . . . . . . . . . 3.1.4 Abstraction . . . . . . . . . . . . . . 3.1.5 Fibonacci . . . . . . . . . . . . . . . 3.1.6 StringCPP11 . . . . . . . . . . . . . 3.2 Mérések az alapbe´ all´ıtással . . . . . . . . . 3.3 A célplatform . . . . . . . . . . . . . . . . . 3.4 Pufferes biztons´ agi ellen˝orzések kikapcsolása 3.5 Az architekt´ ura specifikálása . . . . . . . . 3.6 P´ arhuzamos k´ odgenerálás . . . . . . . . . . 3.7 A C++11 és a mozgató konstruktorok . . . 3.8 A GCC ford´ıt´ oval elért eredmények . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

27 27 27 28 29 29 29 30 31 32 34 35 36 38 43

¨ 4 Osszefoglal´ as

. . . . . . . . . . . . . .

45

1

1 1.1

Bevezet´ es A dolgozat t´ em´ aj´ anak, c´ elj´ anak ismertet´ ese

A mai vil´ agunkban teljesen természetes, hogy a szoftverfejleszt˝ok a szoftvereket magas szint˝ u programozási nyelvek és vizuális fejleszt˝oeszközök seg´ıtségével kész´ıtik. Azonban ehhez a mögöttes technológia, a magas nyelv˝ u programokat futtat´ o alacsony szint˝ u keretrendszerek magas fok´ u optimaliz´ alts´ aga sz¨ ukséges – vagy nagyon er˝os hardver. Rengeteg apróbb alkalmaz´ asn´ al szinte észrevehetetlen a k¨ ulönbség egy alacsony és egy magas szint˝ u nyelv seg´ıtségével kész´ıtett program között a mai rendk´ıv¨ ul gyors hardvereknek k¨ osz¨ onhet˝ oen. Viszont a teljes´ıtményigényes alkalmazásoknál, amiket az imént eml´ıtett technológiák seg´ıtségével manapság nagyon gyorsan el lehet kész´ıteni, sokszor tapasztalhatunk problémákat a sebességgel. Ezen dolgozat alapvet˝ o kérdése az, hogy valóban nyugodt sz´ıvvel felejthetj¨ uk el a k¨ ul¨ onb¨ oz˝ o optimaliz´ aci´ os lehet˝oségeket és b´ızhatunk mindent a ford´ıtónkra vagy esetleg vannak-e bizonyos lehet˝oségeink, amelyek akár u ´jak (például az u ´j C++11 szabv´ any), ak´ ar régiek, ám mára kiszorultak a fókuszból (például a ford´ıt´ asi kapcsol´ ok). Azonban adja mag´ at a kérdés: elég ”okosak” a ford´ıtóink? Valóban ki tudnak tal´ alni magukt´ ol mindent? Vagy lehet hogy érdemes lenne bizonyos be´ all´ıt´ asokat manu´ alisan elvégezni, ami esetleg jav´ıthatna az alkalmazásaink teljes´ıtményén? Természetesen a szoftverfejlesztés átalakulásának folyamatát meg´ all´ıtani nem lehet, a célunk sokkal inkább pár olyan még / már kevésbé ismert lehet˝ oség megvizsg´ al´ asa, amelyekkel az alkalmazásaink teljes´ıtményét lehetne jav´ıtani. A szoftver eszk¨ oz¨ ok min˝os´ıtését szám´ıtógép-hardverrel támogatott mérésekkel k´ıv´ anjuk elvégezni. Ehhez egy, az RTD-USA által kész´ıtett DM7520 t´ıpus´ u, PCI buszra illeszked˝o mérés-adatgy˝ ujt˝o kártyát használunk fel, amelyhez saj´ at illeszt˝ oprogram is kész¨ ult a nagyobb flexibilitás érdekében. Ez´ altal a szoftver fut´ asi teljes´ıtményét egzakt módon, a hardver k¨ uls˝o portjain kiadott impulzusok m˝ uszeres mérésével fogjuk elvégezni. Egy ilyen tém´ aban nagyon nehéz teljes kör˝ u, minden platform fejleszt˝ oeszk¨ oz p´ aros´ıt´ ast megvizsgálni, ezért a mi választásunk a Windows 7 (x64) platformra és a Visual Studio leg´ ujabb, 2012-es változatára esett. Emellett egy-egy r¨ ovid ¨ osszehasonl´ıtás kedvéért a GCC által el˝oáll´ıtott kódot is megvizsg´ altuk, ´ am ezzel nem foglalkoztunk részleteiben. A dolgozat eredményei seg´ıthetnek mélyebben megérteni a programfejlesztési eszk¨ oz¨ ok beáll´ıtásainak hatásait, valamint az optimalizációs lehet˝ oségek kihaszn´ alhat´ os´ ag´ at. A dolgozat két nagyobb részre bontható: az els˝o részben a mérésekhez vezet˝o u ´t bemutat´ asa tal´ alhat´ o. Egy áttekintés a kernel-mód´ u programozásról, annak el˝ onyeir˝ ol és h´ atr´ anyair´ ol, a driverfejlesztésr˝ol, a mérés menetér˝ol. A m´ asodik rész k¨ ul¨ onb¨ oz˝o lehet˝oségeket próbál feltárni a performancia n¨ ovelése érdekében. G´ orcs˝ o alá ker¨ ul a Windows prioritáskezelése, k¨ ulönböz˝o kevésbé ismert, keveset használt ford´ıtási kapcsoló, és a C++ világ leg´ ujabb a´tt¨ orése, a C++11 szabv´ any ny´ ujtotta optimalizációs lehet˝oségek is.

2

1.2

A m´ er´ esi k¨ or¨ ulm´ enyek r¨ ovid ismertet´ ese

Mivel a mérések sor´ an pont a nagyon apró, ám mégis jelen lév˝o sebességk¨ ul¨ onbségeket szeretném kimutatni, a Windows által biztos´ıtott szoftveres id˝ omérés pontoss´ aga nem elegend˝o. Ezért a mérésekhez egy data acquisition (mérés-adatgy˝ ujt˝ o) kártyát használunk, amelyhez egy - kifejezetten erre a célra - ´ altalunk fejlesztett illeszt˝oprogramot használunk. A k´ artya egy, a RealTime Devices Inc. által kész´ıtett DM7520-as t´ıpus´ u mérés-adatgy˝ ujt˝ o k´ artya. Ez egy PC/104 formátum´ u eszköz, amelyet azért v´ alasztottunk a mérések elvégzésére, mert mind a hardver, mind a szoftver dokument´ aci´ oja rendelkezés¨ unkre állt, ami nélk¨ ulözhetetlen volt a kés˝obb ismertetésre ker¨ ul˝ o saj´ at kernel-mód´ u driver meg´ırásához. Mivel a kártyát asztali sz´ am´ıt´ ogépben haszn´ altuk, egy PCI-PC/104 konverter seg´ıtségével helyezt¨ uk be az asztali gépbe. A mérés-adatgy˝ ujt˝o kártya ki/bemenetei egy I/O termin´ al k´ arty´ an kereszt¨ ul érhet˝ok el, amelyre már tetsz˝oleges k¨ uls˝o mér˝ oeszk¨ oz csatlakoztathat´ o. Az 1. ábrán látható a DM7520 kártya a PCI konvertermodulra szerelve, továbbá a hozzá csatlakoztatott I/O modul.

1. ´ abra A mérés-adatgy˝ ujt˝ o kártya PCI konverterrel és terminál-kártyával

A DM7520 egy univerz´ alis, PCI buszra illesztett mérés-adatgy˝ ujt˝o eszköz, amely anal´ og ki- és bemenetekkel rendelkezik, univerzális id˝oz´ıt˝o áramköröket tartalmaz, digit´ alis I/O portjai és még számos egyéb, általunk nem használt er˝ oforr´ asa van. A dolgozatban kit˝ uz¨ ott célok eléréséhez csupán a digitális I/O portok haszn´ alat´ ara volt sz¨ ukség, amelyeknek a korlátlan hozzáférését biztos´ıtja a kés˝ obbiekben ismertetésre ker¨ ul˝o eszközmeghajtó szoftver. A k´ artya digit´ alis I/O modulja két, egyenként nyolc bites csatornát biztos´ıt sz´ amunkra, ami a méréseinkben kulcsszerepet tölt be. Ezek a portok a PCI 3

interfészen kereszt¨ ul mem´ oriába ágyazott eszközként érhet˝ok el, és kimenetként programozva logikai 1 vagy 0 érték ´ırható ki rájuk. A logikai jel porton t¨ ortén˝ o megjelenését a kártya hardver felép´ıtése csak minimális mértékben korl´ atozza, éppen a memóriába ágyazott m˝ uködés miatt. A PCI busz arbitr´ aci´ oja ugyanakkor nagyobb mérték˝ u, ráadásul el˝ore nem kisz´ am´ıthat´ o késleltetést visz be a rendszerbe, de ennek az ideje is nagys´ agrendekkel kisebb, mint a tesztelni k´ıvánt szoftverek futási idejei. Mindazon´ altal a teszthardver az alaplapi vezérl˝okön k´ıv¨ ul semmilyen egyéb PCI eszk¨ ozt nem tartalmazott, hogy az ebb˝ol adódó mérési hibákat kik¨ usz¨ ob¨ olhess¨ uk. A hardveres id˝ omérés menete a következ˝o: A kártyához egy I/O egységet kapcsolunk, amelynek az egyik kimenetét rákötj¨ uk egy oszcilloszkópra. A mérend˝ o tartom´ anyba val´ o belépéskor és annak elhagyásakor a kimeneten megjelen´ıt¨ unk egy impulzust, majd a két impulzus közötti távolságot leolvasva megkapjuk a mérni k´ıv´ ant id˝ot. Természetesen az impulzus kiadása és az aktu´ alis algoritmus k¨ oz¨ ott még eltelik egy kevés id˝o am´ıg az irány´ıtás visszaker¨ ul a driverb˝ ol a mér˝oprogramba, azonban ezt az id˝ot is le tudjuk mérni és ez´ altal pontos´ıtani a mérés¨ unket.

2. ´ abra - Egy mérés kinézete Az 1. ´ abr´ an egy konkrét mérésnek a megjelenését látjuk az oszcilloszkópon. Az els˝ o impulzus az el˝ oz˝ o mérés végét jelzi (a mérések ciklusban futnak, ´ıgy k¨ onnyebben mérhet˝ oek a kontextusváltásból származó késleltetések). A m´ asodik impulzus jelzi az aktuális mérés kezdetét, az utolsó pedig a mérés végét. A ciklusban fut´ o méréseket a 2. ábrán látható módon gy˝ ujtj¨ uk össze.

4

3. ´ abra - A mérések összegy˝ ujtése Itt m´ ar nem l´ atszik a mérések közötti nanoszekundumos sz¨ unet, azonban milliszekundumban mérhet˝ o értékeknél ez elhanyagolható mérési hiba. Az oszcilloszk´ op id˝ otartom´ any´ anak megfelel˝o mérték˝ u növelésével elérj¨ uk, hogy 5-10 mérést l´ assunk egyszerre, majd a mért id˝ok átlagolásával meghatározzuk a végs˝ o id˝ ot.

5

2 2.1

A m´ er´ esek el˝ ok´ esz´ıt´ ese Kernel m´ od´ u programoz´ as - ´ attekint´ es

Miel˝ ott a k´ arty´ ahoz meg´ırt illeszt˝oprogramot bemutatnánk, ny´ ujtanánk egy r¨ ovid ´ attekintést a kernel m´ odban való programozásról, annak el˝onyeir˝ol és h´ atr´ anyair´ ol. Kernel m´ odban sokkal nagyobb a hatalma, és ezáltal a felel˝ossége is a programoz´ onak. [1] Nem lehet a ”trial-and-error” megközel´ıtést alkalmazni, ugyanis itt a ”Program m˝ uk¨ odése leállt” képerny˝o helyett minden apró hiba STOP hib´ ahoz (ismertebb nevein: kék halál, Blue Screen of Death) vezet. Lok´ alis gépen dolgozva el kell felejteni a 21. századi debug eszközöket; még egy hibak´ odot sem lehet ki´ırni a képerny˝ore, hiszen a STOP hiba azonnal megjelenik. A debug eszk¨ oz¨ okh¨ oz hasonlóan b´ ucs´ ut kell inteni a CRT-nek (C RunTime), amelyet alapb´ ol minden felhasználói-mód´ u program használ, ugyanis alapból a main, illetve WinMain f¨ uggvényeinket a CRT h´ıvja meg. A CRT ´ altal biztos´ıtott, széles körben ismert és használt f¨ uggvények és oszt´ alyok (printf, fopen, cout, vector, list, stb.) bár közvetlen¨ ul nem elérhet˝oek kernel-m´ odb´ ol, rengetek CRT-beli f¨ uggvény el˝obb-utóbb egy kernel-mód´ u API h´ıv´ asként végzi, ´ıgy sokszor elegend˝o némi kutatás a megoldáshoz. Például a printf f¨ uggvény kernel-m´ od´ u megfelel˝oje a DbgPrint f¨ uggvény, még a paraméterei is ugyanazok (minimális k¨ ulönbségekkel). A Windows programoz´ asban jártas emberek által ismert Windows API sem elérhet˝ o, azonban ezen h´ıv´ asok két részre oszthatóak. Az els˝o csoport olyan h´ıv´ asokat tartalmaz, amelyek azonnal, vagy minimális ellen˝orzéseket követ˝oen tov´ abb´ıtja a h´ıv´ ast a kernelbe. Ezeket a f¨ uggvényeket a printf -hez hasonlóan lehet haszn´ alni. Ebbe a csoportba tartoznak például a fájlokkal kapcsolatos f¨ uggvények. A m´ asodik csoportban olyan f¨ uggvények találhatóak, amelyek a kernel-mód´ u fejlesztésnél irrelev´ ansak. Ilyen például a multimédiával vagy az ablakokkal kapcsolatos h´ıv´ asok. Ezen funkciókra kernel-módban egyszer˝ uen nincs sz¨ ukség, ´ıgy nagy rész¨ uknek nincs is kernel-mód béli megfelel˝oj¨ uk. A legnagyobb API, ami a rendelkezés¨ unkre áll, az az u ´gynevezett Native API, ami a Windows API (r¨ oviden WINAPI) alatt helyezkedik el. A Native API-ban rengeteg alul-dokumentált vagy egyáltalán nem dokumentált f¨ uggvény tal´ alhat´ o, ami tov´ abb nehez´ıti a kernel-mód´ u fejlesztést.

2.2

A driverfejleszt´ es alapjai, legfontosabb l´ ep´ esei

A driverfejesztés sokrét˝ u feladat. Meg kell valós´ıtani a hardver és a Windows k¨ oz¨ otti kommunik´ aci´ ot, amihez a hardver részletesebb ismerete sz¨ ukséges. Implement´ alni kell az eszk¨ oz m˝ uködéséhez és kezeléséhez sz¨ ukséges logikát, egyfajta bels˝ o f¨ uggvénycsoportot. Létre kell hozni egy API-t, aminek seg´ıtségével a felhaszn´ al´ oi-m´ od´ u programok kommunikálhatnak a driverrel. Sz¨ ukség van tov´ abb´ a a drivernek a ”le´ırására”, egy .inf fájlra, amely seg´ıtségével a Windows tudja, hogy pontosan mit is tartalmaz az illeszt˝ oprogram. Ezen fel¨ ul egy felhasználói mód´ u API-t is érdemes kész´ıteni, ugyanis felhaszn´ al´ oi-m´ odb´ ol a kernel-mód´ u API-nkat csak a DeviceIoControl

6

nev˝ u f¨ uggvényen kereszt¨ ul érhetj¨ uk el, ami semminem˝ u kényelmet illetve valid´ aci´ ot nem biztos´ıt. 2.2.1

A driver szolg´ altat´ as elk´ esz´ıt´ ese

Az illeszt˝ oprogramok a Windows számára service-ekként, magyarul szolg´ altat´ asokként jelennek meg. Az elkész¨ ult driver a legminimalisztikusabb esetben két f´ ajlként jelenik meg. Lesz egy .inf fájlunk, ami le´ırja az illeszt˝ oprogramot, a m´ asik pedig egy .sys fájl, ami a futtatható kódot tartalmazza. Ez a rész a .sys fájl elkész´ıtésébe ny´ ujt betekintést. A Native API-ra ép¨ ul˝ o alkalmazások, ´ıgy az illeszt˝oprogramok belépési pontja is alapértelmezés szerint a DriverEntry f¨ uggvény, melynek szignat´ urája a k¨ ovetkez˝ o: 1 NTSTATUS D r i v e r E n t r y (PDRIVER OBJECT p D r i v e r O b j e c t , PUNICODE STRING pRegistryPath )

Ehelyett azonban a legt¨ obb helyen ezt lehet látni: 1 extern ”C” NTSTATUS D r i v e r E n t r y (PDRIVER OBJECT p D r i v e r O b j e c t , PUNICODE STRING p R e g i s t r y P a t h )

Ennek az oka az, hogy a drivereket k¨ ulön ford´ıtóprogramokkal kell leford´ıtani, amelyek viszont alapból C nyelven várják a forráskódot. Azonban a C++ ny´ ujtotta rugalmass´ ag (például a változók ”akárhol” megengedett deklar´ aci´ oja) miatt rendszerint mégis C++ lesz a választott nyelv, ebben az esetben azonban gondoskodni kell róla, hogy a DriverEntry f¨ uggvény C f¨ uggvénynek megfelel˝ o dekor´ acióval ker¨ uljön bele a .sys fájlba. Az els˝ o paraméter a driver¨ unk viselkedését szabályozó DRIVER OBJECT strukt´ ur´ ara egy mutat´ o, a második pedig a driver¨ unk registry kulcsához az elérési u ´t. A DriverEntry f¨ uggvény feladata összekapcsolni a Windows-t a driverrel. A DriverEntry fut´ asakor az illeszt˝oprogramunk még nem m˝ uködésre kész, hanem pont ekkor kész¨ ul az indulásra, ebben hivatott a DriverEntry seg´ıt˝o kezet ny´ ujtani a Windows sz´ amára. A visszatérési érték egy NTSTATUS, ami longként van definiálva, ezen kereszt¨ ul tudjuk jelezni a m˝ uveleteink sikerességét. A mi konkrét DriverEntry-nk a következ˝oképpen néz ki: 1 extern ”C” NTSTATUS D r i v e r E n t r y (PDRIVER OBJECT p D r i v e r O b j e c t , PUNICODE STRING p R e g i s t r y P a t h ) 2 { 3 p D r i v e r O b j e c t −>D r i v e r U n l o a d = DM7520 DriverUnload ; 4 p D r i v e r O b j e c t −>D r i v e r E x t e n s i o n −>AddDevice = DM7520 AddDevice ; 5 p D r i v e r O b j e c t −>MajorFunction [ IRP MJ PNP ] = DM7520 PnP ; 6 p D r i v e r O b j e c t −>MajorFunction [ IRP MJ CLOSE ] = DM7520 Close ; 7 p D r i v e r O b j e c t −>MajorFunction [ IRP MJ CREATE]= DM7520 Create ; 8 p D r i v e r O b j e c t −>MajorFunction [ IRP MJ DEVICE CONTROL ] = DM7520 DeviceControl ; 9 return STATUS SUCCESS ; 10 }

Ahogy az a k´ odb´ ol is látható, a PDRIVER OBJECT strukt´ ura f¨ uggvénymutat´ okon kereszt¨ ul éri el az illeszt˝oprogramunk funkcióit. A 7

DriverUnload a driver rendszerb˝ol való eltávol´ıtásakor ker¨ ul megh´ıvásra, ennek felel˝ ossége minden az egész drivernek (nem csak egy-egy konkrét funkciójának) lefoglalt er˝ oforr´ as felszabad´ıt´ asa. Az AddDevice h´ıv´ as felel azért, hogy amikor egy u ´j, a mi driver¨ unk által kezelt eszk¨ ozt csatlakoztatnak a szám´ıtógéphez, az eszköz megfelel˝oen fel legyen telep´ıtve. A MajorFunction t¨ omb felel a kártya f˝obb funkcióinak implementációjáért, ezekr˝ ol kés˝ obb lesz sz´ o. A STATUS SUCCESS, ami 0-ként van definiálva jelzi az általános sikert. Amikor a DriverEntry visszatér, a szolgáltatásunk természetesen nem áll le, hanem pont hogy ilyenkor ´ all készen a k¨ ulönböz˝o h´ıvások fogadására. A k¨ ovetkez˝ o lépés felkész´ıteni a drivert arra, hogy az eszközt behelyezik a rendszerbe, ezért felel az AddDevice f¨ uggvény, amely a mi eset¨ unkben a k¨ ovetkez˝ oképpen néz ki: 1 NTSTATUS DM7520 AddDevice (PDRIVER OBJECT p D r i v e r O b j e c t , PDEVICE OBJECT pdo ) { 2 PDEVICE OBJECT f d o ; 3 NTSTATUS s t a t u s = I o C r e a t e D e v i c e ( p D r i v e r O b j e c t , s i z e o f ( DEVICE EXTENSION) , NULL, FILE DEVICE UNKNOWN, FILE DEVICE SECURE OPEN , FALSE, &f d o ) ; 4 DEVICE EXTENSION∗ pdx = (DEVICE EXTENSION∗ ) fdo−>D e v i c e E x t e n s i o n ; 5 i f ( ! NT SUCCESS( s t a t u s ) ) { 6 return s t a t u s ; 7 } 8 pdx−>l o w e r D e v i c e O b j e c t = I o A t t a c h D e v i c e T o D e v i c e S t a c k ( fdo , pdo ) ; 9 i f ( ! pdx−>l o w e r D e v i c e O b j e c t ) 10 { 11 IoDeleteDevice ( fdo ) ; 12 return s t a t u s ; 13 } 14 fdo−>F l a g s |= DO POWER PAGABLE; 15 fdo−>F l a g s |= DO BUFFERED IO ; 16 fdo−>F l a g s &= ˜DO DEVICE INITIALIZING ; 17 s t a t u s = I o R e g i s t e r D e v i c e I n t e r f a c e ( pdo , &DM7520 GUID , NULL, &pdx −>i f n a m e ) ; 18 i f ( ! NT SUCCESS( s t a t u s ) ) 19 { 20 i f ( ! pdx−>i f n a m e . B u f f e r ) 21 { 22 R t l F r e e U n i c o d e S t r i n g (&pdx−>i f n a m e ) ; 23 } 24 I o D e t a c h D e v i c e ( pdx−>l o w e r D e v i c e O b j e c t ) ; 25 IoDeleteDevice ( fdo ) ; 26 return s t a t u s ; 27 } 28 s t a t u s = I o S e t D e v i c e I n t e r f a c e S t a t e (&pdx−>ifname , TRUE) ; 29 i f ( ! NT SUCCESS( s t a t u s ) ) 30 { 31 i f ( ! pdx−>i f n a m e . B u f f e r ) 32 { 33 R t l F r e e U n i c o d e S t r i n g (&pdx−>i f n a m e ) ; 34 } 35 I o D e t a c h D e v i c e ( pdx−>l o w e r D e v i c e O b j e c t ) ; 36 IoDeleteDevice ( fdo ) ; 37 return s t a t u s ; 38 } 39 return STATUS SUCCESS ; 40 }

8

Ez a kicsit testesebb f¨ uggvény egy nagyon kritikus illeszt˝ oprogramnak. A két kapott paraméter köz¨ ul az els˝o a asodik pedig egy PDEVICE OBJECT PDRIVER OBJECT, a m´ egy mutat´ o. Ezen mutat´ o mögött már az éppen behelyezett és k´ıv´ ant eszk¨ oz tal´ alhat´ o.

pontja az már ismert strukt´ urára konfigurálni

´ Erdemes még a konkrét implementáció el˝ott néhány szóban megeml´ıteni az u ń. driver stacket, ami tulajdonképpen a driverek absztrakciós rétegei. Legalul helyezkednek el az u ń. PDO-k, Physical Device Object, azaz maga a konkrét fizikai eszk¨ oz. Ez a réteg felel az eszközzel való legalapvet˝obb kommunik´ aci´ oj´ aért, mint például az adatok k¨ uldésének és fogadásának implement´ aci´ oja, vagy ak´ ar az áramellátás szabályozása. Ezzel a réteggel nek¨ unk nem sok dolgunk van, mivel a mi eszköz¨ unk egy teljesen szabványos PCI eszk¨ oz, a Windows alapértelmezett módszerei tökéletesen megfelelnek. Erre a szintre ép¨ ul a Filter Device Object, ami tulajdonképpen egy ”sz˝ ur˝o”, ez a réteg nem k¨ otelez˝ o egy illeszt˝oprogramhoz; itt k¨ ulönböz˝o cache-eléseket lehet péld´ aul megval´ os´ıtani. Az erre ép¨ ul˝o réteg az FDO, Function Device Object, ami tulajdonképpen a driver logikáját tartalmazza, itt van megvalós´ıtva a kernel-m´ od´ u API. Sz¨ ukség szerint az FDO-ra ép¨ ulhet még egy sz˝ ur˝oréteg, azonban n´ alunk erre nincs sz¨ ukség. A k´ odban megjelenik két rövid´ıtés két változónév formájában. Az fdo-ra a funkcionális illeszt˝oprogramunkat keresztelt PDEVICE OBJECT reprezent´ alja, ezért teljes mértékben mi vagyunk a felel˝osek. A pdo nev˝ u, szintén PDEVICE OBJECT t´ıpus´ u változónk pedig a fizikai eszközilleszt˝onkre mutat, ezt javarészt a Windows maga menedzseli. A f¨ uggvénybe val´ o belépéskor a PDO már létezik és készen áll arra, hogy r´ aép´ıts¨ unk a driver stack t¨ obbi részét. Els˝o lépésként létrehozzuk az alap FDOt (4). Ehhez csak p´ ar nagyon alapvet˝o paraméterre van sz¨ ukség¨ unk, mint az eszk¨ oz t´ıpusa, az ´ altalunk igényelt extra tárter¨ ulet, az u ń. device extension mérete, valamint minim´ alis biztonsággal kapcsolatos paraméterek. A DEVICE EXTENSION egy többé-kevésbé megszokott elnevezése annak az ´ altalunk defini´ alt strukt´ urának, ami egy az eszközhöz csatolt adatokat tartalmazza, ennek a tartalma minden eseteben a konkrét eszközön m´ ulik. A mi driver¨ unkben ez a strukt´ ura a következ˝oképpen van definiálva: 1 struct DEVICE EXTENSION 2 { 3 PDEVICE OBJECT l o w e r D e v i c e O b j e c t ; 4 UNICODE STRING i f n a m e ; 5 v o l a t i l e UCHAR∗ l a s 0 ; 6 v o l a t i l e UCHAR∗ l a s 1 ; 7 v o l a t i l e UCHAR∗ l c f g ; 8 };

A lowerDeviceObject az FDO alatt elhelyezked˝o rétegre mutat, ennek seg´ıtségével fogjuk tudni azt elérni. Az ifname (interface name) tartalma az eszk¨ oz¨ unk interfészének neve, amin kereszt¨ ul majd a felhasználói mód´ u programok elérik az eszk¨ ozt. A másik három mez˝o már a kártyánk konkrét felép´ıtését t¨ ukr¨ ozi, ez a h´ arom mutató a kártya három memóriater¨ uletére mutat, ezeken kereszt¨ ul fogunk majd tudni I/O m˝ uveleteket végezni. Az IoAttachDeviceToDeviceStack h´ıvás (10) seg´ıtségével tudjuk az FDO-t 9

csatlakoztatni a driver stackre, majd a visszakapott PDEVICE OBJECT -et, ami a k¨ ozvetlen¨ ul alattunk elhelyezked˝o rétegre mutat, elmentj¨ uk a unkbe. DEVICE EXTENSION -¨ Miut´ an létrehoztuk és csatlakoztattuk az FDO-t, természetesen konfigur´ alni is kell azt. A legfontosabb lépés a k¨ ulönféle flagek beáll´ıtása (16 18). H´ arom olyan csoportja van ezeknek a flageknek, amelyekre mindenféleképpen oda kell figyelni. Az els˝o az áramellátás. A ń. lapozható eszközilleszt˝ok jele. Ez annyit DO POWER PAGABLE flag az u jelent, hogy sz¨ ukség esetén a Windows kilapozhatja a driver¨ unket a mem´ ori´ ab´ ol, ami csak a sz´ am´ıtógép m˝ uködéséhez kritikus eszközök esetében jelentene problém´ at. Senki nem szeretne arra várni, hogy a videokártya drivere visszaker¨ ulj¨ on a memóriába, ám egy mérés-adatgy˝ ujt˝o kártya megnyit´ asakor ez nem jelent gondot. A m´ asodik be´ all´ıtand´ o flag az input/output módját szabályozza. Egy eszk¨ oznek h´ arom k¨ ul¨ onféle lehet˝osége van az I/O m˝ uveleteinek ul˝o belebonyol´ıt´ as´ ara. Az els˝ o a DO BUFFERED IO, ami a pufferen kereszt¨ és kimenetet jelenti. Ebben az esetben az eszköz és a driver közé a Windows automatikusan létrehoz egy puffert, amit ˝o maga kezel számunkra. A második lehet˝ oség a a DO DIRECT IO, ami a DMA használatával ”közvetlen” utat biztos´ıt a k´ artya és a driver közé az adatok számára. A harmadik beáll´ıtás, ami egyben az alapértelmezett is, az u ´gynevezett ”Neither” (egyik sem) megold´ as. Ebben az esetben a driver csak egy forrás és egy cél c´ımet lát és neki kell megoldania a m´ asol´ ast. Azonban ez nagyon kör¨ ulményes, lévén hogy a két c´ım teljesen m´ as kontextusban van (jó eséllyel a cél egy kernel-mód´ u c´ım a mi driver¨ unkben, a forr´ as azonban szinte biztosan nem, hiszen mi egy FDO-ban vagyunk), pontosan emiatt ezt a megoldást nagyon ritkán haszn´ alj´ ak FDO-kban. A v´ alasztás azért esett a pufferelt megoldásra, mert sokkal kisebb az overhead az adatok mozgatásakor, mint a DMA-s megoldás esetén, az adataink alacsony mérete (1-1 bájtot k¨ uld¨ unk egyszerre), miatt pedig a DMA am´ ugy sem ny´ ujtana semmi el˝onyt. Az utols´ o flag, ami nélk¨ ulözhetetlen, az a DO DEVICE INITIALIZING. Ez a flag alapb´ ol be van ´ all´ıtva, és am´ıg ezt ki nem törölj¨ uk, az eszközt nem lehet elind´ıtani, ugyanis ez a flag jelzi, hogy az eszköz még konfiguráció alatt all. A pontoss´ ´ ag kedvéért érdemes megjegyezni, hogy az, hogy ezt a flaget az AddDevice f¨ uggvény k¨ ozepén törölj¨ uk, nem jelenti azt, hogy az eszközt azonnal el lehetne ind´ıtani, miel˝ ott a f¨ uggvény többi része lefutna; az eszköz elind´ıtása csak az AddDevice f¨ uggvény lefutása után lehetséges. K¨ ovetkez˝ o lépésként létrehozunk az eszköz¨ unknek egy interfészt (19), illetve ahhoz egy nevet. Ezen a néven kereszt¨ ul lehet elérni az interfészt, amin kereszt¨ ul pedig a k´ arty´ aval való interakció lehetséges. Ezt az interfészt hozzá kell rendeln¨ unk egy konkrét PDO-hoz, valamint sz¨ ukség van egy GUID-ra is, ami a mi eszk¨ oz¨ unket azonos´ıtja. A DM7520 GUID nálunk egy egyszer˝ u konstans GUID, amit a Visual Studio beép´ıtett GUID generátorával kész´ıtett¨ unk. Nem elég azonban regisztrálni egy interfészt, k¨ ulön lépésként engedélyezni is kell azt (30). Amennyiben minden j´ ol ment, nincs más dolgunk mint jelezni az eszköz hozz´ aad´ as´ anak sikerét a STATUS SUCCESS értékkel való visszatéréssel (41). A val´ o életben természetesen messze nem megy minden problémák nélk¨ ul, ´ıgy tekints¨ uk ´ at r¨ oviden a WDK által biztos´ıtott hibakezelési lehet˝oségeket. 10

A driverfejlesztéshez használt WDK f¨ uggvények nagy többsége egy, már eml´ıtett, NTSTATUS -t ad vissza, ezzel jelezve a m˝ uvelet eredményét. A WDK-ban haszn´ alt konvenci´ o szerint a negat´ıv értékek hibát, a nulla és a pozit´ıv értékek pedig sikert jeleznek. Azonban a konkrét értékek jelentésének ismerete nélk¨ ul, az NT SUCCESS makró seg´ıtségével egy boolként tekinthet¨ unk az adott st´ atuszra. Minden egyes rendszerh´ıv´ as után célszer˝ u ellen˝orizni, annak sikerességét. Hiba esetén minden félkész konfigurációt vissza kell vonni. Ezek ut´ an biztos´ıtanunk kell a kártyának a legalapvet˝obb m˝ uveleteket, ilyen péld´ aul a k´ artya megnyit´ asa és bezárása. Ehhez azonban tudni kell, hogy hogyan m˝ uk¨ odnek a kernelben az u ¨zenetek. A k¨ ulönböz˝o kéréseket u ¨zenetek formájában kapj´ ak meg a driverek, ezeknek a pontos neve IRP (Interrupt Request Packet), ezek tartalmazz´ ak a kérést, illetve a kéréssel kapcsolatos alapvet˝o információkat. Amikor egy driver egy adott kérést fogad, el kell döntenie mit k´ıván vele tenni. Egy egyszer˝ ubb illeszt˝oprogramban javarészt kétféle megoldásra van sz¨ ukség¨ unk. Az els˝ o a kérésnek a teljes´ıtése, ebben az esetben a mi driver¨ unk egy-az-egyben teljes´ıti a kérést: végrehajtja a kért m˝ uveletet, majd egy st´ atuszk´ odot mellékelve jelzi, hogy az adott kérés teljes´ıtve lett. A második gyakran haszn´ alt lehet˝ oség az u ´gynevezett ”Forward & Forget” nev˝ u módszer. Ebben az esetben mi nem kezelj¨ uk az adott kérést csupán tovább´ıtjuk másnak. Ut´ obbira tipikus péld´ ak a k¨ ulönböz˝o áramellátással kapcsolatos kérések, ahol egy FDO-nak rendszerint semmi dolga nincs (esetleg a kártya alaphelyzetbe a´ll´ıt´ asa), azonban az als´ obb, fizikai eszközökkel foglalkozó rétegnek igen jelent˝ os munk´ ajuk van. A kérések teljes´ıtése pedig a k¨ ulönböz˝o I/O m˝ uveleteknél j¨ on el˝ o leggyakrabban, hiszen a Windows nem tudhatja, hogy a mem´ ori´ ab´ ol pontosan melyik c´ımre is kéne ker¨ ulnie az adatoknak, ennek a meg´ allap´ıt´ as´ aért m´ ar az eszk¨ ozilleszt˝o a felel˝os. Anélk¨ ul, hogy minden f¨ uggvényt részleteznénk, a két eljárást használó egyegy f¨ uggvényt bemutatunk: 1 NTSTATUS DM7520 PnP StopDevice (PDEVICE OBJECT fdo , PIRP p i r p ) 2 { 3 p i r p −>I o S t a t u s . S t a t u s = STATUS SUCCESS ; 4 I o S k i p C u r r e n t I r p S t a c k L o c a t i o n ( p i r p ) ; // Forward and F o r g e t 5 DEVICE EXTENSION∗ pdx = (DEVICE EXTENSION∗ ) fdo−>D e v i c e E x t e n s i o n ; 6 return I o C a l l D r i v e r ( pdx−>l o w e r D e v i c e O b j e c t , p i r p ) ; 7 }

Az itt l´ athat´ o f¨ uggvény a kártyánk megáll´ıtásáért felel, ami például az eszk¨ oz szoftveres elt´ avol´ıt´ asakor jöhet el˝o. Kernel-mód´ u u ¨zenetkezel˝o f¨ uggvényekre j´ ol jellemz˝ o m´ odon egy NTSTATUS -szal fogjuk jelezni a sikert. Paraméterként megkapjuk szokás szerint az FDO-t, valamint a már eml´ıtett IRP-re egy mutat´ ot. A st´ atuszt a m´ ar megszokott módon alapból jóhiszem˝ uen STATUS SUCCESS -re all´ıtjuk. ´ Ezután megh´ıvjuk az IoSkipCurrentIrpStackLocation f¨ uggvényt, amely annyit csinál, hogy az IRP-nket eggyel lejjebb k¨ uldi a driver stacken. Azonban az alattunk lév˝o drivert még meg is kell h´ıvni, amihez el˝oször is meg kell azt találni (5), majd az IoCallDriver h´ıv´ assal delegáljuk az - immáron jó helyen lév˝o - kérés¨ unket az alattunk elhelyezked˝ o driver-réteg felé. 11

A k¨ ovetkez˝ o k´ odrészlet pedig egy kérés teljes´ıtését mutatja be: 1 NTSTATUS DM7520 Create (PDEVICE OBJECT fdo , PIRP p i r p ) 2 { 3 I oCom ple teR eque st ( p i r p , IO NO INCREMENT) ; 4 p i r p −>I o S t a t u s . S t a t u s = STATUS SUCCESS ; 5 return STATUS SUCCESS ; 6 }

Itt a kulcs lépés az IoCompleteRequest h´ıvás, amellyel jelezhetj¨ uk, hogy az adott kérést mi teljes mértékben teljes´ıtett¨ uk és az IRP-vel további munka nincs. Ennek megh´ıv´ asa el˝ ott van természetesen maga a kérést teljes´ıt˝o logika, amely jelen eset¨ unkben u ¨res, ugyanis itt a kártyát megnyitó kérést kezelj¨ uk, amelynek sor´ an azt kell biztos´ıtanunk, hogy a h´ıvó fél gond nélk¨ ul tudjon ´ırni és olvasni akar´ o kéréseket k¨ uldeni. Mivel az eszközilleszt˝ot saját célokra fejlesztett¨ uk, eltekintett¨ unk a k¨ ulönféle biztonsági óvintézkedésekt˝ol amelyeket itt lehetne tenni (pl. blokkolni hogy egyszerre többen is ´ırási engedéllyel rendelkezzenek). A f¨ uggvény második paraméterével a kérést eredetileg feladó sz´ alnak a priorit´ as´ at lehetne növelni (cserébe azért, hogy eddig a kérést teljes´ıtésére kellett v´ arnia), azonban mi ezzel nem k´ıvántunk élni. Mivel lényegében semmit nem csin´ altunk, ezért a státuszt gond nélk¨ ul áll´ıthatjuk unk vissza a f¨ uggvényb˝ol. STATUS SUCCESS -re, majd térhet¨ ´ Erdemes még k¨ ul¨ on sz´ ot ejteni a Plug and Play u ¨zenetekr˝ol. A k¨ ulönféle Plug and Play u ¨zeneteket (mint pl. a kártya behelyezése vagy eltávol´ıtása) egyszerre, egy f¨ uggvényben tudjuk kezelni (ld. a DriverEntry f¨ uggvény). 1 NTSTATUS DM7520 PnP (PDEVICE OBJECT fdo , PIRP p i r p ) 2 { 3 PIO STACK LOCATION s t a c k = I o G e t C u r r e n t I r p S t a c k L o c a t i o n ( p i r p ) ; 4 switch ( s t a c k −>MinorFunction ) 5 { 6 case IRP MN START DEVICE : return DM7520 PnP StartDevice ( fdo , pirp ) ; 7 case IRP MN REMOVE DEVICE : return DM7520 PnP RemoveDevice ( fdo , pirp ) ; 8 } 9 // D e f a u l t − ” Forward and F o r g e t ” 10 IoSkipCurrentIrpStackLocation ( pirp ) ; 11 DEVICE EXTENSION∗ pdx = (DEVICE EXTENSION∗ ) fdo−>D e v i c e E x t e n s i o n ; 12 return I o C a l l D r i v e r ( pdx−>l o w e r D e v i c e O b j e c t , p i r p ) ; 13 }

Ez a f¨ uggvény fogadja az összes Plug and Play u ¨zenetet, majd sz¨ ukség szerint deleg´ alja az u ¨zeneteket további f¨ uggvényeknek. Az eddigi kezel˝o f¨ uggvényeinkben mindig pontosan tudtuk, hogy milyen u ¨zenettel van dolgunk, ezért sosem volt sz¨ ukség az IRP tartalmát vizsgálni, azonban itt már csak annyit tudunk, hogy valamilyen Plug and Play esemény történt. Az IRP tartalmazza a pontos eseményt is, ehhez azonban hozzá kell férn¨ unk az IRP-hez, amit az IoGetCurrentIrpStackLocation h´ıvással tudunk megtenni. Ezek ut´ an m´ ar meg tudjuk vizsgálni az u ń. Minor code-ját a kérésnek, amelyb˝ ol m´ ar kider¨ ul, hogy a PnP-en bel¨ ul pontosan mi is történt. A mi driver¨ unkben a PnP események köz¨ ul csak kett˝o érdekel, amikor elind´ıtj´ ak a k´ arty´ at, illetve amikor eltávol´ıtják azt a rendszerb˝ol, ´ıgy ezeket egy-egy k¨ ul¨ on f¨ uggvény kezeli. Minden egyéb PnP kérésre a már korábban bemutatott Forward & Forget megoldást alkalmazzuk. 12

Az eszk¨ oz elind´ıt´ asakor a DM7520 PnP StartDevice f¨ uggvényt h´ıvjuk meg, ez felel a k´ artya felkész´ıtéséért, hogy tudja fogadni a k¨ ulönböz˝o szoftver-eredet˝ u kéréseket (ilyen péld´ aul az ´ır´ as és az olvasás). A f¨ uggvény a következ˝oképpen néz ki: 1 NTSTATUS DM7520 PnP StartDevice (PDEVICE OBJECT fdo , PIRP p i r p ) 2 { 3 DEVICE EXTENSION∗ pdx = (DEVICE EXTENSION∗ ) fdo−>D e v i c e E x t e n s i o n ; 4 I o S e t D e v i c e I n t e r f a c e S t a t e (&pdx−>ifname , TRUE) ; 5 6 PIO STACK LOCATION s t a c k = I o G e t C u r r e n t I r p S t a c k L o c a t i o n ( p i r p ) ; 7 PCM PARTIAL RESOURCE LIST t r a n s l a t e d = &s t a c k −>P a r a m e t e r s . S t a r t D e v i c e . A l l o c a t e d R e s o u r c e s T r a n s l a t e d −>L i s t [ 0 ] . PartialResourceList ; 8 9 PCM PARTIAL RESOURCE DESCRIPTOR r e s o u r c e s = t r a n s l a t e d −> PartialDescriptors ; 10 ULONG count = t r a n s l a t e d −>Count ; 11 f o r (ULONG i = 0 ; i < count ; ++i ) 12 { 13 i f ( r e s o u r c e s [ i ] . Type == CmResourceTypeMemory ) 14 { 15 switch ( r e s o u r c e s [ i ] . u . Memory . Length ) 16 { 17 case 5 1 2 : // LAS0 18 pdx−>l a s 0 = ( v o l a t i l e UCHAR∗ ) MmMapIoSpace ( r e s o u r c e s [ i ] . u . Memory . S t a r t , 5 1 2 , MmNonCached) ; 19 break ; 20 case 2 5 6 : // LCFG 21 pdx−>l c f g = ( v o l a t i l e UCHAR∗ ) MmMapIoSpace ( r e s o u r c e s [ i ] . u . Memory . S t a r t , 2 5 6 , MmNonCached) ; 22 break ; 23 case 1 6 : // LAS1 24 pdx−>l a s 1 = ( v o l a t i l e UCHAR∗ ) MmMapIoSpace ( r e s o u r c e s [ i ] . u . Memory . S t a r t , 1 6 , MmNonCached) ; 25 break ; 26 } 27 } 28 } 29 30 p i r p −>I o S t a t u s . S t a t u s = STATUS SUCCESS ; 31 I oCom ple teR eque st ( p i r p , IO NO INCREMENT) ; 32 return STATUS SUCCESS ; 33 }

Els˝ o lépésként aktiv´ aljuk az AddDevice f¨ uggvényben már regisztrált interfész¨ unket (4). Ahogyan ott, itt sem kell attól tartanunk, hogy az engedélyezés és a StartDevice f¨ uggvény vége között valaki megpróbálja haszn´ alni a félkész k´ arty´ ankat, ugyanis az eszköz csak a f¨ uggvény visszatérése ut´ an sz´ am´ıt m˝ uk¨ odésre késznek. Ezek után a már látott módon hozzáfér¨ unk az IRP m¨ og¨ otti tartalomhoz (6), amelyb˝ol megszerezz¨ uk az eszköz¨ unk er˝ oforr´ asainak list´ ait (7). Ezek után a felismert er˝oforrásokon végigiterálva bemappelj¨ uk a k´ artya mem´ oriater¨ uleteit a szám´ıtógép memóriájába. A mi k´ arty´ ankon h´ arom, k¨ ul¨ onb¨ oz˝ o méret˝ u memóriater¨ ulet található (LAS0, LAS1 és LCFG), ´ıgy szerencsére a méret¨ uk ismeretében már egyértelm˝ uen tudjuk azonos´ıtani ˝ oket. Az MmMapIoSpace f¨ uggvény felel a mappelésért, amelynek egyszer˝ uen ´ at kell adni a mappelni k´ıvánt memóriater¨ uletre egy mutatót, annak hossz´ at, illetve hogy k´ıvánunk-e a gyors´ıtótárazással élni. Mivel mi nanoszekundumos sebességgel k´ıvánunk jeleket kiadni a kártyán, ´ıgy nem 13

él¨ unk ezzel a lehet˝ oséggel. A f¨ uggvény által visszaadott void* -t, amely a unk sz´ am´ıt´ ogép mem´ ori´ aj´ ara mutat, elmentj¨ uk a DEVICE EXTENSION -¨ megfelel˝ o részeibe, a b´ ajtonkénti elérés és a gyors´ıtótárazás elker¨ ulése érdekében volatile UCHAR* -re átalak´ıtva. Végezet¨ ul jelezz¨ uk a siker¨ unket és teljes´ıtj¨ uk a kérést. Az el˝ obb bemutat´ asra ker¨ ult, hogy miként foglaljuk le az er˝oforrásokat a k´ artya haszn´ alat´ ahoz, azonban az is nagyon fontos, hogy ezeket a megfelel˝o id˝ oben visszaadjuk a rendszernek. Ezért felel az alábbi f¨ uggvény: 1 NTSTATUS DM7520 PnP RemoveDevice (PDEVICE OBJECT fdo , PIRP p i r p ) 2 { 3 DEVICE EXTENSION∗ pdx = (DEVICE EXTENSION∗ ) fdo−>D e v i c e E x t e n s i o n ; 4 I o S e t D e v i c e I n t e r f a c e S t a t e (&pdx−>ifname , FALSE) ; 5 R t l F r e e U n i c o d e S t r i n g (&pdx−>i f n a m e ) ; 6 MmUnmapIoSpace ( (PVOID) pdx−>l a s 0 , 5 1 2 ) ; 7 MmUnmapIoSpace ( (PVOID) pdx−>l a s 1 , 16) ; 8 MmUnmapIoSpace ( (PVOID) pdx−>l c f g , 2 5 6 ) ; 9 10 p i r p −>I o S t a t u s . S t a t u s = STATUS SUCCESS ; 11 NTSTATUS s t a t u s = I o C a l l D r i v e r ( pdx−>l o w e r D e v i c e O b j e c t , p i r p ) ; 12 I o D e t a c h D e v i c e ( pdx−>l o w e r D e v i c e O b j e c t ) ; 13 IoDeleteDevice ( fdo ) ; 14 return s t a t u s ; 15 }

Ez a f¨ uggvény ker¨ ul megh´ıvásra, amikor az eszközt eltávol´ıtják a rendszerb˝ ol, legyen az ak´ ar fizikai eltávol´ıtás vagy szoftveres. Els˝o lépésként megsz¨ untetj¨ uk a k´ artya interfészének elérhet˝oségét, felszabad´ıtjuk az interfész nevének fenntartott mem´ oriát, valamint egyesével megsz¨ untetj¨ uk a mappeléseket mindh´ arom memóriater¨ uletre. Ezek után nem egyszer˝ uen teljes´ıtj¨ uk a kérést, hanem tovább k¨ uldj¨ uk az alsóbb rétegeknek, hiszen ha a k´ arty´ at fizikailag elt´ avol´ıtj´ ak a rendszerb˝ol, akkor arról a fizikai drivernek is tudnia kell. A Forward & Forget módszerrel ellentétben azonban most nem felejtj¨ uk el a kérést, hanem megvárjuk m´ıg az alattunk lév˝o rétegek elvégzik teend˝ oiket, majd ezek ut´ an leválasztjuk a driver¨ unket a driver stackr˝ol az IoDetachDevice h´ıv´ assal, valamint megsemmis´ıtj¨ uk a funkcionális driver¨ unket. Ezek a f¨ uggvények biztos´ıtják a kártyánk alapvet˝o m˝ uködéséhez az ”adminisztr´ aci´ ot”. B´ ar az eszköz¨ unk még egyáltalán nem funkcionális, de már gond nélk¨ ul be-ki lehet kapcsolni, illetve hozzá lehet adni és el lehet venni a rendszerb˝ ol. Mag´ aért a funkcionális m˝ uködésért a következ˝o f¨ uggvény felel:

14

1 NTSTATUS DM7520 DeviceControl (PDEVICE OBJECT fdo , PIRP p i r p ) 2 { 3 PIO STACK LOCATION s t a c k = I o G e t C u r r e n t I r p S t a c k L o c a t i o n ( p i r p ) ; 4 DEVICE EXTENSION∗ pdx = (DEVICE EXTENSION∗ ) fdo−>D e v i c e E x t e n s i o n ; 5 NTSTATUS s t a t u s = STATUS INVALID DEVICE REQUEST ; 6 p i r p −>I o S t a t u s . I n f o r m a t i o n = 0 ; 7 8 switch ( s t a c k −>P a r a m e t e r s . D e v i c e I o C o n t r o l . I o C o n t r o l C o d e ) 9 { 10 case DM7520 WRITE BUFFERED : 11 { 12 // . . . 13 break ; 14 } 15 case DM7520 READ BUFFERED : 16 { 17 // . . . 18 break ; 19 } 20 } 21 I oCom ple teR eque st ( p i r p , IO NO INCREMENT) ; 22 p i r p −>I o S t a t u s . S t a t u s = s t a t u s ; 23 return s t a t u s ; 24 }

A driver API-j´ anak bemutatásánál látni fogjuk, hogy az eszközzel való kommunik´ aci´ ohoz minden esetben a Windows API által biztos´ıtott DeviceIoControl f¨ uggvényt fogjuk használni. Ezek a f¨ uggvényh´ıvások jutnak el ´ kérések form´ aj´ aban a fent l´ atható f¨ uggvény¨ unkhöz. Altal´ anosságban ez a f¨ uggvény felel azért, hogy a kártyára specifikus funkcionális kéréseket fogadja és végrehajtsa. A mi eset¨ unkben csupán két funkciót definiáltunk a kártyához, az ´ır´ ast és az olvas´ ast. Kezdésként megszerezz¨ uk az IRP-hez tartozó inform´ aci´ okat és be´ all´ıtjuk a visszaadandó értékek alapértelmezéseit. Az information jelentése mindig az adott kérést˝ol f¨ ugg, ´ıgy a legegyszer˝ ubb ezt kezdetben lenull´ azni. A status kezdeti értékének a STATUS INVALID DEVICE REQUEST értéket választottuk, ezzel garant´ alva a megfelel˝ o hibajelzést amennyiben valaki egy érvénytelen kérést k¨ uld. Az IoControlCode tartalmazza a pontos kérést (mint a Plug and Play esetében a MinorCode), amelynek lehetséges értékeit mi definiáltuk a k¨ ovetkez˝ o m´ odon: 1 // IOCTL c o d e s 2 #define DM7520 WRITE BUFFERED \ 3 CTL CODE(FILE DEVICE UNKNOWN, 0 x800 , METHOD BUFFERED, FILE WRITE ACCESS) 4 #define DM7520 READ BUFFERED \ 5 CTL CODE(FILE DEVICE UNKNOWN, 0 x801 , METHOD BUFFERED, FILE READ ACCESS)

A CTL CODE egy speci´ alis makró, amely seg´ıtségével létre lehet hozni a négy részb˝ ol ´ all´ o IOCTL (I/O Control) kódokat. A kód els˝o tartalmazza, hogy a k´ od milyen eszk¨ ozre vonatkozik (például grafikus kártya, merevlemez). A mérés-adatgy˝ ujt˝ o k´ arty´ akhoz a Windows nem biztos´ıt semmilyen k¨ ulönleges b´ an´ asm´ odot, ezért az ”egyéb” kategóriát jelöl˝o FILE DEVICE UNKNOWN értéket v´ alasztottuk. A k´ od második része egy, általunk megadott, azonos´ıtója

15

a kérésnek. Harmadikként kell megadni, hogy ehhez a kéréshez milyen t´ıpus´ u I/O-t k´ıv´ anunk haszn´ alni, ami a mi eset¨ unkben mindig pufferelt. Vég¨ ul pedig a kéréshez sz¨ ukséges jogokat kell megadni, azaz ahhoz hogy ezt a kérést valaki elk¨ uldhesse, milyen hozz´ aférési joggal kell rendelkeznie a kártyához. Ezek ut´ an végrehajtjuk az ´ırást / olvasást, majd vég¨ ul teljes´ıtj¨ uk az IRP-t. Amennyiben a program a switch egyik ágába sem lép be, u ´gy a státusz marad STATUS INVALID DEVICE REQUEST, ellenkez˝o esetben pedig az adott ág felel˝ os a st´ atusz be´ all´ıt´ as´ aért. Az I/O m˝ uveletekhez egy I/O m˝ uveletet le´ıró strukt´ urát használunk, amelynek defin´ıci´ oja a k¨ ovetkez˝o: 1 struct DM7520 IO DESCRIPTOR 2 { 3 DM7520 : : MEMORY LOCATION memloc ; 4 DM7520 : : SIZE s i z e ; 5 UINT16 o f f s e t ; 6 UINT32 data ; 7 };

Az els˝ o tag a memloc, amely azt tartalmazza, hogy a m˝ uvelet a kártyának melyik mem´ oriatartom´ any´ ara vonatkoznak. A size mez˝o mutatja meg, hogy h´ any b´ ajtnyi adatot szeretnénk ´ırni / olvasni. Ez a két tag egy-egy enumer´ aci´ oval adhat´ o meg, ezek a következ˝oképpen néznek ki: 1 enum MEMORY LOCATION : char 2 { LAS0 = 0x0 , LAS1 = 0x1 , LCFG = 0 x2 } ; 3 enum SIZE : char 4 { BYTE = 0x1 , WORD = 0 x02 , DWORD = 0 x04 } ;

Az offset a m˝ uvelet mem´ oriarekeszen bel¨ uli pontos helyét mondja meg, a data pedig az adat amit ´ırni k´ıvánunk, illetve amit beolvastunk. Az ´ır´ asi ´ ag a k¨ ovetkez˝ oképpen néz ki: 1 switch ( s t a c k −>P a r a m e t e r s . D e v i c e I o C o n t r o l . I o C o n t r o l C o d e ) { 2 case DM7520 WRITE BUFFERED : 3 { 4 DM7520 IO DESCRIPTOR∗ i o D e s c = (DM7520 IO DESCRIPTOR∗ ) p i r p −> AssociatedIrp . SystemBuffer ; 5 s t a t u s = STATUS SUCCESS ; 6 p i r p −>I o S t a t u s . I n f o r m a t i o n = i o D e s c −>s i z e ; 7 v o l a t i l e UCHAR∗ a d d r e s s ; 8 switch ( i o D e s c −>memloc ) { 9 case DM7520 : : LAS0 : a d d r e s s = pdx−>l a s 0 ; break ; 10 case DM7520 : : LAS1 : a d d r e s s = pdx−>l a s 1 ; break ; 11 case DM7520 : : LCFG: a d d r e s s = pdx−>l c f g ; break ; 12 } 13 a d d r e s s += i o D e s c −>o f f s e t ; 14 switch ( i o D e s c −>s i z e ) 15 { 16 case DM7520 : : BYTE: WRITE REGISTER UCHAR ( (UCHAR∗ ) a d d r e s s , ( UINT8) i o D e s c −>data ) ; break ; 17 case DM7520 : :WORD: WRITE REGISTER USHORT( (USHORT∗ ) a d d r e s s , ( UINT16 ) i o D e s c −>data ) ; break ; 18 case DM7520 : :DWORD: WRITE REGISTER ULONG ( (ULONG∗ ) a d d r e s s , ( UINT32 ) i o D e s c −>data ) ; break ; 19 } 20 break ; 21 } 22 }

16

Pufferelt I/O esetén a Windows szolgáltat nek¨ unk egy puffert, ahol elérj¨ uk a felhaszn´ al´ oi m´ odb´ ol ´ atk¨ uld¨ ott adat másolatát, ez található a SystemBuffer altal meghat´ ´ arozott helyen, ahol nek¨ unk normális esetben egy I/O m˝ uveletet le´ır´ o strukt´ ura van. Ír´ as esetén az Information az eszközre ´ırt bájtok számát tartalmazza. Ezek ut´ an az address nev˝ u változónkban beáll´ıtjuk a kezd˝oc´ımet az ´ atadott strukt´ ura f¨ uggvényében, majd hozzáadjuk az offsetet. Ezek után a méret f¨ uggvényében a Windows Driver Kit által biztos´ıtott makrókon kereszt¨ ul végrehajtjuk az ´ır´ ast az eszk¨ ozre. Az olvas´ as sokban hasonl´ıt az ´ırásra, azonban van pár fontos k¨ ulönbség k¨ oz¨ ott¨ uk. A megval´ os´ıt´ as a k¨ ovetkez˝o: 1 // . . . 2 case DM7520 READ BUFFERED : 3 { 4 DM7520 IO DESCRIPTOR∗ i o D e s c = (DM7520 IO DESCRIPTOR∗ ) p i r p −> AssociatedIrp . SystemBuffer ; 5 s t a t u s = STATUS SUCCESS ; 6 p i r p −>I o S t a t u s . I n f o r m a t i o n = s i z e o f (DM7520 IO DESCRIPTOR) ; 7 v o l a t i l e UCHAR∗ a d d r e s s ; 8 switch ( i o D e s c −>memloc ) 9 { 10 case DM7520 : : LAS0 : a d d r e s s = pdx−>l a s 0 ; break ; 11 case DM7520 : : LAS1 : a d d r e s s = pdx−>l a s 1 ; break ; 12 case DM7520 : : LCFG: a d d r e s s = pdx−>l c f g ; break ; 13 } 14 a d d r e s s += i o D e s c −>o f f s e t ; 15 switch ( i o D e s c −>s i z e ) 16 { 17 case DM7520 : : BYTE: i o D e s c −>data = READ REGISTER UCHAR ( (UCHAR ∗ ) a d d r e s s ) ; break ; 18 case DM7520 : :WORD: i o D e s c −>data = READ REGISTER USHORT( (USHORT ∗ ) a d d r e s s ) ; break ; 19 case DM7520 : :DWORD: i o D e s c −>data = READ REGISTER ULONG ( (ULONG ∗ ) a d d r e s s ) ; break ; 20 } 21 break ; 22 }

Az ´ır´ ashoz hasonl´ oan itt is sz¨ ukség¨ unk van inputra egy I/O le´ıró strukt´ ura form´ aj´ aban, amelyet a m´ ar eml´ıtett SystemBuffer változón kereszt¨ ul ér¨ unk el. Az Information értékének itt az olvasott bájtok számát áll´ıtjuk be, azonban fontos odafigyelni, hogy a ”beolvasott bájtok száma” kifejezést felhasználói m´ odb´ ol értelmezz¨ uk! A driver szempontjából csak a size-nak megfelel˝o mennyiség˝ u b´ ajtot olvasunk be, azonban a felhasználónak egy egész DM7520 IO DESCRIPTOR strukt´ urát visszajuttatunk, ezért annak az értékét adjuk vissza inform´ aci´ o gyan´ ant. Ezek után pontosan ugyanaz történik mint az ´ır´ asn´ al, azzal a k¨ ulönbséggel természetesen, hogy most a READ REGISTER kezdet˝ u makrókat használjuk, majd az értéket eltároljuk a strukt´ ur´ ankban. Az I/O m˝ uveleteknél nem kell amiatt aggódnunk, hogy van-e hozz´ aférés¨ unk a megadott pufferekhez, vagy hogy azok módosulhatnak-e id˝ ok¨ ozben. Mivel pufferelt I/O-ról beszél¨ unk, ezért a Windows a DeviceIoControl h´ıv´ asokn´ al az átadott paramétereket lemásolja nek¨ unk és egy kernel-m´ od´ u mem´ oriater¨ uleten lév˝o pufferbe teszi ˝oket, amit mi szabadon m´ odos´ıthatunk. Olvas´ as esetében a SystemBuffer els˝o Information bájtja automatikusan visszam´ asol´ odik a Windows által a felhasználói mód´ u pufferbe, 17

´ıgy nek¨ unk ezzel nem kell foglalkoznunk, attól eltekintve, hogy rögz´ıtve van, hogy mely mem´ oriac´ımre kell ´ırnunk a visszaadandó értékeket. ´ Erdemes még a hibamegel˝ozés céljából megeml´ıteni, hogy a WDK ford´ıt´ oprogramjai automatikusan végrehajtanak egy statikus kódanal´ızist a driver¨ unk¨ on, amelynek munkáját nagyban megkönny´ıti, ha a k¨ ulönféle f¨ uggvényeinkr˝ ol el˝ ore megmondjuk, hogy milyen célt k´ıvánnak betölteni. Ezt a k¨ ovetkez˝ oképpen lehet megtenni: 1 2 3 4 5 6 7

extern ”C” DRIVER INITIALIZE D r i v e r E n t r y ; DRIVER UNLOAD DM7520 DriverUnload ; DRIVER ADD DEVICE DM7520 AddDevice ; DRIVER DISPATCH DM7520 Close ; DRIVER DISPATCH DM7520 Create ; DRIVER DISPATCH DM7520 DeviceControl ; DRIVER DISPATCH DM7520 PnP ;

Az´ altal, hogy a k´ odanaliz´ ator látja, hogy a DM7520 AddDevice f¨ uggvény elvileg az eszk¨ oz hozz´ aad´ as´ at kéne hogy kezelje, meg tudja vizsgálni, hogy megfelel-e p´ ar minimumk¨ ovetelménynek, amelyeket az erre a célra ´ırt f¨ uggvényeknek teljes´ıteni¨ uk kell. Ezzel lényegében el is kész´ıtett¨ unk az illeszt˝oprogramunk forráskódját, amit a WDK ´ altal biztos´ıtott speciális ford´ıtókkal le tudunk ford´ıtani egy .sys f´ ajll´ a. Azonban egy .sys f´ ajllal önmagában a rendszer még nem tud mit kezdeni, sz¨ ukség¨ unk van egy második fájlra, amely le´ırja a driver¨ unket. Ezt egy .inf f´ ajlban tudjuk megtenni. A következ˝oekben ennek a fájlnak a rövid bemutat´ asa k¨ ovetkezik. 2.2.2

A driver-le´ır´ o .inf f´ ajlok

Egy driver telep´ıtése a Windows rendszerekben mindig egy .inf fájlon kereszt¨ ul indul. Ezek a f´ ajlok hat´ arozz´ ak meg, hogy melyik eszközhöz pontosan milyen szolg´ altat´ asok és driverek tartoznak, milyen lépéseket kell az operációs rendszernek végrehajtania az eszközök telep´ıtéséhez. Tekints¨ uk át a mi konkrét .inf f´ ajlunkat, hogy pontosan milyen információkat is kell megadni: 1 2 3 4 5 6

[ Version ] Signature Class Cl a ss G ui d Provider DriverVer

= = = = =

”$Windows NT$” RTDDataModule {D695ED6A−630D−4D83−8D8B−F1F0AC107AD0} %DM75 20 In fProv ider% 04/04/2012 ,1.1.2.2

A legt¨ obb .inf f´ ajl a k¨ otelez˝o Version részleggel indul, ebben vannak a legalapvet˝ obb inform´ aci´ ok, amelyek még nem is a konkrét driverr˝ol vagy eszk¨ ozr˝ ol, hanem egy termékcsaládról szól, ugyanis egy .inf fájl több eszközt és t¨ obb drivert is le´ırhat. A Signature azonos´ıtja a rendszer t´ıpusát, amelyre mi telep´ıteni k´ıv´ anjuk az eszk¨ oz¨ unket. Ennek két értéke lehet: $Windows NT$ és $Chicago$. Mindkett˝ o pontosan ugyanazt jelenti, méghozzá hogy Windows alap´ u rendszerr˝ ol beszél¨ unk. Jelenleg tehát lényegében jelentékeny ez az érték, azonban kihagyni nem lehet, k¨ ulönben érvénytelen lesz a fájlunk. A Class bejegyzés azonos´ıtja a mi termékosztályunkat (további példák: videok´ arty´ ak, monitorok, perifériák). Mivel a mérés-adatgy˝ ujt˝o kártyák nem 18

annyira elterjedtek, hogy saj´ at kategóriájuk legyen alapból a Windows-ban, ´ıgy létrehoztunk mi egyet. Az osztályokhoz minden esetben tartozik egy GUID, amelyet a ClassGuid bejegyzésben kell megadni; ezt az értéket szintén mi gener´ altuk. A Provider -nél az eszköz / illeszt˝oprogram kész´ıt˝ojét szokás megadni. Azonban .inf f´ ajlokban nem szokás közvetlen¨ ul a szövegeket megadni, helyette csak egy azonos´ıtót, a szövegeket pedig egy k¨ ulön erre a célra kialak´ıtott részlegben gy˝ ujteni. Végezet¨ ul a driver verzióját, illetve d´ atum´ at sz¨ ukséges megadni, ez alapján tudja a Windows, hogy melyik driver u ´jabb a m´ asikn´ al. A k¨ ovetkez˝ o részlegek a másolandó fájlok forrásait és céljait hivatottak be´ all´ıtani: 1 2 3 4 5 6 7 8 9 10 11

[ SourceDisksNames ] 1 = %DM7520 DiskName% [ S o u r c e D i s k s F i l e s . amd64 ] DM7520 . s y s = 1 , \ x64 [ S o u r c e D i s k s F i l e s . x86 ] DM7520 . s y s = 1 , \ x86 [ DestinationDirs ] D e f a u l t D e s t D i r = 12 ; Windows\ System32 \ D r i v e r s

A SourceDisksNames részlegben kell megadni a telep´ıt˝olemezek elnevezéseit, a ”Kérem helyezze be az XYZ telep´ıt˝olemezt...” t´ıpus´ u u ¨zenetekhez. A mi eset¨ unkben csak egyetlen egyet adtunk meg, aminek a nevét a string poolban adtuk meg. Ezek után jön a SourceDisksFiles részleg, amelyeket a .amd64 és .x86 kiegész´ıtésekkel k¨ ulön lehet választani 32 és 64-bites esetekre. Mindkét esetben a DM7520.sys fájl az egyetlen másolandó, ez maga a driver szolg´ altat´ asunk. Mindkét esetben az els˝o telep´ıt˝olemezen van a f´ ajl, azon bel¨ ul pedig az x64 vagy x86 mappában, az éppen futó rendszer paramétereit˝ ol f¨ ugg˝ oen. Ezut´ an jön, hogy hová is kell a fájlokat másolni, ezt lehet a DestinationDirs részlegben megadni. A mi eset¨ unkben elegend˝o egy alapértelmezett mappa, amelyre a Windows számos, számokkal jelölt lehet˝ oséget biztos´ıt sz´ amunkra. Mi a 12 jel˝ u, Windows\System32\Drivers mapp´ ara mutat´ ot v´ alasztottuk, ahol a legtöbb driver elhelyezkedik. Ezt k¨ oveti a registry-vel kapcsolatos két bejegyzés: 1 2 3 4 5

[ ClassInstall32 ] AddReg = DM7520 Class AddReg [ DM7520 Class AddReg ] HKR, , , , % DM7520 ClassName%

A ClassInstall32 részleg mondja meg, hogy az adott eszközosztály telep´ıtésekor (teh´ at amikor a rendszer el˝oször találkozik egy olyan t´ıpus´ u eszk¨ ozzel) miket kell csin´ alnia. Ebben az egyetlen kötelez˝oen kitöltend˝o bejegyzés az AddReg, aminek egy másik részlegre kell mutatnia, amely le´ırja, hogy hol és milyen bejegyzéseket kell létrehozni a registry-ben. A mi eset¨ unkben egyetlen egy bejegyzést k´ıvánunk létrehozni azzal az egyetlen unk semmit nem kell a sorral a DM7520 Class AddReg részlegben. Mivel nek¨ registry-ben t´ arolni, a lehet˝ o legtöbb beáll´ıtást kihagytuk, ´ıgy egy egyszer˝ u 19

bejegyzést hoztunk létre DM7520 ClassName néven, amit a szövegeket tároló részben oldunk fel. Ezut´ an m´ ar a konkrét eszközöket azonos´ıtó részek következnek (a mi eset¨ unkben csak egy eszk¨ oz van): 1 2 3 4 5 6 7 8

[ Manufacturer ] %DM7520 Manufacturer% = DM7520 , NTamd64 , NTx86 [ DM7520 . ntamd64 ] %D M 7 5 2 0 D e v i c e D e s c r i p t i o n% = D M 7 5 2 0 I n s t a l l , PCI\VEN 1435&DEV 7520 [ DM7520 . ntx86 ] %D M 7 5 2 0 D e v i c e D e s c r i p t i o n% = D M 7 5 2 0 I n s t a l l , PCI\VEN 1435&DEV 7520

A Manufacturer részlegben lehet a gyártókat, az eszközöket és a platformokat ¨ osszekapcsolni. A bejegyzések kulcsa mindig egy-egy gyártónak a neve (ami a string poolban mutat), értéke pedig egy adott eszközcsaládot le´ıró részleg, valamint ut´ ana vessz˝ovel elválasztva a k¨ ulönböz˝o támogatott platformok. Mi egy termékcsaládot és két platformot adtunk meg, amely két tov´ abbi (´ am azonos) részleget eredményez. A részleg neve a megadott termékcsal´ ad azonos´ıt´ oja és a platform azonos´ıtója egy ponttal elválasztva. Ezekben a részlegekben lehet a termékcsaládon bel¨ ul a termékeket megadni. Itt a kulcsok mindig az adott eszköznek a neve (string poolban), az értékek pedig az eszk¨ oznek a telep´ıtésér˝ol szóló részleg neve, valamint az eszköznek az egyedi azonos´ıt´ oja, ami tartalmazza a gyártó (vendor) azonos´ıtóját, az eszk¨ ozét, valamint az illesztés t´ıpusát is (PCI). A telep´ıtésr˝ ol sz´ ol´ o részleg a következ˝oképpen néz ki: 1 2 3 4 5

[ DM7520 Install ] C o p y F i l e s = @DM7520 . s y s [ DM7520 Install . S e r v i c e s ] A d d S e r v i c e = DM7520 srvc , 2 , D M 7 5 2 0 S e r v i c e I n s t a l l

Az els˝ o részlegben meg kell adni a fájlok neveit, amelyeket át k´ıvánunk m´ asolni. Ezek azonban nem magukra a fájlokra hivatkoznak, hanem a SourceDisksFiles részlegben megadott bejegyzésekre! A DM7520 Install.Services részleg a telep´ıtésnek a szolgáltatásokról szóló része. M´ıg az el˝ oz˝ o részben csak fájlokat másoltunk, most u ´j szolgáltatások létrehoz´ as´ ara van lehet˝ oség. Az AddService direkt´ıva els˝o paramétere a létrehozni k´ıv´ ant szolg´ altat´ as neve. Ezt követi a flag paraméter, amelynek a 2 értéke azt jelenti, hogy a megadott szolgáltatás egy Plug and Play function driver. Az utols´ o paraméter pedig egy hivatkozás amely a szolgáltatás telep´ıtésének konkrét paramétereit ´ırja le. Ez a következ˝o: 1 2 3 4 5 6

[ DM7520 ServiceInstall ] DisplayName = %DM7520 ServiceName% ServiceType = 1 ; SERVICE KERNEL DRIVER StartType = 3 ; SERVICE DEMAND START E r r o r C o n t r o l = 1 ; SERVICE ERROR NORMAL S e r v i c e B i n a r y = %12%\DM7520 . s y s

Itt m´ ar a konkrét szolg´ altatásunkat ´ırjuk le, megadva el˝oször a szolgáltatás felhaszn´ al´ ok sz´ am´ ara megjelen˝o nevét (igény szerint egy rövid le´ırás is 20

adhat´ o). Ezek ut´ an meg kell adni a szolgáltatás t´ıpusát, ami a mi eset¨ unkben egy kernel-m´ od´ u driver. Sz¨ ukség van továbbá arra is, hogy ez az adott szolg´ altat´ as mikor induljon el. Itt olyan lehet˝oségek lennének még például, mint a ”minden indul´ askor”, a ”minden induláskor késleltetve”, vagy a ”manu´ alis ind´ıt´ as sz¨ ukséges”. Mi azt választottuk, hogy induljon el automatikusan, de csak akkor ha sz¨ ukség van rá. Beáll´ıtandó továbbá, hogy a szolg´ altat´ as hogyan kezelje a k¨ ulönböz˝o fellép˝o hibákat. Egy merevlemez-illeszt˝ o esetében érthet˝o lehet a hibáknak a szigor´ ubb kezelése, azonban mi megelégedt¨ unk az alapbeáll´ıtással. Végezet¨ ul meg kell adni, hogy a rendszer hol tal´ alja mag´ at a szoftver¨ unket. Itt szintén el˝ojön a már látott Windows\System32\Drivers mappát jelöl˝o 12-es szám. Az utols´ o részleg pedig a string pool, ami a következ˝oképpen néz ki: 1 2 3 4 5 6 7

[ Strings ] DM7520 ClassName DM7520 DeviceDescription DM7520 DiskName D M7520 In fProv ider DM7520 Manufacturer DM7520 ServiceName

= = = = = =

”RTD DataModule ” ”DM7520 D e v i c e ” ”DM7520 d r i v e r i n s t a l l a t i o n d i s c ” ”RTD Embedded T e c h n o l o g i e s , I n c . ” ”RTD Embedded T e c h n o l o g i e s , I n c . ” ”DM7520 d e v i c e d r i v e r ”

Itt egészen egyszer˝ uen kulcsként azonos´ıtókat adunk meg, amelyekre a fájl t¨ obbi részén sz´ azalékjelek között tudunk hivatkozni, értékként pedig az azonos´ıt´ o helyére becserélni k´ıván szöveget lehet megadni. Ezzel a megoldással az ¨ osszes sz¨ oveg¨ unket egy helyre tudjuk gy˝ ujteni, ami sok szempontból is hasznos (pl. lokaliz´ aci´ o). Az .inf és a szoftver¨ unket tartalmazó .sys fájlok birtokában már behelyezhetj¨ uk az eszk¨ ozt a rendszerbe, amelyet a Windows nem fog felismerni, ´ıgy az eszk¨ ozkezel˝ oben manuális kell a driver helyét megadni. Ezek ut´ an az eszk¨ oz automatikusan feltelep¨ ul és használható. 2.2.3

Az eszk¨ ozilleszt˝ ok digit´ alis al´ a´ır´ asa

A 64-bites Windows 7 rendszerben alapból csak és kizárólag digitálisan alá´ırt eszk¨ ozilleszt˝ oket lehet telep´ıteni a drivernek álcázott v´ırusok elleni védelem miatt. Természetesen a mi apró teszt driver¨ unkhöz nem szerezt¨ unk be semmilyen tan´ us´ıtv´ anyt, azonban szerencsére a Windows ezen védelmi mechanizmus´ at sokféle m´ odon meg lehet ker¨ ulni. Az egyik legegyszer˝ ubb, ha az ember belép a boot men¨ ube (F8-at lenyomva az operációs rendszer bet¨ olt˝ odésének kezdetekor), majd ott a ”Disable driver signature enforcement” opci´ ot v´ alasztja. Ennek hat´ asára a Windows u ´gy indul el, hogy alá´ıratlan eszk¨ ozkezel˝ oket is lehet telep´ıteni. Ez a hatás a rendszer u ´jraind´ıtásáig érvényes, ut´ ana deaktiv´ al´ odik. Ebben az esetben a driver¨ unk és az eszköz¨ unk telep´ıtve marad, azonban nem lehet elind´ıtani egy hiba¨ uzenet miatt (A driver nincs al´ a´ırva).

2.3

A k´ artya API-j´ anak bemutat´ asa

Az eddigiek sor´ an megtudtuk hogyan tudjuk a saját driver¨ unket elkész´ıteni. Azonban ¨ onmag´ aban egy driver nehezen használható. Egy fels˝o szint˝ u driver

21

(egy funkcion´ alis driver) rendszerint biztos´ıt valamilyen API-t, annak érdekében, hogy a k´ artya m˝ uködését bels˝oleg nem ismer˝o emberek is tudjanak r´ a programokat fejleszteni. Egy driver API elkész´ıtése lényegében semmiben sem tér el egy b´ armilyen k¨ onyvtár meg´ırásától. Lehet˝oség¨ unk van akár magát a forr´ ask´ odot is ´ atadni (például .h és .cpp fájlokként), akár egy statikus k¨ onyvt´ arat (.h és .lib f´ ajlokkal), vagy akár egy DLL-t is a céloktól f¨ ugg˝oen. A mi eset¨ unkben t¨ orekedt¨ unk az egyszer˝ uségre, ´ıgy a felhasználói alkalmazásunk keretein bel¨ ul fejlesztett¨ uk ki az API-t is. Ez ellent mond bizonyos programoz´ asi elveknek, azonban egy ekkora méret˝ u projektnél kétség k´ıv¨ ul sokkal egyszer˝ ubb. El˝ osz¨ or is meg kell fontoljuk, hogy mekkora hatalmat k´ıvánunk a felhasználó (teh´ at a ”k¨ uls˝ o” programoz´ o) kezébe adni. Itt is fel lehet áll´ıtani a két extrém esetet: 1 // Case 1 : Extreme t r u s t 2 void Write ( DM7520 : : MEMORY LOCATION memloc , unsigned o f f s e t , void ∗ data , unsigned dataLength ) ; 3 void Read ( DM7520 : : MEMORY LOCATION memloc , unsigned o f f s e t , void ∗ b u f f e r , unsigned l e n g t h ) ; 4 5 // Case 2 : Extreme d i s t r u s t − r e t u r n v a l u e s a l w a y s i n d i c a t e s u c c e s s 6 bool ResetCard ( ) ; 7 bool S t a r t T i m e r ( ) ; 8 bool ReadRegisterA ( ) ; 9 bool W r i t e R e g i s t e r B ( char data ) ; 10 bool SetSomeBoolValue ( bool v a l u e ) ;

Az els˝ o esetben teljesen megb´ızunk a programozóban, minimalisztikus API-t alak´ıtunk ki, ennek ellenére azonban mindent meg lehet vele csinálni. Természetesen r´ ab´ızni a programozóra, hogy pontosan tudja, hogy melyik mem´ oriac´ımre ´ırhat és milyen értékeket lehet oda´ırni, ez h´ usz évvel ezel˝ott volt elfogadhat´ o. A m´ asik véglet pedig amikor minden egyes elvégezhet˝o m˝ uveletre k¨ ul¨ on f¨ uggvényt biztos´ıtunk. A mai szoftverfejlesztés ebbe az irányba halad, azonban a mi munk´ ankhoz inkább az els˝o megoldásra hasonl´ıtó API-t hoztunk létre: 1 DEFINE GUID( DM7520 GUID , 2 0 x f 1 4 a f 8 5 1 , 0 x9aeb , 0 x 4 1 f 3 , 0xb3 , 0 xa9 , 0x7d , 0 x51 , 0 x19 , 0 x56 , 0 xce , 0 x33 ) ; 3 4 // IOCTL c o d e s 5 #define DM7520 WRITE BUFFERED \ 6 CTL CODE(FILE DEVICE UNKNOWN, 0 x800 , METHOD BUFFERED, FILE WRITE ACCESS) 7 #define DM7520 READ BUFFERED \ 8 CTL CODE(FILE DEVICE UNKNOWN, 0 x801 , METHOD BUFFERED, FILE READ ACCESS) 9 10 c l a s s DM7520 11 { 12 public : 13 enum MEMORY LOCATION : char 14 { LAS0 = 0x0 , LAS1 = 0x1 , LCFG = 0 x2 } ; 15 enum SIZE : char 16 { BYTE = 0x1 , WORD = 0 x02 , DWORD = 0 x04 } ; 17 ˜DM7520 ( ) ; 18 s t a t i c void C l o s e D e v i c e ( DM7520∗ d e v i c e ) ;

22

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

s t a t i c DM7520∗ OpenDevice ( ) ; UINT32 Read (MEMORY LOCATION memloc , UINT16 o f f s e t , SIZE s i z e ) ; void Write (MEMORY LOCATION memloc , UINT16 o f f s e t , SIZE s i z e , UINT32 data ) ; private : DM7520 ( ) ; DM7520 ( const DM7520∗ ) ; DM7520 (HANDLE h a n d l e ) ; HANDLE h a n d l e ; }; struct DM7520 IO DESCRIPTOR { DM7520 : : MEMORY LOCATION memloc ; DM7520 : : SIZE s i z e ; UINT16 o f f s e t ; UINT32 data ; };

A GUID-ot, az IOCTL k´ odokat, valamint a DM7520 IO DESCRIPTOR strukt´ ur´ at csak a teljesség kedvéért szerepeltetj¨ uk, ezeket korábban már bemutattuk. A k´ artya alapvet˝o manipulációjához a DM7520 nev˝ u osztályt hoztuk létre, amelynek publikus f¨ uggvényeivel meg lehet nyitni és be lehet z´ arni a k´ arty´ at, valamint az ´ırás és olvasás funkciókat is ezen az osztályon kereszt¨ ul lehet elvégezni. Mivel szerett¨ unk volna egy mindig konzisztens allapotb´ ´ ol indul´ o oszt´ alyt megvalós´ıtani, a k¨ ulönböz˝o konstruktorokat priváttá tett¨ uk, ´ıgy az oszt´ alyt csak az OpenDevice f¨ uggvényen kereszt¨ ul lehet péld´ anyos´ıtani. Erre azért volt sz¨ ukség, mert a konstruktorból csak nagyon korl´ atozottan tudtuk volna a hibakezelést megoldani. A k´ arty´ ankhoz minden esetben egy HANDLE t´ıpus´ u változón kereszt¨ ul fogunk tudni hozz´ aférni, amelyet az OpenDevice f¨ uggvényen kereszt¨ ul tudunk biztos´ıtani az oszt´ alyunknak: 1 DM7520∗ DM7520 : : OpenDevice ( ) 2 { 3 HDEVINFO h d i = SetupDiGetClassDevs (&DM7520 GUID , 0 , NULL, DIGCF PRESENT | DIGCF DEVICEINTERFACE) ; 4 i f ( h d i == INVALID HANDLE VALUE) 5 { 6 return n u l l p t r ; 7 } 8 SP DEVICE INTERFACE DATA d i d ; 9 d i d . c b S i z e = s i z e o f (SP DEVICE INTERFACE DATA) ; 10 i f ( ! S e t u p D i E n u m D e v i c e I n t e r f a c e s ( hdi , 0 , &DM7520 GUID , 0 , &d i d ) ) 11 { 12 SetupDiDestroyDeviceInfoList ( hdi ) ; 13 return n u l l p t r ; 14 } 15 ULONG b u f f e r S i z e ; 16 S e t u p D i G e t D e v i c e I n t e r f a c e D e t a i l ( hdi , &did , NULL, 0 , &b u f f e r S i z e , 0) ; 17 PSP DEVICE INTERFACE DETAIL DATA i f D e t a i l = ( PSP DEVICE INTERFACE DETAIL DATA) new char [ b u f f e r S i z e ] ; 18 i f D e t a i l −>c b S i z e = s i z e o f (SP DEVICE INTERFACE DETAIL DATA) ; 19 i f ( ! S e t u p D i G e t D e v i c e I n t e r f a c e D e t a i l ( hdi , &did , i f D e t a i l , b u f f e r S i z e , &b u f f e r S i z e , 0 ) ) 20 { 21 SetupDiDestroyDeviceInfoList ( hdi ) ; 22 delete [ ] i f D e t a i l ;

23

23 24 25 26

27 28 29 30 31 32 33 }

return n u l l p t r ; } SetupDiDestroyDeviceInfoList ( hdi ) ; HANDLE h a n d l e = C r e a t e F i l e ( i f D e t a i l −>DevicePath , GENERIC READ | GENERIC WRITE, 0 , 0 , OPEN EXISTING , FILE ATTRIBUTE NORMAL, 0 ) ; delete [ ] i f D e t a i l ; i f ( h a n d l e == INVALID HANDLE VALUE) { return n u l l p t r ; } return new DM7520 ( h a n d l e ) ;

Ez a f¨ uggvény felel a k´ artya eléréséért, és siker esetén egy, a kártya manipul´ aci´ oj´ ara val´ o oszt´ alyra ad egy mutatót, ellenkez˝o esetben nulla a visszatérési érték. Ez a f¨ uggvény igen nagy mértékben ép´ıt a Windows API egyik ”al-API-j´ ara”, az u ´gynevezett SetupAPI-ra, amellyel a hardverekr˝ol lehet inform´ aci´ ot kérni, illetve kezelni ˝oket. A SetupDiGetClassDevs f¨ uggvénnyel egy adott eszk¨ ozosztályba tartozó eszközöket lehet lekérni. Az els˝ o paraméter hat´ arozza meg az osztályt, ahova mi a kártyánknak megfelel˝o ´ RTDDataModule eszk¨ ozoszt´ aly GUID-ját adtuk meg. Erdekes továbbá még a negyedik paraméter, amivel azt lehet szabályozni, hogy mely eszközöket kapjuk meg. A mi flag-kombinációnk azt jelenti, hogy csak az éppen aktu´ alisan jelenlév˝ o és használható interfésszel rendelkez˝o hardvereket szeretnénk l´ atni. Ez a f¨ uggvény egy HDEVINFO t´ıpust szolgáltat, amely csak egy nyers er˝ oforr´ as, ¨ onmag´ aban nem lehet bel˝ole információkat kinyerni. Ebben ny´ ujt seg´ıtséget a SetupDiEnumDeviceInterfaces metódus, amelynek seg´ıtségével végig iter´ alhatunk az eszközeinken. Mivel a mi tesztprogramunkat csak bels˝ o tesztelésre haszn´ aljuk, tudjuk, hogy mindig maximum egyetlen egy ilyen k´ artya lesz a rendszerben, ´ıgy k¨ ulönösebb vizsgálódás nélk¨ ul elfogadjuk az els˝ o tal´ alatot, amit elment¨ unk egy SP DEVICE INTERFACE DATA strukt´ ur´ aba. B´ ar a program tesztkörnyezetben való futásra kész¨ ult, azért az alapvet˝ o hibakezelést nem hagytuk ki, ´ıgy minden egyes hiba esetén felszabad´ıtjuk az eszk¨ ozinformációs listánkat a speciálisan erre a célra való SetupDiDestroyDeviceInfoList h´ıvással. Miut´ an kez¨ unkben van a feltételezett eszköz, megpróbálunk hozzáférni az interfészéhez, ehhez a SetupDiGetDeviceInterfaceDetail nev˝ u f¨ uggvény lesz a seg´ıtség¨ unkre, ennek haszn´ alata azonban némiképp meg lett bonyol´ıtva. Paraméterként ´ at kell neki adni, hogy mely eszközr˝ol k´ıvánunk információt megtudni, valamint egy puffert illetve annak méretét, ahová az adatokat m´ asolni tudja. Azonban az interfészt le´ıró strukt´ ura minden eszköznél más mérettel rendelkezik, ezért el˝ obb a f¨ uggvényt puffer átadása nélk¨ ul (17) kell megh´ıvni, ami a bufferSize nev˝ u változónkba bele´ırja a sz¨ ukséges méretet. Ezek ut´ an m´ ar létre lehet hozni a PSP DEVICE INTERFACE DETAIL DATA strukt´ uránkat, amelyhez - els˝ore tal´ an meglep˝ o m´ odon - egy bufferSize méret˝ u karaktertömböt rendel¨ unk hozz´ a. Ez azért van ´ıgy, mert ez a strukt´ ura lényegében csak szövegeket tartalmaz, és az API kész´ıt˝ oi ezzel a lépéssel k´ıvántak az összes szövegnek elegend˝ o mem´ oriater¨ uletet foglaltatni. Ezt a kés˝obbiekben természetesen minden esetben felszabad´ıtjuk. A megfelel˝o méret birtokában már megh´ıvhatjuk m´ asodj´ ara is a f¨ uggvény¨ unket, amely ez´ uttal már a számunkra

24

sz¨ ukséges inform´ aci´ okat adja meg. Ebben a pillanatban minden a kez¨ unkben van ahhoz, hogy hozzáférj¨ unk a k´ arty´ ahoz, ´ıgy az inform´ aci´ os listánkat fel is szabad´ıtjuk, majd a CreateFile h´ıv´ assal létrehozzuk a HANDLE -t az eszköz¨ unkhöz. Els˝o paraméterként a megnyitand´ o ”f´ ajl” elérési u ´tját kell megadni, amelyet az imént megszerzett interfész-le´ır´ o strukt´ ur´ ank tartalmaz. Fontos még, hogy milyen jogosults´ agokkal k´ıv´ anjuk az eszközt megnyitni. Egy kereskedelmi-cél´ u driverben célszer˝ u lehet k¨ ul¨ on csak olvasható hozzáférést biztos´ıtó megnyitási m´ odokat is t´ amogatni, azonban a mi eset¨ unkben ez nem volt fontos. Az OPEN EXISTING flag a megnyitás módját szabályozza és azt jelenti, hogy csak akkor nyissa meg a f´ ajlt, hogyha az már létezik (alapból egy nem létez˝o f´ ajl megnyit´ asakor létrej¨ on egy u ´j fájl). Az összes többi paraméter figyelmen k´ıv¨ ul hagyhat´ o. Végezet¨ ul egy dinamikus memóriafoglalást követ˝oen tér¨ unk vissza, amely természetesen potenci´ alis memóriaszivárgásokhoz vezethet, azonban ha valaki betartja azt a szab´ alyt, hogy egy megnyitott fájlt be is kell zárni, akkor nem lesz gond. Mint az l´ athat´ o, a kártyát manipuláló osztályt egy paraméterezett konstruktoron kereszt¨ ul hozzuk létre, amely semmi mást nem csinál csak be´ all´ıtja a HANDLE tagv´ altozó értékét az átadott paraméter értékére: 1 DM7520 : : DM7520 (HANDLE h a n d l e ) 2 : handle ( handle ) { }

Miut´ an az eszk¨ oz¨ unkkel való m˝ uveleteket elvégezt¨ uk, a CloseDevice nev˝ u statikus f¨ uggvénnyel lehet azt biztonságosan lezárni. A f¨ uggvény csak megsemmis´ıti az oszt´ alyt, ami cserébe megh´ıvja az osztály destruktorát, ami bez´ arja a HANDLE -jét: 1 2 3 4 5 6 7 8 9 10 11 12

void DM7520 : : C l o s e D e v i c e ( DM7520∗ d e v i c e ) { delete d e v i c e ; } DM7520 : : ˜ DM7520 ( ) { i f ( handle ) { CloseHandle ( handle ) ; } }

Az ´ır´ asért felel˝ os met´ odus a következ˝o: 1 void DM7520 : : Write ( DM7520 : : MEMORY LOCATION memloc , UINT16 o f f s e t , DM7520 : : SIZE s i z e , UINT32 data ) 2 { 3 ULONG b y t e s W r i t t e n ; 4 DM7520 IO DESCRIPTOR i o D e s c ; 5 i o D e s c . memloc = memloc ; 6 ioDesc . o f f s e t = o f f s e t ; 7 ioDesc . s i z e = s i z e ; 8 i o D e s c . data = data ; 9 D e v i c e I o C o n t r o l ( handle , DM7520 WRITE BUFFERED, (LPVOID) &i o D e s c , s i z e o f ( i o D e s c ) , NULL, 0 , &b y t e s W r i t t e n , NULL) ; 10 }

Mint az l´ athat´ o, semminem˝ u ellen˝orzést nem végz¨ unk el a kérés tov´ abb´ıt´ asa el˝ ott. Ez a driver¨ unk sz˝ uk felhasználása miatt van, egy általános 25

cél´ u illeszt˝ oprogram esetében célszer˝ u lenne még a kernel-módba való atkapcsol´ ´ as el˝ ott megbizonyosodni róla, hogy érvényes-e egyáltalán a kérés. Itt m´ ar megjelenik a m´ ar eml´ıtett DeviceIoControl nev˝ u f¨ uggvény. Ennek haszn´ alat´ aval lehet az eszközeinknek k¨ ulönféle kéréseket k¨ uldeni. A paraméterek k¨ oz¨ ott megjelenik maga az eszköz¨ unk (handle), a konkrét utas´ıtás unket, illetve annak méretét. (DM7520 WRITE BUFFERED), átadjuk a puffer¨ Ezek ut´ an j¨ onne a kimeneti puffer, azonban ´ırásnál erre nincs sz¨ ukség. A bytesWritten v´ altoz´ onkba fog beker¨ ulni az ´ırt bájtok száma (a driverben ez volt az Information). Az utolsó paraméterre pedig csak aszinkron I/O esetén van sz¨ ukség, amit˝ ol mi eltekint¨ unk. A DeviceIoControl bek¨ uldi a kérés¨ unket kernel-m´ odba, a driver stack tetejére, ahol az el˝obb-utóbb feldolgozásra ker¨ ul. Ekkor az als´ o réteg mindig jelzi a felette lév˝onek, hogy a kérést végrehajtott´ ak, m´ıg el nem jut a driver stack tetejére, ahonnan az irány´ıtás el˝ obb-ut´ obb visszaker¨ ul a DeviceIoControl -hoz, ami ezek után visszatér. Az ´ır´ ashoz nagyon hasonl´ o módon történik az olvasás: 1 UINT32 DM7520 : : Read ( DM7520 : : MEMORY LOCATION memloc , UINT16 o f f s e t , DM7520 : : SIZE s i z e ) 2 { 3 DM7520 IO DESCRIPTOR i o D e s c ; 4 i o D e s c . memloc = memloc ; 5 ioDesc . o f f s e t = o f f s e t ; 6 ioDesc . s i z e = s i z e ; 7 ULONG b y t e s R e t u r n e d ; 8 D e v i c e I o C o n t r o l ( handle , DM7520 READ BUFFERED, (LPVOID) &i o D e s c , s i z e o f ( i o D e s c ) , (LPVOID) &i o D e s c , s i z e o f ( i o D e s c ) , & b y t e s R e t u r n e d , NULL) ; 9 return i o D e s c . data ; 10 }

Az egyetlen lényeges k¨ ul¨ onbség, hogy itt már kimeneti puffer¨ unk is van, ami t¨ orténetesen megegyezik a bemeneti pufferrel. Azonban mivel a driver mindig m´ asolatokkal t¨ orténik, ´ıgy ebb˝ol nem lesz gond. Mivel tesztelési célra kész¨ ult a driver¨ unk, a visszatérési érték egy 32-bites jelöletlen egész, még akkor is, ha esetleg az olvasni k´ıv´ ant mennyiség csak egyetlen bájt. Ezzel lényegében teljessé vált az API-nk, abból a szempontból, hogy mindenre képes. B´ ar nem a mai, sok absztrakciós réteget alkalmazó fejlesztésnek megfelel˝ oen kész¨ ult, a használata relat´ıve egyszer˝ u: 1 2 3 4

DM7520∗ d e v i c e = DM7520 : : OpenDevice ( ) ; d e v i c e −>Write ( DM7520 : : LAS0 , 0 x100 , DM7520 : : BYTE, 0 x42 ) ; UINT32 r e s u l t = d e v i c e −>Read ( DM7520 : : LAS1 , 0x06C , DM7520 : : BYTE) ; DM7520 : : C l o s e D e v i c e ( d e v i c e ) ;

26

3

A m´ er´ esek bemutat´ asa

A méréseket a k¨ ovetkez˝ o hardverkonfiguráción végezt¨ uk el: Oper´ aci´ os rendszer Windows 7 x64 Processzor Intel Core 2 Duo E8500 @ 3.16 GHz Mem´ oria (RAM) 4GB Videok´ artya Intel G33 Express Integrated Video Adapter Mérés-adatgy˝ ujt˝ o k´ artya RTD DM7520 Oszcilloszk´ op HAMEG HMO2022 1. t´ abl´ azat - A hardverkonfigurációnk A méréseinket t¨ obb k¨ ul¨ onböz˝o algoritmuson végezt¨ uk el, amelyek mind egy-egy konkrét t´ıpus´ u munkavégzésre voltak kiélezve. A következ˝okben a tesztprogramok, valamint a tesztelési keretprogram rövid ismertetése k¨ ovetkezik.

3.1

A tesztprogramok

3.1.1

A keretprogram

A keretprogramnak nevezett kódrészlet nem más, mint a kódnak az a része, amely az ¨ osszes tesztesetben megegyezik: a kártya felkonfigurálása, valamint a mérési hat´ arok jelzése. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

#include ”DM7520 . h” #include <Windows . h> // G l o b a l t e s t c a s e s p e c i f i c

initialisations ...

i n t main ( ) { DM7520∗ d e v i c e = DM7520 : : OpenDevice ( ) ; d e v i c e −>Write ( DM7520 : : LAS0 , 0 x100 , DM7520 : : BYTE, 0 x42 ) ; // R e s e t d e v i c e −>Write ( DM7520 : : LAS0 , 0x07C , DM7520 : : BYTE, 0 x05 ) ; // Port1 output while ( true ) { // Per−i t e r a t i o n

initialisations ...

d e v i c e −>Write ( DM7520 : : LAS0 , 0 x074 , DM7520 : : BYTE, 0xFF ) ; // Write d a t a S l e e p ( 1 ) ; // The o s c i l l o s c o p e i s s l o w d e v i c e −>Write ( DM7520 : : LAS0 , 0 x074 , DM7520 : : BYTE, 0 x00 ) ; // Write d a t a // The t e s t i n g a l g o r i t h m . . . d e v i c e −>Write ( DM7520 : : LAS0 , 0 x074 , DM7520 : : BYTE, 0xFF ) ; // Write d a t a d e v i c e −>Write ( DM7520 : : LAS0 , 0 x074 , DM7520 : : BYTE, 0 x00 ) ; // Write d a t a

24 } 25 DM7520 : : C l o s e D e v i c e ( d e v i c e ) ; 26 return 0 ; 27 }

27

A DM7520.h f´ ajl a m´ ar korábban bemutatott API-t tartalmazza, m´ıg a Windows.h-ra a Sleep f¨ uggvény miatt van sz¨ ukség. Ezek után a tesztesetek glob´ alis v´ altoz´ oi / deklar´ aci´ oi következnek. A main f¨ uggvényben megnyitjuk a k´ arty´ at, bet¨ oltj¨ uk az alapbeáll´ıtásokat (9), majd beáll´ıtjuk az egyik portot kimenetnek. K¨ ovetkez˝ oként egy végtelen ciklus jön, amelynek egy iterációjában az adott teszteset egyszeri lefut´ asa t¨ orténik. El˝oször is vannak olyan inicializációs lépések, amelyeket nem tudunk globálisan megtenni, muszáj minden egyes iter´ aci´ o elején be´ all´ıtani. Ezt követ˝oen kiadunk egy impulzust a kártyán, ez jelenti az algoritmus fut´ as´ anak kezdetét. A jel visszavétele el˝ott azonban v´ arunk egy milliszekundumot, ugyanis az oszcilloszkópunk nagyobb id˝ otartamok vizsg´ alat´ an´ al sokszor nem vette észre a mikroszekundum nagys´ ag´ u ideig jelen lév˝ o jelet. Az impulzus kiadása után lefut maga a tesztelend˝ o algoritmus, ut´ ana pedig kiadunk még egy impulzust, jelezvén az algoritmus lefut´ as´ anak végét. Végezet¨ ul a ciklusb´ ol kilépve bezárjuk az eszköz¨ unket és visszatér¨ unk. Természetesen a k´ od jelenlegi formájában ez lehetetlen lenne, azonban ezt a tesztprogramot két k¨ ul¨ onféle módon használtuk. Az egyik a kódban látható, végtelen ciklusos m´ odon. Ebben az esetben felesleges a második impulzus kiad´ asa (jobban mondva inkább elhanyagolható), továbbá az eszköz bez´ ar´ as´ ahoz sem jutunk el soha. Ebben a módban mindig ”er˝oszakos módon”, feladatkezel˝ ob˝ ol lett bez´ arva a programunk. Mivel a Windows egy program bez´ ar´ asakor felszabad´ıt minden hozzá tartozó er˝oforrást, ezért nem kell agg´ odnunk amiatt, hogy a kártyához esetleg maradnak bezáratlan hozz´ aférések. A m´ asik haszn´ alati m´ odja a szoftvernek az volt, hogy a ciklusfeltétel egy billenty˝ u lenyom´ asa volt. Ebben az esetben egy billenty˝ u le¨ utésekor lefutott egy iter´ aci´ o az algoritmusb´ ol. Ilyenkor már a második impulzusra is sz¨ ukség van az algoritmus befejez˝ odésének érzékeléséhez. Volt természetesen egy billenty˝ u, amelynek lenyom´ as´ ara a program kilépett. 3.1.2

ArrayCopy

Ez a tesztprogram a mem´ ori´ an bel¨ ul adatmásolásra lett kialak´ıtva. Célja a ford´ıt´ o k¨ ul¨ onféle p´ arhuzamos´ıtási képességeinek vizsgálata volt. 1 2 3 4 5 6 7 8 9

// G l o b a l i n i t i a l i s a t i o n s : #define N 1024∗1024∗768 char a [N] , b [N ] ; // The a l g o r i t h m : f o r ( i n t i = 0 ; i < N; ++i ) { a[ i ] = b[ i ]; }

Mint az l´ athat´ o, t¨ omb¨ ok egyszer˝ u másolásáról van szó, amelyek a mai nagy mennyiség˝ u adattal dolgoz´ o alkalmazásokban rengetegszer el˝ofordulnak. A hardver¨ unk korl´ atozott képességei miatt vég¨ ul a 768 MB-os blokkok másolása mellett d¨ ont¨ ott¨ unk. Mivel a ciklusnak az iteráció teljesen f¨ uggetlenek egymástól, ´ıgy nagy mértékben p´ arhuzamos´ıthat´ o lenne (több szálon), valamint reményeink szerint a gener´ alt gépi k´ odban rengeteg vektorm˝ uvelettel is találkozni fogunk. 28

3.1.3

Parallel

Ez a teszt szintén a ford´ıt´ o p´ arhuzamos´ıtási képességeit próbálja mérni, azonban itt behoztuk a képbe a lebeg˝ opontos utas´ıtásokat is. 1 2 3 4 5 6 7 8 9

// G l o b a l i n i t i a l i s a t i o n s : #define N 1000 double a [N ] ; i n t b [N ] ;

// The a l g o r i t h m : f o r ( i n t i = 0 ; i < N; ++i ) { a [ i ] = rand ( ) / ( double ) ( rand ( ) + 1 ) ∗ ( − 3 7 . 0 ) ∗ ( double ) rand ( ) / ( double ) ( rand ( ) + 1 ) ; 10 b [ i ] = rand ( ) / ( rand ( ) + 1 ) ∗ 37 ∗ rand ( ) / ( rand ( ) + 1 ) ; 11 }

3.1.4

Abstraction

Ennél a tesztnél az absztrakciós réteget teljes´ıtményre vet¨ ul˝o hatásait vizsg´ altuk. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// G l o b a l i n i t i a l i s a t i o n s #define N 50 typedef i n t ( ∗ f u n c t i o n ) ( i n t ) ; f u n c t i o n f u n c t i o n s [N ] ; i n t myFunction ( i n t { i f ( n == 0 ) { for ( int i = 0 ; { functions [ i ] } } return ( n < N) ? }

n = 0)

i < N; ++i ) = myFunction ;

f u n c t i o n s [ n ] ( n + 1) : 0 ;

// The a l g o r i t h m f o r ( i n t i = 0 ; i < N; ++i ) { a[ i ] = b[ i ]; }

Ezzel az els˝ ore tal´ an kicsit elbonyol´ıtottan meg´ırt rekurzióval az volt a célunk, hogy kiker¨ ulj¨ uk a ford´ıtónak a rekurziót optimalizáló beáll´ıtásait (pl. egyszer˝ u cikluss´ a alak´ıt´ as). Mivel itt a f¨ uggvény-pointer tömb¨ unk csak fut´ askor ker¨ ul felt¨ oltésre, amely ráadásul nem is biztos hogy lefut, ´ıgy a ford´ıtó kénytelen minden egyes k´ odban látható f¨ uggvényh´ıváshoz kódot generálni, nem tudja kioptimaliz´ alni azt. Az algoritmusnak egy iterációjában N 2 f¨ uggvényh´ıv´ as zajlik le. 3.1.5

Fibonacci

A Fibonacci nev˝ u tesztprogramunk a Fibonacci számok kiszámolásáról szól, amelynek a lépései egym´ ast´ ol f¨ uggenek, nehez´ıtve ezzel a párhuzamos kód gener´ al´ as´ at. 29

1 2 3 4 5 6 7 8 9 10 11 12

// Per−i t e r a t i o n i n i t i a l i s a t i o n s i n t x1 = 1 , x2 = 1 , c u r r e n t = 1 , tmp ; // The a l g o r i t h m #define N 1000000000L f o r ( i n t 6 4 i = 0 ; i < N; ++i ) { tmp = c u r r e n t ; c u r r e n t = x1 + x2 ; x2 = x1 ; x1 = tmp ; }

3.1.6

StringCPP11

Ez az algoritmus a mai programjainkban rendk´ıv¨ ul gyakran el˝oforduló t¨ ombm´ asol´ as´ anak egy speci´ alis esetét, a szövegmásolást veszi górcs˝o alá. Ehhez a tesztprogramhoz ´ırtunk egy rendk´ıv¨ ul primit´ıv szöveget kezel˝o oszt´ alyt, amely tartalmazza az alap konstruktorokat és a destruktort. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// G l o b a l i n i t i a l i s a t i o n s c l a s s MyString { char∗ s t r ; public : MyString ( ) : {}

str ( nullptr )

MyString ( const char∗ s t r ) : { strcpy ( str , str ) ; }

s t r (new char [ s t r l e n ( s t r ) + 1 ] )

MyString ( const MyString& mystr ) : ) + 1]) { s t r c p y ( s t r , mystr . s t r ) ; }

s t r (new char [ s t r l e n ( mystr . s t r

16 17 18 19 20 MyString& operator=(const char∗ s t r ) 21 { 22 delete s t r ; 23 s t r = new char [ s t r l e n ( s t r ) + 1 ] ; 24 strcpy ( str , str ) ; 25 return ∗ t h i s ; 26 } 27 28 MyString& operator=(const MyString& mystr ) 29 { 30 i f ( t h i s == &mystr ) 31 return ∗ t h i s ; 32 return operator=(mystr . s t r ) ; 33 } 34 35 ˜ MyString ( ) 36 { 37 delete s t r ; 38 } 39 } ;

30

40 41 42 43 44 45 46

extern const char∗ p i ; MyString GetMyString ( ) { return MyString ( p i ) ; }

A pi nev˝ u k¨ uls˝ o v´ altoz´ onk egy másik fájlban van definiálva, ami egy k¨ or¨ ulbel¨ ul 9100 karakterb˝ ol ´ alló, a π számjegyeit tartalmazó karakterlánc. 1 2 3 4 5 6

// The a l g o r i t h m MyString mystr ; f o r ( i n t i = 0 ; i < 1 0 0 0 0 0 ; ++i ) { mystr = GetMyString ( ) ; }

3.2

M´ er´ esek az alapbe´ all´ıt´ assal

Alapbe´ all´ıt´ as alatt a Visual Studio 2012 által alapból felkonfigurált Release m´ odot értj¨ uk, 64-bites ford´ıtással. Ez a következ˝o ford´ıtási kapcsolókat eredményezte [5] (meghagytuk a Visual Studio által alapból létrehozott sorrendet): /GS Extra k´ od gener´ al´ asa a puffer t´ ulcsordulások észrevétele érdekében. /GL Teljes k¨ or˝ u programoptimalizálás. Enélk¨ ul csak modulonként (ford´ıtási egységenként) t¨ orténik optimalizáció. /W3 A figyelmeztetések szintjét szabályozó kapcsoló. optimaliz´ aci´ oban.

Irreleváns az

/Gy Az alapb´ ol k¨ ul¨ on-k¨ ul¨ on elhelyezked˝o f¨ uggvények u ń. f¨ uggvénycsomagokba val´ o csomagol´ as´ at engedélyezi. /Zc:wchar t Hat´ as´ ara a ford´ıtó a wchar t-t beép´ıtett t´ıpusként kezeli. Irrelev´ ans. /Zi A debug inform´ aci´ o generálást befolyásolja. Hatására az információt egy k¨ ul¨ on .pdb f´ ajlba teszi. Irreleváns. /Gm- Kikapcsolja az u ń. minimális u ´jraford´ıtást, tehát hiába módosul csak egyetlen ford´ıt´ asi egység, az összes u ´jra lesz ford´ıtva. Irreleváns. /O2 Optimaliz´ aci´ os be´ all´ıt´ as a maximális sebesség elérése érdekében. /Fd”x64Testvc110.pdb” A .pdb fájl helyét határozza meg. Irreleváns. /fp:precise A lebeg˝ opontos m˝ uveletek sebesség-pontosság arányát határozza meg. Ez a legpontosabb beáll´ıtás, és egyben az alapbeáll´ıtás is. /D ” MBCS” K¨ ul¨ onb¨ oz˝ o szimbólumokat #define-ol. /errorReport:prompt A ford´ıtóban lév˝o bels˝o hibák kezelését manipulálja. Alapb´ ol ha egy ilyen hiba el˝ojön, szól a felhasználónak, majd tovább´ıtja a Microsoft felé. Irrelev´ ans 31

/WX- Deaktiv´ alja a ”minden figyelmeztetés hiba” funkcionalitást. Irreleváns. /Zc:forScope Seg´ıtségével a for ciklus inicializációs változói csak a ciklus végéig tartanak (ellenkez˝o esetben a cikluson k´ıv¨ uli legközelebbi scope-ig). Irrelev´ ans. /Gd Az alapértelmezett h´ıv´ asi konvenció a

cdecl.

/Oi Engedélyezi a k¨ ul¨ onb¨ oz˝ o f¨ uggvényh´ıvások speciális inline-f¨ uggvényekké val´ o optimaliz´ aci´ oj´ at. /MD A runtime k¨ onyvt´ arak (CRT) többszál´ u, DLL változatát fogja használni a programunk. /Fa”x64Test” A gener´ alt assembly kód helyét határozza meg. Irreleváns. /EHsc A kivételkezelés m´ odját határozza meg. Ez a beáll´ıtás engedélyezi a C++ kivételek haszn´ alatát és feltételezi, hogy az extern ”C”-vel ellátott f¨ uggvények sosem dobnak kivételt. /nologo Megakad´ alyozza a ford´ıtó induláskor látható logójának mutatását. Irrelev´ ans. /Fo”x64Test” A gener´ alt t´ argykód helyét határozza meg. Irreleváns. /Fp”x64Testtest.pch” Az el˝oford´ıtott header fájl helyét szabja meg. Irrelev´ ans. Ezzel a be´ all´ıt´ assal a k¨ ovetkez˝o eredményeket ért¨ uk el (Id˝o alatt a tov´ abbiakban mindig az egy iterációhoz sz¨ ukséges átlagos id˝ot értj¨ uk): Teszteset Id˝ o ArrayCopy 328.55 ms Parallel 889.07 ms Fibonacci 532.27 ms Abstraction 264.56 ms StringCPP11 1560 ms 2. t´ abl´ azat - Az alap mérési eredményeink A tov´ abbiakban egyesével megvizsgálunk pár lehetséges optimalizációs lépést, illetve annak hat´ asait a kódra.

3.3

A c´ elplatform

Manaps´ ag m´ ar egyik nagy processzorokkal foglalkozó vállalat sem gyárt olyan a´ltal´ anos felhaszn´ al´ as´ u PC / Notebook processzort, amely ne támogatná az x86-64 utas´ıt´ askészletet, azaz ne lenne képes 64-bites módban futni. Az al´ abbi, 2010-ben kész¨ ult statisztika szerint a Windows futtató szám´ıtógép kevesebb mint fele volt csak 64-bites, addig a szoftveroptimalizáció egyik fontos ter¨ uletén, a j´ atékpiacon a felhasználók 59,70 százaléka futtatott 64-bites Windows 7 oper´ aci´ os rendszert 2012 szeptemberében a Steam rendszer statisztik´ ai szerint. [4] 32

3. t´ abl´ azat - A Windows platformok megoszlása

Mindezek ellenére a mai napig rendk´ıv¨ ul kevés szoftverb˝ol érhet˝o el 64-bites v´ altozat, annak ellenére, hogy a mi méréseink alapján jelent˝os sebességk¨ ul¨ onbségeket lehetne elérni ezekkel. Természetesen a 64-bites t´ amogat´ as majdnem hogy megkétszerezi a terméktámogatáshoz sz¨ ukséges munk´ at, hiszen két k¨ ul¨ onb¨ oz˝ o terméket forgalmaznának egyszerre. Minden k´ odot kétszer kell leford´ıtani, és a binárisoknak nem szabad összekeveredni¨ uk. A kés˝ obbi patch-eket is mindig két k¨ ulön változatban kell biztos´ıtani. Ami a ford´ıt´ ast illeti, ha egy k´ odot jól ´ırunk meg, akkor mindennem˝ u változtatás nélk¨ ul ´ at lehet adni a 64-bites ford´ıtónak. Egy tov´ abbi probléma ezen a téren, hogy ez már t´ ul ”fejlett” egy átlag sz´ am´ıt´ ogép-felhaszn´ al´ onak. A legtöbben nem tudják milyen rendszert futtatnak, és ha most elkezdenének a boltokban többféle változatot is forgalmazni, rengetegen vennének rossz változatot, amely további termékt´ amogat´ asi és jogi problémákhoz vezethet. Ezen a problémán némiképp seg´ıthet a mai let¨ oltéses v´ asárlás, ahol automatikusan lehetne érzékelni a sz´ am´ıt´ ogép konfigur´ aci´ oj´ at és ezáltal a megfelel˝o változatot telep´ıteni. Ezt a megold´ ast azonban még csak a nagyobb vállalatok megoldásaiban lehet felfedezni. Péld´ aul a Visual Studio webes telep´ıt˝oje telep´ıtés közben vizsgálja meg a rendszert, és t¨ olti le a sz¨ ukséges komponenseket. A teszteredményeink egyértelm˝ uen kimondták, hogy 64-bites rendszeren l´ atv´ anyos a k¨ ul¨ onbség a 32- illetve a 64-bites szoftverek futási sebességei közt: Teszteset Id˝ o (x64) Id˝ o (x86) Sebess´ egn¨ oveked´ es ArrayCopy 328.55 ms 546.19 ms 39.85% Parallel 889.07 ms 995.56 ms 10.70% Fibonacci 532.27 ms 1273 ms 58.19% Abstraction 264.56 ms 304.11 ms 13.01% StringCPP11 1560 ms 1790 ms 12.85% 4. t´ abl´ azat - x86 kontra x64 teszteredmények Mint l´ athat´ o, a legrosszabb esetben is több, mint 10 százalékos teljes´ıtményn¨ ovekedést ért¨ unk el. Azonban a nagy számokkal dolgozó 33

alkalmaz´ asok, mint péld´ aul a mi Fibonacci teszt¨ unk is, kihasználhatják a 64-bites operandus´ u m˝ uveletek el˝onyeit, és ´ıgy akár másfélszeres sebességn¨ ovekedést is elérhet¨ unk. Ennek a tesztnek az eredménye az lett, hogy egyértelm˝ uen beláttuk, hogy jelent˝ os el˝ ony¨ uk van a 64-bites programoknak a 64-bites rendszereinken, ´ıgy azt javasoljuk, hogy amennyiben erre lehet˝oség¨ unk van, biztos´ıtsunk a szoftver¨ unkb˝ ol 64-bites v´ altozatot is.

3.4

Pufferes biztons´ agi ellen˝ orz´ esek kikapcsol´ asa

Az alapértelmezettként be´ all´ıtott kapcsolók között találkozhattunk a /GS ford´ıt´ asi kapcsol´ oval, amelynek hatására a ford´ıtónk automatikusan kódot gener´ al a f¨ uggvényvisszatérésekhez, tömbök indexeléséhez, illetve egyéb olyan utas´ıt´ asokhoz, amelyeknél egy puffer t´ ulcsordulás befolyásolhatná az eredményt. Egy példa erre a következ˝o: egy rosszindulat´ u hacker egy olyan adat megad´ as´ aval amely t´ ulcsord´ıtja a puffert, át tudja ´ırni a stack-en a visszatérési c´ımet, potenci´ alisan rossz indulat´ u kódnak átadván ezzel az ir´ any´ıt´ ast. Azonban ha belegondolunk ennek a kapcsolónak a gyakorlati jelent˝oségébe, hogy ez miért is j¨ ohetett létre, mi a következ˝ore jutottunk: régen, amikor még kevés volt a t´ arter¨ ulet és a processzorok feldolgozóképessége, kritikus volt minél t¨ om¨ orebb és gyorsabb k´ odot ´ırni. Viszont amikor elkezdtek az átlag szám´ıtógép paraméterei javulni, a szoftverfejlesztés sokkal biztonságosabbá vált. Legalábbis elkezd˝ odtek a mozgalmak efelé, ezért a Microsoft u ´gy döntött, hogy a ford´ıtójuk automatikusan gener´ alni fogja ezeket az apró ellen˝orzéseket, hiszen sosem fog mindenki biztons´ agos k´ odot ´ırni. Természetesen ezek az ellen˝orzések nem teljes k¨ or˝ uek, ´ıgy nem hanyagolhatjuk el a kódunkban a biztonsági ellen˝orzéseket, azonban egy minim´ alis védelmet ny´ ujtanak. Ugyanakkor egy biztonságosan meg´ırt k´ od esetében tulajdonképpen feleslegesen kidobott teljes´ıtménynek is nevezhetj¨ uk ezt a funkcionalit´ ast. A tesztjeinkben mi kikapcsoltuk a pufferellen˝orz˝o kód generálását, amelyet a /GS- kapcsol´ oval ért¨ unk el. Ez a következ˝o eredményekhez vezetett:

Teszteset ArrayCopy Parallel Fibonacci Abstraction StringCPP11

Id˝ o (/GS) Id˝ o (/GS-) Sebess´ egn¨ oveked´ es 328.55 ms 306.51 ms 6.71% 889.07 ms 854.66 ms 3.87% 532.27 ms 520.72 ms 2.17% 264.56 ms 264.46 ms 0.04% 1560 ms 1490 ms 4.49% 5. t´ abl´ azat - A /GS kapcsoló hatása

Mint az l´ athat´ o, az alkalmazásaink sebessége konzisztensen javult, azonban meglehet˝ osen csekély mértékben. Felmer¨ ul a kérdés, hogy érdemes lehet-e lemondani egy biztons´ agi rétegr˝ol pár százaléknyi sebességnövekedés elérése érdekeben. Mi u ´gy gondoljuk hogy mivel az u ´j operációs rendszerek mindig egyre t¨ obb és t¨ obb biztons´ agot ny´ ujtanak nek¨ unk, amelyek megvédik az alkalmaz´ asainkat a k¨ uls˝ o behatolások ellen, ezért megérheti. Amennyiben a k´ odunkban u ¨gyel¨ unk az alapvet˝o biztonságra, mint például a puffereinkbe

34

ker¨ ulés el˝ ott az adatok hosszának ellen˝orzése, u ´gy nem fog csökkenni a programunk védettsége. Ebben az esetben lényegében ”ingyen”, mindennem˝ u h´ atul¨ ut˝ o nélk¨ ul kapjuk a p´ ar százaléknyi sebességjavulást, amelyet ráadásul egyetlen egyszer˝ u ford´ıt´ asi kapcsoló megadásával el is tudunk érni.

3.5

Az architekt´ ura specifik´ al´ asa

A Visual Studio 2012 optimalizációs beáll´ıtásai között találhatunk egy ”minim´ alis architekt´ ura” nev˝ u beáll´ıtást. A következ˝o lehet˝oségek köz¨ ul v´ alaszthatunk: /arch:IA32 Csak az x87 FPU utas´ıtáskészletét használja. /arch:SSE Engedélyezi a Streaming SIMD Extensions utas´ıtáskészletet. /arch:SSE2 Engedélyezi az SSE2 utas´ıtáskészletet. /arch:AVX Engedélyezi a 2011-ben deb¨ utált Advanced Vector Instructions utas´ıt´ askészletet. Egy adott utas´ıt´ askészlet engedélyezése automatikusan engedélyezi a list´ aban felette szerepl˝ oket is. Sajnos a tesztsz´ am´ıt´ ogép¨ unk processzora nem támogatja az AVX utas´ıt´ asokat, ezért csak az SSE2 utas´ıtásokat tudtuk bekapcsolni. Azonban érdemes megjegyezni, hogy a generált kód az AVX utas´ıtáskészletet specifik´ alva eltért a csak SSE2-t használó kódtól, ezért elképzelhet˝o, hogy annak haszn´ alat´ aval nagyobb sebességnövekedést lehetne elérni. Az x87 FPU lebeg˝ opontos segédprocesszor megjelenése óta rengeteg id˝o telt el, rengeteg u ´j technol´ ogia jelent meg és a processzorokkal szembeni elv´ ar´ asok is teljesen ´ atalakultak. Am´ıg régen a processzor órajelét mindig csak n¨ ovelve nem volt jelent˝ os a p´ arhuzamos´ıtás gondolata, addig manapság szinte egy´ altal´ an nem emelkednek a processzorok órajelei, azonban a párhuzamos m˝ uvelet végrehajt´ as mértéke egyre csak n˝o. Ebben a feladatkörben seg´ıtenek az els˝ osorban p´ arhuzamos adatfeldolgozásra és lebeg˝opontos szám´ıtásokra kialak´ıtott SSE és AVX utas´ıtáskészletek. Ezek nélk¨ ul a processzorban csak ”mesterséges” p´ arhuzamos végrehajtás jön létre, például az utas´ıtások pipeline-ol´ as´ aval. Az SSE utas´ıtáskészlet viszont rengeteg olyan u ´j utas´ıtást tartalmazott, amelyekkel egy adott m˝ uveletet egyszerre lehetett több adaton végezni, ez a SIMD (Single Instruction Multiple Data - Egy utas´ıtás, több adat) utas´ıt´ asok lényege. A minim´ alis processzorarchitekt´ ura megemelésével szinte biztosan javul az alkalmaz´ asunk teljes´ıtménye, amennyiben az tartalmaz bárminem˝ u SIMD utas´ıt´ ass´ a alak´ıthat´ o részeket (ide tartoznak például a szövegekkel való m˝ uveletvégzések is) vagy lebeg˝opontos m˝ uveleteket. Viszont a régebbi processzorok, amelyek nem t´ amogatják az u ´jabb utas´ıtáskészletet nem fogják tudni futtatni a programot, az ugyanis ”érvénytelen utas´ıtás” hiba¨ uzenettel le fog ´ allni. Az optim´ alis minimum megállap´ıtásához tekints¨ uk az alábbi statisztik´ at:

35

Technol´ ogia Elterjedts´ eg SSE2 99.78% SSE3 99.18% SSE4.1 57.26% 6. t´ abl´ azat - Az SSE technológiák elterjedtsége A t´ abl´ azatban tal´ alhat´ o értékek a Steam Hardver Kérd˝o´ıvéb˝ol származnak, amelynek profilja a sz´ am´ıt´ ogépes játékok. Emiatt esélyes, hogy az átlagnál némiképp magasabb értékeket látunk. Ett˝ol f¨ uggetlen¨ ul azonban kijelenthetj¨ uk, hogy az SSE2-es utas´ıtáskészletet nyugodtan engedélyezhetj¨ uk, hiszen az SSE3-at is csak a felhasználók egy nagyon sz˝ uk rétegének nem t´ amogatja a processzora. Ezzel szemben az SSE4, amely az AVX el˝ott négy évvel, 2007-ben ker¨ ult a processzorokba, alig több mint a felhasználók felének gépében tal´ alhat´ o meg. Ezek alapj´ an azt mondhatjuk, hogy már csak a korszer˝ uség miatt is érdemes minden programot az SSE2 utas´ıtáskészlettel ford´ıtani (A Visual Studio nem biztos´ıt lehet˝ oség k¨ ulön az SSE3, SSSE3 és az SSE4 utas´ıt´ askészletek haszn´ alat´ ara), ha az alkalmazásunk az adott rendszeren gond nélk¨ ul fut (teh´ at t´ amogatva van az utas´ıtáskészlet), akkor semminem˝ u hátrány nem ér minket, maximum gyorsabban fog futni a szoftver¨ unk. Alacsony elterjedtsége miatt azonban sem az SSE4-et és ebb˝ol kifolyólag az AVX-et sem érdemes még minim´ alisan t´ amogatott processzorarchitekt´ uraként elvárni. A mi tesztjeinket teh´ at /arch:SSE2 ford´ıtási kapcsolóval ford´ıtottuk, amely a k¨ ovetkez˝ o eredményeket hozta: Teszteset ArrayCopy Parallel Fibonacci Abstraction StringCPP11

Id˝ o Id˝ o (/arch:SSE2) Sebess´ egn¨ oveked´ es 328.55 ms 320.88 ms 2.33% 889.07 ms 840.12 ms 5.51% 532.27 ms 516.52 ms 2.96% 264.56 ms 264.51 ms 0.02% 1560 ms 1390 ms 10.90% 7. t´ abl´ azat - A /arch kapcsoló hatása

A tesztjeink alapj´ an kijelenthetj¨ uk, hogy a teszteseteinkben nem mutatkozott jelent˝ osebb mérték˝ u sebességnövekedés, az utolsó tesztet lesz´ am´ıtva. Ennek ellenére azonban javasoljuk a minimálisan elvárt architekt´ ura megemelését el˝ obb-utóbb, hiszen az egy fejlettebb technológiát haszn´ al, amelyb˝ ol h´ atr´ anyunk biztosan nem, de el˝ony¨ unk esetleg lehet.

3.6

P´ arhuzamos k´ odgener´ al´ as

Mi´ ota a processzorok ´ orajeleinek frekvenciái abbahagyták a trendszer˝ u n¨ ovekedés¨ uket a p´ arhuzamos´ıtásra cs´ uszott át a fókusz. Az informatika ezen a´gazata jelenleg a t¨ obbmagos, többprocesszoros, több szám´ıtógépes rendszerekr˝ ol sz´ ol. Egy szoftverfejleszt˝o számára a párhuzamos´ıtás több szinten b´ır jelentéssel. A fejleszt˝o akár az egész párhuzamos´ıtást a kezébe veheti, ˝ o maga ir´ any´ıthatja a szálakat. Ebben az esetben azonban rengeteg id˝o megy el arra, hogy trivi´ alisan párhuzamos´ıtható feladatokat menedzseljen 36

kézzel, ami r´ aad´ asul a k´ od olvashatóságán is ronthat. Egy nagyon egyszer˝ u példa erre mondjuk egy tömb másolása. Ha a ford´ıtó semmilyen p´ arhuzamos´ıt´ ast nem végez el, hanem ehelyett mindent a programozónak kell megcsin´ alnia, akkor a k´ od jelent˝os része a k¨ ulönböz˝o szálak irány´ıtásáról fog sz´ olni. A m´ asik véglet az, amikor mindent a ford´ıtóra b´ızunk. Azonban sok esetben a ford´ıt´ oknak esély¨ uk sincs kitalálni, hogy mely részek p´ arhuzamos´ıthat´ oak és melyek nem anélk¨ ul, hogy a programozó erre b´ arminem˝ u utal´ ast tenne. Tegy¨ uk hozzá, hogy a vektorutas´ıtásokat jelen esetben nem tekintj¨ uk p´ arhuzamos´ıtásnak, hiszen most a többszál´ u alkalmaz´ asokr´ ol van sz´ o. Mivel a szálak kezelése jelenleg még nem egy nagyon széles k¨ orben elterjedt dolog, ezért a Visual Studio ezt a hatalmat nem veszi ki a kez¨ unkb˝ ol, és ¨ onmag´ at´ ol soha nem hoz létre k¨ ulön szálakat az alkalmaz´ asainkban. A két véglet k¨ oz¨ ott helyezkedik el a ford´ıtók dolgának megkönny´ıtésén alapul´ o, direkt´ıv´ akon kereszt¨ uli párhuzamos kódgenerálás. Ebben az esetben k¨ ul¨ onb¨ oz˝ o direkt´ıv´ akkal tudunk a ford´ıtónknak ”tippeket” adni, hogy a k¨ ovetkez˝ o k´ odrészletet esetleg megpróbálhatná párhuzamos´ıtani. Ehhez természetesen ´ atadhatunk extra információkat a ford´ıtónak, megkönny´ıtve ezzel a dolg´ at. Ilyen extra információ lehet például, hogy garantáljuk, hogy egy adott v´ altoz´ ot csak a k¨ ovetkez˝o kódrészlet használja, tehát egy másik szál azzal soha nem foglalkozik. A módszer hátránya, hogy nem rendelkez¨ unk akkora ir´ any´ıt´ assal a sz´ alak felet, mint az els˝o esetben. El˝onye viszont, hogy mivel csak direkt´ıv´ akr´ ol beszél¨ unk, ´ıgy tulajdonképpen nem része a tényleges forr´ ask´ odunknak, ´ıgy ki tudjuk kapcsolni a párhuzamos kód generálását (péld´ aul egy direkt´ıv´ aval, amellyel be-ki kapcsolhatjuk a párhuzamos´ıtásról sz´ ol´ o direkt´ıv´ ak figyelembe vételét), hogy a kódba bele kellene ny´ ulnunk, esetleges hib´ akat el˝ oidézve ez´ altal. Erre a megoldásra alapul a Visual Studio a´ltal alapb´ ol is t´ amogatott OpenMP nev˝ u API. Azonban nem sz¨ ukséges u ´j API-kat használni, ugyanis a Visual Studiónak van egy saj´ at be´ all´ıt´ asa, amelynek seg´ıtségével a ford´ıtó automatikusan tudja a ciklusainkat p´ arhuzamos´ıtani. Persze a ciklusok csak egy nagyon apró részét teszik ki a k´ odunknak, azonban jelenlét¨ uk messze nem elhanyagolható, és a be´ all´ıt´ as nagyon egyszer˝ u használata miatt egy próbát mindenféleképpen megérhet mindenkinek. Ez a bizonyos kapcsoló a /Qpar amely az általunk megjel¨ olt ciklusokat megvizsgálja és amennyiben lehet˝oséget lát rá, p´ arhuzamos´ıtja ˝ oket. A ciklusaink megjel¨ olése nem tesz mást, mint egy egyszer˝ u direkt´ıva haszn´ alat´ at. Ez a direkt´ıva a #pragma loop(hint parallel(n)). Az n egy nemnegat´ıv egész paraméter, amellyel megmondhatjuk, hogy a ciklusunkat h´ any sz´ alra ossza szét a ford´ıtó. Ha a paramétert 1-re áll´ıtjuk, azaz arra kérj¨ uk a ford´ıt´ ot, hogy egy szálon próbálja párhuzamos´ıtani a ciklusunkat, az olyan mint ha semmit sem ´ırtunk volna. Viszont a paraméter nulla értéke esetén a ford´ıt´ o megpr´ ob´ alja a maximalizálni a szálak számát. A tesztprogramunkat ez a k¨ ovetkez˝oképpen befolyásolta: 1 2 3 4 5

// ArrayCopy : a l g o r i t h m #pragma l o o p ( h i n t p a r a l l e l ( 0 ) ) f o r ( i n t i = 0 ; i < N; ++i ) { a[ i ] = b[ i ]; }

37

A t¨ obbi tesztesetben hasonlóképpen változott a kódunk. Sajnos a hardver¨ unk korl´ atolts´ aga miatt a mi eset¨ unkben az egyszerre futó szálak sz´ ama kett˝ oben maximaliz´ al´ odott. Ennek ellenére az eredményeinken ´ıgy is seg´ıtett ez az apr´ o tr¨ ukk: Teszteset ArrayCopy Parallel Fibonacci StringCPP11

Id˝ o Id˝ o (/Qpar) Sebess´ egn¨ oveked´ es 328.55 ms 300.21 ms 8.63% 889.07 ms 824.12 ms 7.31% 532.27 ms 502.18 ms 5.65% 1560 ms 1430 ms 8.33% 8. t´ abl´ azat - A /Qpar kapcsoló hatása

Az eredményeink alapj´ an elmondhatjuk, hogy a szoftvereink teljes´ıtménye egyértelm˝ uen megn˝ ott, ´ atlagosan 7.5%-kal. Bár tény, hogy itt már nem volt elég egy egyszer˝ u ford´ıt´ asi kapcsolót beáll´ıtani, a forráskódba is bele kellett ´ırni, azonban ennek a mértéke minimális, továbbá akár minden ciklus elé is beilleszthetj¨ uk a #pragma loop(hint parallel(0)) sort, hiszen amennyiben a ciklus nem p´ arhuzamos´ıthat´ o, akkor semmilyen hiba¨ uzenetet nem fogunk kapni, egészen egyszer˝ uen olyan lesz, mint ha a direkt´ıvánkat oda sem ´ırtuk ¨ volna. Osszegezve teh´ at, amennyiben semmilyen más párhuzamos´ıtási m´ odszert nem haszn´ alunk (saját kez˝ u szálkezelés, OpenMP, stb.), és szeretnénk minim´ alis er˝ ofesz´ıtéssel jav´ıtani alkalmazásaink teljes´ıtményein, akkor a Visual Studio saj´ at direkt´ıvákon kereszt¨ uli megoldása jó választás lehet.

3.7

A C++11 ´ es a mozgat´ o konstruktorok

A C++ leg´ ujabb, sokak ´ altal C++0x-ként emlegetett, majd vég¨ ul C++11 névre keresztelt szabv´ anya tavaly érte el hivatalosan a kész állapotát. Bár a Visual Studio a mai napig csak egy részét támogatja a szabványnak, van pár olyan, a j¨ ov˝ oben tal´ an kulcsfontosság´ uvá váló szerkezet, amelyet már a Visual Studio 2010-es verzi´ oja is t´ amogatott. Optimalizációs szempontból ezek köz¨ ul tal´ an a mozgat´ o konstruktor és a mozgató-hozzárendel˝o operátor a legjelent˝ osebb. Mivel err˝ ol a témáról még relat´ıve kevés szakirodalom létezik, r¨ oviden ismertetj¨ uk a problémát, amelyre ezek az u ´j konstrukciók megoldást ny´ ujtanak. Tekints¨ uk a StringCPP11 tesztest¨ unkben létrehozott szövegkezel˝o oszt´ alyunkat: 1 c l a s s MyString 2 { 3 char∗ s t r ; 4 public : 5 6 MyString ( ) : str ( nullptr ) 7 {} 8 9 MyString ( const char∗ s t r ) : 10 { 11 strcpy ( str , str ) ; 12 }

s t r (new char [ s t r l e n ( s t r ) + 1 ] )

38

13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

MyString ( const MyString& mystr ) : ) + 1]) { s t r c p y ( s t r , mystr . s t r ) ; }

s t r (new char [ s t r l e n ( mystr . s t r

MyString& operator=(const char∗ s t r ) { delete s t r ; s t r = new char [ s t r l e n ( s t r ) + 1 ] ; strcpy ( str , str ) ; return ∗ t h i s ; } MyString& operator=(const MyString& mystr ) { i f ( t h i s == &mystr ) return ∗ t h i s ; return operator=(mystr . s t r ) ; } ˜ MyString ( ) { delete s t r ; } }; extern const char∗ p i ; MyString GetMyString ( ) { return MyString ( p i ) ; }

Ezek ut´ an mi péld´ aul a következ˝o módon megh´ıvjuk a GetMyString f¨ uggvény¨ unket: 1 MyString s t r ; 2 // . . . 3 s t r = GetMyString ( ) ;

Ekkor a k¨ ovetkez˝ o met´ odusok fognak lefutni: 1. GetMyString() 2. Ez létrehoz egy lok´ alis példányt az osztályunkból: MyString(const char*) 3. Ehhez ´ at kell m´ asolnunk a szöveget az osztályunkba: strcpy(...) 4. Miut´ an visszatért¨ unk a GetMyString() f¨ uggvényb˝ol, átmásoljuk a visszakapott oszt´ alyunkat: MyString::operator=(const MyString&) 5. MyString::operator=(const char*) ´ asoljuk az ideiglenes példányunkból a véglegesbe a szöveget: 6. Atm´ strcpy(...) 7. Vég¨ ul megsemmis¨ ul az ideiglenes példányunk: MyString()

39

Mint azt észrevehetj¨ uk, az ideiglenes MyString példányunk tulajdonképpen teljesen feleslegesen j¨ ott létre, hiszen ha lenne rá lehet˝oség¨ unk, akkor sokkal jobban j´ arn´ ank vele, hogyha rögtön a célobjektumunkba tudnánk másolni a sz¨ oveget, de legal´ abb ne kellene két teljes érték˝ u példányt létrehoznunk, megdupl´ azva ez´ altal a m´ asolandó adat mennyiségét. A példánkban ez 9 KB helyett 18 KB adatot jelent, ami talán nem t˝ unhet soknak, de ez a probléma rendk´ıv¨ ul szélesk¨ or˝ u, el˝ oj¨ on vektorok, listák és további tárolók esetén is, amelyek komplexebb alkalmazások esetén rengeteg adatot tartalmazhatnak, amelyek j´ o eséllyel szintén kétszer annyi másolást fognak eredményezni. Erre a problém´ ara ny´ ujt megoldást a C++11 egyik u ´jdonsága, az u ń. mozgat´ asi szemantika (move semantics). [3] Ez a bal-értékek (lvalue) és jobb-értékek (rvalue) megk¨ ulönböztetésén alapszik. A bal-értékek olyan kifejezések, amelyeknek a programozó a forráskód ´ırása során tudja venni a c´ımét az & (address-of) oper´ atorral. Régebben a bal-érték defin´ıciója az volt, hogy egy olyan b´ armi, amelyhez hozzá lehet rendelni, azonban ez a const kulcssz´ o megjelenésével megváltozott. Ezzel szemben a jobb-értékek olyan értékek, amelyeknek a programozó nem tudja el˝ore venni a c´ımét, azonban a ford´ıt´ o igen. Erre egy egyszer˝ u példa a (3 + 4) kifejezés, amely elé nem tehet¨ unk ki egy address-of operátort, azonban a program futása során mégis lesz c´ıme, amelyhez a ford´ıtó hozzá is tud férni, és ezáltal k¨ ulönböz˝o optimaliz´ aci´ os lehet˝ oségek ny´ılnak meg el˝ott¨ unk. A jobb-értékekre gyakran ideiglenes ”v´ altoz´ okként” szoktak tekinteni, ugyanis a legtöbb esetben a jobb-értékek szinte azonnal megsemmis¨ ulnek. Erre példa az el˝obb bemutatott ideiglenes MyString péld´ anyunk, amelyre csak azért volt sz¨ ukség, hogy a megh´ıvott f¨ uggvény és a célobjektum közé egyfajta közvet´ıt˝oi szerepet bet¨ olts¨ on. Ezekre a jobb-értékekre hivatkozni is lehet, méghozzá a && használatával, amely tulajdonképpen egy referenciát ny´ ujt nek¨ unk egy jobb-értékre. Emiatt a ”referencia” sz´ o kétértelm˝ uvé válik, ezért megk¨ ulönböztet¨ unk bal-referenciát és jobb-referenci´ at. A szemléltetés kedvéért tekints¨ uk az alábbi példát, amely szeretné a π sz´ amjegyeit feldolgozni valamilyen formában: 1 void f ( const MyString& p i ) 2 { 3 // . . . 4 strcpy ( l o c a l b u f f e r , pi ) 5 // . . . 6 // Modify t h e s t r i n g 7 }

Ez a klasszikus v´ altozat. Ebben az esetben kénytelenek vagyunk lemásolni az egész sz¨ oveget, annak ellenére, hogy lehet, hogy paraméterként egy olyan v´ altoz´ ot kaptunk, ami csak ennek a f¨ uggvényh´ıvásnak a kedvéért jött létre. 1 void f ( MyString&& p i ) 2 { 3 // Modify t h e s t r i n g t h r o u g h t h e parameter 4 }

Ha viszont meg´ırjuk ezt a f¨ uggvényt is, akkor biztosak lehet¨ unk benne, hogy ha ebben a f¨ uggvényben tart´ ozkodunk, akkor a megkapott paraméterre már senkinek nem lesz sz¨ uksége, ezért anélk¨ ul hogy azt lemásolnánk, nyugodt sz´ıvvel manipul´ alhatjuk a paramétert, hiszen a f¨ uggvény¨ unk lefutása után u ´gyis meg

40

fog semmis¨ ulni. Az f f¨ uggvény megh´ıvásakor tehát a paraméter t´ıpusa sokkal nagyobb szerepet kaphat, mint eddig. Amennyiben egy lokális változót adunk at neki, akkor a régi, j´ ´ ol bev´ alt módszer marad, tehát a fels˝o változatot fogjuk megh´ıvni. Azonban ha péld´ aul f(GetMyString())-ként h´ıvjuk meg, akkor már egy ideiglenes v´ altoz´ ot adunk át paraméterként, ´ıgy az irány´ıtás a második v´ altozatn´ al fog kik¨ otni. Ezt a m´ odszert a konstruktorok esetében is lehet használni, hiszen sokszor egy ideiglenes v´ altoz´ on kereszt¨ ul hozunk létre egy u ´jat, ami szintén megduplázza a sz¨ ukséges m´ asol´ ast. Mozgat´ o konstruktort a következ˝oképpen lehet létrehozni: 1 MyString ( MyString&& mystr ) : 2 { 3 mystr . s t r = n u l l p t r ; 4 }

s t r ( mystr . s t r )

Itt az l´ athat´ o, hogy el˝ osz¨ or egyszer˝ uen átvessz¨ uk a paramétert˝ol a char* v´ altoz´ oj´ at, amely az eddigi C++ világban meglehet˝osen szokatlan gyakorlat lett volna. Ezek ut´ an r´ aad´ asul a paraméter str változóját még ki is nullázzuk. Ezt a m˝ uveletet, amikor a másik osztálytól egész egyszer˝ uen ”elvessz¨ uk” a v´ altoz´ oit, lop´ asnak h´ıvjuk. Azonban nézz¨ uk meg, miért is jó a lopás. Mivel tudjuk, hogy a paraméterként kapott osztály egy jobb-érték, ezért tudjuk, hogy hamarosan meg fog semmis¨ ulni, senkinek sincs már sz¨ uksége rá. Ezért neki sincs sz¨ uksége a v´ altoz´ oira! Ha már u ´gyis rendelkezik egy mutatóval, ami m¨ og¨ ott ott van az egész sz¨ oveg, miért másoljuk azt át? Egész egyszer˝ uen csak tegy¨ uk r´ a mi a kez¨ unket, hiszen pillanatokon bel¨ ul megh´ıvásra ker¨ ul a paraméter destruktora és csak ”kidobnánk” egy teljesen céljainknak megfelel˝o sz¨ oveget. Ezért teh´ at a konstruktor inicializáló listában átmásoljuk a mutató értékét, majd a konstruktor testében kinullázzuk a másik osztály változóját. Erre azért van sz¨ ukség, mert ha ott meghagynánk az értéket, akkor a destruktor´ anak megh´ıv´ asakor arra a mutatóra megh´ıvna egy delete-et, amely t¨ onkretenné a sz¨ oveg¨ unket. Így viszont a delete egy nullpointerre lesz megh´ıvva, amely teljesen ´ artalmatlan. Az alap gondolat teh´ at az, hogy miel˝ott nekiállnánk átmásolni a dolgokat, el˝ osz¨ or pr´ ob´ aljunk meg minden használható adatot átmozgatni a saját ir´ any´ıt´ asunk al´ a, majd az ideiglenes változót olyan állapotba kell hoznunk, hogy annak megsemmis¨ ulése senki számára ne okozhasson gondot. Természetesen ha van mozgató konstruktor, akkor lennie kell egy u ´j hozz´ arendelési oper´ atornak is. Azonban mivel ezt az elnevezést már haszn´ aljuk, ezért itt is bevezet¨ unk két u ´j elnevezést: a másoló-hozzárendel˝o oper´ atort (copy-assignment operator) és a mozgató-hozzárendel˝o operátort (move-assignment operator). Ennek kinézete a következ˝o: 1 MyString& operator=(MyString&& mystr ) 2 { 3 delete s t r ; 4 s t r = mystr . s t r ; 5 mystr . s t r = n u l l p t r ; 6 return ∗ t h i s ; 7 }

Az els˝ o dolog amit érdemes megjegyezni, hogy itt nincs sz¨ ukség megvizsg´ alni, hogy ¨ onmagunkhoz rendel¨ unk-e hozzá. Ennek az a magyarázata,

41

hogy a kapott paraméter egy jobb-érték, tehát nem lehet hozzárendelni semmit. Azonban mi egy mozgató-hozzárendel˝o operátorban vagyunk, ez azt jelenti, hogy a *this egy bal-érték. Mivel természetesen semmi nem lehet egyszerre bal-érték és jobb-érték is, ezért kizárt, hogy saját magunkat kapjuk meg paraméterként. Ezt lesz´ am´ıtva minden a már megszokott módon megy. Felszabad´ıtjuk az eddig használt er˝oforrásainkat, ellopjuk a paraméter haszn´ alhat´ o v´ altoz´ oit, biztons´ agosan megsemmis´ıthet˝ové tessz¨ uk a paramétert, majd visszatér¨ unk. Mivel sokszor hasznos, ha a hozzárendel˝o operátoraink és másoló/mozgató konstruktoraink k¨ oz¨ ul csak a konstruktort ´ırjuk meg, az operátorhoz pedig egyszer˝ uen felhaszn´ aljuk a már meg´ırt konstruktort, ezért érdemes megjegyezni a jobb-referenciák egy érdekes tulajdonságát. Mivel egy jobb-referenci´ anak van neve, és f¨ uggvényparaméterként is megjelenik, ´ıgy természetesen lehet hozz´ arendelni és a c´ımét is venni. Ez azt jelenti, hogy a jobb-referencia ¨ onmag´ aban egy bal-érték. Emiatt a következ˝o naiv pr´ ob´ alkoz´ as nem fog m˝ uk¨ odni: 1 MyString& operator=(MyString&& mystr ) 2 { 3 delete s t r ; 4 ∗ t h i s = MyString ( mystr ) ; 5 return ∗ t h i s ; 6 }

Ebben az esetben ugyanis a mystr egy bal-érték, ezért a MyString(const MyString&), vagyis a m´ asol´ o konstruktorunk lesz megh´ıvva. Ez teljesen logikus is, hiszen nek¨ unk ebben a f¨ uggvényben még sz¨ ukség¨ unk lehet a mystr változó tartalm´ ara, azonban ha a mozgató konstruktorunknak jobb-referenciaként lenne atadva, akkor az megsemmis´ıtené a változónkat, amely megakadályoz minket a ´ tov´ abbi haszn´ alat´ aban. Emiatt mindig explicite jelezn¨ unk kell, hogy mi jobbreferenciaként szeretnénk ´ atadni egy változót. Erre a legegyszer˝ ubb megoldás a castol´ as: 1 MyString& operator=(MyString&& mystr ) 2 { 3 delete s t r ; 4 ∗ t h i s = MyString ( s t a t i c c a s t <MyString&&>(mystr ) ) ; 5 return ∗ t h i s ; 6 }

Azonban a C++11 standard könyvtárait kiegész´ıtették rengeteg u ´j f¨ uggvénnyel, amelyek k¨ oz¨ ul az egyik pontosan a változók jobb-referenciává tételéért, m´ as néven mozgat´ asáért felel: 1 2 3 4 5 6 7 8

#include < u t i l i t y > MyString& operator=(MyString&& mystr ) { delete s t r ; ∗ t h i s = MyString ( s t d : : move ( mystr ) ) ; return ∗ t h i s ; }

Ezeket a f¨ uggvényeket hozzáadva az osztályunkhoz a következ˝oképpen v´ altozik a megh´ıvott f¨ uggvények listája: 42

1. GetMyString() 2. Ez létrehoz egy lok´ alis példányt az osztályunkból: MyString(const char*) 3. Ehhez ´ at kell m´ asolnunk a szöveget az osztályunkba: strcpy(...) 4. Visszatért¨ unk a GetMyString() f¨ uggvényb˝ol, azonban egy ideiglenes v´ altoz´ o van a kez¨ unkben, ezért a mozgató-hozzárendel˝o operátort h´ıvjuk meg: MyString(MyString&&) 5. Vég¨ ul megsemmis¨ ul az ideiglenes példányunk: MyString() Teh´ at megsp´ oroljuk az adatmásolás felét, amely komplex alkalmazások esetén ´ ori´ asi el˝ onyt jelenthet. Amint az l´ athat´ o, a mozgató konstruktorok és mozgató-hozzárendelési oper´ atorok meg´ır´ asa tov´ abb tart, mint egy ford´ıtási kapcsoló átáll´ıtása, azonban a hat´ asai is j´ oval nagyobbak. A tesztjeink köz¨ ul egyed¨ ul a StringCPP11 tartalmazott olyan kódot, amelyre alkalmazható volt ez a fajta optimaliz´ aci´ o, ennek az eredménye a következ˝o lett: Teszteset Id˝ o Id˝ o (C++11) Sebess´ egn¨ oveked´ es StringCPP11 1560 ms 589.70 ms 62.20% 9. t´ abl´ azat - A mozgató szemantika hatása A t¨ obb mint 60 sz´ azalékos teljes´ıtménynövekedés magáért beszél, mindenféleképpen érdemes implementálni a mozgatási szemantikát az alkalmaz´ asainkban. Amennyiben ezt nem tudjuk megtenni, de esetleg haszn´ alunk a standard k¨ onyvtárakból osztályokat, már akkor is érdemes lehet u ´jraford´ıtani az alkalmaz´ asainkat, ugyanis a legtöbb ford´ıtó már a C++11-re aktualiz´ alt k¨ onyvt´ arakat tartalmazza. Tehát ha legutoljára 2008-ban ford´ıtottuk le a rengeteg vektort használó alkalmazásunkat, akkor már egy egyszer˝ u u ´jraford´ıt´ ast´ ol is jelent˝osen n˝ohet a teljes´ıtménye a szoftver¨ unknek, amennyiben rendelkez¨ unk egy u ´jabb ford´ıtóval, amely tartalmazza az u ´j k¨ onyvt´ arakat.

3.8

A GCC ford´ıt´ oval el´ ert eredm´ enyek

Noha a mi vizsg´ alatunk a Visual Studióról szólt, tett¨ unk egy rövid o¨sszehasonl´ıt´ ast a GCC ford´ıtóval is. Itt nem tett¨ unk próbát a k¨ ulönböz˝o kapcsol´ ok egyenkénti hat´ asainak megfigyelésére, hanem csak ezt az egy, saját kez˝ uleg ¨ ossze´ all´ıtott kombin´ aciót ford´ıtottuk le: [6] -fabi-version=6 A C++ ABI (Application Binary Interface) verzióját hat´ arozza meg. A hatos érték a leg´ ujabb, C++11-et is támogató v´ altozat. -fno-rtti Kikapcsolja az RTTI (RunTime Type Information) generálását. -fstrict-enums Optimaliz´ aci´ os lehet˝oséget biztos´ıt a ford´ıtó számára azáltal, hogy feltételezi, hogy az egészb˝ol enumerációba való konverzió mindig érvényes (teh´ at mindig létez˝o értéket konvertálunk). 43

-O3 Az optimaliz´ aci´ o mértékét a lehet˝o legmagasabbra áll´ıtja. -Ofast Engedélyezi a ford´ıt´ onak, hogy eltérjen a szabványoktól amennyiben az gyorsabb k´ odot eredményez. -funsafe-loop-optimizations Engedélyezi a ford´ıtónak, hogy még jobban optimaliz´ alja a ciklusokat azáltal, hogy felteszi, hogy a ciklusfeltételek egy id˝ o ut´ an mindig hamisak lesznek (nincs végtelen ciklus), és hogy a ciklusv´ altoz´ ok sosem csordulnak t´ ul. -fipa-pta Hat´ as´ ara a ford´ıtó sokkal nagyobb mértékben vizsgálja át a programunkat optimaliz´ aciós lehet˝oség után kutatva. Ez nagy mértékben megn¨ ovelheti a ford´ıt´ as er˝oforrásigényét. -std=c++11 A haszn´ alt C++ szabványt lehet fele beáll´ıtani. -march=core2 Specifik´ alhatjuk, hogy mely processzorcsaládra szeretnénk leford´ıtani a k´ odot, amely számos egyéb optimalizációs lehet˝oséget nyit meg. A mi eset¨ unkben nem érzékelt¨ unk semmi hatást. Sajnos a ford´ıt´ as sor´ an nem volt lehet˝oség¨ unk 64-bites kód generálására, ´ıgy a 32-bites v´ altozatokat hasonl´ıtjuk össze. Az elért eredményeink a következ˝oek: Teszteset Id˝ o (Visual Studio) Id˝ o (GCC) Sebess´ egn¨ oveked´ es ArrayCopy 546.19 ms 515.60 ms 5.60% Parallel 995.56 ms 864.40 ms 13.17% Fibonacci 1273 ms 1185 ms 6.91% StringCPP11 1790 ms 1020 ms 43.02% 10. t´ abl´ azat - A GCC ford´ıtóval elért eredményeink

Mint az l´ athat´ o, a Visual Studio alapbeáll´ıtásai minden esetben alul maradtak az ´ altalunk ¨ ossze´ all´ıtott GCC beáll´ıtásokkal szemben. A GCC sokkal nagyobb szabads´ agot ad nek¨ unk az optimalizációs beáll´ıtások kezelése u ¨gyében. B´ ar tényleges sebességnövekedésr˝ol beszélhet¨ unk, hasonló eredményeket a Visual Studióval is el tudtunk érni, miután saját kez˝ uleg beleny´ ultunk a ford´ıt´ asi be´ all´ıtásokba. Az egyetlen jelent˝os eltérést a StringCPP11 esetén l´ athatjuk, ahol a GCC sokkal gyorsabbnak bizonyult. Ennek h´ atterében feltehet˝ oleg az áll, hogy a GCC RVO (Return Value Optimization) technik´ aja m´ ar alapból is alkalmazta a C++11-es lehet˝oségeket, m´ıg a Visual Studio ezt mag´ atól nem teszi meg.

44

4

¨ Osszefoglal´ as

A dolgozat célja az volt, hogy megvizsgáljuk, lehetne-e még fokozni a ford´ıt´ oink optimaliz´ al´ asi képességeit azáltal, hogy a manuálisan beáll´ıtható ford´ıt´ asi feltételeket kielemezz¨ uk és megfelel˝oen alkalmazzuk. Ehhez ép´ıtett¨ unk egy tesztrendszert, amely a pontosság kedvéért kernel-módból vezérelve, hardveresen mérte a programok futási idejét. B´ ar a tesztjeink csup´ an a valós alkalmazásokban el˝oker¨ ul˝o sz˝ uk keresztmetszeteknek csak egy részét fedték le, szinte minden esetben tudtunk pozit´ıv eredményeket produk´ alni, még ha azok csak pár százalékkal is voltak ¨ jobbak az alapbe´ all´ıt´ asokn´ al. Osszegz´ esképp kijelenthetj¨ uk, hogy egy kis odafigyeléssel és minim´ alis extra munkával 5-10 százalékos teljes´ıtményn¨ ovekedést érhet¨ unk el a ford´ıtónk k¨ ulönböz˝o beáll´ıtásainak all´ıtgat´ ´ as´ aval. Megvizsg´ altuk a C++ leg´ ujabb szabványát is, amely jelent˝os u ´j´ıtásokat hozott be a nyelvbe. Ezek egyike a mozgatási szemantika, amelyekkel több mint m´ asfélszeresére siker¨ ult növeln¨ unk az alkalmazásunk teljes´ıtményét. Noha ehhez m´ ar nem elég egy-két beáll´ıtást átáll´ıtani, ehhez már u ´j dolgok tanul´ as´ ara és gyakorl´ as´ ara van sz¨ ukség, ami id˝o- és er˝oforrás-igényes lehet, azonban a hat´ asa szerint¨ unk magáért beszél. Mivel a 21. sz´ azadi életnek a szám´ıtógépek kritikus pontjai, nagyon fontos, hogy minél hatékonyabban tudjunk vel¨ uk dolgozni. Ennek ellenére azonban a mai napig rengetegszer kell a szám´ıtógépre várni, ami sokszor blokkolja a ´ munk´ ankat. Ugy gondoljuk, hogy a vizsgálatunk eredménye ezen tud jav´ıtani, amely komolyabb alkalmaz´ asok esetén akár sok másodperces megtakar´ıtást is jelenthet.

45

Irodalomjegyz´ ek [1] Walter Oney, Programming the Microsoft Windows Driver Model, 2nd Edition, 2003. [2] Real Time Devices USA, Inc., PCI4520/DM7520/DM7530 User’s Manual Version 2.0, 2003. [3] Scott Meyers, Presentation Materials: Overview of the New C++ (C++11), 2012. [4] Steam Hardware Survey http://store.steampowered.com/hwsurvey/, 2012 szeptember [5] Compiler Switches for Visual Studio 2012 (C++), http://msdn. microsoft.com/en-us/library/9s7c9wdw(v=vs.110).aspx, Microsoft Developer Network, 2012. [6] Compiler Switches for GCC, http://gcc.gnu.org/onlinedocs/gcc/ Option-Summary.html, 2012.

46

Budapesti Műszaki és Gazdaságtudományi Egyetem. Villamosmérnöki és Informatikai Kar. TDK dolgozat. Hajnal Erik pit6dc. Konzulens: BME-HVT

Recommend Documents