sdbusplus reading InterfacesAdded issue: not all variants are created equal

Paul Fertser fercerpav at gmail.com
Fri Dec 24 23:53:51 AEDT 2021


Hello Patrick,

Thank you for the prompt and elaborate response.

On Thu, Dec 23, 2021 at 10:24:30AM -0600, Patrick Williams wrote:
> > So what is the correct method of using statically-typed sdbusplus APIs
> > to parse such a "dynamic" reply?
> 
...
>  You could pretty easily add a `merge_variant` on top of this that
> would be the union of all the variant types.  Then, the type you'd
> pass into `msg.read` would be:
> 
>     using Value =
>         merge_variant<xyz::openbmc_project::Logging::Entry::PropertiesVariant,
>                       ...>;

Yep, I'll do that and submit a patch for phosphor-dbus-monitor after testing.

> You mentioned the InvalidEnum error.  I'd have to see what you were doing there
> but if you both an Enum-type and a std::string in the variant it should have
> parsed as a std::string if the Enum-matching was unsuccessful and not thrown an
> error.  I thought I had a test case for that exact scenario as well.  If you are
> seeing that, it sounds like a bug.

It is a bug all right, in the development processes of our company
where we primarily work with an outdated fork and it doesn't include
your a22dbf40a115d5cd133e67500afa387b317cac14 commit :/

Thank you for the clear hints, I'm working on doing the right thing to
test this now.

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


More information about the openbmc mailing list