Linux设备树

1、设备树的引进与体验

字符设备驱动程序的三种写法

以LED驱动为例子。
方法1： 直接填充file_operrations，比如在write函数中写死将某个阴极点亮，这样一换设备，就得改代码换阴极。优点是简单，缺点是不易扩展
方法2： 基于总线设备驱动模型，分离设备和驱动。在probe函数里分配注册file_operrations，相当于将方法一的大部分操作挪到probe中，但是里面具体硬件得操作都是操作平台设备指定的资源，不会写死操作某个引脚。
优点：只需要device文件，不需要改变driver文件，易于扩展。
缺点：有一个设备就得创建一个device文件，这些device文件中有很多重复代码，并且这些是以.c文件出现的，每换一个设备，都需要重新编译。其实总线设备驱动模型主要的缺点就是这些硬件文件是C文件，每次都需要重新编译驱动。
感悟： 对于LED这种没有子系统的，总线设备驱动模型就挺好用的，总感觉总线设备驱动模型和子系统有些功能上的重复。
方法3： 使用设备树。设备树方法同样使用总线设备驱动模型的driver部分，只改变device部分。设备树使用.dts文件（device tree source）来指定硬件资源，内核运行时会解析dts文件，自动分配、设置、注册对应的device文件（基于某个总线，比如platform_device）。dts文件最终会被编译为dtb文件，启动单板时，既要启动内核，也要传入dtb文件。需要更改代码时，不需要重新编译驱动，只需要给内核提供一个不一样的dtb文件就行。
优点：更易扩展，无重复代码，不需要重新编译内核或者驱动，只需要提供不一样的设备树文件即可。
为什么叫设备树： 整个单板，从CPU开始，由各级的硬件组成，我们用设备树文件来抽象描述整个单板所有的硬件资源。

使用设备树时对应的驱动编程

driver那边基本不变，原本的device现在变成在dts文件中构建资源节点，dts文件代表了整个单板的硬件资源，每个单独的设备只是其中一个资源节点。
dts文件编译成dtb文件传入内核，内核解析dtb文件，得到代表每一个单独设备的device_node结构体，device_node结构体会具体变为各种总线的结构体，比如platform_device，到这里就和总线设备模型一样了。

dts文件是我们自己编写的，按照一定语法和规则，然后上传到虚拟机内核的某个目录下，编译dts文件（make dtbs，估计这里需要对Makefile做一些改变），得到dtb文件，将该dtb文件烧写到单板nand对应的device_tree分区（这里对nand的分区应该做了调整，内核必须知道从那里去获取dtb文件），重启开发板（重启不等于重新编译，重新编译很费事），这样内核启动过程中会自动解析dtb文件，形成设备树（关于内核具体去哪里解析dtb文件，不太清楚）。

从设备树得到的设备文件和驱动文件的匹配不再是简单的依靠名字，匹配的函数仍然是match函数，只是里面内容有改变（2.6内核不行了，得高版本的内核）。

最先的基于设备树的驱动运行： 编译driver的c文件为ko文件，写dts，编译，传给内核，启动内核（此时已经有设备文件，还没有驱动文件，系统不会创建dev设备节点），insmod驱动文件，此时ls /dev可以看到设备节点，此时可以运行驱动了。
更改设备树文件后驱动的运行： 改dts文件，编译，传给内核，启动内核，insmod，就可以了。

只想使用设备树不想深入研究怎么办

没啥用