Linux Real-Time Introduzione a POSIX1003.1b

1
Linux Real-TimeIntroduzione a POSIX1003.1b

• E.Mumolo, DEEI
• mumolo_at_units.it

2
Il Sistema Operativo Linux

• Numerazione versioni di linux a.b.c (es. 2.4.16)
  dove
• a ? no. versione,
• b ? kernel stabile (se pari), in sviluppo (se
  dispari)
• c ? no. di rilascio del kernel (se pari stabile,
  se dispari in sviluppo)
• Storia del kernel

3
Linux non è in tempo reale

• Linux è nato come un sistema multiutente per usi
  generali
• Sistemi Operativi per usi generali massimizzano
  il throughput alle spese del tempo d'attesa
• Sistemi Operativi in tempo reale minimizzano il
  tempo d'attesa alle spese del throughput
• In particolare
• Le chiamate di sistema di Linux non sono
  interrompibili ? tempi d'attesa non riducibili
• Linux usa memoria paginata ? tempi d'attesa
  impredicibili
• Linux usa una schedulazione equa ? trattando in
  modo equanime tutti i processi si penalizzano i
  processi a alta priorità
• Linux ordina le richieste di I/O per ottimizzare
  l'uso dell'I/O ? un processo a bassa priorità
  potrebbe avere precedenza rispetto ad uno a alta
  priorità

4
Prestazioni di Linux
5
Sistemi in tempo reale

• Un sistema opera in tempo reale soltanto se
  fornisce i risultati attesi entro predefiniti
  limiti temporali
• Proprietà desiderate
• non solo
• correttezza
• affidabilità
• flessibilità
• portabilità
• riusabilità
• ma anche
• efficienza
• prevedibilità
• Attenzione Tempo reale non significa
  necessariamente elevata potenza di calcolo!

6
Tipi di processo

• Real-time con vincoli temporali
• Hard rt se la relativa deadline deve sempre
  essere rispettata
• Periodico con frequenza di esecuzione costante
• Sporadico in caso contrario
• Soft se la relativa deadline può essere disattesa
  in condizioni di temporaneo sovraccarico
• Periodico con frequenza di esecuzione costante
• Aperiodico in caso contrario
• Non real-time senza vincoli temporali

7
Tipologie di schedulazione

• Off-line
• se integralmente pianificata a priori
• On-line
• se stabilita a tempo di esecuzione in base a
  parametri attribuiti ai processi in maniera
• statica
• dinamica
• Guaranteed
• se rispetta i vincoli di esecuzione di ogni
  processo
• Best-effort
• se tende viceversa ad ottimizzare le prestazioni
  medie dellinsieme di processi
• Preemptive
• se lesecuzione di un processo può essere sospesa
• Non-preemptive in caso contrario

8
Sistemi embedded e sistemi in tempo reale

• I sistemi embedded (dedicati) sono quelli che
  fanno parte integrante di un dispositivo
• Ad esempio un calcolatore PDA, un telefono
  cellulare, una segreteria telefonica elettronica,
  una centralina di controllo di unautomobile sono
  tutti sistemi che vengono attivati allaccensione
  del dispositivo di cui fanno parte integrale
• A seconda dei vincoli temporali richiesti dal
  dispositivo i sistemi possono essere considerati
  in tempo reale o meno
• Una delle caratteristiche più importanti del
  sistema in tempo reale è il tempo con cui il
  sistema risponde a eventi interni (segnali o
  trappole software) o esterni (timer esterni o
  interrupt hardware).

9
Sistemi embedded e sistemi in tempo reale

• Una prima misura della risposta del sistema è la
  latenza, cioè il tempo che intercorre tra
  levento e la prima istruzione della routine di
  servizio dellevento
• Una seconda misura è lo jitter, la variazione del
  periodo di eventi periodici con periodo costante
• Per essere in grado di presentare bassa latenza e
  basso jitter, il sistema operativo deve garantire
  che il kernel venga interrotto da i processi in
  tempo reale.

10
Alcuni SO in tempo reale

• VxWorks (Motorola, Pentium, StrongArm, Arm)
• Aderisce a POSIX
• Robotica, controllo di processi, avionica,
  telecomunicazioni, medicina
• Prestazioni su Pentium 200 latenza media 1.7 us,
  latenza massima 6.8 us
• Windows CE .NET (ARM, StrongArm, XScale, MIPS,
  Pentium)
• Non aderisce a POSIX
• Prestazioni su Pentium 200 latenza media 2.4 us,
  latenza massima 5.6 us
