sdbusplus reading InterfacesAdded issue: not all variants are created equal

[Paul Fertser]

Hello,

While digging into current state of SNMP notifications (traps) support
in OpenBMC I found some code I have no idea how to properly improve.

phosphor-dbus-monitor has a handler that's meant to be called whenever
a new log entry is created by monitoring InterfacesAdded signals on
D-Bus logger paths. The processing is at

https://github.com/openbmc/phosphor-dbus-monitor/blob/master/src/snmp_trap.cpp#L28

It seems OK until you look into PathInterfacesAdded definition which
includes a hard-coded std::variant<>:
https://github.com/openbmc/phosphor-dbus-monitor/blob/master/src/data_types.hpp#L66

This already raises suspicions and rightfully so: the interface we're
specifically interested in, xyz.openbmc_project.Logging.Entry,
includes AdditionalData property which should be of type
std::vector<std::string> , but that's not in the list of the allowed
hardcoded variants.

If I'm trying to use the std::variant<> type suitable for
Logging.Entry then msg.read() fails with InvalidEnum error, probably
trying to parse data about other interfaces, and this is a bad idea
anyway.

So what is the correct method of using statically-typed sdbusplus APIs
to parse such a "dynamic" reply?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com