Dans le modèle d'appareil Linux, Bus est un type spécial d'appareil. Il s'agit d'un canal qui connecte le processeur et d'autres appareils. Afin de faciliter la mise en œuvre du modèle de périphérique, le noyau stipule que chaque périphérique du système doit être connecté à un Bus. Ce Bus peut être un Bus interne, un Bus virtuel ou un Bus Plateforme.
Le noyau résume le bus via la structure struct bus_type, qui est définie dans include/linux/device.h. Cet article se concentrera sur cette structure pour décrire les fonctions de Bus dans le noyau Linux et la logique d'implémentation associée. Enfin, nous présenterons brièvement quelques bus standards (tels que Platform) et présenterons leurs utilisations et scénarios d'utilisation.
Comme d'habitude, nous introduisons quelques structures de données de base avant d'introduire les fonctions. Pour le module Bus, la structure de données de base est la structure struct bus_type. Il existe également une structure liée au sous-système, que nous présenterons également.
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, le nom du bus, existera sous la forme d'un répertoire dans sysfs. Par exemple, le bus de la plateforme apparaît sous la forme "/sys/bus/platform" dans sysfs.
dev_name, ce nom est lié au init_name dans la structure de périphérique struct décrite dans "Modèle de périphérique Linux (5)_device et pilote de périphérique". Pour certains périphériques (tels que les périphériques USB de masse), les concepteurs ne prennent tout simplement pas la peine de lui donner un nom, et le noyau prend également en charge cette paresse et permet de laisser le nom du périphérique vide. De cette façon, lorsque le périphérique est enregistré auprès du noyau, la logique de base du modèle de périphérique utilisera la forme « bus-> nom_dev + ID de périphérique » pour générer un nom pour un tel périphérique.
bus_attrs, dev_attrs, drv_attrs, certains attributs par défaut, peuvent ajouter automatiquement les attributs correspondants au bus, au périphérique ou au périphérique_driver lorsqu'ils sont ajoutés au noyau.
dev_root, selon les commentaires du noyau, le périphérique dev_root est le périphérique parent par défaut du bus (périphérique par défaut à utiliser comme parent), mais dans l'implémentation réelle du noyau, il n'est lié qu'à une fonction appelée sous-système, qui sera introduit ultérieurement.
match, une fonction de rappel mise en œuvre par un chauffeur de bus spécifique. Lorsqu'un périphérique ou un périphérique_driver appartenant au bus est ajouté au noyau, le noyau appellera cette interface. Si le périphérique ou le périphérique_driver nouvellement ajouté correspond à son autre moitié, l'interface renverra une valeur non nulle à ce moment-là, le noyau. du module Bus La logique effectuera le traitement ultérieur.
uevent, une fonction de rappel mise en œuvre par un chauffeur de bus spécifique. Lorsqu'un périphérique appartenant au bus est ajouté, supprimé ou utilisé d'une autre manière, la logique de base du module Bus appellera cette interface afin que le pilote de bus puisse modifier les variables d'environnement.
probe et delete, ces deux fonctions de rappel sont très similaires à celles de device_driver, mais leur existence est très significative. Vous pouvez imaginer que si vous avez besoin d'un périphérique spécifié par sonde (en fait une initialisation), vous devez vous assurer que le bus sur lequel se trouve le périphérique a été initialisé et peut fonctionner correctement. Cela nécessite l'exécution de sa sonde de bus avant d'exécuter la sonde de device_driver. Le processus de suppression est inversé.
Remarque 1 : Tous les bus ne nécessitent pas de sonde et de suppression d'interfaces, car pour certains bus (comme le bus de plate-forme), il s'agit d'un bus virtuel lui-même. Il n'a pas besoin d'être initialisé et peut donc être utilisé directement par les pilotes de ces bus. are Les deux fonctions de rappel peuvent être laissées vides.L'arrêt, la suspension et la reprise ont des principes similaires pour sonder et supprimer. L'implémentation liée à la gestion de l'énergie ne sera pas expliquée pour le moment.
pm, la logique liée à la gestion de l'énergie ne sera pas encore expliquée.
iommu_ops, pas encore expliqué.
p, un pointeur de type struct subsys_private, nous l'expliquerons dans une section plus tard.
”
Cette structure est similaire à la struct driver_private dans device_driver. Elle est mentionnée dans le chapitre "Modèle de périphérique Linux (5)_device et pilote de périphérique", mais elle n'est pas expliquée en détail.
要说明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指针。
”
根据上面的核心数据结构，可以总结出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目录下
”
我们有在”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的处理逻辑：
- Allouez de l'espace pour le pointeur struct driver_private (priv) du pilote, initialisez les priv->klist_devices, priv->driver, priv->kobj.kset et d'autres variables, et enregistrez le pointeur en p de device_driver
- Définissez le kset du pilote (priv->kobj.kset) sur le kset des pilotes du bus (bus->p->drivers_kset), ce qui signifie que tous les kobjects du pilote sont situés sous bus->p->drivers_kset (send/ sys/bus/ xxx/répertoire des pilotes)
- En utilisant le nom du pilote comme paramètre, appelez l'interface kobject_init_and_add pour enregistrer le kobject du pilote dans sysfs, ce qui est reflété dans le répertoire /sys/bus/xxx/drivers/, tel que /sys/bus/spi/drivers/spidev
- Enregistrez le pilote dans la liste chaînée klist_drivers du bus et, en fonction de la valeur de drivers_autoprobe, choisissez d'appeler driver_attach pour la sonde
- Appelez l'interface driver_create_file et créez l'attribut uevent
dans le répertoire du pilote dans sysfs- Appelez l'interface driver_add_attrs et créez l'attribut par défaut défini par le pointeur bus->drv_attrs dans le répertoire du pilote dans sysfs
- En même temps, selon l'indicateur suppress_bind_attrs, décidez s'il faut créer des attributs de liaison et de dissociation dans le répertoire du pilote dans sysfs (pour plus de détails, veuillez vous référer à l'introduction dans "Modèle de périphérique Linux (5)_device et pilote de périphérique")
”
Dans "Modèle de périphérique Linux (5)_device et pilote de périphérique", nous avons introduit le timing et le processus de sonde du pilote. La plupart de la logique reposera sur l'implémentation du module de bus, principalement les interfaces bus_probe_device et driver_attach. De même, ces deux interfaces sont déclarées dans drivers/base/base.h et implémentées dans drivers/base/bus.c.
Le comportement de ces deux structures est similaire, et la logique est très simple, c'est-à-dire : rechercher le bus où il se trouve, et comparer s'il existe un périphérique_driver (ou périphérique) avec le même nom. Si oui, le périphérique. n'est pas lié à un pilote (remarque : c'est très important, grâce à lui, le même pilote peut piloter plusieurs périphériques portant le même nom (qui sera mentionné plus tard dans la description du périphérique Platform) et l'interface de sonde de device_driver est appelée .
Dans l'ancienne version du noyau Linux (en prenant comme exemple la version linux2.6.23 du noyau utilisée par Wowo), tous les répertoires de niveau supérieur (y compris certains répertoires secondaires) sous sysfs appellent l'interface subsystem_register sous la forme de sous-système Registered au noyau, tel que :
«
/sys/bus/
/sys/appareils/
/sys/devices/system/
/sys/block
/sys/noyau/
/sys/dalle/
…
”
L'implémentation de subsystem_register à cette époque était très simple, il s'agissait d'appeler kset_register pour créer un kset. On sait que kset est une collection de kobjects et sera présenté sous la forme d'un répertoire dans sysfs.
Dans la nouvelle version du noyau (comme linux3.10.29 référencé dans la série d'articles "Linux Kernel Analysis"), l'implémentation du sous-système a beaucoup changé, par exemple : l'interface subsystem_register a été supprimée (mais afin de être compatible avec le sous-système /sys/device/system Le système, dans drivers/base/bus.c, ajoute une interface interne de subsys_register pour implémenter les fonctions correspondantes). Selon ces changements, il existe désormais deux manières d'enregistrer le sous-système :
Méthode 1 : Dans leurs fonctions d'initialisation respectives, appelez l'interface kset_create_and_add pour créer le sous-système correspondant, comprenant :
其中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。
在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, deux fonctions de rappel, les fonctions principales de l'interface du sous-système. Lorsqu'un périphérique est ajouté ou supprimé sous le bus, le cœur du bus appellera le rappel add_dev ou remove_dev de toutes les interfaces du sous-système sous celui-ci. Les concepteurs peuvent implémenter les fonctions requises dans ces deux fonctions de rappel, comme lier le pilote correspondant à la « fonctionnalité spécifique », etc.
”
La logique d'implémentation de l'interface du sous-système est relativement simple et ne sera pas décrite en détail ici. Pour plus de détails, veuillez vous référer au code correspondant dans "drivers/base/bus.c". De plus, lors de l'analyse ultérieure du framework cpufreq, nous rencontrerons des exemples d'utilisation de l'interface subsys. Nous comprendrons ensuite davantage sa signification pratique.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
