Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751628AbbFXIFW (ORCPT ); Wed, 24 Jun 2015 04:05:22 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:33421 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbbFXIFI (ORCPT ); Wed, 24 Jun 2015 04:05:08 -0400 Date: Wed, 24 Jun 2015 10:05:02 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni , Greg KH , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack Subject: Re: kdbus: to merge or not to merge? Message-ID: <20150624080502.GA23842@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5877 Lines: 111 * Linus Torvalds wrote: > On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/