2014/09/04 6:02 "Bzzzz" <lazyvirus@gmx.com>:
>
> On Wed, 3 Sep 2014 21:38:47 +0100
> Jonathan Dowland <jmtd@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.