【正点原子Linux连载】第四十章 字符设备驱动开发 -摘自【正点原子】I.MX6U嵌入式Linux驱动开发指南V1.0

1）实验平台：正点原子阿尔法Linux开发板
2）平台购买地址：https://item.taobao.com/item.htm?id=603672744434
2）全套实验源码+手册+视频下载地址：http://www.openedv.com/thread-300792-1-1.html
3）对正点原子Linux感兴趣的同学可以加群讨论：935446741
4）关注正点原子公众号，获取最新资料更新

第四十章 字符设备驱动开发

本章我们从Linux驱动开发中最基础的字符设备驱动开始，重点学习Linux下字符设备驱动开发框架。本章会以一个虚拟的设备为例，讲解如何进行字符设备驱动开发，以及如何编写测试APP来测试驱动工作是否正常，为以后的学习打下坚实的基础。

40.1 字符设备驱动简介
字符设备是Linux驱动中最基本的一类设备驱动，字符设备就是一个一个字节，按照字节流进行读写操作的设备，读写数据是分先后顺序的。比如我们最常见的点灯、按键、IIC、SPI，LCD等等都是字符设备，这些设备的驱动就叫做字符设备驱动。
在详细的学习字符设备驱动架构之前，我们先来简单的了解一下Linux下的应用程序是如何调用驱动程序的，Linux应用程序对驱动程序的调用如图40.1.1所示：

图40.1.1 Linux应用程序对驱动程序的调用流程
在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所示：

图40.1.2 open函数调用流程
其中关于C库以及如何通过系统调用“陷入”到内核空间这个我们不用去管，我们重点关注的是应用程序和具体的驱动，应用程序使用到的函数在具体驱动程序中都有与之对应的函数，比如应用程序中调用了open这个函数，那么在驱动程序中也得有一个名为open的函数。每一个系统调用，在驱动中都有与之对应的一个驱动函数，在Linux内核文件 include/linux/fs.h中有个叫做file_operations的结构体，此结构体就是Linux内核驱动操作函数集合，内容如下所示：
示例代码40.1.1 file_operations结构体

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等都是需要实现的，当然了，具体需要实现哪些函数还是要看具体的驱动要求。
40.2 字符设备驱动开发步骤
上一小节我们简单的介绍了一下字符设备驱动，那么字符设备驱动开发都有哪些步骤呢？我们在学习裸机或者STM32的时候关于驱动的开发就是初始化相应的外设寄存器，在Linux驱动开发中肯定也是要初始化相应的外设寄存器，这个是毫无疑问的。只是在Linux驱动开发中我们需要按照其规定的框架来编写驱动，所以说学Linux驱动开发重点是学习其驱动框架。
40.2.1 驱动模块的加载和卸载
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函数就会被调用。字符设备驱动模块加载和卸载模板如下所示：
示例代码40.2.1.1 字符设备驱动模块加载和卸载函数模板

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命令。
40.2.2 字符设备注册与注销
对于字符设备驱动而言，当驱动模块加载成功以后需要注册字符设备，同样，卸载驱动模块的时候也需要注销掉字符设备。字符设备的注册和注销函数原型如下所示:
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中字符设备的注册和注销，内容如下所示：
示例代码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 查看当前设备
在图40.2.2.1中可以列出当前系统中所有的字符设备和块设备，其中第1列就是设备对应的主设备号。200这个主设备号在我的开发板中并没有被使用，所以我这里就用了200这个主设备号。
第21行，调用函数unregister_chrdev注销主设备号为200的这个设备。
40.2.3 实现设备的具体操作函数
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这个结构体变量的初始化操作，完成以后的内容如下所示：
示例代码40.2.3.1 加入设备操作函数

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这四个成员变量。

40.2.4 添加LICENSE和作者信息
最后我们需要在驱动中加入LICENSE信息和作者信息，其中LICENSE是必须添加的，否则的话编译的时候会报错，作者信息可以添加也可以不添加。LICENSE和作者信息的添加使用如下两个函数：
MODULE_LICENSE() //添加模块LICENSE信息
MODULE_AUTHOR() //添加模块作者信息
最后给示例代码40.2.3.1加入LICENSE和作者信息，完成以后的内容如下：
示例代码40.2.4.1 字符设备驱动最终的模板

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行，添加作者名字。
至此，字符设备驱动开发的完整步骤就讲解完了，而且也编写好了一个完整的字符设备驱动模板，以后字符设备驱动开发都可以在此模板上进行。

