On Fri, 09 Jun 2017 at 15:20:49 +0200, Łukasz Stelmach wrote:
> We are developing a daemon that is monitoring a system. One of its
> sources of information is systemd. To avoid dependency on dbus-daemon
> (which may fail and cripple our daemon) the daemon connects to
> /run/systemd/private to listen to signals emitted by systemd. However,
> we don't need all signals, only a few. Thus we are going to create code
> which will filter and dispatch signals.
> We think the best place for such code is not our daemon but rather
> sd-bus. Our question is: would you accept the patch adding a signal
> filter/dispatcher for direct DBus connections? Do you have any
> recommendation for such functionality
Please don't call it a private *bus* unless it implements the full API of
the dbus-daemon, or at least something the same "shape" as that. D-Bus
terminology makes a distinction between connections to a server (one or
more clients connect to one server, which processes messages itself) and
to a bus (clients connect to a server/broker/hub in the middle of a star
topology, the "message bus", and the message bus in the middle forwards
messages between clients and implements the standard org.freedesktop.DBus
APIs, including signal subscriptions and name ownership). As far as I'm
aware, /run/systemd/private is not a bus in those terms: clients that
connect to it can talk directly to systemd, but cannot talk to each
other. A private or direct D-Bus *connection* seems a better term.
The device nodes in kdbus were effectively buses, although using
ioctls instead of the org.freedesktop.DBus interface - they delivered
messages between clients, mediated name ownership and so on. I don't
think kdbus had an equivalent of private/direct D-Bus connections.
Receiving signals on a private/direct connection with the equivalent
of g_dbus_connection_signal_subscribe() seems like a reasonable thing
for sd-bus to have, if its maintainers want that. I think GDBus'
g_dbus_connection_signal_subscribe() works fine on private/direct
connections if you pass in G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE.
However, are you also proposing writing a reimplementation of
the dbus-daemon's signal subscription matching as configured
by AddMatch(), and running it on the service side, so
in this case in systemd? Or are you confusing client-side
subscription (e.g. g_dbus_connection_signal_subscribe() with
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE) with bus-side filtering (adding
match rules)?
If you are considering reimplementing signal subscription, I would
recommend first benchmarking the most naive possible implementation (a
connection is either subscribed to all signals from systemd or no signals,
and ignores the unwanted ones client-side). I suspect you might find that
doing the filtering client-side is not a performance problem in practice;
depending how optimal the server-side filtering implementation is,
server-side filtering might even end up more "expensive" than just
delivering everything and requiring clients to cope, because D-Bus
signal subscription is a lot more general-purpose than what would
be useful to you in this situation in practice.
If you do find that you need server-side filtering, I think I'd prefer it
if you used a non-standard interface name for your signal subscription
mechanism (so org.freedesktop.systemd1.Manager.AddMatch() or something
rather than org.freedesktop.DBus.AddMatch()), although clearly you're
welcome to use the same syntax for subscriptions that AddMatch uses.
I would prefer not to cloud the distinction between connections and
buses by implementing subsets of the org.freedesktop.DBus interface on
non-buses: each connection should either be direct, or a full bus.
A much simpler subscription language (some sort of middle ground between
the simplicity of o.fd.systemd1.Manager.Subscribe() and the complexity
of o.fd.DBus.AddMatch()) might be another option.
S
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
