dbus prefixes (was: DBus ObjectManager Interface usages within the project)
a.amelkin at yadro.com
Wed Jul 13 20:17:10 AEST 2022
As a side note to this discussion, have we considered using shorter and
more convenient paths for dbus?
I don't see any real reason for the project to be using this long and
cumbersome /xyz/openbmc_project/ prefix.
Why not use just '/obmc/' or `/phosphor/` ? I believe that would be more
than enough to separate all our services from any third-party ones on d-bus.
I understand why this prefixing is for in 'big' open desktop or server
systems where there on d-bus can be any number of software from any
number of vendors. In an embedded system, such as OpenBMC, on the
contrary, the set of software using d-bus is strictly limited and we
always know beforehand what prefixes are used. I'm pretty sure none of
the software included into OpenBMC builds will ever use '/obmc' prefix.
So why continue using the inconvenient long prefixes when it is safe to
use short ones? I would even propose dropping all prefixes at all, but
ok, let's pretend that there can be some other 3rd-party 'Inventory'
than '/obmc/' ('/xyz/openbmc_project/').
Am I wrong or missing anything? What's stopping us from switching to a
shorter prefix, aside from the existing code that will need to be
changed to it?
The same proposal/question actually applies to service names (e.g.
xyz.openbmc_project.ObjectMapper could easily become just
obmc.ObjectMapper or phosphor.ObjectMapper), let alone just 'ObjectMapper'.
12.07.2022 21:48, Ed Tanous пишет:
> We've had a couple cases in the project where patches have needed to
> be slowed down because of inconsistencies in our use of object
> manager, so IMO, the time has come to make our usage of ObjectManager
> consistent, documented, and drop support for the (not upstream)
> daemons that don't follow the rules. As part of this, we will port
> forward all the upstream daemons to be consistent, and do our best to
> avoid bugs, but this email is intended to inform those that have
> non-upstream daemons about the change so they can resolve their
> The basics:
> ObjectManager DBus interface will now be required for any daemon
> implementing a Sensor.Value interface or Inventory.Item interface.
> Daemons producing sensors will be required to place their
> ObjectManager at /xyz/openbmc_project/sensors
> Daemons producing inventory items will be required to place their
> ObjectManager at /xyz/openbmc_project/inventory.
More information about the openbmc