Detailed explanation of Linux device model (6)_Bus

1 Overview

In the Linux device model, Bus is a special type of device, which is a channel that connects the processor and other devices. In order to facilitate the implementation of the device model, the kernel stipulates that each device in the system must be connected to a Bus. This Bus can be an internal Bus, a virtual Bus, or a Platform Bus.

The kernel abstracts the Bus through the structure struct bus_type, which is defined in include/linux/device.h. This article will focus on this structure to describe the functions of Bus in the Linux kernel and the related implementation logic. Finally, we will briefly introduce some standard Buses (such as Platform) and introduce their uses and usage scenarios.

2. Function description

As usual, we introduce some core data structures before introducing functions. For the Bus module, the core data structure is the structure struct bus_type. There is also a structure related to the subsystem, which we will also introduce.

2.1 struct bus_type

 1: /* inlcude/linux/device.h, line 93 */
 2: struct bus_type {
 3:     const char *name;
 4:     const char *dev_name;
 5:     struct device       *dev_root;
 6:     struct bus_attribute    *bus_attrs;
 7:     struct device_attribute *dev_attrs;
 8:     struct driver_attribute *drv_attrs;
 9:  
 10:    int (*match)(struct device *dev, struct device_driver *drv);
 11:    int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
 12:    int (*probe)(struct device *dev);
 13:    int (*remove)(struct device *dev);
 14:    void (*shutdown)(struct device *dev);
 15:  
 16:    int (*suspend)(struct device *dev, pm_message_t state);
 17:    int (*resume)(struct device *dev);
 18:  
 19:    const struct dev_pm_ops *pm;
 20:  
 21:    struct iommu_ops *iommu_ops;
 22:  
 23:    struct subsys_private *p;
 24:    struct lock_class_key lock_key;
 25: };

“

name, the name of the bus, will exist in the form of a directory in sysfs. For example, the platform bus appears as "/sys/bus/platform" in sysfs.

dev_name, this name is related to the init_name in the struct device structure described in "Linux Device Model (5)_device and device driver". For some devices (such as mass USB devices), designers simply don't bother to give it a name, and the kernel also supports this laziness and allows the device name to be left blank. In this way, when the device is registered to the kernel, the core logic of the device model will use the form of "bus->dev_name device ID" to generate a name for such a device.

bus_attrs, dev_attrs, drv_attrs, some default attributes, can automatically add corresponding attributes to bus, device or device_driver when they are added to the kernel.

dev_root, according to the kernel comments, the dev_root device is the default device to use as the parent of the bus (Default device to use as the parent), but in the actual implementation of the kernel, it is only related to a function called sub system, which will be introduced later.

match, a callback function implemented by a specific bus driver. When any device or device_driver belonging to the Bus is added to the kernel, the kernel will call this interface. If the newly added device or device_driver matches its other half, the interface will return a non-zero value. At this time, the core of the Bus module The logic will perform subsequent processing.

uevent, a callback function implemented by a specific bus driver. When any device belonging to the Bus is added, removed or otherwise acted upon, the core logic of the Bus module will call this interface so that the bus driver can modify the environment variables.

probe and remove, these two callback functions are very similar to those in device_driver, but their existence is very meaningful. You can imagine that if you need a device specified by probe (actually initialization), you need to ensure that the bus where the device is located has been initialized and can work correctly. This requires executing its bus probe before executing device_driver's probe. The process of remove is reversed.
Note 1: Not all buses require probe and remove interfaces, because for some buses (such as platform bus), it is a virtual bus itself. It does not need to be initialized and can be used directly. Therefore, the drivers of these buses are Both callback functions can be left empty.

Shutdown, suspend, and resume have similar principles to probe and remove. The implementation of power management is not explained yet.

pm, the logic related to power management will not be explained yet.

iommu_ops, not explained yet.

p, a pointer of type struct subsys_private, we will explain it in a section later.

”

2.2 struct subsys_private

This structure is similar to the struct driver_private in device_driver. It is mentioned in the "Linux Device Model (5)_device and device driver" chapter, but there is no detailed explanation.

要说明subsys_private的功能，让我们先看一下该结构的定义：

 1: /* drivers/base/base.h, line 28 */
 2: struct subsys_private {
 3:     struct kset subsys;
 4:     struct kset *devices_kset;
 5:     struct list_head interfaces;
 6:     struct mutex mutex;
 7:  
 8:     struct kset *drivers_kset;
 9:     struct klist klist_devices;
 10:    struct klist klist_drivers;
 11:    struct blocking_notifier_head bus_notifier;
 12:    unsigned int drivers_autoprobe:1;
 13:    struct bus_type *bus;
 14:  
 15:    struct kset glue_dirs;
 16:    struct class *class;
 17: };

