Routine DispatchPnP

La routine DispatchPnP di un driver supporta Plug and Play gestendo i runtime di integrazione per il codice di funzione I /O IRP_MJ_PNP. Associato al codice di funzione IRP_MJ_PNP sono diversi codici di funzione di I/O secondari (vedere Plug and Play Minor IRPs), alcuni dei quali tutti i driver devono gestire e alcuni dei quali possono essere gestiti facoltativamente. Il gestore PnP usa questi codici di funzione secondari per indirizzare i driver all'avvio, all'arresto e alla rimozione di dispositivi e per eseguire query sui driver sui dispositivi.

Tutti i driver per un dispositivo devono avere la possibilità di gestire i runtime di integrazione PnP per il dispositivo, ad eccezione di alcuni casi in cui un driver di funzione o filtro può avere esito negativo in IRP.

La routine DispatchPnP di ogni driver deve seguire queste regole:

• Un driver di funzione o filtro deve passare i runtime di integrazione PnP al driver successivo nello stack di dispositivi, a meno che la funzione o il driver di filtro gestisca l'IRP e non verifichi un errore (ad esempio a causa di risorse insufficienti).

  Tutti i driver per un dispositivo devono avere la possibilità di gestire i runtime di integrazione PnP per il dispositivo, a meno che uno dei driver non verifichi un errore. Il gestore PnP invia i provider di integrazione al driver principale in uno stack di dispositivi. I driver di funzione e filtro passano l'IRP al driver successivo e il driver del bus padre completa l'IRP. Per altre informazioni, vedere Passaggio dei runtime di integrazione PnP nello stack di dispositivi .

  Un driver può non riuscire un IRP se tenta di gestire l'IRP e rileva un errore , ad esempio risorse insufficienti. Se un driver riceve un IRP con un codice che non gestisce, il driver non deve interrompere l'IRP. Deve passare tale IRP al driver successivo senza modificare lo stato di IRP.

• Un driver deve gestire determinati PnP IRP e può facoltativamente gestire altri.

  Ogni driver PnP è necessario per gestire determinati provider di integrazione, ad esempio IRP_MN_REMOVE_DEVICE, e può facoltativamente gestire altri. Per informazioni sui provider di integrazione necessari e facoltativi per ogni tipo di driver (driver di funzione, driver di filtro e driver bus), vedere Plug and Play Minor IRPs (Plug and Play Minor IRPs ).

  Un driver può non riuscire con un IRP PnP necessario con uno stato di errore appropriato, ma un driver non deve restituire STATUS_NOT_SUPPORTED per tale IRP.

• Se un driver gestisce correttamente un IRP PnP, il driver imposta lo stato di IRP sull'esito positivo. Non dipende da un altro driver nello stack per impostare lo stato.

  Un driver imposta Irp-IoStatus.Status> su STATUS_SUCCESS per informare il gestore PnP che il driver ha gestito correttamente l'IRP. Per alcuni provider di integrazione, un driver non bus potrebbe essere in grado di basarsi sul driver del bus padre per impostare lo stato sull'esito positivo. Tuttavia, si tratta di una pratica rischiosa. Per garantire coerenza e affidabilità, un driver deve impostare lo stato di IRP sull'esito positivo per ogni IRP PnP gestito correttamente.

• Se un driver non riesce un IRP, il driver completa l'IRP con uno stato di errore e non passa l'IRP al driver successivo.

  Per eseguire un errore di IRP come IRP_MN_QUERY_STOP_DEVICE, un driver imposta Irp-IoStatus.Status> su STATUS_UNSUCCESSFUL. Altri valori di stato di errore per altri provider di integrazione includono STATUS_INSUFFICIENT_RESOURCES e STATUS_INVALID_DEVICE_STATE.

  I driver non impostano STATUS_NOT_SUPPORTED per i provider di integrazione gestiti. Si tratta dello stato iniziale impostato dal gestore PnP. Se un IRP viene completato con questo stato, significa che nessun driver nello stack ha gestito l'IRP; tutti i driver hanno appena passato l'IRP al driver successivo.

• Un driver deve gestire un IRP PnP nella routine di invio (nella strada verso il basso dello stack di dispositivi), in una routine IoCompletion (nel modo in cui viene eseguito il backup dello stack di dispositivi) o entrambi, come specificato nella pagina di riferimento per IRP.

  Alcuni IRP PnP, ad esempio IRP_MN_REMOVE_DEVICE, devono essere gestiti prima dal driver nella parte superiore dello stack di dispositivi e quindi da ogni driver inferiore successivo. Altri, ad esempio IRP_MN_START_DEVICE, devono essere gestiti prima dal conducente del bus padre. Altri, ad esempio IRP_MN_QUERY_CAPABILITIES, possono essere gestiti sia lungo lo stack di dispositivi che il backup. Per le regole applicabili a ogni PnP IRP, vedere Plug and Play Minor IRPs (Plug and Play Minor IRP ). Vedere Postponing PnP IRP Processing Until Lower Drivers Finish (Postponing PnP IRP Processing Until Lower Drivers Finish) (Postponing PnP IRP Processing Until Lower Drivers Finish Finish For information about handling PnP IRPs that must be processed first by the parent bus driver).

• Un driver deve aggiungere informazioni a un IRP nel percorso verso il basso dello stack di dispositivi e modificare o rimuovere informazioni sul backup di IRP.

  Quando si restituiscono informazioni in risposta a un IRP di query PnP, un driver deve seguire questa convenzione per abilitare il passaggio ordinato delle informazioni dai driver a più livelli per un dispositivo.

• Tranne dove documentato in modo esplicito, un driver non deve dipendere dai provider di integrazione PnP inviati in un ordine specifico.

• Quando un driver invia un IRP PnP, deve inviare l'IRP al driver principale nello stack di dispositivi.

  La maggior parte dei runtime di integrazione PnP viene inviata dal gestore PnP, ma alcuni possono essere inviati dai driver (ad esempio, IRP_MN_QUERY_INTERFACE). Un driver deve inviare un IRP PnP al driver nella parte superiore dello stack di dispositivi. Chiamare IoGetAttachedDeviceReference per ottenere un puntatore all'oggetto dispositivo per il driver nella parte superiore dello stack di dispositivi.