Modele pentru kernel: Partea 1: Concepte de bază - Arhiva WASM.RU
Odată cu împărțirea drepturilor și responsabilităților, este ceva mai dificil.
Următoarele procese sunt legate de procesele utilizatorilor:- Procesele de asistență a sistemului - de exemplu, procesul de conectare pentru Winlogon (implementat în \% SystemRoot% \ System32 \ Winlogon.exe);
- Procese de serviciu - de exemplu, un spooler de imprimare;
- Aplicații utilizator - există cinci tipuri: Win32, Windows 3.1, MS-DOS, POSIX și OS / 2;
- Subsistemul Mediu (Mediu Subsistemele) - sprijinit de mediu trei subsisteme: Win32 (implementat în \% SystemRoot% \ System32 \ csrss.exe), POSIX (implementat în \% SystemRoot% \ System32 \ Psxss.exe), OS / 2 (implementat în \% SystemRoot% \ System32 \ os2ss.exe).
-
Sistemul executiv (management) - gestionarea memoriei, proceselor și fluxurilor, etc;
- Kernel (Kernel) - fir de programare, întrerupe și dispecerizarea excepție, etc. (implementat în \% SystemRoot% \ System32 \ Ntoskrnl.exe) ;.
- Drivere de dispozitive - drivere de dispozitive hardware, drivere de rețea, drivere de sistem de fișiere;
- Nivelul de abstractizare al hardware-ului (Hardware Abstraction Layer, HAL) - izolează trei din componenta de mai sus din diferențele dintre arhitecturi hardware (implementat în \% SystemRoot% \ System32 \ Hal.dll);
- Suport Subsistem fereastra și grafică (Windowing și grafică System) - o grafică funcții de interfață cu utilizatorul (Graphic User Interface, GUI) (implementat în \% SystemRoot% \ System32 \ Win32k.sys).
Modul utilizator și modul kernel
Procesele de modul de utilizare sunt considerate ca potențial periculoase din punct de vedere al stabilității sistemului. Drepturile lor sunt limitate. Și orice încercare de depășire a acestor restricții este sever suprimată.
După cum sugerează și numele, driverul de dispozitiv este un program destinat să controleze un dispozitiv, iar dispozitivul nu trebuie să fie fizic. Poate fi logic sau, ca în cazul nostru, virtual.
Prin structura sa, driver-ul de dispozitiv nu este altceva decât un fișier formatat PE (Portable Executable, PE). La fel ca regulile exe și dll. Încarcă și funcționează doar prin alte reguli. Driverele pot fi considerate ca un mod DLL pentru kernel, conceput pentru a efectua sarcini care nu pot fi soluționate din modul de utilizare. Principala diferență aici (fără a lua în calcul nivelul de privilegii) este că nu putem accesa direct driverul, nici codul, nici datele acestuia, dar vom folosi un mecanism special oferit de managerul de intrare / ieșire. Managerul de I / O oferă un mediu pentru funcționarea conducătorilor auto, precum și mecanisme de încărcare, descărcare și gestionare a acestora.
Începând să dezvolte drivere pentru mod de kernel, vă veți simți ca un începător perfect, deoarece toată experiența anterioară de utilizare a API aici nu ajută - kernelul oferă un set complet diferit de funcții. De asemenea, va trebui să utilizați funcții și structuri de date complet slab documentate (definite numai în fișierele antet) sau complet nedocumentate.
Șoferi la un singur nivel și la mai multe niveluri
Cele mai multe drivere pentru driverul dispozitivului fizic sunt driverele stratificate. Modul de procesare a cererilor I / O este împărțit între mai mulți șoferi. Toată lumea își face parte din slujbă. De exemplu, o cerere de a citi un fișier este transmisă driverului sistemului de fișiere, care, efectuând unele operații (de exemplu, împărțind interogarea în mai multe părți), îl transmite "sub" driverului de disc și conducătorul auto trimite cererea către driverul de autobuz. În plus, între aceste drivere, puteți adăuga orice număr de drivere de filtrare (de exemplu, criptarea datelor). Prin executarea interogării, driverul de nivel inferior trimite rezultatele "în sus" la driverul de nivel superior. Dar, din fericire, totul va fi mult mai ușor pentru noi. Driverele noastre vor fi mereu drivere monolitice, ceea ce simplifică foarte mult întregul proces de scriere și depanare a acestora.
Întrerupeți nivelurile solicitărilor
În primul rând, activitatea șoferilor poate fi oprită în orice moment pentru a întrerupe cu o prioritate mai mare (de exemplu, printr-un temporizator, atunci când planificatorul decide că actuala și deja pentru o lungă perioadă de timp are un procesor, și este timpul să-l odihnească nostru). Prin urmare, în acest sens, codul driverelor noastre este întrerupt și expulzat (procesorul este dat altui fir), la fel ca și codul oricărui fir definit de utilizator. Există funcții ale kernelului care vă informează despre nivelul curent al întreruperii și, de asemenea, îl măriți sau micșorați.
Al doilea punct important: nivelul de pasiv Întrerupere poate apela oricare dintre funcțiile de bază (DDK în descrierea fiecărei funcții, asigurați-vă că pentru a indica nivelul la care este posibil să se determine întrerupere), precum și accesul paginile de memorie fac obiectul unui dumping în fișierul de paginare. La niveluri mai mari de întrerupere (DPC / dispat și mai mare), încercarea de a accesa o pagină care nu este în memoria fizică provoacă blocarea sistemului, deoarece Managerul de memorie nu poate procesa eroarea paginii.
Ecran albastru al morții
Cred că toată lumea, cel puțin o dată, a văzut o imagine interesantă numită "Ecranul albastru al morții" (Screen Blue of Death, BSOD). Probabil, nu este nevoie să explici ce este și de ce apare. Lucrul important aici este că atunci când începeți să dezvoltați drivere pentru mod de kernel, fiți pregătiți pentru faptul că BSOD va apărea adesea pe ecranul monitorului.
În cel de-al treilea inel, totul era simplu: schițat codul de probă, plasat int3 acolo unde era necesar, lansat și. în debugger știi deja ce e ce. Dacă ceva nu este potrivit - greșeli fixate, greșite, recompilate. și așa mai departe, atâta timp cât codul nu funcționează așa cum ar trebui. Când programați driverele despre această tehnică, puteți uita. Aici, "sapper" se confundă o dată. O mișcare greșită. și puteți sta liniștit și vă puteți relaxa pentru o clipă.
Teoreticianul meu este rahat, deci toate cele de mai sus poti considera ca o informatie de baza despre acele principii care sunt absolut necesare pentru a intelege. Nu puteți începe să dezvoltați drivere în mod kernel fără a avea indiciu despre contextul firului, nivelurile de întrerupere și prioritățile firului, modul kernel / utilizator și așa mai departe. și altele asemenea. Simți-te nesigur într-o anumită materie - lista literaturii de mai jos.
Driver Kit de dezvoltare
În plus față de documentația din DDK, există un set de fișiere de bibliotecă (* .lib), care vor fi absolut necesare atunci când se leagă. DDK include două seturi de astfel de fișiere: pentru versiunea finală a Windows (numită construire gratuită); și pentru depanare (numită construcție verificată). Aceste fișiere sunt localizate în directoarele .dk% \ libfre \ i386 și respectiv .dk% \ libchk \ i386. Versiunea de depanare se distinge printr-o verificare mai riguroasă a erorilor. Trebuie să utilizați fișiere care se potrivesc cu versiunea dvs. a sistemului, introducându-le în directorul \ masm32 \ lib \ w2k.
Deși această carte nu are o singură linie de cod sursă, este în primul rând pentru programatori.
În această carte, accentul se pune pe șoferii Plag'n'Play, dar acest lucru nu este deloc invocat de meritele sale, deoarece principiile de bază ale dezvoltării conducătorilor auto sunt universale.
Această carte nu are nicio legătură directă cu programarea șoferului, dar este, de asemenea, foarte interesantă ;-)
Această listă nu se pretinde a fi completă. Multe, în special în limba engleză, pot fi găsite pe Internet (cu excepția lui Schreiber, toate cărțile fiind în versiunea electronică). În ceea ce privește cărțile, vreau să spun mai mult că sunt toate din categoria "trebuie să aibă". Veți vedea - cumpărați fără să vă uitați. Toți, cu excepția lui Walter Oney, sunt transferați la "marele și puternicul nostru".