Re: DBus ObjectManager Interface usages within the project

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]