Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Enkel Vela-Nje Krahasim Midis Arkitekturave te Driver

Enkel Vela-Nje Krahasim Midis Arkitekturave te Driver

Enkel Vela: Kernelat e sistemeve te operimit me modern perbehen nga nje numer komponentesh si nje menaxher memorje,
nje skedulues procesesh, shtresa e abstragimit te hardware-it (HAL - Hardware Abstraction Layer) dhe menaxheri i sigurise.

Enkel Vela

March 18, 2017
Tweet

More Decks by Enkel Vela

Other Decks in Education

Transcript

  1. Enkel Vela: Nje Krahasim Midis Arkitekturave te Driver-ave ne Linux

    dhe Windows 1. Hyrje Kernelat e sistemeve te operimit me modern perbehen nga nje numer komponentesh si nje menaxher memorje, nje skedulues procesesh, shtresa e abstragimit te hardware-it (HAL - Hardware Abstraction Layer) dhe menaxheri i sigurise. Kerneli mund te perfytyrohet si nje kuti e zeze qe duhet te dije si te bashkeveproje me llojet e shumta dhe te ndryshme te pajisjeve hardware qe ekzistojne dhe me akoma me shume pajisje qe ende nuk ekzistojne. Krijimi i nje kerneli qe ka funksionalitetet per bashkeveprim me te gjitha pajisjet hardware qe njihen eshte i mundur por jo praktik. Do te konsumonte pa qene nevoja shume resurse te sistemit. 1.1 Modulariteti i Kernelit Nje kernel nuk pritet te dije se si te bashkeveproje me lloje te reja pajijsjesh qe nuk ekzistonin ne kohen qe ai u krijua. Ne vend te kesaj Kernelat e sistmeve te operimit me modern lejojne qe funksionalitetet e tyre te zgjerohen me shtimin e moduleve te driver-ave te pajisjeve gjate ekzekutimit. Nje modul ve ne jete funksionalitetin qe do ti lejoje kernelit te bashkeveproje me nje pajisje te re te caktuar. Cdo modul ve ne jete nje rutine qe kerneli do ta therrase ne kohen e ngarkimit te modulit dhe nje rutine tjeter qe therritet ne kohen e heqjes se modulit. Modulet gjithashte vene ne jete shume rutina qe perdoren per transferimet e I/O te te dhenave nga dhe ne drejtim te pajisjes, si dhe nje rutine per te vene ne qarkullim instruksione I/O te kontrollit drejt pajisjes. Te mesipermet i takojne arkitekturave te driver-ave si ne Linux ashtu edhe ne Windows. 1.2 Organizimi i ketij dokumenti Materiali ne kete dokument eshte i ndare ne pjeset e meposhteme: • Arkitektura e pergjithshme e driver-ave ne te dy sistemet e operimit (pjesa 2) • Komponentet e akitektures se driver-ave per secilin sistem operimi (pjesa 3) • Venia ne jete e nje driver-i qe kryen I/O tek buffer-i i nje kerneli (pjesa 4) • Mjediset dhe pajisjet zhvilluese te driver-ave qe ofron secili sistem operimi per zhvilluesit (pjesa 5) 2. Arkitekturat e driver-ave te pajisjeve Nje driver pajisjeje lejon funksionimin e nje pjese hardware duke vene ne pah nje nderfaqe programimi qe i jep mundesine nje pajisjeje te kontrollohet nga jashte nga aplikacione dhe pjese te sistemit te operimit. Kjo pjese tregon per arkitekturat e driver-ave aktualisht ne perdorim ne dy prej sistmeve te operimit me te perdorur, MS Windows dhe Linux, si dhe per origjinen e arkitekturave te tyre. 2.1 Origjina e Arkitektures se Driver-ave te Linux-it Meqenese origjina e Linux-it eshte sistemi UNIX kuptohet qe arkitektura e tij do jete shume e ngjashme me ate te sistemeve UNIX. Sistemet e operimit UNIX i shohin pajisjet si nyje te sistemit te skedareve. Pajisjet paraqiten si nyje te vecanta te skedareve qe ndodhen ne nje dosje te caktuar qe ne fillim per te mbajtur hyjre te tipit nyje pajisjeje te sistemit te skedareve. Qellimi i paraqitjes se pajisjeve si nyje te sistemit te skedareve eshte qe ti jepet mundesia aplikacioneve te aksesojne
  2. pajisjet ne nje menyre te pavarur nga pajisja. Aplikacionet mundet

    ende te kryejne veprime te varura nga pajisja me ane te nje veprimi kontrolli I/O mbi pajisjen. ..... Ekzistojne dy tipe pajisjesh ne UNIX: char dhe block. Driver-at e pajisjeve char menaxhojne pajisje qe aksesohen ne menyre sekuenciale pa perdorimin e buffer-ave. Driver-at e pajisjeve block menaxhojne pajisje ku aksesi i cfardoshem eshte i mundur dhe te dhenat aksesohen ne blloqe. Gjithashtu ne rastin e driver-ave block perdoren edhe buffer-a. Linux-i ruan shume nga arkitektura e UNIX-it me ndryshimin qe ne Linux perdorimi i Sistemit Virtual te Skedareve (VFS – Virtual File System) mjegullon ndryshimet midis pajisjeve char dhe block. Linux-i gjithashtu fut nje tip te ri pajisjeje, pajisjen network. Driver-at e pajisjeve network aksesohen ne nje menyre te ndryshme nga ato te char dhe block. Nje bashkesi API-sh e ndryshme nga API I/O i sistemit te skedareve perdoret, si p.sh socket API, qe perdoret per te aksesuar pajisjet e rrjetit. 2.2 Origjina e Arkitektures se Driver-ave te Windows-it Ne 1980 Microsoft-i mori licencen per sitemin e operimit UNIX te Bell lab. dhe me vone e publikoi ate si sistemi i operimit XENIX. Me daljen e IBM PC-ve te para ne 1980 u publikua edhe versioni 1 i MS DOS-it. Ky version kishte nje arkitekture te driver-ave te ngjashme me ate te sistemeve UNIX te bazuar ne XENIX. Ndryshimi me sistemet UNIX ishte se sistemi i operimit vinte me driver-a te parainstaluar per pajisjet me te zakondeshme. Pajisjet nuk paraqiteshin me si nyje te sistemit te skedareve por i viheshin emra te rezervuar, p.sh CON i vendosej tastieres ose ekranit, PRN printerit dhe AUX portava seriale. Aplikacionet mund te hapin pajisjet dhe te marrin ne dorezim driver-at e lidhur me te njelloj sic do te benin me nje nyje te sistemit te skedareve dhe mund te kryejne I/O ne to. Sistemi i operimit perkthente emrat e rezervuar te pajisjeve ne pajisje qe driver-at e tij menaxhonin. Versioni 2 i MS DOS-it futi konceptin e driver-ave te ngarkueshem. Fakti qe Microsoft-i e kishte bere publike nderfaqen e arkitektures se driver-ave beri qe prodhues te trete te shtyheshin per te prodhuar pajisje te reja. Driver-at per keto pajisje tanime mund te jepeshin nga prodhuesit e hardware-eve dhe mund te ngarkoheshin/shkarkoheshin manualisht ne kernel gjate kohes se ekzekutimit. Me pas Microsoft-i publikoi Windows 3.1-shin. Ky sistem kishte mbeshtetje per shume me teper pajisje dhe perdorte nje arkitekture te mbeshtetur ne MS DOS. Me sistemet e mevonshme te operimit Windows 95, 98 dhe NT Microsoft-i paraqiti WDM-ne (Windows Driver Mode). WDM-ja u krijua sepse Microsoft-i deshironte te bente kodin burim te driver-ave te pajisjeve te pajtueshem me te gjithe sistemet e tij te reja te operimit. Keshtu perparesia e krijimit te driver-ave qe i binden WDM-se eshte se nje driver pasi krijohet thjesht duhet te rikompilohet ne menyre qe te jete i perdorshem ne sistemet e mevoneshme te operimit te Microsoft-it. 2.3 Arkitektura e Driver-ave ne Windows Ka dy lloje driver-ash ne Windows: legacy dhe Plug and Play (PnP). Do te perqendrohemi tek driver- at PnP pasi te gjithe driver-at duhet te jene te tille nese eshte e mundur. Driver-at PnP jane te lehte ne perdorim pasi nevojitet nje perpjekje minimale nga perdoruesit per ti instaluar ato. Nje tjeter perparesi e driver-ave PnP eshte se ato ngarkohen nga sistemi i operimit vetem kur nevojiten dhe keshtu nuk zene pa nevoje burimit e sistemit. WDM-ja eshte modeli standart i percaktuar nga Microsoft-i dhe perdoret ne te gjithe sistemet e rinj te operimit. 3.1.2.1 Arkitektura WDM e Driver-ave. Ka tre klasa driver-ash WDM: filtruese (filter), funksionale (functional) dhe bus. Ato formojne radhen e treguar ne figuren 2.3. Per me teper driver-at WDM duhet te jene te dijesuar per PnP-ne, te perkrahin menaxhimin e energjise(fuqise) dhe Windows Management Instrumentation. Figura 2.3 tregon se si te dhena dhe mesazhe shkembehen midis shtresave te ndryshme te driver-it. Nje strukture standarte qe quhet I/O Request Packet (IRP) perdoret per komunikimin. Sa here qe behet nje kerkese nga nje aplikacion tek nje driver, menaxheri I/O nderton nje IRP dhe e kalon ate poshte tek driver-i qe e proceson ate dhe kur mbaron ben “kompletimin” e IRP-se. Jo te gjitha IRP-te
  3. filtrohen poshte deri tek driver-i bus. Disa IRP trajtohen nga

    shtresat e mesiperme dhe i kthehen menaxherit I/O prej andej. Aksesimi hardware i pajisjes behet nepermjet nje shtrese abstragimi te hardware-it. 2.4 Arkitektura e Driver-ave ne Linux Driverat ne Linux paraqiten si module qe jane pjese kodi qe zgjerojne funksionalitetet e kernelit te Linux-it. Modulet mund te shtresezohen sic tregohet ne figuren 2.4. Komunikimi midis moduleve arrihet nepermjet thirrjeve te funksioneve. Ne kohen e ngarkimit nje modul eksporton te gjitha funksionet qe ai do ti bej publike ne nje tabele simbolesh qe mirembahet nga kerneli i Linux-it. Keto funksione tanime jane te dukshme per te gjitha modulet. Aksesimi i pajisjeve behet nepermjet nje shtrese abstragimi te hardware-it, qe jetesohet sipas platformes hardware-ike per te cilen kerneli eshte kompiluar, p.sh x86 ose SPARC.
  4. 2.5 Arkitekturat e Driver-ave te Linux-it dhe Windows-it te krahasuara

    Sic mund te shihet nga figurat 2.3 dhe 2.4, ka disa ngjashmeri midis dy sistemeve te operimit. Ne te dy sistemet driver-at jane komponente modular qe zgjerojne funksionet e kernelit. Komunikimi midis shtresave te driver-ave ne Windows arrihet me perdorimin e IRP-ve qe kalohen si argumenta tek funksionet standarte te sistemit dhe funksionet e percaktuara nga driver-i, ndersa ne Linux perdoret therritja e funksioneve me parametra te pershtatur sipas driver-it. Windows-i ka komponente te vecanta te kernelit per menaxhimin e PnP, I/O dhe Fuqise. Keta komponente i dergojne mesazhe driver-ave duke perdorur IRP-te ne momente te caktuar. Ne Linux nuk ka dallime te qartezuara midis moduleve te shtresezuar, p.sh modulet nuk kategorizohen ne driver-a bus, funksional ose filtrues. Nuk ka nje menaxher Pnp ose te Fuqise ne kernel qe te dergoje mesazhe te standartizuar tek modulet ne momente te caktuar. Kerneli mund te kete te ngarkuara module qe jetesojne Menaxhimin e Fuqise ose funksionalitetin PnP por nderfaqa e ketyre moduleve tek driver-at nuk eshte e percaktuar qartesisht. Ky funksionalitet ka mundesi qe te shtohet ne kernelat e ardhshem te Linux-it meqenese ky kernel eshte gjithmone ne zhvillim. Ne momenti kur kerneli i ka kaluar te dhena nje driver-i, qe eshte pjese e rradhes se moduleve, te dhenat mund te ndahen me driver-a te tjere te rradhes me ane te nje nderfaqe te posacme per ate bashkesi driver-ash. Ne te dy ambjentet aksesimi i hardware-it me ane te nje nderfaqe HAL jetesohet per platformen e caktuar per te cilen kerneli eshte kompiluar, p.sh x86, SPARC, etj. Nje vecori e perbashket e te dy
  5. arkitekturave eshte fakti qe driver-at jane module qe mund te

    ngarkohen ne kernel gjate kohes se ekzekutimit. Secili modul ka nje pike hyrje qe kerneli e njeh dhe nga ku ai mund te filloj ekzekutimin e kodit. Nje modul gjithashtu permban rutina qe kerneli i njeh dhe i therret sa here qe nje veprim I/O i kerkohet nje pajisjeje te menaxhuar nga ai modul. Kjo i lejon kernelit te pajise shtresen e aplikimit me nje nderfaqe te pavarur nga pajisja. Nje krahasim me i thelle i komponenteve driver nga te dy arkitekturat jepet me poshte ne pjesen 3.3. 3. Komponentet e driver-ave Procesi i krijimit te nje paisje driver kerkon njohuri se si paisja HW shoqeruese pritet te operoje. Psh cdo paisje do lejoje klientin e tij te lexoje te dhena dhe te shkruaje te dhena ne te. Ne kete seksion komponentet e driverave qe duhen implementuar nga gjithe driverat jane prezantura po aq mire sin je krahasim i komponenteve te driverave te 2 sistemeve te operimit. Gjithashtu prezantohet implementimi i nje driver qe performon I/O ne nje buffer kernel. Seksioni konkludon me nje shikim tek ambient i zhvillimit te driverave dhe lehtesite e ofruara nga OS. 3.1 Komponentet e driver-ave Windows Driverat ne Windows konsistojne ne rutina te ndryshme.Disa jane te domosdoshme te tjerat opsionale.Ky seksion prezanton rutinat qe cdo driver duhet te implementoje,Nje paisje driver ne Windows prezantohet nga nje structure e quajtur DriverObject.Eshte e nevojshme te paraqesesh nje driver me nje structure si objekti driver sepse kernel implementon rutina te ndryshme qe mund te performohen per cdo driver.Keto rutina te diskutuara ne seksionet e meposhtme veprojen ne nje object driver. 3.1.2.1 Instalimi i driver-ave Cdo paisje driver ne Windows permban nje rutine te quajtur DriverEntry.Sic e thote edhe vete emir ,kjo rutine eshte rutina driver e pare qe ekzekutohet kur nje driver ngarkohet dhe kur performohet inicializimi I paisjes driver te driverit object.DDK e Microsoft konstaton qe nje objekt driver paraqet nje driver kernel te ngarkuar aktualish,nderkohe qe nje objekt paisje paraqet nje pisje fizike,logjike ose virtuale.Nje dirver kernel I ngarkuar I vetem(I paraqitur nga nje objekt driver) mund te menaxhoje paije te shumfishta(perfaqesuar nga objektet paisje). Gjate instalimit, fushat ne objektin paisje qe specifikojne rutinen e pangarkuar te driverit,shton rutine driver dhe vendos rutina mesazhesh.Rutina e pangarkuar eshte rutina qe thirret kur driveri eshte duke mos u ngarkuar keshtu qe ai mund te performoje veprime pastrimi duke lene te lire memorjen e alokuar nga sasia kernel. addDevice eshte nje rutine qe thirret pas rutines DriverEntry nqs driveri qe po ngarkohet eshte nje driver PnP, nderkohe qe rutinat dispatch jane rutina qe implementojne veprimet I/O te driver. 3.1.2.2 Rutina AddDevice Driverat PnP implementojne nje rutine te quajtur AddDevice.Ne kete rutine nje objekt paisje krijohet ne cdo hapesire kohe per te ruajtur te dhena globale per nje paisje qe alokohet.Alokimi dhe inicializimi i burimit te paisjes performohet gjithashtu.Objekteve te paisjes iu referohemi me emra te ndryshem ne varesi se ku jane krijuar.Nqs nje objekt paisje eshte krijuar ne njed te ngarkuar aktualisht per te menaxhuar ate driver, quhet nje a Function Device Object (FDO).Nqs eshte nje objekt paisje nga nje driver me i ulet ne nje stive driverash, quhet nje Physical Device Object (PDO). Nqs eshte nje objekt paisje nga nje driver me i larte ne nje stive driverash, quhet Filter Driver Object (FIDO). 3.1.2.1 Krijimi i nje objekti paisje Nje objekt paisje qe I korespondon nje paijeje eshte lrijuar duke perdorur rutinen I/O Manager te quajtur IoCreateDevice brenda rutines add device. Kerkesat me te rendesishme per IoCreateDevice
  6. jane nje emer per objektin paisje dhe tipin e paisjes.Emri

    lejon aplikimet dhe driverat e tjere kernel ti oforojen nje mbeshtetje driverit ne vend te performojen veprimet I/O.Tipi I paisjes specifikon tipin e paisjes per te cilin driver eshte perdorur, psh nje paisje ruajtese. 3.1.2.2 Global Driver Data Kur krijohet nje paisje driveresht ee mundu rt eshoqerohet me te nje bllok memorje e quajtur DeviceExtension ne Windows, kur driver i zakonshem mund te ruhet. Kjo eshte nje lehtesi e rendesishme per faktin qe eleminon nevojen per te perdorur struktura te dhenash globale ne codin e driver, qe mund te jete I veshtire per tu menaxhuar. Psh ne rastin kur variabli lokal me te nejtin emer si eshte dekaluar variabli global ne nje rutine me abime, shkruajtesi i driverit mund te haste ne veshtiresine te kapi nje bug ne driver. Ai gjihtashtu e ben me te lehte per te menaxhuar objektin paisje per ted hen a specifike, kur me shumem se nje objekt paisje ekziston ne nje driver te vetem, sic eshte rasti kur nje driver bus menaxhon objektet e paisjes fizike bir per paisjet present ne bus-in e tij. 3.1.2.3 Emertimi i paisjeve Nje paisje mund te emertohet ne kohene ekrijimit te nje objekti paisje. Ky emer mund te perdoret per te aksesuar nej mbajtes per driverin.Mbajtesi me pas perdoret per te perormuar I/O. Microsoft rekomandon qe te mos emertohen objektet paisje te krijuar ne filter dhe driverat funksional.(Nqs nje objekt paisje emertohet, ndonje klient mund te hape objektin paisje dhe mund te performoje I/O per paisjet driver pa-disk.Kjo eshte per shkak se aksesi default kontrollon statusin ). Nje problem tjeter eshte se emri i specifikuar nuk duhet te ndjeke ndonje protokoll emertimi,keshtu qe emri i specifikuar mund te mos jet enje emer i zgjedhur mire.Psh dy shkruesa driverash mund te kene te njejtin emer per objektet paisje te tyre qe mund te shkaktoje konflikt. Windows suporton nje paisje objekt te dyte te quajtur skeme duke perdorur nderfaqet e paisjes. Nderfaqet e paisjes jane konstruktuar me identifikues unik global (GUID) 128 bit. Nje GUID mund te gjenerohet duke perdorur nje utilitet te ofruar nga Microsoft DDK. Nderkohe qe gjenerohet nje GUID publikohet. Nje driver regjistron GUID per nje nderfaqe paisje ne rutinen e tij nepermjet nje thirrje te rutines I/O manager IoRegisterDeviceInterface. Pasi regjistrohet, driveri duhet te mundesoje nderfaqen permes nje thirrje te I/O manager routine IoSetDeviceInterfaceState. Procesi i regjistrimit do te shtoje nje nderfaqe te futjes se te dhenave ne registry file te Windows, qe mund te aksesohet nga aplikacionet. 3.1.2.4 Aksesi I driver-ave nga nje aplikacion Nje aplikacin qe do te performoje veprime I/O me nje paisje driver duhet te pajiset me 1 mbajtes per 1 driver paisje permes thirrjes se CreateFile Win32 API. Ai kerkon 1 path per paisjen si psh \\device\devicex. Paisjet e mertuara mund te kene emrat e tyre te shfaqura ne te njejten hapesire te quajtur \\device, keshtu qe pathi I meparshem eshte per paisjen e quajtur devicex. CreateFile gjithashtu kerkon access mode flags si read,write dhe sharing flags per paisjen. Aksesi ne paisjet e paemertuara qe kane te regjistruar nje nderfaqe paisjeje jane peformuar ndryshe sic tregohet ne figure.Kjo kerkon pajisjen me 1 mbajtes per nje structure informacioni te paisjes duke perdorur GUID e driverave dhe duke thirrur SetupDiGetClassDevs rutinen Win32 API. kjo eshte e mundur vetem nese driver ka regjistruar nje nderfaqe paisje, permes te cilit aplikacionet mund te therrasin paisjen (e quajtur klasa nderfaqe e paisjes). Sa here qe 1 driver therret rutinen e menaxhimit I/O ,krijohet nje instance e re e klases nderfaqe te paisjes. Pasi mbajtesi i informacionit te paisjes eshte perdorur nga 1 aplikacion, thirrje te shumfishta te rutines Win32 AP SetupDiEnumDeviceInterfaces do te kthejne te dhena te nderfaqes se paisjes per cdo instance te klases nderfaqe te paisjes.Me pas nje path i paisjes per secilen nga instancat e driverave mund te rifitohet nga nderfaqja e te dhenave e mbajtur nga thirrja e mepareshme me nje tjeter rutine Win32 API.mund te thirret me pas me path-in e pisjes per instancen e leverdisshme, per te paisur nje mbajtes per te performuar I/O.
  7. 3.1.2.5 Stiva e objekteve paisje Kur rutina add device thirret

    nga nje menaxher PnP, nje nga paramettrat e kaluara atij eshte nje objekt paisje (PDO) per nje driver poshte atij ekzistues. Stiva e objekteve paisje eshte performuar ne rutinen keshtu qe IRP I derguar nga driverat ne shtresen me poshte,driver qe po ngarkohet mund te merret nga ai. Stiva e objekteve paisje eshte realizuar nga thirrja e rutines I/O Manager IoAttachDeviceToDeviceStacksic tregohet ne figure. Kerkohet nje objekt paisje fizik (PDO), qe eshte me poshte ne stive sesa objekti paisje I ri kur thirret IoAttachDeviceToDeviceStack. Rutina kap objektin paisje te specifikuar ne krye te stives se driverave dhe kthen nje objekt paisje qe eshte 1 me poshte te riut, ne shembullin e fig ky do ishte objekti paisje X. Objekti paisje fizik me i poshtem (PDO) mund te jete ndonje numer i shtresave ndermjet objektit paisje te ri por IoAttachDeviceToStack kthen nje objekt paisje te ri poshte atij.
  8. Quhem Enkel Vela kam perfunduar universitetin e tiranes ne fakultetin

    e shkencave te natyres nga viti 2004-2009 ne degen Informatike. Kam njohuri shume t emire ne Strukture te dhenash, programim, Algoritmike etj. Zoteroj gjuhen angleze dhe italiane.