4.6 Processo di build di ecos Applicazioni...53 Considerazioni finali e Conclusioni...55 Riferimenti Bibliografici...59

Transcript

1 Sommario Ringraziamenti...3 Introduzione Sistemi operativi Realtime Concetto di Realtime RealTime OS Hard vs Soft Realtime Panoramica sui Sistemi operativi RealTime Content Switch, Stack, Task Control Block, Preemption e Timeslices Concorrenza Interrupt Scheduler Caratteristiche di ecos Dove è cominciato tutto Cygnus Solutions L'origine di ecos Configurabilità e configurazione I componenti chiave di ecos Supporto a processori e piattaforme di valutazione Supporto tecnico ad ecos Vione d'ineme del stema ecos Terminologia di ecos Il component framework Component Repotory Opzioni di Configurazione Pacchetti e componenti Target Template Caratteristiche di ecos Portabilità Caratteristiche di base di HAL Funzionalità di HAL Configurazione di HAL Componenti di configurazione comuni Componenti di configurazione specifici dell'architettura Inizializzazione di HAL Il kernel di ecos Meccanismi di gestione del tempo in ecos Scheduler nativi in ecos Bitmap Scheduling MLQ scheduler Sincronizzazione dei thread con ecos Esempio di applicazione usando ecos Processo di build di ecos Un'occhiata più da vicino Setup dell'hardware di sviluppo Tool di configurazione di ecos Redboot Installazione di RedBoot Boot di RedBoot

2 4.6 Processo di build di ecos Applicazioni...53 Conderazioni finali e Concluoni...55 Riferimenti Bibliografici

3 Ringraziamenti Ringrazio la Prof. Leonardi e il Prof. Valenti per la pazienza e la disponibilità che hanno avuto nei miei confronti durante il periodo di stesura dell'elaborato. Ringrazio immensamente Alfonso e Patrizia, i miei genitori, per la fiducia dimostrata in questi anni e per la sopportazione delle mie frequenti cri univertarie; senza di loro non sarei mai arrivato fino a questo punto e quindi a loro va tutto il mio rispetto, la mia riconoscenza e la mia stima. Ringrazio Alex, mio fratello, anche lui ha mi sopportato parecchio, soprattutto nelle mie richieste di aiuto notturne pre-esame e Cristiana, sua moglie, che più di una volta è data da fare per darmi aiuto con gli esami. Ringrazio poi mia nonna, i miei zii e i miei cugini che sono sempre interessanti di come stesse procedendo l'univertà. Ringrazio tutti i miei amici, in particolar modo Mattia, Lancia, Della, Menga e Bobby con cui ho passato diverse ore a studiare; sono dimostrati veri amici e credo potrò sempre contare su di loro. Non posso poi non menzionare Kenzo e Ruset per le goliardiche serate passate aseme. Un ulteriore grazie a tutti i compagni di attività sportive, specialmente quelli della pallanuoto con cui sono rimasto in contatto nonostante l'abbia dovuta abbandonare. Devo un grazie anche alle mie amiche Elisa e Alice che mi hanno sempre ascoltato e hanno sempre avuto parole di conforto quando ne avevo bisogno. Infine un grazie a tutti coloro che in qualche modo hanno creduto in me e mi hanno sostenuto. 3

