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