驱动程序与应用程序的接口

驱动程序与应用程序的接口

本文翻译自DriverWorks帮助文件

杨全胜

有两种方式可以让设备和应用程序之间联系：

1.通过为设备创建的一个符号链；

2.通过输出到一个接口

WDM驱动程序建议使用输出到一个接口而不推荐使用创建符号链的方法。这个接口保证PDO的安全，也保证安全地创建一个惟一的、独立于语言的访问设备的方法。

一个应用程序使用Win32APIs来调用设备。在某个Win32 APIs和设备对象的分发函数之间存在一个映射关系。

获得对设备对象访问的第一步就是打开一个设备对象的句柄。

用符号链打开一个设备的句柄

为了打开一个设备，应用程序需要使用CreateFile。如果该设备有一个符号链出口，应用程序可以用下面这个例子的形式打开句柄：

hDevice = CreateFile("\\\\.\\OMNIPORT3",

GENERIC_READ | GENERIC_WRITE,FILE_SHARE_READ,

NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL ,NULL

);

文件路径名的前缀“\\.\”告诉系统本调用希望打开一个设备。这个设备必须有一个符号链，以便应用程序能够打开它。有关细节查看有关Kdevice和CreateLink的内容。在上述调用中第一个参数中前缀后的部分就是这个符号链的名字。

注意：CreatFile中的第一个参数不是Windows 98/2000中驱动程序(.sys文件)的路径。是到设备对象的符号链。

如果使用DriverWizard产生驱动程序，它通常使用类KunitizedName来构成设备的符号链。这意味着符号链名有一个附加的数字，通常是0。例如：如果链接名称的主干是L “TestDevice”那么在CreateFile中的串就该是“\\\\.\\TestDevice0”。

如果应用程序需要被覆盖的I/O，第六个参数(Flags)必须或上FILE_FLAG_OVERLAPPED。

使用一个输出接口打开句柄

用这种方式打开一个句柄会稍微麻烦一些。DriverWorks库提供两个助手类来使获得对该接口的访问容易一些，这两个类是CDeviceInterface, 和CdeviceInterfaceClass。

CdeviceInterfaceClass类封装了一个设备信息集，该信息集包含了特殊类中的所有设备接口信息。

应用程序能有用CdeviceInterfaceClass类的一个实例来获得一个或更多的CdeviceInterface类的实例。CdeviceInterface类是一个单一设备接口的抽象。它的成员函数DevicePath()返回一个路径名的指针，该指针可以在CreateFile中使用来打开设备。

下面用一个小例子来显示这些类最基本的使用方法：

extern GUID TestGuid;

HANDLE OpenByInterface(

GUID* pClassGuid,

DWORD instance,

PDWORD pError

)

{

CDeviceInterfaceClass DevClass(pClassGuid, pError);

if (*pError != ERROR_SUCCESS)

return INV ALID_HANDLE_V ALUE;

CDeviceInterface DevInterface(&DevClass, instance, pError);

if (*pError != ERROR_SUCCESS)

return INV ALID_HANDLE_V ALUE;

cout << "The device path is "

<< DevInterface.DevicePath()

<< endl;

HANDLE hDev;

hDev = CreateFile(

DevInterface.DevicePath(),

GENERIC_READ | GENERIC_WRITE,

FILE_SHARE_READ | FILE_SHARE_WRITE,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL

);

if (hDev == INVALID_HANDLE_V ALUE)

*pError = GetLastError();

return hDev;

}

在设备中执行I/O操作

一旦应用程序获得一个有效的设备句柄，它就能使用Win32 APIs来产生到设备对象的

需要解释一下设备类成员的Close和CleanUp：CreateFile使内核为设备创建一个新的文件对象。这使得多个句柄可以映射同一个文件对象。当这个文件对象的最后一个用户级句

柄被撤销后，I/O管理器调用CleanUp。当没有任何用户级和核心级的对文件对象的访问的时候，I/O管理器调用Close。

如果被打开的设备不支持指定的功能，则调用相应的Win32将引起错误（无效功能）。

以前为Windows95编写的VxD的应用程序代码中可能会在打开设备的时候使用FILE_FLAG_DELETE_ON_CLOSE属性。在Windows NT/2000中，建议不要使用这个属性，因为它将导致没有特权的用户企图打开这个设备，这是不可能成功的。

I/O管理器将ReadFile和WriteFile的buff参数转换成IRP域的方法依赖于设备对象的属性。当设备设置DO_DIRECT_IO标志，I/O管理器将buff锁住在存储器中，并且创建了一个存储在IRP中的MDL域。一个设备可以通过调用Kirp::Mdl来存取MDL。

当设备设置DO_BUFFERED_IO标志，设备对象分别通过KIrp::BufferedReadDest或KIrp::BufferedWriteSource为读或写操作获得buff地址。

当设备不设置DO_BUFFERED_IO标志也不设置DO_DIRECT_IO，内核设置IRP 的UserBuffer域来对应ReadFile或WriteFile中的buff参数。然而，存储区并没有被锁住而且地址只对调用进程有效。驱动程序可以使用KIrp::UserBuffer来存取IRP域。

对于DeviceIoControl调用，buffer参数的转换依赖于特殊的I/O控制代码，它不在设备对象的特性中。宏CTL_CODE（在winioctl.h中定义）用来构造控制代码。这个宏的其中一个参数指明缓冲方法是METHOD_BUFFERED, METHOD_IN_DIRECT, METHOD_OUT_DIRECT, 或METHOD_NEITHER。下面的表显示了这些方法和与之对应的能获得输入缓冲与输出缓冲的KIrp中的成员函数：

出。驱动程序必须在向输出缓冲放数据之前拷贝输入数据。驱动程序通过调用KIrp::IoctlBuffer获得缓冲地址。在完成时，I/O管理器从系统缓冲拷贝数据到提供给Ring 3级调用者使用的缓冲中。驱动程序必须在结束前存储拷贝到IRP的Information成员中的数据个数。

如果控制代码不指明METHOD_IN_DIRECT或METHOD_OUT_DIRECT，则DeviceIoControl的参数呈现不同的含义。参数InputBuffer被拷贝到一个系统缓冲，这个缓冲驱动程序可以通过调用KIrp::IoctlBuffer。参数OutputBuffer被映射到KMemory对象，驱动程序对这个对象的访问通过调用KIrp::Mdl来实现。对于METHOD_OUT_DIRECT，调用者必须有对缓冲的写访问权限。

注意，对METHOD_NEITHER，内核只提供虚拟地址；它不会做映射来配置缓冲。虚拟地址只对调用进程有效。

这里是一个用METHOD_BUFFERED的例子：

首先，使用宏CTL_CODE来定义一个IOCTL代码：

#define IOCTL_MYDEV_GET_FIRMWARE_REV \

CTL_CODE

(FILE_DEVICE_UNKNOWN,0,METHOD_BUFFERED,FILE_ANY_ACCESS) 现在使用一个DeviceIoControl调用：

BOOLEAN b;