I think we're significantly overblowing the impact of kdbus.

I've been following the development of kdbus, and kdbus alone is just
another way to send bytes from one process to others. In a nutshell, it
creates a namespace of special character files that have some interesting
properties. Namely, a single writer can send large (~gigabytes) amounts of
data to many readers in a zero-copy manner, and writers can require readers
to authenticate at runtime using something like UNIX domain socket
credentials. At the end of the day, it's not terribly different from a
namespace of UNIX domain sockets, and if you follow the conversations on
lkml, you'll see people asking the developers why they didn't just make the
UNIX domain socket implementation better (why they didn't is still a
question that has not been answered to my satisfaction, but whatever--I'll
just compile it out if I don't like it).

The code required to set up kdbus from userspace is currently handled by
systemd, but it isn't that tricky. We might have to modify sysvinit or
dbus to do it instead, but it's doable.

The future of userspace dbus isn't in question over this, at least in the
medium-term. The userspace dbus we have now will continue to run as
normal, since it uses UNIX domain sockets behind the scenes to push bytes
around. The new dbus implemented in systemd offers the same interface, but
uses kdbus to push bytes around, and takes advantage of kdbus's
authentication mechanisms as well as a few other subtle things instead
(like the notion of an atomic
"send-message-only-if-receiver-has-not-closed"). In both cases, the data
validation and marshalling continue to run in userspace.

The future for applications on !Linux that assume that dbus is capable of
sending gigabytes of RAM to a bunch of other processes, however, looks
bleak, unless !Linux add their own kdbus-like IPC. What I'd like to know,
however, is which applications these are. Apparently, the stakeholders
that come up repeatedly on lkml are IVI developers, so I'm guessing that
the applicability of kdbus-powered dbus is pretty small.

-Jude

On Sun, Feb 15, 2015 at 10:26 AM, Gravis <ring3k@???> wrote:

> > Kernel live patching makes KDBUS and systemD support mandatory!
>
> i'm weary of KDBUS but live patching is something i consider too dangerous.
> --Gravis
>
>
> On Sun, Feb 15, 2015 at 9:09 AM, <joerg@???> wrote:
> > As you may have read, Linus Torvalds considers to call the next Linux
> > release 4.0 instead of 3.20. Many people have been wondering why, but
> there
> > is one quite radical feature hidden in the new version.
> >
> > - OverlayFS now supports multiple read-only layers.
> > - Many Intel DRM graphics driver improvements.
> > - Improvements to KVM for bettering Linux virtualization.
> > - TPM 2.0 support for trusted computing.
> > - Live kernel patching support via KDBUS.
> > - Fixes to the F2FS file-system.
> > - Some basic changes to XFS.
> > - An important AMD Hawaii GPU re-clocking fix.
> > - Full IBM z13 system support.
> > - Continued support improvements to Sony's PlayStation 3 with Linux even
> > though Sony no longer supports the "Other OS" functionality.
> > - Sound improvements, particularly around bettering the support for HP
> > laptops.
> > - The usual plethora of ACPI / power management updates.
> > - New and updated input drivers and new HID hardware support.
> > - Numerous media driver improvements.
> >
> > Kernel live patching makes KDBUS and systemD support mandatory! Who will
> > maintain our kernel fork? Or maybe we should just move on to OpenSolaris,
> > the only true Unix left? We have been warning people of this happening,
> but
> > they did not listen!
> >
> > _______________________________________________
> > 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
>