如何编写驱动程序？

如何编写Linux设备驱动程序

回想学习Linux *** 作系统已经有近一年的时间了，前前后后，零零碎碎的一路学习过来，也该试着写的东西了。也算是给自己能留下一点记忆和回忆吧！由于完全是自学的，以下内容若有不当之处，还请大家多指教。

Linux是Unix *** 作系统的一种变种，在Linux下编写驱动程序的原理和思想完全类似于其他的Unix系统，但它dos或window环境下的驱动程序有很大的区别。在Linux环境下设计驱动程序，思想简洁， *** 作方便，功能也很强大，但是支持函数少，只能依赖kernel中的函数，有些常用的 *** 作要自己来编写，而且调试也不方便。

以下的一些文字主要来源于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 *** 作系统下的设备驱动程序

二、实例剖析

我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。

#define __NO_VERSION__

#include modules.h>

#include version.h>

char kernel_version [] = UTS_RELEASE

这一段定义了一些版本信息，虽然用处不是很大，但也必不可少。Johnsonm说所有的驱动程序的开头都要包含config.h>，一般来讲最好使用。

由于用户进程是通过设备文件同硬件打交道，对设备文件的 *** 作方式不外乎就是一些系统调用，如 open，read，write，close…， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：

struct file_operations

{

int (*seek) (struct inode * ，struct file *， off_t ，int)

int (*read) (struct inode * ，struct file *， char ，int)

int (*write) (struct inode * ，struct file *， off_t ，int)

int (*readdir) (struct inode * ，struct file *， struct dirent * ，int)

int (*select) (struct inode * ，struct file *， int ，select_table *)

int (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long)

int (*mmap) (struct inode * ，struct file *， struct vm_area_struct *)

int (*open) (struct inode * ，struct file *)

int (*release) (struct inode * ，struct file *)

int (*fsync) (struct inode * ，struct file *)

int (*fasync) (struct inode * ，struct file *，int)

int (*check_media_change) (struct inode * ，struct file *)

int (*revalidate) (dev_t dev)

}

这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write *** 作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。

下面就开始写子程序。

#include types.h>

#include fs.h>

#include mm.h>

#includeconfig.h>

#include errno.h>

#include segment.h>

unsigned int test_major = 0

static int read_test(struct inode *node，struct file *file，char *buf，int count)

{

int left

if (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )

return -EFAULT

for(left = count left >0 left--)

{

__put_user(1，buf，1)

buf++

}

return count

}

这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考Robert著的《Linux内核设计与实现》（第二版）。然而，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。

static int write_tibet(struct inode *inode，struct file *file，const char *buf，int count)

{

return count

}

static int open_tibet(struct inode *inode，struct file *file )

{

MOD_INC_USE_COUNT

return 0

}

static void release_tibet(struct inode *inode，struct file *file )

{

MOD_DEC_USE_COUNT

}

这几个函数都是空 *** 作。实际调用发生时什么也不做，他们仅仅为下面的结构提供函数指针。

struct file_operations test_fops = {

NULL，

read_test，

write_test，

NULL， /* test_readdir */

NULL，

NULL， /* test_ioctl */

NULL， /* test_mmap */

open_test，

release_test，

NULL， /* test_fsync */

NULL， /* test_fasync */

/* nothing more， fill with NULLs */

}

这样，设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(modules)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。

int init_module(void)

{

int result

result = register_chrdev(0， "test"， &test_fops)

if (result <0) {

printk(KERN_INFO "test: can't get major number\n")

return result

}

if (test_major == 0) test_major = result/* dynamic */

return 0

}

在用insmod命令将编译好的模块调入内存时，init_module 函数被调用。在这里，init_module只做了一件事，就是向系统的字符设备表登记了一个字符设备。register_chrdev需要三个参数，参数一是希望获得的设备号，如果是零的话，系统将选择一个没有被占用的设备号返回。参数二是设备文件名，参数三用来登记驱动程序实际执行 *** 作的函数的指针。

如果登记成功，返回设备的主设备号，不成功，返回一个负值。

void cleanup_module(void)

{

unregister_chrdev(test_major，"test")

}

在用rmmod卸载模块时，cleanup_module函数被调用，它释放字符设备test在系统字符设备表中占有的表项。

