Hi James, On Thu, Apr 30, 2015 at 4:26 AM, James Powell <[email protected]> wrote:
> The discussion has not been favorable towards the adoption from current > reading on LKML. Past tests have not proven reliability, nor any > significant increase of speed of messaging across the IPC. Linus seems to > be of no love for it. > > IMO from the collective discussion, kdbus doesn't seem to be really well > designed, fast, or reliable compared to traditional D-Bus and only has a > small if minimal gain over traditional D-Bus near negligible. In short, one > could wonder if this effort was a complete waste of time, or a convoluted > effort to introduce a proprietary IPC in the kernel that can only be used > by system so they can kill off netlink support in udev in favor of kdbus. > My pick is the latter as we all know how the systemd kabal thinks, and we > all can make an educated guess as to where Greg Kroah-Hartman's > true loyalties lie. > The D-Bus implementation you're using isn't really fast or reliable in the first place :P Linus's benchmarks suggest that the reason the D-Bus implementation is so slow is because it suffers performance-death-by-a-thousand-cuts. There are a bunch of needless malloc()s, copies, locks, etc. per call that aren't costly by themselves, but they add up. What remains to be seen is how a *well-written* userspace D-Bus performs, or even a D-Bus that uses memfds or page-spicing for large messages. Also, netlink isn't going anywhere. Linus does not break userspace, and other device managers (including vdev) and hotplug programs all rely on netlink to receive device events. > The native IPC for Linux has been reliable, though it's not exactly fast > by all means, but in terms of working, it works, does it's job well, and > has a proven track record. > Shared memory is pretty damn fast--close to as fast as theoretically possible. Once set up, there is literally zero overhead (no context swtiches, no MMU reprogramming, no TLB flushes, etc.) since the pages of RAM are mapped in both the producers and consumer's page tables. Also, according to Kay Sievers himself, the humble pipe is faster than kdbus for messages smaller than 32K on an x86_64 system. This is even without vmsplice(2). All it needs are new protocols worked in to help it out by introducing new > methods of using the IPC while maintaining legacy pathways. Oddly enough > another IPC, Plumper from 9P has been available for some time now, but has > never been attempted at a port. > > IIRC 9P gets used today in libvirt and qemu for sharing folders. Also, it's "plumber" :) > I, and possibly others, can only hope Linus actually and ultimately says > "no" to kdbus and sees the purpose behind kdbus not being a successor > to D-Bus but a proprietary IPC that can be used by system for udev, and > only for that purpose. > It doesn't really matter to us whether or not kdbus gets accepted. Obviously, Linus won't accept it if he feels that it'll be a maintenance hassle, since once it's in the kernel, its interface is not allowed to change. Gazing into my cracked and cloudy crystal ball, what'll probably happen is the policy and marshaling logic will be kept in userspace, and the kernel will get a patch that adds the minimal set of primitives needed to address the actual shortcomings with the D-Bus design (but not problems with the current implementation). This includes memfd and file descriptor sealing today. Maybe down the road send(2) and write(2) will get a new flag to atomically check if the receiver is still connected and abort if not, and maybe read(2) and recv(2) will an option to atomically check the sender's credentials before receiving data. I get the impression from the discussion that these are all the D-Bus developers really need the kernel to do for them, but I could be wrong. > > Though should it become part of the mainline, we all know Lennart will > waste no time in dropping netlink support in udev just to get his way. > He's already said as much. > > If that becomes the case, eudev can hopefully make an effort to keep > netlink alive in a separate tree while backporting code in from > system-udev, but who knows how long that will last. However, Linus did make > a stern warning that if they did anything to break the userspace (and > breaking netlink in udev would do just that), they could have any number of > penalties from more developers from systemd banned from kernel > developments, to as well as possibly code excised from the kernel. > No doubt that eudev will continue regardless of systemd-udev. Plus, we'll have vdev soon enough too (which addresses problems that neither udev nor eudev handle). -Jude Date: Tue, 28 Apr 2015 23:00:55 +1000 > From: [email protected] > To: [email protected] > Subject: [Dng] About (k)dbus in LKML > > > https://news.ycombinator.com/item?id=9450806 > > Hot discussion about merging kdbus in kernel. > > TL;DR: The people who talk about how kdbus improves performance are just > full of sh*t. (c) Linus > > > _______________________________________________ Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
