On Do, 23.05.19 11:56, Stanislav Angelovič (angelovi...@gmail.com) wrote: > Hi Lennart, > > Sorry for a bit late reply, I've been quite busy recently. > > > So we could readd the ability to create a bus message with a NULL bus, > > but I am a bit concerned that people then always pass NULL which might > > ultimately result in constant remarshalling if the message is > > eventually enqueued on a real bus. When you put together a message it > > actually matters which bus connection you do that for... > > My proposal is that we would allow passing NULL bus ptr only for > `sd_bus_message_new` function. And such a message would be disallowed from > enqueuing. In functions that need real bus ptr we might place an assert > that bus != NULL. In a limited set of functions, which I mentioned in > previous e-mail (`sd_bus_message_seal` for example), we would allow bus == > NULL.
Prepare a patch that does this. If it's minimal and doesn't litter the API with too many new calls, that should be OK. (Note that due to the demise of kdbus, gvariant-over-dbus never really materialized in the end, hence the logic in sd-bus that can generate either is kinda dead. There's hope though that dbus-broker might add this eventually, not sure where that went though. In general I think it would make a ton of sense to switch to gvariant for everything, it just needs somebody to hack it up in dbus-daemon/dbus-broker) > OK, I will try. So we don't introduce any new message factory function > without bus parameter, but make use of existing `sd_bus_message_new`, > right? We will modify it to allow NULL bus ptr. However, this function > needs three things from the bus when initializing message: > `message_version`, `can_fds`, and `allow_interactive_authorization`. What > values shall we use there when bus is NULL? there never was any other version than 1, and fds are off. the allow a_i_a stuff should probably left off, as it doesn't really matter for most cases. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel