IVI == "In-Vehicle Infotainment." The stuff that runs your new car's UI.
On Sun, Feb 15, 2015 at 12:44 PM, Gravis <rin...@adaptivetime.com> 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 <jud...@gmail.com> 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 <rin...@adaptivetime.com> > 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, <jo...@trash-mail.com> 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@lists.dyne.org > >> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > >> > > >> _______________________________________________ > >> Dng mailing list > >> Dng@lists.dyne.org > >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