• QNX Neutrino RTOS (Pentium, Power PC, ARM,
  StrongArm, XScale, MIPS, SH-4)
• Microkernel, aderisce a POSIX
• Prestazioni su Pentium 200 latenza media 1.6 us,
  latenza massima 4.1 us
• pSOSystem 3
• Aderisce a POSIX
• Prestazioni su Pentium 200 latenza media 1.9 us,
  latenza massima 3.8 us
• Arx RTOS http//arx.snu.ac.kr/html/overview-arx.en
  .html
• AvSys http//www.avocetsystems.com
• CMX RTOS http//www.cmx.com

11
Progetti Linux Real Time

• Primo approccio eliminazione di funzionalità
  dal kernel Linux standard.
• Ridurre la complessità e la dimensione del
  sistema operativo, con particolare attenzione
  alle sezioni con comportamenti meno
  deterministici
• Es. uCLinux http//www.uclinux.org
• Secondo approccio modifiche al kernel Linux
  standard.
• Sostituire lo scheduler standard Linux con un
  algoritmo più deterministico
• Aggiungere punti di chiamata dello scheduler in
  punti sicuri dei sorgenti del kernel, per
  renderlo più reattivo.
• Es. Montavista's Hard Hat Linux, KURT
  http//www.mvista.com/products/hhl.htmlhttp//www
  .ittc.ku.edu/kurt/
• Terzo approccio Linux allinterno di un sistema
  real-time
• Eseguire Linux come processo a bassa priorità di
  un minimo kernel real-time. Questo kernel
  gestisce lhardware direttamente, offrendo a
  Linux una simulazione software (macchina
  virtuale).
• Es. RTLinux, RTAI http//www.rtlinux.org/
  http//www.rtai.org/

12
In sintesi Soluzioni Real Time più popolari

• Alcuni dei sistemi operativi realtime generici
• Soluzioni proprietarie
• VxWorks
• QNX
• RTLinuxPro
• Soluzioni opensource
• RTLinuxFree (solo per kernel 2.4)
• RTAI
• RTLinux e RTAI sono soluzioni basate sul kernel
  di Linux
• Possono sfruttare tutte le applicazioni e
  l'ambiente del sistema operativo di partenza.

13
Architettura di RTAI

• Sviluppato dal Dipartimento di Ing.Aereospaziale,
  Università di Milano, www.rtai.org
• Si introduce un nuovo layer tra il kernelLinux e
  il sistema hardware RTHAL (Real-Time Hardware
  AbstractionLayer).
• Versione estesa di RTHAL ADEOS (Adaptive Domain
  Environment for Operating Systems)
• Racchiude tutti i dati e le funzioni
  temporalmente critiche del kernel in ununica
  struttura
• Sostituisce le operazioni sulle strutture
  originali con operazioni su puntatori RTHAL
• I puntatori RTHAL sono modificabili
  dinamicamente. Se RTAI non è attivo puntano alle
  strutture originali di Linux, se RTAI è attivo
  puntano alle strutture del kernel real-time
• Linux non ha più il controllo sullabilitazione /
  disabilitazionedelle interruzioni.

14
Architettura di RTAI

• Real Time HAL (RTHAL) non fornisce servizi
  real-time ha la sola funzione di intercettare le
  chiamate al kernelLinux.
• Le chiamate sono redirette alle strutture puntate
  da RTHAL.
• RTAI non attivo ? Funzionamento normale di Linux.
• RTAI attivo ? Linux è gestito come un
  processo a bassa priorità.
• Quindi RTAI può essere attivato o disattivato a
  piacere?
• SÌperché RTAI è disponibile come modulo kernel
  di Linux.
• Permette di estendere dinamicamente le
  funzionalità del kernel senza dover essere
  caricato al boot di sistema.

15
Architettura di RTAI

• Scopo realizzare un ambiente flessibile per
  condividere risorse hardware tra più sistemi
  operativi o più istanze di uno stesso SO
• La realizzazione consiste in un microkernel che
  gestisce la comunicazione con i diversi domini
  (es. SO) installati
• La gestione delle interruzioni è implementata con
  uno schema a pipeline in cui ogni stadio
  rappresenta un dominio
• Ogni interruzione è propagata alla pipeline, ogni
  stadio può
• Accettare linterrupt, gestirlo, scegliere se
  propagarlo o terminarlo
• Ignorare linterrupt, non accettarlo
  immediatamente ma gestirlo al momento opportuno,
  scegliere se propagarlo o terminarlo