一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。

下面编译 :

$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c

得到文件test.o就是一个设备驱动程序。

如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后

ld -r file1.o file2.o -o modulename。

驱动程序已经编译好了，现在把它安装到系统中去。

$ insmod –f test.o

如果安装成功，在/proc/devices文件中就可以看到设备test，并可以看到它的主设备号。要卸载的话，运行 :

$ rmmod test

下一步要创建设备文件。

mknod /dev/test c major minor

c 是指字符设备，major是主设备号，就是在/proc/devices里看到的。

用shell命令

$ cat /proc/devices

就可以获得主设备号，可以把上面的命令行加入你的shell script中去。

minor是从设备号，设置成0就可以了。

我们现在可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。

#include

#include types.h>

#include stat.h>

#include

main()

{

int testdev

int i

char buf[10]

testdev = open("/dev/test"，O_RDWR)

if ( testdev == -1 )

{

printf("Cann't open file \n")

exit(0)

}

read(testdev，buf，10)

for (i = 0i <10i++)

printf("%d\n"，buf[i])

close(testdev)

}

编译运行，看看是不是打印出全1 ？

以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，DMA，I/O port等问题。这些才是真正的难点。请看下节，实际情况的处理。

如何编写Linux *** 作系统下的设备驱动程序

　三、设备驱动程序中的一些具体问题

1。 I/O Port。

和硬件打交道离不开I/O Port，老的ISA设备经常是占用实际的I/O端口，在linux下， *** 作系统没有对I/O口屏蔽，也就是说，任何驱动程序都可对任意的I/O口 *** 作，这样就很容易引起混乱。每个驱动程序应该自己避免误用端口。

有两个重要的kernel函数可以保证驱动程序做到这一点。

1）check_region(int io_port， int off_set)

这个函数察看系统的I/O表，看是否有别的驱动程序占用某一段I/O口。

参数1：I/O端口的基地址，

参数2：I/O端口占用的范围。

返回值：0 没有占用， 非0，已经被占用。

2）request_region(int io_port， int off_set，char *devname)

如果这段I/O端口没有被占用，在我们的驱动程序中就可以使用它。在使用之前，必须向系统登记，以防止被其他程序占用。登记后，在/proc/ioports文件中可以看到你登记的I/O口。

参数1：io端口的基地址。

参数2：io端口占用的范围。

参数3：使用这段io地址的设备名。

在对I/O口登记后，就可以放心地用inb()， outb()之类的函来访问了。

在一些pci设备中，I/O端口被映射到一段内存中去，要访问这些端口就相当于访问一段内存。经常性的，我们要获得一块内存的物理地址。

2。内存 *** 作

在设备驱动程序中动态开辟内存，不是用malloc，而是kmalloc，或者用get_free_pages直接申请页。释放内存用的是kfree，或free_pages。 请注意，kmalloc等函数返回的是物理地址！

注意，kmalloc最大只能开辟128k-16，16个字节是被页描述符结构占用了。

内存映射的I/O口，寄存器或者是硬件设备的RAM(如显存)一般占用F0000000以上的地址空间。在驱动程序中不能直接访问，要通过kernel函数vremap获得重新映射以后的地址。

另外，很多硬件需要一块比较大的连续内存用作DMA传送。这块程序需要一直驻留在内存，不能被交换到文件中去。但是kmalloc最多只能开辟128k的内存。

这可以通过牺牲一些系统内存的方法来解决。

3。中断处理

同处理I/O端口一样，要使用一个中断，必须先向系统登记。

int request_irq(unsigned int irq ，void(*handle)(int，void *，struct pt_regs *)，

unsigned int long flags， const char *device)

irq: 是要申请的中断。

handle：中断处理函数指针。

flags：SA_INTERRUPT 请求一个快速中断，0 正常中断。

device：设备名。

如果登记成功，返回0，这时在/proc/interrupts文件中可以看你请求的中断。

4。一些常见的问题。

