Using D-Bus well-known service names and deprecating mapper service lookups

[Brad Bishop]

On Thu, 2019-04-11 at 23:47 -0400, Andrew Jeffery wrote:
> 
> On Fri, 12 Apr 2019, at 01:21, Andrew Geissler wrote:
> > On Thu, Apr 11, 2019 at 12:03 AM Andrew Jeffery <andrew at aj.id.au>
> > wrote:
> > > 
> > > I'm kicking this thread off because it's something that's
> > > bothered me for a while. I've complained about it to various
> > > people in private but have never taken it any further. My
> > > impression is that there's support for the idea that we move away
> > > from the mapper for service lookups (though we can't eliminate it
> > > entirely, we still need the interface reverse mapping feature), 

I'd like to eliminate the mapper entirely someday, if we can.  Can you
elaborate on why you think we can't?  I'm not sure I understand what
you mean by the interface reverse mapping feature.

> > > and I want to gauge how much support it has and whether there are
> > > solid counter-arguments.
> > 
> > Thanks for getting this started. Definitely something that's been
> > bothering me more and more lately as some of the issues you've
> > noted
> > above have become more prevalent. I agree that I'd like to
> > transition
> > away form GetObject usage in our process's. I'd be interested in
> > the
> > history from Brad on the reasons this was initially created and
> > whether they are still relevant though.
> 
> Great! Yeah, I think getting Brad's input is important here.

Doing lookups based on well-known bus names would make DBus programming
in OpenBMC more like DBus programming on the desktop, and that is a win
IMO.

FWIW the mapper was conceived (back in 2015) as a means to provide
flexibility in where (which process) objects are implemented, yet still
enable client reuse across those different implementations.  Want to
implement all your sensors in a single application?  No problem.  Want
to implement one application for each type of sensor?  No problem. 
Want to implement an application for every sensor instance?  No
problem.

Here is another way to look at it.  If we start applying a schema to
the well-known bus name as is normal in desktop-land, what would the
scope be?  Consider sensors.  You could have either specific or general
scope e.g. bus names like:

xyz.openbmc_project.sensors (general)

-or-

xyz.openbmc_project.nvme (specific)

In the case of the former, every sensor in a system has to be
implemented by a single process.  That isn't workable is it?

In the case of the latter, every client application looking for sensors
in the general sense (it doesn't care that it is a sensor on an nvme
drive that talks nvme-mi over i2c) has to introspect this bus, along
with every other bus to find any objects that implement a sensor
interface.

OpenBMC still needs a way to address these issues today - that hasn't
changed I don't think.  Is the mapper the best possible solution? 
Probably not.

-brad