• Scartare linterrupte propagarlo
• Terminare linterrupts enza propagarlo
  ulteriormente

16
Architettura di RTAI
17
RTAI scheduling

• Ogni possibile configurazione dello scheduler è
  adatta ad una specifica combinazione di hardware
  e requisiti delle applicazioni
• RTAI permette una gestione full-preemptable dei
  processi, in funzione delle loro priorità.
• Funzione del numero di processori presenti
• Scelta della modalitàdi funzionamento dello
  Scheduler
• Scelta della politica di scheduling
• Configurazione dello scheduler

18
RTAI scheduling

• Uniprocessor Scheduler(UP) Utilizzabile nei
  sistemi monoprocessore
• Symmetric Multiprocessor Scheduler (SMP) In un
  sistema multiprocessore permette una
  distribuzione di carico simmetrica.
• Ogni processo di default può essere assegnato a
  qualsiasi processore per ottimizzare
  lesecuzione è possibile imporre lesecuzione di
  un processo su una CPU o su un insieme ristretto
  di CPU
• Multi Uniprocessor Scheduler(MUP)
• In un sistema multiprocessore impone ad ogni
  processo lesecuzione su una CPU stabilita al
  momento della sua creazione. Meno flessibile ma
  più efficiente di SMP
• La scelta dello scheduler in funzione
  dellhardware in uso impatta su quale modulo
  kernel viene caricato con RTAI.

19
RTAI scheduling

• Periodic mode
• Esegue lo scheduler periodicamente il timer
  viene settato una sola volta allinizio
  dellesecuzione
• Il periodo dei processi deve essere multiplo
  esatto del periodo dello scheduler, in caso
  contrario il periodo dei processi viene
  approssimato al multiplo del periodo dello
  scheduler più vicino (introduce jitter di
  attivazione)
• One-shot mode
• Lo scheduler viene eseguito in maniera non
  periodica. Il timer deve essere settato ogni
  volta in base al processo prioritario
• Permette una gestione più flessibile delle
  temporizzazioni di tutti i processi a costo di un
  maggiore overhead dovuto alla necessità di
  riprogrammare il timer al termine di ogni periodo
• Occorre scegliere la temporizzazione con cui lo
  scheduler viene eseguito.

20
RTAI politiche di scheduling

• FIFO
• Il processo attivo a priorità più alta ottiene il
  controllo della CPU fino a quando la rilascia
  volontariamente oppure diventa attivo un processo
  a prioritàmaggiore
• Round-Robin (RR)
• Il processo attivo a priorità più alta ottiene il
  controllo della CPU per un determinato intervallo
  di tempo, al termine del quale il controllo passa
  ad un altro processo allo stesso livello di
  priorità(se presente). Un processo può subire
  preemption da parte di un processo a
  prioritàmaggiore
• RTAI integra primitive che associate alla
  politica FIFO permettono una semplice
  implementazione degli algoritmi di scheduling
  Rate Monotonic - Priority Ordered Earliest
  Deadline First.

21
RTAI politiche di IPC

• Real-time fifos
• Meccanismo di base per scambiare dati in modo
  asincrono tra processi real-time e processi
  Linuxnon real-time
• Shared Memory
• Condivide aree di memoria tra processi RT e
  processi Linux
• Messages
• Possibilitàdi inviare messaggi sia in maniera
  asincrona che sincrona (RPC) tra processi RT
• Mailboxes
• Permettono di inviare/ricevere messaggi di
  qualsiasi dimensione, ordinati per prioritào per
  istante di arrivo, tra processi RT e processi
  Linux
• Semaphores
• Permettono di sincronizzare i processi
  nellaccesso a risorse condivise evitando
  inversioni di priorità incontrollate

22
Moduli RTAI

• RTAI presenta un certo numero di moduli
• rtai_hal intercetta gli interrupt
• rtai_sched gestione dei task schedulazione,
  messaggi,
• semafori,...IPC
• rtai_fifos FIFO
• rtai_shm memoria condivisa
• rtai_lxrt task in tempo reale nello spazio
  utente LXRT
• permette di sviluppare processi real time usando
• le API RTAI da spazio utente
• rtai_pthread Thread Posix
• Questi moduli devono essere inseriti a seconda
  delle esigenze
• insmod rtai_hal
• insmod rtai_sched ...