对硬件 *** 作，有时时序很重要（关于时序的具体问题就要参考具体的设备芯片手册啦！比如网卡芯片RTL8139）。但是如果用C语言写一些低级的硬件 *** 作的话，gcc往往会对你的程序进行优化，这样时序会发生错误。如果用汇编写呢，gcc同样会对汇编代码进行优化，除非用volatile关键字修饰。最保险的办法是禁止优化。这当然只能对一部分你自己编写的代码。如果对所有的代码都不优化，你会发现驱动程序根本无法装载。这是因为在编译驱动程序时要用到gcc的一些扩展特性，而这些扩展特性必须在加了优化选项之后才能体现出来。

写在后面：学习Linux确实不是一件容易的事情，因为要付出很多精力，也必须具备很好的C语言基础；但是，学习Linux也是一件非常有趣的事情，它里面包含了许多高手的智慧和“幽默”，这些都需要自己亲自动手才能体会到，O(∩_∩)O~哈哈！

开发虚拟串口驱动程序

虚拟串口就是当本地并没有对应的串口硬件设备，而为应用层提供串口设备一样的系统调用接口，以兼容原本使用本地串口的应用软件的“虚”设备。本文作者给出了一种在Windows平台上实现虚拟串口的方法，由此实现的“串口”具有真实串口完全相同的系统调用接口。

在很多应用中需要用到虚拟串口，如在Modem卡出现之前，已经有了接在计算机串口上的外部Modem，而且各种拔号程序也是通过串口与外部Modem通信的。为了让已有的拔号程序不做修改,像使用外部Modem一样使用内置卡，就需要内置卡的驱动程序虚拟一个串口设备。又如当前工业界使用的一些串口服务器，往往有8个或16个甚至更多的串口，以连接多个串口设备，再通过一个网卡直接连入以太网。与它在同一网络上的计算机就通过以太网与串口服务器上挂接的串口设备通信。为了让计算机中原来使用本地串口的软件兼容，就需要在计算机上提供虚拟串口驱动。

虚拟串口的设计关键在于，该“串口”实现后必须具有与真实串口完全相同的系统调用接口。要做到这点，从已有的串口设备驱动程序上做修改是最佳捷径。下文就介绍以Windows NT上的串口驱动程序为基础，开发可运行于Windows NT、Windows 2000、Windows XP的各个版本虚拟串口驱动程序。

串口驱动中使用的几个链表

由于串口是双工设备，在一个读请求发出来还没有完成之前，同时可以发出写请求，加上在驱动程序层所有I/O请求都要求异步完成，即前一个请求尚没有完成，下一个相同的请求可能又来了。为此，串口驱动程序需要使用多个双向链表数据结构来处理各种IRP（I/O Request Packet，I/O请求包）。当收到一个IRP，先判断是否可立即完成，可以马上处理并返回，如果不允许则将IRP插在相应链表尾，在适当的时候如设备有空闲时处理，这时往往会产生一个硬件中断，激发DPC（Deferred Procedure Call，暂缓过程调用）过程，由DPC处理函数逐个从链表头取出IRP并试着完成它。串口驱动中有以下几个链表和DPC(在serial.h中有定义):

ReadQueue 和 CompleteReadDpc

用于保存Read IRP的链表和用于调度的DPC，与DPC对应的处理函数是SerialCompleteRead，它在read.c文件中，该函数的主要任务就是从ReadQueue中提取下一个IRP，并试着完成它。

WriteQueue 和 CompleteWriteDpc

用于保存Write IRP的链表和对应的DPC，与DPC对应的函数是SeriaCompleteWrite，它的实现在write.c中，该函数负责从WriteQueue中提取IRP，并试着完成它。

MaskQueue 和 CommWaitDpc

这一对链表用于处理Windows串口驱动的一个特性：事件驱动机制。它允许应用程序预设一个事件标志，而后等待与标志对应事件发生。DPC所调用的函数是SerialCompleteWait，它实现在Waitmask.c文件中，该函数也是试着从MaskQueue中提取IRP并完成它。

PurgeQueue

该链表与前面几个稍有不同，它没有与之相对应的DPC机制，而是在每次收到Purge请求时从PurgeQueue中逐个提取IRP并试着完成，因某种原因不能完成时则插入链表。相应的函数是purge.c文件中的SerialStartPurge。

