Re: [systemd-devel] Compatibility between D-Bus and kdbus
David Herrmann <[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <CANq1E4Tn4EmMps7jymBuc2ZOKLC6+4KDhbhxYjimyWRAG810DA@mail.gmail.com> |
Hi On Tue, Nov 25, 2014 at 8:27 PM, Thiago Macieira <[email protected]> wrote: > On Tuesday 25 November 2014 17:19:41 Lennart Poettering wrote: >> On Mon, 24.11.14 18:40, Thiago Macieira ([email protected]) 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 _______________________________________________ dbus mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dbus