Ler em inglês

Compartilhar via

Dispatch(Internal)DeviceControl em drivers de classe/porta

  • Artigo

O driver de nível superior de um par de classe/porta às vezes pode concluir IRPs em sua rotina DispatchDeviceControl . Por exemplo, um driver de classe poderia, durante a inicialização, coletar e armazenar informações sobre os recursos do dispositivo subjacente, que podem ser procurados em uma solicitação de IRP_MJ_DEVICE_CONTROL subsequente e, portanto, economizar tempo de processamento atendendo à solicitação sem passá-la para o driver de dispositivo subjacente. Um driver de classe também pode ser projetado para marcar os parâmetros do IRP e enviar somente solicitações com parâmetros válidos para o driver de porta.

Drivers de classe/porta estreitamente acoplados também podem definir um conjunto de códigos de controle de E/S internos específicos do driver ou específicos do dispositivo que o driver de classe pode usar para IRP_MJ_INTERNAL_DEVICE_CONTROL solicitações para o driver de porta.

Por exemplo, as rotinas DispatchCreateClose no teclado do sistema e drivers de classe de mouse enviam solicitações de controle de dispositivo internas definidas pelo sistema para habilitar ou desabilitar interrupções de teclado e mouse para os drivers de porta subjacentes. Esses drivers de classe do sistema configuram IRP_MJ_INTERNAL_DEVICE_CONTROL solicitações para um driver de porta subjacente. Qualquer novo driver de porta do mouse ou teclado que interopere com esses drivers de classe do sistema também deve dar suporte a essas solicitações de controle de dispositivo internas públicas.

O modelo de driver de porta/classe paralela do sistema tem recursos semelhantes. Novos drivers de classe paralela podem obter suporte do driver de porta paralela do sistema configurando IRPs para solicitações de IRP_MJ_INTERNAL_DEVICE_CONTROL com códigos de controle públicos IOCTL_PARALLEL_PORT_XXX . Você pode substituir o driver de porta paralela do sistema, mas qualquer novo driver também deve dar suporte a esse conjunto de solicitações de controle de dispositivo internas públicas.

Para obter mais informações sobre essas solicitações de controle de dispositivo internas públicas, consulte a documentação específica do dispositivo no WDK (Kit de Driver do Windows). Para obter informações sobre como definir códigos de controle de E/S privados, consulte Usando códigos de controle de E/S.

Para um par estreitamente acoplado de drivers de porta/classe, o driver de classe pode lidar com o processamento de determinadas solicitações de controle de dispositivo sem passá-las para o driver de porta. Em um novo par de driver de classe/porta, a rotina DispatchDeviceControl do driver de classe pode fazer o seguinte:

  • Verifique a validade dos parâmetros em seu próprio local de pilha de E/S, defina o bloco de status de E/S se encontrar erros de parâmetro e chame IoCompleteRequest com um PriorityBoost de IO_NO_INCREMENT; caso contrário, chame IoGetNextIrpStackLocation para copiar seu próprio local de pilha de E/S para o driver de porta e passe o IRP com IoCallDriver.

  • Ou não faça nada além de configurar o local da pilha de E/S do driver de porta no IRP sem verificar parâmetros e passá-lo para o driver de porta para processamento.

Os drivers de classe SCSI têm requisitos especiais para lidar com solicitações de controle de dispositivo. Para obter mais informações sobre esses requisitos, consulte Drivers de armazenamento.