4 Introduzione Un stema operativo (SO, o in inglese OS) è il componente di infrastruttura software di un stema informatico (computer) responsabile della gestione, del coordinamento delle attività e la condivione delle risorse hardware del computer. Il stema operativo mette a dispozione dell'utente una interfaccia software (grafica o testuale) per accedere alle risorse hardware (dischi, memoria, I/O in generale) del stema. Il compito principale del stema operativo è quello di permettere all'utente, umano o non, di interagire direttamente con la macchina. Quando invece parliamo di stema operativo realtime, intendiamo un stema operativo multitasking (che permette l'esecuzione contemporanea di più proces) programmato per applicazioni realtime cioè genericamente con vincoli temporali. Queste applicazioni includono stemi embedded (progettati per uno specifico scopo), robot industriali, macchine a controllo numerico, equipaggiamento scientifico, etc. Come vedrà nel capitolo uno del presente elaborato, un stema operativo realtime rende posbile la creazione di un stema realtime, ma non garantisce che il risultato finale a realtime; questo richiede infatti il corretto sviluppo del software. Un stema operativo realtime non deve necessariamente avere grandi capacità elaborative quanto piuttosto garantire di riuscire a fare il proprio lavoro entro i tempi prefissati. I SO realtime sono valutati in modo migliore più velocemente e/o deterministicamente rispondono a particolari eventi piuttosto che alla quantità di lavoro che riescono a svolgere in un determinato periodo. Nel capitolo uno inoltre vedremo poi come un stema realtime riesce attraverso algoritmi di scheduling (organizzazione del lavoro) a fornire gli strumenti che gli permettono di essere predicibile nel tempo. La diffuone di dispotivi embedded che utilizzano stemi operativi realtime è curamente sottostimata dalla popolazione media; questo perché sono generalmente nascosti. Solitamente hanno risorse limitate e sono studiati per avere una bassa interazione con l'uomo, oppure quando permettono l'interazione, questa avviene in maniera diversa rispetto a quella clasca mouse-tastiera-monitor. L'interazione, nei ca di stemi operativi realtime per dispotivi embedded, avviene solitamente con attuatori (pulsanti) e/o sensori. Un esempio di dispotivi commerciali che fanno uso di questo tipo di stemi operativi sono: lettori mp3, console portatili da gioco, stampanti, fotocamere, dispotivi GPS, robot, telefoni cellulari etc. 4

5 Vista la diffuone di questi stemi operativi, nel capitolo due andremo ad introdurre ecos, un stema operativo realtime, open source, royalty-free per stemi embedded, che viene utilizzato per il tipo di applicazioni poc'anzi descritte. Vedremo come e perché è nato, come è strutturato, quali sono i suoi componenti chiave, come configura e con quali piattaforme hardware può essere utilizzato. Il capitolo tre è dedicato all'approfondimento delle caratteristiche chiave di ecos: il kernel, HAL, lo scheduler e i meccanismi di ncronizzazione dei thread. Nel quarto capitolo poi andremo a vedere un esempio di processo di build di ecos, cioè come riesce attraverso l'ambiente fornito da ecos a realizzare una propria applicazione che girerà poi su una piattaforma hardware reale. Infine l'elaborato conclude con alcune conderazioni e commenti relativi a quanto appreso. 5

6 1 Sistemi operativi Realtime 1.1 Concetto di Realtime Nel panorama informatico vi sono molteplici definizioni di realtime, ma il più di esse sono contraddittorie. Il tema è piuttosto discusso poiché non trova un accordo sulla terminologia. La definizione canonica di un stema realtime, data da Donald Gillies (matematico e informatico), è la seguente: Un stema è realtime quando la correttezza della computazione dipende non solo dalla correttezza logica della computazione, ma anche dal tempo richiesto per produrre il risultato di questa. Se la restrizione temporale del stema non sono rispettate, questo può portare alla cri del stema. Questa definizione, ha portato altri ad aggiungere: è essenziale che che le restrizioni temporali del stema abbiano una garanzia che vengano rispettate. Questa garanzia richiede che il stema a di tipo prevedibile. Sarebbe inoltre gradito che il stema mantenga un altro grado di utilizzazione mentre soddisfa le restrizioni temporali. Il clasco esempio di software che deve essere realtime è quello del stema frenante ABS: se non viene azionato in tempo il stema ABS, questo può causare un incidente. Quindi è estremamente importante che i progettisti di stemi realtime conoscano tutte le posbili castiche di funzionamento del stema in modo da poterne prevedere il comportamento. Per questo motivo i progettisti spendono gran parte del loro tempo a studiare quello che è definito il caso peggiore in termini prestazionali. L'istituto degli ingegneri elettrici ed elettronici (IEEE) definisce invece il concetto di realtime attraverso lo standard POSIX : Real time in un stema operativo: l'abilita del stema operativo di soddisfare un determinato carico di lavoro in un determinato tempo di risposta. Anche il dipartimento di ingegneria aerospaziale del politecnico di Milano dà la sua definizione di stema realtime: un stema capace di garantire requiti temporali del processo sotto il suo controllo. Il stema deve quindi essere veloce e predicibile. Veloce gnifica con basse latenze, per esempio nel rispondere ad eventi esterni ancroni in tempi ridotti. Più è bassa la latenza, meglio il stema risponde ad eventi che richiedono attenzione immediata. Predicibile gnifica che deve essere posbile determinare il periodo di completamento del processo in un tempo certo. 6

7 Un'altra interessante definizione di stema operativo realtime (o RTOS) è quella data dal prof. Claudio Melchiorri del DEIS (Dipartimento di Elettronica, Informatica e Sistemistica dell'univertà di Bologna): un RTOS è un stema in cui per valutare la correttezza delle operazioni condera anche la variabile tempo. Devono essere garantite quindi due tipologie di correttezza: la correttezza logica e quella temporale. La prima implica che i risultati e le risposte forniti dal stema ano quelli previsti (giusta computazione dei dati), mentre la seconda deve fare in modo che i dati ano prodotti entro certi limiti temporali fissati (deadlines). Nel marzo 2003, presso la nostra Univertà, è tenuto un seminario sulla progettazione dei stemi embedded e realtime, durante il quale il Prof. Valenti ha illustrato il suo punto di vista sulle caratterizzazioni realtime: Le specifiche tecniche dei stemi embedded contengono spesso vincoli sui tempi di risposta agli eventi esterni tali, da soli, a giustificare l'avvio di una progettazione hardware dedicata. Tali vincoli temporali, indicati dal Prof. Valenti, possono essere di vario tipo: Deadline: è la richiesta temporale più restrittiva; conste nella pretesa di ascurare un tempo masmo di risposta prevedibile e sempre inferiore ad un certo limite fra il presentar di un evento e la generazione dell'evento effetto. Si conderi, come esempio, un stema di controllo dei freni di un veicolo che, in alcun caso, può ammettere un ritardo imprevedibile fra il comando di frenatura e l'attuazione dello stesso. Average: è una richiesta piuttosto generica che conste nello specificare un ritardo tipico fra evento stimolo ed evento effetto. Questo traduce nel dimenonamento del tempo medio di risposta in una tuazione standard senza conderare il caso peggiore che potrebbe anche essere notevolmente più lento. Burst: è una richiesta che non influisce sul tempo di risposta ma, piuttosto, sulla capacita del stema di non perdere eventi, eventualmente utilizzando strumenti di accodamento hardware (fifo o milari). Si conderi, ad esempio, un frame grabber che deve acquire una immagine senza, ovviamente, perdere alcun pixel, pur potendo impiegare un tempo variabile nella succesva elaborazione dell'informazione. I stemi che hanno almeno un vincolo del tipo deadline sono identificati come stemi hard realtime mentre quelli che hanno almeno un vincolo "average" o "burst" sono detti stemi soft realtime. Nel caso in cui le specifiche funzionali non contengano alcun vincolo temporale, invece, ha un stema senza caratterizzazione realtime. 7

