Inicializando um driver de protocolo
O sistema chama a rotina DriverEntry de um driver de protocolo depois de carregar o driver. Os drivers de protocolo são carregados como serviços do sistema. Eles podem carregar a qualquer momento antes, durante ou após o carregamento dos drivers de miniport.
Os drivers de protocolo alocam recursos do driver e registram funções ProtocolXxx no DriverEntry. Isso inclui clientes CoNDIS e gerentes de chamadas autônomos. Para registrar suas funções ProtocolXxx com NDIS, um driver de protocolo chama a função NdisRegisterProtocolDriver .
DriverEntry retornará STATUS_SUCCESS ou seu NDIS_STATUS_SUCCESS equivalente, se o driver registrado como um driver de protocolo NDIS tiver êxito. Se DriverEntry falhar na inicialização propagando um erro status que foi retornado por uma função NdisXxx ou por uma rotina de suporte no modo kernel, o driver não permanecerá carregado. DriverEntry deve ser executado de forma síncrona; ou seja, ele não pode retornar STATUS_PENDING ou seu NDIS_STATUS_PENDING equivalente.
A função DriverEntry de um driver de protocolo NDIS deve chamar a função NdisRegisterProtocolDriver . Para registrar os pontos de entrada ProtocolXxx do driver com a biblioteca NDIS, um driver de protocolo inicializa uma estrutura NDIS_PROTOCOL_DRIVER_CHARACTERISTICS e a passa para NdisRegisterProtocolDriver.
Os drivers que chamam NdisRegisterProtocolDriver devem estar preparados para uma chamada imediata para qualquer uma de suas funções ProtocolXxx.
Os drivers de protocolo NDIS fornecem as seguintes funções ProtocolXxx , que são versões atualizadas das funções que os drivers herdados fornecem:
ProtocolCloseAdapterCompleteEx
Os drivers de protocolo NDIS fornecem as seguintes funções ProtocolXxx para operações de envio e recebimento:
ProtocolSendNetBufferListsComplete
Todos os tipos de drivers de protocolo NDIS devem registrar funções ProtocolBindAdapterEx e ProtocolUnbindAdapterEx totalmente funcionais para dar suporte a Plug and Play (PnP). Em geral, uma função DriverEntry deve chamar NdisRegisterProtocolDriver imediatamente antes de retornar o controle com um valor status de STATUS_SUCCESS ou NDIS_STATUS_SUCCESS.
Qualquer driver de protocolo que exporta um conjunto de rotinas padrão de driver no modo kernel, além de suas funções ProtocolXxx definidas pelo NDIS, deve definir os pontos de entrada para essas rotinas de driver no objeto driver fornecido que é passado para sua função DriverEntry . Para obter mais informações sobre a funcionalidade da função DriverEntry de um driver de protocolo, consulte Escrevendo uma rotina driverEntry.
Se uma tentativa de alocar recursos que o driver precisa para executar operações de E/S de rede falhar, o DriverEntry deverá liberar todos os recursos já alocados antes de retornar o controle com um status diferente de STATUS_SUCCESS ou NDIS_STATUS_SUCCESS.
Se ocorrer um erro após uma chamada bem-sucedida para NdisRegisterProtocolDriver, o driver deverá chamar a função NdisDeregisterProtocolDriver antes que DriverEntry retorne.
Para permitir que um driver de protocolo configure serviços opcionais, o NDIS chama a função ProtocolSetOptions no contexto da chamada do driver de protocolo para NdisRegisterProtocolDriver. Para obter mais informações sobre serviços opcionais, consulte Configurando serviços opcionais de driver de protocolo.
Os drivers de cliente coNDIS devem chamar a função NdisSetOptionalHandlers da função ProtocolSetOptions . O driver inicializa uma estrutura NDIS_CO_CLIENT_OPTIONAL_HANDLERS e a passa no parâmetro OptionalHandlers de NdisSetOptionalHandlers.
Os gerenciadores de chamadas autônomos do CoNDIS também devem chamar a função NdisSetOptionalHandlers da função ProtocolSetOptions . O driver inicializa uma estrutura NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS e a passa no parâmetro OptionalHandlers de NdisSetOptionalHandlers.
OS MCMs não são drivers de protocolo. Portanto, eles devem chamar a função NdisSetOptionalHandlers da função MiniportSetOptions . O MCM inicializa uma estrutura NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS e a passa no parâmetro OptionalHandlers de NdisSetOptionalHandlers.
Para cancelar o registro com o NDIS, um driver de protocolo chama NdisDeregisterProtocolDriver de sua rotina de descarregamento .
Para executar operações de limpeza antes que um driver de protocolo seja desinstalado, um driver de protocolo pode registrar uma função ProtocolUninstall . A função ProtocolUninstall é opcional. Por exemplo, a borda inferior do protocolo de um driver intermediário pode exigir uma função ProtocolUninstall . O driver intermediário pode liberar seus recursos de borda de protocolo no ProtocolUninstall antes que o NDIS chame sua função MiniportDriverUnload .