40.3 Linux设备号
40.3.1 设备号的组成
为了方便管理，Linux中每个设备都有一个设备号，设备号由主设备号和次设备号两部分组成，主设备号表示某一个具体的驱动，次设备号表示使用这个驱动的各个设备。Linux提供了一个名为dev_t的数据类型表示设备号，dev_t定义在文件include/linux/types.h里面，定义如下：
示例代码40.3.1 设备号dev_t
12 typedef __u32 __kernel_dev_t;
…
15 typedef __kernel_dev_t dev_t;
可以看出dev_t是__u32类型的，而__u32定义在文件include/uapi/asm-generic/int-ll64.h里面，定义如下：
示例代码40.3.2 __u32类型
26 typedef unsigned int __u32;
综上所述，dev_t其实就是unsigned int类型，是一个32位的数据类型。这32位的数据构成了主设备号和次设备号两部分，其中高12位为主设备号，低20位为次设备号。因此Linux系统中主设备号范围为0~4095，所以大家在选择主设备号的时候一定不要超过这个范围。在文件include/linux/kdev_t.h中提供了几个关于设备号的操作函数(本质是宏)，如下所示：
示例代码40.3.3 设备号操作函数

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类型的设备号。

40.3.2 设备号的分配
1、静态分配设备号
本小节讲的设备号分配主要是主设备号的分配。前面讲解字符设备驱动的时候说过了，注册字符设备的时候需要给设备指定一个设备号，这个设备号可以是驱动开发者静态的指定一个设备号，比如选择200这个主设备号。有一些常用的设备号已经被Linux内核开发者给分配掉了，具体分配的内容可以查看文档Documentation/devices.txt。并不是说内核开发者已经分配掉的主设备号我们就不能用了，具体能不能用还得看我们的硬件平台运行过程中有没有使用这个主设备号，使用“cat /proc/devices”命令即可查看当前系统中所有已经使用了的设备号。
2、动态分配设备号
静态分配设备号需要我们检查当前系统中所有被使用了的设备号，然后挑选一个没有使用的。而且静态分配设备号很容易带来冲突问题，Linux社区推荐使用动态分配设备号，在注册字符设备之前先申请一个设备号，系统会自动给你一个没有被使用的设备号，这样就避免了冲突。卸载驱动的时候释放掉这个设备号即可，设备号的申请函数如下：
int alloc_chrdev_region(dev_t *dev, unsigned baseminor, unsigned count, const char *name)
函数alloc_chrdev_region用于申请设备号，此函数有4个参数：
dev：保存申请到的设备号。
baseminor：次设备号起始地址，alloc_chrdev_region可以申请一段连续的多个设备号，这些设备号的主设备号一样，但是次设备号不同，次设备号以baseminor为起始地址地址开始递增。一般baseminor为0，也就是说次设备号从0开始。
count：要申请的设备号数量。
name：设备名字。
注销字符设备之后要释放掉设备号，设备号释放函数如下：
void unregister_chrdev_region(dev_t from, unsigned count)
此函数有两个参数：
from：要释放的设备号。
count：表示从from开始，要释放的设备号数量。
40.4 chrdevbase字符设备驱动开发实验
字符设备驱动开发的基本步骤我们已经了解了，本节我们就以chrdevbase这个虚拟设备为例，完整的编写一个字符设备驱动模块。chrdevbase不是实际存在的一个设备，是笔者为了方便讲解字符设备的开发而引入的一个虚拟设备。chrdevbase设备有两个缓冲区，一个为读缓冲区，一个为写缓冲区，这两个缓冲区的大小都为100字节。在应用程序中可以向chrdevbase设备的写缓冲区中写入数据，从读缓冲区中读取数据。chrdevbase这个虚拟设备的功能很简单，但是它包含了字符设备的最基本功能。
40.4.1 实验程序编写
本实验对应的例程路径为：开发板光盘-> 2、Linux驱动例程-> 1_chrdevbase。
应用程序调用open函数打开chrdevbase这个设备，打开以后可以使用write函数向chrdevbase的写缓冲区writebuf中写入数据(不超过100个字节)，也可以使用read函数读取读缓冲区readbuf中的数据操作，操作完成以后应用程序使用close函数关闭chrdevbase设备。
1、创建VSCode工程
在Ubuntu中创建一个目录用来存放Linux驱动程序，比如我创建了一个名为Linux_Drivers的目录来存放所有的Linux驱动。在Linux_Drivers目录下新建一个名为1_chrdevbase的子目录来存放本实验所有文件，如图40.4.1.1所示：

图40.4.1.1 Linux实验程序目录
在1_chrdevbase目录中新建VSCode工程，并且新建chrdevbase.c文件，完成以后1_chrdevbase目录中的文件如图40.4.1.2所示：

图40.4.1.2 1_chardevbase目录文件
2、添加头文件路径
因为是编写Linux驱动，因此会用到Linux源码中的函数。我们需要在VSCode中添加Linux源码中的头文件路径。打开VSCode，按下“Crtl+Shift+P”打开VSCode的控制台，然后输入“C/C++: Edit configurations(JSON) ”，打开C/C++编辑配置文件，如图40.4.1.3所示：

图40.4.1.3 C/C++编辑配置文件。
打开以后会自动在.vscode目录下生成一个名为c_cpp_properties.json的文件，此文件默认内容如下所示：
示例代码40.4.1.1 c_cpp_properties.json文件原内容