看到结构内部的字段，就清晰多了，没事不要乱起名字嘛！什么subsys啊，看的晕晕的！不过还是试着先理解一下为什么起名为subsys吧：

按理说，这个结构就是集合了一些bus模块需要使用的私有数据，例如kset啦、klist啦等等，命名为bus_private会好点（就像device_driver模块一样）。不过为什么内核没这么做呢？看看include/linux/device.h中的struct class结构（我们会在下一篇文章中介绍class）就知道了，因为class结构中也包含了一个一模一样的struct subsys_private指针，看来class和bus很相似啊。

想到这里，就好理解了，无论是bus，还是class，还是我们会在后面看到的一些虚拟的子系统，它都构成了一个“子系统（sub-system）”，该子系统会包含形形色色的device或device_driver，就像一个独立的王国一样，存在于内核中。而这些子系统的表现形式，就是/sys/bus（或/sys/class，或其它）目录下面的子目录，每一个子目录，都是一个子系统（如/sys/bus/spi/）。

好了，我们回过头来看一下struct subsys_private中各个字段的解释：

“

subsys、devices_kset、drivers_kset是三个kset，由”Linux设备模型(2)_Kobject”中对kset的描述可知，kset是一个特殊的kobject，用来集合相似的kobject，它在sysfs中也会以目录的形式体现。其中subsys，代表了本bus（如/sys/bus/spi），它下面可以包含其它的kset或者其它的kobject；devices_kset和drivers_kset则是bus下面的两个kset（如/sys/bus/spi/devices和/sys/bus/spi/drivers），分别包括本bus下所有的device和device_driver。

interface是一个list head，用于保存该bus下所有的interface。有关interface的概念后面会详细介绍。

klist_devices和klist_drivers是两个链表，分别保存了本bus下所有的device和device_driver的指针，以方便查找。

drivers_autoprobe，用于控制该bus下的drivers或者device是否自动probe，”Linux设备模型(5)_device和device driver”中有提到。

bus和class指针，分别保存上层的bus或者class指针。

”

2.3 功能总结

根据上面的核心数据结构，可以总结出bus模块的功能包括：

• bus的注册和注销
• 本bus下有device或者device_driver注册到内核时的处理
• 本bus下有device或者device_driver从内核注销时的处理
• device_drivers的probe处理
• 管理bus下的所有device和device_driver

3. 内部执行逻辑分析

3.1 bus的注册

bus的注册是由bus_register接口实现的，该接口的原型是在include/linux/device.h中声明的，并在drivers/base/bus.c中实现，其原型如下：

 1: /* include/linux/device.h, line 118 */
 2: extern int __must_check bus_register(struct bus_type *bus);

“

该功能的执行逻辑如下：

• 为bus_type中struct subsys_private类型的指针分配空间，并更新priv->bus和bus->p两个指针为正确的值
• 初始化priv->subsys.kobj的name、kset、ktype等字段，启动name就是该bus的name（它会体现在sysfs中），kset和ktype由bus模块实现，分别为bus_kset和bus_ktype
• 调用kset_register将priv->subsys注册到内核中，该接口同时会向sysfs中添加对应的目录（如/sys/bus/spi）
• 调用bus_create_file向bus目录下添加一个uevent attribute（如/sys/bus/spi/uevent）
• 调用kset_create_and_add分别向内核添加devices和device_drivers kset，同时会体现在sysfs中
• 初始化priv指针中的mutex、klist_devices和klist_drivers等变量
• 调用add_probe_files接口，在bus下添加drivers_probe和drivers_autoprobe两个attribute（如/sys/bus/spi/drivers_probe和/sys/bus/spi/drivers_autoprobe），其中drivers_probe允许用户空间程序主动出发指定bus下的device_driver的probe动作，而drivers_autoprobe控制是否在device或device_driver添加到内核时，自动执行probe
• 调用bus_add_attrs，添加由bus_attrs指针定义的bus的默认attribute，这些attributes最终会体现在/sys/bus/xxx目录下

”

3.2 device和device_driver的添加

