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

wowo · 2014年2月27日 · 统一设备模型 · 阅读 102703 · 2014年2月存档

1. 前言

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

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

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

2. Linux设备模型的基本概念

2.1 Bus, Class, Device和Device Driver的概念

下图是嵌入式系统常见的硬件拓扑的一个示例：

硬件拓扑描述Linux设备模型中四个重要概念中三个：Bus，Class和Device（第四个为Device Driver，后面会说）。

Bus（总线）：Linux认为（可以参考include/linux/device.h中struct bus_type的注释），总线是CPU和一个或多个设备之间信息交互的通道。而为了方便设备模型的抽象，所有的设备都应连接到总线上（无论是CPU内部总线、虚拟的总线还是“platform Bus”）。

Class（分类）：在Linux设备模型中，Class的概念非常类似面向对象程序设计中的Class（类），它主要是集合具有相似功能或属性的设备，这样就可以抽象出一套可以在多个设备之间共用的数据结构和接口函数。因而从属于相同Class的设备的驱动程序，就不再需要重复定义这些公共资源，直接从Class中继承即可。

Device（设备）：抽象系统中所有的硬件设备，描述它的名字、属性、从属的Bus、从属的Class等信息。

Device Driver（驱动）：Linux设备模型用Driver抽象硬件设备的驱动程序，它包含设备初始化、电源管理相关的接口实现。而Linux内核中的驱动开发，基本都围绕该抽象进行（实现所规定的接口函数）。

注：什么是Platform Bus？
在计算机中有这样一类设备，它们通过各自的设备控制器，直接和CPU连接，CPU可以通过常规的寻址操作访问它们（或者说访问它们的控制器）。这种连接方式，并不属于传统意义上的总线连接。但设备模型应该具备普适性，因此Linux就虚构了一条Platform Bus，供这些设备挂靠。

2.2 设备模型的核心思想

Linux设备模型的核心思想是（通过xxx手段，实现xxx目的）：

用Device（struct device）和Device Driver（struct device_driver）两个数据结构，分别从“有什么用”和“怎么用”两个角度描述硬件设备。这样就统一了编写设备驱动的格式，使驱动开发从论述题变为填空体，从而简化了设备驱动的开发。
同样使用Device和Device Driver两个数据结构，实现硬件设备的即插即用（热拔插）。
在Linux内核中，只要任何Device和Device Driver具有相同的名字，内核就会执行Device Driver结构中的初始化函数（probe），该函数会初始化设备，使其为可用状态。
而对大多数热拔插设备而言，它们的Device Driver一直存在内核中。当设备没有插入时，其Device结构不存在，因而其Driver也就不执行初始化操作。当设备插入时，内核会创建一个Device结构（名称和Driver相同），此时就会触发Driver的执行。这就是即插即用的概念。
通过"Bus–>Device”类型的树状结构（见2.1章节的图例）解决设备之间的依赖，而这种依赖在开关机、电源管理等过程中尤为重要。
试想，一个设备挂载在一条总线上，要启动这个设备，必须先启动它所挂载的总线。很显然，如果系统中设备非常多、依赖关系非常复杂的时候，无论是内核还是驱动的开发人员，都无力维护这种关系。
而设备模型中的这种树状结构，可以自动处理这种依赖关系。启动某一个设备前，内核会检查该设备是否依赖其它设备或者总线，如果依赖，则检查所依赖的对象是否已经启动，如果没有，则会先启动它们，直到启动该设备的条件具备为止。而驱动开发人员需要做的，就是在编写设备驱动时，告知内核该设备的依赖关系即可。
使用Class结构，在设备模型中引入面向对象的概念，这样可以最大限度地抽象共性，减少驱动开发过程中的重复劳动，降低工作量。

原创文章，转发请注明出处。蜗窝科技，www.wowotech.net。

标签：Kernel内核设备模型DeviceModel驱动开发

继续讨论

新讨论请用 GitHub 账号在下方发言——评论会保存在本仓库的 Discussions 里，与站点同寿；再下方的「历史评论」是原站的只读存档。

