Sådan overlever du indlejret linuk-Del 1 Den integrerede Linuk-udviklingsproces
den integrerede Linuk-udviklingsproces
Linuk-kernen kan køre på mange forskellige computerarkitekturer, hvoraf de fleste er ret populære i den indlejrede verden. Alle basispakkerne, der giver OS mulighed for at udføre de grundlæggende opgaver, er egnede til krydskompilering, derfor kan Linuk være lige så gennemgribende som mikrocontrollere og systemer på Chip (SOC ‘ er).
en distribution er et styresystem, der er lavet af en programsamling, som er baseret på kernen og – ofte – et pakkehåndteringssystem. Distributionen kan komme som prækompilerede binære filer og pakker sammensat
af distributionsvedligeholderne eller som kilder parret med instruktioner om, hvordan man (kryds-) kompilerer dem.
i det indlejrede domæne, da udstyrsplatformen normalt er skræddersyet, foretrækker OS-designeren generelt at generere distributionen fra bunden, startende fra kilder. Dette giver designeren absolut kontrol over, hvad der ender i
produktet. Desuden ændrer Board Support Package (BSP)-ingeniøren koden på lavt niveau for at få OS ‘ s kernefunktionalitet til at fungere på det specifikke udstyrsprodukt.
at samle alle de nødvendige programmelkomponenter for at generere distributionen for et bestemt indlejret produkt plejede at være et mareridt, men det er ikke længere tilfældet.
mange har delt med open source-samfundet kilderne til byggesystemer, der er i stand til at hente alle programkomponenterne fra internettet, kompilere dem og forbinde dem sammen, op til generering af installationsbilleder af fuldt udviklede operativsystemer. Et par virksomheder udvikler og vedligeholder deres eget byggesystem, andre kompilerer kun få af kernekomponenterne og tager derefter forudbyggede binære filer for at færdiggøre operativsystemet.
i 2010 begyndte en arbejdsgruppe at adressere værktøjer og processer for at gøre det muligt at oprette distributioner til integrerede programmer. En sådan arbejdsgruppe, kendt som Yocto-projektet, tilpassede sig Open Embedded, en ramme med lignende mål.
Yocto-projektet er et open source-projekt, hvis fokus er på at forbedre programmeludviklingsprocessen for indlejrede distributioner. Yocto-projektet giver interoperable værktøjer, metadata og processer, der muliggør
hurtig, gentagelig udvikling af integrerede systemer.
Yocto-projektet driver i øjeblikket de mest populære distributioner til indlejret system til et punkt, hvor udtrykkene “indlejret Linuk” og “Yocto-projekt” undertiden let forveksles som synonymer. Yocto det er ikke en integreret distribution, det skaber en brugerdefineret en for dig.
Yoctos meta-lags layout
den moderne version af Yoctos arkitektur er baseret på meta-lag, som er mapper, der indeholder konfigurationsfiler og regler for, hvordan man kompilerer og samler distributioner til indlejrede systemer.
normalt, men ikke altid, lever et meta-lag på sit eget git-arkiv og giver:
- sine egne pakker (defineret af opskrifter, .bb-filer),
- ændringer af pakker leveret af andre meta-lag (.bbappend filer),
- maskiner (.conf filer),
- konfigurationsfiler (.conf filer),
- fælles kode (.bbclass filer),
- licenser,
- og andre mindre bits og stykker.
et enkelt meta-lag adresserer normalt et bestemt formål. For at opnå et fuldt fungerende system skal flere meta-lag kombineres sammen.
versioner plukning og matching
når man sætter forskellige programmelkomponenter sammen, skal man være opmærksom på versionen af hver komponent, da den forkerte version muligvis ikke fungerer godt sammen med de andre komponenter eller endda bryder systemet.
Yocto-projektet leverer udgivelser af komponenter, der vides at fungere godt sammen, men det er kun udgangspunktet for dit produkt.
Linuk-kernen er en stor del af koden, der skal udsætte de rigtige grænseflader for brugerrummet og skal indeholde de rigtige drivere, for at systemet kan fungere korrekt. Derfor er siliciumleverandørens rolle blevet mere og mere vigtig i disse dage, da de normalt har deres egne udviklingslagre til Linuks-kernen og bootloaderen, og derfor er de de bedste mennesker til at sammensætte et arbejdsbasesystem baseret på deres teknologi.
Googles repo
oprindeligt udviklet til at klare de mange Git-arkiver i et Android-projekt, er repo også blevet meget populær blandt Yocto-udviklere.
Repo er et værktøj bygget oven på Git; det bruger en” manifest-fil ” til at klone og trække et sæt Git-arkiver på samme tid.
en repo manifest er en .repo kan bruge manifestet til at udfylde en mappe med alle kilder, der kommer fra de flere Git-arkiver, der kræves for at opbygge et projekt.
det samme manifest kan også bruges af repo til at kontrollere (synkronisere) projektkilderne, når opstrøms foretager ændringer.
et par siliciumleverandører leverer manifester til deres udvikling og frigiver filialer i disse dage, så designere let kan tjekke udgangspunktet for deres egne produkter.
Yocto-baseret produktudvikling
BSP-ingeniøren starter normalt fra siliciumleverandørens repo-manifest for at tjekke versionen af programmet til referencedesignet (hvilket er et design leveret af siliciumleverandøren selv eller en af dens partnere, der indeholder den samme eller lignende SoC som den, det nye produkt er baseret på). For at sikre, at det udstyr, der er valgt af Elektronikingeniøren, har korrekt support på lavt niveau (f.eks. enhedsdrivere, enhedstræ, kernekonfiguration osv.).
formålet med produktet er at køre en eller flere applikationer, derfor sørger BSP/os-ingeniøren for, at alle afhængigheder af applikationen(e) bygges til systemet. De ingeniører, der udvikler applikationen, har brug for et Programudviklingssæt (SDK) til at krydskompilere og forbinde applikationen, derfor vil BSP/os-ingeniøren
give dem et sådant sæt, og takket være Yocto er dette blevet ret ligetil.
integreret god praksis
de repo-manifester, der bruges til udvikling, indeholder normalt henvisning til udviklingsgrene, hvilket betyder, at repo vil hente den seneste forpligtelse for disse filialer.
hvis du bruger det samme manifest til at hente projektet på et senere tidspunkt, kan du hente en anden version af koden! Dette er helt fint til udvikling, fordi du vil holde fast i den nyeste version af dit projekt, men en af dine udviklingsversioner bliver til sidst en udgivelse, og derfor skal du “tage et billede” af den præcise version af de kilder, der bruges til at generere den programudgivelse, der går på projektet. Hvis du undlader at gøre det, kan du udsætte dig for juridiske problemer, da du ikke vil være i stand til at regenerere den samme bygning fra kilder, derfor vil du ikke være i stand til at foretage en ændring oven på en bestemt udgivelse, hvilket tvinger kunden til at teste hele systemet igen, da du bliver tvunget til at rette fejlen eller tilføje den nye funktion oven på den nyeste version af programmet.
hvis du ikke tager disse snapshots, er der ingen måde, du kan køre en bisect på projektkilderne for at finde ud af, hvilken commit har brudt den funktionalitet, du så desperat har brug for. Når du designer din udviklingsproces, skal du finde en måde at automatisk generere repo manifester med præcise forpligtelser i dem, så du kan gemme dem sammen med udgivelser for at tjekke de samme kilder igen på et senere tidspunkt og gøre hvad du får betalt for at gøre.
Kopier kilder i huset
Husk også, at 99,9% af de kilder, der går ind i dit produkt, kommer fra open source-samfundet, hvilket betyder, at du ikke har nogen garanti for, at de samme kilder kan hentes igen. Som designer skal du beskytte dig mod ændringer og fejl, der er foretaget opstrøms. Opbevar en kopi af alle relevante kilder i huset, og find en måde at tilslutte dem tilbage til dit build-system. Det kan også være en god ide at spejle nogle af de arkiver, du bruger mest, da nogle gange opstrøms git-servere pludselig blev utilgængelige. Hvis du ikke har en intern kopi, sidder du fast, indtil serverne kommer tilbage online.
på ByteSnap har vi en fuldautomatisk måde at frigive Yocto-baserede projekter på, så vi kan få gendanne de kilder, der går i en udgivelse, og også genopbygge den samme udgivelse på et senere tidspunkt. Vi opbevarer kopier af open source-pakker på en automatisk måde, så vi ikke oplever nogen nedetid forårsaget af defekte servere over hele verden. Desuden bakker vi alt op hver eneste dag, så vi kan garantere, at intet arbejde går tabt, selv i tilfælde af katastrofe på stedet.
Fabricio Castro
Fab er en ledende programmør. Han fik sin bachelor-og kandidatgrad på Politecnico di Milano, i Milano, Italien. Han har 20 års erfaring med udvikling af allround-programmer (tjenester, databaser, applikationer, videnskabelige programmer, RTO ‘ er, enhedsdrivere, liniekerner osv.), brugt på at arbejde i den akademiske verden og industrien. Fab har været medforfatter til videnskabelige artikler og bøger og arbejdet med patenter. Ud over forskning og udvikling har han specialiseret sig i integreret Linuks – udvikling-og leverer avancerede designs, der driver succesfulde videnskabelige, industrielle, kommercielle og militære produkter. Fab har også været lektor og har undervist studerende på nogle af de mest prestigefyldte universiteter i Europa. For mere information om ByteSnap Design besøg http://www.bytesnap.co.uk.