|
|
@@ -0,0 +1,111 @@
|
|
|
+# Piattaforme e Software per la rete
|
|
|
+#### William Fornaciari
|
|
|
+###### 9 March 2016
|
|
|
+## Modulo 2
|
|
|
+__Networking__ -> __embedded systems__ -> __Network embedded systems__
|
|
|
+
|
|
|
+## Testi adottati
|
|
|
+Deitel, Choffines - Operating Systems, per ripassare
|
|
|
+
|
|
|
+Mitchell Oldhamm, ... Advanced Linux Programming, scaricabile gratis.
|
|
|
+
|
|
|
+## RIpasso - Architettura di un sistema linux
|
|
|
+Modalità
|
|
|
+- Modo kernel
|
|
|
+- Modo utente
|
|
|
+ - Programmi utente
|
|
|
+ - Shell
|
|
|
+
|
|
|
+Hardware recente è in grado di supportare il parallelismo,
|
|
|
+mentre storicamente i sistemi operativi sono pensati per la
|
|
|
+condivisione delle risorse di un solo processore.
|
|
|
+
|
|
|
+Il cambiamento storico è stato dal vax780 che ha introdotto un SoC,
|
|
|
+- Inizialmente si è adottato un singolo core sempre più potente, fino a 2,5GHz
|
|
|
+- Raggiunto il limite della frequenza di clock (power wall) si cerca di aumentare le prestazioni
|
|
|
+aumentando il numero di core.
|
|
|
+
|
|
|
+E poi c'è il *dark silicon*
|
|
|
+
|
|
|
+Anche per quello l'evoluzione sta al momento nel creare meccanismi di memoria e di caching
|
|
|
+in grado di permettere il funzionamento contemporaneo di molti core (~50)
|
|
|
+
|
|
|
+__Sistemi di gestione dinamica dele risorse__
|
|
|
+Come *barbecue* non gesticono i processi in modo agnostico ma danno priorità in base alle condizioni
|
|
|
+(es: utilizzo in batteria)
|
|
|
+La gestione viene fatta a livello userspace con uno strato intermedio,
|
|
|
+ in modo che sia indipendente dal kernel o sistema operativo.
|
|
|
+
|
|
|
+Per coordinare molti core non si usa un bus ma una Network on Chip (16 core in sù)
|
|
|
+
|
|
|
+## Funzionalità del kernel
|
|
|
+- Mantenere in memoria il s.o. e i programmi in spazi di indirizzamento separati
|
|
|
+- Permettere il passaggio dall'esecuzione di un programma all'altro,
|
|
|
+ma nei sistemi a molti core la cosa è diversa (distribuzione dei thread in un pool di risorse)
|
|
|
+- Gestire le operazioni di I/O
|
|
|
+A volte nelle applicazioni embedded si scrive del codice bare-metal senza sistema operativo
|
|
|
+In quel caso l'I/O è gestito dal proprio software
|
|
|
+- Verifica dei dati di esecuzione, ad esempio in sysfs
|
|
|
+
|
|
|
+#### BoardSupportP?
|
|
|
+è lo strato che permette di mappare le funzioni del sistema operativo su un particolare tipo di hardware.
|
|
|
+
|
|
|
+### Esecuzione di un processo
|
|
|
+Il kernel sceglie il processo da mandare in esecuzione
|
|
|
+Quando un processo richiede un servizio di sistema tramite una SVC
|
|
|
+Viene fornita la funzione richiesta nel contesto del processo.
|
|
|
+
|
|
|
+### Sospensione dei processo
|
|
|
+Il processo può lasciare l'esecuzione
|
|
|
+- Per *sospensione volontaria* con cui passa allo stato di attesa
|
|
|
+(Ad esempio per aspettare un evento di I/O)
|
|
|
+- Per *fine del quanto di tempo*
|
|
|
+
|
|
|
+3 stati:
|
|
|
+- Processo in esecuzione: processo che usa il processore, tanti quanti i core
|
|
|
+- Processi in attesa: attende una risorsa non disponibile.
|
|
|
+- Processi pronti: attende di essere eseguito
|
|
|
+
|
|
|
+I processi in attesa sono differenziati da quelli pronti per evitare che un proceso singolo
|
|
|
+monopolizzi il processore, e faccia andare gli altri in starvation.
|
|
|
+
|
|
|
+Nei sistemi con __preemption__ si può togliere il processo in esecuzione dal processore
|
|
|
+Nei sistemi senza, il processo tiene il processore fino alla fine del quanto di tempo o fino a che
|
|
|
+si sospende volontariamente.
|
|
|
+
|
|
|
+### Gestione degli interrupt
|
|
|
+Le interruzioni possono essere nestate, e in quel caso non si sa quando finiranno di eseguirsi.
|
|
|
+Questo può creare problemi nei sistemi embedded in cui è necessario garantire un tempo di risposta rapido.
|
|
|
+
|
|
|
+Gli interrupt possono essere __mascherabili__ quando non possono essere eseguiti altri interrupt, in
|
|
|
+modo da creare una sezione atomica, non interrompibile.
|
|
|
+
|
|
|
+Ci sono interruzioni che possono essere __non mascherabili__ perchè cruciali, ad esempio spegnimento in caso di batterie scariche.
|
|
|
+
|
|
|
+### Watchdog
|
|
|
+Viene usato per capire se un processo è bloccato, ad esempio facendo un timer che va resettato periodicamente.
|
|
|
+Se il timer non viene resettato e scade, viene attivato un interrupt che accende un led ad esempio.
|
|
|
+Collegare il watchdog al reset del sistema non è una delle soluzioni migliori (es: applicazioni critiche)
|
|
|
+Il watchdog implica un hardware esterno perchè il processore in quel caso è bloccato.
|
|
|
+
|
|
|
+### Gestione del quanto di tempo
|
|
|
+Per il quanto di tempo viene usato uno dei timer programmabili hardware del PC (RTC)
|
|
|
+Facendo un quanto di tempo troppo piccolo ho un parallelismo più spinto
|
|
|
+ma aumenta l'overhead per il context switching
|
|
|
+Il problema in questo caso è il mixed-workflow in cui è importante che il sistema rimanga interattivo
|
|
|
+ed è anche importante terminare i processi lunghi.
|
|
|
+
|
|
|
+### Ritorno da interrupt
|
|
|
+Fino a 8 anni fa il kernel linux era monolitico (non interrompibile) mentre ora è preemptable (interrompibile)
|
|
|
+e in questo modo è più difficile da gestire ma è più interattivo.
|
|
|
+
|
|
|
+### Memoria Virtuale (swap)
|
|
|
+Nei sistemi embedded non esiste, perchè serve avere un sistema predicibile.
|
|
|
+Anche i questo caso i processi che subiscono swap-in (ritorno in memoria da swap) finiscono
|
|
|
+in uno stato in attesa, e non pronto, per evitare la starvation dei processi
|
|
|
+
|
|
|
+### Stati dei processi UNIX
|
|
|
+Esiste una distinzione tra Ready to run in memory e Preempted
|
|
|
+
|
|
|
+### Processo di boot
|
|
|
+Ultimamente in linux si sta tentando di caricare le cose non tutte insieme ma quelle essenziali prima in modo che il sistema risulti già usabile
|
