From: Robert Richter <rric@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/16] perf, persistent: Kernel updates for perf tool integration
Date: Sat, 1 Jun 2013 18:15:55 +0200 [thread overview]
Message-ID: <20130601161555.GE2132@rric.localhost> (raw)
In-Reply-To: <20130531122136.GA17843@nazgul.tnic>
On 31.05.13 14:21:36, Borislav Petkov wrote:
> On Fri, May 31, 2013 at 11:32:10AM +0200, Robert Richter wrote:
> > Hmm, since the changes in the onliner patches are either hard effort
> > to find in reviewing/testing or more or less related to the new
> > implementation, I better prefer to keep authorship as well to document
> > the code development (don't blame me about patch count ;)). We better
> > should add a branch (preferable at topic branch in tip?) as soon as
> > possible for this.
>
> Yes, you should definitely keep authorship - simply state this in the
> commit message, add your SOB, etc. However, I don't want to have messy
> history for patches which haven't been reviewed yet. This complicates
> review needlessly and makes absolutely no sense for later when you stare
> at the history.
No, it's not about authorship in the sense of copyright, it's just
about keeping track of changes. My changes weren't related to a patch
review. In that case it would be totally fine to instantly merge the
changes.
Instead I reviewed the code while developing it with certain goals in
mind. Most changes I found necessary while building and running a
modified version during development. That never could be found in a
patch review. These changes are what we actually want to see in git
history.
And your argument that changes should be merged to reduce review
effort would actually mean to drop all the code you introduce which is
later removed in my patches (see below for the diff stats).
I also don't think we need to re-review your patches. Most of it has
been reviewed and should also not change much to avoid rebase
conflicts. In my point of view they are fine to be applied to a perf
topic branch. Ingo, would this be ok? There is no messy history if we
later just apply my patches on top. So no, I don't agree with you here
to merge some of my patches.
-Robert
$ git diff tip/master...ras --stat kernel/
kernel/events/Makefile | 2 +-
kernel/events/core.c | 56 +++++++++++++++++++----------------
kernel/events/internal.h | 4 +++
kernel/events/persistent.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/events/ring_buffer.c | 7 ++---
5 files changed, 214 insertions(+), 30 deletions(-)
$ git diff ras...persistent --stat kernel/
kernel/events/core.c | 6 ++-
kernel/events/internal.h | 1 -
kernel/events/persistent.c | 292 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------
3 files changed, 221 insertions(+), 78 deletions(-)
next prev parent reply other threads:[~2013-06-01 16:16 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-31 8:47 [PATCH 00/16] perf, persistent: Kernel updates for perf tool integration Robert Richter
2013-05-31 8:47 ` [PATCH 01/16] perf, persistent: Fix build error for no-tracepoints configs Robert Richter
2013-05-31 9:05 ` Borislav Petkov
2013-05-31 8:47 ` [PATCH 02/16] perf, persistent: Fix attr size Robert Richter
2013-05-31 9:05 ` Borislav Petkov
2013-05-31 8:47 ` [PATCH 03/16] perf, persistent: Setting default buffer size to 512k as in perf tools Robert Richter
2013-05-31 9:07 ` Borislav Petkov
2013-05-31 8:47 ` [PATCH 04/16] perf, persistent: Print error code on failure when adding events Robert Richter
2013-05-31 9:10 ` Borislav Petkov
2013-05-31 8:47 ` [PATCH 05/16] perf, persistent: Return resonable error code Robert Richter
2013-05-31 9:11 ` Borislav Petkov
2013-05-31 8:47 ` [PATCH 06/16] perf, persistent: Return -EACCES if mapped buffers must be readonly Robert Richter
2013-05-31 9:12 ` Borislav Petkov
2013-05-31 8:47 ` [PATCH 07/16] perf, persistent: Rework struct pers_event_desc Robert Richter
2013-05-31 8:47 ` [PATCH 08/16] perf, persistent: Remove rb_put() Robert Richter
2013-05-31 8:47 ` [PATCH 09/16] perf, persistent: Introduce get_persistent_event() Robert Richter
2013-05-31 8:47 ` [PATCH 10/16] perf, persistent: Reworking perf_get_persistent_event_fd() Robert Richter
2013-05-31 8:47 ` [PATCH 11/16] perf, persistent: Protect event lists with mutex Robert Richter
2013-05-31 8:47 ` [PATCH 12/16] perf, persistent: Avoid adding identical events Robert Richter
2013-05-31 8:47 ` [PATCH 13/16] perf, persistent: Implementing a persistent pmu Robert Richter
2013-05-31 8:47 ` [PATCH 14/16] perf, persistent: Name each persistent event Robert Richter
2013-05-31 8:47 ` [PATCH 15/16] perf, persistent: Exposing persistent events using sysfs Robert Richter
2013-05-31 8:47 ` [PATCH 16/16] perf, persistent: Allow multiple users for an event Robert Richter
2013-06-03 13:49 ` Jiri Olsa
2013-06-04 8:20 ` Borislav Petkov
2013-06-04 9:19 ` Jiri Olsa
2013-06-04 9:35 ` Borislav Petkov
2013-06-07 13:47 ` Robert Richter
2013-05-31 9:15 ` [PATCH 00/16] perf, persistent: Kernel updates for perf tool integration Borislav Petkov
2013-05-31 9:32 ` Robert Richter
2013-05-31 12:21 ` Borislav Petkov
2013-06-01 16:15 ` Robert Richter [this message]
2013-06-02 7:29 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130601161555.GE2132@rric.localhost \
--to=rric@kernel.org \
--cc=acme@ghostprotocols.net \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox