All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Reorganize perf kernel side
Date: Fri, 4 Dec 2015 23:40:52 +0100	[thread overview]
Message-ID: <20151204224052.GT21177@pd.tnic> (raw)
In-Reply-To: <20151204220907.GJ17308@twins.programming.kicks-ass.net>

On Fri, Dec 04, 2015 at 11:09:07PM +0100, Peter Zijlstra wrote:
> I _will_ blame you for at least a month after every time I mistype a
> pathname because of this ;-)

Oh boy, I probably shouldn't do it after all out of fear of you coming
over ... :-)

> git blame --follow must keep working. That is, git had better be able to
> understand this code movement, loosing history is just a total PITA.

Well, I did

git annotate arch/x86/kernel/cpu/perf_event.c > blame.before

git annotate arch/x86/perf/perf_event.c > blame.after

The diff is:

--- /tmp/blame.before   2015-12-04 23:30:28.502701279 +0100
+++ /tmp/blame.after    2015-12-04 23:29:53.618702295 +0100
@@ -37,7 +37,7 @@ e3f3541c19c89 (Peter Zijlstra 2011-11-21
 d07bdfd322d30  (Peter Zijlstra 2012-07-10 09:42:15 +0200       37)#include <asm/desc.h>
 d07bdfd322d30  (Peter Zijlstra 2012-07-10 09:42:15 +0200       38)#include <asm/ldt.h>
 241771ef016b5  (Ingo Molnar    2008-12-03 10:39:53 +0100       39)
-de0428a7ad485  (Kevin Winchester       2011-08-30 20:41:05 -0300       40)#include "perf_event.h"
+b5e0c1bab8637  (Borislav Petkov        2015-12-04 22:02:51 +0100       40)#include "../kernel/cpu/perf_event.h"
 de0428a7ad485  (Kevin Winchester       2011-08-30 20:41:05 -0300       41)
 de0428a7ad485  (Kevin Winchester       2011-08-30 20:41:05 -0300       42)struct x86_pmu x86_pmu __read_mostly;
 efc9f05df2dd1  (Stephane Eranian       2011-06-06 16:57:03 +0200       43)

and that include file change is only temporary in order to keep the
churn at the lowest level.

Is this what you had in mind?

> Also, a script that can auto-convert patches would be nice.

Sure, I can do that.

Also, I was thinking of doing this in 4-5 patches sets only so that we
can keep everything easily manageable.

For sure, I don't want to do one insane move in one go and cause
needless churn and regressions.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

  reply	other threads:[~2015-12-04 22:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 21:17 Reorganize perf kernel side Borislav Petkov
2015-12-04 22:09 ` Peter Zijlstra
2015-12-04 22:40   ` Borislav Petkov [this message]
2015-12-06  9:54 ` Ingo Molnar

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=20151204224052.GT21177@pd.tnic \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.