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