Re: sd-bus: Enabling free-standing, bus-independent plain messages

[Lennart Poettering <mznyfn@xxxxxxxxxxx>]

On Do, 23.05.19 11:56, Stanislav Angelovič (angelovic.s@xxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel