Intermediate Drivers

9/8/2008

A arquitetura NDIS suporta intermediário drivers. Um intermediário NDIS driver não usa funções NDIS para hardware adaptador controle. Em vez disso, ele existe no parte superior de outro driver, such as o serial driver. A em camadas driver modelo representa um tipo especial de intermediário driver que existe em parte superior de um driver de miniporta NDIS. Uma em camadas driver de miniporta expõe uma interface de miniporta para o driver protocolo sobrejacente e um protocolo-interface driver para o subjacente miniporta. Em uma em camadas estrutura driver de miniporta, o driver protocolo se comunica com um driver de miniporta na inferior de em camadas driver de miniporta. Uma em camadas exportações driver de miniporta MiniportaXXX funções em seu borda superior e ProtocoloXXX funções em seu borda inferior.

A seguinte ilustração mostra a em camadas arquitetura driver de miniporta NDIS.

Drivers de miniporta em camadas podem ser usados para filtro certos pacotes de saída ou para executar outras funções especiais, such as a descriptografia e criptografar dados.

Uma em camadas driver de miniporta mantém duas interfaces: Uma interface driver de miniporta fornecido para drivers protocolo e uma interface driver protocolo fornecidos para subjacente miniportas. Use as diretrizes driver NDIS protocolo quando compilação a em camadas interface driver protocolo de miniporta. Use as diretrizes driver de miniporta NDIS quando compilação a em camadas interface driver de miniporta da miniporta; No entanto, a em camadas miniporta geralmente usará o intermediário funções driver, NdisIMXXXe não o padrão de miniporta funções, NdisMXXX.

A seguinte tabela mostra um conjunto de novas funções biblioteca NDIS. Aplicar essas funções para intermediário drivers, assim as to em camadas arquiteturas driver de miniporta.

Função	Descrição
NdisIMRegisterLayeredMiniport	Registra um intermediário do driver MiniportaXXX entrada pontos e o nome com a biblioteca NDIS quando o driver é inicializado.
NdisIMInitializeDeviceInstance	Chama um intermediário NDIS do driver MiniportInitialize função para configurar adaptador rede virtual do driver para operações E/S em um subjacente driver adaptador rede à qual o intermediário driver está ligado.
NdisIMInitializeDeviceInstanceEx	Chama um intermediário NDIS do driver MiniportInitialize função para inicializar adaptador rede virtual do driver e, opcionalmente, para configurar o informações do estado sobre adaptador rede virtual do driver subseqüentemente ligado protocolos.
NdisIMDeInitializeDeviceInstance	Chama um intermediário NDIS do driver MiniportHalt função para subdividir adaptador rede virtual do driver.
NdisIMGetDeviceContext	Permite que um intermediário NDIS do driver MiniportInitialize função para acessar a área contexto dispositivo que está alocado pelo seu ProtocolBindAdapter função.

Qualquer NDIS intermediário ou em camadas driver de miniporta que exporta ambos MiniportaXXX e ProtocoloXXX funções geralmente configura uma estrutura características e chamadas de NdisIMRegisterLayeredMiniport função de seu DriverEntry função após DriverEntry Chamadas de NdisMInitializeWrapper função. Essa estrutura é copiada na NdisIMRegisterLayeredMiniport solicitação para o armazenamento interno da biblioteca de NDIS. Portanto, depois que ele tenha registrado, tal um driver não é possível alteração suas funções manipulador. Um intermediário driver pode chamar o NdisMRegisterMiniport função, em vez da NdisIMRegisterLayeredMiniport função, se ele está preparado para um chamar imediata para o MiniportInitialize função.

NDIS intermediário de drivers e o gerenciamento de energia

Windows CE .NET 4.0 introduziu suporte para Network Driver Interface Specification (NDIS) versão 5.1. Isso inclui o wake - on - recurso LAN que implementa OIDs Wake-specific e estado de energia D3. Para obter mais informações, consulte Plug and Play and Power Management Object Identifiers e Power Manager Requests and NDIS.

Nesse design, o driver protocolo TCPIP pode optar por enviar um objeto OID_PNP_ADD_WAKE_UP_PATTERN informar o subjacente miniporta quando a ativação automática. Portanto, NDIS registra os drivers com o Power Manager. O seguinte exemplo mostra como o NDIS GUID é definido em % _WINCEROOT%\PUBLIC\COMMON\SDK\INC\cedrv_guid.h:

#define CE_DRIVER_POWER_MANAGEABLE_NDIS_GUID        TEXT("{98C5250D-C29A-4985-AE5F-AFE5367E5006}")

O Windows Driver Development Kit atMSDN descreve como criar um intermediário NDIS driver filtro. Com o versão de Windows desse driver, você pode ocultar o intermediário driver da interface de usuário Windows. Isso é feito no área de trabalho através de configuração o sinalizador NCF_HIDDEN no arquivo .inf para o intermediário driver.

Windows Embedded CE não oferece esse sinalizador. Portanto, o Power Manager (PM) detecta dois o intermediário driver e o subjacente driver de miniporta. Inversamente, NDISUIO apenas detecta o intermediário driver. No entanto, as especificações de como um intermediário gerenciamento de energia alças driver são idênticos. Isso faz com que conseqüências não intencionais.

Para instâncias de intermediário drivers, o convenção de nomenclatura requer que você anexar o subjacente miniporta Nome:

<Intermediate_Driver>\<Underlying_Miniport_Driver>

De exemplo, um intermediário driver deve ser registrado da seguinte maneira:

{98C5250D-C29A-4985-AE5F-AFE5367E5006}\PASS\NETCARD  

Problemas com Drivers intermediárias de gerenciamento de energia e NDIS

Após o intermediário driver é inicializado, ele recebe uma consulta de OID_PNP_CAPABILITIES. A documentação do DDK naMSDN indica que o intermediário driver não deve transmitir para baixo as OIDs que são direcionar os mapeamentos de IRPs PM. Esses OIDs incluem OID_PNP_QUERY_POWER e OID_PNP_SET_POWER. Portanto, os blocos corretamente PASSTHRU exemplo driver essas consultas para seu subjacente driver de miniporta. No entanto, um intermediário driver para Windows Embedded CE deve responder a essas duas consultas de uma maneira específica. Se o intermediário driver passado para baixo esses OIDs, no entanto, ele pode resultar em envio duplicado e mesmo conflitantes de OIDs para o físico adaptador.

Para o OID_PNP_CAPABILITIES consulta, se o intermediário driver retorna NDIS_STATUS_SUCCESS, isso irá resultar em dois adaptadores gerenciáveis de energia que estão registrados para o Power Manager. No entanto, somente o subjacente adaptador está realmente gerenciado de energia. Atualmente, não há nenhum mecanismo para diferenciar um driver filtro de driver MUX. Portanto, o usuário pode detecção 1 + n instâncias de adaptadores gerenciáveis de energia.

Essa pode causar confusão quando o GetDevicePower ou SetDevicePower funções são usadas, e o chamador pressupõe que os nomes de NDIS e PM são idênticos. O OID_PNP_CAPABILITIES consulta e o exemplo PASSTHRU Ambas retornam NDIS_STATUS_SUCCESS quando ambos os nomes instância são consultados. No entanto, o código de retorno de sucesso de um intermediário driver não alteração de estado de energia do subjacente adaptador. Portanto, um usuário pode interpretar que o subjacente driver é desligado quando for realmente ainda execução na energia total.

Recomendações para o gerenciamento de energia e NDIS drivers intermediárias

Para endereço os problemas descritos nos parágrafos anteriores, a seguinte lista fornece recomendações para ativar um intermediário NDIS driver para trabalho corretamente com Power Manager.

• Um intermediário driver deve indicar conjunto DisablePowerManagement no Registro. Para obter mais informações sobre essa configuração Registro, consulte TCP/IPv4 and TCP/IPv6 Common Registry Settings. Quando isso é definido, NDIS não irá registrar o instância de adaptador virtual ou o intermediário instâncias driver para o Power Manager.

• Um intermediário driver deve precisamente relatório o OID_PNP_CAPABILITIES do subjacente driver de miniporta para o qual ele vincula. Este será habilitar Wake-on LAN requisitos a serem passados para o subjacente driver de miniporta.

• Após capacidades de relatório do subjacente driver de miniporta, um intermediário driver deve passagem de Power Management OIDs que ele recebe: OID_PNP_ENABLE_WAKE_UP, OID_PNP_WAKE_UP_PATTERN e assim por diante. Ele não deve passagem OID_PNP_QUERY_POWER e OID_PNP_SET_POWER, de acordo com o DDK.

• Um intermediário driver deve chamar NdisIMNotifyPnPEvent quando seu manipulador PnP driver protocolo recebe uma rede evento. Por chamado essa função, drivers protocolo camada superior podem detecção uma alteração de energia adaptador do subjacente driver de miniporta que o filtro / S proxy driver. Iniciar em Windows Embedded CE 6.0, NDIS também passa até a NetEventSetPower evento.

• Aplicativos devem usar a função RequestDeviceNotifications para enumerar os drivers NDIS gerenciáveis de energia. Chamadas para a função SetDevicePower devem ser feitas para o subjacente adaptador, qual será alteração de estado de energia.

• Iniciar em CE 6.0, recomendamos que um intermediário driver conjunto a FilterDriver entrada Registro para que o utilitário rede aplicativo precisamente será identificá-lo. O driver também deve identificar seu UnderlyingAdapterName no Registro. Isso permite que o utilitário rede software aplicativo para identificar o driver de miniporta Real ele controla com precisão. A seguinte é um exemplo de uma entrada Registro:

      [HKLM\Comm\PASS\PCCARD\NE20001]        " FilterDriver"=dword:1         " UnderlyingAdapterName"="PCCARD\\NE20001" 
  

• Em versões anteriores, emitir um bloqueio ocorreu no exemplo de PASSTHRU quando executou operações ligação no seu manipulador BIND. Este emitir não ocorrer em CE 6.0.

See Also

Concepts

Miniports, Intermediate Drivers, and Protocol Drivers
NDIS Driver Upper-Edge Functions
NDIS Protocol Driver Lower-Edge Functions