Uso de Avc.sys

  • Artículo

Una vez que Windows carga e inicializa Avc.sys, Avc.sys usa comandos estándar de unidad AV/C y subunidad para detectar las subunidades activas en todos los dispositivos AV/C conectados al bus IEEE 1394 (incluidas las subunidades virtuales cuando el equipo es una unidad AV/C virtual). Avc.sys luego genera identificadores de dispositivo (identificadores) para todas las subunidades activas. A continuación, Avc.sys usa mecanismos de Plug and Play estándar (PnP) para cargar el controlador de subunidad adecuado para cada subunidad. El controlador de subunidad que se va a cargar se selecciona en función del archivo INF que instala el controlador de subbúnit y el identificador del dispositivo de la subunidad, tal y como se genera mediante Avc.sys y se describe en Identificadores de dispositivo AV/C. El identificador del dispositivo se genera a partir de la información de unidad del dispositivo AV/C, en combinación con los campos SubunitType y SubunitID de la subunidad. El controlador que admite una subunidad puede ser específico del proveedor o puede ser genérico para el tipo de subunidad. Por ejemplo, el controlador de subunidad para la mayoría de las videocámaras DV es el Msdv.sysproporcionado por Microsoft.

Los controladores de subbúnit se comunican con Avc.sys a través del mecanismo estándar basado en IRP empleado por todos los controladores basados en la arquitectura WDM. Un controlador de subunidad se comunica con su subunidad av/C mediante la asignación y el envío de IRP a la pila de controladores al controlador de protocolo AV/C, Avc.sys. Para realizar solicitudes de E/S, incluya el archivo de encabezado Avc.h, que se incluye con el Kit de controladores de Microsoft Windows (WDK).

Un controlador de subunidad asigna e inicializa los IRP que va a procesar Avc.sys. Un controlador de subunidad establece el miembro Parameters.DeviceIoControl.IoControlCode del IRP en el IOCTL que corresponde a la operación de AV/C deseada.

Avc.sys registra una de las dos interfaces de dispositivo, dependiendo de la pila de controladores de subunidad que se cargó para admitir (del mismo nivel o virtual). Estas interfaces definen la funcionalidad que Avc.sys exportaciones de controladores de subunidad, otros controladores y aplicaciones que se van a usar. Avc.sys , a continuación, cambia el estado de la interfaz a habilitado o deshabilitado según el estado PnP del controlador.

Avc.sys registra una nueva instancia de GUID_AVC_CLASS si se cargó para proporcionar compatibilidad con subunidades externas de AV/C (la pila del mismo nivel). Esta interfaz solo admite el siguiente código de control de E/S (IOCTL):

IOCTL_AVC_CLASS a su vez admite varios códigos de función. Se garantiza que los controladores secundarios de instancias de Avc.sys admitan las subunidades del mismo nivel tengan acceso a esta interfaz a través de su objeto de dispositivo primario.

La interfaz GUID_AVC_CLASS admite todos los códigos de función IOCTL_AVC_CLASS, aunque algunas tienen limitaciones en su uso, tal como se describe en las páginas de referencia de cada función.

Avc.sys registra una nueva instancia de GUID_VIRTUAL_AVC_CLASS, si se cargó, para proporcionar compatibilidad con subunidades virtuales de AV/C (la pila virtual). Esta interfaz admite cuatro códigos de control de E/S (IOCTL):

La interfaz GUID_VIRTUAL_AVC_CLASS no admite todos los IOCTL_AVC_CLASS código de función. La página de referencia de cada código de función individual especifica si se admite para GUID_VIRTUAL_AVC_CLASS instancias de Avc.sys.

IOCTL_AVC_CLASS IRP solo se admiten en modo kernel (normalmente para la comunicación entre controladores) a través de IRP_MJ_INTERNAL_DEVICE_CONTROL. Por lo tanto, las aplicaciones no pueden acceder directamente a las funciones proporcionadas por el código IOCTL_AVC_CLASS IOCTL.

Los tres últimos códigos IOCTL se admiten tanto en modo kernel como en modo de usuario a través de IRP_MJ_DEVICE_CONTROL. Esto significa que las aplicaciones pueden enviar estas ICTL directamente a Avc.sys.

El IOCTL_AVC_CLASS código IOCTL siempre debe ir acompañado de un bloque de solicitud de E/S (IRB), que describe aún más la operación de AV/C que se va a realizar. El encabezado IRB incluye un número de función, que determina la estructura del resto del IRB. La estructura y el tamaño de IRB varían según la función . Avc.sys usa dos IRB personalizados:

La elección de qué IRB debe usar un controlador de subunidad depende de la función deseada. Para obtener más información sobre los códigos de función de IOCTL_AVC_CLASS compatibles con Avc.sys, consulte Códigos de función del controlador del protocolo AV/C.

La función principal de AV/C que usan los controladores de subbúnit es AVC_FUNCTION_COMMAND, que usa la estructura AVC_COMMAND_IRB. AVC_FUNCTION_COMMAND envía solicitudes de AV/C y recibe las respuestas de AV/C correspondientes. Los detalles para compilar comandos de AV/C se controlan mediante Avc.sys, pero el controlador de subunidad debe proporcionar el código de operación av/C y los operandos de cada comando.