http://blog.csdn.net/zuishikonghuan/article/details/50190339
在上一篇博文中,介绍了NT驱动的基本结构,这几篇博文,博主来说说驱动开发的一个核心内容——如何处理I/O请求。
为何要处理I/O请求?因为通常一个驱动程序是为了控制硬件而设计的(虽然没有对应具体硬件的驱动远比有对应具体硬件的驱动要多得多),可以说,是操作系统与硬件通信的桥梁。而驱动程序就是为操作系统提供了一种抽象,驱动程序如何控制硬件,是硬件厂商和硬件开发人员的工作,而操作系统只需要将I/O请求发送到驱动程序里就行了。也就是说,驱动程序向上按照微软的相关规范和标准处理Windows NT内核中的I/O请求,向下控制不同接口,不同标准的硬件。这体现了微内核的思想。(注:Windows NT内核并不是微内核,或许叫混合内核是一个不错的选择)
一个叫做“I/O请求数据包”(IRP)的数据结构在WDK的头文件中被定义,Windows NT内核就是用IRP这个结构来组织内核I/O请求的。
我们来看看IRP这个结构是怎么定义的:
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;
暂时不解释各个成员的含义,因为现在说大家也不好理解,同时这篇博文侧重点在引人主题,是以思想为主,在接下来的几篇中,我们将围绕着处理IRP展开这些内容。
另外,还有一种说法,认为IRP数据结构只是IRP(I/O请求数据包)的一部分,还有一个IO_STACK_LOCATION的东西,这个就是I/O堆栈的当前这一层,这个可以在派遣函数中使用IoGetCurrentIrpStackLocation函数得到它的指针。关于I/O堆栈,博主不想现在详细说,只是告诉大家处理IRP时一般都要得到这一层的指针,关于I/O堆栈的细节,博主打算以后在过滤驱动的那一些博文中说。
暂时撇开如何处理IRP不谈,我们来说说派遣函数和IRP的关系。在Win32中,消息(MSG结构)有一个叫“窗口过程”(WndProc)的回调函数(CallBack Function)来处理,与之类似,在驱动开发中,IRP是在“派遣函数”或者叫“派遣例程”(DispatchRoutine)中处理的。
还记得在上一篇中,是如何注册派遣函数的吗?在DriverEntry中,用DRIVER_OBJECT中的MajorFunction指针指向的内存设置为我们派遣函数的指针,就像这样:
extern "C" NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegistryPath)
{
DbgPrint("DriverEntry\r\n");
pDriverObject->DriverUnload = DriverUnload;//驱动卸载函数
pDriverObject->MajorFunction[IRP_MJ_CREATE] = DispatchRoutine;//注册派遣函数
pDriverObject->MajorFunction[IRP_MJ_CLOSE] = DispatchRoutine;
pDriverObject->MajorFunction[IRP_MJ_WRITE] = DispatchRoutine;
pDriverObject->MajorFunction[IRP_MJ_READ] = DispatchRoutine;
可以为每一种IRP设置一个派遣函数,也可以分开。
IRP有很多,比如:(这里面还有一些是给WDM驱动用于即插即和电源管理的)
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
IRP_MJ_CREATE
IRP_MJ_DEVICE_CONTROL
IRP_MJ_FILE_SYSTEM_CONTROL
IRP_MJ_FLUSH_BUFFERS
IRP_MJ_INTERNAL_DEVICE_CONTROL
IRP_MJ_PNP
IRP_MJ_POWER
IRP_MJ_QUERY_INFORMATION
IRP_MJ_READ
IRP_MJ_SET_INFORMATION
IRP_MJ_SHUTDOWN
IRP_MJ_SYSTEM_CONTROL
IRP_MJ_WRITE
来看看派遣函数的原型:
extern "C" NTSTATUS DispatchRoutine(PDEVICE_OBJECT pDevObj, PIRP pIrp)
pDevObj:设备对象的指针。也就是接受I/O请求的设备对象的指针。说白了就是我往哪个设备发出I/O请求,那么这个参数就是那个设备。
pIrp:要处理IRP的指针。
返回值:参见之前的一篇博文“内核中的内存分配和错误码”。
派遣函数类似于win32应用程序的回调函数,只不过派遣函数的调用是并发的。
在结束之前,我大致说一下下几篇博文的打算,下一篇讲一个Win32应用程序,这个应用程序呢,他将直接向磁盘这一个设备发出I/O请求,也就是绕过FileSystem直接读写磁盘上的扇区,这依旧是一个引子,让我们看看在R3下是如何向一个设备发出I/O请求的,之后就讲在驱动中如何处理这些I/O请求。