1  {
2      "configurations": [
3          {
4              "name": "Linux",
5              "includePath": [
6                  "${workspaceFolder}/**",
7                  ],
8              "defines": [],
9              "compilerPath": "/usr/bin/clang",
10             "cStandard": "c11",
11             "cppStandard": "c++17",
12             "intelliSenseMode": "clang-x64"
13         }
14     ],
15     "version": 4
16 }

第5行的includePath表示头文件路径，需要将Linux源码里面的头文件路径添加进来，也就是我们前面移植的Linux源码中的头文件路径。添加头文件路径以后的c_cpp_properties.json的文件内容如下所示：

示例代码40.4.1.2 添加头文件路径后的c_cpp_properties.json

1  {
2      "configurations": [
3          {
4              "name": "Linux",
5              "includePath": [
6                  "${workspaceFolder}/**",
7                  "/home/zuozhongkai/linux/IMX6ULL/linux/temp/linux-imx-rel_imx_4.1.15_2.1.0_ga_alientek/include", 
8                  "/home/zuozhongkai/linux/IMX6ULL/linux/temp/linux-imx-rel_imx_4.1.15_2.1.0_ga_alientek/arch/arm/include", 
9                  "/home/zuozhongkai/linux/IMX6ULL/linux/temp/linux-imx-rel_imx_4.1.15_2.1.0_ga_alientek/arch/arm/include/generated/"
10             ],
11             "defines": [],
......
16         }
17     ],
18     "version": 4
19 }

第7~9行就是添加好的Linux头文件路径。分别是开发板所使用的Linux源码下的include、arch/arm/include和arch/arm/include/generated这三个目录的路径，注意，这里使用了绝对路径。
3、编写实验程序
工程建立好以后就可以开始编写驱动程序了，新建chrdevbase.c，然后在里面输入如下内容：

示例代码40.4.1.3 chrdevbase.c文件

1   #include <linux/types.h>
2   #include <linux/kernel.h>
3   #include <linux/delay.h>
4   #include <linux/ide.h>
5   #include <linux/init.h>
6   #include <linux/module.h>
7   /***************************************************************
8   Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved.
9   文件名 	: chrdevbase.c
10  作者   	: 左忠凯
11  版本   	: V1.0
12  描述   	: chrdevbase驱动文件。
13  其他   	: 无
14  论坛   	: www.openedv.com
15  日志   	: 初版V1.0 2019/1/30 左忠凯创建
16  ***************************************************************/
17  
18  #define CHRDEVBASE_MAJOR    200             		/* 主设备号 		*/
19  #define CHRDEVBASE_NAME     "chrdevbase"    	/* 设备名     	*/
20  
21  static char readbuf[100];       					/* 读缓冲区 		*/
22  static char writebuf[100];      					/* 写缓冲区 		*/
23  static char kerneldata[] = {"kernel data!"};
24  
25  /*
26   * @description 	: 打开设备
27   * @param – inode	: 传递给驱动的inode
28   * @param - filp 	: 设备文件，file结构体有个叫做private_data的成员变量
29   *                    一般在open的时候将private_data指向设备结构体。
30   * @return       	: 0 成功;其他 失败
31   */
32  static int chrdevbase_open(struct inode *inode, struct file *filp)
33  {
34      //printk("chrdevbase open!\r\n");
35      return 0;
36  }
37  
38  /*
39   * @description  	: 从设备读取数据 
40   * @param - filp 	: 要打开的设备文件(文件描述符)
41   * @param - buf  	: 返回给用户空间的数据缓冲区
42   * @param - cnt  	: 要读取的数据长度
43   * @param - offt 	: 相对于文件首地址的偏移
44   * @return       	: 读取的字节数，如果为负值，表示读取失败
45   */
46  static ssize_t chrdevbase_read(struct file *filp, char __user *buf, 
size_t cnt, loff_t *offt)
47  {
48      int retvalue = 0;
49      
50      /* 向用户空间发送数据 */
51      memcpy(readbuf, kerneldata, sizeof(kerneldata));
52      retvalue = copy_to_user(buf, readbuf, cnt);
53      if(retvalue == 0){
54          printk("kernel senddata ok!\r\n");
55      }else{
56          printk("kernel senddata failed!\r\n");
57      }
58      
59      //printk("chrdevbase read!\r\n");
60      return 0;
61  }
62  
63  /*
64   * @description  	: 向设备写数据 
65   * @param - filp 	: 设备文件，表示打开的文件描述符
66   * @param - buf  	: 要写给设备写入的数据
67   * @param - cnt  	: 要写入的数据长度
68   * @param - offt 	: 相对于文件首地址的偏移
69   * @return        	: 写入的字节数，如果为负值，表示写入失败
70   */
71  static ssize_t chrdevbase_write(struct file *filp, 
const char __user *buf, 
size_t cnt, loff_t *offt)
72  {
73      int retvalue = 0;
74      /* 接收用户空间传递给内核的数据并且打印出来 */
75      retvalue = copy_from_user(writebuf, buf, cnt);
76      if(retvalue == 0){
77          printk("kernel recevdata:%s\r\n", writebuf);
78      }else{
79          printk("kernel recevdata failed!\r\n");
80      }
81      
82      //printk("chrdevbase write!\r\n");
83      return 0;
84  }
85  
86  /*
87   * @description  	: 关闭/释放设备
88   * @param - filp 	: 要关闭的设备文件(文件描述符)
89   * @return       	: 0 成功;其他 失败
90   */
91  static int chrdevbase_release(struct inode *inode, 
struct file *filp)
92  {
93      //printk("chrdevbase release！\r\n");
94      return 0;
95  }
96  
97  /*
98   * 设备操作函数结构体
99   */
100 static struct file_operations chrdevbase_fops = {
101     .owner = THIS_MODULE,   
102     .open = chrdevbase_open,
103     .read = chrdevbase_read,
104     .write = chrdevbase_write,
105     .release = chrdevbase_release,
106 };
107 
108 /*
109  * @description 	: 驱动入口函数 
110  * @param       	: 无
111  * @return      	: 0 成功;其他 失败
112  */
113 static int __init chrdevbase_init(void)
114 {
115     int retvalue = 0;
116 
117     /* 注册字符设备驱动 */
118     retvalue = register_chrdev(CHRDEVBASE_MAJOR, CHRDEVBASE_NAME, 
&chrdevbase_fops);
119     if(retvalue < 0){
120         printk("chrdevbase driver register failed\r\n");
121     }
122     printk("chrdevbase_init()\r\n");
123     return 0;
124 }
125 
126 /*
127  * @description 	: 驱动出口函数
128  * @param       	: 无
129  * @return      	: 无
130  */
131 static void __exit chrdevbase_exit(void)
132 {
133     /* 注销字符设备驱动 */
134     unregister_chrdev(CHRDEVBASE_MAJOR, CHRDEVBASE_NAME);
135     printk("chrdevbase_exit()\r\n");
136 }
137 
138 /* 
139  * 将上面两个函数指定为驱动的入口和出口函数 
140  */
141 module_init(chrdevbase_init);
142 module_exit(chrdevbase_exit);
143 
144 /* 
145  * LICENSE和作者信息
146  */
147 MODULE_LICENSE("GPL");
148 MODULE_AUTHOR("zuozhongkai");

