LibXZR 的小本本 - openbmc
type: channel
link: https://blog.xzr.moe/tag/openbmc/
items: openbmc 之 entity-manager 是如何工作的

openbmc 之 entity-manager 是如何工作的
type: item
date: 2024-01-16T14:32:00+00:00
description: 前言文章基于 1e19c030559e84a42c98effa19e35665c7ae4b7c (2.16.0-dev) ，即截止文章撰写时的最新代码版本。这篇文章主要从我的视角记录了 entity manager 的工作过程，可能存在不准确的地方，还望补充修正。这篇文章之所以产生，是因为我发现了一个逻辑不通：就以其自带的 configurations/1ux16_riser.json 这样一个配置文件为例。在这个配置文件中，并没有指定这张卡挂在哪个总线上，所有总线相关的条目都是 $bus ，甚至连 eeprom 所对应的设备地址也都是 $address，而且，在相关 kernel devicetree 中，也没有任何与这张卡相关的总线和地址信息。那么，问题来了，是谁为 $address 和 $bus 填入了对应的地址？ I2C 不是不可探测的总线吗？那设备是怎么被扫描出来的？完全未知不就意味着驱动都没有？那设备又是怎么被识别出来的？设计架构在开始之前，先来介绍一下 openbmc 对于板卡管理的架构设计。总的来说，OpenBMC 的社区设计，将部件管理分为三大个模块：探测器配置管理器执行器“探测器”用于发现硬件设备并搜集这些设备的原始信息。这些原始信息将被推送至 dbus 上，供“配置管理器”之类的其它模块使用。“探测器”的典型代表是接下来要介绍的 fru-device ，当然，社区也有其它的“探测器”实现，比如 peci-pcie 。“配置管理器”负责将本地的配置文件与“设备原始信息”进行匹配，从而正确的识别这些设备并形成更加详细的设备配置信息。这些配置信息也将被推送至 dbus 上，供“执行器”之类的其它模块使用。“配置管理器”的典型代表是 entity-manager 。“执行器”有许多不同的种类。它们所做的事，是根据“配置管理器”挂在 dbus 上的信息，找出自己可以操作的设备，获取需要的信息，最后再将信息推回到 dbus 上。“执行器”的典型代表是 dbus-sensors 。也许你对上面所说的过程并没有什么概念，但是我们可以举个更详细的例子：“探测器”扫描到了一个硬件设备，但是只知道这个设备的 id 是 xxxx ，于是它将这个 id 推送到了 dbus 上。“配置管理器”根据这个 id ，结合本地的配置文件，确定了这到底是哪一张板卡。于是“配置管理器”便可以往 dbus 上推送与这张板卡有关的信息，比如它的名称、描述，它所带有的传感器地址等等。“执行器”根据“配置管理器”提供的传感器地址信息，读取传感器数据，最终又将数据推回到 dbus 上。由于所有数据都在 dbus 上，因此，需要获取信息的东西，如 bmcweb 提供的 redfish 接口，便可以轻松的从 dbus 上拿到任何想要的东西。用一张图来总结这个过程：包结构好了，了解了设计架构，接下来看看 entity-manager 这个包（配方）的结构。来看看它的编译产物：meson.build...... executable( 'entity-manager', 'entity_manager.cpp', 'expression.cpp', 'perform_scan.cpp', 'perform_probe.cpp', 'overlay.cpp', 'topology.cpp', 'utils.cpp', ...... ) ...... executable( 'fru-device', 'expression.cpp', 'fru_device.cpp', 'utils.cpp', 'fru_utils.cpp', 'fru_reader.cpp', ...... ) ...... 可以看到，entity-manager 虽然是一个包，但却会构建两个可执行文件，一个是 entity-manager ，另一个是 fru-device 。这两个可执行文件分别是由 xyz.openbmc_project.EntityManager.service 和 xyz.openbmc_project.FruDevice.service 独立负责启动的，两者在启动时并没有直接的依赖关系。从上面我们的架构分析可知，这两者，一个是“配置管理器”，另一个则是“探测器”。说句实在话，把 fru-device 放在这个包里其实并没有那么合适，倒是有种作为“探测器” demo 的感觉，它完全可以像 peci-pcie 一样自己起一个包。接下来，我们分别探一探这两个可执行文件，看看它们分别是如何工作的。fru-device概述先来概况一下这个可执行文件的工作内容：它需要在没有设备驱动的情况下扫描所有 i2c 总线下的每一个地址（实际上是指定范围的地址），如果发现地址上存在 FRU …