How to Survive Embedded Linux – 1.rész a beágyazott Linux fejlesztési folyamat
a beágyazott Linux fejlesztési folyamat
a Linux kernel számos különböző számítógépes architektúrán futhat, amelyek többsége meglehetősen népszerű a beágyazott világban. Az összes alapcsomag, amely lehetővé teszi az operációs rendszer számára az alapvető feladatok elvégzését, alkalmas a keresztfordításra, ezért a Linux ugyanolyan átható lehet, mint a mikrovezérlők és a chipen lévő rendszerek (Soc).
a Linux disztribúció egy szoftvergyűjteményből készült operációs rendszer, amely a Linux kernelre és – gyakran – csomagkezelő rendszerre épül. A disztribúció történhet előre lefordított bináris fájlokként és csomagokként, amelyeket a disztribúció fenntartói
állítottak össze, vagy forrásokként párosítva a (kereszt) fordítási utasításokkal.
a beágyazott tartományban, mivel a hardverplatform általában testre szabott, az operációs rendszer tervezője általában inkább a nulláról generálja az elosztást, forrásokból kiindulva. Ez abszolút irányítást ad a tervezőnek arról, hogy mi kerül a
termékbe. Ezenkívül a Board Support Package (BSP) mérnök módosítja az alacsony szintű kódot annak érdekében, hogy az operációs rendszer alapvető funkcionalitása működjön az adott hardverterméken.
az összes szükséges szoftverkomponens összegyűjtése egy adott beágyazott termék Linux disztribúciójának létrehozásához rémálom volt, de hálásan ez már nem így van.
sokan megosztották a nyílt forráskódú közösséggel a build rendszerek forrásait, amelyek képesek letölteni az összes Szoftverkomponenst az internetről, lefordítani és összekapcsolni őket, egészen a teljes értékű operációs rendszerek telepítési képeinek generációjáig. Néhány vállalat saját build rendszert fejleszt és tart fenn, mások csak néhány alapvető összetevőt állítanak össze, majd előre elkészített binárisokat készítenek az operációs rendszer véglegesítéséhez.
2010-ben a Linux Foundation egy munkacsoportja elkezdett foglalkozni olyan eszközökkel és folyamatokkal, amelyek lehetővé teszik a Linux disztribúciók létrehozását beágyazott szoftverekhez (más néven beágyazott Linux). Egy ilyen munkacsoport, az úgynevezett Yocto projekt, igazodott az Open Embedded-hez, egy hasonló célú keretrendszerhez.
a Yocto projekt egy nyílt forráskódú projekt, amelynek középpontjában a beágyazott Linux disztribúciók szoftverfejlesztési folyamatának javítása áll. A Yocto projekt interoperábilis eszközöket, metaadatokat és folyamatokat biztosít, amelyek lehetővé teszik a Linux-alapú beágyazott rendszerek
gyors, megismételhető fejlesztését.
a Yocto projekt jelenleg a beágyazott rendszerek legnépszerűbb Linux disztribúcióit táplálja, olyan pontig, ahol néha a “beágyazott Linux” és a “Yocto projekt” kifejezések könnyen összetéveszthetők szinonimaként. Yocto ez nem egy beágyazott Linux disztribúció, hanem egy egyedi disztribúciót hoz létre az Ön számára.
Yocto ‘ s meta-layers layout
a Yocto architektúrájának modern változata meta-layereken alapul, amelyek a konfigurációs fájlokat és a beágyazott rendszerek Linux disztribúcióinak fordítására és összeállítására vonatkozó szabályokat tartalmazó könyvtárak.
általában, de nem mindig, a meta-réteg él a saját git repository, és biztosítja:
- saját csomagok (által meghatározott receptek,. bb fájlok),
- módosítások csomagok által nyújtott más meta-rétegek (.bbappend fájlok),
- gépek (.conf fájlok),
- konfigurációs fájlok (.conf fájlok),
- közös kód (.bbclass fájlok),
- licencek,
- és egyéb kisebb bitek.
egyetlen metaréteg általában egy meghatározott célt szolgál. Ezért egy teljesen működő rendszer eléréséhez több metaréteget kell kombinálni.
verziók kiválasztása és illesztése
amikor különböző szoftverkomponenseket állítunk össze, figyelembe kell venni az egyes komponensek verzióját, mivel a rossz verzió nem működik jól a többi komponenssel, vagy akár megszakítja a rendszert.
a Yocto projekt olyan alkatrészek kiadását biztosítja, amelyekről ismert, hogy jól működnek együtt, de ez csak a termék kiindulópontja.
a Linux kernel egy nagy kóddarab, amelynek ki kell tárnia a megfelelő interfészeket a felhasználói térbe, és tartalmaznia kell a megfelelő illesztőprogramokat a rendszer megfelelő működéséhez. Ezért a szilícium szállító szerepe egyre fontosabbá vált ezekben a napokban, mivel általában saját fejlesztési tárolókkal rendelkeznek a Linux kernelhez és a bootloaderhez, ezért ők a legjobbak, akik a technológiájukon alapuló működő alaprendszert összeállítanak.
Google repo
eredetileg azért fejlesztették ki, hogy megbirkózzon az Android-projekt Git-tárolóinak sokaságával, a repo meglehetősen népszerűvé vált a Yocto fejlesztők körében is.
a Repo a Git tetejére épített eszköz; ez használ egy “manifest file” klónozni, majd húzza egy sor Git tárolók minden ugyanabban az időben.
a repo manifest egy .xml dokumentum, amely hivatkozásokat tartalmaz git adattárak (azok verzióival együtt), a repo a manifest segítségével feltölthet egy könyvtárat a projekt felépítéséhez szükséges több Git adattárból származó összes forrással.
a repo ugyanazt a jegyzéket is felhasználhatja a projekt forrásainak ellenőrzéséhez (szinkronizálásához), amikor az upstream változtatásokat hajt végre.
néhány szilíciumgyártó manapság biztosítja a fejlesztési és kiadási ágak manifesztjeit, így a tervezők könnyen megnézhetik saját termékeik kiindulópontját.
Yocto-alapú termékfejlesztés
a BSP mérnök általában a silicon vendor repo manifest-től indul, hogy megnézze a szoftver verzióját a referenciaterv számára (amely maga a szilícium-szállító vagy annak egyik partnere által biztosított terv, amely ugyanazt vagy hasonló SoC-t tartalmaz, mint amelyen az új termék alapul). A mérnök módosítja a rendszerbetöltőt és a Linux kernelt, hogy megbizonyosodjon arról, hogy az elektronikai mérnök által kiválasztott hardver megfelelő alacsony szintű szoftvertámogatással rendelkezik (például eszközillesztők, eszközfa, kernel konfiguráció stb.).
a termék célja egy vagy több alkalmazás futtatása, ezért a BSP/OS mérnök gondoskodik arról, hogy az alkalmazás(ok) összes függősége felépüljön a rendszer számára. Az alkalmazást fejlesztő mérnököknek szükségük van egy szoftverfejlesztő készletre (SDK) az alkalmazás keresztfordításához és összekapcsolásához, ezért a BSP/OS mérnök
biztosítja számukra egy ilyen készletet, és a Yocto-nak köszönhetően ez meglehetősen egyszerűvé vált.
Embedded Linux good practice
a fejlesztéshez használt repo manifesztek általában tartalmaznak hivatkozást a fejlesztési ágakra, ami azt jelenti, hogy a repo lekéri a legújabb elkötelezettséget ezekhez az ágakhoz.
Ha ugyanazt a jegyzéket használja a projekt későbbi lekéréséhez, akkor a kód egy másik verzióját is lekérheti! Ez tökéletesen megfelel a fejlesztésnek, mert ragaszkodni szeretne a projekt legújabb verziójához, de az egyik fejlesztési verziója végül kiadássá válik, ezért “képet kell készítenie” a projekten futó szoftverkiadás előállításához használt források pontos verziójáról. Ennek elmulasztása jogi problémáknak teheti ki Önt, mivel nem tudja regenerálni ugyanazt az építkezést a forrásokból kezdve, ezért nem lesz képes változtatni egy adott kiadás tetején, arra kényszerítve az Ügyfelet, hogy újra tesztelje az egész rendszert, mivel kénytelen lesz kijavítani a hibát, vagy hozzáadja az új funkciót a szoftver legújabb verziójának tetejére.
Továbbá, ha nem készíti el ezeket a pillanatképeket, akkor nincs mód arra, hogy a projekt forrásain felezővonalat futtasson, hogy megtudja, melyik elkövetés szakította meg a szükséges funkciókat. A fejlesztési folyamat megtervezésekor keresse meg a módját, hogy automatikusan generálja a repo manifeszteket pontos elkötelezettségekkel, így mentheti őket a kiadások mellett, hogy egy későbbi időpontban ismét ugyanazokat a forrásokat fizesse meg, és tegyen meg bármit, amiért fizetnek.
források másolása a házban
ne feledje azt is, hogy a terméken belüli források 99,9% – a A nyílt forráskódú közösségből származik, ami azt jelenti, hogy nincs garancia arra, hogy ugyanazok a források újra letölthetők lesznek. Tervezőként meg kell védenie magát az upstream változásokkal és hibákkal szemben. Tartsa meg az összes releváns forrás másolatát a házban, és találja meg a módját, hogy csatlakoztassa őket a build rendszeréhez. Is, érdemes tükrözni a legtöbbet használt tárolókat, mivel néha az upstream Git szerverek hirtelen elérhetetlenné válhatnak. Ha nincs belső másolata, akkor elakad, amíg a szerverek vissza nem térnek online.
a ByteSnap, van egy teljesen automatizált módon felszabadító Yocto alapú projektek, oly módon, hogy mi lehet kapni vissza a forrásokat, hogy menjen be egy kiadás, valamint, újra építeni ugyanazt a kiadás egy későbbi időpontban. A nyílt forráskódú csomagok másolatait automatikus módon őrizzük meg, hogy ne tapasztaljunk leállási időt a hibás szerverek miatt szerte a világon. Továbbá minden nap támogatunk mindent, hogy garantálni tudjuk, hogy a helyszínen bekövetkező katasztrófa esetén sem veszhet el munka.
Fabrizio Castro
a Fab vezető szoftvermérnök. Főiskolai és mesterdiplomáit a Milánói Politecnico di Milano – ban szerezte. 20 éves tapasztalattal rendelkezik a teljes körű szoftverfejlesztés területén (szolgáltatások, adatbázisok, alkalmazások, tudományos szoftverek, firmware, RTOS, eszközmeghajtók, Linux kernel stb.), az egyetemen és az iparban dolgozott. A Fab társszerzője tudományos cikkeknek és könyveknek, és szabadalmakkal foglalkozott. A kutatás és fejlesztés mellett a beágyazott Linux fejlesztésre is specializálódott – a legkorszerűbb dizájnokat szállítja, amelyek sikeres tudományos, ipari, kereskedelmi és katonai termékeket támogatnak. Fab is volt egy előadó és tanított egyetemisták néhány a legrangosabb európai egyetemek. További információ a ByteSnap Design látogatás http://www.bytesnap.co.uk.