Accodamento e dequeuing di IRP

Poiché il gestore di I/O supporta l'I/O asincrona all'interno di un sistema multithreading e multithreading, le richieste di I/O a un dispositivo possono venire eseguite più velocemente rispetto al relativo driver possono elaborarle al completamento, in particolare nei computer multiprocessore. Di conseguenza, i provider di sicurezza di rete associati a qualsiasi dispositivo specifico devono essere accodati nel driver quando il dispositivo è già occupato nell'elaborazione di un'altra IRP.

Di conseguenza, un driver di livello più basso richiede uno dei seguenti elementi:

• Routine StartIo , che il gestore di I/O chiama per avviare le operazioni di I/O per gli INDIRIZZI IP che il driver ha accodato a una coda IRP fornita dal sistema (vedere IoStartPacket).

• Meccanismo di accodamento e dequeuing interno di IRP, che il driver usa per gestire gli IRP che arrivano più velocemente di quanto possa soddisfarli. I driver possono usare code di dispositivi, code interlock o code annullate. Per altre informazioni, vedere Code IRP gestite da driver.

Solo un driver di dispositivo di livello più basso che può soddisfare e completare ogni possibile IRP nelle routine di invio non necessita di routine StartIo e di nessuna coda gestita da driver per i gruppi di integrazione.

I driver di livello superiore quasi non hanno mai routine StartIo . La maggior parte dei driver intermedi non ha routine StartIo né code interne; un driver intermedio può in genere passare ip con parametri validi dalle routine di invio e eseguire qualsiasi operazione di post-elaborazione necessaria per qualsiasi IRP nella routine IoCompletion .

Di seguito vengono descritte, in generale, alcune considerazioni sulla progettazione per determinare se implementare una routine StartIo con o senza code interne gestite da driver per i provider di sicurezza di rete.

Routine StartIo nei driver

Per i dispositivi periferici computer in grado di gestire una sola operazione di I/O del dispositivo alla volta, i driver di dispositivo possono implementare routine StartIo . Per questi driver, il gestore I/O fornisce routine IoStartPacket e IoStartNextPacket per accodare e dequeue IRP da e verso una coda IRP fornita dal sistema.

Per altre informazioni sulle routine StartIo , vedere Scrittura di una routine StartIo.

Code interne per i provider di servizi di integrazione nei driver

Se un dispositivo può supportare più operazioni di I/O simultanee, il driver di dispositivo di livello più basso deve configurare code di richieste interne e gestire la propria accodamento di indirizzi IP. Ad esempio, il driver seriale di sistema gestisce code separate per operazioni di lettura, scrittura, eliminazione e attesa nei dispositivi perché supporta dispositivi seriali full-duplex.

Un driver di livello superiore che invia richieste a un certo numero di driver di dispositivo sottostanti potrebbe anche mantenere le code interne di IRP. Ad esempio, i driver del file system hanno quasi sempre code interne per gli INDIRIZZI IP.

Per altre informazioni, vedere Code IRP gestite da driver.

Sincronizzazione coda interna

I driver con thread dedicati ai dispositivi e i driver di livello più alto che usano thread di lavoro esecutivi (inclusi la maggior parte dei driver del file system) in genere configurano la propria coda per i provider di servizi di integrazione. La coda viene condivisa dal thread del driver o dal callback del thread di lavoro fornito dal driver e da altre routine del driver che elaborano i provider di sicurezza.

Un driver che implementa la propria struttura di coda deve garantire che l'accesso alla coda sia sincronizzato e che gli INDIRIZZI DI rete annullati vengano rimossi dalla coda. Per semplificare questa attività per i writer driver, le code IRP annullate consentono di usare un framework standard che è possibile usare durante l'implementazione di una coda IRP. Per altre informazioni, vedere Annulla code IRP sicure . Si tratta del metodo preferito per l'implementazione di una coda IRP.

I driver possono anche implementare la sincronizzazione di tutte le code IRP e annullare la logica in modo esplicito. Ad esempio, un driver potrebbe usare una coda interlock. Le routine di invio del driver inseriscono irP nella coda interlocked e un thread creato dal driver o il callback del thread di lavoro del driver li rimuove chiamando le routine di supporto di ExInterlockedXxxList .

Ad esempio, il driver del controller floppy di sistema usa una coda interlocked. Il thread dedicato al dispositivo gestisce lo stesso processo di IRP eseguito da altre routine StartIo dei driver di dispositivo e alcune delle stesse elaborazioni di IRP eseguite da altre routine DpcForIsr dei driver di dispositivo.

Code interne con routine StartIo nei driver

Un driver che gestisce le proprie code interne può avere anche una routine StartIo , ma non è necessario. La maggior parte dei driver di dispositivo di livello più basso ha una routine StartIo o gestisce la propria accodamento di IP, ma non entrambi.

Un'eccezione a questo è il driver della porta SCSI, che ha una routine StartIo e gestisce le code interne di IRP. Il gestore I/O accoda irPs alla routine StartIo del driver di porta nella coda del dispositivo associata all'oggetto dispositivo creato dal driver che rappresenta un HBA SCSI. Il driver della porta SCSI configura e gestisce anche le code di dispositivi per i gruppi di integrazione a ogni dispositivo di destinazione (corrispondente a un'unità logica SCSI) in qualsiasi bus SCSI basato su HBA nel computer.

Il driver della porta SCSI usa le code di dispositivi supplementari per contenere i provider di integrazione inviati dai driver di classe SCSI nelle code specifiche di LU ogni volta che qualsiasi dispositivo in un bus SCSI è particolarmente occupato. In effetti, le code di dispositivo specifiche del driver consentono al driver della porta SCSI di serializzare le operazioni per dispositivi SCSI eterogenei tramite un'HBA mantenendo ogni dispositivo nei bus SCSI di HBA il più occupato possibile.