DBus ObjectManager Interface usages within the project

Patrick Williams patrick at stwcx.xyz
Wed Jul 13 21:44:07 AEST 2022

On Tue, Jul 12, 2022 at 01:02:37PM -0700, Nan Zhou wrote:
> Ed brought up this issue that OM is optional as of today in inventories and
> sensors during the code review of
> https://gerrit.openbmc.org/c/openbmc/bmcweb/+/53824. The path of the OM is
> also inconsistent.

I don't think "OM is optional" is really a true statement.  It is
optional from a dbus perspective, true, but practically speaking all of
our daemons have it (just at an inconsistent location).  One of the
primary features of the object manager is to emit the signals for
managed objects, such as PropertiesChanged.  If you don't have an object
manager you don't get those signals.  We have to have that on Sensors,
at least, and I'm pretty sure everyone adds them for Inventory as well.

As you're seeing, there are typically two behaviors of implementation:

1. Anything using ASIO places OM at the root by default.
2. Anything using PDI-bindings places the OM at the lowest common part
   in their hierarchy.  (Something like /xyz/openbmc_project/sensors or
   /xyz/openbmc_project typically).

Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220713/050e66d8/attachment-0001.sig>

More information about the openbmc mailing list