以上机制是串口驱动程序的重要实现方法，在虚拟串口驱动中需要保留，但不同的是，硬件串口驱动中是ISR（中断服务程序）根据收、发或MODEM中断来激发相应的DPC，而在虚拟串口驱动中将因实际情况不同会有不同的激发机制。

DriverEntry的实现

DriverEntry是驱动程序的入口函数，相当于应用程序C语言中的main函数，开发一个虚拟串口驱动首先要修改的就是它。它的函数实体在initunlo.c文件中。只是在虚拟串口驱动中由于不与具体的硬件打交道，就不存在硬件资源分析、硬件初始化、判断其工作状态等处理，只需要为虚拟串建立设备对象、符号链接和初始化数据结构。一个典型函数实现大体如下：

NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath)

{

/*填写DriverObject->MajorFunction[]数组*/

/*建立设备对象*/

/*初始化SERIAL_DEVCIE_EXETENSION数据结构*/

Status = IoCreateDevice(DriverObject, sizeof(SERIAL_DEVICE_EXTENSION), &uniNameString, FILE_DEVICE_SERIAL_PORT, 0,TRUE,&deviceObject)

//初始化所有链表

InitializeListHead(&extension->ReadQueue)

InitializeListHead(…)

…

//初始化所有DPC

KeInitializeDpc(&extension->CompleteReadDpc,SerailCompleteRead,extension)

KeInitializeDpc(…)

/*建立符号链接*/

SerialSetupExternalNaming(extension)

return Status

}

SerialRead和SerialCompleteRead的实现

函数SerailRead和SerialCompleteRead决定了对Read IRP的响应策略，它们都存于read.c中。以串口服务器要用的虚拟串口为例，当串口服务器收到来自外部数据时将通过网络发至计算机，计算机则产生相应的网络中断并进行协议数据处理。网络接收线程缓存新收到的数据并激活CompleteReadDpc，从而SerialCompleteReadIrp得到调用，它再调用CompleteReadIrp对每个IRP进行处理。它们的实现大体如下：

NTSTATUS SerialRead(IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp)

{

/*此处略去变量声明和初始化*/

/*提取IRP中相关的数据*/

stack = IoGetCurrentIrpStackLocation(Irp)

ReadLen = stack->Parameters.Read.Length

/*先看本地缓冲有数据否？有的话先读取*/

if(Extension->InCounter >0 )

{ //注意这里要加锁，以防数据访问冲突

KeAcquireSpinLock(&Extension->

ReadBufferLock,&lIrql)

FirstRead = (ReadLen>Extension->

InCounter)? Extension->InCounter: ReadLen

RtlCopyMemory(Irp->AssociatedIrp.

SystemBuffer,Extension->pInBuffer,FirstRead)

Extension->InCounter -= FirstRead

ReadLen -= FirstRead

KeReleaseSpinLock(&Extension->

ReadBufferLock,lIrql)//释放锁

}

/*是否已读到足够数据？是的话则完成该IRP*/

if( 0 == ReadLen)

{

status=STATUS_SUCCESS

Irp->IoStatus.Status = status

Irp->IoStatus.Information = FirstRead

IoCompleteRequest(Irp,0)

return status

}

/*没有则将IRP插入队列中，通过网络向串口服务器发出读数据请求*/

IoMarkIrpPending(Irp)

InsertWaitList(Extension->ReadQueue,Irp)

status = TdiSendAsync(Extension->ComChannel,pAckPacket,PacketLen(pAckPacket),(PVOID)ReadAckComplete,Irp)

/*返回PENDING，表示该IRP尚没有完成*/

return STATUS_PENDING

}

Void CompleteReadIrp(IN PSERIAL_DEVICE_EXTENSION extension,IN PIRP Irp,IN PUCHAR pInData,IN ULONG Length )