我们有在”Linux设备模型(5)_device和device driver”中讲过，内核提供了device_register和driver_register两个接口，供各个driver模块使用。而这两个接口的核心逻辑，是通过bus模块的bus_add_device和bus_add_driver实现的，下面我们看看这两个接口的处理逻辑。

这两个接口都是在drivers/base/base.h中声明，在drivers/base/bus.c中实现，其原型为：

 1: /* drivers/base/base.h, line 106 */
 2: extern int bus_add_device(struct device *dev);
 3:  
 4: /* drivers/base/base.h, line 110 */ 
 5: extern int bus_add_driver(struct device_driver *drv);

“

bus_add_device的处理逻辑：

• 调用内部的device_add_attrs接口，将由bus->dev_attrs指针定义的默认attribute添加到内核中，它们会体现在/sys/devices/xxx/xxx_device/目录中

• 调用sysfs_create_link接口，将该device在sysfs中的目录，链接到该bus的devices目录下，例如：

  xxx# ls /sys/bus/spi/devices/spi1.0 -l
  lrwxrwxrwx root root 2014-04-11 10:46 spi1.0 -> ../../../devices/platform/s3c64xx-spi.1/spi_master/spi1/spi1.0
  其中/sys/devices/…/spi1.0，为该device在sysfs中真正的位置，而为了方便管理，内核在该设备所在的bus的xxx_bus/devices目录中，创建了一个符号链接

• 调用sysfs_create_link接口，在该设备的sysfs目录中（如/sys/devices/platform/alarm/）中，创建一个指向该设备所在bus目录的链接，取名为subsystem，例如：

  xxx # ls /sys/devices/platform/alarm/subsystem -l
  lrwxrwxrwx root root 2014-04-11 10:28 subsystem -> ../../../bus/platform

• 最后，毫无疑问，要把该设备指针保存在bus->priv->klist_devices中

bus_add_driver的处理逻辑：

• Allocate space for the driver's struct driver_private pointer (priv), initialize the priv->klist_devices, priv->driver, priv->kobj.kset and other variables, and save the pointer at p of device_driver
• Set the driver's kset (priv->kobj.kset) to the bus's drivers kset (bus->p->drivers_kset), which means that all driver kobjects are located under bus->p->drivers_kset (send/ sys/bus/xxx/drivers directory)
• Using the driver's name as a parameter, call the kobject_init_and_add interface to register the driver's kobject in sysfs, which is reflected in the /sys/bus/xxx/drivers/ directory, such as /sys/bus/spi/drivers/spidev
• Save the driver in the klist_drivers linked list of the bus, and according to the value of drivers_autoprobe, choose whether to call driver_attach for probe
• Call the driver_create_file interface and create uevent attribute
in the directory of the driver in sysfs.
• Call the driver_add_attrs interface and create the default attribute defined by the bus->drv_attrs pointer in the directory of the driver in sysfs
• At the same time, according to the suppress_bind_attrs flag, decide whether to create bind and unbind attributes in the directory of the driver in sysfs (for details, please refer to the introduction in "Linux Device Model (5)_device and device driver")

”

3.3 driver probe

In "Linux Device Model (5)_device and device driver", we have introduced the driver's probe timing and process. Most of the logic will rely on the implementation of the bus module, mainly the bus_probe_device and driver_attach interfaces. Similarly, these two interfaces are declared in drivers/base/base.h and implemented in drivers/base/bus.c.

