[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150421110942.GA6008@kroah.com>
Date: Tue, 21 Apr 2015 13:09:42 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Andy Lutomirski <luto@...capital.net>,
Richard Weinberger <richard@....at>,
David Herrmann <dh.herrmann@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Jiri Kosina <jkosina@...e.cz>,
Al Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Tom Gundersen <teg@...m.no>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Daniel Mack <daniel@...que.org>,
Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
On Tue, Apr 21, 2015 at 12:53:20PM +0200, Borislav Petkov wrote:
> On Tue, Apr 21, 2015 at 12:31:28PM +0200, Greg Kroah-Hartman wrote:
> > "Your code is too large" does not provide any value to this discussion
> > at all, sorry. Richard is being a jerk here, please don't perpetuate
> > that line of discussion, it's not helpful at all.
>
> We're becomint offensive slowly, aren't we?
Vs. being offensive quickly like you started out with? :)
> I'm sorry but Richard's right. A lot of people told you already that
> this is a *lot* of code and no other kernel person has given its
> Reviewed-by: for this.
And I've kept asking for review, and the people who have reviewed it,
their issues have been addressed.
But to somehow say "it's insecure because it is a lot of code" is
unhelpful and flat out mean.
> Which tells me that no one has reviewed it, maybe because it is a *lot*
> of code. Or maybe because people are busy with other stuff and don't
> have time to review 13KLOC and a spec ontop for something which is
> supposed to speed up some userspace pile which reportedly hasn't been
> written yet or for some use cases which by no means justify the addition
> of 13KLOC accelerator code to the kernel.
We add chunks of code large than this to the kernel all the time. For
core infrastructure pieces. Asking for people to review it, and discuss
it is normal, nothing is happening different here.
In the end, not everyone reviews all of the code, that's normal. I see
chunks get merged all the time and I go "what? That's crazy? Who would
want a virtual machine as their networking packet parser?" But given
that the maintainer of the subsystem acked it, and has agreed to
maintain it, I trust them to do the right thing. That's how kernel
development works, on trust.
And that's the core issue here, trust.
You are the only one to bring this up in the thread, but I feel it's the
underlying theme. You act as if you don't trust us, the developers, to
be doing the right thing here. If so, great, please, let's talk about
it.
Trust is about not always getting everything right, but trust that the
people involved will be around to fix it if something is wrong. And
that the people involved are actually working toward something they see
is valuable and needed in an honest way.
If you don't trust me, great, say it. If you don't trust David, Daniel,
and Djalal, great, say so, and we can work on addressing that issue.
If you don't trust the code, wonderful, please let me know that and show
what is untrustworthy about it, again, as Al and Andy have done so. Let
us address it that way, as has been done so thanks to Al and Andy's
review.
But to do drive-by potshots in an email thread, just because you somehow
don't like the color of the bikeshed, without having every looked inside
the bikeshed to see what it is doing there, is completely unfair and a
unreasonable and totally unproductive.
greg "read the code luke" k-h
--
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