如何编写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.//hehe

( 请看下节 , 实例剖析 )

读 / 写时 , 它首先察看缓冲区的内容 , 如果缓冲区的数据如何编写 Linux 操作系统下的设备驱动程序 Roy G

二 . 实例剖析

我们来写一个最简单的字符设备驱动程序 . 虽然它什么也不做 , 但是通过它可以了解 Linux 的设备驱动程序的工作原理 . 把下面的 C 代码输入机器 , 你就会获得一个真正的设备驱动程序 . 不过我的 kernel 是 2.0.34 , 在低版本的 kernel 上可能会出现问题 , 我还没测试过 .//xixi

#define __NO_VERSION__

#include <linux/modules.h>

#include <linux/version.h>

char kernel_version [] = UTS_RELEASE;

这一段定义了一些版本信息 , 虽然用处不是很大 , 但也必不可少 .Johnsonm 说所有的驱动程序的开头都要包含 , 但我看倒是未必 . 由于用户进程是通过设备文件同硬件打交道 , 对设备文件的操作方式不外乎就是一些系统调用 , 如 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 <linux/types.h>

#include <linux/fs.h>

#include <linux/mm.h>

#include <linux/errno.h>

#include <asm/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 提供的一个函数 , 用于向用户传送数据 . 另外还有很多类似功能的函数 . 请参考 . 在向用户空间拷贝数据之前 , 必须验证 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 ");

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 | awk "/$2=="test" {print /$1}"

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

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

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

#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

main()

{

int testdev;

int i;

char buf[10];

testdev = open("/dev/test",O_RDWR);

if ( testdev == -1 )

{

printf("Cann't open file ");

exit(0);

}

read(testdev,buf,10);

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

printf("%d ",buf[i]);

close(testdev);

}

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

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

Roy G

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

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 ： io 端口的基地址，

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

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

2 ） request_region(int io_port, int off_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 硬件完成的，那样汇编指令的操作数应该是线性地址，驱动程序同样也不能直接使用物理地址而是线性地址。但是事实上 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 端口一样，要使用一个中断，必须先向系统登记。

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 一些常见的问题。

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

关于 kernel 的调试工具，我现在还没有发现有合适的。有谁知道请告诉我，不胜感激。我一直都在 printk 打印调试信息，倒也还凑合。关于设备驱动程序还有很多内容，如等待 / 唤醒机制，块设备的编写等。我还不是很明白，不敢乱说。

欢迎大家批评指正。