Commit Message

On Thu, 20 Nov 2008, Ingo Molnar wrote:
> > Hm, something like this shouldnt be pulled into the powerpc tree: it > touches the core kernel, x86 code and ftrace code as well.> > Please do the suggestion i outlined and which Paul agreed with: > prepare a branch that touches _only_ powerpc files and gets these > changes there, without actually breaking the build on powerpc. And > please do not name the branch as "hack" - we dont want Paul to pull > such a branch name - it will show up in the upstream git logs.> > Those changes should only touch powerpc files. Do not try to shoe-horn > already applied ftrace commits into a separate branch with different > sha1's. Yes, ftrace wont be enable-able on powerpc when that is > pulled, but it will only be for a brief period shortly before the > merge window. (and it will all just work fine when integrated > together)
As stated in the original post, I also had a separate branch called
ppc/ftrace-disable. Here's the generate posting if I were to send it:
The following patches are in:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
branch: ppc/ftrace-disable
Matt Fleming (1):
ftrace: align __mcount_loc sections
Steven Rostedt (8):
ftrace: disable dynamic ftrace from PowerPC
powerpc: ftrace, do not latency trace idle
powerpc: ftrace, convert to new dynamic ftrace arch API
powerpc/ppc64: ftrace, mcount record powerpc port
powerpc: ftrace, use probe_kernel API to modify code
powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace
powerpc/ppc32: ftrace, enabled dynamic ftrace
powerpc/ppc32: ftrace, dynamic ftrace to handle modules
----
arch/powerpc/Kconfig | 2 +
arch/powerpc/include/asm/ftrace.h | 14 +-
arch/powerpc/include/asm/module.h | 16 ++-
arch/powerpc/kernel/ftrace.c | 473 +++++++++++++++++++++++++++++++++---
arch/powerpc/kernel/idle.c | 5 +
arch/powerpc/kernel/module_32.c | 10 +
arch/powerpc/kernel/module_64.c | 13 +
kernel/trace/Kconfig | 1 +
scripts/recordmcount.pl | 20 ++-
9 files changed, 511 insertions(+), 43 deletions(-)
There is a dependency on Matt's commit for one of the PPC commits to
apply. I could hack that commit to work without Matt's patch, but then
that just postpones conflicts later on.
Matt's change is this:
scripts/recordmcount.pl | 20 ++-
The commit to disable PPC is this:
This does touch generic code, but this is to handle the chicken and the
egg problem. I would like the disabling of PowerPC code in a separate
commit (one easy to revert). But I can not disable the PowerPC code before
the code is there. If I disable it after the code is there, then there
exists a time that PowerPC will not compile due to this not being
disabled.
> > Once this branch is done, and once Paul agrees that it looks OK-ish to > him, we can put it into ftrace-next straight away [but still keep it > in a separate topic tree in tip/tracing/powerpc - so it can all be > reconsidered reversibly if it causes too much merge trouble]. Paul > will then be able to pull it in a few weeks, in the runup to the > v2.6.29 merge window.
I guess the question comes down to, do I work around Matt's patch?
> > The other option is to go the slow route of 2-3 kernel releases to > pull this all off.
2 or 3 kernel releases seems a bit extreme. But this is Paul's call.
Paul, any suggestions?
-- Steve
> > ok?> > Ingo> >