Linux设备模型_导航篇

1. Linux设备模型系列文章说明

所有文章均转载自wowo科技，经过小编的重新排版、增添发布到知乎上了。

转载目的：

• 能够让更多的小伙伴发现优质的文章；
• 对原文进行重新排版梳理替换，让文章更优质；
• 本人目前还没能力总结出这样的文章，因此先转载一些自认为优质的文章，供大家享用。等我有所感悟之后，总结出更清晰明了的文章，供大家学习交流，共同进步。

所有封面图均来源于网络，并注明了来源，侵删！！！

2. Linux设备模型系列文章目录

2.0 Linux内核的整体架构

本文是“Linux内核分析”系列文章的第一篇，会以内核的核心功能为出发点，描述Linux内核的整体架构，以及架构之下主要的软件子系统。之后，会介绍Linux内核源文件的目录结构，并和各个软件子系统对应。

https://makelinux.github.io/kernel/map/

2.1 Linux设备模型(1)_基本概念

在“Linux内核的整体架构”中，蜗蜗有提到，由于Linux支持世界上几乎所有的、不同功能的硬件设备（这是Linux的优点），导致Linux内核中有一半的代码是设备驱动，而且随着硬件的快速升级换代，设备驱动的代码量也在快速增长。个人意见，这种现象打破了“简洁就是美”的理念，是丑陋的。它导致Linux内核看上去非常臃肿、杂乱、不易维护。但蜗蜗也知道，这不是Linux的错，Linux是一个宏内核，它必须面对设备的多样性，并实现对应的驱动。

为了降低设备多样性带来的Linux驱动开发的复杂度，以及设备热拔插处理、电源管理等，Linux内核提出了设备模型（也称作Driver Model）的概念。设备模型将硬件设备归纳、分类，然后抽象出一套标准的数据结构和接口。驱动的开发，就简化为对内核所规定的数据结构的填充和实现。

本文将会从设备模型的基本概念开始，通过分析内核相应的代码，一步一步解析Linux设备模型的实现及使用方法。

http://www.wowotech.net/device_model/13.html

2.2 Linux设备模型(2)_Kobject

由“Linux设备模型(1)_基本概念”可知，Linux设备模型的核心是使用Bus、Class、Device、Driver四个核心数据结构，将大量的、不同功能的硬件设备（以及驱动该硬件设备的方法），以树状结构的形式，进行归纳、抽象，从而方便Kernel的统一管理。

而硬件设备的数量、种类是非常多的，这就决定了Kernel中将会有大量的有关设备模型的数据结构。这些数据结构一定有一些共同的功能，需要抽象出来统一实现，否则就会不可避免的产生冗余代码。这就是Kobject诞生的背景。

https://www.cnblogs.com/tanghuimin0713/p/3826904.html

2.3 Linux设备模型(3)_Uevent

Uevent是Kobject的一部分，用于在Kobject状态发生改变时，例如增加、移除等，通知用户空间程序。用户空间程序收到这样的事件后，会做相应的处理。

该机制通常是用来支持热拔插设备的，例如U盘插入后，USB相关的驱动软件会动态创建用于表示该U盘的device结构（相应的也包括其中的kobject），并告知用户空间程序，为该U盘动态的创建/dev/目录下的设备节点，更进一步，可以通知其它的应用程序，将该U盘设备mount到系统中，从而动态的支持该设备。

http://www.wowotech.net/device_model/uevent.html

2.4 Linux设备模型(4)_sysfs

sysfs是一个基于RAM的文件系统，它和Kobject一起，可以将Kernel的数据结构导出到用户空间，以文件目录结构的形式，提供对这些数据结构（以及数据结构的属性）的访问支持。

sysfs具备文件系统的所有属性，而本文主要侧重其设备模型的特性,因此不会涉及过多的文件系统实现细节，而只介绍sysfs在Linux设备模型中的作用和使用方法。具体包括：

• sysfs和Kobject的关系
• attribute的概念
• sysfs的文件系统操作接口

转载者注：
本文代码在4.x版本中大部分不存在！！！这部分内容变动比较大，但核心思想估计没变，大家小心食用。

https://blog.csdn.net/qq_28992301/article/details/52381868

2.5 Linux设备模型(5)_device和device driver

device和device driver是Linux驱动开发的基本概念。Linux kernel的思路很简单：驱动开发，就是要开发指定的软件（driver）以驱动指定的设备，所以kernel就为设备和驱动它的driver定义了两个数据结构，分别是device和device_driver。因此本文将会围绕这两个数据结构，介绍Linux设备模型的核心逻辑，包括：

• 设备及设备驱动在kernel中的抽象、使用和维护；
• 设备及设备驱动的注册、加载、初始化原理；
• 设备模型在实际驱动开发过程中的使用方法。

