You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
How to create two (or more) interfaces with the same name #103
I have a case where I have to create two interfaces with the same name, but with different properties (these interfaces are exposed on different paths). Basically I have two options: a) create one class which will return properties based on exposed path (some props are optional) b) create two classes with the same interface name. Unfortunately, both these solutions are not possible right now.
In case of option a) the limitation seems to be imposed by libsystemd. It's not possible to define property as "optional", i.e. when property is not available, the org.freedesktop.DBus.Properties.GetAll does not return value for such property and org.freedesktop.DBus.Properties.Get returns org.freedesktop.DBus.Error.InvalidArgs: No such property 'Name'. The problem is that the sd_bus_emit_interfaces_added_strv() function collects all properties internally and in case when property value getter fails, the entire sd_bus_emit_interfaces_ added_* call fails. There are some possibilities like libsystemd-specific PropertyExplicitFlag flag, but this conflicts with PropertyEmitsChangeFlag. So, such approach is not ideal.
For option b) the problem is with sdbus internals where parse_properties_changed uses global DBUS_INTERFACE_NAME_TO_CLASS mapping... Would it be possible to remove internal mapping in favor of user provided list of interfaces? This function takes interface argument but does not use it...
For option b) the problem is with sdbus internals where parse_properties_changed uses global DBUS_INTERFACE_NAME_TO_CLASS mapping... Would it be possible to remove internal mapping in favor of user provided list of interfaces? This function takes interface argument but does not use it...
There is an alternative implementation idea I had on how to store the interface metadata without global variables but I really don't want users to create same interface names with different implementations. Maybe I should make it emit a large warning instead of completely preventing it. Seems like a lot of legacy code likes to have duplicated interface names.
In case of option a) the limitation seems to be imposed by libsystemd. It's not possible to define property as "optional", i.e. when property is not available, the org.freedesktop.DBus.Properties.GetAll does not return value for such property and org.freedesktop.DBus.Properties.Get returns org.freedesktop.DBus.Error.InvalidArgs: No such property 'Name'. The problem is that the sd_bus_emit_interfaces_added_strv() function collects all properties internally and in case when property value getter fails, the entire sd_bus_emit_interfaces_ added_* call fails. There are some possibilities like libsystemd-specific PropertyExplicitFlag flag, but this conflicts with PropertyEmitsChangeFlag. So, such approach is not ideal.
The vtables can't really be modified once created but sd-bus also supports fully callback based objects. (see sd_bus_add_object) The obvious downside that you will have to re-implement the entire properties, ping and other logic that vtable automatically provides.
I agree that everything here is a workaround for something else. IMHO, the proper solution for a) would be a logic within libsystemd which will allow skipping adding property to the InterfacesAdded when getter returns some value indicating that the value is not available right now. However, it looks that the optional property "feature" is not something that D-Bus specification covers... so I'm not blaming libsystemd that it lacks such functionality.
Activity
igo95862 commentedon Apr 15, 2025
Hello @arkq
There is an alternative implementation idea I had on how to store the interface metadata without global variables but I really don't want users to create same interface names with different implementations. Maybe I should make it emit a large warning instead of completely preventing it. Seems like a lot of legacy code likes to have duplicated interface names.
igo95862 commentedon Apr 16, 2025
The vtables can't really be modified once created but sd-bus also supports fully callback based objects. (see
sd_bus_add_object) The obvious downside that you will have to re-implement the entire properties, ping and other logic that vtable automatically provides.arkq commentedon Apr 16, 2025
I agree that everything here is a workaround for something else. IMHO, the proper solution for a) would be a logic within libsystemd which will allow skipping adding property to the
InterfacesAddedwhen getter returns some value indicating that the value is not available right now. However, it looks that the optional property "feature" is not something that D-Bus specification covers... so I'm not blaming libsystemd that it lacks such functionality.igo95862 commentedon Apr 16, 2025
Do you want to open systemd issue about it?