A kernel modulok fejlesztése linux 16. rész
Ez a tartalom a sorozat része: Linux kernel modulok fejlesztése
Vigyázz az új cikkekre ebben a sorozatban.
A ciklus korábbi részeiben szinte minden, a rendszermag modul létrehozásának folyamatával kapcsolatos kérdést tekintettek, kivéve a legfontosabbakat. Ez a modulok összeállítása és a Makefile build scriptek készítése. Korábban a Makefile változatokat a példákban már használják, de bizonyos esetek tanulmányozásával ismerni kell a Makefiles létrehozásának alapelveit a kernel modulok építéséhez.
Összeállítási lehetőségek
A modul összeállítási opcióit felülbírálhatja a fordítandó szkriptben definiált változók megváltoztatásával, például:
Ugyanígy kiegészítheti a modul előkészítéséhez szükséges előfeldolgozó-változók (amelyek az összeállított kódban működnek) definícióit:
(vegye figyelembe a + jelet).
Megjegyzés. Hol vannak azok a változók, amelyeket kifejezetten nem definiáltak a Makefile szövegében, mint például az EXTRA_CFLAGS? Vagy hol származnak az alapértelmezett összeszerelési szabályok (például az előző cikkben bemutatott összeszerelési kód példáján)? És hogyan láthatja ezeket a szabályokat? A make segédprogram alapértelmezett értékeket (változókat, utótagokat stb.) Tartalmaz, amelyek közül a legfontosabb az utótagok feldolgozásának szabályai, valamint a belső környezeti változók meghatározása. Mindezeket az információkat a make adatbázisnak nevezik, és a -p opcióval megjeleníthetők. De az információ kimeneti mennyisége nagyon nagy lesz, ezért érdemes ezt a fájlt elküldeni egy fájlnak, és csak ezt követően tanulmányozni:
1. A belső környezeti változók definíciói
Most használhatja ezeket a változókat a saját Makefile build szkriptjein.
Modulok összeállítása részletesen
A korábbi változatokhoz képest (2.4 és korábbi) összeszerelési modulok sokkal összetettebb módon, amelyek szintén eltér a megközelítést alkalmazza, 2.6 verzióját (ezért nem szükséges, hogy összpontosítson kiadványok és az előző kernel). A 2.6-os verzió óta a rendszermag fejlesztői létrehoztak egy teljes makró-rendszert, amely tisztán technikai jellegű.
Ezután megfontoljuk a kernel modul projektek építésének (vázlat) eljárásának különböző jellemzőit. Azt is be kell mutatni és elemezni egy sor build szkripteket (Makefile) a leggyakoribb helyzetekben, mint például: szerelés több modulból a projektben, a szerelvény a modul kombinálásával számos forrásból, stb
Hogyan lehet egyszerre több modulot összeállítani?
Az előzőekben említett Makefile-ben tetszőleges számú modul egyidejű összeállítása végezhető el:
Listázás 2. Két modul egyidejű összeállítása
Hogyan lehet összeállítani a modult a kapcsolódó programokkal?
Gyakran előfordul, hogy nem csak a modult kell gyűjteni, hanem a modultal együtt felhasznált több felhasználói programot is (tesztek, segédprogramok stb.). Gyakran előfordul, hogy a modul és a felhasználói programok közös definíciós fájlokat (fejlécfájlokat) használnak. Itt van egy Makefile fragmentum összeszerelni egy működő példány a modul és használata minden programok (archív ioctl.tgz, amelyet figyelembe kell venni a közeljövőben).:
Listázás 3. A modul és a felhasználói programok egyidejű összeállítása
A jellemzője egy ilyen közös szerelvény az, hogy mind a modul és a felhasználói folyamatok közé (a #include direktívák) az azonos általános és elfogadott meghatározások (például az azonos archív ioctl.tgz):
Egy ilyen hivatkozási fájl közös meghatározásokat tartalmaz, mind a rendszermag térkódja, mind a felhasználói alkalmazások esetében. Például az ioctl.h fájl tartalma jelenik meg:
Ebben a tekintetben előfordulhat, hogy van egy bizonyos probléma, mert amikor alkalmazások és modulok (közös definíciók használatával) felkutatják a rendszert (# include <.> ) fejlécfájlok különböző alapértelmezett könyvtárakat használnak. / usr / include a folyamatokhoz és / lib / modules / `uname -r` / build / include modulokhoz. Megfelelő megoldás az ilyen típusú töredéknek a közös fejlécfájlba (ioctl.h) való felvétele:
Listázás 4. Feltételes definíciók a rendszermaghoz és az alkalmazásokhoz
A fejléc fájlok neveinek hasonlósága (és néha teljes egybeesés, például:
Egyéni könyvtárak
Amellett, hogy egy sor felhasználói űralkalmazásokon célszerű lehet gyűjteni egy-egy könyvtár számos közös funkciók ezen alkalmazások (például a párhuzamos kódot kiesik, és egyszerűsíti a változások javított szerkezettel projekt). Makefile fragmentum az archív time.tgz, amely bemutatásra kerül egy későbbi cikkben, bemutatja, hogyan kell ezt csinálni, anélkül, kifejezett cél az összes szerelvények (szerepel a változó lista OBJLIST) minden egyes objektum fájl tartalmazza a könyvtárban (végrehajtó külön a könyvtár funkciója). Ebben az esetben a libdiag.a statikus könyvtár megy:
Listázás 5. Egyéni statikus könyvtár létrehozása
Az 5. lista összeállít két gólt, prog és lib. egyesült egy közös cél. Kívánt esetben a statikus könyvtárat egy dinamikus könyvtárral lehet helyettesíteni (megosztva), amely nagy projektekben igényelhető. Ebben az esetben a Makefile-ben csak kisebb módosítások lesznek (minden más projektfájl változatlan marad).
Listázás 6. Egyéni megosztott könyvtár létrehozása
Megjegyzés. Ha megosztott könyvtárat szeretne létrehozni, biztosítsa azt is, hogy az újonnan létrehozott könyvtár (példánkban libdiag.so) megtalálható azon a pályán, ahol a dinamikus betöltő megtalálja azt. Ebben az esetben az "aktuális könyvtár" elhelyezés nem megfelelő: a relatív könyvtárnevek nem használhatók dinamikus könyvtárak keresésére. Számos módon oldja meg ezt a problémát:
De mindezek a kérdések a rendszer adminisztrációjához kapcsolódnak, és nem tartoznak e cikk hatálya alá.
következtetés
Ebben a cikkben megvitatták a kernel modulok kódexből való építésének folyamatával kapcsolatos szokásos kérdéseket. A következő cikkben folytatjuk a témával kapcsolatos kérdéseket.