IVI == "In-Vehicle Infotainment." The stuff that runs your new car's UI.

On Sun, Feb 15, 2015 at 12:44 PM, Gravis <ring3k@???> wrote:

> 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
> >
> >
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>