【linux内核分析与应用-陈莉君】设备驱动模型

目录

 

1.设备驱动模型的引入

2.sys文件系统

3.linux设备模型

4.linux设备模型中的核心对象KOBJECT

5.linux设备模型中的对象集合体KSET

6.linux设备模型中的共同特性KTYPE

7.platform平台总线驱动模型

7.1 总述

7.2 platform device

7.3 platform driver

7.4 device driver

7.5 driver_private

7.6 设备与驱动匹配的过程

8.参考资料和思考问题

---

1.设备驱动模型的引入

为什么要引入设备驱动模型？
由于linux支持世界上所有的不同功能的硬件设备,导致linux中有一般的代码是设备驱动而且随着硬件的快速
升级换代,设备驱动的代码量也快速增长，为了设备多样性带来的linux驱动开发的复杂度以及设备热插拔处理
电源管理等,linux内核提出了设备模型,也成为了driver module的概念.


设备驱动模型的引入.
设备模型将硬件设备归纳,分类，然后抽象出一套标准的数据结构和接口,驱动的开发就简化为对内核所规定的
数据结构的填充和实现,因此linux设备驱动模型是一种抽象,为内核建立起统一的设备模型,其目的是提供一个
系统结构的一般性抽象描述,linux设备模型跟踪所有系统所知道的设备,以便让设备驱动模型的核心程序协调
驱动和新设备之间的关系.


Linux设备驱动模型引入的目的:
(1)电源管理和系统关机,设备之间大部分情况下都是有依赖和耦合的,因此要实现电源管理就必须对系统的
  设备结构有清楚的理解,应该知道先关那个,然后再关哪个.
(2)与用户空间通信,因为linux设备驱动程序非常复杂,它提供了一种与用户空间进行通信的机制,即sys文
   件系统.sys虚拟文件系统的实现与设备模型密切相关,并且向外界展示了它所表述的结构,向用户空间所
   提供的系统信息以及改变操作参数的接口,要通过sys文件系统来实现,也就是通过设备模型来实现. 
(3)热插拔设备,处理与用户空间通信的热插拔设备是通过设备模型来管理的.
(4)设备分类机制,设备模型包括了对设备分类的机制,它在更高的功能层上描述了这些设备,并使得这些设备
   对用户空间可见,尤其是将命名设备的功能从内核层转移到了用户层,大大提高了设备管理的灵活性;
(5)对象生命周期的管理,设备模型实现一系列机制以及处理对象的生命周期,对象之间的关系以及这些对象
   在用户空间的表示简化了编程人员创建或者管理对象的工作.

2.sys文件系统

sys文件系统是一个类似于proc文件系统的特殊文件系统,用于将系统中的设备组织成层次结构,
并向用户程序提供详细的内核数据信息,也就是在用户态下可以通过对sys文件系统的信息的访问
来查看内核态的驱动或设备等信息,如图为sys文件系统的目录及子目录信息.

3.linux设备模型

linux设备驱动模型使用一系列抽象(面向对象思想中的类),提供统一的设备管理视图,
这些抽象包括:总线，类，设备和设备驱动.

(1)总线
   BUS,它是CPU和一个或多个设备之间信息交互的通道,为了方便设备模型的抽象,所有的设备都应该连接到总
线上.
(2)分类
   CLASS,在linux设备模型中,CLASS的概念非常类似面向对象设计中的CLASS,它主要是集合具有相似功能或
属性的设备,这样就可以抽象出一套在多个设备中公用的数据结构或接口函数.因而从属于相同CLASS的设备的
驱动程序就不再需要重新定义这些公共的资源,直接从CLASS中继承即可.
(3)设备
   DEVICE,抽象系统中所有的硬件设备,描述它的名字,属性,从属的BUS,从属的CLASS等信息.
(4)设备驱动
   DEVICE DRIVER,linux设备模型用Driver抽象硬件设备的驱动程序,它包括设备的初始化,电源管理相关接
口的实现,linux内核中的驱动开发基本上都是围绕该抽象进行，也就是实现规定的接口函数.

4.linux设备模型中的核心对象KOBJECT

kobject结构体是对设备驱动模型下所有对象抽象出来的共有部分,它提供一些公共的服务，
比如对象的引用计数,维护对象的链表,对象的上锁,对用户空间的表示等,设备驱动模型中各种
对象其内部都会包含一个object,它的地位相当于面向对象思想中的总基类.

5.linux设备模型中的对象集合体KSET

kset是嵌入相同类型结构的kobject的集合,可以将其看做容器,可将所有相关的kobject对象聚集在一起,
比如全部的块设备就是一个kset.


kset结构关心的是对象的聚集与集合,它与kobject之间的关系如图所示.

6.linux设备模型中的共同特性KTYPE

7.platform平台总线驱动模型

7.1 总述

为了解决驱动代码与设备信息耦合的问题,linux提出了platform bus,也就是平台总线的概念,
也就是使用虚拟总线将设备信息和驱动程序进行分离,也就是机制与策略分离的一种策略,平台
总线会维护两条链表,分别管理设备和驱动,当一个设备被注册到总线上的时候,总线会根据其名字
搜索对应的驱动,如果找到,就将设备信息导入驱动程序并执行驱动;当一个驱动被注册到平台总线
的时候,总线也会搜索设备,总是,平台总线负责将设备信息与驱动代码进行匹配,这样就可以做到
驱动与设备信息的分离,与传统的bus device driver机制相比,platform平台由内核进行统一管理,
在驱动中使用资源,提高了代码的安全性和可移植性.
当硬件部分的时序变了或者芯片替换了,我们只需要修改硬件的部分代码,还有一部分代码属于内核
的稳定部分,是不需要进行修改的，这就是一种通用的接口,因此，本讲将重点讲解platform模型.

platform bus是一条虚拟总线,其中platform device是相应的设备,platform driver是相应的驱动.

7.2 platform device

7.3 platform driver

7.4 device driver

7.5 driver_private

7.6 设备与驱动匹配的过程

实现platform模型的过程就是总线对设备和驱动的匹配过程.
打个比方,就好比相亲,总线是红娘,设备是男方,驱动是女方,
红娘(总线)负责男方(设备)和女方(驱动)的撮合,过程如下：

(1)男方(女方)找到红娘，说我来登记一下,看有没有合适的姑娘（汉子）—— 设备或驱动的注册；
(2)红娘这时候就需要看看有没有八字匹配的姑娘(汉子)——match函数进行匹配,基本匹配规则是看name是否相同；
  如果八字不合，就告诉男方(女方)没有合适的对象,先等着.—— 设备和驱动会等待,直到匹配成功；
  终于遇到八字匹配的了，那就结婚呗！接完婚，男方就向女方交代,我有多少存款，我的房子在哪，钱放在哪
等等（相对于交代struct resource *resource中的信息）,女方说好啊,于是去房子里拿钱去给男方买菜啦，
给自己买衣服、化妆品、首饰啊等等,这个就相当于执行probe函数(匹配成功后驱动执行的第一个函数),
当然如果男的跟小三跑了(设备卸载),女方也不会继续待下去的,女方会执行remove函数将自己卸载.


从代码角度上来实际看一下内核中是如何匹配设备和驱动的：
1.实例化struct bus_type,系统为总线定义了一个bus_type的platform_bus_type;
2.执行平台总线驱动注册函数,注册函数中会将相关的函数都挂上去;
3.设备与驱动匹配代码.


设备驱动中引入platform这个概念隔离了BSP和驱动,在BSP中定义platform和设备使用的资源,设备具体
匹配的信息,而在驱动中只需要通过API去获取资源或数据,做到了把相关代码和驱动代码的分离,使得驱动
具有更好的扩展性和跨平台性.

8.参考资料和思考问题