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

[Andrew Jeffery]

On Mon, 15 Apr 2019, at 12:23, Brad Bishop wrote:
> 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.

Your discussion below is what I was talking about, probably just poor
terminology on my part.

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

So I think you've painted a reasonable picture of the problem here,
however I also think that the solution to this specific problem has
been over-generalised to the point of pervasive use in OpenBMC,
and my argument is I don't think that's necessary.

Backing up, the motivation for this thread was that I wanted to know
whether phosphor-ipmi-host had got to the point of being considered
"on the bus". I knew we had the mapper-wait@ systemd service that
several units already used, so I gave that a go, and found that it didn't
behave as I expected (as outlined in the original message). From there
I moved on to poking at systemd and dbus-activation. The point is that
we're using the mapper in a lot of places where it should be
unnecessary. Having a well-defined schema and hence a well-known
bus name for ipmid doesn't seem too far fetched. The practical reality
of the implementation is it's done as a single process.

I'm not arguing that we eliminate the mapper entirely, your scenario
above does a good job of motivating its existence. I'm just arguing that
we should rely on it less, and do a better job of defining what services
should have the benefit of a well-known bus names, as this enables
reliable dependency management without hacks like mapper-wait at .

Maybe we could put together a list of what could benefit from well
known bus names and what requires the mapper? Might help us
understand the scope and whether any of this is a useful idea.

Cheers,

Andrew