Adicionando um dispositivo PnP a um sistema em execução

Esta seção descreve a sequência de eventos que ocorrem quando o sistema configura um dispositivo PnP que um usuário adicionou a uma máquina em execução. Esta discussão destaca as funções do gestor PnP, drivers de barramento e drivers de funções e de filtro na enumeração e configuração de um novo dispositivo.

A maior parte desta discussão também é relevante para configurar um dispositivo PnP que está presente quando a máquina é inicializada. Especificamente, os dispositivos cujos drivers são marcados SERVICE_DEMAND_START em um arquivo INF são configurados essencialmente da mesma maneira, quer o dispositivo seja adicionado dinamicamente ou esteja presente no momento da inicialização.

A figura a seguir mostra os primeiros passos na configuração do dispositivo, começando a partir de quando o usuário conecta o hardware à máquina.

As seguintes notas correspondem aos números circulares da figura anterior:

1. Um utilizador conecta um dispositivo PnP num slot livre num barramento PnP.

   Neste exemplo, o usuário conecta um joystick USB PnP ao hub em um controlador host USB. O hub USB é um dispositivo de barramento PnP porque dispositivos filho podem ser conectados a ele.

2. O controlador de função para o dispositivo de barramento determina que um novo dispositivo está no seu barramento.

   A forma como o condutor determina isso depende da arquitetura do autocarro. Para alguns ônibus, o motorista da função de barramento recebe notificação hot-plug de novos dispositivos. Se o barramento não suportar a notificação hot-plug, o usuário deve executar a ação apropriada no Painel de Controle para fazer com que o barramento seja enumerado.

   Neste exemplo, o barramento USB suporta notificação hot-plug para que o driver de função para o barramento USB seja notificado de que seus filhos foram alterados.

3. O driver de função para o dispositivo de barramento notifica o gerenciador PnP que seu conjunto de dispositivos filho foi alterado.

   O driver de função notifica o gestor PnP chamando o comando IoInvalidateDeviceRelations com um Tipo de BusRelations.

4. O gestor PnP consulta os drivers do barramento para obter a lista atual de dispositivos no barramento.

   O gestor PnP envia um pedido de IRP_MN_QUERY_DEVICE_RELATIONS à pilha de dispositivos do barramento. O valor Parameters.QueryDeviceRelations.Type é BusRelations, indicando que o gerenciador PnP está solicitando a lista atual de dispositivos presentes no barramento (relações de barramento).

   O gerenciador PnP envia o IRP para o driver superior na pilha de dispositivos para o barramento. De acordo com as regras para IRPs PnP, cada driver na pilha processa o IRP, se apropriado, e passa o IRP para o próximo driver.

5. O controlador funcional do dispositivo de barramento gere o IRP.

   Consulte a página de referência para IRP_MN_QUERY_DEVICE_RELATIONS para obter informações detalhadas sobre como lidar com este IRP.

   Neste exemplo, o driver do hub USB manipula esse IRP para o FDO do hub. O driver do hub cria um PDO para o dispositivo joystick e inclui um ponteiro referenciado para o PDO do joystick em sua lista de dispositivos filho retornados com o IRP.

   Quando o driver de barramento pai do hub USB (o par de drivers de classe/miniclasse do controlador host USB) conclui o IRP, o IRP viaja de volta para cima da pilha de dispositivos por meio de quaisquer rotinas IoCompletion registradas pelos drivers do hub.

Observe que o driver da função de barramento relata uma alteração em sua lista de filhos, solicitando que o gerenciador PnP consulte sua lista de dispositivos filho. A solicitação de IRP_MN_QUERY_DEVICE_RELATIONS resultante é vista por todos os drivers para o dispositivo de barramento. Normalmente, o controlador da função de barramento é o único driver para lidar com o IRP e reportar dispositivos filhos. Em algumas pilhas de dispositivos, um driver de filtro de barramento está presente e participa da construção da lista de relações de barramento. Um exemplo é ACPI, que se conecta como um driver de filtro de barramento para dispositivos ACPI. Em algumas pilhas de dispositivos, os drivers de filtro que não são de barramento lidam com a solicitação de IRP_MN_QUERY_DEVICE_RELATIONS , mas isso não é típico.

Neste ponto, o gerenciador PnP tem a lista atual de dispositivos no barramento. Em seguida, o gerenciador PnP determina se algum dispositivo é recém-chegado ou foi removido. Neste exemplo, há um novo dispositivo. A figura a seguir mostra o gerenciador PnP criando um devnode para o novo dispositivo e começando a configurar o dispositivo.

As seguintes notas correspondem aos números circulares da figura anterior:

1. O gerenciador PnP cria devnodes para quaisquer novos dispositivos filho no barramento.

   O gestor PnP compara a lista de relações de barramento retornadas no IRP IRP_MN_QUERY_DEVICE_RELATIONS à lista de crianças para o barramento atualmente registrado na árvore de dispositivos PnP. O gerenciador PnP cria um devnode para cada novo dispositivo e inicia o processamento de remoção para todos os dispositivos que foram removidos.

   Neste exemplo, há um novo dispositivo (um joystick), portanto, o gerenciador PnP cria um devnode para o joystick. Neste ponto, o único driver configurado para o joystick é o driver de barramento USB principal, que criou o PDO do joystick. Qualquer driver de filtro de barramento opcional também estaria presente na pilha de dispositivos, mas o exemplo omite drivers de filtro de barramento para simplificação.

   A seta larga entre os dois devnodes na figura anterior indica que o devnode do joystick é descendente do devnode do hub USB.

2. O gerenciador PnP reúne informações sobre o novo dispositivo e começa a configurá-lo.

   O gerenciador PnP envia uma sequência de IRPs para a pilha de dispositivos para coletar informações sobre o dispositivo. Neste ponto, a pilha de dispositivos consiste apenas no PDO criado pelo driver de barramento pai do dispositivo e DOs de filtro para quaisquer drivers de filtro de barramento opcionais. Portanto, o motorista de ônibus e os motoristas de filtro de ônibus são os únicos motoristas que respondem a esses IRPs. Neste exemplo, o único controlador na pilha de dispositivos de joystick é o controlador de barramento pai, o controlador de hub USB.

   O gestor PnP recolhe informação sobre um novo dispositivo enviando IRPs para a pilha de dispositivos. Esses IRPs incluem o seguinte:

   • IRP_MN_QUERY_ID, um IRP separado para cada um dos seguintes tipos de IDs de hardware:

     • BusQueryDeviceID
     • BusQueryInstanceID
     • BusQueryHardwareIDs
     • BusQueryCompatibleIDs
     • BusQueryContainerID

   • IRP_MN_QUERY_CAPABILITIES

   • IRP_MN_QUERY_DEVICE_TEXT, um IRP separado para cada um dos seguintes itens:

     • DeviceTextDescription
     • DeviceTextLocationInformation

   • IRP_MN_QUERY_BUS_INFORMATION

   • IRP_MN_QUERY_RESOURCES

   • IRP_MN_QUERY_RESOURCE_REQUIREMENTS

   O gerenciador PnP envia os IRPs listados acima nesta etapa de processamento de um novo dispositivo PnP, mas não necessariamente na ordem listada, então você não deve fazer suposições sobre a ordem em que os IRPs são enviados. Além disso, você não deve assumir que o gerente PnP envia apenas os IRPs listados acima.

   O gerenciador PnP verifica o registro para determinar se o dispositivo foi instalado nesta máquina anteriormente. O gerente PnP verifica a existência de uma subchave <enumerator>\<deviceID> para o dispositivo na ramificação Enum. Neste exemplo, o dispositivo é novo e deve ser configurado "do zero".

3. O gerenciador PnP armazena informações sobre o dispositivo no registro.

   A ramificação Enum do Registro é reservada para uso por componentes do sistema operacional e seu layout está sujeito a alterações. Os desenvolvedores de drivers devem usar rotinas do sistema para extrair informações relacionadas aos drivers. Não aceda diretamente ao ramo Enum a partir de um driver. As seguintes informações do Enum são listadas apenas para fins de depuração.

   • O gerenciador PnP cria uma subchave para o dispositivo sob a chave para o enumerador do dispositivo.

     O gerenciador PnP cria uma subchave chamada HKLM\System\CurrentControlSet\Enum\<enumerator>\<deviceID>. Ele cria a subchave do <enumerador> se ela ainda não existir.

     Um enumerador é um componente que descobre dispositivos PnP com base em um padrão de hardware PnP. As tarefas de um recenseador são realizadas por um motorista de ônibus PnP em parceria com o gerente PnP. Um dispositivo é normalmente enumerado pelo seu controlador de barramento pai, como PCI ou PCMCIA. Alguns dispositivos são enumerados por um driver de filtro de barramento, como o ACPI.

   • O gerenciador PnP cria uma subchave para esta instância do dispositivo.

     Se Capabilities.UniqueID for retornado como TRUE para IRP_MN_QUERY_CAPABILITIES, o ID único do dispositivo é único em todo o sistema. Caso contrário, o gerenciador PnP modifica o ID para que ele seja exclusivo em todo o sistema.

     O gerenciador PnP cria uma subchave chamada HKLM\System\CurrentControlSet\Enum\<enumerator><\deviceID>\<instanceID>.

   • O gerenciador PnP grava informações sobre o dispositivo na subchave da instância do dispositivo.

     O gerenciador PnP armazena informações, incluindo o seguinte, se foi fornecido para o dispositivo:

     • DeviceDesc - a partir de IRP_MN_QUERY_DEVICE_TEXT
     • Localização - a partir de IRP_MN_QUERY_DEVICE_TEXT
     • Capacidades - os flags de IRP_MN_QUERY_CAPABILITIES
     • UINumber - a partir de IRP_MN_QUERY_CAPABILITIES
     • HardwareID - a partir de IRP_MN_QUERY_ID
     • CompatibleIDs - a partir de IRP_MN_QUERY_ID
     • ContainerID - a partir de IRP_MN_QUERY_ID
     • LogConf\BootConfig - a partir de IRP_MN_QUERY_RESOURCES
     • LogConf\BasicConfigVector - a partir de IRP_MN_QUERY_RESOURCE_REQUIREMENTS

Neste ponto, o gestor PnP está pronto para localizar os drivers de função e de filtro para o dispositivo, se houver. (Veja a figura a seguir.)

As seguintes notas correspondem aos círculos numerados na figura anterior:

1. O gerenciador PnP do modo kernel coordena-se com o gerenciador PnP do modo de usuário e os componentes de configuração do modo de usuário para encontrar a função e os drivers de filtro para o dispositivo, se houver.

   O gerenciador PnP de modo kernel enfileira um evento para o gerenciador PnP de modo de usuário, identificando um dispositivo que precisa ser instalado. Depois que um usuário privilegiado faz login, os componentes de modo de usuário prosseguem com a localização de drivers. Para obter informações sobre os componentes de instalação e sua função na instalação de um dispositivo, consulte Instalação de dispositivo e driver.

2. Os componentes de configuração em modo de usuário direcionam o gestor PnP em modo kernel para carregar os drivers de função e de filtro.

   Os componentes do modo de utilizador fazem chamadas de retorno para o modo núcleo para obter os drivers carregados, fazendo com que suas rotinas AddDevice sejam chamadas.

A figura a seguir mostra o gerenciador PnP carregando os drivers (se apropriado), chamando suas rotinas AddDevice e direcionando os drivers para iniciar o dispositivo.

As seguintes notas correspondem aos círculos numerados na figura anterior:

1. Drivers de filtro inferior

   Antes que o driver de função seja anexado à pilha de dispositivos, o gerenciador PnP processa todos os drivers de filtro inferior. Para cada driver de filtro inferior, o gestor PnP chama a rotina DriverEntry se o driver ainda não estiver carregado. Em seguida, o gerenciador PnP chama a rotina AddDevice do driver. Na sua rotina AddDevice, o driver de filtro cria um objeto de dispositivo de filtro (filter DO) e anexa-o à pilha de dispositivos (IoAttachDeviceToDeviceStack). Assim que anexa o objeto de dispositivo à pilha de dispositivos, o driver é envolvido como controlador para o dispositivo.

   No exemplo do joystick USB, há um driver de filtro de nível inferior para o dispositivo.

2. Controlador de função

   Depois que todos os filtros inferiores são anexados, o gerenciador PnP processa o driver de função. O gestor PnP chama a rotina DriverEntry do driver de função se o driver ainda não estiver carregado e também chama a rotina AddDevice do driver de função. O driver de função cria um objeto de dispositivo de função (FDO) e o anexa à pilha de dispositivos.

   Neste exemplo, o controlador de função para o joystick USB é, na verdade, um par de controladores: o controlador de classe HID e o controlador de subclasse HID. Os dois drivers trabalham juntos para funcionar como driver de função. O par de drivers cria apenas um FDO e o anexa à pilha de dispositivos.

