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