评论（67 条，只读存档）

以下为原站的历史评论（只读存档）；继续讨论请用上方的评论区。

常山黄豆 2014-10-09
学习，good！
- wowo 2014-10-09
  @常山黄豆：多谢鼓励，欢迎常来。
醉中幻想 2014-10-15
写得好形象易懂啊，受教了！
artake 2015-06-01
群主写得实在是太好了，膜拜，I love you
- wowo 2015-06-01
  @artake：谢谢夸奖，不过膜拜、love就不需要了，哈哈~~
lanbo 2015-07-29
只要任何Device和Device Driver具有相同的名字 ==>device是属于某一bus,所以是调用bus的mach接口，当然如果没有id_table才会对比name,但也只是该bus上的driver与device做mach并不是任何Device和Device Driver
- wowo 2015-07-29
  @lanbo：是的，文中的表述比较武断，多谢提醒，稍后会修改~~~
  - lanbo 2015-07-30
    @wowo：有朋友看到你们网站，所以来看看，确认写的是易懂的。坚持！
  - Ethan 2022-08-05
    @wowo：这句话从我中学到现在还没改，建议把这些用的评论置顶，这样有疑惑的朋友能第一时间看到大佬们的讨论
linuxer2010 2015-08-01
能写些iic,i2s,spi,usb等等这些协议的驱动框架吗，想学习学习。。。
- wowo 2015-08-02
  @linuxer2010：这些框架是可以写，不过暂时没有多少时间。
- lucifer 2016-08-06
  @linuxer2010：我也想学
  - wowo 2016-08-06
    @lucifer：多谢关注，我们会尽快写这些框架的分析文章～～～
Eros_Y 2015-08-12
刚开始学习，受益良多，会继续跟进！
xiao 2015-09-15
设备模型怎么英文就是 driver Model，网上看到还有的地方是 “设备驱动模型”。虽然对Linux的理解不是很深刻，但是觉得设备模型理解得更加合理。驱动仅仅时围绕这这个模型进行操作。
- wowo 2015-09-15
  @xiao：这个可能没有特别的深意，是device，还是driver，应该是一样的意义。你看kernel的document（Documentation/driver-model/overview.txt），也是混着用的。
linux_emb 2015-12-14
用Device（struct device）和Device Driver（struct device_driver）两个数据结构，分别从“有什么用”和“怎么用”两个角度描述硬件设备。这样就统一了编写设备驱动的格式，使驱动开发从论述题变为填空体，从而简化了设备驱动的开发。这是我最喜欢的说明方式，把复杂的问题归结到最基本的有什么用和怎么用，简单有效。把论述题变为填空题生动形象。不仅有知识的理解，更有强大的表达能力，小弟佩服。。。。。
huad_ 2016-01-15
首先，感谢楼主的好文，通俗易懂。请问，“3. 通过"Bus-->Device”类型的树状结构（见2.1章节的图例）解决设备之间的依赖” 这个图在哪里呢？我没找着
- wowo 2016-01-15
  @huad_：文章里面只有那一个图啊，看来那个图画的不好啊，才让老兄你视而不见，呵呵~~~
  - huad_ 2016-01-15
    @wowo：@wowo: 不好意思，看到你这是一系列文章，我以为是链接了别的文章的图，找别的文章去了，让你见笑了~ 图画的很好，结构清晰，一目了然。谢谢~
    - wowo 2016-01-15
      @huad_：不客气~话说文章的图片应该加一个编号的，只怪太懒了。