23
Altra vista della architettura
RT FIFO
Processi Linux
Processi Linux
RT task
RT task
Kernel Linux
Real time kernel (RTHAL/ADEOS
24
Programmazione in RTAI

• Struttura utilizza 3 parti principali scritte
  dallutente
• Funzione che inizializza il sistema, definisce le
  caratteristiche dei vari task e IPC
• Definizione della funzione real time
• Funzione che rilascia le risorse

25
Programmazione in RTAI

• Esempio della funzione di inizializzazione
• int init_module(void)
• RTIME tick_period, now
• //crea la fifo
• rtf_create(0, 1000sizeof(struct msg_t))
• //inizializza la struttura rt
• // rt_task_init( , , , stacksize, priorità, uso
  fpu, signal function)
• rt_task_init(hiprio_task, task_body, F, 2000,
  0, 0, 0)
• //start rt_timer
• rt_set_oneshot_mode()
• tick_period start_rt_timer(nano2count(TIMERTICK
  S))
• //start the rt-task
• now rt_get_time()
• rt_task_make_periodic(hiprio_task,
  nowtick_period, 12tick_period)

26
Programmazione in RTAI

• Definizione di un task (thread in tempo reale)
• int rt_task_init(RT_TASK task,
  void(rt_thread)(int), int data, int stack_size,
• int priority, int uso_fpu, void(signal)(void))
  
• Attenzione definisce il task, non lesegue!
• Il task si trova nello stato SUSPENDED
• Argomenti della funzione
• Primo argomento descrittore del task
• Secondo argomento entry point della funzione
• Terzo argomento un intero passato dal genitore
  al thread
• Quarto argomento dimensione dello stack
• Quinto argomento priorità (RT_LOWEST_PRIORITY
  0)
• Sesto argomento flag per luso della fpu
• Settimo argomento funzione per gestire il
  segnale inviato quando il thread diventa corrente

27
Programmazione in RTAI

• Attivazione di un task (messa in esecuzione) due
  modalità
• Mediante la definizione di task periodico
• int rt_task_make_periodic(RT_TASK task, RTIME
  start_time, RTIME period)
• Mediante la messa in stato di pronto
• int rt_task_resume(RT_TASK task)
• Listante di esecuzione è dato con
• start_time (valore assoluto misurato in clock
  ticks)
• start_delay (valore relativo al tempo corrente e
  misurato in
• nanosecondi)

28
Programmazione in RTAI

• Gestione della schedulazione
• Nel caso di task periodico
• int rt_task_wait_period(void)
• sospende lesecuzione del thread corrente fino
  al prossimo periodo
• Nel caso di task aperiodico
• int rt_task_yield(void)
• int rt_task_suspend(RT_TASK task)
• task_yield ferma il task corrente e lo mette
  alla fine della coda lo schedulatore attiva il
  primo thread alla stessa priorità
• task_suspend sospende lesecuzione, che verrà
  ripresa con resume o con make_periodic

29
Programmazione in RTAI

• Funzioni di utilità per la schedulazione
• void rt_sleep(RTIME delay)
• void rt_sleep_until(RTIME time)
• sospendono il thread in esecuzione e lo mettono
  in stato DELAYED
• void rt_busy_sleep(int nanosecs)
• addormenta in thread mandando in loop la CPU per
  il tempo indicato
• void rt_sched_lock(void)
• void rt_sched_unlock(void)
• blocca/sblocca lo schedulatore pe evitare corse
  critiche
