Re: [PATCH v3 00/13] Add kdbus implementation

[Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>]

On Tue, Jan 20, 2015 at 02:38:06AM +0800, Greg Kroah-Hartman wrote:
> Yes, I do agree, there are lots of existing ipc solutions today that
> kdbus is not designed for, nor would it be good to use it for.  The
> majority of them being IPC that crosses the network layer, as there are
> lots of good solutions today for that problem.  That being said, I do
> know one research group that has kdbus working cross-network, just "to
> try it out", but I don't know what ever came of it.
...
> Everyone uses D-Bus today for everything on their system, so by
> replacing the underlying library with kdbus, they will continue to use
> it for everything without having to change any application or library
> code at all.

These two statements somehow contradict. From my admittedly very
limited experience, I never used D-Bus because it did not
fit my usage scenarios: I never needed a bus, only point-to-point
links like pipes or sockets.

Let me rephrase my previous, lengthy mail: Will kdbus only
support the same IPC model as D-Bus (just with higher
performance and some bells and whistles), or will it
be useful for other scenarios?  Like, can two programs
use it to communicate directly without the need of
any daemon?  (And if so, would there be any advantage
compared to traditional UNIX IPC methods?)

You were comparing kdbus and Binder.  Why?
So far my impression is that D-Bus and Binder are
completely seperate things, not just because of
the thread vs. event-loop programming model but
also because Binder is not a bus (i.e. no multicast messaging).

> Hope this helps,

Well, it made your intentions a bit clearer, but it does
not help to sell kdbus to me, sorry ;-/


Thanks,
Johannes