Compartilhar via


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 um computador em execução. Esta discussão destaca as funções do gerenciador de PnP, dos drivers de barramento e dos drivers de função e filtro na enumeração e configuração de um novo dispositivo.

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

A figura a seguir mostra as primeiras etapas na configuração do dispositivo, começando de quando o usuário conecta o hardware ao computador.

diagrama ilustrando a enumeração e o relatório de um dispositivo plug-and-play.

As anotações a seguir correspondem aos números circulados na figura anterior:

  1. Um usuário conecta um dispositivo PnP a um slot gratuito em um barramento PnP.

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

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

    A forma como o driver determina isso depende da arquitetura do barramento. Para alguns ônibus, o driver de função de barramento recebe uma notificação de hot-plug de novos dispositivos. Se o barramento não der suporte à notificação de hot-plug, o usuário deverá tomar as medidas apropriadas em Painel de Controle para fazer com que o barramento seja enumerado.

    Neste exemplo, o barramento USB dá suporte à notificação de hot-plug para que o driver de função do 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 de que seu conjunto de dispositivos filho foi alterado.

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

  4. O gerente do PnP consulta os motoristas do ônibus para obter a lista atual de dispositivos no barramento.

    O gerenciador PnP envia uma solicitação de IRP_MN_QUERY_DEVICE_RELATIONS para a pilha de dispositivos para o 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 manipula o IRP, se apropriado, e passa o IRP para o próximo driver.

  5. O driver de função para o dispositivo de barramento manipula o IRP.

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

    Neste exemplo, o driver do hub USB manipula esse IRP para o FDO do hub. O driver de 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 de host USB) conclui o IRP, o IRP faz backup da pilha do dispositivo por meio de qualquer rotina IoCompletion registrada pelos drivers do hub.

Observe que o driver de 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 ônibus. Normalmente, o driver de função de barramento é o único driver a lidar com o IRP e relatar filhos. Em algumas pilhas de dispositivos, um driver de filtro de barramento está presente e participa na construção da lista de relações de ônibus. Um exemplo é a ACPI, que é anexada como um driver de filtro de barramento para dispositivos ACPI. Em algumas pilhas de dispositivos, os drivers de filtro nãobus 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 foi 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.

diagrama ilustrando a criação de um devnode para um novo dispositivo plug and play.

As anotações a seguir correspondem aos números circulados na figura anterior:

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

    O gerente do PnP compara a lista de relações de ônibus retornadas no IRP IRP_MN_QUERY_DEVICE_RELATIONS com a lista de filhos do ônibus 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 do hub USB pai, que criou o PDO do joystick. Todos os drivers de filtro de barramento opcionais também estariam presentes na pilha do dispositivo, mas o exemplo omite os drivers de filtro de barramento para simplificar.

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

  2. O gerenciador PnP coleta informações sobre o novo dispositivo e começa a configurar o dispositivo.

    O gerenciador de PnP envia uma sequência de IRPs para a pilha do dispositivo 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 os DOs de filtro para quaisquer drivers de filtro de barramento opcionais. Portanto, os motoristas de motorista de ônibus e de filtro de ônibus são os únicos motoristas que respondem a esses IRPs. Neste exemplo, o único driver na pilha de dispositivos joystick é o driver de barramento pai, o driver do hub USB.

    O gerenciador PnP coleta informações sobre um novo dispositivo enviando IRPs para a pilha de dispositivos. Esses IRPs incluem o seguinte:

    O gerenciador de PnP envia os IRPs listados acima nesta fase de processamento de um novo dispositivo PnP, mas não necessariamente na ordem listada, portanto, 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 gerenciador PnP envia apenas os IRPs listados acima.

    O gerenciador PnP verifica o registro para determinar se o dispositivo foi instalado nesse computador anteriormente. O gerenciador PnP verifica se há uma <subchave enumerador>\<deviceID> para o dispositivo no branch Enum . Neste exemplo, o dispositivo é novo e deve ser configurado "do zero".

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

    O branch Enum do registro é reservado para uso por componentes do sistema operacional e seu layout está sujeito a alterações. Os gravadores de driver devem usar rotinas do sistema para extrair informações relacionadas a drivers. Não acesse o branch Enum diretamente de um driver. As informações de Enumeração a seguir 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 criará 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 enumerador são realizadas por um motorista de ônibus PnP em parceria com o gerente PnP. Um dispositivo normalmente é enumerado por seu driver de barramento pai, como PCI ou PCMCIA. Alguns dispositivos são enumerados por um driver de filtro de barramento, como ACPI.

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

      Se Capabilities.UniqueID for retornado como TRUE para IRP_MN_QUERY_CAPABILITIES, a ID exclusiva do dispositivo será exclusiva em todo o sistema. Caso contrário, o gerenciador PnP modifica a ID para que ela seja exclusiva 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 as seguintes, se elas foram fornecidas para o dispositivo:

      DeviceDesc – de IRP_MN_QUERY_DEVICE_TEXT

      Localização – de IRP_MN_QUERY_DEVICE_TEXT

      Funcionalidades — os sinalizadores de IRP_MN_QUERY_CAPABILITIES

      UINumber – de IRP_MN_QUERY_CAPABILITIES

      HardwareID – de IRP_MN_QUERY_ID

      CompatibleIDs – de IRP_MN_QUERY_ID

      ContainerID — de IRP_MN_QUERY_ID

      LogConf\BootConfig – de IRP_MN_QUERY_RESOURCES

      LogConf\BasicConfigVector – de IRP_MN_QUERY_RESOURCE_REQUIREMENTS

Neste ponto, o gerenciador PnP está pronto para localizar o driver de função e filtrar drivers para o dispositivo, se houver. (Consulte a figura a seguir.)

diagrama ilustrando a localização de drivers de função e filtro.

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

  1. O gerenciador PnP no modo kernel coordena com o gerenciador PnP do modo de usuário e os componentes de Instalação do modo de usuário para localizar a função e filtrar drivers para o dispositivo, se houver algum.

    O gerenciador PnP no modo kernel enfileira um evento para o gerenciador PnP do modo de usuário, identificando um dispositivo que precisa ser instalado. Depois que um usuário privilegiado faz logon, os componentes do modo de usuário prossseguem com a localização de drivers. Confira a visão geral da instalação do dispositivo Para obter informações sobre os componentes de Instalação e sua função na instalação de um dispositivo.

  2. Os componentes de Instalação do modo de usuário direcionam o gerenciador PnP do modo kernel para carregar a função e filtrar drivers.

    Os componentes do modo de usuário chamam de volta para o modo kernel para que os drivers sejam 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.

diagrama ilustrando a chamada de rotinas adddevice e iniciando o novo dispositivo.

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

  1. Drivers de filtro inferior

    Antes que o driver de funções seja anexado à pilha de dispositivos, o gerenciador PnP processa todos os drivers de filtro inferior. Para cada driver de filtro inferior, o gerenciador PnP chamará a rotina DriverEntry do driver se o driver ainda não estiver carregado. Em seguida, o gerenciador PnP chama a rotina AddDevice do driver. Em sua rotina AddDevice , o driver de filtro cria um objeto de dispositivo de filtro (filter DO) e o anexa à pilha do dispositivo (IoAttachDeviceToDeviceStack). Depois de anexar seu objeto de dispositivo à pilha do dispositivo, o driver será envolvido como um driver para o dispositivo.

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

  2. Driver de função

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

    Neste exemplo, o driver de função para o joystick USB é, na verdade, um par de drivers: o driver de classe HID e o driver de miniclasse HID. Os dois drivers trabalham juntos para servir como o driver de função. O par de driver cria apenas um FDO e o anexa à pilha do dispositivo.

  3. Drivers de filtro superior

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

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

  4. Atribuindo recursos e iniciando o dispositivo

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

    • Atribuindo recursos

      Anteriormente no processo de configuração, o gerenciador de PnP reuniu os requisitos de recursos de hardware para o dispositivo do driver de barramento pai do dispositivo. Depois que o conjunto completo de drivers é carregado para o dispositivo, o gerenciador de PnP envia uma solicitação 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 atribuirá recursos ao dispositivo, se o dispositivo exigir algum, com base nos requisitos do dispositivo e nos recursos disponíveis no momento.

      O gerenciador PnP pode precisar reorganizar as atribuições de recursos de dispositivos existentes para atender às necessidades do novo dispositivo. Essa reatribuição de recursos é chamada de "rebalanceamento". 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 exigem recursos de hardware para que o gerenciador PnP defina a lista de recursos como NULL.

    • Iniciando o dispositivo (IRP_MN_START_DEVICE)

      Depois que o gerenciador PnP atribui recursos ao dispositivo, ele envia um IRP IRP_MN_START_DEVICE para a pilha do dispositivo para direcionar os drivers para iniciar o dispositivo.

    Depois que o dispositivo é iniciado, o gerenciador PnP envia mais três IRPs para os drivers do dispositivo:

    • IRP_MN_QUERY_CAPABILITIES

      Depois que o IRP inicial é concluído com êxito, o gerenciador de PnP envia outra IRP_MN_QUERY_CAPABILITIES IRP para a pilha de dispositivos. Todos os drivers do dispositivo têm a opção de lidar com o IRP. O gerenciador PnP envia esse IRP neste momento, depois que todos os drivers são anexados e o dispositivo é iniciado, pois os drivers de função ou filtro podem precisar acessar o dispositivo para coletar informações de funcionalidade.

    • IRP_MN_QUERY_PNP_DEVICE_STATE

      Esse IRP dá a um driver a oportunidade de, por exemplo, relatar que o dispositivo não deve ser exibido em interfaces do usuário, como 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. Nesse caso, o gerenciador PnP configura cada dispositivo filho.

Usando GUID_PNP_LOCATION_INTERFACE

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

Para implementar essa interface no driver, manipule a IRP_MN_QUERY_INTERFACE IRP com InterfaceType = GUID_PNP_LOCATION_INTERFACE. O driver fornece um ponteiro para uma estrutura 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.