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

[Brad Bishop]

On Mon, Apr 15, 2019 at 09:51:19PM -0400, Andrew Jeffery wrote:
>
>
>On Mon, 15 Apr 2019, at 12:23, Brad Bishop wrote:
>> 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.

Agreed.  FWIW in the past there was a heavy tendency to solve problems
that didn't necessarily exist yet.

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

Agreed.

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

It certainly can't hurt to have something like this.

>
>Cheers,
>
>Andrew