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

On Tue, Jan 20, 2015 at 12:38:12AM +0100, Johannes Stezenbach wrote:

On Tue, Jan 20, 2015 at 04:31:55AM +0800, Greg Kroah-Hartman wrote:

quoted

On Mon, Jan 19, 2015 at 09:19:06PM +0100, Johannes Stezenbach wrote:

quoted

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.

Great, then you don't need this, no need to worry about it at all, why
are we having this conversation? :)

Well, for one because that's what I wanted to find out...

quoted

quoted

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

It's not my "goal" to sell kdbus to you, if you don't want it, great,

I used this language because I think you're not providing
the facts that would allow me to judge for myself whether
kdbus is a good idea.  Those automotive applications you
were talking about, what was the OS they were ported from
and what was the messaging API they used?

They were ported from QNX and I don't know the exact api, it is wrapped
up in a library layer for them to use.  And typically, they run about
40 thousand messages in the first few seconds of startup time.  Or was
it 400 thousand?  Something huge and crazy to be doing on tiny ARM
chips, but that's the IVI industry for you :(

quoted

But odds are, you are using a system with D-Bus today, if not, then you
are using Linux in a very specific and limited manner, which is
wonderful, in that case this whole thread isn't really pertinent.

Lots of people do use D-Bus, and for those users, that is what this
patchset is for.

As I said before, I'm seeing about a dozen D-Bus messages per minute,
nothing that would justify adding kdbus to the kernel for
performance reasons.  Wrt security I'm also not aware of any
open issues with D-Bus.  Thus I doubt normal users of D-Bus
would see any benefit from kdbus.  I also think none of the
applications I can install from my distribution has any performance
issue with D-Bus.

That's because people have not done anything really needing performance
on the desktop over D-Bus in the past due to how slow the current
implementation is.  Now that this is being resolved, that can change,
and there are demos out there of even streaming audio over kdbus with no
problems.

But performance is not just the only reason we want this in the kernel,
I listed a whole long range of them.  Sure, it's great to now be faster,
cutting down the number of context switches and copies by a huge amount,
but the other things are equally important for future development
(namespaces, containers, security, early-boot, etc.)

And this is the point where I ask myself if I missed something.

Don't focus purely on performance for your existing desktop system,
that's not the only use case here.  There are lots of others, as I
document, that can benefit and want this.

One "fun" thing I've been talking to someone about is the ability to
even port binder to be on top of kdbus.  But that's just a research
project, and requires some API changes on the userspace binder side, but
it shows real promise, and would then mean that we could deprecate the
old binder code and a few hundred million devices could then use kdbus
instead.  But that's long-term goals, not really all that relevant here,
but it shows that having a solid bus IPC mechanism is a powerful thing
that we have been missing in the past from Linux.

thanks,

greg k-h