Verwenden von Avc.sys

  • Artikel

Nachdem Windows Avc.sysgeladen und initialisiert hat, verwendetAvc.sys standardmäßige AV/C-Einheits- und -Untereinheitsbefehle, um die aktiven Untereinheiten auf allen AV/C-Geräten zu ermitteln, die mit dem IEEE 1394-Bus verbunden sind (einschließlich aller virtuellen Untereinheiten, wenn der Computer eine virtuelle AV/C-Einheit ist). Avc.sys generiert dann Gerätebezeichner (IDs) für alle aktiven Untereinheiten. Als Nächstes verwendetAvc.sys PnP-Mechanismen (Standard Plug & Play), um den entsprechenden Untereinheitstreiber für jede Untereinheit zu laden. Der zu ladende Untereinheitstreiber wird basierend auf der INF-Datei ausgewählt, die den Untereinheitstreiber installiert, und dem Gerätebezeichner der Untereinheit, wie von Avc.sys generiert und unter AV/C-Geräte-IDs beschrieben. Der Gerätebezeichner wird aus den Einheiteninformationen des AV/C-Geräts in Kombination mit den Feldern SubunitType und SubunitID der Untereinheit generiert. Der Treiber, der eine Untereinheit unterstützt, kann herstellerspezifisch oder für den Typ der Untereinheit generisch sein. Der Untereinheitstreiber für die meisten DV-Camcorder ist beispielsweise der von Microsoft bereitgestellteMsdv.sys.

Untereinheitstreiber kommunizieren mit Avc.sys über den standardmäßigen IRP-basierten Mechanismus, der von allen Treibern basierend auf der WDM-Architektur verwendet wird. Ein Untereinheitstreiber kommuniziert mit seiner AV/C-Untereinheit, indem irPs im Treiberstapel an den AV/C-Protokolltreiber Avc.syszugeordnet und gesendet werden. Um E/A-Anforderungen zu stellen, schließen Sie die Headerdatei Avc.h ein, die im Lieferumfang des Microsoft Windows Driver Kit (WDK) enthalten ist.

Ein Untereinheitstreiber ordnet irPs zu und initialisiert sie, die von Avc.sysverarbeitet werden sollen. Ein Untereinheitstreiber legt das Parameters.DeviceIoControl.IoControlCode-Element des IRP auf die IOCTL fest, die dem gewünschten AV/C-Vorgang entspricht.

Avc.sys registriert eine von zwei Geräteschnittstellen, je nachdem, welcher Untereinheitstreiberstapel (Peer oder virtuell) geladen wurde. Diese Schnittstellen definieren die Funktionalität, die Avc.sys Exporte für Untereinheitstreiber, andere Treiber und Anwendungen, die verwendet werden sollen. Avc.sys ändert dann den Zustand der Schnittstelle entsprechend dem PnP-Zustand des Treibers in aktiviert oder deaktiviert.

Avc.sys registriert eine neue instance von GUID_AVC_CLASS, wenn sie geladen wurde, um Unterstützung für externe AV/C-Untereinheiten (den Peerstapel) bereitzustellen. Diese Schnittstelle unterstützt nur den folgenden I/O-Steuerelementcode (IOCTL):

IOCTL_AVC_CLASS unterstützt wiederum mehrere Funktionscodes. Untergeordnete Treiber von Instanzen von Avc.sys , die Peeruntereinheiten unterstützen, haben über ihr übergeordnetes Geräteobjekt garantiert Zugriff auf diese Schnittstelle.

Die GUID_AVC_CLASS-Schnittstelle unterstützt alle IOCTL_AVC_CLASS Funktionscodes, obwohl einige Einschränkungen hinsichtlich ihrer Verwendung haben, wie auf den Referenzseiten für jede Funktion beschrieben.

Avc.sys registriert eine neue instance von GUID_VIRTUAL_AVC_CLASS, wenn sie geladen wurde, um Unterstützung für virtuelle AV/C-Untereinheiten (den virtuellen Stapel) bereitzustellen. Diese Schnittstelle unterstützt vier I/O-Steuerungscodes (IOCTL):

Die GUID_VIRTUAL_AVC_CLASS-Schnittstelle unterstützt nicht jeden IOCTL_AVC_CLASS Funktionscode. Die Referenzseite für jeden einzelnen Funktionscode gibt an, ob er für GUID_VIRTUAL_AVC_CLASS Instanzen von Avc.sysunterstützt wird.

IOCTL_AVC_CLASS IRPs werden nur im Kernelmodus (in der Regel für die Kommunikation zwischen Treibern) über IRP_MJ_INTERNAL_DEVICE_CONTROL unterstützt. Daher können Anwendungen nicht direkt auf die Funktionen zugreifen, die vom IOCTL_AVC_CLASS IOCTL-Code bereitgestellt werden.

Die letzten drei IOCTL-Codes werden sowohl im Kernelmodus als auch im Benutzermodus über IRP_MJ_DEVICE_CONTROL unterstützt. Dies bedeutet, dass Anwendungen diese IOCTLs direkt an Avc.syssenden können.

Der IOCTL_AVC_CLASS IOCTL-Code muss immer von einem E/A-Anforderungsblock (IRB) begleitet werden, der den auszuführenden AV/C-Vorgang genauer beschreibt. Der IRB-Header enthält eine Funktionsnummer, die die Struktur des restlichen IRB bestimmt. Die IRB-Struktur und -Größe variiert je nach Funktion. Avc.sys verwendet zwei benutzerdefinierte IRBs:

Welche IRB ein Untereinheitstreiber verwenden muss, hängt von der gewünschten Funktion ab. Weitere Informationen zu den IOCTL_AVC_CLASS Funktionscodes, die vonAvc.sys unterstützt werden , finden Sie unter Av/C-Protokolltreiberfunktionscodes.

Die primäre AV/C-Funktion, die von Untereinheitstreibern verwendet wird, ist AVC_FUNCTION_COMMAND, die die AVC_COMMAND_IRB-Struktur verwendet. AVC_FUNCTION_COMMAND sendet AV/C-Anforderungen und empfängt die entsprechenden AV/C-Antworten. Details zum Erstellen von AV/C-Befehlen werden von Avc.sysverarbeitet, aber der Untereinheitstreiber muss den AV/C-Opcode und die Operanden jedes Befehls bereitstellen.