The behavior of these two structures is similar, and the logic is very simple, that is: search for the bus where it is located, and compare whether there is a device_driver (or device) with the same name. If so, the device is not bound to a Driver (Note: This is very important. Importantly, through it, the same Driver can drive multiple devices with the same name (which will be mentioned later in the description of the Platform device) and the probe interface of device_driver is called.

4. Miscellaneous

4.1 Let’s talk about Subsystem again

In the old Linux kernel version (taking the linux2.6.23 version of the kernel used by Wowo as an example), all top-level directories (including some secondary directories) under sysfs call the subsystem_register interface and use sub-system Registered to the kernel in the form of:

“

/sys/bus/

/sys/devices/

/sys/devices/system/

/sys/block

/sys/kernel/

/sys/slab/

…

”

The implementation of subsystem_register at that time was very simple, which was to call kset_register and create a kset. We know that kset is a collection of kobjects and will be presented in the form of a directory in sysfs.

In the new version of the kernel (such as linux3.10.29 referenced in the "Linux Kernel Analysis" series of articles), the implementation of subsystem has changed a lot, for example: the subsystem_register interface has been removed (but in order to be compatible with /sys/device/ system subsystem, in drivers/base/bus.c, an internal interface of subsys_register is added to implement the corresponding functions). According to these changes, there are now two ways to register a subsystem:

Method 1: In their respective initialization functions, call the kset_create_and_add interface to create the corresponding subsystem, including:

• bus子系统，/sys/bus/，buses_init（drivers/base/bus.c）
• class子系统，/sys/class
• kernel子系统，/sys/kernel
• firmware子系统，/sys/firmware
• 等等

其中bus子系统就是本文所讲的Bus模块，而其它的，我们会在后续的文章中陆续讲述。这个方式和旧版本内核使用kset_register接口的方式基本一样。

方式二，在bus模块中，利用subsys_register接口，封装出两个API：subsys_system_register和subsys_virtual_register，分别用于注册system设备(/sys/devices/system/)和virtual设备(/sys/devices/virtual/)。 而该方式和方式一的区别是：它不仅仅创建了sysfs中的目录，同时会注册同名的bus和device。

4.2 system/virtual/platform

在Linux内核中，有三种比较特殊的bus（或者是子系统），分别是system bus、virtual bus和platform bus。它们并不是一个实际存在的bus（像USB、I2C等），而是为了方便设备模型的抽象，而虚构的。

system bus是旧版内核提出的概念，用于抽象系统设备（如CPU、Timer等等）。而新版内核认为它是个坏点子，因为任何设备都应归属于一个普通的子系统（New subsystems should use plain subsystems, drivers/base/bus.c, line 1264），所以就把它抛弃了（不建议再使用，它的存在只为兼容旧有的实现）。

virtaul bus是一个比较新的bus，主要用来抽象那些虚拟设备，所谓的虚拟设备，是指不是真实的硬件设备，而是用软件模拟出来的设备，例如虚拟机中使用的虚拟的网络设备（有关该bus的描述，可参考该链接处的解释：https://lwn.net/Articles/326540/）。

platform bus就比较普通，它主要抽象集成在CPU（SOC）中的各种设备。这些设备直接和CPU连接，通过总线寻址和中断的方式，和CPU交互信息。

我们会在后续的文章中，进一步分析这些特殊的bus，这里就暂时不详细描述了。

4.3 subsys interface

subsys interface是一个很奇怪的东西，除非有一个例子，否则很难理解。代码中是这样注释的：

“

Interfaces usually represent a specific functionality of a subsystem/class of devices.

”

字面上理解，它抽象了bus下所有设备的一些特定功能。

kernel使用struct subsys_interface结构抽象subsys interface，并提供了subsys_interface_register/subsys_interface_unregister用于注册/注销subsys interface，bus下所有的interface都挂载在struct subsys_private变量的“interface”链表上（具体可参考2.2小节的描述）。struct subsys_interface的定义如下：

1. /**
2. \* struct subsys_interface - interfaces to device functions
3. \* @name: name of the device function
4. \* @subsys: subsytem of the devices to attach to
5. \* @node: the list of functions registered at the subsystem
6. \* @add_dev: device hookup to device function handler
7. \* @remove_dev: device hookup to device function handler
8. *
9. \* Simple interfaces attached to a subsystem. Multiple interfaces can
10. \* attach to a subsystem and its devices. Unlike drivers, they do not
11. \* exclusively claim or control devices. Interfaces usually represent
12. \* a specific functionality of a subsystem/class of devices.
13. */
14. struct subsys_interface {
15. const char *name;
16. struct bus_type *subsys;
17. struct list_head node;
18. int (*add_dev)(struct device *dev, struct subsys_interface *sif);
19. int (*remove_dev)(struct device *dev, struct subsys_interface *sif);
20. };

“

name，interface的名称。

subsys，interface所属的bus。

node，用于将interface挂到bus中。

add_dev/remove_dev, two callback functions, the core functions of subsys interface. When a device is added or deleted under the bus, the bus core will call the add_dev or remove_dev callback of all subsys interfaces under it. Designers can implement the required functions in these two callback functions, such as binding the driver corresponding to the "specific functionality", etc.

”

The implementation logic of subsys interface is relatively simple and will not be described in detail here. For details, please refer to the corresponding code in "drivers/base/bus.c". In addition, when analyzing cpufreq framework later, we will encounter examples of using subsys interface. Then we will further understand its practical significance.

The above is the detailed content of Detailed explanation of Linux device model (6)_Bus. For more information, please follow other related articles on the PHP Chinese website!