Rotinas de DispatchPnP

A rotina DispatchPnP de um driver suporta Plug and Play manipulando IRPs para o código de função IRP_MJ_PNP de E/S. Associado ao código de função IRP_MJ_PNP estão vários códigos de função de entrada/saída menores (consulte IRPs Menores de Plug and Play), alguns dos quais todos os drivers devem tratar e alguns dos quais podem ser tratados opcionalmente. O gerenciador PnP usa esses códigos de função secundária para direcionar os drivers para iniciar, parar e remover dispositivos e para consultar drivers sobre seus dispositivos.

Todos os drivers para um dispositivo devem ter a oportunidade de lidar com IRPs PnP para o dispositivo, exceto em alguns casos em que um driver de função ou filtro tem permissão para rejeitar o IRP.

A rotina DispatchPnP de cada motorista deve seguir estas regras:

• Uma função ou driver de filtro deve passar os IRPs PnP para o próximo driver na pilha de dispositivos, a menos que a função ou driver de filtro manipule o IRP e encontre uma falha (devido a recursos insuficientes, por exemplo).

  Todos os drivers de um dispositivo devem ter a oportunidade de processar IRPs PnP desse dispositivo, a menos que um dos drivers encontre um erro. O gerenciador PnP envia IRPs para o driver superior em uma pilha de dispositivos. Os drivers de função e filtro passam o IRP para o próximo driver, e o driver de barramento pai completa o IRP. Consulte Passagem de IRPs PnP na cadeia de dispositivos para obter mais informações.

  Um driver pode falhar um IRP se tentar processar o IRP e encontrar um erro (como recursos insuficientes). Se um driver recebe um IRP com um código que não manipula, o driver não deve falhar o IRP. Ele deve passar esse IRP para o próximo driver sem modificar o status do IRP.

• Um driver deve lidar com determinados IRPs PnP e, opcionalmente, pode lidar com outros.

  Cada driver PnP é necessário para lidar com determinados IRPs, como IRP_MN_REMOVE_DEVICE, e pode, opcionalmente, lidar com outros. Veja IRPs menores Plug and Play para obter informações sobre quais IRPs são necessários e opcionais para cada tipo de controlador (controladores de função, controladores de filtro e controladores de barramento).

  Um driver pode falhar um IRP PnP necessário com um status de erro apropriado, mas um driver não deve retornar STATUS_NOT_SUPPORTED para tal IRP.

• Se um driver manipula um IRP PnP com êxito, o driver define o status do IRP como bem-sucedido. Não depende de outro driver na pilha para definir o status.

  Um driver define Irp-IoStatus.Status> como STATUS_SUCCESS para informar ao gerente PnP que o driver manipulou o IRP com êxito. Para alguns IRPs, um motorista que não seja de ônibus pode confiar em seu motorista de ônibus pai para definir o status de sucesso. No entanto, esta é uma prática arriscada. Para consistência e robustez, um driver deve definir o status IRP como bem-sucedido para cada IRP PnP que processa com sucesso.

• Se um controlador falhar um IRP, o controlador completa o IRP com um status de erro e não passa o IRP para o próximo controlador.

  Para falhar um IRP como IRP_MN_QUERY_STOP_DEVICE, um driver define Irp-IoStatus.Status> como STATUS_UNSUCCESSFUL. Os valores de status de erro adicionais para outros IRPs incluem STATUS_INSUFFICIENT_RESOURCES e STATUS_INVALID_DEVICE_STATE.

  Os drivers não definem STATUS_NOT_SUPPORTED para IRPs que eles manipulam. Este é o status inicial definido pelo gerente PnP. Se um IRP for concluído com esse status, isso significa que nenhum driver na pilha manipulou o IRP; todos os drivers apenas o passaram para o próximo driver.

• Um driver deve lidar com um IRP PnP em sua rotina de despacho (no caminho do IRP para baixo da pilha de dispositivos), em uma rotina IoCompletion (no caminho de volta do IRP para cima da pilha de dispositivos), ou ambos, conforme especificado na página de referência para o IRP.

  Alguns IRPs PnP, como IRP_MN_REMOVE_DEVICE, devem ser manipulados primeiro pelo driver na parte superior da pilha de dispositivos e, em seguida, por cada driver inferior seguinte. Outras, como IRP_MN_START_DEVICE, devem ser tratadas primeiro pelo motorista do ônibus pai. Outros ainda, como IRP_MN_QUERY_CAPABILITIES, podem ser manipulados tanto no caminho para baixo da pilha de dispositivos quanto no caminho de volta. Consulte IRPs Plug and Play menores para obter as regras que se aplicam a cada IRP PnP. Consulte Adiando o processamento de IRP PnP até que os drivers inferiores terminem para obter informações sobre como lidar com IRPs PnP que devem ser processados primeiro pelo driver de barramento principal.

• Um driver deve adicionar informações a um IRP enquanto ele desce pela pilha de dispositivos e modificar ou remover informações no caminho de volta do IRP.

  Ao retornar informações em resposta a uma consulta PnP IRP, um driver deve seguir esta convenção para possibilitar a passagem ordenada de informações pelos drivers em camadas de um dispositivo.

• Exceto quando explicitamente documentado, um driver não deve depender do envio de IRPs PnP em uma ordem específica.

• Quando um driver envia um IRP PnP, ele deve enviar o IRP para o driver superior na pilha de dispositivos.

  A maioria dos IRPs PnP são enviados pelo gerente PnP, mas alguns podem ser enviados por drivers (por exemplo, IRP_MN_QUERY_INTERFACE). O driver deve enviar um PnP IRP para o driver no topo da pilha de dispositivos. Chame IoGetAttachedDeviceReference para obter um ponteiro para o objeto de dispositivo para o driver no topo da pilha de dispositivos.