Messages in this thread | | | Date | Wed, 5 Aug 2015 09:10:50 +0200 | Subject | Re: kdbus: to merge or not to merge? | From | David Herrmann <> |
| |
Hi
On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann <dh.herrmann@gmail.com> wrote: >> This is a bug in the proxy (which is already fixed). > > Should I expect to see it in Rawhide soon?
Use this workaround until it does:
$ DBUS_SYSTEM_BUS_ADDRESS="kernel:path=/sys/fs/kdbus/0-system/bus" ./your-binary
> Anyway, the broadcasts that I intended to exercise were > KDBUS_ITEM_ID_REMOVE. Those appear to be broadcast to everyone, > irrespective of "policy", so long as the "match" thingy allows it.
Matches are opt-in, not opt-out. Nobody will get this message unless they opt in.
> The bloom filter thing won't help at all according to the docs: bloom > filters don't apply to kernel-generated notifications.
Bloom filters apply to message payloads. Kernel notifications do not carry a message payload. Message metadata can be filtered for explicitly (without false-positives).
> So yes, as far as I can tell, kdbus really does track object lifetime > by broadcasting every single destruction event to every single > receiver (subject to caveats above) and pokes the data into every > receiver's tmpfs space.
Broadcast reception is opt-in.
Thanks David
| |