Cartea albă a driverelor de dispozitive
(Copyright 1999 by Jungo)
1.Drivere de dispozitive – privire generală
a.Ce este un driver de dispozitiv?
Ceva foarte util, deoarece fereşte aplicaţiile obişnuite de detaliile incomode şi greoaie ale dispozitivelor hardware reale. Driverele permit proiectanţilor de aplicaţii soft să se concentreze asupra problemelor aplicaţiei în sine, şi să nu-şi mai bată capul cu detaliile de nivel scăzut despre hardware.
Sistemele de operare multi-proces (cum ar fi Windows şi Unix), izolează aplicaţiile ce rulează în modul User (spaţiul aplicaţiilor), limitându-le accesul la resursele sistemului. Sub aceste sisteme de operare, aplicaţiilor nu li se permite să acceseze direct hardware-ul. Accesul nemijlocit la hardware este privilegiul codului ce rulează pe inelul zero al sistemului de operare, respectiv în “Kernel Mode”. De aceea, pentru a putea accesa hardware-ul, un proiectant de soft va trebui să scrie un driver de dispozitiv în modul de lucru kernel înainte de a putea accesa hard-ul din modul User.
Codul ce are privilegiul de a rula în modul kernel şi accesează nemijlocit un echipament specific este denumit un “Driver de dispozitiv”. Astfel, un driver de dispozitiv este tipic singura entitate de program care ştie cum lucrează pe dinăuntru un anumit echipament, pentru care driverul a fost scris, şi este singura entitate care accesează fizic hardware-ul respectiv.
De aceea, o topologie tipică pentru aplicaţie / driver de dispozitiv / hardware va avea arhitectura din figura 1.
Pentru a putea accesa hardware-ul, driverul dvs. de dispozitiv trebuie să apeleze API-urile specifice ale sistemului de operare, şi trebuie să se conformeze metodei specifice sistemului de operare de a scrie, edita legăturile şi încărca driverele de dispozitive.
b. Ce trebuie să cunosc pentru a putea scrie un driver de dispozitiv? (fără unelte software de la Jungo)
Arhitectura sistemului de operare
Deoarece driverul de dispozitiv este strâns legat de sistemul de operare pe care rulează, nu-i de mirare că este necesară o bună cunoaştere a arhitecturii sistemului de operare şi a funcţionării sale interne, pentru a putea pune la punct un driver de dispozitiv. Aceasta se poate învăţa citind un număr de cărţi bune disponibile pe acest subiect (vezi la http://www.Jungo.com/resources.html o listă de manuale recomandate pe tema “drivere şi sisteme de operare”).
Interfeţele driverului cu sistemul de operare
Interfeţele sistemului de operare pe care driverul scris de dvs. le va folosi ca să acceseze hardware-ul trebuiesc de asemenea bine studiate. Sub Windows 9x/NT/2000, setul de interfeţe de driver ale sistemului de operare sunt denumite DDK (Driver Development Kit). În Windows CE, acest set este denumit ETK (Embedded Toolkit).
Depanarea modului Kernel
După ce aţi scris un driver, apar alte probleme. Depanarea unui driver de dispozitive este o sarcină anevoioasă, ce necesită nu numai cunoştinţe speciale, ci şi un nou set de instrumente.
Atunci când depanaţi aplicaţii, se lansează programe “debuggers”, ca procese separate. Debugger-ul analizează procesul care este depanat oprind procesul subiect, şi mergând prin el pas cu pas. Dar asta presupune ca restul sistemului, inclusiv driverele, să funcţioneze corect!
Cum un driver de dispozitiv este o parte integrantă a sistemului de operare, dacă el ar fi oprit de un debugger, întreg sistemul de operare s-ar opri, deci nici-un alt proces (inclusiv debugger-ul) nu ar mai putea rula. De aceea, pentru depanarea unui driver de dispozitiv nu este suficientă o singură maşină: trebuie legate două calculatoare, din care unul este folosit ca gazdă ce rulează programul de depanare, iar celălalt are rolul de computer-ţintă, pe el rulând driverul ce trebuie depanat.
Deoarece driverul foloseşte un API specific anumitui sistem de operare (de exemplu, DDK), un proiectant va trebui să scrie câte un driver de dispozitive separat pentru fiecare versiune a sistemului de operare pe care trebuie să ruleze respectivul hardware. De exemplu, chiar în cadrul produselor Microsoft, trebuie scrise versiuni diferite: scrierea unui driver de dispozitiv pentru Windows 95 necesită studierea aprofundată a arhitecturii lui Windows 95, şi cunoaşterea DDK -ului pentru Windows 95. Atunci când rescrieţi driverul pentru a rula sub Windows NT, va trebui să învăţaţi bine arhitectura lui Windows NT (care urmează o abordare diferită de arhitectura lui 95, OSR2 şi 98), şi să cunoaşteţi DDK-ul pentru New Technology.
Tipuri de drivere de dispozitive.
Urmează o trecere în revistă a tipurilor celor mai răspândite arhitecturi pentru driverele de dispozitive:
Drivere monolitice
Driverele dintr-o singură bucată sunt tipul “clasic” de driver de dispozitive, utilizate în primul rând pentru a comanda echipamente speciale (custom hardware). Un driver monolitic este accesat de una sau mai multe din aplicaţiile utilizatorului şi comandă direct un dispozitiv hardware. Driverul comunică cu aplicaţia prin intermediul comenzilor de control al I/O – (IOCTL-urile), şi comandă echipamentul prin apelarea de diferite funcţii DDK.
Drivere multistrat
Driverele organizate pe mai multe straturi (Layered) sunt drivere de dispozitive care fac parte dintr-o stivă, “stack”, de drivere, care toate împreună procesează o cerere de intrare/ ieşire. Un exemplu de astfel de driver cu mai multe straturi ar fi driverul care interceptează apelurile către unitatea de disk, şi criptează / decriptează toate datele care sunt scrise pe disk sau citite de pe acesta. Driverul respectiv este “agăţat” deasupra driverelor deja existente, şi nu se ocupă decât de criptare şi decriptare, restul funcţiilor de I/O fiind asigurate de driverele deja existente.
Drivere “Standard” (Miniport)
Există clase de drivere de dispozitive în care majoritatea codului de program are de-a face cu funcţionalitatea dispozitivului, şi nu cu angrenajele interne ale dispozitivului respectiv. În cadrul acestor clase de drivere, elementele de cod vor fi duplicate.
Astfel, Windows NT şi 2000 oferă mai multe clase de drivere (denumite “porturi”) care gestionează funcţionalitatea comună a clasei respective. Utilizatorul foloseşte aceste porturi; nu-i rămâne decât să adauge funcţionalitatea particulară lui, adică cea care are de-a face cu modul de lucru intern al dispozitivului hard specific.
Un exemplu concret din categoria driverelor Miniport este driver Miniport “NDIS”, cunoscut de toţi cei care au avut de-a face cu legare în reţea. Cadrul de lucru NDIS Miniport este folosit pentru a crea drivere de reţea care se leagă de stivele de comunicaţii ale NT-ului, şi astfel devin accesibile pentru apelurile comune de comunicaţii din interiorul aplicaţiilor.
Nucleul Windows NT asigură drivere pentru diferitele stive de comunicaţii, precum şi alt cod de program care este comun pentru plăcile de comunicaţii. Datorită existenţei cadrului de lucru NDIS, proiectantul de soft care dezvoltă driverul pentru o placă de reţea NU mai trebuie să scrie tot acest cod, ci numai partea de program care este specifică pentru cartela de reţea respectivă.
2.WinDriver
Scrierea unor drivere de dispozitive necesită aptitudini speciale, şi este oricum un proces de durată, ce trebuie repetat pentru fiecare nouă versiune a sistemului de operare care trebuie să fie suportat de hardware sau de aplicaţie.
Jungo furnizează două linii de produse soft ce automatizează procesul de dezvoltare a driverelor de dispozitive şi deci simplifică dramatic sarcina programatorului. Aceste
linii de produse se numesc “WinDriver” şi respectiv “KernelDriver”, şi sunt descrise şi explicate în cele ce urmează:
c. Modelul “WinDriver”
WinDriver permite proiectanţilor de softuri să creeze aplicaţii care accesează hardware nou sau existent, fără să mai trebuiască să scrie un driver de dispozitiv în modul kernel. Această tehnologie poate economisi mai multe luni de muncă, şi permite ca driverul pe care l-aţi pus la punct să fie compatibil la nivel de cod sursă pentru mai multe sisteme de operare diferite. Iată cum funcţionează:
WinDriver asigură API de acces hardware care este disponibil pentru aplicaţiile dvs. în modul de lucru User Mode. Acest API (denumit “WinDriver API”) permite ca aplicaţiile dvs. să acceseze hardware-ul prin intermediul modulului generic de nucleu WinDriver, care rezidă pe nivelul de nucleu al sistemului de operare, şi rulează în privilegiile inelului zero (Ring-0).
API-ul WinDriver permite aplicaţiilor dvs. să acceseze registrele hardware, gamele de memorie, gamele de adrese de I/O, şi să gestioneze întreruperile echipamentului.
– va urma –
Traducere de Cristian Malide