第32~36行，chrdevbase_open函数，当应用程序调用open函数的时候此函数就会调用，本例程中我们没有做任何工作，只是输出一串字符，用于调试。这里使用了printk来输出信息，而不是printf！因为在Linux内核中没有printf这个函数。printk相当于printf的孪生兄妹，printf运行在用户态，printk运行在内核态。在内核中想要向控制台输出或显示一些内容，必须使用printk这个函数。不同之处在于，printk可以根据日志级别对消息进行分类，一共有8个消息级别，这8个消息级别定义在文件include/linux/kern_levels.h里面，定义如下：

#define KERN_SOH		"\001"	
#define KERN_EMERG		KERN_SOH "0"	/* 紧急事件，一般是内核崩溃 			*/
#define KERN_ALERT		KERN_SOH "1"	/* 必须立即采取行动 					*/
#define KERN_CRIT		KERN_SOH "2"	/* 临界条件，比如严重的软件或硬件错误*/
#define KERN_ERR		KERN_SOH "3"	/* 错误状态，一般设备驱动程序中使用
KERN_ERR报告硬件错误      	*/
#define KERN_WARNING	KERN_SOH "4"	/* 警告信息，不会对系统造成严重影响	*/
#define KERN_NOTICE	KERN_SOH "5"	/* 有必要进行提示的一些信息			*/
#define KERN_INFO		KERN_SOH "6"	/* 提示性的信息 						*/
#define KERN_DEBUG		KERN_SOH "7"	/* 调试信息							*/

一共定义了8个级别，其中0的优先级最高，7的优先级最低。如果要设置消息级别，参考如下示例：

