Lezioni Anno Accademico 2017/18 II semestre
Lezione del 28 febbraio 2018
Inizia oggi la seconda parte del corso di Sistemi Operativi che si terrà dal 28/02/18 al 25/05/18.
Le lezioni si svolgeranno, il mercoledì e il giovedì, in aula E1. Il venerdì invece ci sposteremo in M1.
La suddivisione degli argomenti trattati sarà: mercoledì teoria, giovedì tendenzialmente parte progettuale (potrebbe iniziare con un po' di teoria) e venerdì, data la scarsa dotazione dell'aula assegnataci, verranno svolti esercizi scritti in preparazione all'esame.
Nel corso della lezione ci siamo chiesti, riprendendo un po' il filo logico delle lezioni dello scorso semestre, quali siano i servizi che ci aspettiamo da un sistema operativo.
Questa volta, tuttavia, non li analizzeremo dal punto di vista dell'utilizzatore, ma da un punto di vista interno al sistema stesso.
I servizi elencati sono stati:
- Scheduling (Gestione CPU)
- Gestione dei processi
- Gestione della memoria primaria
- Gestione dei device di I/O
- Gestione della memoria secondaria
- Filesystem
- Networking
- Protezione
- Shell
Come in tutta l'informatica spesso succede, la complessità di questi servizi viene gestita tramite la creazione di livelli di astrazione.
Il livello zero di astrazione, quello più basso, sarà l'hardware che noi dovremo considerare come un linguaggio (l'ISA del processore).
Seguito poi da due blocchi:
- Kernel
- Utente
Cosa va incluso nel kernel di un S.O.? Cosa nella parte utente? Meglio massimizzare o minimizzare le operazioni nello livello kernel?
KERNEL MONOLITICO O MICRO-KERNEL?
I kernel monolitici (tipo Linux) hanno il vantaggio di essere leggermente più performanti, mentre i microkernel (che presentano più livelli di astrazione) sono molto più flessibili e facili da manutenere. Ad esempio, nei microkernel un bug non obbliga necessariamente a riavviare la macchina perché è possibile riavviare il singolo "modulo" che presenta l'errore.
Lezione del 1 marzo 2018
La lezione tace come concordato con gli studenti.
Lezione del 2 marzo 2018
La lezione tace causa chiusura dell'intero Ateneo per condizioni climatiche avverse.
Lezione del 7 marzo 2018
Tutto incomincia dal boot, ossia, è nella fase di boot che si carica il kernel. Una volta caricato, il kernel ha davanti una gradissima diversità di modelli hardware, ma come utilizzare tutti questi dispositivi hardware? Una prima soluzione sarebbe quella di includere nel kernel tutti i relativi device driver, tuttavia il kernel diventerbbe davvero corposo, a meno che non si crei un kernel ad hoc per una specifica macchina. Un'altra soluzione (quella comunemente adottata) utilizza i moduli. I moduli vengono caricati dal kernel all'occorrenza senza essere inseriti direttamente in esso (non è quindi necessaria la ricompilazione).
Tuttavia con quest'ultima soluzione si viene a creare un dilemma, ovvero:
Chi carica i moduli? Il kernel.
Chi carica il kernel? Il boot tramite moduli.
In verità non esiste solo il kernel ma anche un filesystem che contiene i moduli chiamato "init.rd" (inutile se il kernel è configurato per una specifica macchina). Arrivati a questo punto ci si chiede: come si compila un kernel? Prima di tutto occorrono i sorgenti (quelli di linux sono reperibili su https://www.kernel.org). Una volta scaricati, si deve configurare il file “.config” che sostanzialmente descrive le specifiche del kernel. Questo file lo si può configurare a mano o tramite il “menuconfig” che dovrà essere prima di tutto opportunatamente compilato. All'interno del menuconfig tra le altre cose c'è una lista di tutti i device driver supportati e possono essere spuntati con: * (driver inserito nel kernel) o M (creazione del relativo modulo). Una volta configurato il “.config” non resta che compilare il kernel per la macchina ospite o per una specifica architettura. Ad esempio:
wget link_of_kernel_source #scarica i sorgenti tar xf source_compressed_file # decomprime i relativi sorgenti, in questo caso dal file.tar.xz cd linux #entra nella directory dei sorgenti
- Di regola esiste già un .config standard ma per configurarlo
make menuconfig make #compila il kernel per la macchina ospite
- make -arch=armhf, compila seconda l'architettura dei processori armhf
- make -j n , compila il kernel per la macchina ospite utilizzando i suoi n-1 core.
Una volta compilato l'immagine del kernel si troverà in arch/nome_architettura/boot/bzImage.
Ora si ricordi la differenza tra processo e thread: Il processo è l'entità titolare delle risorse, mentre il thread è la componente sequenziale dell'elaborazione. Nei sistemi monothread il concetto di thread si sovrappone al concetto di processo ma in linea generale un processo può avere anche più di un thread. Ma quali sono le caratteristiche principali dei processi e dei thread?
| Processo (PCB) | Thread (TCB) |
|---|---|
| ID (self, parent,child etc) | ID |
| Info sulla memoria (puntatore alla tabella dei segmenti) | Stato del processore |
| File aperti | Stato: Ready, Running,Block |
| Ownership | Puntatori |
| Interprocess comunication | |
| Informazioni sull'accounting |
Modo Kernel e modo user Si definisce Mode switch il passaggio da Kernel mode a user mode e viceversa (esiste tale differenza per motivi di sicurrenzza). Attenzione però da non confondere la kernel mod con i permessi di root (root è solo un utente con più permessi in assoluto ma è gestito tramite user mode). Si definisce Context switch il passaggio di processi. Esempio: un processo A in usermode si ferma e passa il controllo al trap che tramite lo scheduler chiama un altro processo. Da qui si capische che è lo scheduler a decidere il prossimo processo da mandare avanti (tramite la Ready Queue). Un tipico scheduler è lo scheduler FIFO per sistemi batch con processi no preamptive (il processo si può chiudere per sua volontà). I thread posso essere creati sia in modo kernel e sia in modo user.