【问题标题】:How does FILE_FLAG_NO_BUFFERING interact with handles opened to communication devices?FILE_FLAG_NO_BUFFERING 如何与打开到通信设备的句柄交互?
【发布时间】:2015-10-25 15:17:04
【问题描述】:

正如标题所说,我正在编写一个网络程序,在其中我使用 CreateFile 打开网络驱动程序的句柄,并且我一直在尝试使用 NO_BUFFERING 标志。

大多数文档甚至都不会提及将其与通信设备一起使用,而那些这样做的文档(AKA MSDN 参考等)只是提及您可以。

有人知道这会如何影响与设备的通信吗?

【问题讨论】:

    标签: windows driver createfile


    【解决方案1】:

    这是一个设备驱动程序实现细节,您在 CreateFile() 调用中指定的选项在 IRP_MJ_REQUEST request 中传递。我链接的那个是用于文件系统的,它非常花哨。单击 IrpSp->Parameters.Create.Options 链接到 IoCreateFileSpecifyDeviceObjectHint()'s Options 参数以查看 FILE_NO_INTERMEDIATE_BUFFERING。

    串行端口is here 的 IRP_MJ_REQUEST 的文档。非常简单,完全没有参数 :) 一般来说,用于通信端口的 winapi 到设备驱动程序接口是一个非常直截了当的方法。记录在案的 winapi 函数与其underlying IOCTL 之间存在(几乎)直接映射。 winapi 函数除了基本的错误检查之外并没有做太多的事情,然后迅速将工作传递给驱动程序。

    因此没有任何方法可以传递您指定的 FILE_FLAG_NO_BUFFERING 选项,因此它根本不会被使用。

    否则逻辑结论,串行端口 I/O 是中断驱动的,驱动程序必须缓冲以不丢失字节并保持可接受的传输速率。您可以通过SetupComm() 在技术上修改缓冲区大小,但正如文档所述,这只是一个建议,驱动程序忽略非常低的值的可能性很高。

    【讨论】:

    • 哇,你为我打开了一个全新的视角!回顾一下:这是否意味着 Windows 本身实际上并没有缓冲任何东西——驱动程序会缓冲?如果是这样,则网络上的某些文档是错误的 - 我发现明确表示该标志阻止 Windows 使用它自己的缓冲区的网站!此外,网络驱动程序是 Windows 的 TUN/TAP 驱动程序,而不是串行端口本身。这有什么影响吗?我想它仍然是中断驱动的,但我需要确定!非常感谢汉斯,-JN
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-01-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-07-18
    • 2012-04-28
    相关资源
    最近更新 更多