printk(KERN_EMERG “gsmi: Log Shutdown Reason\n”);
上述代码就是设置“gsmi: Log Shutdown Reason\n”这行消息的级别为KERN_EMERG。在具体的消息前面加上KERN_EMERG就可以将这条消息的级别设置为KERN_EMERG。如果使用printk的时候不显式的设置消息级别，那么printk将会采用默认级别MESSAGE_LOGLEVEL_DEFAULT，MESSAGE_LOGLEVEL_DEFAULT默认为4。
在include/linux/printk.h中有个宏CONSOLE_LOGLEVEL_DEFAULT，定义如下：
#define CONSOLE_LOGLEVEL_DEFAULT 7
CONSOLE_LOGLEVEL_DEFAULT控制着哪些级别的消息可以显示在控制台上，此宏默认为7，意味着只有优先级高于7的消息才能显示在控制台上。
这个就是printk和printf的最大区别，可以通过消息级别来决定哪些消息可以显示在控制台上。默认消息级别为4，4的级别比7高，所示直接使用printk输出的信息是可以显示在控制台上的。
参数filp有个叫做private_data的成员变量，private_data是个void指针，一般在驱动中将private_data指向设备结构体，设备结构体会存放设备的一些属性。
第46~61行，chrdevbase_read函数，应用程序调用read函数从设备中读取数据的时候此函数会执行。参数buf是用户空间的内存，读取到的数据存储在buf中，参数cnt是要读取的字节数，参数offt是相对于文件首地址的偏移。kerneldata里面保存着用户空间要读取的数据，第51行先将kerneldata数组中的数据拷贝到读缓冲区readbuf中，第52行通过函数copy_to_user将readbuf中的数据复制到参数buf中。因为内核空间不能直接操作用户空间的内存，因此需要借助copy_to_user函数来完成内核空间的数据到用户空间的复制。copy_to_user函数原型如下：
static inline long copy_to_user(void __user *to, const void *from, unsigned long n)
参数to表示目的，参数from表示源，参数n表示要复制的数据长度。如果复制成功，返回值为0，如果复制失败则返回负数。
第71~84行，chrdevbase_write函数，应用程序调用write函数向设备写数据的时候此函数就会执行。参数buf就是应用程序要写入设备的数据，也是用户空间的内存，参数cnt是要写入的数据长度，参数offt是相对文件首地址的偏移。第75行通过函数copy_from_user将buf中的数据复制到写缓冲区writebuf中，因为用户空间内存不能直接访问内核空间的内存，所以需要借助函数copy_from_user将用户空间的数据复制到writebuf这个内核空间中。
第91~95行，chrdevbase_release函数，应用程序调用close关闭设备文件的时候此函数会执行，一般会在此函数里面执行一些释放操作。如果在open函数中设置了filp的private_data成员变量指向设备结构体，那么在release函数最终就要释放掉。
第100~106行，新建chrdevbase的设备文件操作结构体chrdevbase_fops，初始化chrdevbase_fops。
第113~124行，驱动入口函数chrdevbase_init，第118行调用函数register_chrdev来注册字符设备。
第131~136行，驱动出口函数chrdevbase_exit，第134行调用函数unregister_chrdev来注销字符设备。
第141~142行，通过module_init和module_exit这两个函数来指定驱动的入口和出口函数。
第147~148行，添加LICENSE和作者信息。
40.4.2 编写测试APP
1、C库文件操作基本函数
编写测试APP就是编写Linux应用，需要用到C库里面和文件操作有关的一些函数，比如open、read、write和close这四个函数。
①、open函数
open函数原型如下：
int open(const char *pathname, int flags)
open函数参数含义如下：
pathname：要打开的设备或者文件名。
flags：文件打开模式，以下三种模式必选其一：
O_RDONLY 只读模式
O_WRONLY 只写模式
O_RDWR　　 读写模式
因为我们要对chrdevbase这个设备进行读写操作，所以选择O_RDWR。除了上述三种模式以外还有其他的可选模式，通过逻辑或来选择多种模式：
O_APPEND　　 每次写操作都写入文件的末尾
O_CREAT　　 如果指定文件不存在，则创建这个文件
O_EXCL　　 如果要创建的文件已存在，则返回 -1，并且修改 errno 的值
O_TRUNC　　 如果文件存在，并且以只写/读写方式打开，则清空文件全部内容
O_NOCTTY　　 如果路径名指向终端设备，不要把这个设备用作控制终端。
O_NONBLOCK 如果路径名指向 FIFO/块文件/字符文件，则把文件的打开和后继 I/O设置为非阻塞
DSYNC　　 等待物理 I/O 结束后再 write。在不影响读取新写入的数据的前提
下，不等待文件属性更新。
O_RSYNC　　 read 等待所有写入同一区域的写操作完成后再进行。
O_SYNC　　 等待物理 I/O 结束后再 write，包括更新文件属性的 I/O。
返回值：如果文件打开成功的话返回文件的文件描述符。
在Ubuntu中输入“man 2 open”即可查看open函数的详细内容，如图40.4.2.1所示：

