Message-ID: <878ub9ie2d.fsf@x220.int.ebiederm.org>
Date:	Wed, 24 Jun 2015 05:41:14 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Havoc Pennington <havoc.pennington@...il.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>
Subject: Re: kdbus: to merge or not to merge?

Ingo Molnar <mingo@...nel.org> writes:

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

This is largely not what happened with kdbus.

The initial submission was problematic.  Many pieces of technical review
were not addressed at the time a pull request was sent to Linus.  Even
now there are remaining outstanding technical items such as performance
that have not been addressed.

The cost to the rest of the core is potentially quite high as parts of
kdbus double down on the worst mistakes in user interface of the kernel.

Politics and emotion are involved because the discussions around kdbus
have not been honest:
- Lennart Poettering who has been hugely involved in the creation and
  the design of kdbus has not shown is face on lkml during the review,
  and he seems the only one who can actually answer many of the
  technical questions about kdbus.

- Many times it was said some feature of kdbus is not important because
  using it was not required, and yet in practice using that feature is
  required in the common case.

- Performance has been said to be a large benefit of kdbus and yet in
  the common case there will be a number of shared cache lines modifed
  for every message sent, for reference counts.

  At a quick glance it appears that communication with every system
  daemon will be serialized because they all have init as their parent
  process, so every reply will modify the reference count of init's
  struct pid.

At this point I honestly do not know how to have a technical dialogue
about the code in kdbus.  

Pointing out that bumping several reference counts per message is a bad
idea, has gotten no where so far.

Crazy things like using the processes command line (copied from
userspace when a message is sent) for message authentication is still
present in the code.

I don't think any of these things are particularly subtle, hard to
understand, or hard to fix yet months after they have been pointed out
the code persists.

For subtle issues who knows.  Every review I have seen seems to get to
a couple of simple things, point them out, and then stops.  I am
actually very strongly surprised at how many of these little issues
remain in the code.  There were enough changes added to the kdbus tree
to fix small issues since the last merge window I would have thought I
would have had to looked a little harder for problems.

So whatever else the case may be I think the current kdbus code base is
a long way from being ready to be merged.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists