Utilisation de Avc.sys

  • Article

Une fois que Windows a chargé et initialisé Avc.sys, Avc.sys utilise les commandes standard d’unité av/C et de sous-unité pour découvrir les sous-unités actives sur tous les appareils AV/C connectés au bus IEEE 1394 (y compris les sous-unités virtuelles lorsque l’ordinateur est une unité AV/C virtuelle). Avc.sys génère ensuite des identificateurs d’appareil (ID) pour toutes les sous-unités actives. Ensuite, Avc.sys utilise des mécanismes de Plug-and-Play standard (PnP) pour charger le pilote de sous-unité approprié pour chaque sous-unité. Le pilote de sous-unité à charger est sélectionné en fonction du fichier INF qui installe le pilote de sous-unité et de l’identificateur d’appareil de la sous-unité, tel que généré par Avc.sys et décrit dans ID d’appareil AV/C. L’identificateur d’appareil est généré à partir des informations d’unité de l’appareil AV/C, en combinaison avec les champs SubunitType et SubunitID de la sous-unité. Le pilote qui prend en charge une sous-unité peut être spécifique au fournisseur ou il peut être générique pour le type de sous-unité. Par exemple, le pilote de sous-unité pour la plupart des caméscopes DV est le Msdv.sysfourni par Microsoft .

Les pilotes de sous-unités communiquent avec Avc.sys via le mécanisme IRP standard utilisé par tous les pilotes basés sur l’architecture WDM. Un pilote de sous-unité communique avec sa sous-unité AV/C en allouant et en envoyant des IIP dans la pile de pilotes vers le pilote de protocole AV/C, Avc.sys. Pour effectuer des demandes d’E/S, incluez le fichier d’en-tête Avc.h, qui est fourni avec le Kit de pilotes Microsoft Windows (WDK).

Un pilote de sous-unité alloue et initialise les IRPs à traiter par Avc.sys. Un pilote de sous-unité définit le membre Parameters.DeviceIoControl.IoControlCode de l’IRP sur le IOCTL qui correspond à l’opération AV/C souhaitée.

Avc.sys inscrit l’une des deux interfaces d’appareil, en fonction de la pile de pilotes de sous-unité pour laquelle il a été chargé pour prendre en charge (homologue ou virtuel). Ces interfaces définissent les fonctionnalités que Avc.sys exportent pour les pilotes de sous-unités, d’autres pilotes et les applications à utiliser. Avc.sys modifie ensuite l’état de l’interface sur activé ou désactivé en fonction de l’état PnP du pilote.

Avc.sys inscrit un nouveau instance de GUID_AVC_CLASS s’il a été chargé pour assurer la prise en charge des sous-unités AV/C externes (pile d’homologues). Cette interface prend uniquement en charge le code de contrôle d’E/S (IOCTL) suivant :

IOCTL_AVC_CLASS à son tour prend en charge plusieurs codes de fonction. Les pilotes enfants des instances de Avc.sys pour prendre en charge les sous-unités homologues ont la garantie d’avoir accès à cette interface via leur objet d’appareil parent.

L’interface GUID_AVC_CLASS prend en charge tous les codes de fonction IOCTL_AVC_CLASS, même si certains ont des limitations sur leur utilisation, comme décrit dans les pages de référence pour chaque fonction.

Avc.sys inscrit une nouvelle instance de GUID_VIRTUAL_AVC_CLASS, s’il a été chargé, pour prendre en charge les sous-unités AV/C virtuelles (la pile virtuelle). Cette interface prend en charge quatre codes de contrôle d’E/S (IOCTL) :

L’interface GUID_VIRTUAL_AVC_CLASS ne prend pas en charge chaque code de fonction IOCTL_AVC_CLASS. La page de référence pour chaque code de fonction individuel spécifie s’il est pris en charge pour GUID_VIRTUAL_AVC_CLASS instances de Avc.sys.

IOCTL_AVC_CLASS les IIP sont uniquement pris en charge en mode noyau (généralement pour la communication de pilote à pilote) via IRP_MJ_INTERNAL_DEVICE_CONTROL. Par conséquent, les applications ne peuvent pas accéder directement aux fonctions fournies par le code IOCTL IOCTL_AVC_CLASS.

Les trois derniers codes IOCTL sont pris en charge en mode noyau et en mode utilisateur via IRP_MJ_DEVICE_CONTROL. Cela signifie que les applications peuvent envoyer ces IOCTL directement à Avc.sys.

Le IOCTL_AVC_CLASS code IOCTL doit toujours être accompagné d’un bloc de demande d’E/S (IRB), qui décrit plus en détail l’opération AV/C à effectuer. L’en-tête IRB inclut un numéro de fonction, qui détermine la structure du reste de la CISR. La structure et la taille de la CISR varient en fonction de la fonction. Avc.sys utilise deux irbs personnalisés :

Le choix de l’IRB qu’un pilote de sous-unité doit utiliser dépend de la fonction souhaitée. Pour plus d’informations sur les codes de fonction IOCTL_AVC_CLASS pris en charge par Avc.sys, consultez Codes de fonction du pilote de protocole AV/C.

La fonction AV/C principale utilisée par les pilotes de sous-unité est AVC_FUNCTION_COMMAND, qui utilise la structure AVC_COMMAND_IRB. AVC_FUNCTION_COMMAND envoie les requêtes AV/C et reçoit les réponses AV/C correspondantes. Les détails de la génération de commandes AV/C sont gérés par Avc.sys, mais le pilote de sous-unité doit fournir l’opcode AV/C et les opérandes de chaque commande.