图40.4.2.1 open函数帮助信息
②、read函数
read函数原型如下：
ssize_t read(int fd, void *buf, size_t count)
read函数参数含义如下：
fd：要读取的文件描述符，读取文件之前要先用open函数打开文件，open函数打开文件成功以后会得到文件描述符。
buf：数据读取到此buf中。
count：要读取的数据长度，也就是字节数。
返回值：读取成功的话返回读取到的字节数；如果返回0表示读取到了文件末尾；如果返回负值，表示读取失败。在Ubuntu中输入“man 2 read”命令即可查看read函数的详细内容。
③、write函数
write函数原型如下：
ssize_t write(int fd, const void *buf, size_t count);
write函数参数含义如下：
fd：要进行写操作的文件描述符，写文件之前要先用open函数打开文件，open函数打开文件成功以后会得到文件描述符。
buf：要写入的数据。
count：要写入的数据长度，也就是字节数。
返回值：写入成功的话返回写入的字节数；如果返回0表示没有写入任何数据；如果返回负值，表示写入失败。在Ubuntu中输入“man 2 write”命令即可查看write函数的详细内容。
④、close函数
close函数原型如下：
int close(int fd);
close函数参数含义如下：
fd：要关闭的文件描述符。
返回值：0表示关闭成功，负值表示关闭失败。在Ubuntu中输入“man 2 close”命令即可查看close函数的详细内容。
2、编写测试APP程序
驱动编写好以后是需要测试的，一般编写一个简单的测试APP，测试APP运行在用户空间。测试APP很简单通过输入相应的指令来对chrdevbase设备执行读或者写操作。在1_chrdevbase目录中新建chrdevbaseApp.c文件，在此文件中输入如下内容：
示例代码40.4.2.1 chrdevbaseApp.c文件

1  #include "stdio.h"
2  #include "unistd.h"
3  #include "sys/types.h"
4  #include "sys/stat.h"
5  #include "fcntl.h"
6  #include "stdlib.h"
7  #include "string.h"
8  /***************************************************************
9  Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved.
10 文件名     : chrdevbaseApp.c
11 作者       : 左忠凯
12 版本       : V1.0
13 描述       : chrdevbase驱测试APP。
14 其他       : 使用方法：./chrdevbaseApp /dev/chrdevbase <1>|<2>
15              argv[2] 1:读文件
16              argv[2] 2:写文件       
17 论坛       : www.openedv.com
18 日志       : 初版V1.0 2019/1/30 左忠凯创建
19 ***************************************************************/
20 
21 static char usrdata[] = {"usr data!"};
22 
23 /*
24  * @description  	: main主程序
25  * @param - argc  	: argv数组元素个数
26  * @param - argv  	: 具体参数
27  * @return        	: 0 成功;其他 失败
28  */
29 int main(int argc, char *argv[])
30 {
31  	int fd, retvalue;
32  	char *filename;
33  	char readbuf[100], writebuf[100];
34 
35  	if(argc != 3){
36      	printf("Error Usage!\r\n");
37      	return -1;
38  	}
39 
40  	filename = argv[1];
41 
42  	/* 打开驱动文件 */
43  	fd  = open(filename, O_RDWR);
44  	if(fd < 0){
45      	printf("Can't open file %s\r\n", filename);
46      	return -1;
47  	}
48 
49  	if(atoi(argv[2]) == 1){ /* 从驱动文件读取数据 */
50      	retvalue = read(fd, readbuf, 50);
51      	if(retvalue < 0){
52         		printf("read file %s failed!\r\n", filename);
53      	}else{
54         		/*  读取成功，打印出读取成功的数据 */
55          		printf("read data:%s\r\n",readbuf);
56      	}	
57  	}
58 
59  	if(atoi(argv[2]) == 2){
60      	/* 向设备驱动写数据 */
61      	memcpy(writebuf, usrdata, sizeof(usrdata));
62      	retvalue = write(fd, writebuf, 50);
63      	if(retvalue < 0){
64          		printf("write file %s failed!\r\n", filename);
65      	}
66  	}
67 
68  	/* 关闭设备 */
69  	retvalue = close(fd);
70  	if(retvalue < 0){
71      	printf("Can't close file %s\r\n", filename);
72      	return -1;
73  	}
74 
75  	return 0;
76 }

第21行，数组usrdata是测试APP要向chrdevbase设备写入的数据。
第35行，判断运行测试APP的时候输入的参数是不是为3个，main函数的argc参数表示参数数量，argv[]保存着具体的参数，如果参数不为3个的话就表示测试APP用法错误。比如，现在要从chrdevbase设备中读取数据，需要输入如下命令：

./chrdevbaseApp /dev/chrdevbase 1
上述命令一共有三个参数“./chrdevbaseApp”、“/dev/chrdevbase”和“1”，这三个参数分别对应argv[0]、argv[1]和argv[2]。第一个参数表示运行chrdevbaseAPP这个软件，第二个参数表示测试APP要打开/dev/chrdevbase这个设备。第三个参数就是要执行的操作，1表示从chrdevbase中读取数据，2表示向chrdevbase写数据。
第40行，获取要打开的设备文件名字，argv[1]保存着设备名字。
第43行，调用C库中的open函数打开设备文件：/dev/chrdevbase。
第49行，判断argv[2]参数的值是1还是2，因为输入命令的时候其参数都是字符串格式的，因此需要借助atoi函数将字符串格式的数字转换为真实的数字。
第50行，当argv[2]为1的时候表示要从chrdevbase设备中读取数据，一共读取50字节的数据，读取到的数据保存在readbuf中，读取成功以后就在终端上打印出读取到的数据。
第59行，当argv[2]为2的时候表示要向chrdevbase设备写数据。
第69行，对chrdevbase设备操作完成以后就关闭设备。
chrdevbaseApp.c内容还是很简单的，就是最普通的文件打开、关闭和读写操作。
40.4.3 编译驱动程序和测试APP
1、编译驱动程序
首先编译驱动程序，也就是chrdevbase.c这个文件，我们需要将其编译为.ko模块，创建Makefile文件，然后在其中输入如下内容：
示例代码40.4.3.1 Makefile文件

