Rotinas DispatchPnP

A rotina DispatchPnP de um driver dá suporte ao Plug and Play manipulando IRPs para o código de função de E/S IRP_MJ_PNP. Associados ao código de função IRP_MJ_PNP estão vários códigos de função de E/S menores (consulte Plug and Play Minor IRPs), alguns dos quais todos os drivers devem manipular e alguns dos quais podem ser manipulados opcionalmente. O gerenciador PnP usa esses códigos de função secundários para orientar os drivers a iniciar, desativar e remover dispositivos e consultar os drivers sobre seus dispositivos.

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

A rotina DispatchPnP de cada driver deve seguir estas regras:

• Um driver de função ou filtro deve passar IRPs PnP para o próximo driver na pilha do dispositivo, a menos que o driver de função ou 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 manipular IRPs PnP para o dispositivo, a menos que um dos drivers encontre um erro. O gerenciador PnP envia IRPs para o driver mais alto em uma pilha de dispositivos. Os drivers de função e filtro passam o IRP para o próximo driver e o motorista do ônibus pai conclui o IRP. Confira o encaminhamento de IRPs PnP na hierarquia de dispositivos para obter mais informações.

  Um driver pode falhar na execução de um IRP se tentar manipular o IRP e encontrar um erro (como recursos insuficientes). Se um driver receber um IRP com um código que ele não consegue tratar, o driver não deve rejeitar 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 pode lidar, opcionalmente, com outros.

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

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

• Se um driver manipular um IRP do PnP com êxito, o driver definirá o status do IRP para êxito. Ele 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 lidou com o IRP com êxito. Para alguns IRPs, um motorista que não seja de ônibus pode ser capaz de contar com seu motorista de ônibus pai para definir o status como sucesso. No entanto, essa é uma prática arriscada. Para consistência e robustez, um driver deve definir o status IRP como bem-sucedido para cada PnP IRP que ele processa com êxito.

• Se um driver falhar ao processar um IRP, o driver concluirá o IRP com um status de erro e não o passará para o próximo driver.

  Para falhar um IRP como IRP_MN_QUERY_STOP_DEVICE, o driver deve definir 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. Esse é o status inicial definido pelo gerenciador PnP. Se um IRP for concluído com esse status, isso significa que nenhum dos drivers na pilha tratou o IRP; todos os drivers apenas passaram o IRP para o próximo driver.

• Um driver deve lidar com um IRP PnP em sua rotina de despacho (no caminho do IRP descendo na pilha do dispositivo), em uma rotina IoCompletion (no caminho do IRP subindo na pilha do dispositivo), ou ambos, conforme especificado na página de referência do IRP.

  Alguns IRPs PnP, como IRP_MN_REMOVE_DEVICE, devem ser tratados primeiro pelo driver no topo da pilha de dispositivos e, em seguida, por cada driver inferior. Outros, como IRP_MN_START_DEVICE, devem ser tratados primeiro pelo motorista do ônibus pai. Outros, como IRP_MN_QUERY_CAPABILITIES, podem ser manipulados tanto no caminho descendente da pilha do dispositivo quanto no caminho ascendente. Consulte Plug and Play Minor IRPs para obter as regras que se aplicam a cada PnP IRP. Consulte Postergando o Processamento de IRPs PnP até que os Drivers Inferiores Concluam para obter informações sobre como lidar com PnP IRPs que devem ser processados primeiro pelo controlador do barramento pai.

• Um driver deve adicionar informações a um IRP à medida que o IRP desce na pilha do dispositivo e modificar ou remover informações à medida que o IRP sobe novamente.

  Ao retornar informações em resposta a um IRP de consulta PnP, um driver deve seguir essa convenção para permitir a passagem ordenada de informações pelos drivers em camadas para 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 do dispositivo.

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