Using a struct[enum] as an sdbusplus D-Bus method arg?

[Patrick Williams]

On Thu, Jan 09, 2020 at 11:25:24AM -0600, Matt Spinler wrote:
> 
> 
> On 1/9/2020 10:22 AM, Patrick Williams wrote:
> > On Wed, Jan 08, 2020 at 01:32:49PM -0600, Matt Spinler wrote:

> Since the vectors are of different types, I think the code generated code
> would have to
> do the equivalent of?
> 
>     std::vector<std::tuple<std::string, uint8_t>> data{};
>     m.read(data);
> 
>     std::vector<std::tuple<Types, uint8_t>> apiData{};
> 
>     for (const auto& [arg0, arg1]: data)
>        apiData.emplace_back(convertStringToEnum(arg0), arg1))
>     o->createStuff(apiData);
> That's a pretty big change from what's there today.  Think that's possible
> to do generically?
> 

It seems like that is something that should have been done in the
`message::read` function.  First, since your initial data type is wrong
(that funny enum<...>), I think we need to figure out why this function
isn't working correctly:

https://github.com/openbmc/sdbusplus/blob/master/tools/sdbusplus/property.py#L72

It was suppose to have handled, through recursion, enums.  I would have
expected data's type to be vector<tuple<Interface::Types, uint8_t>>.
After that, I suspect you'll get compile errors that m.read doesn't know
how to handle an Interface::Types enum type.  This would require some
C++ template magic, but I think it could be handled there.  We need to
teach m.read to be able to call convertToMessage and convertFromMessage
if those exist.  I don't know why we originally did that lifting in the
from the generated code, except maybe that enums were bolted on later
and never fully complete?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200109/e0aa636b/attachment-0001.sig>