Re: [PATCH 0/9] powerpc: port of dynamic ftrace

[Steven Rostedt]

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:

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 33dbefd..d9127f4 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -162,6 +162,7 @@ config DYNAMIC_FTRACE
        depends on FUNCTION_TRACER
        depends on HAVE_DYNAMIC_FTRACE
        depends on DEBUG_KERNEL
+       depends on !PPC
        default y
        help
          This option will modify all the calls to ftrace dynamically


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
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/