Création et utilisation d’objets fichier Driver-Created
Avertissement
UMDF 2 est la dernière version d’UMDF et remplace UMDF 1. Tous les nouveaux pilotes UMDF doivent être écrits à l’aide d’UMDF 2. Aucune nouvelle fonctionnalité n’est ajoutée à UMDF 1 et la prise en charge d’UMDF 1 est limitée sur les versions plus récentes de Windows 10. Les pilotes Windows universels doivent utiliser UMDF 2.
Les exemples UMDF 1 archivés sont disponibles dans la mise à jour des exemples de pilotes Windows 11, version 22H2 - Mai 2022.
Pour plus d’informations, consultez Prise en main avec UMDF.
Si votre pilote doit créer et envoyer une demande d’E/S indépendante de l’application au pilote suivant de la pile (la cible d’E/S par défaut), le pilote doit créer et fermer ses propres objets de fichier.
Création d’un objet File
Votre pilote doit appeler la méthode IWDFDevice::CreateWdfFile pour créer un objet file à utiliser par le pilote. Lorsque le pilote appelle IWDFDevice::CreateWdfFile, le framework envoie une demande de création au pilote suivant dans la pile. Le pilote suivant dans la pile peut être en mode noyau ou en mode utilisateur.
Ce traitement des demandes de fichier de création est différent dans le modèle de pilote Windows (WDM). Dans WDM, un appel à la fonction ZwCreateFile entraîne l’iRP de création en haut de la pile en mode noyau. La figure suivante illustre le traitement des demandes de création de fichier dans UMDF et WDM :
En appelant IWDFDevice::CreateWdfFile, le pilote peut créer un objet fichier, puis envoyer des demandes d’E/S au démarrage de l’appareil, avant le démarrage de la pile entière.
Le pilote suivant dans la pile doit déterminer s’il peut gérer la demande de création de fichier ou s’il doit transférer la requête plus loin dans la pile.
Après avoir appelé IWDFDevice::CreateWdfFile, un pilote ne peut pas annuler l’opération de création.
Utilisation de l’objet File
Pour envoyer une demande de lecture asynchrone au pilote suivant empilé en dessous, votre pilote peut utiliser le modèle suivant.
- Appelez IWDFDevice::CreateWdfFile pour créer l’objet file.
- Appelez IWDFDevice::GetDefaultIoTarget pour récupérer l’interface représentant le pilote de niveau inférieur.
- Appelez IWDFDevice::CreateRequest pour créer un objet IWDFIoRequest non mis en forme.
- Appelez IWDFIoRequest::SetCompletionCallback pour inscrire une interface IRequestCallbackRequestCompletion pour la méthode OnCompletion que le framework appelle lorsqu’une demande d’E/S se termine.
- Appelez IWDFIoTarget::FormatRequestForRead, en fournissant un pointeur vers l’interface IWDFDriverCreatedFile dans le paramètre pFile .
- Appelez IWDFIoRequest::Send pour envoyer la demande.
Fermeture de l’objet File
Le pilote qui a appelé IWDFDevice::CreateWdfFile doit ultérieurement appeler IWDFDriverCreatedFile::Close.
En règle générale, votre pilote appelle IWDFDriverCreatedFile::Close à partir de sa méthode de rappel IPnpCallbackHardware::OnReleaseHardware ou IPnpCallbackSelfManagedIo::OnSelfManagedIoCleanup .
Lorsque le pilote appelle IWDFDriverCreatedFile::Close, le framework appelle la méthode IFileCallbackCleanup::OnCleanupFile du pilote suivant. Dans cette méthode, le pilote suivant doit annuler ou terminer toutes les demandes d’E/S en attente associées à l’objet fichier. L’infrastructure annule ensuite toutes les demandes d’E/S créées par le pilote qui a appelé IWDFDevice::CreateWdfFile. L’infrastructure n’annule pas les demandes d’E/S que les pilotes inférieurs de la pile peuvent avoir associés à l’objet file. Il est de la responsabilité du pilote d’annuler ces demandes. L’objet file se ferme uniquement une fois que toutes les demandes d’E/S associées sont terminées.
Ensuite, le framework appelle la méthode IFileCallbackClose::OnCloseFile du pilote suivant. À ce stade, l’infrastructure garantit que le pilote suivant ne recevra pas de demandes d’E/S supplémentaires pour cet objet de fichier.
Une fois que le framework a appelé OnCloseFile, il détruit l’interface IWDFFile qui représente l’objet file.
Si les objets de fichier créés par le pilote restent après le retour des méthodes de suppression de périphérique du pilote (par exemple IPnpCallbackHardware::OnReleaseHardware et IPnpCallbackSelfManagedIo::OnSelfManagedIoCleanup), l’infrastructure génère un arrêt du pilote. Pour plus d’informations sur la résolution de ce problème, consultez Détermination de la raison pour laquelle UMDF indique des fichiers en attente au moment de la suppression de l’appareil.