Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1170995 > unrolled thread

Re: kdbus: to merge or not to merge?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: kdbus: to merge or not to merge? Linus Torvalds <torvalds@linux-foundation.org> - 2015-06-24 01:30 +0200
    Re: kdbus: to merge or not to merge? Andy Lutomirski <luto@amacapital.net> - 2015-06-24 03:00 +0200
    Re: kdbus: to merge or not to merge? Ingo Molnar <mingo@kernel.org> - 2015-06-24 10:10 +0200

#1170995 — Re: kdbus: to merge or not to merge?

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

[toc] | [next] | [standalone]

#1171018

On Tue, Jun 23, 2015 at 4:19 PM, 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.

Then I'll try to review the parts that I can review, time permitting,
in the event that someone sends a clean, reviewable set of patches.
Preferably not during the merge window.

If my, or anyone else's, review uncovers an ABI issue, then I will be
correspondingly grumpy now that the userspace code is slated to ship
with new systemd versions.  Because we can't actually ship a
kernel.org kernel that will fail to boot with Fedora Rawhide or Arch
AUR or whatever unless kdbus=0 is set on the kernel command line.

If someone ships an actual desktop sandbox based on kdbus custom
endpoints, I'll try to poke holes in it as usual.  I don't intend to
review that part for security in advance because I've already said my
part: I think the design is unfit for its purpose.  Given that I don't
see how one is supposed to use it in a sensible manner for sandboxing
in the first place, it's hard to evaluate whether it will do its job a
priori.

(NB: I think I may have figured out what people mean when they say
that custom endpoints are useful for sandboxes.  They might be talking
about BusPolicy= in systemd .service files.  That's a nifty feature,
but it seems rather limited and doesn't seem to me like it would be
useful for things like xdg-app.  Also, it could certainly be
implemented in userspace.)

--Andy

P.S.  I still remain unconvinced that any of the other arguments for
merging it are better than the performance argument.  But whatever.
--
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/

[toc] | [prev] | [next] | [standalone]

#1171164

* 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
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web