Re: kdbus: to merge or not to merge?

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/