How to Survive Embedded Linux – Parte 1 Il processo di sviluppo di Linux embedded
Il processo di sviluppo di Linux Embedded
Il kernel Linux può essere eseguito su molte architetture di computer diverse, la maggior parte delle quali sono molto popolari nel mondo embedded. Tutti i pacchetti di base che consentono al sistema operativo di eseguire le attività di base sono adatti per la compilazione incrociata, quindi Linux può essere pervasivo come microcontrollori e sistemi su chip (SOC).
Una distribuzione Linux è un sistema operativo costituito da una collezione di software, che si basa sul Kernel Linux e – spesso – un sistema di gestione dei pacchetti. La distribuzione può venire come binari e pacchetti precompilati messi insieme
dai manutentori della distribuzione, o come sorgenti accoppiate con istruzioni su come compilarli (incrociandoli).
Nel dominio embedded, poiché la piattaforma hardware è solitamente su misura, il progettista del sistema operativo generalmente preferisce generare la distribuzione da zero, a partire dai sorgenti. Questo dà al progettista il controllo assoluto di ciò che finisce nel prodotto
. Inoltre, l’ingegnere Board Support Package (BSP) modifica il codice di basso livello per far funzionare le funzionalità di base del sistema operativo sullo specifico prodotto hardware.
Riunire tutti i componenti software necessari per generare la distribuzione Linux per un particolare prodotto embedded era un incubo, ma fortunatamente questo non è più il caso.
Molti hanno condiviso con la comunità open source le fonti di sistemi di compilazione in grado di recuperare tutti i componenti Software da Internet, compilarli e collegarli insieme, fino alla generazione di immagini di installazione di sistemi operativi a tutti gli effetti. Alcune aziende stanno sviluppando e mantenendo il proprio sistema di compilazione, altre compilano solo alcuni dei componenti principali e quindi prendono binari pre-costruiti per finalizzare il sistema operativo.
Nel 2010, un gruppo di lavoro della Linux Foundation ha iniziato ad affrontare strumenti e processi per consentire la creazione di distribuzioni Linux per software embedded (aka Embedded Linux). Tale gruppo di lavoro, noto come Progetto Yocto, si è allineato con Open Embedded, un framework con obiettivi simili.
Il progetto Yocto è un progetto open source il cui obiettivo è migliorare il processo di sviluppo del software per le distribuzioni Linux embedded. Il progetto Yocto fornisce strumenti interoperabili, metadati e processi che consentono lo sviluppo
rapido e ripetibile di sistemi embedded basati su Linux.
Il progetto Yocto sta attualmente alimentando le distribuzioni Linux più popolari per sistemi embedded, al punto che a volte i termini “Embedded Linux” e “Yocto Project” sono facilmente confusi come sinonimi. Yocto non è una distribuzione Linux Embedded, ne crea una personalizzata per te.
Layout dei meta-layer di Yocto
La versione moderna dell’architettura di Yocto si basa sui meta-layer, che sono directory contenenti file di configurazione e regole su come compilare e assemblare distribuzioni Linux per sistemi embedded.
Di solito, ma non sempre, un meta-layer vive sul proprio repository git e fornisce:
- i propri pacchetti (definiti da ricette, file.bb),
- modifiche ai pacchetti forniti da altri meta-layer (.bbappend file),
- macchine (.file conf),
- file di configurazione (.file conf),
- codice comune (.file bbclass),
- licenze,
- e altri bit e pezzi minori.
Un singolo meta-layer normalmente affronta uno scopo specifico. Pertanto, per ottenere un sistema completamente funzionante, è necessario combinare più meta-livelli.
Versioni prelievo e corrispondenza
Quando si mettono insieme diversi componenti software, è necessario essere consapevoli della versione di ciascun componente, poiché la versione sbagliata potrebbe non funzionare bene insieme agli altri componenti o addirittura rompere il sistema.
Il progetto Yocto fornisce versioni di componenti noti per funzionare bene insieme, ma questo è solo il punto di partenza per il tuo prodotto.
Il kernel Linux è un grosso pezzo di codice che deve esporre le interfacce giuste allo spazio utente e deve contenere i driver giusti, affinché il sistema funzioni correttamente. Pertanto, il ruolo del fornitore di silicio è diventato sempre più importante in questi giorni, in quanto di solito hanno i propri repository di sviluppo per il kernel Linux e il bootloader, quindi, sono le persone migliori per mettere insieme un sistema di base funzionante basato sulla loro tecnologia.
Repo di Google
Originariamente sviluppato per far fronte alla moltitudine di repository Git in un progetto Android, repo è diventato molto popolare tra gli sviluppatori Yocto troppo.
Repo è uno strumento costruito su Git; usa un” file manifest ” per clonare e tirare un set di repository Git allo stesso tempo.
Un manifesto repo è un .documento xml contenente riferimenti ai repository git (insieme alle loro versioni), repo può utilizzare il manifest per popolare una directory con tutte le fonti provenienti dai diversi repository Git necessari per costruire un progetto.
Inoltre, lo stesso manifest può essere utilizzato da repo per tenere sotto controllo (sincronizzare) le origini del progetto quando si apportano modifiche a monte.
Alcuni fornitori di silicio forniscono manifesti per i loro rami di sviluppo e rilascio in questi giorni, in modo che i progettisti possono facilmente controllare il punto di partenza per i propri prodotti.
Sviluppo del prodotto basato su Yocto
L’ingegnere BSP di solito parte dal manifesto repo del fornitore di silicio per il checkout della versione del software per il progetto di riferimento (che è un progetto fornito dal fornitore stesso di silicio o da uno dei suoi partner, contenente lo stesso o simile SoC a quello su cui è basato il nuovo prodotto). L’ingegnere apporta modifiche al bootloader e al kernel Linux per assicurarsi che l’hardware selezionato dall’ingegnere elettronico abbia un adeguato supporto software di basso livello (ad esempio driver di periferica, albero dei dispositivi, configurazione del kernel, ecc.).
Lo scopo del prodotto è quello di eseguire una o più applicazioni, pertanto l’ingegnere BSP/OS si assicura che tutte le dipendenze delle applicazioni siano state create per il sistema. Gli ingegneri che sviluppano l’applicazione hanno bisogno di un kit di sviluppo software (SDK) per compilare e collegare l’applicazione, quindi l’ingegnere BSP/OS
fornirà loro un kit di questo tipo, e grazie a Yocto questo è diventato abbastanza semplice.
Embedded Linux good practice
I manifesti repo usati per lo sviluppo di solito contengono riferimenti ai rami di sviluppo, il che significa che repo recupererà l’ultimo commit per quei rami.
Se si utilizza lo stesso manifest per recuperare il progetto in un secondo momento, è possibile recuperare una versione diversa del codice! Questo va perfettamente bene per lo sviluppo perché vuoi rimanere con l’ultima versione del tuo progetto, ma una delle tue versioni di sviluppo alla fine diventerà una release, e quindi devi “scattare una foto” di quella versione precisa dei sorgenti utilizzati per generare la versione del software che va sul progetto. Non farlo può esporti a problemi legali in quanto non sarai in grado di rigenerare la stessa build a partire dai sorgenti, quindi non sarai in grado di apportare una modifica su una specifica release, costringendo il cliente a testare nuovamente l’intero sistema in quanto sarai costretto a correggere il bug o aggiungere la nuova funzionalità all’ultima versione del software.
Inoltre, se non si scattano quelle istantanee, non è possibile eseguire una bisezione sulle origini del progetto per scoprire quale commit ha interrotto la funzionalità di cui hai così disperatamente bisogno. Quando si progetta il processo di sviluppo, trovare un modo per generare automaticamente i manifesti repo con commit precisi in essi, in modo da poterli salvare insieme ai rilasci per controllare nuovamente le stesse fonti in un secondo momento e fare tutto ciò che si è pagati per fare.
Copia le fonti in casa
Tieni anche presente che il 99,9% delle fonti che entrano nel tuo prodotto provengono dalla comunità open source, il che significa che non hai alcuna garanzia che le stesse fonti saranno nuovamente disponibili per il download. Come designer, è necessario proteggersi dai cambiamenti e dagli errori commessi a monte. Conserva una copia di tutte le fonti rilevanti in casa e trova un modo per ricollegarle al tuo sistema di compilazione. Inoltre, potresti voler eseguire il mirroring di alcuni dei repository che usi di più, poiché a volte i server git upstream potrebbero diventare improvvisamente non disponibili. Se non si dispone di una copia interna sarete bloccati fino a quando i server torneranno online.
A ByteSnap, abbiamo un modo completamente automatizzato di rilasciare progetti basati su Yocto, in modo tale da poter recuperare le fonti che entrano in una versione e, inoltre, ricostruire la stessa versione in una data successiva. Conserviamo copie di pacchetti open source in modo automatico, in modo da non subire tempi di inattività causati da server difettosi in tutto il mondo. Inoltre, sosteniamo tutto ogni singolo giorno in modo da poter garantire che nessun lavoro andrà perso anche in caso di disastro sul posto.
Fabrizio Castro
Fab è un senior software engineer. Ha conseguito la laurea triennale e magistrale presso il Politecnico di Milano. Ha 20 anni di esperienza nello sviluppo di software a tutto tondo (servizi, basi dati, applicazioni, software scientifico, firmware, RTOS, driver di periferica, kernel Linux, ecc.), trascorso a lavorare nel mondo accademico e nell’industria. Fab è co-autore di articoli scientifici e libri, e ha lavorato su brevetti. Oltre alla ricerca e allo sviluppo, è specializzato nello sviluppo di Linux embedded – offrendo progetti all’avanguardia che alimentano prodotti scientifici, industriali, commerciali e militari di successo. Fab è stato anche un docente e ha insegnato studenti universitari in alcune delle più prestigiose università in Europa. Per ulteriori informazioni su ByteSnap Design visita http://www.bytesnap.co.uk.