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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
