Hi James,

On Thu, Apr 30, 2015 at 4:26 AM, James Powell <james4591@???> 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: ad_user@???
> To: dng@???
> 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
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>