La migrazione verso LINUX EMBEDDED

In questo articolo si affronteranno gli step necessari per il passaggio da un qualsiasi sistema operativo verso Linux Embedded, una scelta importante che può avere un impatto notevole nel lungo periodo.

Linux ha guadagnato fama e importanza anche nel mercato embedded. La domanda però rimane: è stato utilizzato solo per le nuove applicazioni o anche per i prodotti già esistenti? La sostituzione di un sistema operativo in un prodotto già definito non è cosa da poco. Lo sforzo e il rischio che si corre con una migrazione verso Linux Embedded, le difficoltà tecniche e soprattutto l’analisi e la pianificazione per la migrazione, richiedono attenzione e tempo. Le motivazioni che possono portare alla scelta della migrazione possono essere molteplici: nuove funzionalità e nuove tecnologie, le performance inadeguate dell’hardware e del sistema operativo esistente oppure l’arrivo a fine ciclo di un componente (hardware o software). In ogni caso desiderio comune è che la migrazione porti a una riduzione dei costi altrimenti in molti casi non viene neppure considerata.

L’affermazione di Linux all’interno del mercato embedded è legata essenzialmente a diversi fattori: alla massiccia e libera disponibilità di codice riutilizzabile, alla possibilità di supportare diversi tipi di hardware, al numero elevato di sviluppatori che lo utilizzano, alla riduzione di costi immediata, alla flessibilità e alla possibilità di avere il completo controllo sugli strumenti di sviluppo e sul sistema operativo. Linux attualmente offre una piattaforma tecnologica adatta ai sistemi embedded, solamente i problemi legati alle esecuzioni real-time spinte e l’aspetto della certificazione rimangono punti interrogativi. In ogni caso su questi problemi le cose si evolvono e migliorano ogni giorno. La scelta di passare a Linux Embedded rappresenta spesso un valore aggiunto per il prodotto, che lo distingue dalla concorrenza. Per questo motivo solitamente il project manager punta su Linux. Lo strato di middleware necessario (ovvero la parte di software che permette all’applicazione di poter essere eseguita), viene molto spesso arricchito con funzionalità supplementari che rendono la migrazione molto più appetibile.

COME MIGRARE

Se la scelta del nuovo sistema operativo verso il quale migrare ricade su Linux, il passo successivo rimane la pianificazione delle operazioni. Il primo step è definire gli obiettivi della migrazione e valutare i possibili rischi a cui si va incontro. In linea di principio i metodi applicabili per convertire l’applicazione a Linux sono tre. Per il primo approccio, gli sforzi maggiori sono spesi sul rifacimento dell’applicazione, con l’obiettivo anche di sfruttare al massimo le potenzialità di Linux. Il codice sorgente esistente potrebbe essere adatto al porting se fa già uso di API (ad esempio UNIX o POSIX) e la struttura interna dell’applicazione è simile a Linux. Per esempio Wind River, venditrice di software, utilizza una metodologia di migrazione come in Figura 1.

Figura 1: metodologia di migrazione proposta da Wind River

Se il codice sorgente è troppo intrecciato con le API del sistema operativo corrente, la soluzione potrebbe essere inserire un livello di API intermedio per comunicare tra le API correnti e quelle di Linux. Se anche questa soluzione non è possibile, allora l’applicazione deve rimanere abbinata al sistema operativo corrente e stratificata in modo da appoggiarsi su Linux, come l’ultimo caso di Figura 2.

Figura 2: le tre possibili strategie per realizzare la migrazione

Questo approccio richiede la scrittura di un livello di astrazione hardware, HAL (Hardware Abstraction Layer) per un sistema operativo legacy. Un obiettivo difficile da raggiungere se il sistema operativo non utilizza già un HAL o se questo non è documentato. Un’alternativa percorribile è la virtualizzazione per “incapsulare” l’applicativo e il sistema operativo esistenti. Ovviamente se la CPU permette di virtualizzare mantenendo le prestazioni a un livello accettabile. A parte questi problemi di carattere generale, esistono alcuni specifici accorgimenti per Linux da considerare durante la migrazione. I task del sistema operativo corrente saranno raggruppati come thread di un processo Linux, perciò la separazione tra lo spazio utente e kernel è da mettere in conto.