{

/*此处略去变量声明和初始化*/

/*读取新数据*/

ReadLen = (ReadLen >Length)? Length : ReadLen

if(ReadLen != 0)

{

RtlCopyMemory(pReadAsync->

pReadBuffer,pInData,ReadLen)

pReadAsync->pReadBuffer += ReadLen

pReadAsync->ReadAlready += ReadLen

extension->PerfStats.ReceivedCount +=

ReadLen

}

else

{

/*因为串口服务器端只有在已经有了相应的数据或超过时间（此时，Length=0）才会发来应答并激活本DPC过程，所以此时已经超时，为了便于结束本IRP，这里有意改变TotalNeedRead，造成接收完毕的假象*/

pReadAsync->TotalNeedRead =

pReadAsync->ReadAlready

}

if(pReadAsync->TotalNeedRead == pReadAsync->ReadAlready)

{

/*该IRP是否已经接收完毕，是的话则结束该

IRP*/

EndReadIrp(Irp)；

/*从ReadQueue中取下一个IRP*/

}

/*本IRP没有完成也没有超时，则继续等待本DPC下次被激活，注意此时要判断IRP是否被要求取消*/

}

SerialWrite和SerailCompleteWrite的实现

SerialWrite和SerailCompleteWrite决定了Write IRP的实现。在SerialWrite中调用了网络发送函数TdiSendAsync,当该发送完成后将激活CompleteWriteDpc，调度SerialCompleteWrite函数，而它主要就是取出当前的WriteIRP,设置已经发送的数据数量，调用CompleteWriteIrp做该IRP的进一步处理。它们大体如下：

NTSTATUS SerialWrite(IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp)

{

/*此处略去变量声明和初始化*/

/*从IRP中提取有关数据*/

stack=IoGetCurrentIrpStackLocation(Irp)

SendLen = stack->Parameters.Write.Length

/*为网络发送和异步 *** 作分配缓冲,在CompleteWrite中全部数据发送完后释放*/

pWriteAsync = ExAllocatePool(NonPagedPool,

SendLen+PACKET_HEADER_LEN+sizeof(WRITE_ASYNC))

if(pWriteAsync == NULL)

{

//错误处理

}

//保存异步数据

…

//设置网络发送数据包

BuildDataPacket(pPacket,WRITE,(USHORT)SendLen,pWriteAsync->pWriteBuffer)

/*先将IRP暂时阻塞并插入队列，在CompleteWrite中完成*/

IoMarkIrpPending(Irp)

InsertWaitList(extension->WriteQueue, Irp)

/*将写请求和相关数据通过网络发向串口服务器，由它负责将数据传到具体串口设备*/

status = TdiSendAsync(Extension->ComChannel,pPacket,PacketLen(pPacket),(PVOID)CompleteWriteIrp,Irp)

//统计数据累加

Extension->PerfStats.TransmittedCount += SendLen

return STATUS_PENDING

}

NTSTATUS CompleteWriteIrp(IN PDEVICE_OBJECT deviceobject,IN PIRP pIrp,IN PVOID context)

{

/*此处略去变量声明和初始化*/

SendLen=pWriteAsync->TotalNeedWrite - pWriteAsync->WroteAlready

if(SendLen == 0)//全部数据发送完毕

{

EndWaitWriteIrp(pWriteIrp,STATUS_SUCCESS,

pWriteAsync->WroteAlready,pWriteAsync)

//从WriteQueue中取下一个IRP

}

else //发送剩余数据

{

if(pWriteIrp->Cancel)

{

//IRP被要求取消，完成WriteIrp

EndWaitWriteIrp(pWriteIrp,STATUS_CANCELLED,

pWriteAsync->WroteAlready,pWriteAsync)

return STATUS_CANCELED

}

else

{

//再次设置网络数据包并发送

BuildDataPacket(…)

status = TdiSendAsync(…)

//统计数据累加

Extension->PerfStats.TransmittedCount +=

SendLen

return STATUS_MORE_PROCESSING_REQUIRED

}

}

}

其他几个接口函数的实现

除Read/Write外，SerialUnload、SerialCreateOpen、 SerialClose、SerialCleanup、SerailFlush等调用接口是硬件相关性比较弱的接口函数，基本不要修改，直接删除原来 *** 作硬件的部分即可。复杂一点就是SerialIoControl，该接口函数包含有大量设置、读取串口硬件状态的处理，可建立一个本地数据结构随时保存虚拟串口的当前硬件状态。同时为了保证串口服务器端的真实串口状态和上层软件要求的一致，需要将所有设置请求通过网络发送到服务器端，由它负责改变真实硬件的状态。

---