如何写驱动程序文档格式.docx
- 文档编号:20925510
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:11
- 大小:31.78KB
如何写驱动程序文档格式.docx
《如何写驱动程序文档格式.docx》由会员分享,可在线阅读,更多相关《如何写驱动程序文档格式.docx(11页珍藏版)》请在冰豆网上搜索。
3、文件系统驱动程序(FSD)
FSD是一类比较特殊的驱动程序,通常负责维护各种文件系统所需要的磁盘结构。
注意我们并不能使用DDK来开发FSD,而必须使用Microsoft的文件系统开发人员工具包。
一般比较少写中间过滤驱动程序,过滤驱动程序它截获和修改高层发送给类驱动程序的请求。
这样就允许利用现有类驱动程序的功能,而不必从头开始写所有程序。
NT内核模式对象在我们的实际开发过程中的对象是设备,由于端口驱动程序已经隐藏了硬件控制操作,因此我在这里不讲述跟硬件相关的部份。
如果今后的开发对象不同,需要对硬件进行操作的时候,可能会对中断、DMA等有比较详细的了解,这些内容可以参考DDK帮助。
NT使用对象技术管理所有的数据,下面分别对一般驱动程序所涉及的一些对象做一介绍。
不过在介绍这些对象之前,有必要先对驱动程序的结构做一介绍。
驱动程序结构
NT驱动程序和一般的DOS/WindowsC语言程序不一样,它没有main()或者WinMain()函数入口。
和DLL类似地,它向操作系统显露一个名称为DriverEntry()的函数,在启动驱动程序的时候,操作系统将调用这个入口。
DriverEntry除了做一些必要的设备初始化工作外,还初始化一些Dispatch例程入口。
我们知道,NT应用和设备驱动程序打交道主要是通过CreateFile、Read和DeviceIoControl等Win32API来进行的。
这些API其实都对应着驱动程序的一些Dispatch例程。
而驱动程序除了DriverEntry以外,主要就是由这些Dispatch例程组成的。
例如调用Win32APICreateFile的时候,操作系统最终转化为对驱动程序IRP_MJ_CREATE功能代码所对应的Dispatch例程的调用,如果驱动程序没有提供该例程,CreateFile调用就会失败。
NT中一些常用的功能代码和Win32API的对象关系如下所示。
功能代码
说明
IRP_MJ_CREATE
打开设备CreateFile
IRP_MJ_CLEANUP
在关闭设备时,取消挂起的I/O请求CloseHandle
IRP_MJ_CLOSE
关闭设备CloseHandle
IRP_MJ_READ
从设备获得数据ReadFile
IRP_MJ_WRITE
向设备发送数据WriteFile
IRP_MJ_DEVICE_CONTROL
对用户模式或内核模式客户程序可用的控制操作DeviceIoControl
IRP_MJ_INTERNAL_DEVICE_CONTROL
只对内核模式客户程序可用的控制操作
IRP_MJ_QUERY_INFORMATION
得到文件的长度Get
IRP_MJ_SET_INFORMATION
设置文件的长度Set
IRP_MJ_FLUSH_BUFFERS
写输出缓冲区或丢弃输入缓冲区
Flush
FlushConsoleInputBuffer
PurgeComm
IRP_MJ_SHUTDOWN
系统关闭InitialSystemShutdown
和上面的驱动程序支持的功能代码相对应,一般的驱动程序看起来就象下面的样子。
DriverEntry(…)//驱动程序入口
{
…
DeviceObject->
MajorFunction[IRP_MJ_CREATE]=XXDriverCreateClose;
//XX对应的是你自己给你的驱动程序的命名
MajorFunction[IRP_MJ_CLOSE]=XXDriverCreateClose;
MajorFunction[IRP_MJ_READ]=XXDriverReadWrite;
MajorFunction[IRP_MJ_WRITE]=XXDriverReadWrite;
}
XXDriverCreateClose(…)//对应IRP_MJ_CREATE和IRP_MJ_CLOSE的例程
//……….
XXDriverDeviceControl(…)//对应IRP_MJ_DEVICE_CONTROL的例程
XXDriverReadWrite(…)//对应IRP_MJ_READ和IRP_MJ_WRITE的例程
一个驱动程序并不需要支持所有的功能代码,比如如果一个驱动程序根本就不必要与用户模式客户程序交互,那么就不用支持IRP_MJ_CREATE和IRP_MJ_CLOSE。
又如设备不支持设备读写,就不用支持IRP_MJ_READ和IRP_MJ_WRITE。
驱动程序对象是在操作系统启动驱动程序、在调用驱动程序入口DriverEntry之前就已经创建好了的,并且作为DriverEntry函数的参数传递给驱动程序。
如果驱动程序启动失败,操作系统将删除该对象。
该对象的数据结构如下。
注意下表并不是完整地列出了ntddk.h中的DEVICE_OBJECT结构体的所有数据项,这里仅列出了一般驱动程序可能使用到的数据项。
Driver对象数据项
说明
PDEVICE_OBJECT
DeviceObject
由本驱动程序创建的Device对象的链表
ULONGFlags
PDRIVER_INITIALIZEDriverInit
驱动程序初始化例程(一般较少用)
PDRIVER_STARTIODriverStartIo
StartIo例程入口,一般该例程对低层设备驱动程序用得较多,高层驱动程序较少使用本例程。
PDRIVER_UNLOAD
DriverUnload
卸载驱动程序例程,如果想在控制面版的设备里停止该设备,应该提供本例程。
PDRIVER_DISPATCHMajorFunction[IRP_MJ_MAXIMUM_FUNCTION+1]
驱动程序的Dispatch例程表
在上面提到过驱动程序是管理同类型的所有设备,所以上面的结构中DeviceObject指向的就不是单个的设备对象,而是一个对象链表,这个链表的维护在下面介绍Device对象时可以看到。
Device对象与DeviceExtension驱动程序在调用IoCreateDevice函数成功后就创建了一个Device对象。
下面对Device对象几个比较重要的数据做一介绍。
Device对象数据项
PVOIDDeviceExtension
指向DeviceExtension结构的指针
PDRIVER_OBJECTDriverObject
指向这个设备的Driver对象的指针,IoCreateDevice会自动填写本数据。
ULONGFlags
指定这个设备的缓冲策略
PDEVICE_OBJECTNextDevice
指向属于这个驱动程序的下一个设备对象,依靠本数据来维护设备对象链表
CCHARStackSize
发送到这个设备的IRP需要的I/O堆栈单元的最小数目,一般对分层驱动程序来说,本数据应该比其下层设备的大1
ULONGAlignmentRequirement
缓冲区要求的内存对齐,一般对分层驱动程序来说,本值应该和其下层设备的对齐一致
Device记录着设备的特徵和状态信息,对系统上的每个虚拟的、逻辑的和物理的设备都有一个Device对象。
例如对一个硬盘驱动程序,对一个物理硬盘有一个名称为Partition0的Device对象,对应整个物理磁盘,同时对硬盘的每个分区,也都有一个Device对象,它们的名称分别为PartitionX(X从1开始,每个分区对应一个数字)。
DeviceExtension是连接到Device对象的一个很重要的数据结构,它的数据结构是由驱动程序设计者自己来确定的,在调用IoCreateDevice的时候应该指定它的大小,DeviceExtension其实是由操作系统在非份页内存池中为每个Device对象分配的一块内存。
由于驱动程序必须是完全可重入的,因此使用任何全局变量和静态变量都不是好的办法,一般来说和设备有关的任何需要保持的信息都应该放到DeviceExtension里去。
设备的缓冲策略也必须提一下,这里的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头和一个IRPstack的区域。
由于WDM的模式下都是包驱动的,所里IRP可以说是一个非常重要的东东。
还有那个该死的URB(GoddamnURB!
)[人一辈子真的很过瘾,有些人或有些事你明明不喜欢或做不来,可是有时侯你又不得不硬着头皮去做,就像一大堆球迷围着一堆狗屎般的中国足球,那班傻儿真是要钱不要脸,丢咱中国人的脸]
IRP主要数据项
IO_STATUS_BLOCKIoStatus
存放I/O请求的状态
PVOIDAssociatedIrp.SystemBuffer
如果设备执行缓冲I/O,则为指向系统空间缓冲区的指针。
否则为NULL
PMDLMdlAddress
如果设备执行直接I/O,指向用户空间缓冲区的内存描述表的指针
PVOIDUserBuffer
I/O缓冲区的用户空间地址
BOOLEANCancel
指示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请求,我们先来看看WIN32APIDeviceIoControl函数的原型。
BOOLDeviceIoControl(
HANDLEhDevice,//设备句柄
DWORDdwIoControlCode,//IOCTL请求操作代码
LPVOIDlpInBuffer,//输入缓冲区地址
DWORDnInBufferSize,//输入缓冲区大小
LPVOIDlpOutBuffer,//输出缓冲区地址
DWORDnOutBufferSize,//输出缓冲区大小
LPDWORDlpBytesReturned,//存放返回字节数的指针
LPOVERLAPPEDlpOverlapped//用于同步操作的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.DeviceIoControl.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对象的DeviceExtension的内容和数据结构。
开始驱动程序开发
驱动程序的开发是一个从粗到细逐步求精的过程。
NTDDK的src\目录下有一个庞大的样板代码,几乎覆盖了所有类型的设备驱动程序、高层驱动程序和过滤器驱动程序。
在开始开发你的驱动程序之前,你应该在这个样板库下面寻找是否有和你所要开发的类似类型的例程。
例如我们所开发的驱动程序,虽然DDK对USB描述得不是很详细,我们还是可以在src\storage\class目录发现很多和USB设备有关的驱动程序。
下面我们来看开发驱动程序的基本步骤。
最简的驱动程序框架
1、写一个DriverEntry例程,在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何 驱动程序