mapper: should it add "default interfaces" and is it valid to implement no interfaces on an object?

[Lei Yu]

On Thu, Oct 31, 2024 at 11:50 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Wed, Oct 30, 2024 at 03:00:01PM +0800, Lei Yu wrote:
>
> Based on the info from Matt, answering these questions.
>
> > So here are the questions:
> > 1. How to explain the above behavior of "D-Bus calls on default
> > interfaces", especially for 2 & 3?
>
> #2 seems like a bug in mapper?  When I run this on a sample from systemd
> I get good results:
>
> ```
> $ busctl --user call org.freedesktop.systemd1 /org/freedesktop/systemd1/unit org.freedesktop.DBus.Properties GetAll s org.freedesktop.DBus.Properties
> a{sv} 0
> ```

Yup, on objects created by mapper for association, I get this error:
```
# busctl call xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/software/c172a378 org.freedesktop.DBus.Properties
GetAll s org.freedesktop.DBus.Properties
Call failed: Unknown object '/xyz/openbmc_project/software/c172a378'.
```
I do not know how to fix this in mapper though.

>
> > 2. Should mapper add "default interfaces" for all the objects and
> > their parents? If yes, it adds extra interfaces that are not
> > implemented; If no, it misses some interfaces that an object really
> > implements.
>
> I don't know that it is adding "default interfaces" really.  This code
> you linked to seems to be "assume these default interfaces will exist
> because they are a requirement of dbus".  The code appears to be an
> optimization to be able to advertise the path (and contained objects)
> before the bus introspection is complete.
>
> So, I think this is valid, isn't it?
>
> > 3. Is it valid for a D-Bus service to implement no interfaces on an object?
>
> It appears that "no interfaces" isn't a thing.  "no interfaces other
> than the 3" is a thing.
>
> I'm not finding explicitly in the dbus specification[1] where Peer,
> Introspectable, and Properties are required (except that it is perhaps
> implied by the discussion about the Message Bus itself).  sd-bus appears
> to always add these though (you can find multiple references in the
> code)[2].
>
> Interestingly, another application I have running (Spotify) does *not*
> always have these 3 interfaces.  They're obviously using a different
> dbus library than sd-bus:
>
> ```
> $ busctl --user introspect org.mpris.MediaPlayer2.spotify /org/ayatana/NotificationItem
> NAME TYPE SIGNATURE RESULT/VALUE FLAGS
> $ busctl --user introspect org.mpris.MediaPlayer2.spotify /org/ayatana/NotificationItem/spotify_client
> NAME                                TYPE      SIGNATURE RESULT/VALUE                             FLAGS
> org.freedesktop.DBus.Introspectable interface -         -                                        -
> ...
> ```
>
> So, the "assumption" that mapper has is perhaps only valid for sd-bus
> and not for other dbus libraries.

Then how do you think about mapper? Should we keep the current "assumption"?
I want to keep mapper's current behavior, but filter the default
interfaces in bmcweb
(https://gerrit.openbmc.org/c/openbmc/bmcweb/+/74593), which is a
smaller change and does not break anything, and the "default
interfaces" do not provide any properties anyway.

>
> [1]: https://dbus.freedesktop.org/doc/dbus-specification.html
> [2]: https://github.com/systemd/systemd/blob/6e492ae98abd9500a4310653dec0c3fced66c7da/src/libsystemd/sd-bus/bus-objects.c#L2472
>
> --
> Patrick Williams


-- 
BRs,
Lei YU