Dezvoltarea modulelor kernel linux part 16

Acest conținut face parte din seria: Dezvoltarea modulelor de kernel Linux

Aveți grijă de articole noi din această serie.

În părțile anterioare ale ciclului, au fost luate în considerare aproape toate aspectele legate de procesul de creare a modulelor de kernel, cu excepția celor mai importante. Aceasta este o chestiune de asamblare a modulelor și scrierea scripturilor de construcție Makefile. Exemplele anterioare au folosit diferite versiuni ale Makefile, cu toate acestea, împreună cu studiul de cazuri particulare, este necesar să se cunoască principiile de bază și crearea de Makefiles pentru a construi modulele de kernel.

Opțiuni de compilare

Puteți să înlocuiți opțiunile de compilare ale modulului schimbând variabilele definite în scriptul care se compilează, de exemplu:

În același mod, puteți completa definițiile variabilelor preprocesor necesare (care vor funcționa în codul asamblat) specifice asamblării modulului:

(notați semnul +).

Notă. Unde provin variabilele care nu sunt definite explicit în textul Makefilei, cum ar fi EXTRA_CFLAGS? Sau de unde provin regulile implicite de asamblare (ca în exemplul de utilizare a codului de asamblare prezentat în articolul precedent)? Și cum vedeți aceste reguli? Utilitatea de creare are un set de valori implicite (variabile, sufixe etc.), dintre care cele mai importante sunt regulile pentru procesarea sufixelor, precum și definirea variabilelor de mediu interne. Toate aceste informații se numesc baza de date a mărcii și pot fi afișate cu opțiunea -p. Dar cantitatea de informații va fi foarte mare, deci este rezonabil să trimiteți această ieșire la un fișier și numai apoi să o studiați:

Listarea 1. Definițiile variabilelor de mediu interne fac

Acum puteți utiliza toate aceste variabile în propriile script-uri de construcție Makefile.

Asamblarea modulelor în detaliu

În versiunile anterioare de kernel (2.4 și versiunile anterioare), module de asamblare sunt metode mai complexe, care sunt, de asemenea, diferită de abordarea utilizată în versiunea 2.6 (care este motivul pentru care nu este necesar să se concentreze asupra publicațiilor legate de versiunea anterioară a kernel-ului). De la versiunea 2.6, dezvoltatorii kernel-ului au creat un întreg sistem de macrocomenzi de construcție, ceea ce face ca montajul să fie pur tehnic.

Apoi, vom lua în considerare diferitele caracteristici ale procedurii pentru proiectele de proiectare a modulelor de kernel. Un set de scenarii de construcție pentru cele mai frecvente situații va fi, de asemenea, prezentat și analizat, de exemplu: asamblarea mai multor module în proiect, asamblarea modulului prin fuzionarea mai multor fișiere cu codul sursă și așa mai departe.

Cum pot asambla mai multe module în același timp?

În fișierul Makefile menționat mai sus, se poate realiza asamblarea simultană a oricărui număr de module:

Listarea 2. Montarea simultană a două module

Cum se asamblează modulul împreună cu programele conexe?

Adesea, este necesar să se colecteze nu numai modulul în sine, ci și mai multe programe de utilizator utilizate împreună cu modulul (teste, utilități etc.). Adesea, într-un astfel de scenariu, programele de module și de utilizatori utilizează fișiere de definiție comune (fișiere antet). Acesta este modul în care fragmentul Makefile pare să fie construit într-un singur director de lucru al modulului și toate programele care îl folosesc (arhiva ioctl.tgz, care va fi luată în considerare în viitorul apropiat).

Listarea 3. Asamblarea simultană a modulului și a programelor de utilizator

O caracteristică a unui astfel de ansamblu de îmbinare este că atât procesele modulului și utilizator includ (folosind directivele #include) aceleași definiții generale și convenite (exemplu, în aceeași ioctl.tgz arhiva):

Un astfel de fișier de legătură conține definiții comune, atât pentru codul spațiului kernel cât și pentru aplicațiile utilizatorilor. De exemplu, conținutul fișierului ioctl.h este afișat:

În acest sens, poate exista o anumită problemă, deoarece atunci când se creează aplicații și module (folosind definiții comune) pentru a căuta un sistem (# include <.> ) fișierele antet utilizează directoare diferite implicite. / usr / include pentru procese și / lib / modules / `uname -r` / build / include pentru module. O soluție adecvată este să includem un fragment de acest tip în fișierul antet comun (ioctl.h):

Listing 4. Definiții condiționale pentru kernel și pentru aplicații

Pentru toate similaritatea numelor fișierelor antet (și, uneori, o coincidență completă, de exemplu: ) aceasta va include includeri din seturi API complet diferite (API-ul bibliotecii partajate .so pentru spațiul utilizator și API-ul kernel-ului pentru module).

Bibliotecile personalizate

În plus față de un set de aplicații user-spațiu poate fi convenabil să colecteze într-o singură bibliotecă un număr de funcții comune ale acestor aplicații (ca cod duplicarea este eliminat și simplifică schimbările îmbunătățite proiectul structurii). fragment Makefile din time.tgz arhivă, care va fi prezentat într-un articol viitor, demonstrează modul de a face acest lucru, fără a specifica un obiectiv explicit al tuturor ansamblurilor (enumerate în lista OBJLIST variabilă) pentru fiecare obiect fișier care urmează să fie incluse în bibliotecă (punerea în aplicare a diferitelor straturi funcția bibliotecii). În acest caz, biblioteca statică libdiag.a merge:

Listarea 5. Construirea unei biblioteci statice personalizate

Listarea 5 adună două obiective, prog și lib. unite într-un singur scop comun. Dacă doriți, biblioteca statică poate fi înlocuită cu o bibliotecă dinamică (partajată), care poate fi revendicată în proiecte mari. În acest caz, numai modificările minore vor fi făcute în Makefile (toate celelalte fișiere de proiect rămân neschimbate).

Listarea 6. Construirea unei biblioteci partajate personalizate

Notă. În cazul construirii unei biblioteci partajate, trebuie să se asigure, de asemenea, plasarea bibliotecii nou creat (în acest exemplu libdiag.so), pe drum, în cazul în care acesta va fi găsit de către încărcătorul dinamic. Plasarea în "directorul curent" în acest caz nu este potrivită: numele directorului relativ nu sunt folosite pentru a căuta biblioteci dinamice. Rezolvați această problemă în mai multe moduri:

Dar toate aceste întrebări sunt legate de administrarea sistemului și sunt dincolo de scopul acestui articol.

concluzie

În acest articol, au fost discutate întrebările standard referitoare la procesul de construire a modulelor de kernel din cod. În următorul articol, vom continua să discutăm aspecte legate de acest subiect.