KDBUS To Be Included In The Linux 4.1 Kernel

[quikee]

There are well thought out valid criticisms, and I'd hope they get addressed. I'm not sure the dbus guys understand that once this is merged all its flaws are locked in place.

One of the top kernel development guy is working on kdbus - of course he knows exactly what it means when something gets merged.

[quikee]

I'm not sure why you included JSON and BSON in there-- unless there's something about them that I don't know, so it really comes down to KDBUS vs Thrift vs ProtocolBuffers.
ProtocolBuffers looks like it outputs C++, Java, or Python... which means the kernel would have to support those languages, wouldn't it?

Aren't ProtocolBuffers just a serialization format - which would make it more much more closer to JSON and BSON than KDBus? AFAIK there is no IPC functionality in ProtocolBuffers, just serialization, which is also designed to be more for general purpose rather than a specific (IPC) purpose.

[zanny]

http://lkml.iu.edu/hypermail/linux/k...4.1/03953.html
http://lkml.iu.edu/hypermail/linux/k...4.1/03981.html

There are well thought out valid criticisms, and I'd hope they get addressed. I'm not sure the dbus guys understand that once this is merged all its flaws are locked in place.

But I also understand that a lot of these unintuitive or complex problems are due to it being a legitimate port of dbus - that you do not need to rewrite your dbus libs and apis to take advantage of kdbus (at least I don't think so, you didn't need to when I was reading about it a year ago). Fixing the problems in those posts basically necessitates forking more from userspace dbus.

[Ericg]

KDBUS vs JSON vs BSON vs Thrift vs ProtocolBuffers?

I'm not sure why you included JSON and BSON in there-- unless there's something about them that I don't know, so it really comes down to KDBUS vs Thrift vs ProtocolBuffers.

Thrift would probably be out because its written in C++, and we all know how Linus feels about that.

ProtocolBuffers looks like it outputs C++, Java, or Python... which means the kernel would have to support those languages, wouldn't it?

KDBUS is the only one left standing.

The only real competition to KDBUS is Binder, from Android, and that was trashed for various reasons which are described here: http://kroah.com/log/blog/2014/01/15/kdbus-details/

[uid313]

Versus?

KDBUS vs JSON vs BSON vs Thrift vs ProtocolBuffers?

[valeriodean]

Well, they are the same replies, from the same people, with the same counter replies from the same people part of the kdbus camp.
It appears evident that nobody is available to move away from his position, so what will happen now?
I'm not aware of the kernel policy in terms of code inclusion: is it enough to have a couple of NAKs to refuse a pull request or what?
Who is the "area" maintainer that will have the last word about the PR?

[ptrwis]

(k)d-bus looks quite similar to Enterprise Java Beans (and JMS). I even wonder if (k)d-bus could be used to implement component/microservices based application. Like Java EE with Linux in place of application server, system services instead of EJBs, systemd for service management, services might packaged into containers instead of modules.

[AnAkIn]

Any particular reason not to want it merged? It sounds pretty nice.

http://lkml.iu.edu/hypermail/linux/kernel/1504.1/03953.html

http://lkml.iu.edu/hypermail/linux/kernel/1504.1/03981.html

[rabcor]

Any particular reason not to want it merged? It sounds pretty nice.

[AnAkIn]

Judging by the replies some people are apparently trying to not get it merged.