Utilisation du regroupement d’appareils dans les pilotes UMDF

  • Article

User-Mode Driver Framework (UMDF) versions 1.11 et 2.0

Si votre pilote UMDF (User-Mode Driver Framework) a été créé avec la version 1.11 ou 2.0 et s’exécute sur Windows 8 ou une version ultérieure, l’infrastructure crée une seule instance de Wudfhost qui peut héberger plusieurs piles d’appareils. Cette technique est appelée regroupement d’appareils. Le main’avantage du regroupement d’appareils est la réduction de la consommation de mémoire dans un environnement avec plusieurs appareils UMDF.

Si un appareil mis en pool échoue, l’infrastructure met fin à la instance de Wudfhost et tente de redémarrer tous les appareils qui se trouvaient précédemment dans le pool. Si l’appareil échoue à nouveau lors du pool, l’infrastructure crée un processus Wudfhost distinct pour l’appareil et tente de redémarrer l’appareil.

Si l’appareil échoue dans le processus hôte distinct, l’infrastructure tente de le redémarrer jusqu’à cinq fois. L’infrastructure réinitialise le nombre d’erreurs de l’appareil à un lorsque trente minutes se sont écoulées depuis le dernier échec.

Si le système est redémarré, l’infrastructure met en pool les appareils à l’exception de ceux qui ont échoué lors de l’exécution dans un processus distinct.

Pour désactiver le regroupement d’appareils pour un appareil spécifique, utilisez la directive UmdfHostProcessSharing dans la section DDInstall spécifique à WDF de l’INF. Pour plus d’informations sur UmdfHostProcessSharing, consultez Spécification de directives WDF dans les fichiers INF.

Si votre pilote utilise les E/S directes, vous devez définir UmdfHostProcessSharing sur ProcessSharingDisabled. Sinon, votre pilote risque de ne pas démarrer. Si WdfDeviceIoBufferedOrDirect est sélectionné et que l’appareil est mis en pool, l’infrastructure modifie la méthode d’accès à la mémoire tampon en E/S mises en mémoire tampon. Si WdfDeviceIoBufferedOrDirect est sélectionné et que l’appareil n’est pas mis en pool, le framework modifie la méthode d’accès à la mémoire tampon en direct E/S.

Pour sélectionner une méthode d’accès à la mémoire tampon, votre pilote doit appeler la méthode IWDFDeviceInitialize2::SetIoTypePreference à partir de sa fonction de rappel IDriverEntry::OnDeviceAdd . Pour plus d’informations sur les méthodes d’accès, consultez Accès aux mémoires tampons de données dans les pilotes UMDF-Based.

UMDF versions 1.9 et antérieures

Si votre pilote a été créé avec UMDF version 1.9 ou antérieure, l’infrastructure crée une instance distincte du processus hôte (Wudfhost) pour chaque pile d’appareils.

Si l’appareil ne parvient pas à démarrer, l’infrastructure tente de le redémarrer jusqu’à cinq fois. L’infrastructure réinitialise le nombre d’erreurs de l’appareil à un lorsque trente minutes se sont écoulées depuis le dernier échec.

Dans un environnement non mis en pool, si plusieurs piles d’appareils partagent le même pilote UMDF :

  • Chaque pile d’appareils se charge dans un processus WudfHost distinct.
  • L’infrastructure appelle les méthodes IDriverEntry::OnInitialize et IDriverEntry::OnDeinitialize du pilote une fois pour chaque pile d’appareils.
  • Le framework appelle la méthode IDriverEntry::OnDeviceAdd du pilote une fois pour chaque pile d’appareils. Chaque objet d’appareil est associé à un objet pilote distinct.

Dans un environnement mis en pool, si plusieurs piles d’appareils partagent le même pilote en mode utilisateur :

Étant donné qu’il n’existe qu’un seul objet pilote dans une configuration mise en pool, le pilote ne doit pas stocker de contexte par appareil dans des variables globales ou dans des objets partagés entre les appareils, tels que l’objet de rappel du pilote. Au lieu de cela, le pilote doit stocker le contexte par appareil dans un objet qui n’est pas partagé entre les piles d’appareils, comme l’objet de rappel d’appareil du pilote.