[SSSD] Design Discussion: Support for multiple D-Bus interfaces on single object path

Stef Walter stefw at redhat.com
Thu Nov 13 15:39:05 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My opinion: I would suggest not exposing this concept/code struct
outside of src/sbus/

Callers should just sbus_conn_add_interface(). If two interfaces have
the same object path, it just works ...

Internally when dispatching calls, the interface+path is taken into
account when walking the conn->intf_list.

FWIW, at some point, once you start exporting many many interfaces
(irregardless of which paths they're at) conn->intf_list is ripe for a
hash table of some sort.

Stef

On 13.11.2014 12:43, Pavel Březina wrote:
> CC-ing Stef
> 
> On 11/11/2014 09:42 PM, Pavel Brezina wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Jakub Hrozek" <jhrozek at redhat.com> To:
>>> sssd-devel at lists.fedorahosted.org Sent: Tuesday, November 11,
>>> 2014 9:04:23 PM Subject: Re: [SSSD] Design Discussion: Support
>>> for multiple D-Bus interfaces on single object path
>>> 
>>> On Tue, Nov 11, 2014 at 08:34:04PM +0100, Jakub Hrozek wrote:
>>>> On Tue, Nov 11, 2014 at 05:55:57PM +0100, Pavel Březina
>>>> wrote:
>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusMultipleInterfaces
>>>>
>>>>
>>>>> 
For convenience, I'm pasting the full design page text below:
>>>> 
>>>> = Support for multiple D-Bus interfaces on single object path
>>>> =
>>>> 
>>>> Related ticket(s): *
>>>> [https://fedorahosted.org/sssd/ticket/2339 IFP: support
>>>> multiple interfaces for object]
>>>> 
>>>> == Problem Statement ==
>>>> 
>>>> Currently our D-Bus implementation supports having only one
>>>> interface registered per one object path prefix. This can be
>>>> rather limiting feature since it is often useful to separate
>>>> shared methods and properties under one interface that can
>>>> even have the same implementation for different object types.
>>>> This will soon become a serious drawback when the Infopipe 
>>>> starts supporting signals and new objects. SSSD already
>>>> supports few specialized interfaces such as DBus.Properties
>>>> and DBus.Introspectable but those are currently hardcoded to
>>>> the S-Bus dispatching logic which can be avoided with direct
>>>> support for multiple interfaces.
>>>> 
>>>> == Current state ==
>>>> 
>>>> The D-Bus interface in the !InfoPipe is defined by a
>>>> sbus_vtable structure and associated with a single object
>>>> path or an object path prefix followed by '*' wildcard. For
>>>> example the current list of !InfoPipe interfaces looks as
>>>> follows:
>>>> 
>>>> {{{ static struct sysbus_iface ifp_ifaces[] = { {
>>>> "/org/freedesktop/sssd/infopipe", &ifp_iface.vtable }, {
>>>> "/org/freedesktop/sssd/infopipe/Domains*", &ifp_domain.vtable
>>>> }, { "/org/freedesktop/sssd/infopipe/Components*", 
>>>> &ifp_component.vtable }, { NULL, NULL }, }; }}}
>>>> 
>>>> There is only one allowed wildcard '*' and if present it has
>>>> to be the last character of the object path.
>>>> 
>>>> The dispatch logic is:
>>>> 
>>>> 1. Lookup the vtable by object path from the message 2. Check
>>>> that the interface name is the same as the interface define 
>>>> in the message, if not check if the interface in the message
>>>> is one of the hard coded interfaces 3. Fail if the interface
>>>> is invalid 4. Find and execute the method handler
>>>> 
>>>> == Proposed solution ==
>>>> 
>>>> The structure sysbus_iface combines an object path (pattern)
>>>> and a list of supported interfaces on this object path.
>>>> 
>>>> There can still be only one supported wildcard and that is
>>>> '*' but it is possible to use it everywhere and multiple
>>>> times in one object path.
>>>> 
>>>> The dispatch logic is:
>>>> 
>>>> 1. Acquire interface and object path from D-Bus message 2.
>>>> Find an object path pattern that matches the object path from
>>>> the message, if more than one such pattern exist then the
>>>> first one defined is used
>>> 
>>> Can you remind me (sorry, I don't remember the code anymore and
>>> I'm busy with other work atm) if these structures are
>>> generated? If so, then first match sounds a bit dangerous, just
>>> moving around some code or changing the codegen would make sssd
>>> use a different interface.
>> 
>> No, this is outside the generated code. I don't expect any
>> changes in the codegen.
>> 
>>> Should we use some 'best match' instead (more wildcards matched
>>> or something like that) ?
>> 
>> I thought about that but I think it is not worth it to code a
>> best match algorithm. At least not at the moment. I would rather
>> wait until the InfoPipe is more mature so we can say what
>> approach is the best for such algorithm since you can define best
>> match in several ways.
>> 
>>> 
>>>> 3. Find a list of interfaces associated with this object
>>>> path pattern, if not found continue with next pattern that
>>>> matches 4. Execute a message handler that is associated with
>>>> both object path and interface
>>> 
>>> It would be helpful if you could provide an example like above,
>>> I'm afraid it's not easy for me to visualize the matching
>>> flow.
>>> 
>>>> 
>>>> == Authors ==
>>>> 
>>>> * Pavel Březina <pbrezina at redhat.com> 
>>>> _______________________________________________ sssd-devel
>>>> mailing list sssd-devel at lists.fedorahosted.org 
>>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>> _______________________________________________ sssd-devel
>>> mailing list sssd-devel at lists.fedorahosted.org 
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>> 
>> _______________________________________________ sssd-devel
>> mailing list sssd-devel at lists.fedorahosted.org 
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlRk0JkACgkQe/sRCNknZa+kTgCdFDWWJkp0Nu7Hic+krYBK5Ipp
tbwAni/9KuW00j9D2Y+LqWVTGXMBjLDf
=WW/9
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list