Towards less magic strings.

[Patrick Williams]

On Thu, Sep 14, 2023 at 10:33:10AM -0400, Brad Bishop wrote:
> On Thu, 2023-09-14 at 01:36 -0500, Patrick Williams wrote:
> > 
> > ## Service Names
> > 
> > I think it should be rare that you need a hard-coded service name in
> > your code, since typically you'll want to do some kind of mapper 
> 
> I would actually propose the opposite - we should use mapper lookups as
> a last resort and prefer hard-coded service names.  Mapper lookups add
> latency, and require developers to have OpenBMC specific domain
> knowledge to do something that should otherwise be simple and well
> documented.  Mapper indirection also prevents the use of dbus
> activation, which drastically simplifies service dependencies.

I do like dbus activation when we can and do think it would be
beneficial to transition to it where appropriate.  I don't think
anything I've added would get in the way (except possibly that
opinionated statement you quoted here).  You can certainly document
service name(s) in the YAML with the support I've added.

I'm not positive how we get to what you're proposing from where we are at
though.  There are a good number of dbus interfaces that are anticipated
to exist in multiple daemons.  Sensors, inventory, software versions.  I
don't know how "interfaces should live in a single process" meshes with
support for PLDM, Redfish aggregation, and multi-host designs.

Maybe you could have a dbus-activated service for
"xyz.openbmc_project.Sensors", which the providing service for that
in turn has drop-in dependencies installed by all the sensor
providers (ie. sensors.wants.d has files installed by each package).
I'm not sure how a dbus client finds all these services, unless we have
a set of registered daemons to look for, but that seems to be just as
latent as mapper and precludes non-open daemons.

Do you have more thoughts on how we can solve some of these intrinsically
dynamic interfaces?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230915/c5ff67bf/attachment.sig>