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. I think the 2 underlying problems you saw are bugs in both gdbus and sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is only about counting interfaces and properly detecting negative interface-counts. The gdbus bug is non-severe, though, since it originates in a buggy remote client. So there is no hard reason to change gdbus there. Thanks David _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