crystal 2016-01-29
"在Linux内核中，只要任何Device和Device Driver具有相同的名字，内核就会执行Device Driver结构中的初始化函数（probe），该函数会初始化设备，使其为可用状态。"这一句陈述是否略欠考虑，对于usb设备来说，不是有相同名字就行的，而是要usb_bus_type的match函数返回1才行吧？
- wowo 2016-01-29
  @crystal：是的，这句话欠妥，但不是“欠考虑”，因为device的probe机制是相当复杂的，可以匹配的case是多种多样的，因而不是几句话就可以罗列完的。所以我就一笔带过了。很多时候我写文章的方法有些极端，关注简单易懂多于严谨。这样做的出发点是：对于刚接触这方面知识的工程师来说，概念比细节重要。如果描述的过多过细，反而会带来压力；而对于已经熟悉这方法知识的工程师来说，他们可以深入到细节里面，轻易发现表述的逻辑问题，然后提出来，大家讨论一下，也皆大欢喜。回到这句话，其实去kenrel里面看一下代码（每个bus的match回调），就会知道probe的所有依据。蜗窝的目的是引导大家去看，而不应是告诉每一个细节。不过还是非常感谢您能够指正，您的提问，对读者的帮助才是最大的，因为可以引发思考。多谢！！欢迎常来~~
  - crystal 2016-01-29
    @wowo：明白楼主的良苦用心，只是觉得在表述上更加精益求精才好，这对于您以后出书都是很有帮助的，不过还是非常敬佩楼主的分享精神。赞赞赞
    - wowo 2016-01-29
      @crystal：是的，从其它角度看，确实应该精益求精，虚心接受您的建议，多谢:-)
    - hony 2017-01-09
      @crystal：可以引发大家的思考——出书会失去一些语言精髓。
      - wowo 2017-01-10
        @hony：其实书籍有一个毛病：缺乏互动。这一点没有博客方便。但电子化也有毛病，没有翻一页页纸的感觉爽，哎……
雕兄 2016-04-06
楼主，有没有想过把这些子系统模块录制为视频的形式？
- wowo 2016-04-06
  @雕兄：我一直有疑问：视频比文字更能帮助理解吗？大家可以讨论一下。
  - 雕兄 2016-04-06
    @wowo：1，可以知道你分析内核的思路 2，可以顺便看着代码说 3，初学者可以快速进入linux内核
  - freeman 主页 2016-08-24
    @wowo：我觉得视频不能让人高效地学习。视频是一种流媒体，就好像字符设备，基于时序的。这样人们想随机访问视频片段就得来回跳。跳得准跳不准是一回事，就我个人来讲，这样来回跳心也就散了，甚至会机械性地快进，无法保持耐心和专注。文字相比就好很多，可以方便地定位、仔细品味。另外就我个人来讲，看视频时往往会把自己放在被动地位——视频容量极大可以把知识嚼碎了喂给观众，这样观众容易处于温水煮青蛙的状态。而文字就不一样，不主动去跟随作者的思路、不主动去思考，那结果就是神马也不知道。最后一点，大部分知识都没有被录成视频。从文字中挖掘知识还是我们大部分时间需要做的事。
    - wowo 2016-08-25
      @freeman：你的观点和我一样:-)
    - hony 主页 2017-01-09
      @freeman：赞，有道。
paoshapaoxue 2016-07-30
@wowo:文章写的好，可否在系列的文章里面，加一个下一节的链接，比如在文章linux设备模型1后的末尾加一个linux设备模型2的链接呢？
- wowo 2016-07-30
  @paoshapaoxue：多谢建议:-) 不过呢，通常是先写1，后写2。所以就懒懒在写完2之后，再去修改1，将2的链接加进去了。不过你可以通过右侧的“文章分类”阅读一个系列的文章。
MOLLY 2016-09-01
我是初学者，你写的我都看懂了，文章浅显易懂，文字精准，属于搞IT里文章写的最好的
- wowo 2016-09-02
  @MOLLY：多谢夸奖:-)
