Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

[gens]

The D-Bus _protocol_ isn't complex. But you miss the point about the speed of kdbus/D-bus completely. It is the ability to use the same framework for both control mechanisms and data at a much higher speed than previously possible, that is the point about the data speed up for kdbus.

It is quite possible to make very fast data side-channels to dbus, but then you have to duplicate D-Bus functionality for the data channel, which is an error prone mess and which leads to proprietary hack jobs.

With kdbus, everybody can easily add data payloads to D-Bus, which is useful and will reduce both developing complexity and errors for such users.

And that really is the whole point and philosophy behind kdbus; make complex things easy by abstracting the complexity away with an easy to use API, and make developing fast with libs and features.

this is dbus
it is complex

it was made to be a generic bus to make writing desktop applications easier
it was not made to transport audio or be used for real-time interactive processes

if you want to transport large amounts of data between two processes with low latency you are way better off using a plain ringbuffer+sync protocol
or even just plain sockets, be it custom or TCP

people want to use whatever they know how to use for everything
but that is not always the best solution
for example just because java is one of the more popular programming languages today does not mean we should design everything around java
so just because desktop app programmers know dbus well does not mean that it should be used for everything

i hope you can agree with this

[finalzone]

...

Reading your comments sound like you are uninterested to read the post that responded to your question as long they don't fit your own view. In that case, it means you wasted those people time honestly.

[gens]

Reading your comments sound like you are uninterested to read the post that responded to your question as long they don't fit your own view. In that case, it means you wasted those people time honestly.

the post was about using dbus for performance sensitive things
making it usable for everything and making everything use it

to quote
"And that really is the whole point and philosophy behind kdbus; make complex things easy by abstracting the complexity away with an easy to use API, and make developing fast with libs and features."

that is what i was replying to with the "jack of all trades, master of none" argument
i think educating programmers is more important then making things easier for people who do not want to learn
things like ring buffers are not really complex, it's just the general idea that they are that frightens people away from learning them


do you have anything to add ?

[interested]

this is dbus
it is complex

No, the _protocol_ isn't complex. The reference implemenation may be because it was made to run on Linux/Unix/BSD/Windows/Mac.

it was made to be a generic bus to make writing desktop applications easier
it was not made to transport audio or be used for real-time interactive processes

if you want to transport large amounts of data between two processes with low latency you are way better off using a plain ringbuffer+sync protocol
or even just plain sockets, be it custom or TCP

people want to use whatever they know how to use for everything
but that is not always the best solution
for example just because java is one of the more popular programming languages today does not mean we should design everything around java
so just because desktop app programmers know dbus well does not mean that it should be used for everything

i hope you can agree with this

Again, you are missing the point; your "solution" would never work like D-Bus unless you invent and duplicate D-Bus for your data channels. Your solution simply can't solve the problems that kdbus/D-Bus solves.

And again, if you try to add marshaling, broadcasting and message queues to your solution, you have in fact invented a new IPC that only works on Linux and isn't supported by a single piece of software.

kdbus on the other hand, will instantly upgrade the entire D-Bus-using Linux userland to a new kernel IPC, without anybody needing to change a line of code.

The kdbus solution also mean that Unix/BSD and non-systemd distros aren't left behind by systemd-distros migrating to a new IPC.

[psychoticmeow]

i think educating programmers is more important then making things easier for people who do not want to learn

This is like arguing that we should be writing things in assembler instead of making things easier.

things like ring buffers are not really complex, it's just the general idea that they are that frightens people away from learning them

And when dealing with the scenarios that dbus deals with this is applicable how?

[psychoticmeow]

if you want to transport large amounts of data between two processes with low latency you are way better off using a plain ringbuffer+sync protocol
or even just plain sockets, be it custom or TCP

Ok, we'll switch to using sockets. Great. Now every application and it's dog has a slightly different protocol, and it's nearly impossible to interconnect things that were not designed specifically to interconnect. And throw security out the window too, because now every damn application handles that differently.

Or we could just use kdbus, which is now more capable of handling large amounts of data than dbus ever was.

[gens]

No, the _protocol_ isn't complex. The reference implemenation may be because it was made to run on Linux/Unix/BSD/Windows/Mac.

Again, you are missing the point; your "solution" would never work like D-Bus unless you invent and duplicate D-Bus for your data channels. Your solution simply can't solve the problems that kdbus/D-Bus solves.

And again, if you try to add marshaling, broadcasting and message queues to your solution, you have in fact invented a new IPC that only works on Linux and isn't supported by a single piece of software.

kdbus on the other hand, will instantly upgrade the entire D-Bus-using Linux userland to a new kernel IPC, without anybody needing to change a line of code.

The kdbus solution also mean that Unix/BSD and non-systemd distros aren't left behind by systemd-distros migrating to a new IPC.

http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol

the protocols first byte is an endianness flag
-it deals with endianness, that no sane protocol should
-the "flag" is one byte, instead of 1 bit
2nd byte is msg type, theres 3 (plus error and "unknown")
3rd byte is an OR of 3 flags
4th is the protocol version (mind you this goes in every msg)
then there are 2 32bit paramaters, data length and a cookie
and still no data, data comes after additional paramater fields that depend on msg type and flags

that's just a basic msg format, the protocol defines a lot more things
maybe you are thinking about the API

and no, i never said you should reinvent broadcasting
i specifically said that dbus should not be used for latency or throughput sensitive problems
for example; using dbus to discover/connect to a media player is fine, while using dbus to actually transport the media is not

[gens]

Ok, we'll switch to using sockets. Great. Now every application and it's dog has a slightly different protocol, and it's nearly impossible to interconnect things that were not designed specifically to interconnect. And throw security out the window too, because now every damn application handles that differently.

you are still making your own IPC version, since you are sending arbitrary data over a bus
org.mplayer.whatever is not the same as org.vlc.whatever

if you made a org.videoplayer.whatever, you made a standard "videoplayer" protocol
but then the underlying transport protocol does not matter in the slightest


do explain the security part
an example would be even better

[psychoticmeow]

you are still making your own IPC version, since you are sending arbitrary data over a bus
org.mplayer.whatever is not the same as org.vlc.whatever

if you made a org.videoplayer.whatever, you made a standard "videoplayer" protocol
but then the underlying transport protocol does not matter in the slightest

dbus is the protocol for sending/receiving data, you're talking about specific interfaces, where as if everyone invents their own alternative to sending data via sockets you're bound to end up with a bunch of incompatible solutions using different protocols.

do explain the security part
an example would be even better

I mean that it is then up to each application to handle the security of its IPC, instead of relying on something that is designed exactly for that purpose. The same exact problem as above.

[duby229]

Well, he didn't exactly say he was looking forward to merging it. I think really what he said was that he trusts the people he surrounds himself with, and so he'll merge it to keep the system working.