在前面几个模块的介绍中，我们主要以vfs为起始，完成了sysfs、设备-总线-驱动模型、platform设备驱动模型、i2c设备驱动模型、spi设备驱动模型的分析。在对这些模块进行分析的时候，我们或多或少均对字符设备驱动进行了一些说明，此前认为字符设备驱动模型比较简单，也没打算进行分析，但为了让本次学习的内容能够全面和关联，本次还是打算开一次字符设备驱动模型的分析。关于字符设备驱动模型的分析，主要涉及如下几个部分：

一、LINUX字符设备驱动模型分析

二、LINUX 混杂设备驱动模型分析（并介绍一个混杂设备驱动模型的实例：watchdog驱动模型）

三、LINUX RTC设备驱动模型分析

本篇作为字符设备驱动模型分析的第一篇，主要介绍字符设备驱动模型。

字符设备驱动模型的总体说明

针对字符设备驱动模型，主要通过设备号来进行区分不同的设备，而设备号由主设备号+次设备号组合而成，其中主设备号占用高8位，次设备号占用低20位。因此支持的主设备号为255个，而针对每一个主设备号，则可以支持多个次设备号。针对字符设备驱动模块，包括两个主要的部分：字符设备号的管理、字符设备的管理，其中字符设备号的管理主要用于管理系统中已注册的字符设备号的使用情况，防止字符设备号被重复注册等操作；而字符设备的管理主要涉及字符设备的引用计数、字符设备与sysfs的关联等内容。针对这两个部分主要涉及结构体struct char_device_struct、struct cdev ，其中char_device_struct实现了对已注册的字符设备区间的管理，并完成与cdev的关联，而cdev主要用于实现该cdev的引用计数、与sysfs的关联（实现再/sysfs下的char子目录下完成文件及目录的创建等内容）。

相关结构体说明

struct char_device_struct

该结构体主要用于描述一个字符设备相关的字符设备号的区间以及对应的字符设备指针和字符设备的名称等字符设备相关信息的抽象。

1. next成员实现这些结构体之间的关联，在系统中主要是完成该类型变量的链接（主设备号相同，次设备号不同且次设备号区间不交叉的结构体变量才会链接在一起）；
2. major表示字符设备的主设备号；
3. baseminor表示起始次设备号；
4. minorct表示该字符设备支持的最大次设备个数；
5. cdev指针指向该字符设备对应的设备抽象结构体变量。

struct cdev

该结构体主要是字符设备的抽象，该结构体包含的主要内容如下：

1. kobj变量主要用于实现引用计数的功能，针对字符设备驱动模型，其kobj_type有两种方式：
1. 一种是针对使用字符设备驱动模型创建的cdev，针对这一类的cdev，则其kobj_type为ktype_cdev_dynamic，通过该kobject方法，可通过kobject的kref，实现cdev变量的自行释放操作（调用cdev_dynamic_release接口，去除cdev->list链表上所有的inode->i_devices，并解除inode与cdev的绑定操作，最后释放给cdev）；
2. 一种是各字符设备驱动模块自行创建的cdev，针对这一类的cdev，其kobj_type为ktype_cdev_default，通过该kobject方法，则无须字符设备驱动模块自行释放cdev变量对应的内存（调用cdev_default_release接口，去除cdev->list链表上所有的inode->i_devices，并解除inode与cdev的绑定操作）
2. ops主要用于指向该cdev对应的文件操作接口，用于应用层实现对该设备文件的读、写、控制操作。
3. dev说明该字符设备的设备号（主设备号+次设备号）。
4. list链表主要实现与vfs模块中的索引节点的关联操作

在字符设备驱动模型中，创建了两个全局变量cdev_map、chrdevs，其中chrdevs为包含255个指针的数组，每一个成员均用于指向static struct char_device_struct类型的内存空间，该变量主要用于系统中已申请的字符设备区间的登记与查重操作。而cdev_map主要用于将cdev类型变量链接在一起，该变量中的probes数组也是一个包含255个指针的数组，该数组中的每一个成员均用于指向struct probe类型的内存空间。

字符设备驱动模型中的数据关联

如下为cdev_map、chrdevs以及cdev类型变量、char_device_struct类型变量的关联图，下面我们简要说明一下：

1. chrdevs变量以及每一个成员变量之间的关联，主要用于字符设备区间的注册，这种关联涉及的接口有__register_chrdev_region
2. 每一个cdev变量以及该变量与kobject、kobj_type的关联，这主要是通过接口cdev_alloc/cdev_init实现的；
3. cdev_map与cdev、probe类型变量之间的关联，当调用接口cdev_add实现cdev的添加时，即完成cdev与cdev_map的关联操作；
4. char_device_struct类型变量与cdev类型变量之间的关联如下图橙色虚线箭头与绿色虚线箭头所示，这两者之间的关联主要是通过char_device_struct类型变量的成员cdev实现关联。但这种关联不是必须的，当调用接口__register_chrdev实现字符设备号申请以及cdev创建及添加时，才会实现这种关联。若调用接口register_chrdev_region+cdev_add实现字符设备号的申请以及cdev的添加时，则不会进行char_device_struct类型变量与cdev类型变量之间的关联。针对char_device_struct类型变量与cdev类型变量而言，真正使它们进行关联的是设备号，只要设备号固定，即可在cdev_map和chrdevs中查找到对应的char_device_struct类型变量与cdev类型变量。