A seconda dei requisiti sul tempo di risposta dell’applicazione, il kernel Linux potrebbe essere in grado di soddisfare le richieste senza modifiche (il tempo di risposta a un evento è di circa 10 millisecondi), oppure necessitare di interventi, come l’applicazione della patch PREEMPT_RT al kernel (il tempo di risposta scende a 100 microsecondi). Se l’applicazione richiede tempi di risposta deterministici, ossia garantiti al 100%, inferiori ai 10 microsecondi, Linux non è in grado di soddisfare questo requisito. In questo caso i sistemi operativi non più gratuiti basati su Linux Embedded ci vengono in aiuto, come per esempio quello proposto da Wind River che aggiunge alla CPU un meccanismo di scheduling real-time che permette di elaborare eventi in tempi brevissimi se la CPU non è impegnata in thread o interrupt che utilizzano la CPU al 100%.

Il passaggio da un sistema a memoria distribuita con indirizzi fisici a un sistema con indirizzi virtuali e pagine, protetto da MMU (Memory Management Unit) come è Linux, richiede delle modifiche. La comunicazione tra i processi e la sincronizzazione dovrebbero mantenersi, non esistono problemi di compatibilità su questi argomenti. Linux ha rigida struttura degli utenti e dei file, perciò le personalizzazioni sono molto richieste su questi aspetti. Un modo per ovviare a questo problema è scrivere un’applicazione di partenza che imposti l’ambiente e poi far partire l’applicazione migrata come processo figlio. Tutto ciò impone un aggiustamento delle priorità dei task per il modello Linux a thread. Non ha senso migrare i driver di dispositivo, se sono necessari è meglio pianificare una nuova implementazione. Linux richiede memoria RAM e flash in maniera superiore rispetto ad altri sistemi operativi; questo aspetto è da tenere in considerazione quando si sviluppa l’hardware. Un kernel di Linux tipico va da 1 a 2 megabyte, il che significa predisporsi per avere almeno 8 Mb di RAM in un sistema Linux. Per facilitare il test e il debug sono a disposizione i sorgenti dell’interfaccia JTAG, seriale ed Ethernet. L’avvio di Linux differisce dagli altri sistemi operativi real-time, Linux necessita di un boot-loader e accede a un “mountable root file system” contenente tutti i binari, che deve risiedere in flash, su disco collegato o su file server NFS in rete.

Figura 3: vantaggi proposti dalla versione commerciale di Linux proposta da Wind River

QUALE LINUX?

La questione ancora irrisolta è quale versione di Linux Embedded utilizzare per la migrazione. Questa domanda può sembrare superflua in un primo tempo, ma la risposta può impattare sul successo a lungo termine della migrazione. All’inizio esistevano quatto possibilità:

autocostruirsi Linux, detto anche RYO, ossia Roll Your, costituisce la scelta più originale e permette di avere il controllo completo ma anche la completa responsabilità di manutenzione. Si sceglie questa strada quando i vantaggi sono consistenti e i rischi di progetto notevoli, tutte cose che comunque non contribuiscono a incrementare le caratteristiche e il valore del prodotto finale;
una distribuzione Linux gratuita come Ubuntu, Fedora, OpenSUSE o Debian sono solitamente non adatte ai progetti embedded a causa della loro stretta correlazione con le architetture x86 delle CPU;
le versioni Linux offerte dai costruttori di hardware non sono solitamente aggiornate e hanno una scarsa manutenzione, specie nel lungo periodo. Pagano, inoltre, la mancata correlazione con gli strumenti di sviluppo, fatta eccezione per il compilatore. Così anche se si dichiarano adatte per supportare diverse piattaforme hardware, si rivelano spesso inadeguate e laboriose;
versioni di Linux commerciali. Offrono i vantaggi di Linux (open source, codice libero e supporto diffuso) senza lo sviluppo aggiuntivo, lo sforzo per il debugging e le limitazioni associate ad un RYO o a una versione abbinata all’hardware.

Con un’attenta pianificazione e valutando in anticipo quelli che potrebbero essere i problemi che si presenteranno, la migrazione potrebbe avere successo. Quello che il mercato dei sistemi operativi embedded conferma, è che buona parte di chi sceglie Linux si appoggia a prodotti commerciali, questo permette allo sviluppatore di concentrarsi sull’applicazione e sul suo miglioramento, minimizzando allo stesso tempo i rischi sul breve e sul lungo periodo.