April 25, 2017 9:54 AM, "David Herrmann" <[email protected]> wrote:
> Hi > > On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman <[email protected]> wrote: > >> April 21, 2017 1:22 PM, "David Herrmann" <[email protected]> wrote: >>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman <[email protected]> wrote: >> >> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote: >> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman <[email protected]> wrote: >> I'm implementing a server which creates an ObjectManager using the >> sd-bus API and there seems to be some differences between how gdbus and >> sd-bus implements the API. >> >> I implemented a simple ObjectManager at /org/gnome/TestManager which >> exports objects /org/gnome/TestManager/fooX with interface >> org.gnome.TestManager.Device. >> >> Under sd-bus, if an object is removed, the following signal is >> generated: >> >> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination) >> serial=90 path=/org/gnome/TestManager; >> interface=org.freedesktop.DBus.ObjectManager; >> member=InterfacesRemoved >> object path "/org/gnome/TestManager/foo0" >> array [ >> string "org.freedesktop.DBus.Peer" >> string "org.freedesktop.DBus.Introspectable" >> string "org.freedesktop.DBus.Properties" >> string "org.freedesktop.DBus.ObjectManager" >> string "org.gnome.TestManager.Device" >> ] >> >> If I implement the same simple server in gdbus, the signal is instead: >> >> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination) >> serial=90 path=/org/gnome/TestManager; >> interface=org.freedesktop.DBus.ObjectManager; >> member=InterfacesRemoved >> object path "/org/gnome/TestManager/foo0" >> array [ >> string "org.gnome.TestManager.Device" >> ] >> >> The corresponding signals are also generated when an object is added. >> .... >> Does the appended patch fix your issue? >> (line-breaks might be screwed, sorry) >> >> Haven't tried it yet, but just from reading the patch...it seems to do >> the opposite of what I'd expect? I.e. add *more* interfaces? >>> This change makes sure all objects have the built-in interfaces >>> reported at all times. The GetManagedObjects() call didn't report them >>> so far. >> >> Quite the contrary? If you look at the output from dbus-monitor above, >> you'll see that it is sd-bus >> that already *does* report all interfaces while gdbus doesnt? > > No, it does not. sd-bus was inconsistent. See, there are 3 things > involved in the Object-Manager: > > Signal: InterfacesAdded > Signal: InterfacesRemoved > Call: GetManagedObjects > > The first two signals are used to add and remove objects (and their > respective interfaces) at runtime. The GetManagedObjects() call is > used to bootstrap, that is, to get the initial set of objects (and > their respective interfaces) when starting your application. > > So far, sd-bus reported the builtin interfaces correctly via the > signals, but did not return that information in the > GetManagedObjects() call. My patch fixed this omission. > The effect of this is that objects added/removed at runtime work fine, > but if an object was there already when your application starts, then > it will never be removed, since gdbus will see an interface-count > mismatch (as you observed above). > > Hence, the patch I provided fixes how sd-bus provides this > information. It does *not* change any policy. Oh, I see. Thanks. I'll try the patch ASAP. Regards, David _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
