[systemd-devel] Compatibility between D-Bus and kdbus

[David Herrmann]

Hi

On Tue, Nov 25, 2014 at 8:27 PM, Thiago Macieira <thiago at kde.org> wrote:
> On Tuesday 25 November 2014 17:19:41 Lennart Poettering wrote:
>> On Mon, 24.11.14 18:40, Thiago Macieira (thiago at kde.org) wrote:
>> > Another thought that comes to mind: should we reserve the entire highest
>> > bit in connection IDs for broadcasts? It would allow for the existence of
>> > multicast groups in the future.
>>
>> I discussed this quickly with the kdbus guys, and while none of us was
>> thrilled about the posibility of introducing such a concept we all
>> agreed that if it should be introduced one day it really should be
>> part of the well-known names concept, not the unique names
>> concept. Meaning: you'd put a label on a group, and join the group by
>> the label then, rather than via numeric ids...
>>
>> In general, numeric ids are about being automatic, and well-known
>> names are about discoverability. But mcast memberships should never be
>> automatic, but only about discoverability, hence using unique ids for
>> identifying them sounds wrong.
>
> Agreed that mcast memberships should not be automatic. Just like IPv4 and
> IPv6, joining a multicast group requires placing a request.
>
> I was thinking more on the fact that 802 MAC addresses have a bit to indicate
> multicast/broadcast data.
>
> Can I suggest the following two changes to kdbus.txt when it comes to
> connection IDs:
>
> 1) remove the part that the numbers are not reused
> 2) say that the highest bit is reserved for future purposes

ID allocation is already done by the kernel. There is no reason to
reserve anything. We never hand out IDs with the highest bit set (IDs
are sequential, you will never trigger 2^63 IDs).

At any time, we can reserve any unique-ID to be special-purpose. For
instance, we can later decide to reserve 2^64-2 to be
KDBUS_DST_ID_MULTICAST to denote multicast messages that have the
multicast group as destination name.

I don't see why we should force clients to assume no-one ever gets IDs
assigned with the highest bit set. I don't want clients to assume any
magic behavior on IDs. Clients should never place any assumptions on
IDs that weren't advertised to them.

Thanks
David