IDs de conexão para dispositivos periféricos SPB-Connected

Antes que um driver possa enviar solicitações de E/S para um dispositivo periférico em um SPB ( barramento periférico simples ), o driver deve abrir uma conexão lógica com o dispositivo. Por meio dessa conexão, o driver pode enviar solicitações de leitura e gravação para transferir dados de e para o dispositivo. Além disso, o driver pode enviar solicitações de controle de E/S (IOCTL) para o dispositivo para executar operações específicas do SPB.

Na inicialização do sistema, o gerenciador de Plug and Play (PnP) enumera dispositivos PnP e dispositivos não PnP. Para um dispositivo periférico não PnP que tem uma conexão fixa com um SPB, o gerenciador PnP consulta o firmware ACPI da plataforma de hardware para obter um conjunto de parâmetros de conexão que descrevem como acessar o dispositivo. Esses parâmetros de conexão identificam o controlador SPB do barramento ao qual o dispositivo está conectado e incluem outras informações, como o endereço do barramento e a frequência do relógio do barramento, que o controlador requer para se comunicar com o dispositivo.

O gerenciador PnP atribui um identificador, chamado de ID de conexão, aos parâmetros de conexão do dispositivo periférico conectado ao SPB. O gerenciador PnP armazena essa ID e os parâmetros de conexão juntos em um armazenamento de dados do sistema chamado hub de recursos. (O hub de recursos é um armazenamento de dados interno no qual o gerenciador PnP armazena informações de configuração sobre um dispositivo periférico conectado ao SPB.) A ID de conexão encapsula esses parâmetros para que o driver não precise fornecê-los explicitamente.

O driver de um dispositivo periférico conectado ao SPB recebe a ID de conexão do dispositivo como parte dos recursos de hardware atribuídos ao driver. Quando o driver do dispositivo periférico chama uma função do sistema para abrir uma conexão com o dispositivo, o driver fornece a ID de conexão, que a função usa para recuperar os parâmetros de conexão do dispositivo do hub de recursos.

O desenvolvedor do driver pode usar o UMDF ( User-Mode Driver Framework ) ou o KMDF ( Kernel-Mode Driver Framework ) para criar o driver para o dispositivo periférico conectado ao SPB. Um driver UMDF recebe seus recursos (que incluem a ID da conexão) quando a estrutura chama o método IPnpCallbackHardware2::OnPrepareHardware do driver. Um driver KMDF recebe seus recursos de hardware durante um retorno de chamada EvtDevicePrepareHardware .

Para permitir que um driver periférico UMDF receba IDs de conexão em sua lista de recursos, o arquivo INF que instala o driver deve incluir a seguinte diretiva em sua seção DDInstall específica do WDF :

UmdfDirectHardwareAccess = AllowDirectHardwareAccess Para obter mais informações sobre essa diretiva, consulte Especificando diretivas WDF em arquivos INF. Para obter um exemplo de um arquivo INX (usado para compilar o arquivo INF correspondente) que usa essa diretiva, consulte o exemplo de driver SpbAccelerometer .

A ID de conexão que o driver recebe como um recurso é um inteiro de 64 bits, mas o driver deve incorporar essa ID em um nome de caminho do dispositivo que pode ser usado para recuperar os parâmetros de conexão do hub de recursos. Para criar o nome do caminho do dispositivo, o driver chama a função RESOURCE_HUB_CREATE_PATH_FROM_ID , que é declarada no arquivo de cabeçalho Reshub.h.

Para abrir uma conexão lógica com o dispositivo periférico conectado ao SPB, um driver UMDF chama o método IWDFRemoteTarget::OpenFileByName e um driver KMDF chama o método WdfIoTargetOpen . Qualquer um dos métodos requer o nome do caminho do dispositivo como um parâmetro de entrada.

Para obter exemplos de código UMDF e KMDF que usam IDs de conexão para abrir conexões lógicas com dispositivos periféricos conectados ao SPB, confira os seguintes tópicos:

Os recursos de hardware para User-Mode recursos de hardware de drivers periféricos do SPB para aplicativos do modo de usuário drivers periféricos do Kernel-Mode SPB não podem abrir conexões lógicas para dispositivos periféricos conectados ao SPB e não podem enviar solicitações de E/S diretamente para esses dispositivos.

Somente um driver pode manter uma conexão lógica aberta com um dispositivo periférico conectado ao SPB por vez. Falha na tentativa de outro driver de abrir uma segunda conexão com o mesmo dispositivo.