Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O sistema chama a rotina DriverEntry de um protocolo de driver depois que o sistema carrega o driver. Os drivers de protocolo são carregados como serviços do sistema. Eles podem ser carregados a qualquer momento antes, durante ou após o carregamento dos drivers de miniporta.
Os drivers de protocolo alocam recursos de controlador e registram funções de ProtocolXxx no DriverEntry. Isso inclui clientes CoNDIS e gerentes de chamadas autônomos. Para registrar as suas funções ProtocolXxx com NDIS, um driver de protocolo chama a função NdisRegisterProtocolDriver.
O DriverEntry retorna STATUS_SUCCESS, ou o seu equivalente NDIS_STATUS_SUCCESS, se o driver for registado como um driver de protocolo NDIS com êxito. Se o DriverEntry falhar a inicialização ao propagar um estado de erro que foi retornado por uma função NdisXxx ou por uma rotina de suporte em modo kernel, o driver não permanecerá carregado. DriverEntry deve ser executado de forma síncrona; ou seja, não pode retornar STATUS_PENDING ou o seu equivalente NDIS_STATUS_PENDING.
A função DriverEntry de um driver de protocolo NDIS deve chamar a função NdisRegisterProtocolDriver. Para registar os pontos de entrada do driver ProtocolXxx com a biblioteca NDIS, um driver de protocolo inicializa uma estrutura NDIS_PROTOCOL_DRIVER_CHARACTERISTICS e passa-a 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 fornecidas pelos drivers herdados:
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 totalmente funcionais ProtocolBindAdapterEx e funções de ProtocolUnbindAdapterEx para suportar Plug and Play (PnP). Em geral, uma função DriverEntry deve chamar NdisRegisterProtocolDriver imediatamente antes de retornar o controlo com um valor de estado de STATUS_SUCCESS ou NDIS_STATUS_SUCCESS.
Qualquer driver de protocolo que exporte um conjunto de rotinas de driver de modo kernel padrão, além de suas funções de ProtocolXxx definidas pelo NDIS, deve definir os pontos de entrada para essas rotinas de driver no objeto de driver específico que é passado para sua função DriverEntry. Para obter mais informações sobre a funcionalidade da função de DriverEntry do de um driver de protocolo, consulte Writing a DriverEntry Routine.
Se uma tentativa de alocar recursos de que o driver precisa para realizar operações de E/S de rede falhar, 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 a função NdisRegisterProtocolDriver, o driver deve 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 de driver de protocolo opcional.
Os drivers de cliente CoNDIS devem chamar a função NdisSetOptionalHandlers da funçãoProtocolSetOptions. O driver inicializa uma estrutura NDIS_CO_CLIENT_OPTIONAL_HANDLERS e a passa para o parâmetro OptionalHandlers de NdisSetOptionalHandlers.
Os gestores de chamadas autónomos do CoNDIS também devem chamar a função NdisSetOptionalHandlers da função ProtocolSetOptions. O driver inicializa a estrutura NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS e passa-a como parâmetro OptionalHandlers de NdisSetOptionalHandlers.
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 passa-a para o parâmetro OptionalHandlers de NdisSetOptionalHandlers.
Para anular o registo no NDIS, um driver de protocolo chama NdisDeregisterProtocolDriver da sua rotina Unload.
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 requerer uma função ProtocolUninstall. O driver intermediário pode liberar os recursos de borda de protocolo em ProtocolUninstall antes de o NDIS chamar a sua função MiniportDriverUnload.