Când instalezi o distribuție Linux sau treci la un kernel mai nou, întrebarea nu este doar „pornește sistemul?”. Pentru laptopuri, servere mici, stații de lucru cu drivere speciale sau module DKMS, întrebarea importantă este dacă modulele de kernel rămân compatibile. Aici intră în discuție ABI-ul: contractul binar pe care un modul îl așteaptă de la kernelul în care va fi încărcat.
Pe scurt, API-ul intern descrie ce funcții și structuri folosește codul sursă al unui modul, iar ABI-ul descrie cum arată aceste elemente după compilare: simboluri exportate, dimensiuni de structuri, convenții de apel, opțiuni de compilare și versiuni de simboluri. Configurația kernelului este a treia piesă: două kerneluri cu același număr upstream pot avea opțiuni diferite, iar unele funcții pot exista, lipsi sau se pot comporta diferit în funcție de .config.
Primul semn de verificat este vermagic. Un modul .ko include metadate pe care le poți citi cu modinfo. Câmpul vermagic arată, de obicei, versiunea kernelului pentru care a fost construit modulul și anumite caracteristici relevante ale compilării. Dacă vermagic nu se potrivește cu kernelul țintă, sistemul poate refuza încărcarea modulului. Nu este un test complet de compatibilitate, dar este un filtru rapid și util.
Al doilea element este Module.symvers. Documentația kernel.org explică faptul că, la compilarea modulelor externe, sistemul kbuild folosește acest fișier în etapa MODPOST pentru a cunoaște simbolurile exportate de kernel. Dacă este activ CONFIG_MODVERSIONS, Module.symvers conține și informații de versiune pentru simboluri. Atenție: ținta modules_prepare pregătește sursele pentru compilarea modulelor, dar nu generează Module.symvers chiar dacă CONFIG_MODVERSIONS este setat; pentru versiuni de simboluri funcționale este nevoie de un build complet al kernelului.
În practică, compararea ABI-ului începe cu trei întrebări. Unu: modulele au fost compilate pentru exact kernelul țintă, cu pachetul corect de headers? Doi: simbolurile de care depinde modulul există și au aceeași versiune/CRC acolo unde distribuția folosește versionare? Trei: configurațiile kernelurilor sunt suficient de apropiate pentru acel modul? Diferențele din .config pot conta la fel de mult ca diferența dintre două versiuni 6.x.
Distribuțiile Linux complică și mai mult comparația, în sens bun și rău. Numărul upstream, de tip 6.12 sau 6.16, nu spune toată povestea. Debian documentează separat versiunea upstream, versiunea de pachet, numele ABI și versiunea afișată de uname -r. Red Hat vorbește despre kABI ca despre un set de simboluri interne folosite de drivere și module, cu liste stabile pentru anumite versiuni RHEL. Asta înseamnă că două distribuții pot livra kerneluri cu același nucleu upstream, dar cu patch-uri, backporturi, opțiuni și politici ABI diferite.
Pentru un administrator sau dezvoltator, metoda sigură este una defensivă. Compară uname -r, configurațiile din /boot sau /proc/config.gz, metadatele modinfo, pachetele de headers și fișierele Module.symvers ale celor două kerneluri. Citește notele de lansare ale distribuției, nu doar changelogul upstream. Dacă distribuția oferă o politică kABI, folosește-o ca reper; dacă nu, presupune că modulele binare externe trebuie reconstruite.
DKMS ajută tocmai aici: reconstruiește modulele pentru kernelul nou, folosind headers potrivite. Nu transformă însă un modul incompatibil într-unul sigur. Dacă sursa modulului folosește interfețe interne care s-au schimbat, buildul poate eșua sau modulul poate necesita actualizare de la producător.
Regula practică este simplă: nu testa compatibilitatea direct pe sistemul de producție. Fă snapshot sau backup, verifică în staging, păstrează kernelul vechi în meniul de boot și testează funcțiile reale ale modulului după încărcare. Pentru drivere de stocare, rețea sau securitate, prudența este obligatorie.
Concluzia importantă: Linux are o interfață userspace foarte stabilă, dar interfețele interne ale kernelului nu oferă o garanție universală pentru module binare între versiuni diferite. Compatibilitatea se verifică pe kernelul concret al distribuției, cu pachetele și configurația lui, nu doar după numărul versiunii.
