经过几篇文章的分析，我们基本上完成了字符设备驱动模型的介绍，以及基于字符设备驱动模型而建立的复杂设备模型的介绍（混杂设备模型、RTC设备模型中的字符设备模型使用篇），本章我们主要针对字符设备驱动模型做一个总结说明，也算是对上面几篇文章中没有提到的知识点的补充。

字符设备驱动模型与文件系统以及VFS之间的关联说明

在之前几个模块的分析中我们知道（主要是VFS模块分析），应用层若要通过系统调用实现对一个文件的操作，在内核层主要涉及VFS模块、进程模块、文件系统模块、驱动模块的关联，如下图所示。

在之前的学习中，我们知道针对一个文件或目录，需要inode与dentry两个结构体变量来描述，而在inode中定义了针对文件或目录的操作接口指针变量（包括open、read、write、readdir、ioctl等等），而这这些接口的实现一般由对应的文件系统模块来提供。而字符设备文件也属于文件，那是否存在针对字符设备文件或者块设备文件的专用文件系统呢？

其实内核没有提供针对字符设备文件或块设备文件的专用文件系统，而是针对字符设备文件或块设备文件的操作抽象出统一的操作接口def_chr_fops、def_blk_fops，内核提供了接口init_special_inode用于支持字符设备文件、块设备文件、pipe文件类型的创建，因此各类型的文件系统类型只要在进行文件创建时调用init_special_inode即可完成对字符设备文件、块设备文件等类型文件创建的支持，基于此LINUX内核中大多数文件系统均支持对字符设备等特殊文件的创建操作，如jffs、ubifs、ext2、ext3、ext4、squashfs、ubifs、ramfs、devtmpfs等

针对字符设备文件而言，def_chr_fops->open为所有设备文件统一的打开接口，可以理解

为字符设备文件的virtule_open，而在该open接口中，通过设备号在cdev_map中查找到对应的cdev类型变量，然后将file->f_op替换为cdev->ops，从而实现对具体字符设备的操作。

字符设备驱动模型的设备号区间分配以及cdev的注册关系

在字符设备驱动模型中针对设备号区间使用申请和cdev注册，提供了两个结构体变量及全局变量，分别为struct char_device_struct、struct cdev、chrdevs、cdev_map，而struct char_device_struct中其实定义了struct cdev类型的成员，以此可实现struct char_device_struct与struct cdev的关联。

但是字符设备驱动模型在字符设备的注册时，并没有强制要求struct char_device_struct、struct

cdev类型变量的绑定，而完成字符设备的注册后，而针对字符设备的查找只需要在cdev_map中进行即可。这可能存在问题：即驱动开发者可以只进行cdev的添加，而不需进行字符设备区间的申请（事实上也可以这样操作，这样的话，字符设备区间的申请就没有意义了。。）

事实上RTC设备驱动模型中的字符设备驱动部分的实现就存在这个问题，其申请了支持次设备

数为16的字符设备区间，但是针对每一个次设备的创建时，并不会检测RTC模块申请的次设备号区间是否已用完，则可能会导致字符设备区间申请与次设备注册不匹配。

但其实字符设备驱动模型也提供了设备区间申请以及cdev注册且实现它们两个绑定的接口，即

__register_chrdev。若我们在字符设备驱动添加时都使用该接口，则可以完整的遵循字符设备驱动创建的流程，即先申请字符设备区间，再进行字符设备cdev的注册。因此建议我们创建字符设备驱动时可以使用该接口。

基于字符设备驱动模型实现复杂设备驱动模型

在linux系统中i2c通用设备驱动、spi通用设备驱动模型、混杂设备驱动模型以及RTC设备驱动

模型均是基于字符设备驱动模型而实现的复杂设备驱动模型，这其中i2c通用设备驱动、spi通用设备驱动模型、混杂设备驱动模型的实现，比较类似于字符设备模型def_chr_fops->open的抽象，这三个模块也抽象了一个open接口，可以理解为xxx_module_virtual_open，而在这几个模块的open接口中，再根据次设备号查找对应次设备号所依附的操作接口，从而完成针对具体设备的访问。针对这几个设备模型，我们可以抽象出复杂字符设备驱动模型的创建流程（此处指支持多个次设备的注册，且这些次设备的功能或类型类似）：

1. 申请一段字符设备区间；
2. 针对该段字符设备区间创建cdev类型变量，并注册至cdev_map中，同时完成cdev与字符设备驱动的绑定；
3. 针对该cdev的操作接口成员ops，实现一个open接口，该open接口是该模块所有次设备访问的抽象，通过该open接口以及对应的次设备号，查找对应次设备注册的访问接口，从而实现对具体次设备的访问操作。
4. 在该模块下实现全局的变量，用于记录该模块已注册的次设备以及针对该次设备的访问接口实现；
5. 实现次设备注册的接口，该接口的实现操作包括实现该次设备的操作接口，并将该次设备注册到该模块中去，同时借助设备模型的device_register/device_create，实现该次设备对应的设备文件节点的创建操作。
6. 实现次设备注销接口。

以上便是基于字符设备驱动模型而实现某一类赋值设备驱动模型的步骤（我们前面的分析的RTC设备驱动模型中字符设备注册部分的实现，可能存在字符设备申请区域与次设备号注册可能存在不匹配的问题，但一般一个硬件系统中的rtc个数也并不会超过16个，因此该问题也基本上不会出现）。

本篇主要是针对字符设备驱动模型做一个总结，并提供了针对某一类复杂设备驱动模型的实现流程，至此我们完成了字符设备驱动模块的分析，其实字符设备驱动模块说简单也简单，说复杂也复杂（比如字符设备驱动模块与VFS模块的关联、与设备驱动模型的关联等等）若仅仅针对字符设备驱动模型的实现而言不算复杂。