注：在介绍device和device_driver的过程中，会遇到很多额外的知识点，如Class、Bus、DMA、电源管理等等，这些知识点都很复杂，任何一个都可以作为一个单独的专题区阐述，因此本文不会深入解析它们，而会在后续的文章中专门描述。

https://lwn.net/Kernel/LDD3/

2.6 Linux设备模型(6)_Bus

在Linux设备模型中，Bus（总线）是一类特殊的设备，它是连接处理器和其它设备之间的通道（channel）。为了方便设备模型的实现，内核规定，系统中的每个设备都要连接在一个Bus上，这个Bus可以是一个内部Bus、虚拟Bus或者Platform Bus。

内核通过struct bus_type结构，抽象Bus，它是在include/linux/device.h中定义的。本文会围绕该结构，描述Linux内核中Bus的功能，以及相关的实现逻辑。最后，会简单的介绍一些标准的Bus（如Platform），介绍它们的用途、它们的使用场景。

https://lwn.net/Kernel/LDD3/

2.7 Linux设备模型(7)_Class

在设备模型中，Bus、Device、Device driver等等，都比较好理解，因为它们对应了实实在在的东西，所有的逻辑都是围绕着这些实体展开的。而本文所要描述的Class就有些不同了，因为它是虚拟出来的，只是为了抽象设备的共性。

举个例子，一些年龄相仿、需要获取的知识相似的人，聚在一起学习，就构成了一个班级（Class）。这个班级可以有自己的名称（如295），但如果离开构成它的学生（device），它就没有任何存在意义。另外，班级存在的最大意义是什么呢？是由老师讲授的每一个课程！因为老师只需要讲一遍，一个班的学生都可以听到。不然的话（例如每个学生都在家学习），就要为每人请一个老师，讲授一遍。而讲的内容，大多是一样的，这就是极大的浪费。

设备模型中的Class所提供的功能也一样了，例如一些相似的device（学生），需要向用户空间提供相似的接口（课程），如果每个设备的驱动都实现一遍的话，就会导致内核有大量的冗余代码，这就是极大的浪费。所以，Class说了，我帮你们实现吧，你们会用就行了。

这就是设备模型中Class的功能，再结合内核的注释：

A class is a higher-level view of a device that abstracts out low-level implementation details(include/linux/device.h line326)，就容易理解了。

https://book.douban.com/subject/26600201/

2.8 Linux设备模型(8)_platform设备

在Linux设备模型的抽象中，存在着一类称作“Platform Device”的设备，内核是这样描述它们的（Documentation/driver-model/platform.txt）：

Platform devices are devices that typically appear as autonomous
entities in the system. This includes legacy port-based devices and
host bridges to peripheral buses, and most controllers integrated into
system-on-chip platforms. What they usually have in common is direct
addressing from a CPU bus. Rarely, a platform_device will be connected
through a segment of some other kind of bus; but its registers will
still be directly addressable.

概括来说，Platform设备包括：

• 基于端口的设备（已不推荐使用，保留下来只为兼容旧设备，legacy）；
• 连接物理总线的桥设备；
• 集成在SOC平台上面的控制器；
• 连接在其它bus上的设备（很少见）;
• 等等。

这些设备有一个基本的特征：可以通过CPU bus直接寻址（例如在嵌入式系统常见的“寄存器”）。因此，由于这个共性，内核在设备模型的基础上（device和device_driver），对这些设备进行了更进一步的封装，抽象出paltform bus、platform device和platform driver，以便驱动开发人员可以方便的开发这类设备的驱动。

可以说，paltform设备对Linux驱动工程师是非常重要的，因为我们编写的大多数设备驱动，都是为了驱动plaftom设备。本文我们就来看看Platform设备在内核中的实现。

http://www.wowotech.net/device_model/platform_device.html

2.9 Linux设备模型(9)_device resource management

相信每一个写过Linux driver的工程师，都在probe函数中遇到过上面的困惑：要顺序申请多种资源（IRQ、Clock、memory、regions、ioremap、dma、等等），只要任意一种资源申请失败，就要回滚释放之前申请的所有资源。于是函数的最后，一定会出现很多的goto标签（如上面的exit_free_irq、exit_free_dma、等等），并在申请资源出错时，小心翼翼的goto到正确的标签上，以便释放已申请资源。

http://www.wowotech.net/device_model/device_resource_management.html

3. 总结

刚入坑的小白，建议多读几遍，我看了将近5遍了，但仍然没有全部理解Linux设备模型的精华，任重而道远呀！！！

转载不易，切勿剽窃！

欢迎大家关注我创建的微信公众号——小白仓库
原创经验资料分享：包含但不仅限于FPGA、ARM、RISC-V、Linux、LabVIEW等软硬件开发，另外分享生活中的趣事以及感悟。目的是建立一个平台记录学习过的知识，并分享出来自认为有用的与感兴趣的道友相互交流进步。