Virtualizzazione
delle Periferiche
Corso di Sistemi Operativi
Introduzione
Una delle funzioni principali di un SO è di
controllare tutte le periferiche connesse al PC
SO deve:
comandare
i dispositivi
ascoltare gli interrupt
gestire gli errori
Deve fornire un’interfaccia tra i dispositivi ed il
resto del sistema che sia semplice e facile da
usare.
Le interfacce dovrebbero essere le stesse per
tutti i dispositivi (device-independent).
Principi di I/O hardware
Per un elettronico una periferica è un insieme di
chip, di cavi, di condensatori, ecc..
Un informatico guarda all’interfaccia che la
perifericha gli mette a disposizione (comandi
che l’hardware accetta, funzioni che supporta,
errori che potrebbe restituire).
I dispositivi possono essere divisi in due grosse
categorie:
a
blocchi
a carattere
Virtualizzazione delle Periferiche
Classificazione non perfetta. Comunque questa
divisione è abbastanza generale per poter iniziare il
discorso sulla “virtualizzazione delle periferiche”.
Ad esempio il File System lavora con le periferiche e non
deve avere differenti modalità di accesso alle periferiche
se a blocchi o a carattere. File System lavora con
dispositivi a blocchi astratti, lasciando la vera e propria
implementazione ai device driver.
Gestione delle Periferiche
Le unità I/O sono generalmente composte da
componenti meccanici e da componenti
elettronici.
E’ possibile separare i due aspetti per
aumentare la generalizzazione:
Il
componente elettronico: device controller
(adapter) è di solito una scheda che viene inserita nel
PC che permette al PC stesso di interfacciarsi con il
dispositivo.
Il componente meccanico è il dispositivo stesso.
Gestione delle Periferiche (2)
CPU
SW
HWport
Mechanical
Perif
Abbiamo fatto la distinzione tra controller e dispositivo
perché il SO non tratta mai direttamente con il
dispositivo ma sempre con il controller.
A volte questa interfaccia è direttamente sul dispositivo e
questo si collega al system bus del PC.
Principi di I/O software
L’idea del SO di gestire l’I/O è attraverso la
strutturazione in livelli.
I livelli più bassi servono per mascherare le specifiche
hw dei dispositivi mentre quelli superiori servono per
fornire un interfaccia comune, regolare, carina agli utenti.
Cercare DEVICE INDEPENDENCE
Iniziamo affrontando un concetto chiave: indipendenza
del dispositivo. Dovrebbe essere possibile scrivere
programmi che lavorino indiferrentemente con un hard
disk o con un floppy senza modificare il codice.
Dovrebbe essere possibile scrivere: sort <input> output
sapendo che input potrebbe essere floppy o HD e che l’output
può essere floppy, HD, terminale o modem…
Principi di I/O software: Uniform Naming
Innanzitutto per ottenere l’indipendenza del dispositivo
devo avere uniform naming. Il nome di un dispositivo o
di un file deve essere una stringa e non dipendere dal
nome del dispositivo.
In UNIX file e dispositivi sono gestiti nello stesso modo: i
floppy e gli altri dispotivi sono montati ed il SO maschera
il fatto che sono “estranei” /usr/mnt/fd0
In Windows questo non avviene e devo specificare dove
si trovano (a:/ )
Principi di I/O software: Error Handling
Un’altra funzione importante del SO è l’error handling.
Error handling deve essere gestito il più vicino all’hw
possibile. Se il controller scopre errore, richiede di nuovo
il dato.
Solo se il problema non può essere risolto dai livelli più
bassi, i livelli più alti ne vengono informati (ad es.
qualcuno ha tolto il dischetto).
E’ anche fondamentale gestire in modo trasparente
le periferiche sincrone (blocking) e quelle asincrone
(interrupt).
Virtualizzazione delle Periferiche
Ultimo ma non secondario aspetto: SO deve gestire la
virtualizzazione delle periferiche (permettere a + utenti di
usare una sola stampante).
Alcune periferiche possono essere virualizzate (dischi,
stampante, rete) altre no (schermo, tastiera) ecc…
Per quanto riguarda le periferiche virtualizzate, SO si
occupa di gestire i possibili conflitti tra utenti (più utenti
vogliono scrivire sulla stampante o accedere ad un file).
Livelli di S.O.
User level software
Device independent OS software
Device driver
Interrupt Handler
Interrupt Handler
Gli interrupt sono nascosti nel cuore del sistema
operativo. Essi servono per segnalare via HW al SO il
verificarsi di determinati eventi (es un blocco di dati è
pronto).
Il processo che richiede dei dati si sospende in attesa di
questo interrupt.
Device Driver
Tutto il codice che dipende dal dispositivo va in questo
livello. Ogni device driver gestisce una o più classi di
dispositivi.
I controller hanno dei registri che sono usati per trasferire
dati/comandi. Il disk driver è quella parte del SO che
conosce quanti e quali registri ci sono nel controller.
Il disk driver conosce i comandi da usare per il dispositivo
e controlla che siano eseguiti correttamente. Lui solo
conosce quanti settori, cilindri, testine, ecc. ci sono nel
disco.
Device Driver (2)
Il compito di un driver è di accettare richieste
astratte provenienti dal device-independent software
e di controllare che queste siano eseguire.
Una richiesta tipica è ad es: “leggi il blocco n”. Il driver si
attiva per leggere da disco, se è occupato a fare un’altra
richiesta, quest’ultima viene messa in coda.
Se è pronta prende la richiesta e da astratta viene
tradotta in richiesta concreta determinando quale testina
usare e quando. Esso deve determinare le corrette
operazioni da eseguire.
Device Driver (3)
Quando i comandi sono stati scelti, vengono copiati nei
registri del dispositivo.
Quello che succede è che poi:
Il driver attende che l’operaziona restituisca il risultato.
Operazioni lunghe. Interrupt (si blocca in attesa: scrivo il disco).
Il driver si attiva per eseguire un’altra operazione.
Operazioni brevi. (scrivo a video)
Dopo aver terminato l’operazione controlla che non ci siano stati
errori e rende il risultato al device independet layer.
DEVICE-INDEPENDENT I/O
SOFTWARE
Le funzioni base fornite da questo livello permettono al
SO di eseguire le operazioni I/O che sono comuni a tutti i
dispositivi e di fornire un’interfaccia comune all’user-level
software
Naming e Protezione
Device-independent block-size
Buffering
Allocare e rilasciare i dispositivi
Error handling
Naming e Protezione
Questo livello si occupa del gestire il mapping
tra i nomi simbolici dei driver (LPT1, A:, es.. ) ed
i driver a cui si riferiscono.
Protection: previnire accessi indesiderati ai
dispositivi (errori, intrusioni). In MS-DOS si
poteva fare tutto, non c’era protezione. In UNIX
ci sono i rwe bits, gestibili dal proprietario e
dall’amministratore.
Device-Independent block-size
I dischi possono avere differenti sector size.
Questo livello deve mascherare questa
differenza, trattando i blocchi in blocchi logici di
dimensioni fissate e poi occupandosi di gestire
le diffenti dimensioni dei dispositivi (sia per
blocchi che per stream di caratteri)
Buffering
Si occupa di
Gestire
letture successive di grandi blocchi.
Fornire dati tutti insieme.
Per stream di caratteri, utente scrive troppo
veloce sulla tastiera e non riesce a gestire
l’input.
Allocare e rilasciare dispositivi
I dispositivi possono essere usati da uno o più
utenti.
Questo scambio di “proprietario” è gestito dal
SO (anche per quanto riguarda i processi)
Error handling
Abbiamo visto l’error handling gestito dal device
depende level. Quando il livello più basso non
riesce a gestire l’errore (disco rotto) questo
livello ne viene informato.
L’ errore viene quindi gestito in modo
indipendente dal dispositivo (informando il
processo che aveva fatto la richiesta oppure
visualizza un messaggio di errore).
User-Space I/O Software
SO mettono a disposizione dei programmatori
delle librerie di funzioni che permettono, tra
l’altro, di usare i dispositivi connessi al PC.
Una chiamata classica è (linguaggio C):
count=write(fd, buffer,nbytes);
La funzione write appropriata verrà chiamata a
sceconda di cosa è fd (video, printer, disco,
modem..)
In questo modo ho anche superato la deviceindependence.
I/O request
Make I/O call, format I/O,
spooling
User processes
Device-Indep-Software
Naming, protection,
blocking, buffering,
allocation
Device-Drivers
Setup device register, check
status
Interrupr Handlers
Wakeup driver when I(O
completed
Perform I/O operations
Hardware
I/O reply
