首页理论教育深入剖析Linux设备驱动

深入剖析Linux设备驱动

2023-11-22 理论教育版权反馈

【摘要】：具体分析设备模型中的设备管理，首先要分析device结构。从device可见，重点是管理的资源，当然也包含针对sys文件系统关联的属性。而设备的层次关系在实际的情况下通常是从逻辑层的功能设备逐渐到物理层的总线设备，最终到platform bus中对应的device，这样系统就建立了完整的设备层次关系。设备模型通知udev的方式如图5-19所示。通过uevent通知到应用层，就完成设备管理创建设备文件到应用层的操作。

对设备模型中的设备，考虑的重点是如何进行抽象。任何设备要使用都是需要资源的，无论是自身的资源还是系统的资源，所以应从其拥有的资源考虑进行抽象。

具体分析设备模型中的设备管理，首先要分析device结构。

从device可见，重点是管理的资源，当然也包含针对sys文件系统关联的属性。而设备的层次关系在实际的情况下通常是从逻辑层的功能设备逐渐到物理层的总线设备，最终到platform bus中对应的device，这样系统就建立了完整的设备层次关系。

还是以platform总线的设备进行实例化分析：

这里可以理解为其记录总线相关的特殊资源，但实际又有platform总线的特殊性，re-sources实际是各种资源的抽象，其中包含中断、IO空间等。其资源具体的类型在ioport.h中定义，具体如下：

可见platform设备管理的资源就是物理设备的各种资源，这和实际也是一致的。

整体来说，设备模型中的设备就是管理资源以供驱动访问和操作，资源管理是设备管理的一个核心。

当然设备管理还需要能为用户创建合适的操作接口文件，不能因为创建时间的差异而产生不同的文件名，这就需要和用户层的管理程序结合，相应的框架和流程如图5-18所示。

从图5-18可见，内核设备模型和udev紧密结合，按从1～6的顺序执行最终对固定的设备产生固定的操作接口文件，从而保证了应用的一致视角。设备模型通知udev的方式如图5-19所示。

通过uevent通知到应用层，就完成设备管理创建设备文件到应用层的操作。这样设备管理的功能就是完整的了。(www.chuimin.cn)

图5-18　设备模型设备文件创建流程及框架

图5-19　设备模型通知应用层流程

关于设备名，设备模型提供产生文件名的接口device_get_devnode，并通过uevent属性文件提供给用户层，device_get_devnode的细节如下：

设备模型通过device_add接口来为以上功能提供统一的服务，具体细节如下：

从代码细节可见，设备并不完全与总线绑定，还有上层功能抽象的功能类，这和之前的设备分类是吻合的。具体的设备在进行add操作之前要将其bus或者class的属性进行正确地设置。设备模型提供了良好的框架，具体的实例化就交由具体的模块实现。