从需求的角度去理解Linux系列：总线、设备和驱动

笔者成为博客专家后整理以前原创的嵌入式Linux系列博文，现推出以让更多的读者受益。

《从需求的角度去理解linux系列：总线、设备和驱动》是一篇有关如何学习嵌入式Linux系统的方法论文章，也是从需求的角度去理解Linux系统软件的开篇，期待此系列文章日后会是学习嵌入式Linux的标杆！

这是作者精心撰写的经验总结，希望嵌入式Linux的学习者仔细领会，多读几遍也无妨。

一、软件、面向对象、软件框架

软件是为了解决现实问题而产生的，面向对象的软件思维是解决普遍现实问题的一种有效的抽象方法，而软件框架指的是用面向对象的思维去解决某种特定领域的问题而专门设计的一套行之有效的解决方案。

一般地，Java/C++编程反映面向对象的软件思维，而像Android Framework、Windows MFC和Linux的QT则代表应用层的软件框架。前述应用框架要解决的问题包括应用消息处理、UI控件显示和处理、资源管理等等。软件框架带来的好处就是对于解决某个领域问题，框架会帮你完成80%的开发工作量，而你只需要完成20%的开发工作量。

Linux平台上的各个子系统，如设备驱动模型、input子系统、I2C总线、frame buffer驱动等等都属于软件框架，它是针对特定的硬件体系需求以面向对象的思维去设计的一种软件解决方案，而且已经经过长时间的多平台验证。严格意义上，将子系统归入软件抽象组件会更加贴切，而软件框架表现为一组抽象组件及其组件实例之间的交互。软件框架和软件组件的特点都是解决特点领域问题，可以高度重用设计。

Linux系统以C语言开发为主，C语言在教科书上会被认为是过程语言。事实上，面向对象只是一种软件思维，并不局限于某种语言，只不过C++/JAVA在娘胎(编译器)里就已经得到支持，而C语言通过struct数据结构和函数指针一样可以出色地完成面向对象抽象的工作。Linux系统绝对是利用C语言进行面向对象编程的开山鼻祖，处处洋溢着软件艺术的光辉！

二、理解好软件需求是学习好软件框架的前提

对于学习着来说，软件需求（即软件要解决的问题）和软件框架都已经存在。但学习者往往只关注软件框架，因为学习的终极目标也是为了掌握软件框架并使用它来解决自己的问题。对于一般的知识传播者来说（例如学校老师、机构培训师；教科书或者网络文献），往往也是着重于解读软件框架的组成和原理。

事实上，对于一个代码量有几万甚至几十万行代码量的软件框架，一开始接触就学习原理和代码并不是好事。这种做法很像是试图从软件框架的学习理解中得出软件需求，有太多的未知就接触源码，那理解过程会非常痛苦，往往会感到非常迷惑。

我认为，深入地理解好需求，再去理解软件框架会事半功倍。

甚至，当达到一定的水平后，知道了需求，完全可以去猜测软件框架的实现。

三、Linux系统的软件需求

对于软件需求，最容易让人联想到的是一种具体的业务需求，如12306购票业务等等。Linux是一种操作系统，操作系统的软件需求是什么？操作系统是为了给应用层提供良好的接口而进行总线设备驱动管理、内存管理、文件管理、进程管理等等。总线设备驱动管理就是我们今天要谈的主题。Linux平台有各种子系统、各种总线、各种驱动，Linux系统对它们的管理就是软件框架的组成。我们要理解好Linux已有的框架，就要清晰地知晓其解决的问题，也就是其管理了哪些硬件设备，这些硬件设备的特点是什么，这些设备的访问方式是什么。

可以说，深入地理解硬件体系是理解好Linux总线设备驱动框架的前提！从面向对象的角度，我们要弄清楚，物理意义上的硬件是什么，而对应的软件对象是如何表述的。

以下阐述会重点讲述软件需求，作为以后分析框架的基础。

四、总线、驱动、设备

1.总线

总线代表着同类设备需要共同遵守的工作时序，不同的总线对于物理电平的要求是不一样的，对于每个比特的电平维持宽度也是不一样，而总线上传递的命令也会有自己的格式约束。如I2C总线、USB总线、PCI总线等等。以I2C总线为例，在同一组I2C总线上连接着不同的I2C设备。

2.设备

设备代表真实的、具体的物理器件，在软件上用器件的独特的参数属性来代表该器件。如I2C总线上连接的I2C从设备都有一个标识自己的设备地址，由这个设备地址来确定主设备发过来的命令是否该由它来响应。

3.驱动

