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.
next prev parent 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.