1  KERNELDIR := /home/zuozhongkai/linux/IMX6ULL/linux/temp/linux-imx-rel_imx_4.1.15_2.1.0_ga_alientek
2  CURRENT_PATH := $(shell pwd)
3  obj-m := chrdevbase.o
4  
5  build: kernel_modules
6  
7  kernel_modules:
8   	$(MAKE) -C $(KERNELDIR) M=$(CURRENT_PATH) modules
9  clean:
10  	$(MAKE) -C $(KERNELDIR) M=$(CURRENT_PATH) clean

第1行，KERNELDIR表示开发板所使用的Linux内核源码目录，使用绝对路径，大家根据自己的实际情况填写即可。
第2行，CURRENT_PATH表示当前路径，直接通过运行“pwd”命令来获取当前所处路径。
第3行，obj-m表示将chrdevbase.c这个文件编译为chrdevbase.ko模块。
第8行，具体的编译命令，后面的modules表示编译模块，-C表示将当前的工作目录切换到指定目录中，也就是KERNERLDIR目录。M表示模块源码目录，“make modules”命令中加入M=dir以后程序会自动到指定的dir目录中读取模块的源码并将其编译为.ko文件。
Makefile编写好以后输入“make”命令编译驱动模块，编译过程如图40.4.3.1所示：

图40.4.3.1 驱动模块编译过程
编译成功以后就会生成一个叫做chrdevbaes.ko的文件，此文件就是chrdevbase设备的驱动模块。至此，chrdevbase设备的驱动就编译成功。
2、编译测试APP
测试APP比较简单，只有一个文件，因此就不需要编写Makefile了，直接输入命令编译。因为测试APP是要在ARM开发板上运行的，所以需要使用arm-linux-gnueabihf-gcc来编译，输入如下命令：
arm-linux-gnueabihf-gcc chrdevbaseApp.c -o chrdevbaseApp
编译完成以后会生成一个叫做chrdevbaseApp的可执行程序，输入如下命令查看chrdevbaseAPP这个程序的文件信息：
file chrdevbaseApp
结果如图40.4.3.2所示：

图40.4.3.2 chrdevbaseAPP文件信息
从图40.4.3.2可以看出，chrdevbaseAPP这个可执行文件是32位LSB格式，ARM版本的，因此chrdevbaseAPP只能在ARM芯片下运行。
40.4.4 运行测试
1、加载驱动模块
驱动模块chrdevbase.ko和测试软件chrdevbaseAPP都已经准备好了，接下来就是运行测试。为了方便测试，Linux系统选择通过TFTP从网络启动，并且使用NFS挂载网络根文件系统，确保uboot中bootcmd环境变量的值为：
tftp 80800000 zImage;tftp 83000000 imx6ull-alientek-emmc.dtb;bootz 80800000 - 83000000
bootargs环境变量的值为：
console=ttymxc0,115200 root=/dev/nfs rw nfsroot=192.168.1.250:/home/zuozhongkai/linux/nfs/
rootfs ip=192.168.1.251:192.168.1.250:192.168.1.1:255.255.255.0::eth0:off
设置好以后启动Linux系统，检查开发板根文件系统中有没有“/lib/modules/4.1.15”这个目录，如果没有的话自行创建。注意，“/lib/modules/4.1.15”这个目录用来存放驱动模块，使用modprobe命令加载驱动模块的时候，驱动模块要存放在此目录下。“/lib/modules”是通用的，不管你用的什么板子、什么内核，这部分是一样的。不一样的是后面的“4.1.15”，这里要根据你所使用的Linux内核版本来设置，比如ALPHA开发板现在用的是4.1.15版本的Linux内核，因此就是“/lib/modules/4.1.15”。如果你使用的其他版本内核，比如5.14.31，那么就应该创建“/lib/modules/5.14.31”目录，否则modprobe命令无法加载驱动模块。
因为是通过NFS将Ubuntu中的rootfs(第三十八章制作好的根文件系统)目录挂载为根文件系统，所以可以很方便的将chrdevbase.ko和chrdevbaseAPP复制到rootfs/lib/modules/4.1.15目录中，命令如下：
sudo cp chrdevbase.ko chrdevbaseApp /home/zuozhongkai/linux/nfs/rootfs/lib/modules/4.1.15/ -f
拷贝完成以后就会在开发板的/lib/modules/4.1.15目录下存在chrdevbase.ko和chrdevbaseAPP这两个文件，如图40.4.4.1所示：

