驱动开发（7）IRP与派遣函数

http://blog.csdn.net/zuishikonghuan/article/details/50190339&＃xfeff;&＃xfeff;

在上一篇博文中&＃xff0c;介绍了NT驱动的基本结构&＃xff0c;这几篇博文&＃xff0c;博主来说说驱动开发的一个核心内容——如何处理I/O请求。

为何要处理I/O请求&＃xff1f;因为通常一个驱动程序是为了控制硬件而设计的&＃xff08;虽然没有对应具体硬件的驱动远比有对应具体硬件的驱动要多得多&＃xff09;&＃xff0c;可以说&＃xff0c;是操作系统与硬件通信的桥梁。而驱动程序就是为操作系统提供了一种抽象&＃xff0c;驱动程序如何控制硬件&＃xff0c;是硬件厂商和硬件开发人员的工作&＃xff0c;而操作系统只需要将I/O请求发送到驱动程序里就行了。也就是说&＃xff0c;驱动程序向上按照微软的相关规范和标准处理Windows NT内核中的I/O请求&＃xff0c;向下控制不同接口&＃xff0c;不同标准的硬件。这体现了微内核的思想。&＃xff08;注&＃xff1a;Windows NT内核并不是微内核&＃xff0c;或许叫混合内核是一个不错的选择&＃xff09;

一个叫做“I/O请求数据包”&＃xff08;IRP&＃xff09;的数据结构在WDK的头文件中被定义&＃xff0c;Windows NT内核就是用IRP这个结构来组织内核I/O请求的。

我们来看看IRP这个结构是怎么定义的&＃xff1a;


typedef struct _IRP {..PMDL MdlAddress;ULONG Flags;union {struct _IRP *MasterIrp;..PVOID SystemBuffer;} AssociatedIrp;..IO_STATUS_BLOCK IoStatus;KPROCESSOR_MODE RequestorMode;BOOLEAN PendingReturned;..BOOLEAN Cancel;KIRQL CancelIrql;..PDRIVER_CANCEL CancelRoutine;PVOID UserBuffer;union {struct {..union {KDEVICE_QUEUE_ENTRY DeviceQueueEntry;struct {PVOID DriverContext[4];};};..PETHREAD Thread;..LIST_ENTRY ListEntry;..} Overlay;..} Tail;} IRP, *PIRP;

暂时不解释各个成员的含义&＃xff0c;因为现在说大家也不好理解&＃xff0c;同时这篇博文侧重点在引人主题&＃xff0c;是以思想为主&＃xff0c;在接下来的几篇中&＃xff0c;我们将围绕着处理IRP展开这些内容。

另外&＃xff0c;还有一种说法&＃xff0c;认为IRP数据结构只是IRP&＃xff08;I/O请求数据包&＃xff09;的一部分&＃xff0c;还有一个IO_STACK_LOCATION的东西&＃xff0c;这个就是I/O堆栈的当前这一层&＃xff0c;这个可以在派遣函数中使用IoGetCurrentIrpStackLocation函数得到它的指针。关于I/O堆栈&＃xff0c;博主不想现在详细说&＃xff0c;只是告诉大家处理IRP时一般都要得到这一层的指针&＃xff0c;关于I/O堆栈的细节&＃xff0c;博主打算以后在过滤驱动的那一些博文中说。

暂时撇开如何处理IRP不谈&＃xff0c;我们来说说派遣函数和IRP的关系。在Win32中&＃xff0c;消息&＃xff08;MSG结构&＃xff09;有一个叫“窗口过程”&＃xff08;WndProc&＃xff09;的回调函数&＃xff08;CallBack Function&＃xff09;来处理&＃xff0c;与之类似&＃xff0c;在驱动开发中&＃xff0c;IRP是在“派遣函数”或者叫“派遣例程”&＃xff08;DispatchRoutine&＃xff09;中处理的。

还记得在上一篇中&＃xff0c;是如何注册派遣函数的吗&＃xff1f;在DriverEntry中&＃xff0c;用DRIVER_OBJECT中的MajorFunction指针指向的内存设置为我们派遣函数的指针&＃xff0c;就像这样&＃xff1a;


extern "C" NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegistryPath){DbgPrint("DriverEntry\r\n");pDriverObject->DriverUnload &＃61; DriverUnload;//驱动卸载函数pDriverObject->MajorFunction[IRP_MJ_CREATE] &＃61; DispatchRoutine;//注册派遣函数pDriverObject->MajorFunction[IRP_MJ_CLOSE] &＃61; DispatchRoutine;pDriverObject->MajorFunction[IRP_MJ_WRITE] &＃61; DispatchRoutine;pDriverObject->MajorFunction[IRP_MJ_READ] &＃61; DispatchRoutine;

可以为每一种IRP设置一个派遣函数&＃xff0c;也可以分开。

IRP有很多&＃xff0c;比如&＃xff1a;&＃xff08;这里面还有一些是给WDM驱动用于即插即和电源管理的&＃xff09;


IRP_MJ_CLEANUPIRP_MJ_CLOSEIRP_MJ_CREATEIRP_MJ_DEVICE_CONTROLIRP_MJ_FILE_SYSTEM_CONTROLIRP_MJ_FLUSH_BUFFERSIRP_MJ_INTERNAL_DEVICE_CONTROLIRP_MJ_PNPIRP_MJ_POWERIRP_MJ_QUERY_INFORMATIONIRP_MJ_READIRP_MJ_SET_INFORMATIONIRP_MJ_SHUTDOWNIRP_MJ_SYSTEM_CONTROLIRP_MJ_WRITE

来看看派遣函数的原型&＃xff1a;

extern "C" NTSTATUS DispatchRoutine(PDEVICE_OBJECT pDevObj, PIRP pIrp)

pDevObj&＃xff1a;设备对象的指针。也就是接受I/O请求的设备对象的指针。说白了就是我往哪个设备发出I/O请求&＃xff0c;那么这个参数就是那个设备。

pIrp&＃xff1a;要处理IRP的指针。

返回值&＃xff1a;参见之前的一篇博文“内核中的内存分配和错误码”。

派遣函数类似于win32应用程序的回调函数&＃xff0c;只不过派遣函数的调用是并发的。

在结束之前&＃xff0c;我大致说一下下几篇博文的打算&＃xff0c;下一篇讲一个Win32应用程序&＃xff0c;这个应用程序呢&＃xff0c;他将直接向磁盘这一个设备发出I/O请求&＃xff0c;也就是绕过FileSystem直接读写磁盘上的扇区&＃xff0c;这依旧是一个引子&＃xff0c;让我们看看在R3下是如何向一个设备发出I/O请求的&＃xff0c;之后就讲在驱动中如何处理这些I/O请求。&＃xfeff;&＃xfeff;