分类: C/C++
2008-03-17 13:46:46
Driver对象数据项 | 说明 |
PDEVICE_OBJECT DeviceObject | 由本驱动程序创建的Device对象的链表 |
ULONG Flags PDRIVER_INITIALIZE DriverInit | 驱动程序初始化例程(一般较少用) |
PDRIVER_STARTIO DriverStartIo | StartIo例程入口,一般该例程对低层设备驱动程序用得较多, 高层驱动程序较少使用本例程。 |
PDRIVER_UNLOAD DriverUnload | 卸载驱动程序例程,如果想在控制面版的设备里停止该设备,应该提供本例程。 |
PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1] | 驱动程序的Dispatch例程表 |
在上面提到过驱动程序是管理同类型的所有设备,所以上面的 结构中DeviceObject指向的就不是单个的设备对象,而是一个对象链表,这个链表的维护在下面介绍Device对象时可以看到。 Device对象与Device Extension 驱动程序在调用IoCreateDevice函数成功后就创建了一个Device 对象。下面对Device对象几个比较重要的数据做一介绍。
Device对象数据项 | 说明 |
PVOID DeviceExtension | 指向Device Extension结构的指针 |
PDRIVER_OBJECT DriverObject | 指向这个设备的Driver对象的指针,IoCreateDevice会 自动填写本数据。 |
ULONG Flags | 指定这个设备的缓冲策略 |
PDEVICE_OBJECT NextDevice | 指向属于这个驱动程序的下一个设备对象,依靠本数据来维护设备对象链表 |
CCHAR StackSize | 发送到这个设备的IRP需要的I/O堆栈单元的最小数目,一般对分层驱动程序来说,本数据应该比其下层设备的大1 |
ULONG AlignmentRequirement | 缓冲区要求的内存对齐,一般对分层驱动程序来说,本值应该 和其下层设备的对齐一致 |
Device记录着设备的特徵和状态信息,对系统上的每个虚拟的、逻辑的和物理的设备都有一个Device对象。例如对一个硬盘驱动程序,对一个物理硬盘有一个名称为Partition0的Device对象,对应整个物理磁盘,同时对硬盘的每个分区,也都有一个Device对象,它们的名称分别为PartitionX(X从1开始,每个分区对应一个数字)。
Device Extension是连接到Device对象的一个很重要的数据结构,它的数据结构是由驱动程序设计者自己来确定的,在 调用IoCreateDevice的时候应该指定它的大小,Device Extension其实是由操作系统在非份页内存池中为每个Device 对象分配的一块内存。由于驱动程序必须是完全可重入的, 因此使用任何全局变量和静态变量都不是好的办法,一般来 说和设备有关的任何需要保持的信息都应该放到Device Extension里去。
设备的缓冲策略也必须提一下,这里的Flag的缓冲策略主要 决定设备读写(功能代码IRP_MJ_READ和IRP_MJ_WRITE)时候的 缓冲策略,另外功能代码IRP_MJ_DEVICE_CONTROL时候的缓冲 策略是由IOCTL控制代码本身来决定的。两者不能混为一谈。 在下面我将专门用一节来讨论I/O的缓冲策略。
I/O请求包(IRP)
在上面的结构里面已经出现了IRP了,在这里对它做一说明。 在NT中,几乎所有的I/O都是包驱动的,可以说驱动程序和操作系统其他部份都是通过I/O请求包来进行交互的。我们 来看看一个I/O请求的执行过程。
(1) 操作系统的I/O管理器从非分页内存分配一个IRP,响应一个I/O请求。基于由客户指定的I/O函数,I/O管理器将该 IRP传递给合适的驱动程序的Dispatch例程。
(2) Dispatch例程检查请求的参数是否有效,如果有效,驱动程序根据请求的内容进行一系列的操作。否则设置错 误状态信息直接返回。
(3) 操作完成时,将数据(如果有)和状态信息存放到IRP中 并返回给I/O管理器。
(4) I/O管理器对返回的IRP进行适当的处理后将最后状态和 数据(如果有)返回给用户。
一个IRP的主要数据项如下表所示。
IRP包括一个IRP头和一个IRP stack 的区域。由于WDM的模式下都是包驱动的,所里IRP可以说是一个非常重要的东东。还有那个该死的URB(God damn URB!)
IRP主要数据项 | 说明 |
IO_STATUS_BLOCK IoStatus | 存放I/O请求的状态 |
PVOID AssociatedIrp.SystemBuffer | 如果设备执行缓冲I/O,则为指向系统空间缓冲区的指针。 否则为NULL |
PMDL MdlAddress | 如果设备执行直接I/O,指向用户空间缓冲区的内存描述表的指针 |
PVOID UserBuffer | I/O缓冲区的用户空间地址 |
BOOLEAN Cancel | 指示IRP已被取消 |
关于AssociatedIrp.SystemBuffer、MdlAddress和UserBuffer将在 下面的I/O缓冲区策略里面更详细地讨论。
NT还有更多其他的对象,例如中断对象、Controller对象、定时器对象等等,但在我们开发的驱动程序中并没有用到,因此在这里不做介绍。
I/O缓冲策略
很明显的,驱动程序和客户应用程序经常需要进行数据交换,但我们知道驱动程序和客户应用程序可能不在同一个地址空间,因此操作系统必须解决两者之间的数据交换。这就就设计到设备的I/O缓冲策略。
读写请求的I/O缓冲策略
前面说到通过设置Device对象的Flag可以选择控制处理读写请求的I/O缓冲策略。下面对这些缓冲策略分别做一介绍。
1、缓冲I/O(DO_BUFFERED_IO)
在读写请求的一开始,I/O管理器检查用户缓冲区的可访问性,然后分配与调用者的缓冲区一样大的非分页池,并把它的地址放在IRP的AssociatedIrp.SystemBuffer域中。驱动程序就利用这个域来进行实际数据的传输。
对于IRP_MJ_READ读请求,I/O管理器还把IRP的UserBuffer域设置 成调用者缓冲区的用户空间地址。当请求完成时,I/O管理器利用 这个地址将数据从驱动程序的系统空间拷贝回调用者的缓冲区。对 于IRP_MJ_WRITE写请求,UserBuffer被设置为NULL,并把用户缓冲 区的数据拷贝到系统缓冲区中。
2、 直接I/O(DO_DIRECT_IO)
I/O管理器首先检查用户缓冲区的可访问性,并在物理内存中锁定它。然后它为该缓冲区创建一个内存描述表(MDL),并把MDL的地址 存放在IRP的MdlAddress域中。AssociatedIrp.SystemBuffer和 UserBuffer都被设置为NULL。驱动程序可以调用函数 MmGetSystemAddressForMdl得到用户缓冲区的系统空间地址,从而 进行数据操作。这个函数将调用者的缓冲区映射到非份页的地址空 间。驱动程序完成I/O请求后,系统自动从系统空间解除缓冲区的映射。
3、 这两种方法都不是
这种情况比较少用,因为这需要驱动程序自己来处理缓冲问题。 I/O管理器仅把调用者缓冲区的用户空间地址放到IRP的UserBuffer 域中。我们并不推荐这种方式。
IOCTL缓冲区的缓冲策略
IOCTL请求涉及来自调用者的输入缓冲区和返回到调用者的输出 缓冲区。为了理解IOCTL请求,我们先来看看WIN32 API DeviceIoControl函数的原型。
BOOL DeviceIoControl (
HANDLE hDevice, // 设备句柄
DWORD dwIoControlCode, // IOCTL请求操作代码
LPVOID lpInBuffer, // 输入缓冲区地址
DWORD nInBufferSize, // 输入缓冲区大小
LPVOID lpOutBuffer, // 输出缓冲区地址
DWORD nOutBufferSize, // 输出缓冲区大小
LPDWORD lpBytesReturned, // 存放返回字节数的指针
LPOVERLAPPED lpOverlapped // 用于同步操作的Overlapped结构体指针
);
IOCTL请求有四种缓冲策略,下面一一介绍。
1、 输入输出缓冲I/O(METHOD_BUFFERED)
I/O管理器首先分配一个非分页池,它足够大地存放调用者的输入或输出缓冲区(不管哪个更大)。非分页缓冲区的地址放在IRP的AssociatedIrp.SystemBuffer域中,然后把IOCTL的输入数据拷贝 到这个非份页缓冲区中,并把IRP的UserBuffer域设置成调用者输出缓冲区的用户空间地址。当驱动程序完成IOCTL请求时,I/O管理器将这个非份页缓冲区中的数据拷贝到调用者的输出缓冲区。注意这里同一个非份页池同时用于输入和输出缓冲区,因此驱动程序在向缓冲区写东西之前应该把输入的所有数据读出来。
2、 直接输入缓冲输出I/O(METHOD_IN_DIRECT)
I/O管理器首先检查调用者输入缓冲区的可访问性,并在物理内存中将其锁定。然后为该输入缓冲区创建一个MDL,并把指定该MDL的指针存放到IRP的MdlAddress域中。同时,I/O管理器还在非份页池中分配一输出缓冲区,并把这个缓冲区的地址存放在IRP的AssociatedIrp.SystemBuffer域中,并把IRP的UserBuffer域设置成调用者输出缓冲区的用户空间地址。当驱动程序完成IOCTL请求时,I/O管理器将非份页缓冲区中的数据拷贝到调用者的输出缓冲区。
3、 缓冲输入直接输出I/O(METHOD_OUT_DIRECT)
I/O管理器首先检查调用者输出缓冲区的可访问性,并在物理内存中将其锁定。然后为该输出缓冲区创建一个MDL,并把指定该MDL的指针存放到IRP的MdlAddress域中。同时,I/O管理器还在非份页池中分配一输入缓冲区,并把这个缓冲区的地址存放在IRP的AssociatedIrp.SystemBuffer域中, 同时把调用者用户输入缓冲区中的数据拷贝到系统缓冲区中,并把IRP的 UserBuffer域设置为NULL。
4、 上面三种方法都不是(METHOD_NEITHER)
I/O管理器把调用者的输入缓冲区的地址放到IRP当前I/O堆栈单元的Parameters.Devi ceIoControl.TypeInputBuffer域中,把输出缓冲 区的地址存放到IRP的UserBuffer域中。这两个地址都是用户空间地 址。
从上面的说明可以看出,在执行缓冲I/O时,I/O管理器将在非份页池 中分配内存,如果调用者的缓冲区比较大时,分配的非份页池也将 比较大。非份页池是系统比较宝贵的资源,因此,如果调用者的缓 冲区比较大时,我们一般采用直接I/O的方式(例如磁盘读写请求等), 这样不仅节省系统资源,另一方面由于省去了I/O管理器在系统缓冲 区和调用者缓冲区之间的数据拷贝,也提高了效率,这对存在大量 数据传送的驱动程序尤其明显。
可以注意到DDK中的Samples下,几乎所有的例程的读写请求都是直 接I/O的,而对于IOCTL请求则是缓冲区I/O的居多。
开始驱动程序设计
下面的文字是从Microsoft的DDK帮助中节选出来的,它让我们明 白在开始设计驱动程序应该注意些什么问题,这些都是具有普遍 意义的开发准则。应该支持哪些I/O请求在开始写任何代码之前, 应该首先确定我们的驱动程序应该处理哪些IRP例程。
如果你在设计一个设备驱动程序,你应该支持和其他相同类型 设备的NT驱动程序相同的IRP_MJ_XXX和IOCTL请求代码。
如果你是在设计一个中间层NT驱动程序,应该首先确认你下层 驱动程序所管理的设备,因为一个高层的驱动程序必须具有低层 驱动程序绝大多数IRP_MJ_XXX例程入口。高层驱动程序在接到I/O 请求时,在确定自身IRP当前堆栈单元参数有效的前提下 ,设置好IRP中下一个低层驱动程序的堆栈单元,然后再调用IoCallDriver 将请求传递给下层驱动程序处理。
一旦决定好了你的驱动程序应该处理哪些IRP_MJ_XXX,就可以开始 确定驱动程序应该有多少个Dispatch例程。当然也可以考虑把某些 RP_MJ_XXX处理的例程合并为同一例程处理。例如在ChangerDisk和 VDisk里,对IRP_MJ_CREATE和IRP_MJ_CLOSE处理的例程就是同一函数。 对IRP_MJ_READ和IRP_MJ_WRITE处理的例程也是同一个函数。
应该有多少个Device对象?
一个驱动程序必须为它所管理的每个可能成为I/O请求的目标的物理和逻辑设备创建一个命名Device对象。一些低层的驱动程序还可能要创建一些不确定数目的Device对象。例如一个硬盘驱动程序必须为每一个物理硬盘创建一个Device对象,同时还必须为每个物理磁盘上的每个逻辑分区创建一个Device对象。
一个高层驱动驱动程序必须为它所代表的虚拟设备创建一个Device 对象,这样更高层的驱动程序才能连接它们的Device对象到这个驱动程序的Device对象。另外,一个高层驱动程序通常为它低层驱动 程序所创建的Device对象创建一系列的虚拟或逻辑Device对象。
尽管你可以分阶段来设计你的驱动程序,因此一个处在开发阶段的 驱动程序不必一开始就创建出所有它将要处理的所有Device对象。 但从一开始就确定好你最终要创建的所有Device对象将有助于设计者所要解决的任何同步问题。另外,确定所要创建的Device对象还有助于你定义Device对象的Device Extension的内容和数据结构。
开始驱动程序开发
驱动程序的开发是一个从粗到细逐步求精的过程。NT DDK的src\ 目录下有一个庞大的样板代码,几乎覆盖了所有类型的设备驱动程序、高层驱动程序和过滤器驱动程序。在开始开发你的驱动程序之前,你应该在这个样板库下面寻找是否有和你所要开发的类似类型的例程。例如我们所开发的驱动程序,虽然DDK对USB描述得不是很详细,我们还是可以在src\storage\class目录发现很多和USB设备有关的驱动程序。下面我们来看开发驱动程序的基本步骤。
最简的驱动程序框架
1、 写一个DriverEntry例程,在里面调用IoCreateDevice创建 一个Device对象。
2、 写一个处理IRP_MJ_CREATE请求的Dispatch例程的基本框架 (参见DDK Kernel-Mode Drivers 4.4.3描述的一个DispatchCreate 例程所要完成的最基本工作。当然写了DispatchCreate例程后, 要在DriverEntry例程为IRP_MJ_CREATE初始化例程入口)。如果驱动程序创建了多于一个Device对象,则必须为IRP_MJ_CLOSE 请求写一个例程,该例程通常情况下可以和DispatchCreate共用一个例程,参见参见DDK Kernel-Mode Drivers 4.4.3。
3、 编译连接你的驱动程序。
用下面的方法来测试你的驱动程序。
首先按上面介绍的方法安装好驱动程序。
其次我们还得为NT逻辑设备名称和目标Device对象名称之间建立 起符号连接,我们在前面已经知道Device对象名称对WIN32用户模式 是不可见的,是不能直接通过API来访问的,WIN 32 API只能访问NT 逻辑设备名称。我们可以通过修改注册表来建立这两种名称之间的符 号连接。运行REGEDT32.EXE在\HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\Control\ Session Manager\ DOS Devices下建立起符号连接(这种符号连接也可以在驱动程序里调用函数 IoCreateSymbolicLink来创建)。
重新启动系统。
编写一个简单的测试程序调用WIN32API CreateFile函数以刚才你命名的NT逻辑设备名打开这个设备。如果打开成功,那么你也就成功地写出了一个最简单的驱动程序了。
支持更多的设备I/O请求
例如你的驱动程序可能需要对IRP_MJ_READ请求做出响应(完成后可用WIN32 API ReadFile函数进行测试)。如果你的驱动程序需要能够手工卸载,那么还必须对IRP_MJ_CLOSE做出响应。为你所需要处理IRP_MJ_XXX写好处理例程,并在DriverEntry里面初始化好这些例 程入口。
一个低层的驱动程序可能需要最起码一个StartIo,ISR和DpcForIsr 例程,可能需要一个SynchCritSection例程,如果设备使用了DMA, 那么可能还需要一个AdapterControl例程。关于这些例程,请参考 DDK相应文档。
对于高层驱动程序可能需要一个或多个IoCompletion例程,最起码 完成检查I/O状态块然后调用IoCompleteRequest的工作。 如果需要,还要对Device Extension数据结构和内容做些修改。
驱动程序的书写过程的确是很烦人的,从你开始理解结构开始,你就像掉在一个泥潭里一样,无论你如何出拳,发觉总是稀泥一堆。即使你是计算机高手,可以写三千行源代码没犯一个错,一次写完,一次就编译通过(我的一个“同事”在面试的时候对我们老板说的,我想他说的对,他没犯一个错,而是犯了三十万零一个半错,不过,由不的你不信,俺朋友老板就信世间有这类高手,并供为上宾),你还得了解一些基础的硬件知识,你还要了解你的驱动程序的设备的种类,设备的硬件结构,一些特殊的寄存器,或许一些更基础的汇编程序你也的去跑一遍。还的去看什么微微有点软出的什么鸟DDK(这玩意是最重要的),我看像敌敌畏(啊啊,给我一杯敌敌畏,让我不用写程序........哈哈,我的水平直逼牛得滑了,好耍!好耍!)。然后你开始写了一大堆你自认为不比“葵花宝典”差的驱动程序,嘿嘿,你发觉整个程序就是编译不过去,就好像你花十块零五毛RMB买了本“葵花宝典”,终于下定决心按照书的首页要求的引刀什么的,可是你发觉费了九马二骡之力引完了刀,神功依旧未成,点解!你又得去学什么程序调试,去Debug,俺们称其为捉虫,NN的,TMD,虫没有捉到,脑袋可肿的大大的。什么SOFTICE,WINDBG之类,尽是一些系统杀手的角色,一不小心改错了一个内存地址,哼,我CRASH你的机器,你只好又装机,又调试,又死翘翘,你不见密西西比河不死心,又重来一遍,如此三番,惹得你无名火起,起身饮茶,又见隔壁部门的老板正和小蜜在讨论周末去哪里加班工作,不由的气不打一处出,大吼一声“呔,来将何人!洒家张翼德在此!”..........哎,人在老板下,哪能不干活,只有硬头再上.............无数次的失败,无数次的徒劳之后,终于让你的机器跑的欢极了,你不由的小哼一句“对面的小蜜看过来,这里的男孩很能干!”
驱动程序真的得看个人造化,若你有张无忌般奇遇,有韦小宝般艳福,有段舆般韧劲,(对了,还要有东方不败般的勇气)还有什么做不了的。哈哈!