驱动代表着操作设备的方式和流程。对于应用来说，应用程序open打开设备后，接着就read访问这个设备，驱动就是如何实现这个访问的具体的过程。驱动主要包括两部分，第一是通过对SOC的控制寄存器进行编程，按总线要求输出时序和命令，成功地与外围设备进行交互；第二是对第一步中得到的数据进行处理，并向应用层提供特定格式的数据。

a.不同总线的设备的驱动过程是不一样的，这个很容易理解，USB鼠标的驱动和I2C EEPROM的读时序肯定是不一样的，访问时序的产生和控制也是驱动的一部分。

b.同种总线不同设备类型的设备驱动也是不一样的。如I2C电容屏设备，对于读read来说就是在datasheet规定的地址上去读触摸点的X和Y坐标，而I2C EEPROM的读操作是读取存储的内容，两种设备的datasheet是不一样的，驱动自然是不一样的。

c.同种总线的同类设备的设备驱动也可能是不一样的。例如对于触摸屏，TSC2003只支持单点触控，而FT5X06支持多点触摸。在获取触控坐标时，前者只需要获得一个点的数据就返回，而后者则需要先获得当前有几个点的数据，然后再把所有点的坐标都读出来。

在驱动的操作中，一般都会用到GPIO和中断等硬件资源，如上图的SDA和SCL会连接到SOC芯片的具体的两个GPIO引脚，而I2C读写时一般都采用中断控制的方式（查询读写是否完成比较低效，浪费CPU）。如果我们在驱动中直接针对具体的引脚来编程，那这个驱动的平台可移植性就比较差，因为不同的产品设计可能引脚不一样。所以，为了提高驱动的可移植性，Linux把驱动要用到的GPIO和中断等资源剥离给设备去管理。即在设备里面包含其自己的设备属性，还包括了其连接到SOC所用到的资源。而驱动重点关注操作的流程和方法。

4.再谈总线

第1点中谈到的总线只是物理意义上的表述，总线就是在行业中制定出标准，明确规定时序的格式。我们在第3点中谈到，在软件层面上，时序的产生和控制由驱动负责。那我们要思考在软件层面上，总线的职责是什么？

总线在软件层面主要是负责管理设备和驱动。

a.设备要让系统感知自己的存在，设备需要向总线注册自己；同样地，驱动要让系统感知自己的存在，也需要向总线注册自己。设备和总线在初始化时必须要明确自己是哪种总线的，I2C设备和驱动不能向USB总线注册吧。

b.多个设备和多个驱动都注册到同一个总线上，那设备怎么找到最适合自己的驱动呢，或者说驱动怎么找到其所支持的设备呢？这个也是由总线负责，总线就像是一个红娘，负责在设备和驱动中牵线。设备会向总线提出自己对驱动的条件（最简单的也是最精确的就是指定对方的名字了），而驱动也会向总线告知自己能够支持的设备的条件（一般是型号ID等，最简单的也可以是设备的名字）。那设备在注册的时候，总线就会遍历注册在它上面的驱动，找到最适合这个设备的驱动，然后填入设备的结构成员中；驱动注册的时候，总线也会遍历注册在其之上的设备，找到其支持的设备（可以是多个，驱动和设备的关系是1:N），并将设备填入驱动的支持列表中。我们称总线这个牵线的行为是match。牵好线之后，设备和驱动之间的交互红娘可不管了。

c.总线在匹配设备和驱动之后驱动要考虑一个这样的问题，设备对应的软件数据结构代表着静态的信息，真实的物理设备此时是否正常还不一定，因此驱动需要探测这个设备是否正常。我们称这个行为为probe，至于如何探测，那是驱动才知道干的事情，总线只管吩咐得了。所以我们可以猜测在总线的管理代码中会有这样的逻辑：

if(match(device, driver) == OK)

driver->probe();

5.再谈驱动

假设设备正常，探测成功，这时就代表应用程序可以通过驱动来访问操作这个设备了。事实上是这样吗？仔细想想还少了什么东西。应用层通过什么来访问操作这个设备？想起来吗？我们公众号“嵌入式企鹅圈”的第一篇文章《Linux字符设备驱动剖析》中曾清晰地分析了Linux字符设备驱动的开发和访问过程，在开篇即提到应用程序如何访问设备：

int fd = open(“设备文件名”);

read(fd, buf, len);

write(fd, buf, len);

在这个应用程序中会涉及驱动两个问题，一是设备文件名从何而来，二是应用层的open、read和write对应驱动哪些接口，是如何对应的。这些都是驱动要解决的问题。

