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

Matt Spinler mspinler at linux.ibm.com
Tue Jan 14 05:59:26 AEDT 2020



On 1/9/2020 1:03 PM, Patrick Williams wrote:
> 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?
>

To go from enums to strings, there is a convertForMessage() function, 
but to go from
strings back to the enums, which is what we need, the function has the 
enum name in it:
      convert<enum name>FromString(const std::string& s);

I don't think it's possible for message::read() to know that?





More information about the openbmc mailing list