lkml.org 
[lkml]   [2015]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: kdbus: to merge or not to merge?
From
On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> Can you opine as to whether you think that kdbus should be merged? I
> don't mean whether you'd accept a pull request that Greg may or may
> not send during this merge window -- I mean whether you think that
> kdbus should be merged if it had appropriate review and people were
> okay with the implementation.

So I am still expecting to merge it, mainly for a rather simple
reason: I trust my submaintainers, and Greg in particular. So when a
major submaintainer wants to merge something, that pulls a *lot* of
weight with me.

That said, I have to admit to being particularly disappointed with the
performance argument for merging it. Having looked at the dbus
performance, and come to the conclusion that the reason dbus performs
abysmally badly is just pure shit user space code, I am not AT ALL
impressed by the performance argument. We don't merge kernel code just
because user space was written by a retarded monkey on crack. Kernel
code has higher standards, and yes, that also means that it tends to
perform better, but no, "user space code is shit" is not a valid
reason for pushing things into the kernel.

So quite frankly, the "better performance" argument is bogus in my opinion.

That still leaves other arguments, but it does weaken the case for
kdbus quite a bit.

Because go out and read pretty much any argument for kdbus, and the
*first* argument is always performance. The articles never say "..
because the user-space dbus code is crap", though.

Linus


\
 
 \ /
  Last update: 2015-06-24 01:41    [W:0.249 / U:2.800 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site