a.总线匹配设备和驱动之后，驱动探测到设备正常，这时驱动是处于做好准备让应用层来差遣了，但是设备文件名如果没有创建，应用程序也不知从何入手。所以在驱动的probe探测成功之后，立即创建设备文件是最合适的时机。其通过sysfs文件系统、uevent事件通知机制和后台应用服务mdev程序配合能够成功地在/dev目录创建对应的设备文件。

b.驱动要提供应用层open、read、write、ioctl等操作的对应接口，而且这些接口要向系统报备（注册）自己，否则系统也不知道怎么调用驱动，因为在上面的描述中从始至终都是设备、驱动和总线三个东西在唱戏，它们跟系统，严格意义是跟Linux的虚拟文件系统和设备文件系统还没建立起关系来。即驱动要包括以下步骤：

B1.设备要提供struct file_operation结构定义的接口：

struct file_operations {

int (*open) (struct inode *, struct file *);

int (*ioctl) (struct inode *, struct file *, ...);

ssize_t (*read) (struct file *, char __user *,...);

ssize_t (*write) (struct file *, const char __user *, ...);

…}

这些接口将会对应到应用层的设备访问操作。在这些接口中，其会根据第3点中提到的需求去完成自己的操作任务。

B2.应用层正常的访问流程是：应用层操作->虚拟文件系统操作->具体文件系统操作->具体设备驱动的操作。虚拟文件系统VFS系统已经存在，具体文件系统操作对于字符设备来说非常简单，我们姑且认为是字符设备文件系统devfs，此时字符设备驱动要做的是将自己的struct file_operations向devfs注册，对应字符设备驱动是cdev_add函数。详细的分析过程可以参考《Linux字符设备驱动剖析》。

所以我们可以想象在驱动driver的结构体中有一个probe接口，驱动要实现这个接口，而这个probe接口要完成的工作包括：

Driver->probe()

I.探测设备是否正常

II.cdev_add(struct file_operations)注册操作接口

III. device_create()创建设备文件

6.继续谈驱动

做好以上准备即已万事俱备的时候，等着应用程序来访问操作了。通过《Linux字符设备驱动剖析》中open的整个过程，到最后会调用到具体驱动的open，接下来我们就要阐述一下设备驱动的struct file_operations中的接口都要做什么。我们挑几个主要的来讲讲，其余可以自己想象。

a.open一般会进行驱动的初始化，可能包括硬件的初始化和软件的初始化。我们在第3点谈驱动的时候，曾说明为了让驱动更具移植性，会将驱动driver过程中使用到的具体GPIO和IRQ中断等资源列入设备device的属性内容。这时device数据结构中断的GPIO和IRQ的标识都来源于SOC datasheet的物理地址定义。我们都知道Linux在运行过程中会使用到SOC的MMU内存管理单元来管理自己的内存，会将内存分为两部分，内核空间（3G-4G）和用户空间（0-3G），这两块地址空间都是虚拟线性地址空间，即程序编译链接之后对应的地址空间，虚拟地址空间需要通过MMU和页表来映射到实际的物理内存空间才能最终访问到物理内存和物理IO等资源。而驱动操作硬件都处在内核空间，在open函数中主要包括以下操作：

a1.通过系统提供的资源获取接口获取到GPIO和IRQ等资源

a2.通过ioremap接口将GPIO和IRQ从物理地址空间映射到3G-4G中的虚拟地址空间

a3.根据具体的控制规格设置GPIO和IRQ相关的寄存器。

以上初始化的动作可能会出现在驱动probe探测的代码中，那open的接口可以什么都不做。

b. read：驱动的open如果成功，那整个访问流程已经成功一大半了，因为open的流程足够漫长和复杂。而read只是从用户空间的fd文件句柄找到所属进程的file文件结构，然后即可找出file_operations->read，其即是驱动的read接口。那就按着外网设备的规格和总线的时候进行操作，达到read设备的目的。Write也一样。

c. ioctl一般是对设备进行参数设置。

隆重推荐本人以下原创文章，有助读者系统、全面地理解嵌入式Linux的系统架构和驱动开发！

从需求的角度去理解Linux系列相关博文：

1. Linux字符设备驱动剖析

2.  Linux设备文件的创建和mdev

3. 符设备驱动字、平台设备驱动、设备驱动模型、sysfs的关系

4.Linux模块化机制和module_init

5. Linux中断完全分析

6. Linux input子系统分析之一:软件层次

7. 全网络对Linux input子系统最清晰、详尽的分析

8. 陆续推出Framebuffer、I2C、MTD等子系统的分析

微信公众号：嵌入式企鹅圈

1.忠于Linux源码，百分百原创。

2.从上电第一行代码、系统第一行代码、模块第一行代码、应用第一行代码，深入讲解嵌入式软件生命周期。
3 从需求出发，从架构着眼。