dbus prefixes (was: DBus ObjectManager Interface usages within the project)

[Alexander Amelkin]

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'.

WBR, Alexander.

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 
> implementations.
>
> 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.
>