windays 2017-08-06
好文章啊，清晰易懂。虽然应用起来还需要代码支持，但是对于框架整体的把握帮助很大。
kernel_journey 2018-08-09
深表同意
大道无门 主页 2018-08-21
想知道小哥在哪就职？是哪位大神对linux内核讲的很透彻。然后，请小哥多写写关于外围设备驱动的博文，这样会更牛 x。但是这难度极大，光usb就足够吃力了吧，hah
东风笑 2018-09-03
@wowo 博主你好，请教一下为啥2.1的图，有两个线连接到camera上？
- 小亮 2018-09-03
  @东风笑：博主表示的是I2C控制接口的Camera吧？如果是基于mipi-csi是不是就只有一条呢？
  - pcszx 2018-09-03
    @小亮：看camera模组吧，mipi-csi通路用来传输数据，CCI（也就是i2c）来控制。
画像 2019-01-03
博主真的写的很好, 赞一个! 对于文中"用Device（struct device）和Device Driver（struct device_driver）两个数据结构，分别从“有什么用”和“怎么用”两个角度描述硬件设备" 对于这句话我感觉和机制与策略比较类似, device的数据结构提供了有什么功能, device driver的数据结构则说明了怎么用这些功能, 这不就是机制和策略吗, 新手一个, 不知道这样理解是否正确.
- wowo 2019-01-04
  @画像：是的，这样理解也没问题。每个人都可以有自己的理解，只要把事情搞懂就行了:-)
sdssgl 2019-01-19
2.2 设备模型的核心思想而对大多数热拔插设备而言，它们的Device Driver一直存在内核中。当设备没有插入时，其Device结构不存在，因而其Driver也就不执行初始化操作。当设备插入时，内核会创建一个Device结构（名称和Driver相同），此时就会触发Driver的执行。这就是即插即用的概念 /*************************************************************************************** * 对于此处个人的理解： ***************************************************************************************/ 此处的设备插入，并非真实物理设备的插入，而是通过dts或板级文件添加注册设备，即插入；当没有对应的dts文件或者板级文件的设备注册时，Device结构不存在，故Driver不会执行初始化操作
- wowo 2019-01-21
  @sdssgl：DTS仅仅是“插入”的一个子集。
wyz 2019-03-06
版主，网站打开很慢……可以改进下吗。文章写的鞭辟入里，我以赞助10元
- wowo 2019-03-07
  @wyz：多谢支持~~慢可能是因为服务器在香港吧，估计没法改进啊。
liaocj 2019-03-12
每看一次就会有不同的收获
wgy504 2019-08-30
原文中“就是在编写设备驱动时，告知内核该设备的依赖关系即可。” 能否举一个例子啊？
HYH 2019-09-27
以spi为例，spi的控制器（master端）注册为platform设备，而diver就是驱动挂在使用spi传输的外设和spi控制器之间正常通信工作，该driver也就是platform driver？这样理解对吗？求大神指点
- ysh 2019-09-27
  @HYH：很难理解spi dev、drv和platform dev、drv之间的关系
  - Dongwei 2019-11-13
    @ysh：spi总线实际存在，platform总线实际并不存在，是抽象出来的。所以spi总线在注册时，实际还是device与driver，只是用platform的形式将两者分别封装起来。
  - Dongwei 2019-11-13
    @ysh：spi总线实际存在，platform总线实际并不存在，是抽象出来的。所以spi总线在注册时，实际还是device与driver，只是用platform的形式将两者分别封装起来。
alilili 2020-07-02
2020前来考古
- lin 2022-11-07
  @alilili：22年前来学习
  - ty 2023-06-15
    @lin：23年前来学习
三变 2021-08-10
写的很好，5年前我的师傅看着你的文章学习到了今天我靠着你的博文入门好的技术好的博文永不过时
- 董先生 主页 2021-10-07
  @三变：好有道理，好的博文永不过时！！！
lxq 2021-12-02
赞赞赞赞！！！
抚泪 2021-12-31
看了2个多星期，终于对设备模型有个基本的概念了，感谢wowo。
LLEo 2022-03-07
感谢wowo 大佬
Jam 2024-09-01
2024.9.1来考古
Simbr 2025-04-14
bus至少是不是还有个subsystem？
鲁班七号 2025-05-15
2025年转行linux 考古来了。文章一看就懂了不少。点赞博主。
Hichens 2025-07-19
常看常新