Linux是Unix操作系统的一种变种,在Linux下编撰驱动程序的原理和思想完全类似于其他的Unix系统,但它dos或window环境下的驱动程序有很大的区别。在Linux环境下设计驱动程序,思想简约,操作便捷,功能也很强悍,而且支持函数少,只能依赖kernel中的函数,有些常用的操作要自己来编撰,但是调试也不便捷。本人这几周来为实验室自行研发的一块多媒体卡编制了驱动程序,获得了一些经验,愿与Linuxfans共享,有不当之处,请予见谅。
以下的一些文字主要来始于khg,johnsonm的Writelinuxdevicedriver,Brennan'sGuidetoInlineAssembly,TheLinuxA-Z,还有北大BBS上的有关devicedriver的一些资料.那些资料有的早已过时,有的还有一些错误,我根据自己的试验结果进行了修正.
一、Linuxdevicedriver的概念
系统调用是操作系统内核和应用程序之间的插口,设备驱动程序是操作系统内核和机器硬件之间的插口.设备驱动程序为应用程序屏蔽了硬件的细节,这样在应用程序看来,硬件设备只是一个设备文件,应用程序可以象操作普通文件一样对硬件设备进行操作.设备驱动程序是内核的一部份,它完成以下的功能:
1.对设备初始化和释放.
2.把数据从内核传送到硬件和从硬件读取数据.
3.读取应用程序传送给设备文件的数据和回送应用程序恳求的数据.
4.检查和处理设备出现的错误.
在Linux操作系统下有两类主要的设备文件类型,一种是字符设备,另一种是块设备.字符设备和块设备的主要区别是:在对字符设备发出读/写请求时,实际的硬件I/O通常就紧接着发生了,块设备则不然,它借助一块系统显存作缓冲区,当用户进程对设备恳求能满足用户的要求,就返回恳求的数据,假如不能,就调用恳求函数来进行实际的I/O操作.块设备是主要针对c盘等慢速设备设计的,以免花费过多的CPU时间来等待.
早已提及,用户进程是通过设备文件来与实际的硬件打交道.每位设备文件都都有其文件属性(c/b),表示是字符设备还蔤强樯璞?另外每位文件都有两个设备号,第一个是主设备号,标示驱动程序,第二个是从设备号,标示使用同一个设备驱动程序的不同的硬件设备,例如有两个软驱,就可以用从设备号来区分她们.设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致,否则用户进程将难以访问到驱动程序.
最后必须提及的是,在用户进程调用驱动程序时,系统步入核态度,这时不再是抢鲜式调度.也就是说,系统必须在你的驱动程序的子函数返回后才会进行其他的工作.假如你的驱动程序深陷死循环linux查看硬件信息,不幸的是你只有重新启动机器了,之后就是漫长的fsck.//hehe
读/写时,它首先察看缓冲区的内容,假如缓冲区的数据
怎样编撰Linux操作系统下的设备驱动程序
二、实例分析
我们来写一个最简单的字符设备驱动程序。其实它哪些也不做,而且通过它可以了解Linux的设备驱动程序的工作原理.把下边的C代码输入机器,你都会获得一个真正的设备驱动程序.不过我的kernel是2.0.34,在低版本的kernel上可能会出现问题,我还没测试过.//xixi
#define__NO_VERSION__
#include
#include
charkernel_version[]=UTS_RELEASE;
这一段定义了一些版本信息,即使好处不是很大,但也必不可少.Johnsonm说所有的驱动程序的开头都要包含,但我看倒是未必.
因为用户进程是通过设备文件同硬件打交道,对设备文件的操作方法不外乎就是一些系统调用,如open,read,write,close....,注意,不是fopen,fread,然而怎样把系统调用和驱动程序关联上去呢?这须要了解一个十分关键的数据结构:
structfile_operations{
int(*seek)(structinode*,structfile*,off_t,int);
int(*read)(structinode*,structfile*,char,int);
int(*write)(structinode*,structfile*,off_t,int);
int(*readdir)(structinode*,structfile*,structdirent*,int);
int(*select)(structinode*,structfile*,int,select_table*);
int(*ioctl)(structinode*,structfile*,unsinedint,unsignedlong);
int(*mmap)(structinode*,structfile*,structvm_area_struct*);
int(*open)(structinode*,structfile*);
int(*release)(structinode*,structfile*);
int(*fsync)(structinode*,structfile*);
int(*fasync)(structinode*,structfile*,int);
int(*check_media_change)(structinode*,structfile*);
int(*revalidate)(dev_tdev);
这个结构的每一个成员的名子都对应着一个系统调用.用户进程借助系统调用在对设备文件进行例如read/write操作时,系统调用通过设备文件的主设备号找到相应的设备驱动程序,之后读取这个数据结构相应的函数表针,接着把控制权交给该函数.这是linux的设备驱动程序工作的基本原理.既然是这样,则编撰设备驱动程序的主要工作就是编撰子函数,并填充file_operations的各个域.
相当简单,不是吗?
下边就开始写子程序.
#include
#include
#include
#include
#include
unsignedinttest_major=0;
staticintread_test(structinode*node,structfile*file,
char*buf,intcount)
intleft;
if(verify_area(VERIFY_WRITE,buf,count)==-EFAULT)
return-EFAULT;
for(left=count;left>0;left--)
__put_user(1,buf,1);
buf++;
returncount;
这个函数是为read调用打算的.当调用read时,read_test()被调用,它把用户的缓冲区全部写1.buf是read调用的一个参数.它是用户进程空间的一个地址.并且在read_test被调用时,系统步入核态度.所以不能使用buf这个地址,必须用__put_user(),这是kernel提供的一个函数linux的设备驱动程序,用于向用户传送数据.另外还有好多类似功能的函数.请参考.在向用户空间拷贝数据之前,必须验证buf是否可用。
这就用到函数verify_area.
staticintwrite_tibet(structinode*inode,structfile*file,
constchar*buf,intcount)
returncount;
staticintopen_tibet(structinode*inode,structfile*file)
MOD_INC_USE_COUNT;
return0;
staticvoidrelease_tibet(structinode*inode,structfile*file)
MOD_DEC_USE_COUNT;
这几个函数都是空操作.实际调用发生时哪些也不做,她们仅仅为下边的结构提供函数表针。
structfile_operationstest_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*/
/*nothingmore,fillwithNULLs*/
};
设备驱动程序的主体可以说是写好了。如今要把驱动程序嵌入内核。驱动程序可以根据两种形式编译。一种是编译进kernel,另一种是编译成模块(modules),假如编译进内核的话,会降低内核的大小,还要改动内核的源文件,但是不能动态的卸载,不利于调试,所以推荐使用模块形式。
intinit_module(void)
intresult;
result=register_chrdev(0,"test",&test_fops);
if(result<0){
printk(KERN_INFO"test:can'tgetmajornumber/n");
returnresult;
if(test_major==0)test_major=result;/*dynamic*/
return0;
在用insmod命令将编译好的模块调入显存时,init_module函数被调用。在这儿,init_module只做了一件事,就是向系统的字符设备表登记了一个字符设备。register_chrdev须要三个参数,参数一是希望获得的设备号,若果是零的话,系统将选择一个没有被占用的设备号返回。参数二是设备文件名,参数三拿来登记驱动程序实际执行操作的函数的表针。
假如登记成功,返回设备的主设备号,不成功,返回一个负值。
voidcleanup_module(void)
unregister_chrdev(test_major,"test");
在用rmmod卸载模块时,cleanup_module函数被调用,它释放字符设备test在系统字符设备表中占有的表项。
一个非常简单的字符设备可以说写好了,文件名就叫test.c吧。
下边编译
$gcc-O2-DMODULE-D__KERNEL__-ctest.c
得到文件test.o就是一个设备驱动程序。
假如设备驱动程序有多个文件,把每位文件按前面的命令行编译,之后
ld-rfile1.ofile2.o-omodulename.
驱动程序早已编译好了,如今把它安装到系统中去。
$insmod-ftest.o
假如安装成功,在/proc/devices文件中就可以看见设备test,并可以看见它的主设备号。
要卸载的话,运行
$rmmodtest
下一步要创建设备文件。
mknod/dev/testcmajorminor
c是指字符设备,major是主设备号,就是在/proc/devices里听到的。
用shell命令
$cat/proc/devices|awk"}"
就可以获得主设备号,可以把里面的命令行加入你的shellscript中去。
minor是从设备号,设置成0就可以了。
我们如今可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。
#include
#include
#include
#include
main()
inttestdev;
inti;
charbuf[10];
testdev=open("/dev/test"linux的设备驱动程序,O_RDWR);
if(testdev==-1)
printf("Cann'topenfile/n");
exit(0);
read(testdev,buf,10);
for(i=0;i<10;i++)
printf("%d/n",buf[i]);
close(testdev);
编译运行,瞧瞧是不是复印出全1?
以上只是一个简单的演示。真正实用的驱动程序要复杂的多,要处理如中断,DMA,I/Oport等问题。这种才是真正的难点。请看下节,实际情况的处理。
怎么编撰Linux操作系统下的设备驱动程序
三、设备驱动程序中的一些具体问题
1.I/OPort.
和硬件打交道离不开I/OPort,老的ISA设备常常是占用实际的I/O端口,在linux下,操作系统没有对I/O口屏蔽,也就是说,任何驱动程序都可对任意的I/O口操作,这样就很容易造成混乱。每位驱动程序应当自己防止误用端口。
有两个重要的kernel函数可以保证驱动程序做到这一点。
1)check_region(intio_port,intoff_set)
这个函数察看系统的I/O表,看是否有别的驱动程序占用某一段I/O口。
参数1:io端口的基地址,
参数2:io端口占用的范围。
返回值:0没有占用,非0,早已被占用。
2)request_region(intio_port,intoff_set,char*devname)
倘若这段I/O端口没有被占用,在我们的驱动程序中就可以使用它。在使用之前,必须向系统登记,以避免被其他程序占用。登记后,在/proc/ioports文件中可以见到你登记的io口。
参数1:io端口的基地址。
参数2:io端口占用的范围。
参数3:使用这段io地址的设备名。
在对I/O口登记后,就可以放心地用inb(),outb()之类的函来访问了。
在一些pci设备中,I/O端口被映射到一段显存中去,要访问那些端口就相当于访问一段显存。常常性的,我们要获得一块显存的化学地址。在dos环境下,(之所以不说是dos操作系统是由于我觉得DOS根本就不是一个操作系统,它实在是太简单,太不安全了)只要用段:偏斜就可以了。在window95中,95ddk提供了一个vmm调用_MapLinearToPhys,用以把线性地址转化为化学地址。但在Linux中是如何做的呢?
2.显存操作
在设备驱动程序中动态开辟显存,不是用malloc,而是kmalloc,或则用get_free_pages直接申请页。释放显存用的是kfree,或free_pages.请注意,kmalloc等函数返回的是化学地址!而malloc等返回的是线性地址!关于kmalloc返回的是化学地址这一点本人有点不太明白:既然从线性地址到化学地址的转换是由386cpu硬件完成的,那样汇编指令的操作数应当是线性地址linux内核,驱动程序同样也不能直接使用化学地址而是线性地址。并且事实上kmalloc返回的确实是化学地址,并且也可以直接通过它访问实际的RAM,我想这样可以由两种解释,一种是在核态度严禁分页,然而这似乎不太现实;另一种是linux的页目录和页表项设计得刚好促使化学地址等同于线性地址。我的看法不知对不对,还请前辈指教。
言归正传,要注意kmalloc最大只能开辟128k-16,16个字节是被页描述符结构占用了。kmalloc用法参见khg.
显存映射的I/O口,寄存器或则是硬件设备的RAM(如内存)通常占用F0000000以上的地址空间。在驱动程序中不能直接访问,要通过kernel函数vremap获得重新映射之后的地址。
另外,好多硬件须要一块比较大的连续显存用作DMA传送。这块显存须要仍然留驻在显存,不能被交换到文件中去。并且kmalloc最多只能开辟128k的显存。
这可以通过牺牲一些系统显存的方式来解决。
具体做法是:例如说你的机器由32M的显存,在lilo.conf的启动参数中加上mem=30M,这样linux就觉得你的机器只有30M的显存,剩下的2M显存在vremap以后就可以为DMA所用了。
请记住,用vremap映射后的显存,不用时应用unremap释放,否则会浪费页表。
3.中断处理
同处理I/O端口一样,要使用一个中断,必须先向系统登记。
intrequest_irq(unsignedintirq,
void(*handle)(int,void*,structpt_regs*),
unsignedintlongflags,
constchar*device);
irq:是要申请的中断。
handle:中断处理函数表针。
flags:SA_INTERRUPT恳求一个快速中断,0正常中断。
device:设备名。
假如登记成功,返回0,这时在/proc/interrupts文件中可以看你恳求的中断。
4.一些常见的问题。
对硬件操作,有时时序很重要。并且假如用C语言写一些低级的硬件操作的话,gcc常常会对你的程序进行优化,这样时序就错掉了。假如用汇编撰呢,gcc同样会对汇编代码进行优化,除非你用volatile关键字修饰。最保险的办法是严禁优化。这其实只能对一部份你自己编撰的代码。假如对所有的代码都不优化,你会发觉驱动程序根本没法装载。这是由于在编译驱动程序时要用到gcc的一些扩充特点,而这种扩充特点必须在加了优化选项以后能够彰显下来