[systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()

[Lukasz Skalski]

On 12/12/2013 04:22 PM, Simon McVittie wrote:
> On 12/12/13 14:28, Lennart Poettering wrote:
>> kay and Daniel are working on changing the semantics of monitoring
>> entirely. Instead of turning monitoring on and off on an existing
>> connection they want this to be an entirely new connection type
>
> Colin Walters wanted to do this in dbus-daemon too (a separate
> /var/run/dbus/system_bus_monitor_socket that's only accessible by root,
> or something), but nobody has got round to it yet.
>

I didn't know nothing about above plans - new connection type in kdbus 
and /var/run/dbus/system_bus_monitor_socket in dbus, so support for 
eavesdrop seemed to be missing in libsystemd-bus for me (especially that 
at this moment busctl prints infos only about signals).

Thanks for explanations.

> Another possibility might be to make the eavesdropped stream obviously
> not the same thing as the normal D-Bus stream, for instance by wrapping
> it in pcap format as used by bustle(1) (as in my proof-of-concept
> dbus-daemon patches on
> <https://bugs.freedesktop.org/show_bug.cgi?id=60859>). bustle-pcap(1) is
> a standalone implementation of "connect, eavesdrop, produce a pcap
> stream" for traditional D-Bus, similar to dbus-monitor.
>
>> the
>> same way as "starter" (i.e. those which may be used to take a well-known
>> name and get notified when the service behind it needs to be activated)
>> connections are different from normal connections
>
> Please consider naming this differently: "starter" in the D-Bus
> Specification (e.g. DBUS_STARTER_ADDRESS) is something rather different.
> Maybe "placeholder"?
>
>> (Which would break compat wit traditional dbus I figure, but that should
>> be OK given that monitoring is a debugging feature anyway.)
>
> Yes, I think anyone using eavesdropping for purposes other than a
> debugging tool is wrong; when we added eavesdrop="true" to dbus-daemon,
> it broke compatibility with older client libraries anyway.
>
>      S
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>

-- 
Lukasz Skalski
Samsung R&D Institute Poland
Samsung Electronics
l.skalski at partner.samsung.com