Sistemi Operativi - User contributions [en]

Lezioni Anno Accademico 2017/18 II semestre

2018-03-08T15:16:00Z

Francesco97: /* Lezione del 7 marzo 2018 */

== 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 secondo 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?

<table>
<tr>
<th>Processo (PCB)</th><th>Thread (TCB)</th>
</tr>
<tr>
<th>ID (self, parent,child etc)</th><th>ID</th>
</tr>
<tr>
<th>Info sulla memoria (puntatore alla tabella dei segmenti)</th><th>Stato del processore</th>
</tr>
<tr>
<th>File aperti</th><th>Stato: Ready, Running,Block</th>
</tr>
<tr>
<th>Ownership</th><th>Puntatori</th>
</tr>
<tr>
<th>Interprocess comunication</th><th></th>
</tr>
<tr>
<th>Informazioni sull'accounting </th><th></th>
</tr>
</table>

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ò a non confondere la kernel mode con i permessi di root (root è l'utente con più permessi in assoluto ma è comunque gestito in user mode).
Si definisce Context Switch il passaggio di processi. Ad esempio un processo A in user mode 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 non preemptive (ossia è il processo in esecuzione a decidere quando fermarsi e far proseguire l'esecuzione degli altri processi) per sistemi batch.
I thread posso essere creati sia in modo kernel che in modo user.

== Lezione del 8 marzo 2018 ==
== Lezione del 9 marzo 2018 ==
== Lezione del 14 marzo 2018 ==
== Lezione del 15 marzo 2018 ==
== Lezione del 16 marzo 2018 ==
== Lezione del 21 marzo 2018 ==
== Lezione del 22 marzo 2018 ==
== Lezione del 23 marzo 2018 ==
== Lezione del 28 marzo 2018 ==
== Lezione del 29 marzo 2018 ==
== Lezione del 30 marzo 2018 ==

Lezioni Anno Accademico 2017/18 II semestre

2018-03-08T11:14:14Z

Francesco97: /* Lezione del 7 marzo 2018 */

== 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 (e in principio fu il boot), nello specifico è 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, tutta via il kernel diventerbbe davvero corposo (a meno che non si crei un kernel ad hoc per una specifica macchina). Un'altra soluzione (praticamente quella comunemente utilizzata) utilizza i moduli. I moduli vengono caricati dal kernel all'occorrenza senza essere inseriti direttamente in esso (senza ogni volta doverlo ricompilare).
Tuttavia con quest'ultima soluzione si viene a creare un dilemma, ovvero:
Chi carica i moduli? [il kernel]
Chi carica il kernel? [boot tramite moduli]
In verità non esiste solo il kernel ma anche un filesystem che contiene i moduli chiamato init.rd (diventa 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 (es: i sorgenti del kernel linux sono reperibili in www.kernel.org). Una volta scaricato ed entrato nella relativa cartella 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 effettivamente il kernel con la possibilità di compilarlo per la macchina ospite o per una specifica architettura. es:

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:
-processo=entità titolare delle risorse;
-thread=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.

<table>
<tr> <th>Processo (PCB) </th> <th> Thread (TCB)</th></tr>
<tr><th>
ID (self, parent,child etc) </th><th>ID</th></tr>
<tr><th>
Info sulla memoria (puntatore alla tabella dei segmenti)</th><th>Stato del processore</th></tr>
<tr><th>
File aperti</th><th> Stato: Ready, Running,Block</th></tr>
<tr><th>
Ownership</th><th> Puntatori</th></tr>
<tr><th>
Interprocess comunication </th><th></th></tr>
<tr><th>
Informazioni sull'accounting </th><th></th></tr></table>

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.

== Lezione del 8 marzo 2018 ==
== Lezione del 9 marzo 2018 ==
== Lezione del 14 marzo 2018 ==
== Lezione del 15 marzo 2018 ==
== Lezione del 16 marzo 2018 ==
== Lezione del 21 marzo 2018 ==
== Lezione del 22 marzo 2018 ==
== Lezione del 23 marzo 2018 ==
== Lezione del 28 marzo 2018 ==
== Lezione del 29 marzo 2018 ==
== Lezione del 30 marzo 2018 ==

Lezioni Anno Accademico 2017/18 II semestre

2018-03-08T11:12:45Z

Francesco97: /* Lezione del 7 marzo 2018 */

== 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 (e in principio fu il boot), nello specifico è 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, tutta via il kernel diventerbbe davvero corposo (a meno che non si crei un kernel ad hoc per una specifica macchina). Un'altra soluzione (praticamente quella comunemente utilizzata) utilizza i moduli. I moduli vengono caricati dal kernel all'occorrenza senza essere inseriti direttamente in esso (senza ogni volta doverlo ricompilare).
Tuttavia con quest'ultima soluzione si viene a creare un dilemma, ovvero:
Chi carica i moduli? [il kernel]
Chi carica il kernel? [boot tramite moduli]
In verità non esiste solo il kernel ma anche un filesystem che contiene i moduli chiamato init.rd (diventa 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 (es: i sorgenti del kernel linux sono reperibili in www.kernel.org). Una volta scaricato ed entrato nella relativa cartella 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 effettivamente il kernel con la possibilità di compilarlo per la macchina ospite o per una specifica architettura. es:

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:
-processo=entità titolare delle risorse;
-thread=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.

<table>
<tr> <th>Processo (PCB) </th> <th> Thread (TCB)</th></tr>
<tr><th>
ID (self, parent,child etc) </th><th>ID</th></tr>
<tr><th>
Info sulla memoria (puntatore alla tabella dei segmenti)</th><th>Stato del processore</th></tr>
<tr><th>
File aperti</th><th> Stato: Ready, Running,Block</th></tr>
<tr><th>
Ownership</th><th> Puntatori</th></tr>
<tr><th>
Interprocess comunication </th><th></th></tr>
<tr><th>
Informazioni sull'accounting </th><th></th></tr></table>

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.

== Lezione del 8 marzo 2018 ==
== Lezione del 9 marzo 2018 ==
== Lezione del 14 marzo 2018 ==
== Lezione del 15 marzo 2018 ==
== Lezione del 16 marzo 2018 ==
== Lezione del 21 marzo 2018 ==
== Lezione del 22 marzo 2018 ==
== Lezione del 23 marzo 2018 ==
== Lezione del 28 marzo 2018 ==
== Lezione del 29 marzo 2018 ==
== Lezione del 30 marzo 2018 ==

Lezioni Anno Accademico 2017/18 II semestre

2018-03-08T11:10:36Z

Francesco97: /* Lezione del 7 marzo 2018 */

== 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 (e in principio fu il boot), nello specifico è 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, tutta via il kernel diventerbbe davvero corposo (a meno che non si crei un kernel ad hoc per una specifica macchina). Un'altra soluzione (praticamente quella comunemente utilizzata) utilizza i moduli. I moduli vengono caricati dal kernel all'occorrenza senza essere inseriti direttamente in esso (senza ogni volta doverlo ricompilare).
Tuttavia con quest'ultima soluzione si viene a creare un dilemma, ovvero:
Chi carica i moduli? [il kernel]
Chi carica il kernel? [boot tramite moduli]
In verità non esiste solo il kernel ma anche un filesystem che contiene i moduli chiamato init.rd (diventa 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 (es: i sorgenti del kernel linux sono reperibili in www.kernel.org). Una volta scaricato ed entrato nella relativa cartella 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 effettivamente il kernel con la possibilità di compilarlo per la macchina ospite o per una specifica architettura. es:

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:
-processo=entità titolare delle risorse;
-thread=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.

<table>
<tr> <th>Processo (PCB) </th> <th> Thread (TCB)</th></tr>
<tr><th>
ID (self, parent,child etc) </th><th>ID</th></tr>
<tr><th>
Info sulla memoria (puntatore alla tabella dei segmenti)</th><th>Stato del processore</th></tr>
<tr><th>
File aperti</th><th> Stato: Ready, Running,Block</th></tr>
<tr><th>
Ownership</th><th> Puntatori</th></tr>
<tr><th>
Interprocess comunication </th><th></th></tr>
<tr><th>
Informazioni sull'accounting </th><th></th></tr>

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.

== Lezione del 8 marzo 2018 ==
== Lezione del 9 marzo 2018 ==
== Lezione del 14 marzo 2018 ==
== Lezione del 15 marzo 2018 ==
== Lezione del 16 marzo 2018 ==
== Lezione del 21 marzo 2018 ==
== Lezione del 22 marzo 2018 ==
== Lezione del 23 marzo 2018 ==
== Lezione del 28 marzo 2018 ==
== Lezione del 29 marzo 2018 ==
== Lezione del 30 marzo 2018 ==

Lezioni Anno Accademico 2017/18 II semestre

2018-03-08T10:00:26Z

Francesco97: /* Lezione del 7 marzo 2018 */

== 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 (e in principio fu il boot), nello specifico è 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, tutta via il kernel diventerbbe davvero corposo (a meno che non si crei un kernel ad hoc per una specifica macchina). Un'altra soluzione (praticamente quella comunemente utilizzata) utilizza i moduli. I moduli vengono caricati dal kernel all'occorrenza senza essere inseriti direttamente in esso (senza ogni volta doverlo ricompilare).
Tuttavia con quest'ultima soluzione si viene a creare un dilemma, ovvero:
Chi carica i moduli? [il kernel]
Chi carica il kernel? [boot tramite moduli]
In verità non esiste solo il kernel ma anche un filesystem che contiene i moduli chiamato init.rd (diventa inutile se il kernel e configurato per una specifica macchina).
Arrivati a questo punto ci si chiede come si compila un kernel? Prima di tutto occorrono i sorgenti (es: i sorgenti del kernel linux sono reperibili in www.kernel.org). Una volta scaricato ed entrato nella relativa cartella 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 effettivamente il kernel con la possibilità di compilarlo per la macchina ospite o per una specifica architettura. es:

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:
-processo=entità titolare delle risorse;
-thread=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 | Thread 
__________________________________________________________________________________ 
ID (self, parent,child etc) | ID 
Info sulla memoria (puntatore alla tabella | Stato del processore 
dei segmenti) | 
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.

== Lezione del 8 marzo 2018 ==
== Lezione del 9 marzo 2018 ==
== Lezione del 14 marzo 2018 ==
== Lezione del 15 marzo 2018 ==
== Lezione del 16 marzo 2018 ==
== Lezione del 21 marzo 2018 ==
== Lezione del 22 marzo 2018 ==
== Lezione del 23 marzo 2018 ==
== Lezione del 28 marzo 2018 ==
== Lezione del 29 marzo 2018 ==
== Lezione del 30 marzo 2018 ==

Lezioni Anno Accademico 2017/18 II semestre

2018-03-08T09:25:31Z

Francesco97: /* Lezione del 7 marzo 2018 */

== 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 (e in principio fu il boot), nello specifico è 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, tutta via il kernel diventerbbe davvero corposo (a meno che non si crei un kernel ad hoc per una specifica macchina). Un'altra soluzione (praticamente quella comunemente utilizzata) utilizza i moduli. I moduli vengono caricati dal kernel all'occorrenza senza essere inseriti direttamente in esso (senza ogni volta doverlo ricompilare).
Tuttavia con quest'ultima soluzione si viene a creare un dilemma, ovvero:
Chi carica i moduli? [il kernel]
Chi carica il kernel? [boot tramite moduli]
In verità non esiste solo il kernel ma anche un filesystem che contiene i moduli chiamato init.rd (diventa inutile se il kernel e configurato per una specifica macchina).
Arrivati a questo punto ci si chiede come si compila un kernel? Prima di tutto occorrono i sorgenti (es: i sorgenti del kernel linux sono reperibili in www.kernel.org). Una volta scaricato ed entrato nella relativa cartella 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 effettivamente il kernel con la possibilità di compilarlo per la macchina ospite o per una specifica architettura. es:

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:
-processo=entità titolare delle risorse;
-thread=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 | Thread 
__________________________________________________________________________________ 
ID (self, parent,child etc) | ID 
Info sulla memoria (puntatore alla tabella | Stato del processore 
dei segmenti) |
File aperti | Stato: Ready, Running,Block 
Ownership | Puntatori 
Interprocess comunication | 
Informazioni sull'accounting | 

== Lezione del 8 marzo 2018 ==
== Lezione del 9 marzo 2018 ==
== Lezione del 14 marzo 2018 ==
== Lezione del 15 marzo 2018 ==
== Lezione del 16 marzo 2018 ==
== Lezione del 21 marzo 2018 ==
== Lezione del 22 marzo 2018 ==
== Lezione del 23 marzo 2018 ==
== Lezione del 28 marzo 2018 ==
== Lezione del 29 marzo 2018 ==
== Lezione del 30 marzo 2018 ==

Sezioni Critiche in C

2017-10-12T21:54:24Z

Francesco97: /* Dekker */

Tutti questi esempi hanno NPROC thread che svolgono un loop MAX volte sommando 1 ad ogni iterazione ad una variabile globale condivisa val.

Se tutto va bene il risultato finale deve essere NPROC*MAX.

== Dekker ==

<syntaxhighlight lang=C>
#include<stdio.h>
#include<stdint.h>
#include<stdlib.h>
#include<sched.h>
#include<pthread.h>
#include<unistd.h>

#define MAX 400
#define STEP 10
#define NPROC 2

volatile long val = 0;
int need[NPROC];
int turn;

void *codet(void *arg) {
uintptr_t id = (uintptr_t) arg;
int count;
long tmp;
for (count=0; count < MAX; count++) {
/* enter */
need[id] = 1;
while (need[1 - id]) {
if (turn != id) {
need[id] = 0;
while (turn != id)
sched_yield();
need[id] = 1;
}
}
/* /enter */
tmp = val;
//usleep(rand() % 2);
val = tmp + 1;
if (count % STEP == 0)
printf("%d %ld\n",id,val);
/* exit */
turn = 1 - id;
need[id] = 0;
/* /exit */
}
}

int main(int argc, char *argv[]) {
uintptr_t i;
pthread_t t[NPROC];
srand(time(NULL));
for (i=0; i<NPROC; i++)
pthread_create(&t[i], NULL, codet, (void *) i);
for (i=0; i<NPROC; i++)
pthread_join(t[i], NULL);
printf("%ld %d\n",val,NPROC*MAX);
}
</syntaxhighlight>