目录
前言：
一、驱动设计
（1）面向对象：
（2）分层：
（3）分离：
二、驱动框架
（1）传统框架
（2）总线设备驱动框架：
（3）设备树
前言：
经典环节：我一直深信，带着问题思考和实践，能够更容易理解并学习到。
（1）驱动设计的核心思想
- 面向对象
- 分层
- 分离
（2）驱动框架有哪些？
- 传统框架
- 总线设备驱动框架
- 设备树
写作不易，如果有所帮助，多多支持，大家一同进步呀！前人的思想真的巧妙！！！
参考学习：
1.韦老师课程
2.Linux笔记 https://xuesong.blog.csdn.net/article/details/109522945?spm=1001.2014.3001.5502
一、驱动设计
9.驱动设计的思想_面向对象_分层_分离_哔哩哔哩_bilibili
现如今大部分的驱动开发工作，是基于前人的工作上进行修改和完善，所以他所运用的驱动设计思想（前人的想法是真的巧妙），我们需要去学习和理解，之后就可以知道在什么地方完成相应的改进和完善。
驱动的学习，是要认知到驱动的作用，在Linux系统上的驱动程序相较于裸机单片机上的驱动程序有什么区别，为什么要需要驱动框架之类的东西？可以参照阅读以下的博文：
https://blog.csdn.net/weixin_42373086/article/details/129764065?spm=1001.2014.3001.5501
经过前面的应用开发的学习，我们可以非常清晰的认知到，Linux系统需要处理非常多的设备，那么如何管理控制以及处理数据，就是一个比较大的问题。并且尤其是进一步的开发过程中，设备改动以及程序版本更迭，如何快速的开发以及兼容，就又是一个大的问题。
每一个设备都有相关的特点和属性，它就是一个个对象，之后就是将这个对象进行分层（类比，皮肤肌肉），最后就是对其更深层次的分解分离（同一类的共性和特性）。
驱动设计的思想，就如上述的，面向对象、分层以及分离。
（1）面向对象：
字符设备驱动程序就是要抽象出一个file_operations结构体，面向对象（设备），提供具体实现的函数（open/read/write）。
（2）分层：
上下分层，举个例子，字符设备驱动程序
- 上层实现硬件无关的操作，比如注册字符设备驱动
- 下层实现硬件相关的操作，
（3）分离：
以LED驱动程序为例，如果更换一个引脚来控制LED。这里涉及到引脚初始化和设置，某一款芯片每一个GPIO操作都是类似的，这里就可以写出比较通用的硬件操作代码（chipY_gpio.c）。
对上图进行总结，board_A.c和board_B.c定义资源，chipY_gpio.c为硬件通用的代码，实现分离。
二、驱动框架
10.驱动进化之路_总线设备驱动模型_哔哩哔哩_bilibili
（1）传统框架
这里使用到哪个引脚，怎么操作引脚，都写在代码中。
这里的框架，就不考虑拓展性，可以快速实现功能，但是涉及到引脚的修改时，就需要重新编译。
（2）总线设备驱动框架：
如果有一个设备（led）就要建立一个结构体（led_resource）来管理的话，会非常的麻烦
应用分离思想，进行进一步的拓展，引入platform_device/platform_driver，将资源（devise）与“驱动”（driver）分离开来。
按照上述分离之后，我们会发现还是会出现以下多个设备类型的定义，是否可以统一管理呢？这里就引入了总线（bus）的概念，对分离思想更好的实现。
对上述模型进行简化之后就如下图：https://live.csdn.net/v/269203?spm=1001.2014.3001.5501
Linux的设备驱动管理将运用对象思想对各式各样的设备、总线以及驱动进行管理。
总线（bus）：负责管理挂载对应总线的设备以及驱动；
设备（device）：挂载在某个总线的物理设备。
驱动（driver）：与特定设备相关的软件，负责初始化该设备以及提供一些操作该设备的操作方式。
类（class）：对于具有相同功能的设备，归结到一种类别，进行分类管理。
Bus如何管理device和driver呢？
subsys_private，它是总线的驱动核心的私有数据。我们可以看到subsys_private数据结构下有两个链表，一个用于挂载device，一个用于挂载driver，从而实现对device和driver的管理。
（3）设备树
实际开发中，会有不同单板的.c资源文件，如果都放入Linux内核中，会导致内核臃肿不堪。
这里引入了dts配置文件来管理。dts文件会编译出dtb文件，之后传给内核，内核会解析dtb，产生一系列的platform_device/platform_driver文件。
这里我们可以看到dtb文件和dts文件都是在内核外的，这样可以使得内核精简优雅。
