多端口设备驱动程序结构 [英] Multi-port device driver structure

问题描述

我有一个关于多端口设备（不是多功能）的WDM驱动程序设计的查询。



我有一个8 -port serial comms PCI卡，我需要为其编写WDM驱动程序。  PCI卡不是COM端口卡。 它具有同步串行端口和板载处理器。 驱动程序不直接控制端口，驱动程序与控制端口的板载处理器通信
。 因此只有一组资源（IO端口，内存空间，中断）。



我需要弄清楚要使用哪种类型的驱动程序结构，特别是在设备对象。



阅读各种互联网论坛似乎这种多端口驱动程序的简单方案是只创建一个设备对象（对于每个多端口） PCI卡），然后使用附加到设备名称的字符串来区分卡上的端口。

当应用程序打开一个端口（使用CreateFile）时，它会在设备名称后附加一个部分用于指定设备正在打开的端口的字符串，例如\\\\\ SER0 \\\，\\。\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\来自IRP的IO_STACK_LOCATION的FileObject成员的FileName成员的设备名称的一部分，从而确定正在打开哪个端口。



到目前为止，这么好，但我不确定驱动程序如何识别后续READ，WRITE，IOCTL和CLOSE请求与哪个端口相关。 我有以下具体问题：



1. 当应用程序随后进行ReadFile，WriteFile，DeviceIoControl和CloseHandle调用并且驱动程序因此接收IRP_MJ_READ，IRP_MJ_WRITE，IRP_MJ_DEVICE_CONTROL和IRP_MJ_CLOSE IRP时，FileName成员是否也有效
来确定IRP与哪个端口相关？



2. 如果FileName在IRP_MJ_READ等IRP中无效，IRP或IO_STACK_LOCATION中的其他字段或其他方法可用于识别IRP所针对的端口？



3. 如果这个方案根本不起作用，你可以为多端口WDM驱动程序的结构建议下一个最简单的方案是什么？
b


感谢你的期待，

I have a query about the design of a WDM driver for a multi-port device (not multi-function).

I have an 8-port serial comms PCI card for which I need to write a WDM driver.  The PCI card is not a COM port card.  It has synchronous serial ports and an on-board processor.  The driver does not control the ports directly, the driver communicates with the on-board processor which controls the ports.  There is thus just one set of resources (IO ports, memory space, interrupt).

I need to figure out what type of driver structure to use, particularly in regard to Device Objects.

Reading various internet forums it seems that a straightforward scheme for such a multi-port driver is to create just one device object (for each multi-port PCI card), and then to use strings appended to the Device Name to distinguish between ports on the card.
When an application opens a port (using CreateFile), it appends an additional part to the device name string to specify which port on the device it is opening, e.g. \\.\SER0\1, \\.\SER0\2, etc.
The driver will then receive an IRP_MJ_CREATE IRP and will be able to retrieve the extended part of the device name from the FileName member of the FileObject member of the IO_STACK_LOCATION of the IRP, and thus determine which port is being opened.

So far, so good, but I'm not sure how the driver can identify to which port subsequent READ, WRITE, IOCTL and CLOSE requests relate.  I have the following specific queries:

1.  When the application subsequently makes ReadFile, WriteFile, DeviceIoControl, and CloseHandle calls and the driver consequently receives IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL and IRP_MJ_CLOSE IRPs, will the FileName member also be valid to determine which port the IRP is related to?

2.  If the FileName is not valid in the IRP_MJ_READ, etc IRPs, what other field in the IRP or IO_STACK_LOCATION, or what other method can be used to identify which port is being targeted by the IRP?

3.  If this scheme will not work at all, what is the next simplest scheme that you can suggest for the structure of a multi-port WDM driver?

Thanking you in anticipation,

Greg。

推荐答案

首先我不会在WDM中这样做。  WDM是一项老技术，你有大量令人讨厌的代码来处理KMDF框架为你处理的PnP和Power。

First I would not do this in WDM.  WDM is old technology, and you have a ton of nasty code to deal with PnP and Power that the KMDF framework takes care of for you.

当你打开一个带有路径的设备时，每条路径将获得一个唯一的文件对象，您可以使用它来区分它是什么设备。  FsContext和FsContext2中有两个字段，您可以使用它们指向设备唯一的数据，类似于
a设备扩展。

When you open a device with a path each path will get a unique file object, which you can use to distinguish which device it is.  There are two fields in the FsContext and FsContext2 which you can use to point to data unique to the device similar to a device extension.

KMDF也有文件对象支持，并提供你可以使用很多服务。

KMDF has file object support also, and provides a lot of services you can use.

最后在你的设计上，做了很多串口设备，我建议你重新考虑一下。 我会在KMDF中创建一个实际与硬件对话的总线驱动程序，然后从WDK获取串行样本并修改它以向总线驱动程序说出
。  使用这种方法，用户可以获得相同的体验，就好像这些是独立的端口一样。 开发人员拥有一个拥有所有必需支持的框架，您只需将其修改为您的设备。 
注意Serial也是KMDF！

Finally on your design, having done a number of serial port devices, I would recommend you rethink you approach.  I would create a bus driver in KMDF that actually talks to the hardware, then take the Serial sample from the WDK and modify it to talk to the bus driver.   Using this approach the user gets the same experience as if these were separate ports.  You the developer have a framework that has all the required support to start with, you just need to modify it to your device.  Note Serial is also KMDF!

这篇关于多端口设备驱动程序结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！