Comment FILE_FLAG_NO_BUFFERING interagit avec les handles ouverts aux appareils de communication?

Question

Comme le titre l'indique, j'écris un programme de mise en réseau où j'ouvre un handle à un pilote réseau en utilisant CreateFile, et j'ai expérimenté avec le drapeau NO_BUFFERING.

La plupart des documentations ne mentionnent même pas cela étant utilisé avec des périphériques de communication, et ceux qui le font (AKA la référence MSDN, etc), mentionnent simplement que vous pouvez.

Est-ce que quelqu'un a une idée de comment cela peut affecter la communication avec l'appareil?

Answer 1

Il s'agit d'un détail d'implémentation de pilote de périphérique, les options que vous spécifiez dans l'appel CreateFile() sont transmises dans IRP_MJ_REQUEST request. Celui que j'ai lié est celui pour les systèmes de fichiers, il est très chic. Cliquez sur le lien IrpSp-> Parameters.Create.Options à l'argument Options IoCreateFileSpecifyDeviceObjectHint()'s pour voir FILE_NO_INTERMEDIATE_BUFFERING.

La documentation de l'IRP_MJ_REQUEST pour les ports série is here. Très simple, pas du tout d'arguments :) En général, le winapi à l'interface du pilote de périphérique pour les ports de communication est un très simple. Il existe un mappage (presque) direct entre la fonction winapi documentée et sa fonction underlying IOCTL. La fonction winapi ne fait pas beaucoup plus que la vérification d'erreur de base, puis transmet rapidement le travail au pilote.

Il n'y a donc aucun moyen de passer l'option FILE_FLAG_NO_BUFFERING que vous spécifiez afin qu'elle ne soit simplement pas utilisée.

Sinon la conclusion logique, E/S du port série est piloté par interruption, le pilote doit tampon afin de ne pas perdre d'octets et de maintenir un taux de transfert acceptable. Vous pouvez techniquement bricoler avec les tailles de tampon à travers SetupComm() mais, comme documenté, c'est seulement une recommandation avec des chances assez élevées que le conducteur ignore simplement des valeurs très basses.