lkml.org 
[lkml]   [2015]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kdbus: to merge or not to merge?

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > 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.

    Beyond the cons, I see four arguments in favor of kdbus:

    - In its current form kdbus really does not hurt the core kernel in any appreciable
    way: like Android's Binder it sits in its own corner that doesn't hurt anyone.

    Here's the kdbus diffstat (merged to v4.2-rc1-to-be with trivial conflicts fixed):

    97 files changed, 34069 insertions(+), 3 deletions(-)

    But ignoring the kdbus/ specific bits, the diffstat shows essentially zero impact:

    triton:~/tip> git diff -M linus.. --stat | grep -v kdbus
    Documentation/Makefile | 2 +-
    Documentation/ioctl/ioctl-number.txt | 1 +
    MAINTAINERS | 13 +
    Makefile | 1 +
    include/uapi/linux/Kbuild | 1 +
    include/uapi/linux/magic.h | 2 +
    init/Kconfig | 13 +
    ipc/Makefile | 2 +-
    samples/Kconfig | 7 +
    samples/Makefile | 3 +-
    tools/testing/selftests/Makefile | 1 +

    kdbus is a driver in essence, with no core kernel impact other than its
    placement in ipc/kdbus/.

    Beyond some vague opportunity cost kdbus is almost zero-cost for the kernel.

    - I've been closely monitoring Linux kernel changes for over 20 years, and for the
    last 10 years the linux/ipc/* code has been dormant: it works and was kept good
    for existing usecases, but no-one was maintaining and enhancing it with the
    future in mind.

    So there exists a technical vacuum: the kernel does not have any good, modern
    IPC ABI at the moment that distros can rely on as a 'golden standard'. This is
    partly technical, partly political. The technical reason is that SysV IPC is
    ancient and cumbersome. The political reason is that SystemD could be using
    and extending Android's existing kernel accelerated IPC subsystem (Binder)
    that is already upstream - but does not.

    Now that ipc/kdbus/ has been proposed people are up in arms and suggest better
    approaches to almost every aspect. Where have you been for the past 10 years
    and where is your working code and the user-space project that takes advantage
    of an alternative approach? I believe it's fair to say that much of that
    interest and activity would dry up overnight if kdbus was rejected permanently,
    which is sad.

    - Once one (or two) major distros go with kdbus, it becomes a de-facto ABI. If
    the ABI is bad then that distro will hurt from it regardless of whether we
    merge it upstream or not - so technical pressure is there to improve it. But if
    the kernel refuses to merge it, Linux users will get hurt disproportionately
    badly. The kernel not being the first mover with a new ABI is absolutely
    sensible. But once Linux distros have taken the initial (non-trivial) plunge,
    not merging a zero-cost ABI upstream becomes more like revenge and obstruction,
    which is not productive. The kernel has very little value without full
    user-space, after all, so within reason the kernel project has to own up to
    distro ABI mistakes as well.

    - Life does not stop after a merge: once kdbus is upstream, we _can_ express
    pressure to only extend the kernel side ABI in sensible ways. I am fully
    prepared to NAK any crap in its ABI that I care about.

    So just like I was in favor of merging Android's Binder when everyone was against
    it a few years ago, I'm in favor of merging kdbus as well.

    Not because I like it so much, but because I think the merge process should be
    stripped of politics and emotion as much as possible: if an initial submission is
    good and addresses all technical review properly, and if the cost to the core
    kernel is low, then barring alternative, fully equivalent and superior patch
    submissions, rejecting it does more harm than good.

    I'm all for replacing good code with even better code, but I'm not in favor of
    replacing good code with words.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2015-06-24 10:21    [W:2.707 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site