字符设备号的申请

针对字符设备号的申请，主要是保证系统中申请的字符设备区间不会出现重叠，保证申请的字符设备区间唯一。而针对字符设备号的申请流程，也就是根据主设备号，在对应的数组成员链表上，完成针对具体次设备号以及次设备数相关的char_device_struct类型变量的链接。字符设备驱动模块提供的接口有register_chrdev_region、alloc_chrdev_region，其中alloc_chrdev_region用于动态申请主设备号，并根据传递的词设备号与数目完成字符设备区间的申请；而register_chrdev_region接口则根据传递的主设备号进行字符设备区间的申请。这两个函数内部均是调用__register_chrdev_region进行申请操作，该接口的处理流程图如下：

针对某一个主设备号，若该主设备号申请了几个次设备号区间，则对应的逻辑关联图如下所示。如下图蓝色虚线框中，我们在主设备号2中，申请了两个字符设备号区域，主要为次设备号0-20、25-32。__register_chrdev_region接口说白了也就是在次设备号范围0-0xFFFFF中申请字符设备区域罢了。

字符设备cdev的创建以及注册

当完成了字符设备区间的申请之后，则可以进行字符设备的创建与注册操作，cdev_alloc接口则主要创建cdev类型的变量，并完成该cdev对应的kobject的初始化以及kobj_type的设置操作。而cdev_add接口则主要通过调用kobj_map接口，借助kobj_map类型变量、probe类型的变量，为具体的主设备号的cdev创建probe类型的变量，并设置probe->data指向本次注册的cdev，至此完成cdev与对应probe类型变量的绑定，并同时将该probe类型的变量注册到cdev_map变量的probes[]数组中对应设备号的链表上。完成这种绑定之后，则可以通过调用接口kobj_lookup，根据传递的设备号，查找到对应的cdev类型的变量。

假设我们调用cdev_add注册一个主设备号为2，次设备号为25，支持15个次设备的cdev，则完成cdev_add的调用之后，则在全局变量cdev_map的probes数组成员的第3个下标对应的指针中，增加一个probe类型的指针关联，如下图的蓝色虚线框中的内容，执行完cdev_add后，则增加了蓝色虚线框的内容至cdev_map，且其data指针指向cdev类型的内存空间。

注意：针对字符设备的创建，若一个字符设备支持多个次设备，则只需要注册一个cdev即可，后续每一个次设备则通过调用kobj_lookup，根据设备号，从cdev_map中查找注册的cdev类型变量。然后在vfs调用open接口时，根据cdev->ops从而即可调用该字符设备对应的open接口（通过open系统调用，调用具体cdev->ops->open的流程图如下）。

而在具体的open接口中，根据各自模块维护的次设备变量，实现具体次设备的操作。如spi通用字符设备中的open接口中通过device_list链表，并根据设备号查找到对应spidev_data类型的变量，从而完成针对具体spi device的通信；而在i2c通用字符设备驱动中的open接口中，通过i2c_dev_list链表并借助次设备号，查找到i2c_dev类型的变量，从而借助对应的i2c_adapter，实现数据通信。

字符设备节点的创建与删除方式

针对字符设备节点的创建，主要是通过mknod实现inode的创建，也就实现了在/dev目录下完成设备文件的创建。针对字符设备节点的创建有如下几种方式：

1. 在应用层直接调用mknod命令实现字符设备文件inode的创建；
2. 借助linux设备-总线-驱动模型中的uevent，通过调用device_add接口，创建一个device类型的设备变量，并设置该设备变量对应的设备号，然后即会向应用程序发送设备添加的uevent（通过netlink传递该uevent信息），而应用层程序通过udev进行接收uevent事件（或者通过mdev接收udeve事件），当确认该设备存在设备号以及设备添加event后，即自动调用mknod系统调用，实现字符设备文件的创建。

目前字符设备文件的创建，基本上选择后者，我们创建一个字符设备文件的流程大致如下：

1. 调用alloc_chrdev_region/register_chrdev_region实现设备号的创建；
2. 调用cdev_init/cdev_alloc、cdev_add，实现cdev的创建以及注册至cdev_map；
3. 调用class_create创建一个类别；
4. 调用device_create/device_add实现device类型变量的注册，该步主要目的是向应用层发送uevent，借助udev/mdev，从而实现字符设备文件的创建。

字符设备节点的创建只能依赖设备文件系统吗？

这个倒是没有要求，只要一个文件系统类型的目录inode对应的inode_operations成员提供mknod系统调用，即可实现字符设备节点的创建操作。如内存文件系统、jffs2文件系统、squashfs、ext2、ext3、ext4、ubi文件系统等均支持mknod系统调用即可，因此针对系统中的/dev目录，不一定非得使用devtmpfs文件系统挂载，也可以挂载为内存文件系统，只要支持mknod系统调用即可。

以上即为字符设备驱动模型相关内容，本章主要着眼于字符设备驱动模型的实现，而关于字符设备驱动的使用，相对来说比较简单，基本上驱动工程师写的第一个驱动可能就是字符设备驱动，因此此处不介绍字符设备驱动的使用内容，仅介绍实现原理。