[systemd-devel] sd-bus change that broke sdbus-c++

Stanislav Angelovič angelovic.s at gmail.com
Wed Jun 10 16:24:00 UTC 2020


Hi folks,

sdbus-c++, a C++ library on top of sd-bus, is based on plain sd-bus
messages to implement the concept of Variant type. Under plain message here
I mean one created via `sd_bus_message_new` with the type being
_SD_BUS_MESSAGE_TYPE_INVALID. We use such a message as a generic container
of serialized D-Bus data, from which we read and to which we write. More of
this, including an example, is explained in the mailing list thread spawned
a year ago:
https://lists.freedesktop.org/archives/systemd-devel/2019-May/042748.html.

That all of sudden stopped working with systemd 245.6. The reason is highly
likely this commit in systemd:
https://github.com/systemd/systemd/commit/a2dd991d0fde59dc0574bd4d0c1438f01dc0b8ff.
This commit changed `sd_bus_message_new` to be more strict and immediately
reject creating messages of type _SD_BUS_MESSAGE_TYPE_INVALID, whereas
before that case was allowed, as were also allowed a few serialization
operations upon such a message (the rest like enqueuing checked the type
and failed, naturally). That original behavior was a perfect match for our
need for plain sd-bus messages. I understand that this was based on
internal implementation of sd-bus, since as I checked the documentation
now, it instructs clients to use one of the method call, method return,
method error and signal types.

What would you suggest as a solution in this situation? Would it be
possible to get back to the original behavior? Or would you suggest
creating a new API method for creating plain messages? Any is fine for
sdbus-c++, but the latter is a little more difficult because we cannot
conditionally decide upon the behavior in our code based on the systemd
version, as 245 exhibits various behaviors depending on the minor version...

Thanks in advance for your help.

Stanislav.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200610/12d8ca32/attachment.htm>


More information about the systemd-devel mailing list