虚拟字符设备驱动开发
Posted 行稳方能走远
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了虚拟字符设备驱动开发相关的知识,希望对你有一定的参考价值。
目录
Linux 中的三大类驱动:字符设备驱动、块设备驱动和网络设备驱动。
字符设备驱动是占用篇幅最大的一类驱动,因为字符设备最多,从最简单的点灯到I2C、SPI、音频等都属于字符设备驱动的类型。
块设备和网络设备驱动要比字符设备驱动复杂,就是因为其复杂所以半导体厂商一般都给我们编写好了,大多数情况下都是直接可以使用的。
所谓的块设备驱动就是存储器设备的驱动,比如EMMC、NAND、SD 卡和U 盘等存储设备,因为这些存储设备的特点是以存储块为基础,因此叫做块设备。
网络设备驱动就更好理解了,就是网络驱动,不管是有线的还是无线的,都属于网络设备驱动的范畴。
一个设备可以属于多种设备驱动类型,比如USB WIFI,其使用USB 接口,所以属于字符设备,但是其又能上网,所以也属于网络设备驱动。
本书使用的Linux 内核版本为4.1.15,其支持设备树(Device tree),所以本篇所有例程均采用设备树。设备树将是本篇的重点!从设备树的基本原理到设备树驱动的开发方式,从最简单的点灯到复杂的网络驱动开发,本篇均有详细的讲解,是学习设备树的不二之选。
本章会以一个虚拟的设备为例,讲解如何进行字符设备驱动开发,以及如何编写测试APP 来测试驱动工作是否正常,为以后的学习打下坚实的基础。
字符设备驱动简介
字符设备是Linux 驱动中最基本的一类设备驱动,字符设备就是一个一个字节,按照字节流进行读写操作的设备,读写数据是分先后顺序的。比如我们最常见的点灯、按键、IIC、SPI,LCD 等等都是字符设备,这些设备的驱动就叫做字符设备驱动。
在详细的学习字符设备驱动架构之前,我们先来简单的了解一下Linux 下的应用程序是如何调用驱动程序的,Linux 应用程序对驱动程序的调用如图40.1.1 所示:
在Linux 中一切皆为文件,驱动加载成功以后会在“/dev”目录下生成一个相应的文件,应用程序通过对这个名为“/dev/xxx”(xxx 是具体的驱动文件名字)的文件进行相应的操作即可实现对硬件的操作。比如现在有个叫做/dev/led 的驱动文件,此文件是led 灯的驱动文件。应用程序使用open 函数来打开文件/dev/led,使用完成以后使用close 函数关闭/dev/led 这个文件。open
和close 就是打开和关闭led 驱动的函数,如果要点亮或关闭led,那么就使用write 函数来操作,也就是向此驱动写入数据,这个数据就是要关闭还是要打开led 的控制参数。如果要获取led 灯的状态,就用read 函数从驱动中读取相应的状态。
应用程序运行在用户空间,而Linux 驱动属于内核的一部分,因此驱动运行于内核空间。当我们在用户空间想要实现对内核的操作,比如使用open 函数打开/dev/led 这个驱动,因为用户空间不能直接对内核进行操作,因此必须使用一个叫做“系统调用”的方法来实现从用户空间“陷入”到内核空间,这样才能实现对底层驱动的操作。open、close、write 和read 等这些函数是由C 库提供的,在Linux 系统中,系统调用作为C 库的一部分。当我们调用open 函数的时候流程如图40.1.2 所示:
其中关于C 库以及如何通过系统调用“陷入”到内核空间这个我们不用去管,我们重点关注的是应用程序和具体的驱动,应用程序使用到的函数在具体驱动程序中都有与之对应的函数,比如应用程序中调用了open 这个函数,那么在驱动程序中也得有一个名为open 的函数。每一个系统调用,在驱动中都有与之对应的一个驱动函数,在Linux 内核文件include/linux/fs.h 中有个叫做file_operations 的结构体,此结构体就是Linux 内核驱动操作函数集合,内容如下所示:
内核驱动操作函数集合
1588 struct file_operations {
1589 struct module *owner;
1590 loff_t (*llseek) (struct file *, loff_t, int);
1591 ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
1592 ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
1593 ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
1594 ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
1595 int (*iterate) (struct file *, struct dir_context *);
1596 unsigned int (*poll) (struct file *, struct poll_table_struct *);
1597 long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
1598 long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
1599 int (*mmap) (struct file *, struct vm_area_struct *);
1600 int (*mremap)(struct file *, struct vm_area_struct *);
1601 int (*open) (struct inode *, struct file *);
1602 int (*flush) (struct file *, fl_owner_t id);
1603 int (*release) (struct inode *, struct file *);
1604 int (*fsync) (struct file *, loff_t, loff_t, int datasync);
1605 int (*aio_fsync) (struct kiocb *, int datasync);
1606 int (*fasync) (int, struct file *, int);
1607 int (*lock) (struct file *, int, struct file_lock *);
1608 ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
1609 unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
1610 int (*check_flags)(int);
1611 int (*flock) (struct file *, int, struct file_lock *);
1612 ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
1613 ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
1614 int (*setlease)(struct file *, long, struct file_lock **, void **);
1615 long (*fallocate)(struct file *file, int mode, loff_t offset,
1616 loff_t len);
1617 void (*show_fdinfo)(struct seq_file *m, struct file *f);
1618 #ifndef CONFIG_MMU
1619 unsigned (*mmap_capabilities)(struct file *);
1620 #endif
1621 };
简单介绍一下file_operation 结构体中比较重要的、常用的函数:
- 第1589 行,owner 拥有该结构体的模块的指针,一般设置为THIS_MODULE。
- 第1590 行,llseek 函数用于修改文件当前的读写位置。
- 第1591 行,read 函数用于读取设备文件。
- 第1592 行,write 函数用于向设备文件写入(发送)数据。
- 第1596 行,poll 是个轮询函数,用于查询设备是否可以进行非阻塞的读写。
- 第1597 行,unlocked_ioctl 函数提供对于设备的控制功能,与应用程序中的ioctl 函数对应。
- 第1598 行,compat_ioctl 函数与unlocked_ioctl 函数功能一样,区别在于在64 位系统上,32 位的应用程序调用将会使用此函数。在32 位的系统上运行32 位的应用程序调用的是unlocked_ioctl。
- 第1599 行,mmap 函数用于将将设备的内存映射到进程空间中(也就是用户空间),一般帧缓冲设备会使用此函数,比如LCD 驱动的显存,将帧缓冲(LCD 显存)映射到用户空间中以后应用程序就可以直接操作显存了,这样就不用在用户空间和内核空间之间来回复制。
- 第1601 行,open 函数用于打开设备文件。
- 第1603 行,release 函数用于释放(关闭)设备文件,与应用程序中的close 函数对应。
- 第1604 行,fasync 函数用于刷新待处理的数据,用于将缓冲区中的数据刷新到磁盘中。
- 第1605 行,aio_fsync 函数与fasync 函数的功能类似,只是aio_fsync 是异步刷新待处理的数据。
在字符设备驱动开发中最常用的就是上面这些函数,关于其他的函数大家可以查阅相关文档。我们在字符设备驱动开发中最主要的工作就是实现上面这些函数,不一定全部都要实现,但是像open、release、write、read 等都是需要实现的,当然了,具体需要实现哪些函数还是要看具体的驱动要求。
字符设备驱动开发步骤
上一小节我们简单的介绍了一下字符设备驱动,那么字符设备驱动开发都有哪些步骤呢?我们在学习裸机或者STM32 的时候关于驱动的开发就是初始化相应的外设寄存器,在Linux 驱动开发中肯定也是要初始化相应的外设寄存器,这个是毫无疑问的。只是在Linux 驱动开发中我们需要按照其规定的框架来编写驱动,所以说学Linux 驱动开发重点是学习其驱动框架。
驱动模块的加载和卸载
Linux 驱动有两种运行方式,第一种就是将驱动编译进Linux 内核中,这样当Linux 内核启动的时候就会自动运行驱动程序。第二种就是将驱动编译成模块(Linux 下模块扩展名为.ko),在Linux 内核启动以后使用“insmod”命令加载驱动模块。在调试驱动的时候一般都选择将其编译为模块,这样我们修改驱动以后只需要编译一下驱动代码即可,不需要编译整个Linux 代码。
而且在调试的时候只需要加载或者卸载驱动模块即可,不需要重启整个系统。总之,将驱动编译为模块最大的好处就是方便开发,当驱动开发完成,确定没有问题以后就可以将驱动编译进Linux 内核中,当然也可以不编译进Linux 内核中,具体看自己的需求。
模块有加载和卸载两种操作,我们在编写驱动的时候需要注册这两种操作函数,模块的加载和卸载注册函数如下:
module_init(xxx_init); //注册模块加载函数
module_exit(xxx_exit); //注册模块卸载函数
module_init 函数用来向Linux 内核注册一个模块加载函数,参数xxx_init 就是需要注册的具体函数,当使用“insmod”命令加载驱动的时候,xxx_init 这个函数就会被调用。module_exit()函数用来向Linux 内核注册一个模块卸载函数,参数xxx_exit 就是需要注册的具体函数,当使用“rmmod”命令卸载具体驱动的时候xxx_exit 函数就会被调用。字符设备驱动模块加载和卸载模板如下所示:
1 /* 驱动入口函数*/
2 static int __init xxx_init(void)
3 {
4 /* 入口函数具体内容*/
5 return 0;
6 }
7
8 /* 驱动出口函数*/
9 static void __exit xxx_exit(void)
10 {
11 /* 出口函数具体内容*/
12 }
13
14 /* 将上面两个函数指定为驱动的入口和出口函数*/
15 module_init(xxx_init);
16 module_exit(xxx_exit);
第2 行,定义了个名为xxx_init 的驱动入口函数,并且使用了“__init”来修饰。
第9 行,定义了个名为xxx_exit 的驱动出口函数,并且使用了“__exit”来修饰。
第15 行,调用函数module_init 来声明xxx_init 为驱动入口函数,当加载驱动的时候xxx_init函数就会被调用。
第16 行,调用函数module_exit 来声明xxx_exit 为驱动出口函数,当卸载驱动的时候xxx_exit函数就会被调用。
驱动编译完成以后扩展名为.ko,有两种命令可以加载驱动模块:insmod 和modprobe,insmod
是最简单的模块加载命令,此命令用于加载指定的.ko 模块,比如加载drv.ko 这个驱动模块,命
令如下:
insmod drv.ko
insmod 命令不能解决模块的依赖关系,比如drv.ko 依赖first.ko 这个模块,就必须先使用insmod 命令加载first.ko 这个模块,然后再加载drv.ko 这个模块。但是modprobe 就不会存在这个问题,modprobe 会分析模块的依赖关系,然后会将所有的依赖模块都加载到内核中,因此modprobe 命令相比insmod 要智能一些。modprobe 命令主要智能在提供了模块的依赖性分析、错误检查、错误报告等功能,推荐使用modprobe 命令来加载驱动。modprobe 命令默认会去/lib/modules/目录中查找模块,比如本书使用的Linux kernel 的版本号为4.1.15,因此modprobe 命令默认会到/lib/modules/4.1.15 这个目录中查找相应的驱动模块,一般自己制作的根文件系统中是不会有这个目录的,所以需要自己手动创建。
驱动模块的卸载使用命令“rmmod”即可,比如要卸载drv.ko,使用如下命令即可:
rmmod drv.ko
也可以使用“modprobe -r”命令卸载驱动,比如要卸载drv.ko,命令如下:
modprobe -r drv.ko
使用modprobe 命令可以卸载掉驱动模块所依赖的其他模块,前提是这些依赖模块已经没有被其他模块所使用,否则就不能使用modprobe 来卸载驱动模块。所以对于模块的卸载,还是推荐使用rmmod 命令。
字符设备注册与注销
对于字符设备驱动而言,当驱动模块加载成功以后需要注册字符设备,同样,卸载驱动模块的时候也需要注销掉字符设备。字符设备的注册和注销函数原型如下所示:
static inline int register_chrdev(unsigned int major, const char *name,
const struct file_operations *fops)
static inline void unregister_chrdev(unsigned int major, const char *name)
register_chrdev 函数用于注册字符设备,此函数一共有三个参数,这三个参数的含义如下:
major:主设备号,Linux 下每个设备都有一个设备号,设备号分为主设备号和次设备号两部分,关于设备号后面会详细讲解。
name:设备名字,指向一串字符串。
fops:结构体file_operations 类型指针,指向设备的操作函数集合变量。
unregister_chrdev 函数用户注销字符设备,此函数有两个参数,这两个参数含义如下:
major:要注销的设备对应的主设备号。
name:要注销的设备对应的设备名。
一般字符设备的注册在驱动模块的入口函数xxx_init 中进行,字符设备的注销在驱动模块的出口函数xxx_exit 中进行。在示例代码40.2.2.1 中字符设备的注册和注销,内容如下所示:
1 static struct file_operations test_fops;
2
3 /* 驱动入口函数*/
4 static int __init xxx_init(void)
5 {
6 /* 入口函数具体内容*/
7 int retvalue = 0;
8
9 /* 注册字符设备驱动*/
10 retvalue = register_chrdev(200, "chrtest", &test_fops);
11 if(retvalue < 0){
12 /* 字符设备注册失败,自行处理*/
13 }
14 return 0;
15 }
16
17 /* 驱动出口函数*/
18 static void __exit xxx_exit(void)
19 {
20 /* 注销字符设备驱动*/
21 unregister_chrdev(200, "chrtest");
22 }
23
24 /* 将上面两个函数指定为驱动的入口和出口函数*/
25 module_init(xxx_init);
26 module_exit(xxx_exit);
第1 行,定义了一个file_operations 结构体变量test_fops,test_fops 就是设备的操作函数集合,只是此时我们还没有初始化test_fops 中的open、release 等这些成员变量,所以这个操作函数集合还是空的。
第10 行,调用函数register_chrdev 注册字符设备,主设备号为200,设备名字为“chrtest”,设备操作函数集合就是第1 行定义的test_fops。要注意的一点就是,选择没有被使用的主设备号,输入命令“cat /proc/devices”可以查看当前已经被使用掉的设备号,如图40.2.2.1 所示(限于篇幅原因,只展示一部分):
在图40.2.2.1 中可以列出当前系统中所有的字符设备和块设备,其中第1 列就是设备对应的主设备号。200 这个主设备号在我的开发板中并没有被使用,所以我这里就用了200 这个主设备号。
第21 行,调用函数unregister_chrdev 注销主设备号为200 的这个设备。
实现设备的具体操作函数
file_operations 结构体就是设备的具体操作函数,在示例代码40.2.2.1 中我们定义了file_operations 结构体类型的变量test_fops,但是还没对其进行初始化,也就是初始化其中的open、release、read 和write 等具体的设备操作函数。本节小节我们就完成变量test_fops 的初始化,设置好针对chrtest 设备的操作函数。在初始化test_fops 之前我们要分析一下需求,也就是要对
chrtest 这个设备进行哪些操作,只有确定了需求以后才知道我们应该实现哪些操作函数。假设对chrtest 这个设备有如下两个要求:
1、能够对chrtest 进行打开和关闭操作
设备打开和关闭是最基本的要求,几乎所有的设备都得提供打开和关闭的功能。因此我们需要实现file_operations 中的open 和release 这两个函数。
2、对chrtest 进行读写操作假设chrtest 这个设备控制着一段缓冲区(内存),应用程序需要通过read 和write 这两个函数对chrtest 的缓冲区进行读写操作。所以需要实现file_operations 中的read 和write 这两个函数。
需求很清晰了,修改示例代码40.2.2.1,在其中加入test_fops 这个结构体变量的初始化操作,完成以后的内容如下所示:
1 /* 打开设备*/
2 static int chrtest_open(struct inode *inode, struct file *filp)
3 {
4 /* 用户实现具体功能*/
5 return 0;
6 }
7
8 /* 从设备读取*/
9 static ssize_t chrtest_read(struct file *filp, char __user *buf, size_t cnt, loff_t *offt)
10 {
11 /* 用户实现具体功能*/
12 return 0;
13 }
14
15 /* 向设备写数据*/
16 static ssize_t chrtest_write(struct file *filp,
const char __user *buf,
size_t cnt, loff_t *offt)
17 {
18 /* 用户实现具体功能*/
19 return 0;
20 }
21
22 /* 关闭/释放设备*/
23 static int chrtest_release(struct inode *inode, struct file *filp)
24 {
25 /* 用户实现具体功能*/
26 return 0;
27 }
28
29 static struct file_operations test_fops = {
30 .owner = THIS_MODULE,
31 .open = chrtest_open,
32 .read = chrtest_read,
33 .write = chrtest_write,
34 .release = chrtest_release,
35 };
36
37 /* 驱动入口函数*/
38 static int __init xxx_init(void)
39 {
40 /* 入口函数具体内容*/
41 int retvalue = 0;
42
43 /* 注册字符设备驱动*/
44 retvalue = register_chrdev(200, "chrtest", &test_fops);
45 if(retvalue < 0){
46 /* 字符设备注册失败,自行处理*/
47 }
48 return 0;
49 }
50
51 /* 驱动出口函数*/
52 static void __exit xxx_exit(void)
53 {
54 /* 注销字符设备驱动*/
55 unregister_chrdev(200, "chrtest");
56 }
57
58 /* 将上面两个函数指定为驱动的入口和出口函数*/
59 module_init(xxx_init);
60 module_exit(xxx_exit);
在示例代码40.2.3.1 中我们一开始编写了四个函数:chrtest_open、chrtest_read、chrtest_write和chrtest_release。这四个函数就是chrtest 设备的open、read、write 和release 操作函数。第29行~35 行初始化test_fops 的open、read、write 和release 这四个成员变量。
添加LICENSE 和作者信息
最后我们需要在驱动中加入LICENSE 信息和作者信息,其中LICENSE 是必须添加的,否则的话编译的时候会报错,作者信息可以添加也可以不添加。LICENSE 和作者信息的添加使用如下两个函数:
MODULE_LICENSE() //添加模块LICENSE 信息
MODULE_AUTHOR() //添加模块作者信息
最后给示例代码40.2.3.1 加入LICENSE 和作者信息,完成以后的内容如下:
1 /* 打开设备*/
2 static int chrtest_open(struct inode *inode, struct file *filp)
3 {
4 /* 用户实现具体功能*/
5 return 0;
6 }
......
57
58 /* 将上面两个函数指定为驱动的入口和出口函数*/
59 module_init(xxx_init);
60 module_exit(xxx_exit);
61
62 MODULE_LICENSE("GPL");
63 MODULE_AUTHOR("zuozhongkai");
第62 行,LICENSE 采用GPL 协议。
第63 行,添加作者名字。
至此,字符设备驱动开发的完整步骤就讲解完了,而且也编写好了一个完整的字符设备驱动模板,以后字符设备驱动开发都可以在此模板上进行。
Linux 设备号
设备号的组成
为了方便管理,Linux 中每个设备都有一个设备号,设备号由主设备号和次设备号两部分组成,主设备号表示某一个具体的驱动,次设备号表示使用这个驱动的各个设备。Linux 提供了一个名为dev_t 的数据类型表示设备号,dev_t 定义在文件include/linux/types.h 里面,定义如下:
12 typedef __u32 __kernel_dev_t;
......
15 typedef __kernel_dev_t dev_t;
可以看出dev_t 是__u32 类型的,而__u32 定义在文件include/uapi/asm-generic/int-ll64.h 里面,定义如下:
26 typedef unsigned int __u32;
综上所述,dev_t 其实就是unsigned int 类型,是一个32 位的数据类型。这32 位的数据构成了主设备号和次设备号两部分,其中高12 位为主设备号,低20 位为次设备号。因此Linux系统中主设备号范围为0~4095,所以大家在选择主设备号的时候一定不要超过这个范围。在文件include/linux/kdev_t.h 中提供了几个关于设备号的操作函数(本质是宏),如下所示:
6 #define MINORBITS 20
7 #define MINORMASK ((1U << MINORBITS) - 1)
8
9 #define MAJOR(dev) ((unsigned int) ((dev) >> MINORBITS))
10 #define MINOR(dev) ((unsigned int) ((dev) & MINORMASK))
11 #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi))
第6 行,宏MINORBITS 表示次设备号位数,一共是20 位。
第7 行,宏MINORMASK 表示次设备号掩码。
第9 行,宏MAJOR 用于从dev_t 中获取主设备号,将dev_t 右移20 位即可。
第10 行,宏MINOR 用于从dev_t 中获取次设备号,取dev_t 的低20 位的值即可。
第11 行,宏MKDEV 用于将给定的主设备号和次设备号的值组合成dev_t 类型的设备号。
设备号的分配
1、静态分配设备号
本小节讲的设备号分配主要是主设备号的分配。前面讲解字符设备驱动的时候说过了,注册字符设备的时候需要给设备指定一个设备号,这个设备号可以是驱动开发者静态的指定一个设备号,比如选择200 这个主设备号。有一些常用的设备号已经被Linux 内核开发者给分配掉了,具体分配的内容可以查看文档Documentation/devices.txt。并不是说内核开发者已经分配掉的主设备号我们就不能用了,具体能不能用还得看我们的硬件平台运行过程中有没有使用这个主设备号,使用“cat /proc/devices”命令即可查看当前系统中所有已经使用了的设备号。
2、动态分配设备号
静态分配设备号需要我们检查当前系统中所有被使用了的设备号,然后挑选一个没有使用的。而且静态分配设备号很容易带来冲突问题,Linux 社区推荐使用动态分配设备号,在注册字符设备之前先申请一个设备号,系统会自动给你一个没有被使用的设备号,这样就避免了冲突。
卸载驱动的时候释放掉这个设备号即可,设备号的申请函数如下:
int alloc_chrdev_region<以上是关于虚拟字符设备驱动开发的主要内容,如果未能解决你的问题,请参考以下文章
在Tomcat的安装目录下conf目录下的server.xml文件中增加一个xml代码片段,该代码片段中每个属性的含义与用途