Interfacce SpbCx

L'estensione del framework SPB (SpbCx) ha due interfacce. Il primo è un'interfaccia di richiesta di I/O tramite cui SpbCx accetta le richieste di I/O inviate dai client (driver periferici) del controller SPB ai dispositivi periferici collegati al bus. La seconda interfaccia è un'interfaccia DDI (Device Driver Interface) tramite la quale SpbCx comunica con il driver del controller SPB.

Le due interfacce SpbCx sono definite nei file di intestazione Spbcx.h e Spb.h. Spbcx.h definisce l'interfaccia DDI tra SpbCx e il driver del controller SPB. Spb.h definisce i codici di controllo I/O specifici di SPB supportati dall'interfaccia richiesta di I/O SpbCx.

SpbCx Device Driver Interface (DDI)

L'interfaccia DDI (Device Driver Interface) SpbCx è costituita da metodi implementati dal modulo di estensione del framework SPB, Spbcx.syse dalle funzioni di callback degli eventi implementate dal driver del controller SPB. Il driver del controller SPB registra le funzioni di callback con SpbCx durante l'inizializzazione del DDI.

Per richiedere servizi da SpbCx, il driver del controller SPB chiama i metodi di supporto del driver SpbCx. Ad esempio, il driver del controller SPB chiama questi metodi per impostare le opzioni di configurazione del driver per il controller SPB o per ottenere informazioni aggiuntive su una richiesta di I/O.

Per notificare al driver del controller SPB un evento (ad esempio, l'arrivo di una richiesta di I/O da un client), SpbCx chiama una funzione di callback evento implementata dal driver del controller SPB.

Durante i callback da SpbCx, il codice del driver del controller SPB viene eseguito in un contesto di thread arbitrario. Dopo aver ricevuto una richiesta di I/O che richiede l'elaborazione da parte del driver del controller SPB, SpbCx esegue qualsiasi pre-elaborazione richiesta della richiesta prima che SpbCx chiami una funzione EvtSpbXxx per eseguire l'operazione richiesta. Ad esempio, per rendere disponibile un buffer in modalità utente per una funzione di callback, SpbCx potrebbe dover essere eseguito nel contesto del thread che ha originato la richiesta di I/O. La funzione EvtIoInCallerContext è l'unica funzione di callback che non può basarsi su SpbCx per pre-elaborare le richieste.

Per registrare un set di funzioni di callback EvtSpbXxx, il driver del controller SPB chiama il metodo SpbDeviceInitialize . Questo driver chiama il metodo SpbControllerSetIoOtherCallback per registrare una funzione di callback EvtIoInCallerContext .

SpbCx DDI utilizza il tipo di handle dell'oggetto WDFDEVICE per rappresentare l'oggetto di dispositivo di un controller SPB. Includere il file header Wdf.h per definire WDFDEVICE e gli altri tipi di handle oggetti KMDF. Inoltre, DDI usa due tipi di handle di oggetti specifici di SPB, SPBREQUEST e SPBTARGET, simili ai tipi di handle di oggetti WDFREQUEST e WDFTARGET definiti da KMDF. Un handle SPBREQUEST rappresenta una richiesta di I/O. Un handle SPBTARGET rappresenta una connessione logica a un dispositivo periferico sul bus aperto per le operazioni di I/O.

Gli autobus periferici semplici, ad esempio I2C e SPI, vengono generalmente usati dai moduli SoC (System on a Chip), per i quali un basso numero di pin è importante. I moduli SoC vengono spesso usati come processori nei dispositivi palmari che richiedono un consumo energetico ridotto. Poiché i circuiti del controller SPB consumano potenza relativamente piccola, il codice di risparmio energia in SpbCx può essere relativamente semplice. Per impostazione predefinita, SpbCx garantisce che l'alimentazione del controller SPB sia attivata prima di chiamare uno dei metodi di callback degli eventi nel driver del controller SPB. Per altre informazioni, vedere la descrizione del membro PowerManaged in SPB_CONTROLLER_CONFIG.

Se necessario, il driver del controller SPB può attivare e disattivare in modo esplicito il controller chiamando i metodi WdfDeviceStopIdle e WdfDeviceResumeIdle .

Poiché il driver del controller SPB è un driver in modalità kernel, deve assegnare un descrittore di sicurezza appropriato ai relativi oggetti file. Questo descrittore impedisce l'accesso non autorizzato dalla modalità utente ai dispositivi periferici nel SPB. Ad esempio, i driver di controller SPB di esempio in WDK usano la stringa SDDL seguente, che fornisce un livello di sicurezza predefinito adatto per un tipico driver del controller SPB:

D:P(A;; GA;;; SY)(A;; GA;;; BA)(A;; GA;;; UD)

Questa stringa SDDL limita l'accesso al sistema operativo (e ai relativi componenti in modalità utente), ai membri del gruppo Administrators e ai driverUser-Mode Driver Framework (UMDF). Per altre informazioni sulle stringhe SDDL, vedere SDDL per oggetti dispositivo.

Inoltre, la funzione EvtSpbControllerIoOther deve convalidare tutti i parametri nelle richieste di controllo I/O personalizzate ricevute dai client in modalità utente. Per tutte le altre funzioni EvtSpbXxx, SpbCx convalida i parametri nelle richieste di I/O dai client in modalità utente prima che questi parametri vengano passati al driver del controller SPB. Per altre informazioni sulla sicurezza dei dispositivi, vedere Protezione degli oggetti dispositivo.

Tutti i metodi e le funzioni di callback nell'DDI SpbCx che restituiscono codici di stato restituiscono valori NTSTATUS. I metodi di supporto driver in questa DDI seguono le consuete convenzioni per le interfacce KMDF e tutti gli oggetti usati da SpbCx seguono le consuete convenzioni per gli oggetti KMDF. Per altre informazioni, vedere Introduzione agli oggetti framework.

Interfaccia di richiesta I/O SPB

Per implementare l'interfaccia di richiesta di I/O, SpbCx gestisce la coda di I/O per il controller SPB e monitora questa coda per le richieste di I/O dai client del controller SPB. Questi client sono driver in modalità utente e in modalità kernel per i dispositivi periferici connessi a SPB. Le applicazioni non possono comunicare direttamente con i dispositivi periferici connessi tramite SPB tramite l'interfaccia di richiesta di I/O SPB.

SpbCx potrebbe eseguire tutte le operazioni di elaborazione per alcune di queste richieste di I/O ed eseguire la pre-elaborazione di altre richieste prima che le richieste vengano passate al driver del controller SPB. Il driver del controller SPB è responsabile del completamento delle richieste ricevute da SpbCx.

I client possono inviare richieste di lettura e scrittura ai dispositivi periferici connessi a SPB. In risposta a una richiesta di IRP_MJ_READ , il controller SPB trasferisce il numero specificato di byte da un dispositivo periferico a un buffer client. In risposta a una richiesta di IRP_MJ_WRITE , il controller SPB trasferisce il numero specificato di byte da un buffer client a un dispositivo periferico.

Oltre a semplici operazioni di lettura e scrittura, l'interfaccia di richiesta di I/O SpbCx supporta le sequenze di trasferimento di I/O, che combinano uno o più trasferimenti semplici (ovvero letture e scritture) in un'unica operazione atomica del bus. Durante questa operazione, il bus viene usato esclusivamente per i trasferimenti da e verso il dispositivo periferico di destinazione e gli accessi di altre destinazioni sul bus vengono temporaneamente bloccati fino al completamento dell'operazione. SpbCx supporta il codice di controllo I/O IOCTL_SPB_EXECUTE_SEQUENCE, usato da un client per specificare una sequenza di trasferimenti a lunghezza fissa da e verso un dispositivo di destinazione in una singola richiesta di I/O. Questa richiesta di controllo di I/O consente al driver del controller di ottimizzare una sequenza di trasferimenti del bus per migliorare le prestazioni.

L'interfaccia di richiesta di I/O SpbCx supporta i codici di controllo IOCTL_SPB_LOCK_CONTROLLER e IOCTL_SPB_UNLOCK_CONTROLLER I/O, che bloccano e sbloccano il controller SPB. Queste richieste di blocco e sblocco consentono a un client di eseguire una sequenza di trasferimento di I/O. In questo caso, ogni operazione di lettura o scrittura nella sequenza viene specificata da una richiesta di lettura o scrittura separata. Mentre un client ha bloccato il controller, altri client non possono accedere ai dispositivi sul bus. Solo il client che tiene il blocco può eseguire operazioni di I/O sul bus. Per questo motivo, i client devono bloccare il controller solo per brevi periodi. Un client non deve mai lasciare bloccato il controller dopo il completamento di una sequenza di trasferimento. Per altre informazioni, vedere Sequenze di trasferimento di I/O.

Oltre ai codici I/O (IOCTL) supportati da SpbCx, il driver del controller SPB può supportare IOCTLs personalizzati. I client possono inviare richieste IOCTL a oggetti file che rappresentano i dispositivi di destinazione nel bus e queste richieste arrivano nella coda delle richieste di I/O gestita da SpbCx. Se SpbCx riceve una richiesta con un codice IOCTL che non supporta, SpbCx passa la richiesta direttamente al driver del controller, che esegue tutta la gestione della richiesta.

I client in modalità kernel dell'interfaccia richiesta di I/O SpbCx possono inviare richieste di I/O a livello di richiesta di interrupt (IRQL) di PASSIVE_LEVEL o DISPATCH_LEVEL. I client in modalità utente possono inviare richieste di I/O solo a PASSIVE_LEVEL. Il completamento di I/O può verificarsi a livello PASSIVE_LEVEL o DISPATCH_LEVEL. Tutte le richieste di I/O possono restituire STATUS_PENDING.

  • Last updated on