[systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hi

On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman <david at hardeman.nu> wrote:
> April 21, 2017 1:22 PM, "David Herrmann" <dh.herrmann at gmail.com> wrote:
>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman <david at hardeman.nu> 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 <david at hardeman.nu> 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