2014/09/04 6:02 "Bzzzz" <lazyvi...@gmx.com>: > > On Wed, 3 Sep 2014 21:38:47 +0100 > Jonathan Dowland <j...@debian.org> wrote: > > Thanks for your very clear explanation, Jonathan. > > > kernel support is pretty much essential to improve the performance of > > dbus. Lots of data is being passed over dbus by apps nowadays, and > > because it's an entirely userspace solution that means data is being > > copied from process to process. > > These needless copies can be avoided > > with some kind of help from the kernel, but none of the existing IPC > > mechanisms are good enough. > > Beyong my leadue far this is, but applying Ocam's Razor to this > situation, I'd say the solution could be to have "several layers > of userspace" with different rights & privileges ? (a bit like > the i386 CPU privileges layers).
Twenty+ years after Linus's epiphany that the i386 "privilege separation" was just a lock-in technology and nothing more, ... Okay, maybe he didn't quite put it that way. But it was definitely not a unix-ish thing to do then, and it would not be a unixish way to do it now. Computer systems and human systems work better with less hierarchy depth, rather than more. > This way, if app-A and app-B are authorized to communicate, no more > data copy (?) It doesn't end up working that well. The larger the shared memory, the more chance for semaphors and monitors to be missed. dbus/kdbus is actually another case of re-inventing bad solutions, and getting things more wrong the second time. Admitted, it's often better to do something not-quite-right than do nothing at all, but forgetting that there is a better way is not a good thing either. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
