DbusVariant insufficient for complex tree entries

James Feist james.feist at linux.intel.com
Fri Oct 18 05:59:56 AEDT 2019


On 10/17/19 11:30 AM, Patrick Venture wrote:
> James;
> 
> I wanted to validate the problem I'm hitting reading the Association
> vector<tuple<s,s,s,>>:
> 
> using SensorMap = std::map<std::string, std::map<std::string, DbusVariant>>;
> 
> I'm using the SensorMap to read out the Association interface:
>   sensorMap.find("xyz.openbmc_project.Association.Definitions");
> 
> This is fine, as it holds a map<string, DbusVariant> --> except, it
> doesn't, because DbusVariant only holds the basic dbus types.  I was
> curious if there was a way you recommended to deal with this?
> 
> I could individually request that interface against the path and
> connection, introspect, and then use my own receiving structure - but
> it seems a waste to double-grab it.
> 
> I could add the complex type array(tuple<s,s,s,>) to DbusVariant to
> allow for this, but -- that seems a bit ugly.

This is all my opinion, but perfect world.. you would just always 
request the types that you think are possible. I think the 
implementation of DbusVariant has too many types as is, and is 
overused.. but this is  a common practice and adding the association 
type to DbusVariant is probably the best solution. Either that or 
reworking SensorMap to be a map<string, 
std::variant<types-that-we-care-about>>... but I wouldn't expect anyone 
to do that. I think the DbusVariant came to live because of the old 
namespace of the variant being so long, and people not wanting to have 
to type so much when they just wanted a variant.

fwiw phosphor-ipmi-host does the same thing with their Value type.

-James

> 
> Any suggestions?
> 
> Thanks,
> Patrick
> 


More information about the openbmc mailing list