如何写驱动程序
我这里重点的介绍如何写驱动程序，对于一些应用程序我就不做介绍了，因为我对于那些高层的东西写得很少。倘若再讲，有班门弄斧之嫌，呵呵！
作为WIN98和WIN2K推荐的一项新技术来说，USB的驱动程序和以往的直接跟硬件打交道的WIN95的VXD的方式的驱动程序不同，它应该是WDM类型的。
USB的WDM接口框图如下（这个图可以说是USB软件总体框图）
对于HID的设备，就可以采用上图左上边的结构，其它类的话采用右上的结构，其实右边的结构可以又细分成两层，一层是Class Driver，一层是Miniport Driver。而倒数第三行的UHCD和OpenHCI分别是由INTEL和COMPAQ两位老大定的一个和硬件有关的底层驱动程序标准，各位可以根据所需要的选择。
对于USB的驱动程序，大家还得去了解WDM驱动程序的写法，或者早些时候的NT驱动程序，其实WDM驱动程序可以看做是NT驱动程序的一个update，只是增加了一些新的特性。
“写驱动程序是一个很漫长和繁琐的工作，在此之前，你最好要熟悉硬件，熟悉C/C++，还要用过DDK，会用一些调试程序，如SOFTICE和WINDBG之类。如果一切就绪，你就可以开始写驱动程序，工作的进程有时侯会取决于你的运气”。（这是一位留美的朋友对我说的，我写出来和大家共享）
下面是我从一个朋友那里得到的一篇文章的摘要：
NT驱动程序的分层结构
驱动程序是指管理某个外围设备的一段程序代码。NT采用更灵活的分层驱动方法，允许杂应用程序和硬件之间存在几个驱动程序层次。分层机制允许NT更加广泛地定义驱动程序，包括文件系统、逻辑卷管理器和各种网络组件，各种物理设备驱动程序等等。
1、设备驱动程序
这些是管理实际数据传输和控制特定类型的物理设备的操作的驱动程序，包括开始和完成I/O操作，处理中断和执行特定的设备要求的任何差错处理。
2、中间驱动程序
NT允许在物理设备驱动程序上分层任意数目的中间驱动程序。这些中间层次提供扩展I/O系统的功能一种方法，而不必修改底层的驱动程序。这也是微软鼓吹的他们的系统灵活的一面！实际上我觉得这样反而牺牲了一些效率上的东西。
3、文件系统驱动程序(FSD)
FSD是一类比较特殊的驱动程序，通常负责维护各种文件系统所需要的磁盘结构。注意我们并不能使用DDK来开发FSD，而必须使用Microsoft的文件系统开发人员工具包。
一般比较少写中间过滤驱动程序，过滤驱动程序它截获和修改高层发送给类驱动程序的请求。这样就允许利用现有类驱动程序的功能，而不必从头开始写所有程序。 NT内核模式对象在我们的实际开发过程中的对象是设备，由于端口驱动程序已经隐藏了硬件控制操作，因此我在这里不讲述跟硬件相关的部份。如果今后的开发对象不同，需要对硬件进行操作的时候，可能会对中断、DMA等有比较详细的了解，这些内容可以参考DDK帮助。
NT使用对象技术管理所有的数据，下面分别对一般驱动程序所涉及的一些对象做一介绍。不过在介绍这些对象之前，有必要先对驱动程序的结构做一介绍。
驱动程序结构
NT驱动程序和一般的DOS/Windows C语言程序不一样，它没有main()或者WinMain()函数入口。和DLL类似地，它向操作系统显露一个名称为DriverEntry()的函数，在启动驱动程序的时候，操作系统将调用这个入口。DriverEntry除了做一些必要的设备初始化工作外，还初始化一些Dispatch例程入口。我们知道，NT应用和设备驱动程序打交道主要是通过CreateFile、 ReadFile、WriteFile 和DeviceIoControl等Win32 API来进行的。这些API其实都对应着驱动程序的一些Dispatch例程。而驱动程序除了DriverEntry以外，主要就是由这些Dispatch例程组成的。例如调用Win32 API CreateFile的时候，操作系统最终转化为对驱动程序IRP_MJ_CREATE功能代码所对应的 Dispatch例程的调用，如果驱动程序没有提供该例程， CreateFile调用就会失败。
NT中一些常用的功能代码和Win32 API的对象关系如下所示。
功能代
码
说明
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 得到文件的长度GetFileLength
IRP_MJ_SET_INFORMATION 设置文件的长度SetFileLength
IRP_MJ_FLUSH_BUFFERS 写输出缓冲区或丢弃输入缓冲区
FlushFileBuffers
FlushConsoleInputBuffer
PurgeComm
IRP_MJ_SHUTDOWN 系统关闭InitialSystemShutdown
和上面的驱动程序支持的功能代码相对应，一般的驱动程序看起来就象下面的样子。
DriverEntry(…) // 驱动程序入口
{
…
DeviceObject->MajorFunction[IRP_MJ_CREATE] = XXDriverCreateClose; //XX 对应的是你自己给你的驱动程序的命名
DeviceObject->MajorFunction[IRP_MJ_CLOSE] = XXDriverCreateClose; DeviceObject->MajorFunction[IRP_MJ_READ] = XXDriverReadWrite; DeviceObject->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结构体的所有数据项，这里仅列出了一般驱动程序可能使用到的数据项。
在上面提到过驱动程序是管理同类型的所有设备，所以上面的结构中DeviceObject指向的就不是单个的设备对象，而是一个对象链表，这个链表的维护在下面介绍Device对象时可以看到。 Device对象与Device Extension 驱动程序在调用IoCreateDevice函数成功后就创建了一个Device 对象。下面对Device对象几个比较重要的数据做一介绍。
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!)[人一辈子真的很过瘾，有些人或有些事你明明不喜欢或做不来，可是有时侯你又不得不硬着头皮去做，就像一大堆球迷围着一堆狗屎般的中国足球，那班傻儿真是要钱不要脸，丢咱中国人的脸]
关于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 你的机器，你只好又装机，又调试，又死翘翘，你不见密西西比河不死心，又重来一遍，如此三番，惹得你无名火起，起身饮茶，又见隔壁部门的老板正和小蜜在讨论周末去哪里加班工作，不由的气不打一处出，大吼一声“呔，来将何人！洒家张翼德在此！”..........哎，人在老板下，哪能不干活，只有硬头再上.............无数次的失败，无数次的徒劳之后，终于让你的机器跑的欢极了，你不由的小哼一句“对面的小蜜看过来，这里的男孩很能干！”
驱动程序真的得看个人造化，若你有张无忌般奇遇，有韦小宝般艳福，有段舆般韧劲，（对了，还要有东方不败般的勇气）还有什么做不了的。哈哈！
驱动程序原理
知识体系结构 应用程序：是一段可以执行的代码，由操作系统管理。 编译原理，链接器，装载器：是对操作系统依赖的一个工具，将用户的代码变成可执行的机器码，编译器仅仅检查和翻译用户的语言逻辑，但并不装配成符合操作系统要求的可执行文件格式，如windows要求的EXE文件为PE格式（EXE文件并不仅仅是一个可执行的代码段，而且包含了很多其他的内容，如数据段）。 操作系统接口API：是一个可以被用户程序调用的系统功能接口，可以说，我们编写程序，除了计算和流程控制这些只需要用到CPU指令和CPU寄存器的代码外，其余要访问其他（硬件）资源（包括内存，外设）的代码，均是通过调用OS的API来操作除CPU外的资源的，如向屏幕写一个字母，对于程序来说简单得很，print(“A”); 但是其编译后执行的过程是复杂的，编译后的程序会调用操作系统的API，将当前应用程序的状态（上下文，如光标的位置）以及字母传递给显示器的驱动程序去显示。 操作系统管理与调度：操作系统要实现一般通用的资源管理，也要实现资源使用的协调，包含CPU，内存，磁盘，外设。 首先要确定为什么需要操作系统，操作系统设计的目标是什么？ 1．我们总是不能等做完一件事情才去做另外一件，因为有些事情做的过程需要等待，有时候也需要暂停一下当前的任务，先去处理更急的事情，等我回来 时又需要以前的任务保持当时的状态，所以需要计算机也要具备这样的能 力，那怎么实现呢？ 2．CPU和内存是计算机的最需要的资源，就如我们的人脑一样，一般很难在同一时间做两件事情。需要处理好一件事情再处理另一件，如果处理得越快就 越好，但是不能前一件事情要等待，你就休息了，后面一件也做不了，计算 机的办法就是你不用CPU了，那好你等待下，我先处理下一个事情。 3．我们写程序，不可能对每个应用，我们重新去写那些驱动程序，也不可能按照自己的想法去处理这些通常的资源管理。否则很多人各自写的应用软件就 没法在一个电脑上运行。 操作系统目标： 1．实现代码重用，对于硬件的访问，对于CPU和内存的充分利用，使不同的应用不需要重新去写这些代码。 2．实现各个任务（不同应用程序）的协调使用，使用户可以实现暂停、重新启用某个任务。 3．实现数据的安全管理，实现良好的人机界面的管理。 4．实现一个开放的体系结构，提供系统调用使用户可以快速编写自己的应用，并提供编译器、链接器、装载器来让用户编写的程序变成可以与操作系统接口的 可执行软件。 操作系统的功能分层： CPU管理是操作系统的核心：操作系统与用户程序其实可以看成是一个程序，与以前的单任务系统和单片机程序没有本质的区别。 我们来看整个PC机运行过程: 1．系统上电。 2．主板上CPU的CS值设置为0Fx000，IP值设置为0xFFF0，这样CS:IP就指向0xFFFF0位置，这个是程序的开始地址，而硬件上在总线上挂接在0xFFFF0地址 的是主板的BIOS芯片，BIOS开始运行，BIOS是Basic Input Output System简写， 意思即基本的输入输出系统，如果学过单片机就很好理解，其实就是一个程序，由主
什么是驱动程序资料
什么是驱动程序？ 驱动程序扮演沟通的角色，把硬件的功能告诉电脑系统，并且也将系统的指令传达给硬件，让它开始工作。 年轻人最大的动力，或者最大的优势就在于，你一旦想做什么你就马上去做。说这是天真也好，甚至对一些事情的无知也好，有这种勇气和决心就应该去做。” 什么是BSP？ BSP是板级支持包，是介于主板硬件和操作系统之间的一层，应该说是属于操作系统的一部分,主要目的是为了支持操作系统，使之能够更好的运行于硬件主板。BSP是相对于操作系统而言的，不同的操作系统对应于不同定义形式的BSP,例如VxWorks的BSP和Linu x的BSP相对于某一CPU来说尽管实现的功能一样，可是写法和接口定义是完全不同的，所以写BSP一定要按照该系统BSP的定义形式来写（BSP的编程过程大多数是在某一个成型的BSP模板上进行修改），这样才能与上层OS保持正确的接口，良好的支持上层OS。 例如：在VxWorks中的网卡驱动，首先在config.h中包含该网卡，然后将网卡含网卡信息的参数放入数组END_TBL_ENTRY endDevTbl [ ] 中，系统通过函数muxDevLoad ( )调用这个数组来安装网卡驱动。而在Linux中的网卡驱动，是在space.c中声明该网络设备，再把网卡驱动的一些函数加到dev结构中，由函数ether_setup（）来完成网卡驱动的安装。 纯粹的BSP所包含的内容一般说来是和系统有关的驱动和程序，如网络驱动和系统中网络协议有关，串口驱动和系统下载调试有关等等。离开这些驱动系统就不能正常工作。 用户也可以添加自己的程序到BSP中，但严格来说不应该算BSP.一般来说这种做法不建议。因为一旦操作系统能良好运行于最终的主板硬件后，BSP也就固定了，不需要做任何改动。而用户自己在BSP中的程序还会不断的升级更新，这样势必对BSP有不好的影响，对系统造成影响，同时由于BSP调试编译环境较差，也不利于程序的编译调试。 如何编写Linux设备驱动程序 Linux是Unix操作系统的一种变种，在Linux下编写驱动程序的原理和思想完全类似于其他的Unix系统，但它和dos或window环境下的驱动程序有很大的区别。在Linux环境下设计驱动程序，思想简洁，操作方便，功能也很强大，但是支持函数少，只能依赖kerne l中的函数，有些常用的操作要自己来编写，而且调试也不方便。 一、Linux device driver 的概念
usb驱动程序教程
编写Windows https://www.sodocs.net/doc/7017805747.html,的usb驱动程序教程 Windows https://www.sodocs.net/doc/7017805747.html, 是微软推出的功能强大的嵌入式操作系统，国内采用此操作系统的厂商已经很多了，本文就以windows https://www.sodocs.net/doc/7017805747.html,为例，简单介绍一下如何开发windows https://www.sodocs.net/doc/7017805747.html, 下的USB驱动程序。 Windows https://www.sodocs.net/doc/7017805747.html, 的USB系统软件分为两层： USB Client设备驱动程序和底层的Windows CE实现的函数层。USB设备驱动程序主要负责利用系统提供的底层接口配置设备，和设备进行通讯。底层的函数提本身又由两部分组成，通用串行总线驱动程序（USBD）模块和较低的主控制器驱动程序（HCD）模块。HCD负责最最底层的处理，USBD模块实现较高的USBD函数接口。USB设备驱动主要利用 USBD接口函数和他们的外围设备打交道。 USB设备驱动程序主要和USBD打交道，所以我们必须详细的了解USBD提供的函数。 主要的传输函数有： abourttransfer issuecontroltransfer closetransfer issuein te rruptransfer getisochresult issueisochtransfer gettransferstatus istransfercomplete issuebulktransfer issuevendortransfer 主要的用于打开和关闭usbd和usb设备之间的通信通道的函数有： abortpipetransfers closepipe isdefaultpipehalted ispipehalted openpipe resetdefaultpipe resetpipe 相应的打包函数接口有： getframelength getframenumber releaseframelengthcontrol setframelength takeframelengthcontrol 取得设置设备配置函数： clearfeature setdescriptor getdescriptor setfeature
字符设备驱动程序课程设计报告
中南大学 字符设备驱动程序 课程设计报告 姓名：王学彬 专业班级：信安1002班 学号：0909103108 课程：操作系统安全课程设计 指导老师：张士庚 一、课程设计目的 1.了解Linux字符设备驱动程序的结构； 2.掌握Linux字符设备驱动程序常用结构体和操作函数的使用方法； 3.初步掌握Linux字符设备驱动程序的编写方法及过程； 4.掌握Linux字符设备驱动程序的加载方法及测试方法。 二、课程设计内容 5.设计Windows XP或者Linux操作系统下的设备驱动程序; 6.掌握虚拟字符设备的设计方法和测试方法；
7.编写测试应用程序，测试对该设备的读写等操作。 三、需求分析 3.1驱动程序介绍 驱动程序负责将应用程序如读、写等操作正确无误的传递给相关的硬件，并使硬件能够做出正确反应的代码。驱动程序像一个黑盒子，它隐藏了硬件的工作细节，应用程序只需要通过一组标准化的接口实现对硬件的操作。 3.2 Linux设备驱动程序分类 Linux设备驱动程序在Linux的内核源代码中占有很大的比例，源代码的长度日益增加，主要是驱动程序的增加。虽然Linux内核的不断升级，但驱动程序的结构还是相对稳定。 Linux系统的设备分为字符设备(char device)，块设备(block device)和网络设备(network device)三种。字符设备是指在存取时没有缓存的设备，而块设备的读写都有缓存来支持，并且块设备必须能够随机存取(random access)。典型的字符设备包括鼠标，键盘，串行口等。块设备主要包括硬盘软盘设备，CD-ROM等。 网络设备在Linux里做专门的处理。Linux的网络系统主要是基于BSD unix的socket 机制。在系统和驱动程序之间定义有专门的数据结构(sk_buff)进行数据传递。系统有支持对发送数据和接收数据的缓存，提供流量控制机制，提供对多协议的支持。 3.3驱动程序的结构 驱动程序的结构如图3.1所示，应用程序经过系统调用，进入核心层，内核要控制硬件需要通过驱动程序实现，驱动程序相当于内核与硬件之间的“系统调用”。
USB驱动程序编写
USB驱动程序编写 linux下usb驱动编写（内核2.4）——2.6与此接口有区别2006-09-15 14:57我们知道了在Linux 下如何去使用一些最常见的USB设备。但对于做系统设计的程序员来说，这是远远不够的，我们还需要具有驱动程序的阅读、修改和开发能力。在此下篇中，就是要通过简单的USB驱动的例子，随您一起进入USB驱动开发的世界。 USB骨架程序（usb-skeleton），是USB驱动程序的基础，通过对它源码的学习和理解，可以使我们迅速地了解USB驱动架构，迅速地开发我们自己的USB硬件的驱动。 USB驱动开发 在掌握了USB设备的配置后，对于程序员，我们就可以尝试进行一些简单的USB驱动的修改和开发了。这一段落，我们会讲解一个最基础USB框架的基础上，做两个小的USB驱动的例子。 USB骨架 在Linux kernel源码目录中driver/usb/usb-skeleton.c为我们提供了一个最基础的USB驱动程序。我们称为USB骨架。通过它我们仅需要修改极少的部分，就可以完成一个USB设备的驱动。我们的USB驱动开发也是从她开始的。 那些linux下不支持的USB设备几乎都是生产厂商特定的产品。如果生产厂商在他们的产品中使用自己定义的协议，他们就需要为此设备创建特定的驱动程序。当然我们知道，有些生产厂商公开他们的USB协议，并帮助Linux驱动程序的开发，然而有些生产厂商却根本不公开他们的USB协议。因为每一个不同的协议都会产生一个新的驱动程序，所以就有了这个通用的USB驱动骨架程序，它是以pci 骨架为模板的。 如果你准备写一个linux驱动程序，首先要熟悉USB协议规范。USB主页上有它的帮助。一些比较典型的驱动可以在上面发现，同时还介绍了USB urbs的概念，而这个是usb驱动程序中最基本的。 Linux USB 驱动程序需要做的第一件事情就是在Linux USB 子系统里注册，并提供一些相关信息，例如这个驱动程序支持那种设备，当被支持的设备从系统插入或拔出时，会有哪些动作。所有这些信息都传送到USB 子系统中，在usb骨架驱动程序中是这样来表示的： static struct usb_driver skel_driver = { name: skeleton, probe: skel_probe, disconnect: skel_disconnect, fops: &skel_fops, minor: USB_SKEL_MINOR_BASE, id_table: skel_table,
USB驱动程序源代码
项目报告7 USB驱动程序源代码作者：罗仕波 一．头文件go7007sb.h /* *go7007sb.h - this file includes all relative header files that *will be used in go7007sb vedio usb interface driver, and it *also defines all relative driver private data structures and *it's io control commands. */ #ifndef _GO7007SB_H #define _GO7007SB_H #include
linux驱动程序的编写
linux驱动程序的编写 一、实验目的 1.掌握linux驱动程序的编写方法 2.掌握驱动程序动态模块的调试方法 3.掌握驱动程序填加到内核的方法 二、实验内容 1. 学习linux驱动程序的编写流程 2. 学习驱动程序动态模块的调试方法 3. 学习驱动程序填加到内核的流程 三、实验设备 PentiumII以上的PC机，LINUX操作系统，EL-ARM860实验箱 四、linux的驱动程序的编写 嵌入式应用对成本和实时性比较敏感，而对linux的应用主要体现在对硬件的驱动程序的编写和上层应用程序的开发上。 嵌入式linux驱动程序的基本结构和标准Linux的结构基本一致，也支持模块化模式，所以，大部分驱动程序编成模块化形式，而且，要求可以在不同的体系结构上安装。linux是可以支持模块化模式的，但由于嵌入式应用是针对具体的应用，所以，一般不采用该模式，而是把驱动程序直接编译进内核之中。但是这种模式是调试驱动模块的极佳方法。 系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节,这样在应用程序看来,硬件设备只是一个设备文件,应用程序可以像操作普通文件一样对硬件设备进行操作。同时,设备驱动程序是内核的一部分,它完成以下的功能:对设备初始化和释放;把数据从内核传送到硬件和从硬件读取数据;读取应用程序传送给设备文件的数据和回送应用程序请求的数据;检测和处理设备出现的错误。在linux操作系统下有字符设备和块设备，网络设备三类主要的设备文件类型。 字符设备和块设备的主要区别是:在对字符设备发出读写请求时,实际的硬件I/O一般就紧接着发生了;块设备利用一块系统内存作为缓冲区,当用户进程对设备请求满足用户要求时,就返回请求的数据。块设备是主要针对磁盘等慢速设备设计的,以免耗费过多的CPU时间来等待。 1 字符设备驱动结构 Linux字符设备驱动的关键数据结构是cdev和file_operations结构体。
USB设备驱动程序设计
USB设备驱动程序设计 引言 USB 总线是1995 年微软、IBM 等公司推出的一种新型通信标准总线， 特点是速度快、价格低、独立供电、支持热插拔等，其版本从早期的1.0、1.1 已经发展到目前的2.0 版本，2.0 版本的最高数据传输速度达到480Mbit/s，能 满足包括视频在内的多种高速外部设备的数据传输要求，由于其众多的优点，USB 总线越来越多的被应用到计算机与外设的接口中，芯片厂家也提供了多种USB 接口芯片供设计者使用，为了开发出功能强大的USB 设备，设计者往往 需要自己开发USB 设备驱动程序，驱动程序开发一直是Windows 开发中较难 的一个方面，但是通过使用专门的驱动程序开发包能减小开发的难度，提高工 作效率，本文使用Compuware Numega 公司的DriverStudio3.2 开发包，开发了基于NXP 公司USB2.0 控制芯片ISP1581 的USB 设备驱动程序。 USB 设备驱动程序的模型 USB 设备驱动程序是一种典型的WDM(Windows Driver Model)驱动程序，其程序模型如图1 所示。用户应用程序工作在Windows 操作系统的用户模式层，它不能直接访问USB 设备，当需要访问时，通过调用操作系统的 API(Application programming interface)函数生成I/O 请求信息包(IRP)，IRP 被传输到工作于内核模式层的设备驱动程序，并通过驱动程序完成与UBS 外设通 信。设备驱动程序包括两层：函数驱动程序层和总线驱动程序层，函数驱动程 序一方面通过IRP 及API 函数与应用程序通信，另一方面调用相应的总线驱动 程序，总线驱动程序完成和外设硬件通信。USB 总线驱动程序已经由操作系统 提供，驱动程序开发的重点是函数驱动程序。 USB 设备驱动程序的设计
未能成功安装设备驱动程序MTPUSB设备安装失败的解决办法
未能成功安装设备驱动程序M T P U S B设备安装失败的解决办法 文件编码（GHTU-UITID-GGBKT-POIU-WUUI-8968）
M T P U S B设备安装失败未能成功安装设备驱动程序 终极解决方法 环境介绍：电脑系统win7（32位）已安装摩托罗拉手机驱动版本（其他版本应该也行，不行的话去摩托罗拉官网下载最新驱动） 手机型号：摩托罗拉defy mb525（系统） 备注：其他电脑操作系统和不同型号手机可参考此方法，找到相应设置项即可。 问题简介： 1.当我们把手机连接至电脑，把模式调制成“摩托罗拉手机门户”时，出现下列情况 2.过一会之后便会弹出提示说：未能成功安装设备驱动程序
3.单击查看详情便弹出窗口如下图所示： 4.此时桌面右下角图标出现黄色三角号，如图所示： 5.于是我们就开始不淡定了，怎么看怎么别扭、抓狂、按耐不住。下面介绍问题解决方案 解决方法： 1.我的电脑——右键单击——管理——设别管理器，之后会看到如图所示：在便携设备下有黄色三角号提示，即是我们纠结的MTP USB设备安装不成功的展示。
MIUI手机操作系统为例，其他手机操作系统需将USB绑定服务开启即可）。选择设置——系统——共享手机网络——USB绑定，将该选项设置为“开”，这是你会发现如图所示变化，在设备管理器面板中没有了便携设备选项及黄色三角号提醒，如图所示：（但桌面右下角的黄色三角警示还在）
3.在完成以上步骤后，用手机打开WIFI并登录无线WLAN，手机打开网页检验连接是否正常，若正常则如下图所示，黄色三角号警示消失，问题解决；若以上步骤没有解决问题，请先连接WIFI并登录WLAN之后，再按步骤操作。 4.完成以上步骤并解决问题后，选择电脑桌面网络——右键单击——属性，如下图所示：此时不仅手机能上网，而且电脑也能正常连接网络，正常上网。（我的体验是连接数据不稳定，时不时的要手机重新登陆WIFI，才有数据传输，可能是高校WLAN的问题，在家网速快的可以尝试一下） 5.通过这个问题的解决，我才知道原来MTP USB设备安装失败，未能成 功安装设备驱动程序的原因是我们手机里面没有启用该设备服务。今天 才知道MTP USB设备是与手机里的共享手机网络中“USB绑定”服务相关 联的，是电脑用来使用手机WIFI网络连接进行上网的工具。
最新开发usb驱动程序的方法连载一
最新开发usb驱动程序的方法连载一 开发usb驱动程序的方法（连载二） 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, // 存放返回字节数的指针
USB驱动程序的编写采用WDM驱动程序
U S B驱动程序的编写采用W D M驱动程序 Document serial number【UU89WT-UU98YT-UU8CB-UUUT-UUT108】
USB驱动程序的编写采用WDM 驱动程序。WDM 驱动程序是一些例程的集合，它们被动地存在，等待主机系 统软件（PnP 管理器、I/O 管理器、电源管理器等）来调用或激活它们。具体驱动程序不同，其所包含 的例程也不同。一个WDM 驱动程序的基本组成包括以下5个例程：（1）驱动程序入口例程：处理驱动程序的初始化。 （2）即插即用例程：处理PnP 设备的添加、删除和停止。 （3）分发例程：处理用户应用程序发出的各种 I/O 请求。 （4）电源管理例程：处理电源管理请求。 （5）卸载例程：处理驱动程序的卸载。 包含文件： , , , , , makefile,sources) 在文件中，包含了上述五个例程： 中定义了各种数据结构还有各种IOCTL控制码，用于不同数据的读写。
中实现了各种驱动例程。包含了上述五个所说例程外还包含了其他例程，课程从下面的驱动 程序入口例程得出一些信息。 驱动程序入口例程： NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath ) { NTSTATUS ntStatus = STATUS_SUCCESS; PDEVICE_OBJECT deviceObject = NULL; DriverObject->MajorFunction[IRP_MJ_CREATE] = Ezusb_Create; DriverObject->MajorFunction[IRP_MJ_CLOSE] = Ezusb_Close; ources. If you want to add a new source # file to this
编译hello设备驱动程序详细过程
编译hello world设备驱动程序详细过程 1、安装与你的开发板相同的内核版本的虚拟机，我的板子内核是2.6.8.1，虚拟机是2.6.9， 一般是虚拟机的内核只能比板子内核新，不能旧 #uanme –a [1](在任何目录下，输入此命令，查看虚拟机的内核版本，我的内核版本是2.6.9) 2、在虚拟机上设置共享目录，我的共享目录在linux下的/mnt/hgfs/share [2]share是自己命名的，我的物理机上，即Windows下的目录是G:/share, 3、在Windows下，把开发板的的交叉开发工具链[3]，内核源码包[4]，复制到物理机的共享目录下[5] 即Windows下的目录是G:/share, 4、#cp /mnt/hgfs/share/cross-3.3.2.tar.bz2 /usr/local/arm [6] 在Linux下，把交叉工具链，复制到/usr/local/arm目录下 5、#cd /usr/local/arm 6、#tar jxvf cross-3.3.2.tar.bz2 [7] 并在当前目录/usr/local/arm下解压它cross-2.95.3.tar.bz2和gec2410-linux-2.6.8.tar.bz2也是用同样的命令去解压 7、#export PATH=/usr/local/arm/3.3.2/bin:$PATH [8] 安装交叉工具链，在需要使用交叉编译时，只要在终端输入如下命令 #export PATH=/usr/local/arm/版本/bin:$PATH 即可，在需要更改不同版本的工具链时，重新启动一个终端，然后再一次输入上面的命令即可，使用哪个版本的交叉工具链，视你要编译的内核版本决定，编译2.4版本的内核，则用2.95.3版本的交叉工具链，而2.6版本内核的，则要用3.3.2版本的交叉工具链。 8、#cp gec2410-linux-2.6.8.tar.bz2 /root [9]把内核拷贝到/root目录下， 9、#cd /root 10、#tar gec2410-linux-2.6.8.tar.bz2 [10] 在/root解压开发板的内核源码压缩包gec2410-linux-2.6.8.tar.bz2，得到gec2410-linux-2.6.8.1文件夹 11、#cd /root/ gec2410-linux-2.6.8.1 12、#cp gec2410.cfg .config [11] gec2410.cfg文件是广嵌开发板提供的默认内核配置文件，在这里首先把内核配置成默认配置，然后在此基础上用make menuconfig进一步配置，但在这里，不进行进一步的配置，对于内核配置，还需要看更多的知识，在这里先存疑。 13、#make [12]在内核源代码的根目录gec2410-linux-2.6.8.1下用make命令编译内核，注意，先安装交叉工具链，再编译内核，因为这里编译的hello.ko驱动模块最终是下载到开发板上运行的，而不是在虚拟机的Linux系统运行的，如果是为了在虚拟机的Linux系统运行的，则不用安装交叉编译工具链arm-linux-gcc,而直接用gcc,用命令#arm-linux-gcc –v 可以查看当前已经安装的交叉编译工具链的版本。这里编译内核不是为了得到内核的映象文件zImage（虽然会得到内核的映象文件zImage），而是为了得到编译hello.o模块需要相关联，相依赖(depends on)的模块。 14、#cd /root 12、#mkdir hello [13]在/root目录下建立hello文件夹， 13、#cd hel 14 、#vi hello.c [12]编辑hello.c文件,内容是《Linux设备驱动程序》第三版22页的hello world程序。 15、#vi Makefile [13]在hello文件夹下编辑Makefile文件， 16、obj-m := module.o [14] 这是Makefile的内容，为obj-m := module.omodule.o视你编辑的.c文件而定，这里则要写成hello.o，写完后，保存退出。 17、cd /root/hello
开发usb驱动程序的方法(连载一)
开发usb驱动程序的方法（连载一） 开始驱动程序设计 下面的文字是从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_CREA TE请求的Dispatch例程的基本框架 (参见DDK Kernel-Mode Drivers 4.4.3描述的一个DispatchCreate 例程所要完成的最基本工作。当然写了DispatchCreate例程后，要在DriverEntry 例程为IRP_MJ_CREA TE初始化例程入口)。如果驱动程序创建了多于一个Device对象，则必须为IRP_MJ_CLOSE 请求写一个例程，该例程通常情况下可以和DispatchCreate共用一个例程，参见参见DDK Kernel-Mode Drivers 4.4.3。 3、编译连接你的驱动程序。
USB WDM 设备驱动程序
USB WDM 设备驱动程序DriverStudio 引言 随着微机技术水平的日益提高，传统的计算接口已经不能满足当前计算机高速发展的需求，计算机业界迫切需要新的通用型、高速总线接口。通用外设接口标准USB应运而生。USB,全称为通用串行总线（Universal Serial Bus），它是Compaq、IBM等PC大厂商联合开发的一种新型的、基于令牌的、高速的串行总线标准。开发者要设计USB设备接口，就必须首先了解USB协议，在此基础上有针对性的开发USB设备驱动程序。 USB简介 在众多的PC机总线中，USB以其突出的优点独树一帜：①使用方便。支持热拔插，不涉及中断请求（IRQ）冲突等问题，能真正做到“即插即用”。②传输速率高。目前的USB 2.0协议速度高达480Mbps 。③易于扩展。通过使用Hub扩展可连接多达127个外设。④使用灵活。USB共有４种传输模式：控制(control)、同步(Synchronization)、中断(interrupt)、批量(bulk)，以适应不同设备的需要。⑤独立供电。正由于上述优点，开发USB接口的设备已成为一种发展趋势。 一个完整的USB系统包括主机系统和USB设备。所有的传输事务都是由主机发起的。一个主机系统又可以分为以下几个层次结构，如图1所示：
图1 USB 互连通信模型 USB总线接口包括USB主控制器和根集线器，其中USB主控制器负责处理主机与设备之间电气和协议层的互连，根集线器提供USB设备连接点。USB系统使用USB主控制器来管理主机和USB设备之间的数据传输，另外它也负责管理USB资源,如带宽等。应用软件不能直接访问USB设备硬件，而通过USB系统和USB总线接口与USB设备进行交互。 USB设备包含一些向主机软件提供一系列USB设备的特征和能力的信息的设备描述符，用来配置设备和定位USB设备驱动程序。这些信息确保了主机以正确的方式访问设备。通常，一个设备有一个或多个配置(Configuration)来控制其行为。配置是接口(Interface)的集合，接口指出软件应该如何访问硬件。接口又是端点(endpoint)的集合，每一个与USB交换数据的硬件就为端点，它是作为通信管道的一个终点。图1显示了一个多层次结构的通信模型，它表明了端点和管道所扮演的角色。 WDM驱动程序和USB驱动程序的分层结构 设备驱动程序实际上是指一系列控制硬件设备的函数，是操作系统中控制和连接硬件的关键模块。它提供连接到计算机的硬件设备的软件接口。
USB键盘驱动程序
/* * $Id: usbkbd.c,v 1.27 2001/12/27 10:37:41 vojtech Exp $ * * Copyright (c) 1999-2001 Vojtech Pavlik * * USB HIDBP Keyboard support */ /* * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * * Should you need to contact me, the author, you can do so either by * e-mail - mail your message to <>, or by paper mail: * Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic */ #include
一个简单字符设备驱动实例
如何编写Linux设备驱动程序 Linux是Unix操作系统的一种变种，在Linux下编写驱动程序的原理和思想完全类似于其他的Unix系统，但它dos或window环境下的驱动程序有很大的区别。在Linux环境下设计驱动程序，思想简洁，操作方便，功能也很强大，但是支持函数少，只能依赖kernel中的函数，有些常用的操作要自己来编写，而且调试也不方便。本文是在编写一块多媒体卡编制的驱动程序后的总结，获得了一些经验，愿与Linux fans共享，有不当之处，请予指正。 以下的一些文字主要来源于khg，johnsonm的Write linux device driver，Brennan's Guide to Inline Assembly，The Linux A-Z，还有清华BBS上的有关device driver的一些资料. 这些资料有的已经过时，有的还有一些错误，我依据自己的试验结果进行了修正. 一、Linux device driver 的概念 系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能： 1）对设备初始化和释放； 2）把数据从内核传送到硬件和从硬件读取数据； 3）读取应用程序传送给设备文件的数据和回送应用程序请求的数据； 4）检测和处理设备出现的错误。 在Linux操作系统下有两类主要的设备文件类型，一种是字符设备，另一种是块设备。字符设备和块设备的主要区别是：在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O操作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待. 已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备。另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序. 最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。 二、实例剖析 我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理.把下面的C代码输入机器，你就会获得一个真正的设备
相关文档
- USB驱动程序的编写采用WDM驱动程序
- 驱动编写流程图 (精炼)
- 12864液晶经典驱动程序,一看就懂,有详细的注释(C语言编写,不看后悔)
- cs5550 c语言驱动读写程序
- 驱动程序原理
- 通过 Windows 驱动程序框架编写驱动程序
- 如何编写一个显卡的驱动程序
- 教你学会写驱动程序
- 网卡底层驱动程序的编写
- Windows982000驱动程序编写方法
- 板卡驱动 c VxD驱动程序编写方法与实例
- 如何写驱动程序
- 10嵌入式操作系统驱动程序编写基础
- Windows驱动程序设计入门
- 附录_整套24c16单片机读写驱动程序
- (完整word版)驱动程序原理
- 设备驱动程序
- linux驱动程序的编写
- CVI驱动程序编写入门
- 驱动程序设计