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

[Patrick Williams]

On Wed, Oct 30, 2024 at 02:49:40PM -0500, Matt Spinler wrote:
> > This is very strange.  I don't know why mapper would be creating
> > these interfaces on objects that don't exist.  It would be reasonable to
> > create these on the association objects, since those are actually being
> > created by mapper.
> 
> Looks like  every D-Bus service works the same way - if the path only 
> has the 3 interfaces,
> then the GetAll properties method doesn't work:
> 
> ```
> # busctl introspect xyz.openbmc_project.Software.BMC.Updater 
> /xyz/openbmc_project
> NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
> org.freedesktop.DBus.Introspectable interface -         - -
> .Introspect                         method    -         s -
> org.freedesktop.DBus.Peer           interface -         - -
> .GetMachineId                       method    -         s -
> .Ping                               method    -         - -
> org.freedesktop.DBus.Properties     interface -         - -
> .Get                                method    ss        v -
> .GetAll                             method    s         a{sv} -
> .Set                                method    ssv       - -
> .PropertiesChanged                  signal    sa{sv}as  - -

Hmm.  You're right.  I guess I wasn't aware that each segment along the
path, the dbus framework automatically inserts these objects.

I see the same thing from systemd.

If I examine `/org/freedesktop/systemd1/unit/graphical_2dsession_2etarget`,
the whole chain down to even `/` has those 3 interfaces.

> # busctl call xyz.openbmc_project.Software.BMC.Updater
>   /xyz/openbmc_project org.freedesktop.DBus.Properties
> GetAll s org.freedesktop.DBus.Properties
> 
> Call failed: Unknown object '/xyz/openbmc_project'.
> 
> ```
> 
> 
> >
> > Why is mapper creating interfaces anywhere except where the association
> > itself lives?  I don't think deleting the "DefaultInterfaces" is
> > necessarily appropriate because those interfaces _should_ be created on
> > the association leaf, but elsewhere in the hierarchy they don't belong.
> >
> > On my system if I introspect the `/xyz/openbmc_project/software/XXXX` in
> > mapper, I see only the 3 `org.freedesktop.DBus` interfaces.  If I
> > introspect the `/xyz/openbmc_project/software/XXXX/software_version` I
> > see those 3 plus an `xyz.openbmc_project.Assocation` interface.  Only
> > the `.../software_version` one should have the `org.freedesktop.DBus`
> > interfaces.
> >
> > What I don't know is if this code you've changed is where those
> > interfaces are created (probably not).  So your change might not be
> > appropriate for solving the underlying issue, which is that we have
> > interfaces that don't belong being created on dbus independent from the
> > mapper response.
> >

So these interfaces are legitimate.  Why do we want mapper to filter
them?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20241030/baadbdb1/attachment.sig>