Jude,

i'm glad at least one of us is following the kdbus conversation.
advanced authentication is exactly what i wanted added to unix domain
sockets, so kdbus sounds nice as long as it works as advertised. as a
POSIX enthusiast, i wish they had merely extended unix domain sockets
so that it could proposed as an extension of the spec. maybe there is
still time to do this before kdbus becomes too heavily used. question
though what is "IVI"?
--Gravis


On Sun, Feb 15, 2015 at 11:50 AM, Jude Nelson <judecn@???> wrote:
> 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
>
>