Uso di Avc.sys

  • Articolo

Dopo il caricamento e l'inizializzazione di Windows Avc.sys, Avc.sys usa comandi standard di unità AV/C e subunit per individuare le sottounità attive in tutti i dispositivi AV/C connessi al bus IEEE 1394 (incluse le sottounità virtuali quando il computer è un'unità AV/C virtuale). Avc.sys quindi genera identificatori di dispositivo (ID) per tutte le sottounite attive. Successivamente, Avc.sys usa meccanismi di Plug and Play standard (PnP) per caricare il driver di subunit appropriato per ogni subunit. Il driver subunit da caricare viene selezionato in base al file INF che installa il driver subunit e l'identificatore del dispositivo della subunit, come generato da Avc.sys e descritto in ID dispositivo AV/C. L'identificatore del dispositivo viene generato dalle informazioni di unità del dispositivo AV/C, in combinazione con i campi SubunitType e SubunitID del subunit. Il driver che supporta una subunit può essere specifico del fornitore oppure può essere generico per il tipo di subunit. Ad esempio, il driver di subunit per la maggior parte dei dv dv è il Msdv.sysfornito da Microsoft.

I driver subunit comunicano con Avc.sys tramite il meccanismo standard basato su IRP usato da tutti i driver basati sull'architettura WDM. Un driver subunit comunica con la relativa subunit AV/C allocando e inviando irP nello stack di driver al driver di protocollo AV/C ,Avc.sys. Per effettuare richieste di I/O, includere il file di intestazione Avc.h, fornito con Microsoft Windows Driver Kit (WDK).

Un driver subunit alloca e inizializza i runtime di integrazione da elaborareAvc.sys. Un driver subunit imposta il membro Parameters.DeviceIoControl.IoControlCode di IOCTL che corrisponde all'operazione AV/C desiderata.

Avc.sys registra una delle due interfacce del dispositivo, a seconda dello stack di driver subunit caricato per supportare (peer o virtuale). Queste interfacce definiscono la funzionalità che Avc.sys le esportazioni per driver subunit, altri driver e applicazioni da usare. Avc.sys quindi modifica lo stato dell'interfaccia in abilitato o disabilitato in base allo stato PnP del driver.

Avc.sys registra una nuova istanza di GUID_AVC_CLASS se è stata caricata per fornire supporto per le sottounità AV/C esterne (stack peer). Questa interfaccia supporta solo il codice I/O (IOCTL) seguente:

IOCTL_AVC_CLASS supporta a sua volta più codici di funzione. I driver figlio delle istanze di Avc.sys per supportare le sottounit peer hanno la garanzia di avere accesso a questa interfaccia tramite l'oggetto dispositivo padre.

L'interfaccia GUID_AVC_CLASS supporta tutti i codici di funzione IOCTL_AVC_CLASS, anche se alcuni presentano limitazioni sull'uso, come descritto nelle pagine di riferimento per ogni funzione.

Avc.sys registra una nuova istanza di GUID_VIRTUAL_AVC_CLASS, se caricata, per fornire supporto per le sottounità AV/C virtuali (stack virtuale). Questa interfaccia supporta quattro codici di controllo I/O (IOCTL):

L'interfaccia GUID_VIRTUAL_AVC_CLASS non supporta ogni codice di funzione IOCTL_AVC_CLASS. La pagina di riferimento per ogni singolo codice di funzione specifica se è supportata per GUID_VIRTUAL_AVC_CLASS istanze di Avc.sys.

IOCTL_AVC_CLASS i runtime di integrazione sono supportati solo in modalità kernel (in genere per la comunicazione da driver a driver) tramite IRP_MJ_INTERNAL_DEVICE_CONTROL. Di conseguenza, le applicazioni non possono accedere direttamente alle funzioni fornite dal codice IOCTL IOCTL_AVC_CLASS.

Gli ultimi tre codici IOCTL sono supportati sia in modalità kernel che in modalità utente tramite IRP_MJ_DEVICE_CONTROL. Ciò significa che le applicazioni possono inviare questi IOCTLs direttamente a Avc.sys.

Il codice IOCTL IOCTL_AVC_CLASS deve essere sempre accompagnato da un blocco di richieste I/O (IRB), che descrive ulteriormente l'operazione AV/C da eseguire. L'intestazione IRB include un numero di funzione, che determina la struttura del resto dell'IRB. La struttura e le dimensioni di IRB variano in base alla funzione. Avc.sys usa due runtime di integrazione personalizzati:

La scelta di cui deve essere utilizzato un driver di subunit IRB dipende dalla funzione desiderata. Per altre informazioni sui codici di funzione IOCTL_AVC_CLASS supportati da Avc.sys, vedere Codici di funzione del driver di protocollo AV/C.

La funzione AV/C primaria usata dai driver subunit è AVC_FUNCTION_COMMAND, che usa la struttura AVC_COMMAND_IRB. AVC_FUNCTION_COMMAND invia richieste AV/C e riceve le risposte AV/C corrispondenti. I dettagli per la compilazione di comandi AV/C vengono gestiti da Avc.sys, ma il driver subunit deve fornire il codice operativo AV/C e gli operandi di ogni comando.