LA GESTIONE DELL'INGRESSO-USCITA

Questa seconda soluzione è a volte preferita a motivo della sua maggiore 'leggerezza': infatti, nel caso si decida di collegare una nuova periferica al computer, non si sarebbe costretti a modificare il SO. Sarà sufficiente fare in modo che nella fase di boot del computer venga creato il driver della nuova periferica.

Ammettiamo dunque di scegliere la seconda alternativa, e che venga iniziata un'operazione di I/O, lanciando il processo driver. Quest'ultimo allora deve attendere che venga inviato un segnale di interrupt dalla periferica che esso controlla, e si mette perciò in attesa mediante una WAIT su di un semaforo inizializzato a 0. All'arrivo della interruzione parte una ISR facente parte del kernel. A questo punto, la ISR effettua una SIGNAL che sblocca il driver.

Invece, su di una macchina nella quale il processo driver è parte integrante del kernel, esiste uno stretto legame tra le istruzioni del driver ed il kernel. Nel momento in cui arriva al driver sospeso l'interruzione, parte una ISR contenente essa stessa la coda del driver[2] che deve eseguire l'operazione I/O desiderata. I SO per i quali si adotta questa tecnica di allocazione dei driver devono essere rigenerati ogni volta che si aggiunge una nuova periferica; occorre cioè riaggiornare tutti i parametri del SO che riguardano le periferiche e caricare i nuovi driver dal generatore del SO (pizza). UNIX appartiene a questa classe di sistemi operativi.

Come sappiamo dal corso di Calcolatori Elettronici I il driver opera sui registri dato, controllo e stato dell'interfaccia associata alla periferica. La figura seguente mostra (a titolo illustrativo) uno schema di collegamenti tra i dispositivi periferici e l'unità centrale.

SISTEMA CENTRALE

memoria elaboratore

UNITÀ DI registro registro

INTERFACCIA buffer di di

controllo stato

unità di controllo

dispositivo

fisico

Contrariamente a quello che si potrebbe pensare, di solito un driver non invia i comandi ai registri dell'interfaccia, non specifica cioè le modalità operative con le quali la periferica controllata deve funzionare, in quanto ciò viene fatto una tantum al momento del BOOT del sistema. Una routine del boot si fa carico di impartire i comandi ai registri delle varie interfacce, dato che di solito non è previsto che il comportamento di tali interfacce debba cambiare durante la 'vita' del sistema. Generalmente questa routine si occupa pure di inizializzare i bit di interfaccia ('abilitato' - 'disabilitato'), i quali invece potrebbero essere successivamente modificati. A regime, il driver si occuperà di effettuare l'I/O dei dati attraverso il BUFFER della periferica, di leggere il registro di STATO e di modificare il registro di CONTROLLO dell'interfaccia. Ovviamente la struttura del driver è intimamente legata al genere di periferica sulla quale esso agisce.

Ogni driver, a prescindere dell'ambiente in cui si trova (utente o kernel), ha sempre bisogno di una procedura del kernel mediante la quale esso possa 'sospendersi' una volta che sia iniziata l'operazione di I/O. Ad esempio, il driver chiede un dato alla periferica e poi si mette in attesa fino a quando la periferica stessa non è in grado di fornirlo. Per convenzione chiameremo questa particolare procedura del kernel:

WAIT_FOR_INTERRUPT

Nel modello in cui il processo driver è direttamente accessibile agli altri processi, essa viene implementata a mezzo di una WAIT su di un semaforo privato (ogni driver possiede il proprio semaforo privato, inizializzato a zero). Per uscire poi da questa WAIT, occorre trasformare l'INTERRUPT HARDWARE che arriva dalla periferica in una INTERRUZIONE SOFTWARE che sia in grado di sbloccare il driver. All'uopo basta inserire una SIGNAL nel relativo ramo della ISR. La ISR sarà fatta cioè in modo che in ognuno dei suo rami sia contenuta la SIGNAL per risvegliare il corrispondente processo driver.

Anche nel caso del driver gestito a livello kernel la ISR avrà tanti rami quanti sono i driver, ma questa volta ogni ramo contiene direttamente la coda del corrispondente driver; il processo testa del driver non viene mai sbloccato [3]; la ISR comincia le operazioni di I/O e poi si autosospende, per riprendere successivamente quando arriva il segnale di interruzione dalla periferica.

Nel seguito faremo riferimento invece al modello del processo driver. Per poter scrivere un driver, abbiamo bisogno che il SO metta a disposizione, oltre alla succitata procedura WAIT_FOR_INTERRUPT, due opportune istruzioni:

GET (valore, registro)

PUT (valore, registro)

per leggere o scrivere rispettivamente un certo valore in un dato registro di interfaccia. Quando un processo desidera operare con un dispositivo, esegue la PUT scrivendo opportune informazioni nel registro di controllo dell'interfaccia, poi esegue l'operazione WAIT_FOR_INTERRUPT, ponendosi così in attesa dell'interruzione di fine lavoro da parte del dispositivo, e infine esegue la GET sul registro di stato per conoscere l'esito dell'operazione. Il modello descritto opera perciò secondo la dinamica descritta dal seguente grafico:

processo

interno

(driver)

processo

periferico

(è al contempo

di natura HW e SW)

Legenda:  operazione put (attivazione della periferica)

operazione di wait_for_interrupt

interruzione

Ci rimane da vedere in che modo il processo utente ed il processo driver comunicano.

---