• int rt_get_prio(RT_TASK task)
• int rt_change_prio(RT_TASK task, int priority
• determina/setta la priorità di base
• int rt_get_inher_prio(RT_TASK task)
• Determina la priorità ereditata a causa
  dellaccesso a risorse condivise (protocolli
  priority inheritance)

30
Programmazione in RTAI

• Altre funzioni di utilità per la schedulazione
• int rt_get_task_state(RT_TASK task)
• RT_TASK rt_whoami(void)
• int rt_task_use_fpu(RT_TASK task, int
  use_fpu_flag)
• int rt_task_delete(RT_TASK task)
• rimuove is task dal sistema

31
Programmazione in RTAI

• Esempio della funzione di rilascio risorse
• int cleanup_module(void)
• //ferma il timer
• stop_rt_timer()
• rt_busy_sleep(10000000)
• //chiude la fifo
• rtf_destroy(0)
• //cancella la struttura rt
• rt_task_delete(hiprio_task)

32
Programmazione in RTAI

• La gestione del timer
• Modalità di funzionamento
• One-shot temporizzazioni arbitrarie
• void rt_set_oneshot_mode(void)
• I task possono essere eseguiti in istanti
  qualsiasi
• Periodic tutti i tempi del sistema diventano
  multipli del periodo di base del timer
• void rt_set_periodic_mode(void)
• Ogni richiesta non multiplo del periodo viene
  soddisfatta nel periodo più vicino. È il default.
• Attivazione/fermo del timer
• RTIME start_rt_timer(int period)//se modalità
  aperiodica il periodo viene ignorato
• void stop_rt_timer(void)

33
Programmazione in RTAI

• La gestione del timer
• Modalità di funzionamento
• One-shot temporizzazioni arbitrarie
• void rt_set_oneshot_mode(void)
• I task possono essere eseguiti in istanti
  qualsiasi
• Periodic tutti i tempi del sistema diventano
  multipli del periodo di base del timer
• void rt_set_periodic_mode(void)
• Ogni richiesta non multiplo del periodo viene
  soddisfatta nel periodo più vicino. È il default.
• Attivazione/fermo del timer
• RTIME start_rt_timer(int period)//se modalità
  aperiodica il periodo viene ignorato
• void stop_rt_timer(void)

34
Programmazione in RTAI IPC

• RTAI usa sistemi di IPC simili a Linux ma
  implementati separatamente
• rt_fifo scambio dati tra i thread in tempo
  reale, tra processi Linux,
• shared memory, tra thread in tempo reale e
  processi Linux
• mailbox
• semafori
• RPC

35
Programmazione in RTAI IPC

• rt_fifo
• Per creare una rt_fifo
• int rtf_create(unsigned int fifo, int size)
• Per dimensionare una rt_fifo
• int rtf_resize(int fd, int size)
• Per aprire una rt_fifo dallo spazio utente si usa
  open()
• Per aprire una rt_fifo dallo spazio kernel si
  usa
• int rtf_open_sized(const char dev, int perm, int
  size)
• Le rt_fifo possono essere associate a dei command
  handler che vanno
• in esecuzione ogni volta che un processo nello
  spazio utente esegue
• una read() o una write() sulla fifo
• int rtf_create_handler(unsigned int minor, int
  (handler)(unsigned int fifo)))

36
Programmazione in RTAI IPC

• rt_fifo esempio duso dei command handler
• int rtf_create_handler(fifo_numver,
  X_FIFO_HANDLER(x_handler)
• con, ad esempio, come x_handler
• int x_handler(unsigned int fifo, int rw)
• if(rwr)
• //quello che bisogna fare in relazione ad una
  read
• else
• //quello che bisogna fare in relazione ad una
  write

37
Programmazione in RTAI IPC

• rt_fifo per evitare bloccaggi indeterminati
• int rtf_read_all_at_once(int fd, void buf, int
  count)
• int rtf_read_timed(int fd, void buf, int count,
  int ms_delay)
• int rtf_write_timed(int fd, void buf, int count,
  int ms_delay)
• rt_fifo uso dei semafori
• int rtf_sem_init(unsigned int fifo, int value)
• int rtf_sem_wait(unsigned int fifo) //solo dallo
  spazio utente
• int rtf_sem_trywait(unsigned int fifo) //solo
  dallo spazio utente
• ...

38
Programmazione in RTAI IPC

• IPC memoria condivisa (shared memory)
• Per trasferire dati tra processi e task
• Naturalmente sono molto veloci
• Svantaggi
• non essendo serializzati necessitano di un
  protocollo di accesso
• il bloccaggio tra processi e task non è
  supportato ? bisogna gestire il trasferimento con
  un metodo
• non è garantita la mutua esclusione processi/task
• Non è possibile rilevare letture/scritture
  interrotte
• Tipi di shared memory
• Mbuff condivisione procesi/thread (cioè spazio
  utente/spazio kernel) senza richiedere RTAI
• Shmem condivisione procesi/thread (cioè spazio
  utente/spaziokernel) che dipende profondamente da
  RTAI

39
Programmazione in RTAI IPC

• mbuff
• Implementata come device driver device
  /dev/mbuff
• Per accedere alla memoria condivisa dallo spazio
  utente/kernel
• void mbuff_alloc(unsigned long name, unsigned
  int size)
• Per rilasciare la memoria
• void mbuf_free(int name, void mbuf)

40
Programmazione in RTAI IPC

• shmem
• Implementata come device driver device
  /dev/rtai_shm
• Per accedere dallo spazio utente
• void rtai_malloc(unsigned long name, int size)
• Per rilasciarla
• void rtai_free(int name, void adr)
• Per accedere dallo spazio kernel
• void rtai_malloc(unsigned long name, int size)
• Per rilasciarla
• void rtai_free(int name, void adr)