Hi On Wed, Aug 5, 2015 at 10:11 PM, Andy Lutomirski <[email protected]> wrote: > On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann <[email protected]> wrote: >> Hi >> >> On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski <[email protected]> wrote: >>> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann <[email protected]> >>> wrote: >>>> This is a bug in the proxy (which is already fixed). >>> >>> Should I expect to see it in Rawhide soon? >> >> Use this workaround until it does: >> >> $ DBUS_SYSTEM_BUS_ADDRESS="kernel:path=/sys/fs/kdbus/0-system/bus" >> ./your-binary >> > > Which binary is supposed to be run like that?
Your test. >>> Anyway, the broadcasts that I intended to exercise were >>> KDBUS_ITEM_ID_REMOVE. Those appear to be broadcast to everyone, >>> irrespective of "policy", so long as the "match" thingy allows it. >> >> Matches are opt-in, not opt-out. Nobody will get this message unless >> they opt in. >> > > And what opts in? Either something's broken, or there's a different > scalabilty problem, or a whole pile of kdbus-using programs in Fedora > Rawhide do, in fact, opt in. See Daniel's explanation. If applications subscribe to all notifications, they get what they asked for. I recommend filing bug reports for the applications in question. > Given that all existing prototype userspace that I'm aware of > (systemd and its consumers) apparently opts in, I don't really care > that the feature is opt-in. This is just plain wrong. Out of the dozens of dbus applications, you found like 9 which are buggy? Two of them are already fixed, the maintainers of the other ones notified. I'd be interested where you got this notion that "all existing prototype userspace [...] opts in". > Also, given things like this: > > commit d27c8057699d164648b7d8c1559fa6529998f89d > Author: David Herrmann <[email protected]> > Date: Tue May 26 09:30:14 2015 +0200 > > kdbus: forward ID notifications to everyone > > it really does seem to me that the point of these ID notifications is > for everyone to get them. It's not. This patch just opens the policy so everyone can see those notifications. By default, it's not delivered to anyone. > Also, you haven't addressed the memory usage issues -- ..because it doesn't change anything. If your IPC is message based and async, _someone_ needs to buffer. I don't see the difference between buffering locally on !EPOLLOUT or buffering in a shmem pool. In both cases, clients have control over the buffer size. If you disagree, please _elaborate_. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