3. Drivers de filtro superior

   Depois que o driver de função é anexado, o gerenciador PnP processa todos os drivers de filtro superior.

   Neste exemplo, há um driver de filtro superior para o dispositivo.

4. Atribuir recursos e iniciar o dispositivo

   O gerenciador PnP atribui recursos ao dispositivo, se necessário, e emite um IRP para iniciar o dispositivo.

   • Atribuição de recursos

     No início do processo de configuração, o gerenciador PnP reuniu os requisitos de recursos de hardware para o dispositivo do driver de barramento pai do dispositivo. Depois de o conjunto completo de drivers ser carregado para o dispositivo, o gestor PnP envia um pedido IRP_MN_FILTER_RESOURCE_REQUIREMENTS para a pilha de dispositivos. Todos os drivers na pilha têm a oportunidade de lidar com esse IRP e modificar a lista de requisitos de recursos do dispositivo, se necessário.

     O gerenciador PnP atribui recursos ao dispositivo, se o dispositivo exigir algum, com base nos requisitos do dispositivo e nos recursos atualmente disponíveis.

     O gerenciador PnP pode precisar reorganizar as atribuições de recursos de dispositivos existentes para satisfazer as necessidades do novo dispositivo. Essa realocação de recursos é chamada de "reequilíbrio". Os drivers para os dispositivos existentes recebem uma sequência de IRPs de parada e inicialização durante um reequilíbrio, mas o reequilíbrio deve ser transparente para os usuários.

     No exemplo do joystick USB, os dispositivos USB não requerem recursos de hardware, pelo que o gestor PnP define a lista de recursos como NULL.

   • Iniciar o dispositivo (IRP_MN_START_DEVICE)

     Uma vez que o gestor PnP atribui recursos ao dispositivo, ele envia um IRP_MN_START_DEVICE para a pilha de dispositivos, indicando aos drivers que iniciem o dispositivo.

   Após o dispositivo ser iniciado, o gestor PnP envia mais três IRPs aos controladores do dispositivo.

   • IRP_MN_QUERY_CAPABILITIES

     Depois que o IRP de inicialização for concluído com êxito, o gerenciador PnP envia outro IRP IRP_MN_QUERY_CAPABILITIES para a pilha de dispositivos. Todos os drivers para o dispositivo têm a opção de lidar com o IRP. O gestor PnP envia este IRP neste momento, depois de todos os controladores estarem ligados e o dispositivo ser iniciado, porque os controladores de função ou de filtro podem precisar acessar o dispositivo para recolher informações sobre capacidades.

   • IRP_MN_QUERY_PNP_DEVICE_STATE

     Este IRP dá a um driver a oportunidade de, por exemplo, relatar que o dispositivo não deve ser exibido em interfaces de usuário, como o Gerenciador de dispositivos e o programa Hotplug. Isso é útil para dispositivos que estão presentes em um sistema, mas não são utilizáveis na configuração atual, como uma porta de jogo em um laptop que não é utilizável quando o laptop é desencaixado.

   • IRP_MN_QUERY_DEVICE_RELATIONS para relações de ônibus

     O gerenciador PnP envia esse IRP para determinar se o dispositivo tem algum dispositivo filho. Em caso afirmativo, o gestor PnP configura cada dispositivo filho.

Usando GUID_PNP_LOCATION_INTERFACE

A interface GUID_PNP_LOCATION_INTERFACE fornece a propriedade de dispositivo SPDRP_LOCATION_PATHS Plug and Play (PnP) de um dispositivo.

Para implementar essa interface em seu driver, manipule o IRP IRP_MN_QUERY_INTERFACE com InterfaceType = GUID_PNP_LOCATION_INTERFACE. Seu driver fornece um ponteiro para uma estrutura de PNP_LOCATION_INTERFACE que contém ponteiros para as rotinas individuais da interface. A rotina PnpGetLocationString fornece a parte específica do dispositivo da propriedade SPDRP_LOCATION_PATHS do dispositivo.