Missing fan present object in fansensor (and expected usage of object manager)
Lei Yu
yulei.sh at bytedance.com
Fri Dec 2 00:38:17 AEDT 2022
This email is to discuss an issue found in fansensor service, and
about the expected usage of object manager.
# The issue
With upstream dbus-sensors (7627c86), the fan-present objects are
missing on DBus.
The fansensor service should create objects like
`/xyz/openbmc_project/inventory/fan0` to represent the fan presence
status [1].
However, with the changes of "fixing the ObjectManager in the right
place"[2], it creates an object manager with
`/xyz/openbmc_project/sensors` instead of `/`, and the objects created
on different object paths are actually not created anymore.
I see there is a fix for the "control" objects in the fanensor[3], but
the fan-present objects are still missing.
The fix is simple that we could add an extra object manager on
`/xyz/openbmc_project/inventory/`.
# Expected usage of object manager
But that involves extra object managers.
For a service that creates objects on different paths (e.g. sensors,
control, inventory), should it really create different object
managers?
The caller of such service (e.g. bmcweb) usually calls
`GetManagedObjects` to the object manager interface to get the
objects. In the above case, it has to call `GetManagedObjects`
multiple times on different paths.
So the question is, what is the *expected* and *proper* way to use
object manager for such case?
[1]: https://github.com/openbmc/dbus-sensors/blob/master/src/TachSensor.cpp#L77
[2]: https://github.com/openbmc/dbus-sensors/commit/14ed5e99
[3]: https://github.com/openbmc/dbus-sensors/commit/d9067251
--
BRs,
Lei YU
More information about the openbmc
mailing list