Caricare documenti e articoli online 
INFtub.com è un sito progettato per cercare i documenti in vari tipi di file e il caricamento di articoli online.


 
Non ricordi la password?  ››  Iscriviti gratis
 

LA GESTIONE DELL'INGRESSO-USCITA

informatica



LA GESTIONE DELL'INGRESSO-USCITA


Il principale strumento per la risoluzione del problema della gestione dell'ingresso-uscita è costituito dai DRIVER. Un driver, come è noto, è una particolare unità di programma che dirige a basso livello le operazioni di ingresso / uscita. Ma in quale contesto viene eseguito un driveri? Si presentano varie alternative.

Si può pensare che il processo driver appartenga al kernel del SO. Di conseguenza, il driver può venire eseguito solamente effettuando una supervisor call; quindi, il processo che necessita dell'operazione di I/O può restare bloccato o meno; quando possibile, verrà eseguito il driver e infine si uscirà dal kernel tornando al processo

Un'altra possibilità è 616e43g che il driver sia eseguito nel contesto di uno specifico processo, detto appunto PROCESSO DRIVER, al quale un processo che voglia eseguire un'operazione di I/O deve inviare un messaggio, servendosi delle procedure messe appositamente a disposizione dal kernel. Successivamente tale processo si metterà in attesa. Il processo driver eseguirà allora nel proprio contesto la routine driver [1] e infine spedirà un messaggio di risposta al processo sospeso.



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.




È possibile che il termine coda del driver usato nel seguito si riferisca a questa routine (cioè a quella parte del driver che è specificamente dedicata a realizzare le operazioni di I/O), in contrapposizione al termine testa del driver, pure utilizzato da De Carlini, che quindi potrebbe riferirsi alla sezione del driver che realizza operazioni preliminari e di contorno. (Altra possibilità: 'coda del driver' sta per 'coda di messaggi in arrivo al driver').


Cfr. nota 43.

Cfr. nota 43. Il significato del periodo compreso fra i due punti e virgola rimane comunque oscuro.




Privacy




Articolo informazione


Hits: 1860
Apprezzato: scheda appunto

Commentare questo articolo:

Non sei registrato
Devi essere registrato per commentare

ISCRIVITI



Copiare il codice

nella pagina web del tuo sito.


Copyright InfTub.com 2024