Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
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. 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Lukasz Skalski Samsung RD Institute Poland Samsung Electronics l.skal...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
On Thu, 12.12.13 15:22, Simon McVittie (simon.mcvit...@collabora.co.uk) 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. 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? Well, the starter stuff is something that app developers will never see. It's just the backend for the .busname unit type, that's all, and people only get in contact with .busname units, nothing else. Thus I don't think that the name is a big issue. OTOH I don't mind renaming it in the Kernel either. Kay? Maybe call it activator instead? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
On Thu, Dec 12, 2013 at 6:59 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 12.12.13 15:22, Simon McVittie (simon.mcvit...@collabora.co.uk) 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. 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? Well, the starter stuff is something that app developers will never see. It's just the backend for the .busname unit type, that's all, and people only get in contact with .busname units, nothing else. Thus I don't think that the name is a big issue. OTOH I don't mind renaming it in the Kernel either. Kay? Maybe call it activator instead? Put it on my list. I'll rename it, as soon as stuff works again. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
