Inicialización de un controlador de protocolo
El sistema llama a la rutina DriverEntry de un controlador de protocolo después de cargar el controlador. Los controladores de protocolo se cargan como servicios del sistema. Pueden cargarse en cualquier momento antes, durante o después de cargar los controladores de minipuerto.
Los controladores de protocolo asignan recursos de controlador y registran las funciones ProtocolXxx en DriverEntry. Esto incluye clientes de CoNDIS y administradores de llamadas independientes. Para registrar sus funciones ProtocolXxx con NDIS, un controlador de protocolo llama a la función NdisRegisterProtocolDriver .
DriverEntry devuelve STATUS_SUCCESS, o su NDIS_STATUS_SUCCESS equivalente, si el controlador se registró como controlador de protocolo NDIS correctamente. Si DriverEntry produce un error al inicializar mediante la propagación de un estado de error devuelto por una función NdisXxx o por una rutina de soporte técnico en modo kernel, el controlador no permanecerá cargado. DriverEntry debe ejecutarse sincrónicamente; es decir, no puede devolver STATUS_PENDING ni su NDIS_STATUS_PENDING equivalente.
La función DriverEntry de un controlador de protocolo NDIS debe llamar a la función NdisRegisterProtocolDriver . Para registrar los puntos de entrada ProtocolXxx del controlador con la biblioteca NDIS, un controlador de protocolo inicializa una estructura de NDIS_PROTOCOL_DRIVER_CHARACTERISTICS y la pasa a NdisRegisterProtocolDriver.
Los controladores que llaman a NdisRegisterProtocolDriver deben estar preparados para una llamada inmediata a cualquiera de sus funciones ProtocolXxx.
Los controladores de protocolo NDIS proporcionan las siguientes funciones ProtocolXxx , que son versiones actualizadas de las funciones que proporcionan los controladores heredados:
ProtocolCloseAdapterCompleteEx
Los controladores de protocolo NDIS proporcionan las siguientes funciones ProtocolXxx para las operaciones de envío y recepción:
ProtocolSendNetBufferListsComplete
Todos los tipos de controladores de protocolo NDIS deben registrar funciones ProtocolBindAdapterEx y ProtocolUnbindAdapterEx totalmente funcionales para admitir Plug and Play (PnP). En general, una función DriverEntry debe llamar a NdisRegisterProtocolDriver inmediatamente antes de que devuelva el control con un valor de estado de STATUS_SUCCESS o NDIS_STATUS_SUCCESS.
Cualquier controlador de protocolo que exporte un conjunto de rutinas estándar del controlador en modo kernel además de sus funciones ProtocolXxx definidas por NDIS debe establecer los puntos de entrada para esas rutinas de controlador en el objeto de controlador dado que se pasa a su función DriverEntry . Para obtener más información sobre la funcionalidad de esta función DriverEntry del controlador de protocolo, vea Escribir una rutina DriverEntry.
Si se produce un error en un intento de asignar recursos que el controlador necesita para realizar operaciones de E/S de red, DriverEntry debe liberar todos los recursos que ya asignó antes de devolver el control con un estado distinto de STATUS_SUCCESS o NDIS_STATUS_SUCCESS.
Si se produce un error después de una llamada correcta a NdisRegisterProtocolDriver, el controlador debe llamar a la función NdisDeregisterProtocolDriver antes de que Se devuelva DriverEntry .
Para permitir que un controlador de protocolo configure servicios opcionales, NDIS llama a la función ProtocolSetOptions en el contexto de la llamada del controlador de protocolo a NdisRegisterProtocolDriver. Para obtener más información sobre los servicios opcionales, consulte Configuración de servicios opcionales de controlador de protocolo.
Los controladores de cliente de CoNDIS deben llamar a la función NdisSetOptionalHandlers desde la función ProtocolSetOptions . El controlador inicializa una estructura de NDIS_CO_CLIENT_OPTIONAL_HANDLERS y la pasa en el parámetro OptionalHandlers de NdisSetOptionalHandlers.
Los administradores de llamadas independientes de CoNDIS también deben llamar a la función NdisSetOptionalHandlers desde la función ProtocolSetOptions . El controlador inicializa una estructura de NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS y la pasa en el parámetro OptionalHandlers de NdisSetOptionalHandlers.
Los MCM no son controladores de protocolo. Por lo tanto, deben llamar a la función NdisSetOptionalHandlers desde la función MiniportSetOptions . McM inicializa una estructura de NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS y la pasa en el parámetro OptionalHandlers de NdisSetOptionalHandlers.
Para anular el registro con NDIS, un controlador de protocolo llama a NdisDeregisterProtocolDriver desde su rutina De descarga .
Para realizar operaciones de limpieza antes de desinstalar un controlador de protocolo, un controlador de protocolo puede registrar una función ProtocolUninstall . La función ProtocolUninstall es opcional. Por ejemplo, el borde inferior del protocolo de un controlador intermedio podría requerir una función ProtocolUninstall . El controlador intermedio puede liberar sus recursos perimetrales de protocolo en ProtocolUninstall antes de que NDIS llame a su función MiniportDriverUnload .