Linux字符设备驱动基本框架

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

字符设备驱动简介

字符设备是 Linux 驱动中最基本的一类设备驱动，字符设备就是一个一个字节，按照字节流进行读写操作的设备，读写数据是分先后顺序的。比如我们最常见的点灯、按键、IIC、SPI，LCD 等等都是字符设备，这些设备的驱动就叫做字符设备驱动。

在详细的学习字符设备驱动架构之前，我们先来简单的了解一下 Linux 下的应用程序是如何调用驱动程序的，Linux 应用程序对驱动程序的调用如下图所示：

关于用户态和内核态的问题，参考：https://blog.csdn.net/JMW1407/article/details/107901155

在 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 库以及如何通过系统调用“陷入”到内核空间这个我们不用去管，我们重点关注的是应用程序和具体的驱动，应用程序使用到的函数在具体驱动程序中都有与之对应的函数，比如应用程序中调用了 open 这个函数，那么在驱动程序中也得有一个名为 open 的函数（注意，名称并不一定非要一模一样）。每一 个系统调用，在驱动中都有与之对应的一个驱动函数，在 Linux 内核文件 include/linux/fs.h 中 有个叫做 file_operations 的结构体，此结构体就是 Linux 内核驱动操作函数集合，内容如下所示：

简单介绍一下 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”命令加载驱动模块。

难怪menuconfig时，有个tristate三态类型，其中一种就是M，将模块编译成ko模块

在调试驱动的时候一般都选择将其编译为模块，这样我们修改驱动以后只需要编译一下驱动代码即可，不需要编译整个 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 函数就会被调用。字符设备驱动模块加载和卸载模板如下所示：

第 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/<kernel-version>目录中查找模块，比如本书使用的 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 行，定义了一个 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 这个结构体变量的初始化操作，完成以后的内容如下所示：

在示例代码 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 和作者信息，完成以后的内容如下：

第 62 行，LICENSE 采用 GPL 协议。 第 63 行，添加作者名字。

这个其实就是要声明Linux要遵循的开源协议。

参考：https://www.runoob.com/w3cnote/open-source-license.html 虽然Linux是开源，但是开源也要遵循一些协议的。

至此，字符设备驱动开发的完整步骤就讲解完了，而且也编写好了一个完整的字符设备驱动模板，以后字符设备驱动开发都可以在此模板上进行。

Linux 设备号

设备号的组成

为了方便管理，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 中提供了几个关于设备号的操作函数(本质是宏)，如下所示：

第 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(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 开始，要释放的设备号数量。

chrdevbase 字符设备驱动开发实验

字符设备驱动开发的基本步骤我们已经了解了，本节我们就以 chrdevbase 这个虚拟设备为例，完整的编写一个字符设备驱动模块。chrdevbase 不是实际存在的一个设备，是笔者为了方便讲解字符设备的开发而引入的一个虚拟设备。chrdevbase 设备有两个缓冲区，一个为读缓冲区，一个为写缓冲区，这两个缓冲区的大小都为 100 字节。在应用程序中可以向 chrdevbase 设备的写缓冲区中写入数据，从读缓冲区中读取数据。chrdevbase 这个虚拟设备的功能很简单，但是它包含了字符设备的最基本功能。

注意，读写的内存区域还是要我们在驱动里实现的，而不是凭空出现的，也不是内核给出的，我们在应用层使用系统调用来读写，驱动层也要支持读写才行，也要有内存区域可以读写才行。

应用程序调用 open 函数打开 chrdevbase 这个设备，打开以后可以使用 write 函数向chrdevbase 的写缓冲区writebuf 中写入数据(不超过 100 个字节)，也可以使用 read 函数读取读缓冲区 readbuf 中的数据操作，操作完成以后应用程序使用 close 函数关闭 chrdevbase 设备。

第 32~36 行，chrdevbase_open 函数，当应用程序调用 open 函数的时候此函数就会调用，本例程中我们没有做任何工作，只是输出一串字符，用于调试（驱动层没有做任何用户性的事情，应用层也要open来获取文件描述符）。这里使用了 printk 来输出信息，而不是 printf！因为在 Linux 内核中没有 printf 这个函数。printk 相当于 printf 的孪生兄妹，printf运行在用户态，printk 运行在内核态。在内核中想要向控制台输出或显示一些内容，必须使用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 和作者信息。

第 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 内容还是很简单的，就是最普通的文件打开、关闭和读写操作。

更多待补充。。。。。。