图40.4.4.1 驱动和测试文件
输入如下命令加载chrdevbase.ko驱动文件：
insmod chrdevbase.ko
或
modprobe chrdevbase.ko
如果使用modprobe加载驱动的话，可能会出现如图40.4.4.2所示的提示：

图40.4.4.2 modprobe错误提示
从图40.4.4.2可以看出，modprobe提示无法打开“modules.dep”这个文件，因此驱动挂载失败了。我们不用手动创建modules.dep这个文件，直接输入depmod命令即可自动生成modules.dep，有些根文件系统可能没有depmod这个命令，如果没有这个命令就只能重新配置busybox，使能此命令，然后重新编译busybox。输入“depmod”命令以后会自动生成modules.alias、modules.symbols和modules.dep这三个文件，如图40.4.4.3所示：

图40.4.4.3 depmod命令执行结果
重新使用modprobe加载chrdevbase.ko，结果如图40.4.4.4所示：

图40.4.4.4 驱动加载成功
从图40.4.4.4可以看到“chrdevbase init！”这一行，这一行正是chrdevbase.c中模块入口函数chrdevbase_init输出的信息，说明模块加载成功！
输入“lsmod”命令即可查看当前系统中存在的模块，结果如图40.4.4.5所示：

图40.4.4.5 当前系统中的模块
从图40.4.4.5可以看出，当前系统只有“chrdevbase”这一个模块。输入如下命令查看当前系统中有没有chrdevbase这个设备：
cat /proc/devices
结果如图40.4.4.6所示：

图40.4.4.6 当前系统设备
从图40.4.4.6可以看出，当前系统存在chrdevbase这个设备，主设备号为200，跟我们设置的主设备号一致。
2、创建设备节点文件
驱动加载成功需要在/dev目录下创建一个与之对应的设备节点文件，应用程序就是通过操作这个设备节点文件来完成对具体设备的操作。输入如下命令创建/dev/chrdevbase这个设备节点文件：
mknod /dev/chrdevbase c 200 0
其中“mknod”是创建节点命令，“/dev/chrdevbase”是要创建的节点文件，“c”表示这是个字符设备，“200”是设备的主设备号，“0”是设备的次设备号。创建完成以后就会存在/dev/chrdevbase这个文件，可以使用“ls /dev/chrdevbase -l”命令查看，结果如图40.4.4.7所示：

图40.4.4.7 /dev/chrdevbase文件
如果chrdevbaseAPP想要读写chrdevbase设备，直接对/dev/chrdevbase进行读写操作即可。相当于/dev/chrdevbase这个文件是chrdevbase设备在用户空间中的实现。前面一直说Linux下一切皆文件，包括设备也是文件，现在大家应该是有这个概念了吧？
3、chrdevbase设备操作测试
一切准备就绪，接下来就是“大考”的时刻了。使用chrdevbaseApp软件操作chrdevbase这个设备，看看读写是否正常，首先进行读操作，输入如下命令：
./chrdevbaseApp /dev/chrdevbase 1
结果如图40.4.4.8所示：

图40.4.4.8 读操作结果
从图40.4.4.8可以看出，首先输出“kernel senddata ok!”这一行信息，这是驱动程序中chrdevbase_read函数输出的信息，因为chrdevbaseAPP使用read函数从chrdevbase设备读取数据，因此chrdevbase_read函数就会执行。chrdevbase_read函数向chrdevbaseAPP发送“kernel data!”数据，chrdevbaseAPP接收到以后就打印出来，“read data:kernel data!”就是chrdevbaseAPP打印出来的接收到的数据。说明对chrdevbase的读操作正常，接下来测试对chrdevbase设备的写操作，输入如下命令：
./chrdevbaseApp /dev/chrdevbase 2
结果如图40.4.4.9所示：

图40.4.4.9 写操作结果
只有一行“kernel recevdata:usr data!”，这个是驱动程序中的chrdevbase_write函数输出的。chrdevbaseAPP使用write函数向chrdevbase设备写入数据“usr data!”。chrdevbase_write函数接收到以后将其打印出来。说明对chrdevbase的写操作正常，既然读写都没问题，说明我们编写的chrdevbase驱动是没有问题的。
4、卸载驱动模块
如果不再使用某个设备的话可以将其驱动卸载掉，比如输入如下命令卸载掉chrdevbase这个设备：
rmmod chrdevbase.ko
卸载以后使用lsmod命令查看chrdevbase这个模块还存不存在，结果如图40.4.4.10所示：

图40.4.4.10 系统中当前模块
从图40.4.4.10可以看出，此时系统已经没有任何模块了，chrdevbase这个模块也不存在了，说明模块卸载成功。
至此，chrdevbase这个设备的整个驱动就验证完成了，驱动工作正常。本章我们详细的讲解了字符设备驱动的开发步骤，并且以一个虚拟的chrdevbase设备为例，带领大家完成了第一个字符设备驱动的开发，掌握了字符设备驱动的开发框架以及测试方法，以后的字符设备驱动实验基本都以此为蓝本。