KMDF en tant que modèle de paire de pilotes générique

Cet article décrit l’idée que le Kernel-Mode Driver Framework (KMDF) peut être considéré comme un modèle de paire de pilotes générique.

Remarque

Avant de lire cette rubrique, vous devez comprendre les idées présentées dans Minidrivers et les paires de pilotes.

Au fil des ans, Microsoft a créé plusieurs modèles de pilotes spécifiques à la technologie qui utilisent ce paradigme :

  • Le pilote est divisé en deux éléments : un qui gère le traitement général et un qui gère le traitement spécifique à un appareil particulier.
  • L’article général, appelé Framework, est écrit par Microsoft.
  • L’élément spécifique, appelé pilote KMDF, peut être écrit par Microsoft ou un fournisseur de matériel indépendant.

diagramme de kmdf en tant qu'appairage de pilotes génériques.

La partie Framework de la paire de pilotes effectue des tâches générales communes à un large éventail de pilotes. Par exemple, l’infrastructure peut gérer les files d’attente de demandes d’E/S, la synchronisation de threads et une grande partie des tâches de gestion de l’alimentation.

Le Framework possède la table de répartition du pilote KMDF, de sorte que lorsque quelqu'un envoie un paquet de requêtes d'E/S (IRP) à l'appairage (pilote KMDF, Framework), l'IRP va au Framework. Si le framework peut gérer lui-même l’IRP, le pilote KMDF n’est pas impliqué. Si l’infrastructure ne peut pas gérer l’IRP par lui-même, elle obtient de l’aide en appelant des gestionnaires d’événements implémentés par le pilote KMDF. Voici quelques exemples de gestionnaires d’événements qui peuvent être implémentés par un pilote KMDF.

  • EvtDevicePrepareHardware
  • EvtIoRead
  • EvtIoDeviceControl
  • EvtInterruptIsr
  • EvtInterruptDpc
  • EvtDevicePnpStateChange

Par exemple, un pilote de contrôleur hôte USB 2.0 a un élément spécifique nommé usbehci.sys et un élément général nommé usbport.sys. Usbehci.sys, qui est appelé pilote USB 2.0 Miniport, a du code spécifique aux contrôleurs hôtes USB 2.0. Usbport.sys, qui est appelé pilote de port USB, a du code général qui s’applique à la fois à USB 2.0 et USB 1.0. La paire de pilotes (usbehci.sys, usbport.sys) se combine pour former un seul pilote WDM pour un contrôleur hôte USB 2.0.

Les paires de pilotes (spécifiques, générales) portent des noms différents selon les technologies des appareils. La plupart des pilotes spécifiques aux appareils portent le préfixe mini. Les pilotes généraux sont souvent appelés pilotes de port ou de classe. Voici quelques exemples de paires (spécifiques, générales) :

  • (pilote de miniport d'affichage, pilote de port d'affichage)
  • (pilote de miniport USB, pilote de port USB)
  • (pilote de la miniclasse batterie, pilote de la classe batterie)
  • (minipilote HID, pilote de classe HID)
  • (pilote de miniport de stockage, pilote de port de stockage)

Comme de plus en plus de modèles d'appairage de pilotes ont été développés, il est devenu difficile de garder une trace de toutes les différentes façons d'écrire un pilote. Chaque modèle possède sa propre interface pour la communication entre le pilote spécifique à l’appareil et le pilote général. Le corps des connaissances requises pour développer des pilotes pour une technologie d’appareil (par exemple, Audio) peut être tout à fait différent du corps des connaissances requises pour développer des pilotes pour une autre technologie d’appareil (par exemple, Stockage).

Au fil du temps, les développeurs se sont rendu compte qu’il serait judicieux d’avoir un modèle unifié unique pour les paires de pilotes en mode noyau. L’infrastructure kmDF (Kernel Mode Driver Framework), qui était disponible pour la première fois dans Windows Vista, répond à ce besoin. Un pilote basé sur KMDF utilise un paradigme similaire à la plupart des modèles de paire de pilotes spécifiques à la technologie.

  • Le pilote est divisé en deux éléments : un qui gère le traitement général et un qui gère le traitement spécifique à un appareil particulier.
  • L’article général, écrit par Microsoft, est appelé Framework.
  • L’élément spécifique, écrit par Microsoft ou un fournisseur de matériel indépendant, est appelé pilote KMDF.

Le pilote du contrôleur hôte USB 3.0 est un exemple de pilote basé sur KMDF. Dans cet exemple, les deux pilotes de ce duo sont écrits par Microsoft. Le pilote général est l’infrastructure, et le pilote spécifique au périphérique est le pilote du contrôleur hôte USB 3.0. Ce diagramme illustre le nœud d’appareil et la pile d’appareils pour un contrôleur hôte USB 3.0.

diagramme de la pile d’appareils pour le contrôleur hôte usb 3.

Dans le diagramme, Usbxhci.sys est le pilote du contrôleur hôte USB 3.0. Il est associé à Wdf01000.sys, qui est le Framework. La paire (usbxhci.sys, wdf01000.sys) forme un seul pilote WDM qui sert de pilote de fonction pour le contrôleur hôte USB 3.0. Notez que la paire de pilotes occupe un niveau dans la pile d’appareils et est représentée par un seul objet de périphérique. L’objet d’appareil unique qui représente la paire (usbxhci.sys, wdf01000.sys) est l’objet d’appareil fonctionnel (FDO) pour le contrôleur hôte USB 3.0.

Dans une paire (pilote KMDF, Framework), le Framework gère les tâches communes à un grand nombre de pilotes en mode noyau. Par exemple, l’infrastructure peut gérer la mise en file d’attente des demandes d’E/S, la synchronisation de threads, la plupart des tâches Plug-and-Play et la plupart des tâches de gestion de l’alimentation. Le pilote KMDF gère les tâches qui nécessitent une interaction avec un appareil spécifique. Le pilote KMDF participe au traitement des demandes en inscrivant les gestionnaires d’événements que le Framework appelle selon les besoins.

  • Last updated on