8 1.2 RealTime OS Hard vs Soft Realtime Una volta introdotto il concetto di realtime, posamo approfondire l'argomento andando ad analizzare le due modalità appena annunciate: la modalità hard-realtime e softrealtime. La modalità hard-realtime condera inutile il completamento dell'operazione dopo la sua deadline temporale, poiché questo può portare (nell'ambito di utilizzo) a un guasto completo del stema. I stemi hard-realtime sono usati quando è imperativo che il completamento dell'elaborazione rientri nei tempi prestabiliti. Questi stemi sono rivolti ad ambiti in cui il non rispetto della deadline può causare danni fici al stema e all'ambiente che lo circonda: per esempio un pacemaker o il stema di frenata di un auto. Nei stemi soft-realtime invece posamo pensare che le deadline vengano mediamente rispettate, ma non vi sono garanzie che questo accada, né possono fare previoni deterministiche sui tempi di esecuzione delle operazioni succesve. I stemi softrealtime, sono tipicamente usati dove vi è un accesso di tipo concorrenziale dei dati con più stemi interconnes tra di loro che ne fanno uso. Un esempio tipico è quello del stema che ncronizza i voli aerei di linea: i piani aerei devono rimanere costantemente aggiornati, ma può operare senza danni anche con latenze di qualche secondo. Generalmente anche i stemi audio-video sono di questo tipo: se la garanzia temporale non viene rispettata, avrà un degrado della qualità del segnale, ma il stema può continuare a funzionare. 1.3 Panoramica sui Sistemi operativi RealTime Innanzitutto dobbiamo definire cosa rende realtime un stema operativo (RTOS): un RTOS deve essere multi-threaded e preemptible. Deve cioè permettere l'esecuzione di più thread e deve essere munito di un stema che permetta l'interruzione temporanea di un processo che è in esecuzione senza la sua cooperazione. Tale processo verrà poi ripristinato quando il processo a priorità più alta che è stato messo in esecuzione al suo posto, ha concluso le sue operazioni. 8

9 Deve essere presente un meccanismo di priorità. Nella progettazione del stema, sa a priori che alcuni thread hanno più priorità di esecuzione rispetto ad altri; il stema operativo deve prevedere un meccanismo di gestione di queste priorità. L'OS deve supportare un meccanismo di ncronizzazione dei thread di tipo prevedibile (per esempio mutex, semafori, flags, monitor, etc..). Il comportamento deve essere noto. Ciò implica che i produttori di RTOS rilascino determinate specifiche: masma latenza nel servire una richiesta di interrupt, determinato verificando a analiticamente che sperimentalmente il numero di cicli macchina (clock) che intercorre nel caso peggiore fra l'irq (interrupt request) e l'esecuzione della prima istruzione della ISR (interrupt service routine): questo deve essere prevedibile, ripetibile e compatibile con i requisti dell'applicazione. Questo valore, detto interrupt latency, non dipende dal numero di interrupt multanei in attesa essendo per definizione quello del caso peggiore (worst case). il masmo tempo che richiede ogni chiamata di stema (system call). Questo valore può essere eventualmente dato in forma tabulare per determinate configurazioni, ad esempio il numero totale di task o oggetti di stema. Il progettista ne dovrà tenere conto. il tempo masmo di mascheramento degli interrupt da parte di OS e drivers. Lo sviluppatore ha inoltre la completa responsabilità di caratterizzare opportunamente dal punto di vista temporale ogni elemento che possa introdurre ritardi nel processamento degli eventi da trattare in realtime ad esempio dovrà essere posta molta attenzione ai canali DMA ed all'eventuale adozione di cache per dispotivi di memoria intrinsecamente lenti (DRAM). L'offerta commerciale di stemi operativi Real Time è piuttosto ampia. Senza entrare troppo nel dettaglio, andremo ad elencare quelli più conosciuti: ecos (Red Hat) LynxOS (LynuxWorks) Neutrino (QNX Software System) Nucleus (Mentor Graphics) psosystem (Wind River) 9

10 QNX (QNX Software System) Quadros (RTXC) Linux/RT (TimeSys) VxWorks (Wind River) RTAI (Politecnico di Milano) 1.4 Content Switch, Stack, Task Control Block, Preemption e Timeslices Ogni stema operativo per permettere l'esecuzione contemporanea di thread e proces (stema operativo multitasking), ha bisogno di un stema che salvi lo stato della CPU nei momenti in cui deve eseguire un cambio di processo attivo. Questo stato, cioè il contenuto dei registri della CPU e del program counter, è chiamato contesto e l'operazione di cambio contesto è detto context switch. Un registro è una piccola quantità di memoria molto veloce che riede all'interno della CPU che è usata per velocizzare l'esecuzione di programmi, fornendo un accesso veloce ai dati più usati, solitamente durante l'elaborazione. Il program counter invece è un registro specifico che memorizza l'indirizzo di memoria della prosma istruzione che deve essere eseguita. Si noti che su alcune architetture, il program counter memorizza l'indirizzo dell'istruzione che sta eseguendo. Il contesto normalmente trova su una porzione dello stack di ogni processo e concorre a formare il task control block (TCB) ineme a informazioni di carattere più generale come il nome del task, la priorità o dati statistici di esecuzione utili per il debug (figura 1.1). 10

11 Figura 1.1: Contesto e Task Control Block Lo stack è infatti una struttura dati con politica di accesso di tipo LIFO (Last Input First Output) cioè i dati vengono letti in modo inverso rispetto a cui sono stati scritti. Oltre al contesto, lo stack può contenere: variabili automatiche indirizzo di ritorno di chiamate (call) argomenti relativi ai registri Il meccanismo del context switch è una caratteristica fondamentale dei stemi operativi multitasking poiché anche in caso di CPU ngola, ha l'illuone di avere l'esecuzione multanea di due o più proces: la rapida esecuzione di questo meccanismo (centinaia o migliaia di volte al secondo) dà appunto questa illuone (figura 1.2). Figura 1.2: Meccanismo del context switch Il cambio di contesto può avvenire come risultato di un processo che ha volontariamente rinunciato al suo tempo disponibile di CPU, come decione presa dallo scheduler in conseguenza del fatto che il processo ha terminato il timeslice di CPU oppure in seguito ad una preemption causata dall'arrivo di un thread a priorità più alta. Il timeslice è un periodo di tempo predefinito in fase di progettazione entro il quale ogni processo ha il 11

12 permesso di funzionare; al termine di questo tempo ovviamente il lavoro di quest'ultimo non viene perduto, ma viene congelato per poi essere ripreso al momento opportuno. Lo scheduler è quella parte del stema operativo che occupa di scegliere quale processo mandare in esecuzione (riesumandolo o facendolo partire ex novo). Nelle figure 1.3 e 1.4 viene illustrato per una particolare architettura (H8S), la tuazione della CPU idle (libera) con il task 1 pronto e poi con il task 1 in esecuzione. È importante notare che il context switch è generalmente abbastanza avido di risorse, richiedendo un tempo di CPU conderevole (qualche microsecondo) per ogni cambio di contesto; se da una parte infatti il diminuire del tempo di timeslice potrebbe darci maggiore illuone di esecuzione contemporanea di proces, dall'altra ci porta ad un degrado prestazionale causato dalle richieste di stema effettuate durante il cambio di contesto. Vediamo ora i punti essenziali del context switch partendo dal caso di avere due task, task 1 e task 2, di cui task 1 è in esecuzione (figura 1.4) e subisce preemption a causa dell'arrivo del task 2 più prioritario. 1. Sospenone del processo corrente attraverso il salvataggio del contesto 2. Recupero del contesto del prosmo processo da mettere in esecuzione 3. Inserimento del contesto appena recuperato nei registri della CPU (figura 1.5) 4. Ritorno alla locazione di memoria puntata dal program counter (ritorno alla linea di codice che rimette in esecuzione il processo che era stato interrotto) e quindi dopo al context switch il processo in esecuzione è il task 2 (figura 1.6). Figura 1.3: Stato della CPU con il task1 pronto 12

13 Figura 1.4: Figura il task 1 mette in esecuzione Figura 1.5: il task 2 a priorità più alta di task 1 effettua un Context Switch 13

14 Figura 1.6: Il Task 2 è in esecuzione 1.5 Concorrenza La gestione del multitasking in un stema operativo è tanto importante quanto delicata. Per capire meglio come gestisce il multitasking è necessario mettere in evidenza la differenza che c'è tra thread e proces. Mentre i proces sono solitamente indipendenti tra di loro, utilizzando diverse aree di memoria, i thread condividono risorse di stema, memoria e informazioni di stato. La progettazione di applicativi concorrenti in un ambiente orientato ai proces richiede dei servizi di stema (system call) dedicate alla comunicazione come le pipe o i socket di unix. La memoria viene infatti solitamente gestita attraverso MMU (Memory Managment Unit). In questo caso non sono richiesti particolari accorgimenti nel codice applicativo per ascurare la constenza dei dati scambiati in quanto è il kernel ad occupar di questo (atomicità della read o della write, acces concorrenti). La progettazione degli stes applicativi in un ambiente orientato ai thread invece viene da un lato agevolata dalla condivione della memoria; ogni thread infatti può accedere alla medema locazione di memoria per leggere o modificarne il contenuto senza richiedere alcun servizio al SO. Il software applicativo deve però disporre di alcuni 14

15 strumenti per ascurare la constenza dei dati condivi. Ad esempio: due thread accedono ad una variabile di tipo char che normalmente (dipendente comunque dall'architettura), viene acceduta con una istruzione non interrompibile. In questo caso non estono particolari problemi in quanto in un accesso concorrente in scrittura perde il precedente valore ma mantiene l'ultimo scritto. Ipotizziamo comunque che questa variabile di tipo char (detto comunemente tipo atomico) debba essere incrementata da due thread concorrenti. Il thread A legge il valore corrente della variabile (ad esempio 0) poi accinge a scrivervi il nuovo valore (1). Nel mentre il thread B opera una preemption di A e decide di fare lo stesso, quindi legge ancora 0 (A non ha ancora scritto il suo nuovo valore) e scrive il suo nuovo valore 1. A questo punto il thread A viene ripreso ed esegue la scrittura di 1 mentre il doppio incremento avrebbe richiesto la scrittura del valore 2. I thread A e B devono essere ncronizzati per evitare questo tipo di comportamento che facilmente degenera se il tipo di dati acceduti non è atomico o se le operazioni su questi sono più complesse del semplice incremento. Il SO deve mettere a dispozione dei meccanismi di ncronizzazione (in questo caso dei mutex) e il software applicativo deve utilizzarli; è quindi responsabilità del programmatore/stemista evitare il crear di tuazioni quali race condition (corse critiche) e deadlock (stallo). 1.6 Interrupt Lo stato di interruzione rappresenta un contesto aggiuntivo a quello dei proces o dei thread. Si definisce interrupt un tipo particolare di interruzione della CPU che provoca l'interruzione di un processo qualora verifichino determinate condizioni oppure il processo in esecuzione debba effettuare una richiesta al stema operativo. È come un segnale o messaggio, generalmente di natura ancrona, che arriva alla CPU per avvisarla del verificar di un certo evento. Ci sono due tipi di interrupt: Interrupt hardware generati da dispotivi esterni alla CPU, che hanno il compito di comunicare il verificar di eventi esterni, di solito dispotivi di Input/Output. Interrupt software che sono delle istruzioni assembly, tipo INT xx o SYSCALL, che possono essere asmilate alle chiamate di sottoprogrammi, ma che sfruttano il meccanismo delle interruzioni per passare il controllo dal programma 15

16 chiamante a quello chiamato, e viceversa; vengono utilizzati per accedere direttamente alle risorse del stema operativo. L'uso di interrupt è una tecnica ampiamente utilizzata in stemi multitasking e in particolare in stemi di tipo realtime. Quando presenta un interrupt il SO ha poca libertà di azione in quanto normalmente è bloccata la rilevazione di altri eventi ancroni. Come è stato detto, nei stemi realtime il tempo masmo di blocco di una interruzione, deve essere dichiarato. Per un stema operativo general purpose come UNIX o Linux, il trattamento dell'interruzione viene eseguito dal kernel stesso, eventualmente delegando parte della elaborazione ai device drivers. In un stema operativo realtime invece, il trattamento viene solitamente delegato all'applicativo che è stato scritto in modo che sappia come deve operare. Il kernel mette solo a dispozione i mezzi per ncronizzare i thread con l'evento (segnalazione di semafori, accodamento dei dati, schedulazione di thread). 1.7 Scheduler Sebbene a già stata messa in evidenza l'importanza dello scheduler, cerchiamo di fare un po' di chiarezza sul comportamento nei stemi operativi convenzionali, nei stemi operativi soft-realtime e nei stemi operativi hard-realtime. Per i primi posamo dire che il meccanismo di schedulazione ha l'obiettivo di ottimizzare le prestazioni globali del stema, per esempio cercando il compromesso tra la minimizzazione dell'overhead (cioè richieste aggiuntive a quelle strettamente necessarie) e la distribuzione delle risorse di processore ai vari task. Invece nei stemi soft-realtime cerca di ottimizzare i tempi di risposta, mentre nei stemi hard-realtime lo scheduler ha il compito di garantire il rispetto delle deadline. In questi ultimi stemi, interruzioni e proces hanno tutti una priorità definita in quanto è imperativo che vi a sempre la corrispondenza tra tempo fico e tempo di clock. Riassumendo posamo dire che lo scheduler provvede a scegliere quale thread mettere in esecuzione ogni qualvolta un evento interno od esterno modifichi lo stato globale del stema. 16

17 2 Caratteristiche di ecos 2.1 Dove è cominciato tutto Cygnus Solutions Cygnus Solutions, fu fondata nel 1989 da John Gilmore, Michael Tiemann e David Henkel-Wallace con lo scopo di fornire supporto commerciale al free software. Il suo motto era: Making free software affordable, cioè Rendiamo il free software conveniente. Cygnus è un acronimo di "Cygnus, Your GNU Support", "Cygnus, il Tuo Supporto a GNU. L'idea che ebbero questi sviluppatori fu quella di concentrare il loro lavoro sulla creazione di un piccolo set di strumenti open source che sarebbe poi stato venduto. Iniziarono quindi vendendo il compilatore GNU (GCC) e il debugger (GDB) come un piccolo pacchetto software. Questo fu posbile grazie all'enorme talento di Tiemmann, il quale contribuì a numero port del compilatore GNU e scrisse il primo compilatore nativo in C++. L'altro importante contributo venne da Henkel-Wallace e Gilmore che svilupparono rispettivamente le binutils (utility binarie) e il debugger GDB. Questo lavoro ebbe talmente grandi proporzioni che Gilmore divenne il nuovo mantainer di GDB; quando la comunità internet lo venne a sapere, vi fu una inondazione di differenti veroni del debugger; questo portò a integrare in GDB le nuove caratteristiche proposte dalla comunità. Tutto questo duro lavoro è poi stato ripagato in quello che oggi chiamiamo GNUPro Developers Kit, il quale include: GCC Gnu Compiler Collection, un compilatore con supporto a numero linguaggi di programmazione, fra cui il C in particolare; G++ - Compilatore C++ che fa parte di GCC; GDB - GNU DeBugger; GAS GNU Assembler; LD GNU Linker; Cygwin Un set di strumenti per migrare applicazioni da UNIX/Linux alla piattaforma Microsoft Windows; Inght Interfaccia grafica per fare debug; 17

18 Source-Navigator - Un strumento per la comprenone e l'anali del codice 2.2 L'origine di ecos Alla fine degli anni '90 il mercato dei stemi operativi realtime era piuttosto frammentato. Cygnus, grazie all'esperienza maturata e al rapporto con i produttori di semiconduttori, volle creare una soluzione software per dispotivi embedded che fosse di alta qualità e concorrenziale dal punto di vista dei costi. Questa soluzione andava ad affiancare al set GNUPro, espandendo l'offerta di Cygnus. Quello che questo team andò a sviluppare fu un stema operativo realtime che permetteva l'astrazione dell'hardware e che era altamente configurabile. Nacque co ecos (embedded Configurable operative system), un RTOS che adattava a numero stemi embedded e che grazie alla sua flesbilità permetteva una forte riduzione dei tempi per lo sviluppo di questi stemi: la riduzione dei tempi e quindi dei costi è sempre un aspetto fondamentale nei stemi embedded. Utilizzando il modello di sviluppo open source, ecos è a costo zero dato che può essere scaricato e provato gratuitamente. Inoltre un altro aspetto estremamente importante è l'essere royalty-free, cioè non vi sono neppure costi a posteriori. Gli sviluppatori hanno accesso completo a tutto il codice sorgente, strumenti inclu, che possono essere modificati a piacere. Non ci sono costi iniziali associati a licenze di utilizzo del codice e neppure ai tools relativi; tutto ciò che serve per inizializzare lo sviluppo di un stema embedded può essere fatto senza alcuna spesa. Gli sviluppatori non devono neanche dare nessun contributo relativo al codice sviluppato per componenti aggiuntivi o applicazioni sviluppate, ma devono fornire le eventuali modifiche fatte al codice di ecos. Questo permette alla comunità open source di sviluppare un prodotto sempre migliore Configurabilità e configurazione Per capire meglio l'architettura di ecos, è importante analizzare le peculiarità del framework che compongono il stema ecos. Il framework dei componenti è specificamente orientato ai stemi embedded e adatta perfettamente al modello dei stemi embedded. 18

19 Usando questo framework, un enorme quantità di funzioni per una applicazione può essere costruita da componenti software già utilizzati o da blocchi di esso. Il framework dei componenti di ecos è stato progettato per minimizzare l'uso di memoria dei componenti del stema, permettere agli utenti di tenere sotto controllo le tempistiche per soddisfare le caratteristiche di realtime, ed utilizzare i più diffu linguaggi di programmazione (C, C++ e assembly). La maggior parte dei stemi embedded oggi sul mercato supporta più funzionalità di quelle che servono per una specifica applicazione. Spesso viene incluso software aggiuntivo che dà un supporto generico a caratteristiche a cui gli sviluppatori di stemi embedded non sono interessati o di cui non hanno bisogno. Questo software aggiuntivo concorre a rendere il stema più complesso ed inoltre più il codice è lungo e più ci sono probabilità che qualcosa non vada. Un esempio estremo è quello del programma Hello world : usando i tradizionali RTOS, che hanno supporto a mutex, task switching ed altre caratteristiche integrate, tutte queste funzionalità sarebbero presenti nonostante non ce ne a il bisogno. In questo senso ecos dà la maggiore posbilità di controllo dei componenti di run-time, dando la posbilità agli sviluppatori di rimuovere ciò che non è necessario. Il stema ecos è quindi un stema altamente scalabile: possono creare stemi con dimenoni dell'ordine delle centinaia di bytes fino a migliaia di kilobytes quando caratteristiche come lo stack di rete e componenti di terze parti come un web server vengono utilizzate. Gli sviluppatori possono scegliere i componenti che soddisfano le richieste base delle loro applicazioni e configurare quel particolare componente per una specifica implementazione richiesta dall'applicazione. Questo gnifica potere abilitare o meno una specifica caratteristica di un componente, o selezionare una particolare implementazione di quel componente. Un esempio pratico è quello della configurazione dello scheduler del kernel: ecos dà la posbilità di selezionare il numero di livelli di priorità e se utilizzare i time slicing. Ogni linea di codice non necessaria per l'applicazione viene eliminata dall'immagine finale dell'applicazione. La configurabilità permette alle ditte di costruire una base di componenti riutilizzabili, con l'accesso al codice sorgente del componente. Questo può ridurre il tempo di sviluppo e il tempo di immisone sul mercato poiché i componenti sono altamente portabili e possono essere utilizzati in un ampio range di applicazioni. Il framework di ecos incoraggia lo sviluppo di codice di terze parti in modo tale da estendere caratteristiche e funzionalità dei componenti chiave di ecos. Se gli 19

20 sviluppatori lavorano per estendere funzioni sul prodotto e contribuiscono a renderle disponibili in ecos, la crescita delle funzionalità di ecos sono senza limiti. Inoltre, se la funzionalità non è al momento disponibile, il codice sorgente è disponibile e permette di risolvere il problema da sé. La filosofia del controllo dei componenti nell'implementazione di ecos è quella di ridurre le dimenoni del codice, sempre e il più posbile. In questo modo anche stemi minimali non soffrono dell'inserimento di codice aggiuntivo necessario al supporto di caratteristiche avanzate che vengono usate solo in stemi più comples. Nello sviluppo di applicazioni, i metodi di controllo dei componenti software possono essere di 3 tipi: a tempo di esecuzione, a tempo di link e tempo di compilazione. Il metodo utilizzato da ecos è quest'ultimo, in combinazione con il linking selettivo fornito dal GNU Linker: in questo modo hanno i migliori risultati in termini di dimenone del codice e ciò lo rende adatto allo sviluppo di stemi embedded. L'uso del metodo di controllo a tempo di compilazione, anche detto metodo di configurazione a livello sorgente, avviene grazie al preprocessore C e ciò offre numerosme opzioni specifiche che possono essere applicate al codice. Oltre alla generazione di codice più corto, la configurazione a livello sorgente offre molti altri importanti vantaggi nello sviluppo di software per stemi embedded: le applicazioni sono più veloci perché le variabili non devono essere controllate durante l esecuzione per determinare quale azione intraprendere; il codice è più reattivo e le latenze sono ridotte, il che permette di avere stemi più deterministici che è molto importante in dispotivi realtime; il codice generato è più semplice, rendendo verifiche e test più facili da eseguire il codice è generato su misura dell'applicazione e crea quindi una specifica applicazione per RTOS; i costi possono essere ridotti perché l'utilizzo di risorse è ottimizzato e il numero di cicli di CPU sono sfruttati in modo efficiente, permettendo l uso di hardware più economico I componenti chiave di ecos Le funzionalità standard che aspettano di avere in un stema operativo realtime per dispotivi embedded, sono tutte incluse aseme al kernel realtime come componenti 20