Rotinas dispatchPnP

A rotina DispatchPnP de um driver dá suporte a 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 são vários códigos de função de E/S secundários (consulte Plug and Play IRPs menores), 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 direcionar os drivers a iniciar, parar e remover dispositivos e consultar 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 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 conclui o IRP. Consulte Passando IRPs PnP para baixo na pilha de dispositivos para obter mais informações.

  Um driver poderá falhar em 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 não manipula, o driver não deverá falhar no 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, lidar 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 IRPs menores 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 motoristas de ônibus).

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

• Se um driver manipular um IRP PnP com êxito, o driver definirá o status IRP como ê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 gerenciador 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 para o sucesso. No entanto, essa é uma prática arriscada. Para consistência e robustez, um driver deve definir o irp status para êxito para cada PnP IRP que ele lida com êxito.

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

  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. Essa é a status inicial definida pelo gerenciador PnP. Se um IRP for concluído com esse status, isso significa que nenhum driver na pilha lidou com o IRP; todos os drivers passaram o IRP para o próximo driver.

• Um driver deve manipular um PnP IRP em sua rotina de expedição (no caminho do IRP para baixo na pilha do dispositivo), em uma rotina IoCompletion (no caminho do IRP fazer backup da 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 manipulados primeiro pelo driver na parte superior da pilha do dispositivo e, em seguida, por cada driver inferior. Outros, como IRP_MN_START_DEVICE, devem ser tratados primeiro pelo motorista do ônibus pai. Ainda assim, outros, como IRP_MN_QUERY_CAPABILITIES, podem ser manipulados no caminho para baixo na pilha do dispositivo e no caminho de backup. Consulte Plug and Play IRPs menores para obter as regras que se aplicam a cada PnP IRP. Consulte Adiando o processamento de PnP IRP até que os drivers inferiores sejam concluídos para obter informações sobre como lidar com IRPs PnP que devem ser processados primeiro pelo motorista do ônibus pai.

• Um driver deve adicionar informações a um IRP no caminho do IRP para baixo na pilha do dispositivo e modificar ou remover informações sobre o caminho de backup do IRP.

  Ao retornar informações em resposta a um IRP de consulta PnP, um driver deve seguir essa convenção para habilitar informações ordenadas passadas pelos drivers em camadas para um dispositivo.

• Exceto quando explicitamente documentado, um driver não deve depender do envio de IRPs PnP em qualquer 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 na parte superior da pilha do dispositivo. Chame IoGetAttachedDeviceReference para obter um ponteiro para o objeto de dispositivo para o driver na parte superior da pilha do dispositivo.