1) Panoramica sul modello di I/O dell'architettura NT
Qualsiasi sistema operativo definisce un modello di I/O (implicito o esplicito) per gestire il flusso dei dati da e per le periferiche. Una caratteristica del modello di I/O di Microsoft Windows è quello di supportare l'I/O asincrono. Inoltre il modello I/O possiede le seguenti caratteristiche:
- L'I/O Manager fornisce interfacce consistenti per tutti i driver in kernel-model inclusi i driver di basso-medio livello e i driver di tipo filesystem. Tutte le richieste di I/O sono gestite tramite gli IRPs (I/O request packets).
- Le operazioni di I/O sono stratificate. Il manager di I/O mette a disposizione servizi di sistema (syscall) che i sottosistemi e le applicazioni in user-mode possono richiamare. L'I/O manager intercetta queste chiamate, le incapsula in IRPs e le smista attraverso lo stack dei driver della periferica di destinazione
- L'I/O manager definisce un set di routine standard, alcune richieste e altre opzioni, che i driver devono supportare. Tutti i driver seguono relativamente un modello di implementazione consistente, date le differenze tra i dipi di periferiche. (bus, function, filter e filesystem)
- Come il sistema operativo stesso i driver sono object-based. I driver, le periferiche e l'hardware di sistema sono rappresentati com oggetti. L'I/O manager e gli altri componenti del sistema esportano delle routine di supporto per lo sviluppo in kernel mode (Kernel-mode driver support routines o KMDSR) che i driver possono chiamare per fare il loro lavoro manipolando gli oggetti appropriati.
Il sistema degli IRPs è utilizzato per la gestione del Plug-n-Play e del PowerManager. I sottosistemi di I/O, PnP e PowerManagment comunicano tra loro attraverso gli IRPs. Se il sottosistema PnP deve inviare una richiesta utilizza il
sottosistema di I/O per inviare i messaggi ai driver. In questo modo viene utilizzato un unico modello di comunicazione.
2) NT, le periferiche, i driver e gli IRPs
Un computer è un insieme di varie perieriche che forniscono INPUT e OUTPUT da e verso il mondo. Tipicamente le periferiche sono le tastiere, i mouse, i controller audio e video, i dischi, le interfaccie di rete e molte altre. I driver sono dei software che permettono di collegare le periferiche al sistema operativo. Per questo motivo il concetto di I/O è di estrema importanza per il programmatore di Driver.
Il Manager I/O di Windows è un sottosistema che gestisce la comunicazione tra le applicazioni e le interfacce che vengono messe a disposizioen dai Driver. Dato che le periferiche potrebbero operare ad una velocità diversa dal sistema operativo la comunicazione tra queste due entità avviene attraverso pacchetti IRPs. Questi pacchetti sono molto simili ai pacchetti di rete oppure ai pacchetti di messaggi di Windows. Essi possono essere utilizzati sia per far comunicare il sistema operativo con i driver e sia per la comunicazione tra driver.
Il sottosistema di I/O di Windows fornisce, per i driver, un modello a livelli chiamato stack dei driver. Solitamente un IRP viaggia da un driver all'altro nello stesso stack per facilitare la comunicazione. Ad esempio un joystick avrebbe bisogno di comunicare con un hub USB, che a sua volta avrebbe bisogno di comunicare con un host controller USB, che a sua volta dovrebbe comunicare tramite un bus PCI con il resto dell'hardware. Lo stack consiste nei driver per Joystick, Hub USB, USB Host controller e PCI BUS. Questa comunicazione è coordinata avendo ogni driver nello stack per mandare e ricevere IRPs.
Non bisogna mai dimenticare che un driver DEVE RICEVERE E MANDARE IRPs, attraverso l'intero stack, in maniera tempestiva per operare in maniera efficiente. Se il tuo driver fa parte di uno stack e non esegue correttamente le operazioni di ricezione, gestione e passaggio delle informazioni potrebbe causare un crash del sistema.
Le routine che forniscono interfacce per utilizzare l'I/O manager usualmente hanno il prefisso Io come ad esempio IoCreateDevice.
Il manager di I/O ha due sottocomponenti. PnP Manager e PowerManager. Entrambi gestiscono le funzionalità per le tecnologie di Pnp e di Power Managment.
3) Cos'è un IRP e come viene rappresentato dal Sistema Operativo
Un IRP è la struttura di base che l'I/O manager utilizza per comunicare con i driver e che i driver utilizzano per comunicare tra loro. Ogni pacchetto IRP è composto da due parti differenti:
Header
E' una parte fissa dell'IRP. E' utilizzato dal manager di I/O per registrare informazioni sulla richiesta originale,come i parametri device-indipendent dei chiamante, l'indirizzo della device-object che rappresenta la periferica e altro. Inoltre è utilizzato per slavare informazioni sullo stato finale della richiesta.
IO Stack Location
Dopo l'header troviamo un insieme di I/O stack location, una per ogni driver contenuti nello stack dei driver. Ogni stack location (ognuna è associata ad un driver nella coda) contiene i parametri, i function-codes (IRP_MJ_XXX) e il contesto.
I driver di alto livello possono controllare il valore nel membro Cancel associato al proprio IRP, tuttavia non potrebbero sapere niente sullo stato finale dell'IRP nel driver a basso livello. (Ad esempio un Cancel nel primo driver non implica una FAIL nell'ultimo)
La struttura IRP è parzialmente opaca (e quindi non tutti i membri sono visibili) e rappresenta un I/O request Packet. I driver devono utilizzare solo alcuni membri perchè gli altri sono utilizzati dal sistema operativo. Il DDK riporta la seguente definizione:
typedef struct _IRP {
.
.
PMDL MdlAddress;
ULONG Flags;
union {
struct _IRP *MasterIrp;
.
.
PVOID SystemBuffer;
} AssociatedIrp;
.
.
IO_STATUS_BLOCK IoStatus;
KPROCESSOR_MODE RequestorMode;
BOOLEAN PendingReturned;
.
.
BOOLEAN Cancel;
KIRQL CancelIrql;
.
.
PDRIVER_CANCEL CancelRoutine;
PVOID UserBuffer;
union {
struct {
.
.
union {
KDEVICE_QUEUE_ENTRY DeviceQueueEntry;
struct {
PVOID DriverContext[4];
};
};
.
.
PETHREAD Thread;
.
.
LIST_ENTRY ListEntry;
.
.
} Overlay;
.
.
} Tail;
} IRP, *PIRP;
Membri:
MdlAddress
- Se il metodo di I/O utilizzato per comunicare con il driver è di tipo Direct I/O e l'IRP è uno di quelli indicati di seguito, MDLAddress conterrà un puntatore a una struttura di tipo MemoryDescriptionList.
- Nel caso in cui il tipo di I/O non sia Direct I/O il membro è NULL
- Questa struttura è utilizzata per determinare l'indirizzo fisico (visto che i programmi user-mode usano indirizzi logici) della porzione di memoria che driver e programma in user-mode utilizzeranno per comunicare.
Lista degli IRP associati a MDLAddress
- IRP_MJ_READ: La struttura MDL descrive un buffer vuoto che il driver o la periferica devono riempire. Qualcuno ha chiesto una READ sulla periferica.
- IRP_MJ_WRITE: La struttura MDL descrive un buffer che contiene informazioni inviate al driver o alla periferica. Qualcuno ha effettuato una WRITE sulla periferica.
Gli IRP che seguono sono legati agli IOCTLs
- IRP_MJ_DEVICE_CONTROL
or IRP_MJ_INTERNAL_DEVICE_CONTROL
Se il codice IOCTL specifica un metodo di trasferimento METHOD_IN_DIRECT il descrittore MDL descrive il buffer che contiene i dati inviati verso il device.
Se invece il codice IOCTL specifica il metodo di trasferimento METHOD_OUT_DIRECT il descrittore MDL descrive un buffer vuoto dove il driver o la periferica andranno a scrivere.
Per ulteriori informazioni sui BUFFER che sono associati ai due metodi di trasferimento descritti fare riferimento alla sezione MSDN Buffer Descripton for I/O Control Codes
- Flags
Il driver di tipo FileSystem utilizzano questo campo che è di sola lettura per tutti i driver. Alcuni driver di alto
livello e i driver per le interfacce di rete ( Network Driver ) invece oltre a leggerlo potrebbero anche settare una
di queste maschere definite dal sistema.
-
IRP_SYNCHRONOUS_PAGING_IO
- AssociatedIrp.MasterIrp
-
- E' un puntatore all'IRP primario in un IRP creato tramite la funzione IoMakeAssociatedIrp.
- AssociatedIrp.SystemBuffer
E' un puntatore a un buffer di sistema utilizzato con il metodo di I/O di tipo Buffered. Il tipo di buffer è determinato in base al tipo di IRP ( come per il Direct I/O)
-
- IRP_MJ_READ
- Il buffer riceve dati dal Device o dal Driver. La dimensione del buffer è specificata attraverso il parametro Parameters.Read.Length nella struttura IO_STACK_LOCATION.
- IRP_MJ_WRITE
- Il buffer fornisce i dati al device o alla perifercia. La lunghezza è specificata nel parametro
- Parameters.Write.Length nella struttura IO_STACK_LOCATION.
- IRP_MJ_DEVICE_CONTROL
or IRP_MJ_INTERNAL_DEVICE_CONTROL
- Il buffer rappresenta sia il buffer di Input che di Output fornito dalla funzione DeviceIoControl e IoBuildDeviceIoControlRequest. I dati in OUTPUT sovrascrivono quelli in INPUT.
- La lunghezza dell'input è specificata in Parameters.DeviceIoControl.InputBufferLenght nella struttura IO_STACK_LOCATION.
- La lunghezza dell'output è specificata in Parameters.DeviceIoControl.OutputBufferLenght nella struttura IO_STACK_LOCATION.
Per ulteriori informazioni sui BUFFER che sono associati ai due metodi di trasferimento descritti fare riferimento alla sezione MSDN Buffer Descripton for I/O Control Codes
Se il driver utilizza il metodo Direct I/O il tipo di buffer è determianto dal tipo di IRP che può essere uno dei seguenti:
IRP_MJ_READ
IRP_MJ_WRITE
- IRP_MJ_DEVICE_CONTROL
or IRP_MJ_INTERNAL_DEVICE_CONTROL
Il buffer rappresneta l'INPUT fornito con DeviceIoControl e IoBuildDeviceIoControlRequest. La lunghezza del buffer è riportata in Parameters.DeviceIoControl.InputBufferLength nella struttura IO_STACK_LOCATION.
- IoStatus
- Contiene la struttura IO_STATUS_BLOCK dove un driver può registrare informazioni di stato prima di chiamare IoCompleteRequest.
- RequestorMode
- Indica la modalità di esecuzione di chi ha richiesto l'operazione. Esistono due modalità UserMoed e KernelMode.
- PendingReturned
- Se è settato a TRUE il driver marca l'IRP come 'pending'. Ogni IoCompletion routine farà il check del valore di questo
- flag. Se il flag è TRUE e se la routine IoCompletion non ritorna STATUS_MORE_PROCESSING_REQUIRED la routine chiamerà IoMarkIrpPending per propagare lo stato di pending in tutto lo stack.
- Cancel
- Se è settato a TRUE
- If set to TRUE, l'IRP viene annullato.
- CancelIrql
- Contiene il livello IRQL dove sta girando il driver quando viene chiamata la funzione IoAcquireCancelSpinLock.
- CancelRoutine
- Contiene l'entry-point che verrà richiamata quando l'IRP viene cancellato. Se questo membro è NULL l'IRP non può essere cancelato.
- UserBuffer
- Contiene l'indirizzo per un buffer di OUTPUT se l'IRP_MAJOR_CODE è uno tra IRP_MJ_DEVICE_CONTROL
o IRP_MJ_INTERNAL_DEVICE_CONTROL e il metodo di I/O è METHOD_NEITHER. (ne Direct , ne buffer )
- Tail.Overlay.DeviceQueueEntry
- Se l'IRP è in coda nella coda del device questo campo punta alla locazione nella coda.
- Questo link può essere usato solo mentre il driver processa l'IRP
- Tail.Overlay.DriverContext
- Se l'IRP non è in coda nella coda del device associato al driver questo campo può essere usato dal driver per registrare fino a quattro puntatori.
- Questo link può essere usato solo mentre il driver processa l'IRP.
- Tail.Overlay.Thread
- E' un puntatore al thread-control block del chiamante. I driver di alto livello che alloca IRP per driver di basso livello di device removibili devono settare questo campo nell'IRP altrimenti l'FSD non potrà determianre quale thread notificare quando accade qualcosa al media.
- Tail.Overlay.ListEntry
- Se il driver gestisce la propria coda di IRP usa questo campo per collegare un IRP con il successivo. Questo link può essere usato solo mentre il driver ha l'IRP bloccato nella sua coda oppure mentre lo sta processando.
- Commenti
- I membri non documentati della struttura IRP sono riservati. Solo l'I/O manager e l'FSD li utilizzano.