万千设备,linux内核如何知道?

描述

1、简介

本文基于内核源码4.19.4分析。

linux内核设备的注册由device_register()函数完成,这个函数是linux设备驱动模型的核心函数,实现在/drivers/base/core.c中:

电源管理

在device_register()函数中,分为两个步骤:

(1)调用device_initialize():该步骤用于初始化一个device。

(2)调用device_add():该函数用于将device添加到linux内核的device树中。

2、device_initialize分析

该函数接收一个struct device *dev参数,在该函数中初始化struct device结构中的几个重要成员:

电源管理

设置dev->kobj.kset为device_kset。device_kset是一个struct kset类型的全局变量,用于向sysfs文件系统中导出目录:/sys/device/* 。

初始化dev中的kobject,并指定与这个对象相关联的ktype为device_type。

初始化dma_pools链表。

初始化struct device中的各种锁:

电源管理

初始化device的电源管理:

电源管理

如果在NUMA下,还会初始化设置device的numa_node为-1。

接着初始化device下的links中的链表:

电源管理

在struct device 中的links表示链接到该设备的suppliers和consumers,由struct dev_links_info表示:

电源管理

设置device下的links.status值为DL_DEV_NO_DRIVER,表示此时还没有对应驱动attach到这个设备。

以上步骤则是device_initialize()初始化设备时完成的操作。

3、device_add分析

(1)调用get_device(dev)增加device的引用计数。

(2)如果dev->p为NULL,则调用device_private_init()设置device的私有数据:

电源管理

(3)设置device的name:

电源管理

如果开启支持pr_debug()函数,则会打印出对应的设备名称。

(4)寻找父设备和父设备对应的kobj,并调用kobject_add()将dev->kobj添加到dev->kobj.parent:

电源管理

(5)使用device_create_file为device创建sysfs属性文件:

 

error = device_create_file(dev, &dev_attr_uevent);

 

dev_attr_uevent是一个struct device_attribute类型的数据,该结构用于描述导出设备属性的接口,定义如下:

 

struct device_attribute {
 struct attribute attr;
 ssize_t (*show)(struct device *dev, struct device_attribute *attr,
   char *buf);
 ssize_t (*store)(struct device *dev, struct device_attribute *attr,
    const char *buf, size_t count);
};

 

(6)添加类的符号链接:

 

error = device_add_class_symlinks(dev);

 

device_add_class_symlinks()的功能是将设备添加到指定的设备类中,并在/sys/class目录下为设备创建符号链接,以便用户空间程序能够方便地访问和管理设备。

(7)调用device_add_attrs()为设备添加属性:

 

error = device_add_attrs(dev);

 

device_add_attrs()的功能是为设备添加属性,并在/sys/devices目录下创建相应的属性文件。这样,用户空间程序可以通过访问设备的属性文件来读取和修改设备的属性值。这个函数在设备驱动的初始化过程中常常被调用,以确保设备的属性能够正确地显示和访问。

(8)调用bus_add_device()添加设备到bus:

电源管理

bus_add_device用于将设备添加到总线上。它的功能是将一个设备(struct device结构体)添加到指定总线(struct bus_type结构体)上,并进行相应的初始化和注册操作。

bus_add_device的执行逻辑:

(1)从dev->bus中取得bus_type*类型的指针bus,如果获取bus不成功,则函数直接返回;如果bus获取成功,则会继续后续的第(2)步操作。

(2)调用device_add_attrs接口,将由bus->dev_attrs指针定义的默认attribute添加到内核中,这个操作会体现在sysfs文件系统中的/sys/devices/xxx/xxx_device/目录中。

(3)调用device_add_groups将bus_dev_groups添加到内核中。

(4)调用sysfs_create_link将该设备在sysfs中的目录,链接到该bus的devices目录下

(5)接着依然调用sysfs_create_link,在该设备的sysfs目录中,创建一个指向该设备所在bus目录的链接,命名为subsystem。

(6)前面几个操作实则是向sysfs文件系统注册关于设备的信息,向用户空间抛出接口。最后步骤则是调用klist_add_tail()将该设备指针保存到bus->p->klist_devices中。

(9)调用device_pm_add()将一个设备添加到PM核心的active设备链表中。

(10)创建设备节点:

电源管理

(11)通过bus_notifier告知系统设备已经添加:

电源管理

(12)调用bus_probe_device()为该设备probe一个驱动。该函数实现如下:

电源管理

具体执行流程如下:

(1)从dev中解析出该dev所在而bus,如果bus不存在,则退出该函数。

(2)如果设置了driver_autoprobe,则调用device_initial_probe(dev)。该函数本质调用到device_attach(),尝试将设备连接到驱动程序。

(3)遍历bus上的子系统接口链表interfaces,如果add_dev函数指针存在,则调用对应的函数。(从源码来看有些驱动程序,会使用struct subsys_interface来实现,在此处实现对注册的subsys_interface下的add_dev的调用执行)

(13)如果父设备存在,则会将该设备添加到父设备的klist_children链表中(klist_children是包含此设备的所有子节点的链表):

电源管理

(14)如果设备的class不为NULL,则会将class绑定到device:

 

klist_add_tail(&dev->p->knode_class,&dev->class->p->klist_devices);

 

(15)通知所有的interface接口:

电源管理

在内核中,struct class_interface是用于表示设备类和设备驱动之间的接口的结构体。它定义了设备类与设备驱动之间的关联关系,允许设备驱动在注册时与相应的设备类进行关联,并提供了一组函数指针,用于设备类调用设备驱动中的操作。

struct class_interface结构体定义如下:

 

struct class_interface {
    struct list_head node;
    struct class *class;
    int (*add)(struct device *dev, struct class_interface *class_intf);
    void (*remove)(struct device *dev, struct class_interface *class_intf);
};

 

node: 用于将struct class_interface链接到设备类的接口链表中。

class: 指向与该接口相关联的设备类。

add: 指向设备类调用设备驱动的添加操作的函数指针。当设备添加到设备类时,会调用此函数。

remove: 指向设备类调用设备驱动的移除操作的函数指针。当设备从设备类中移除时,会调用此函数。

通过使用struct class_interface,设备驱动可以与设备类进行交互,以便在设备添加或移除时执行相应的操作。这种机制允许设备驱动与设备类解耦,使得设备驱动可以在设备类的上下文中执行一些操作,而无需直接操作设备类。

回到device_add()中,使用了list_for_each_entry()遍历interfaces链表,如果设置了class_intf->add_dev,则调用该回调函数指针指向的函数。

4、总结

结合本文内容和linux内核源码,得出以下结论:

(1)在设备驱动模型中,所有的设备注册操作最后都会调用device_register()函数实现。

(2)在笔者分析的linux版本下的device_register()中,存在两个数据结构:struct class_interface 和struct subsys_interface。从内核源码来看,这两个结构只在为数不多的几个特定驱动程序中使用,那么可证明这可能是历史发展遗留下来的代码,在device_register中仍然保留了对这部分代码的支持。

(3)在device_register()中调用了bus_probe_device(),从而证明在注册设备的时候发生了『设备与驱动匹配』的过程。





审核编辑:刘清

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分