[PATCH 0/7] Porting dynmaic ftrace to PowerPC

[Ingo Molnar]

* Paul Mackerras <paulus at samba.org> wrote:

> Ingo Molnar writes:
> 
> > * Steven Rostedt <rostedt at goodmis.org> wrote:
> > 
> > > On Wed, 19 Nov 2008, Paul Mackerras wrote:
> > > 
> > > > Steven Rostedt writes:
> > > > 
> > > > > Can I add your Acked-by: to all these patches that I submitted? I'm going 
> > > > > to recommit them with a consistent subject (all lower case ppc), but I'm 
> > > > > not going to change the patches themselves.
> > > > > 
> > > > > Would you two be fine with that? Or at least one of you?
> > > > 
> > > > My preference would be for the patches to go through the powerpc tree
> > > > unless there is a good reason for them to go via another tree.
> > > 
> > > I have no problem with that. The only thing is that we have a lot of 
> > > pending work still in the linux-tip tree, which you may need to pull 
> > > in to get these patches working. Well, there's two or three commits 
> > > in the generic code that I know the PPC code is dependent on.
> > > 
> > > I could give you a list of commits in tip that need to go mainline 
> > > first before we can pull in the PPC changes. Then you could wait 
> > > till those changes make it into 29 and then you could push the PPC 
> > > modifications in from your tree.
> > 
> > note that this inserts a lot of (unnecessary) serialization and a 
> > window of non-testing - by all likelyhood this will delay ppc ftrace 
> > to v2.6.30 or later kernels.
> 
> Well, note that I said "unless there is a good reason".  If it does 
> need to go via your tree, it can, though I don't see that it will 
> get much testing on powerpc there, and having it there will make it 
> harder to manage any conflicts with the other stuff I have queued 
> up.

this is the diffstat:

 arch/powerpc/Kconfig              |    2 +
 arch/powerpc/include/asm/ftrace.h |   14 +-
 arch/powerpc/include/asm/module.h |   16 ++-
 arch/powerpc/kernel/ftrace.c      |  460 +++++++++++++++++++++++++++++++++---
 arch/powerpc/kernel/idle.c        |    5 +
 arch/powerpc/kernel/module_32.c   |   10 +
 arch/powerpc/kernel/module_64.c   |   13 +
 scripts/recordmcount.pl           |   18 ++-
 8 files changed, 495 insertions(+), 43 deletions(-)

90% of it creates new code that shouldnt be collision-happy.

it does not "need" to go via tip/tracing, i just pointed out the 
effects of the proposed workflow and i'm just trying to find a more 
efficient workflow for it - while not impacting yours either. I think 
it can be done - git gives us tons of tools to do this intelligently.

> How much generic stuff that's not upstream do the powerpc ftrace 
> patches depend on?

a lot:

   66 files changed, 3266 insertions(+), 985 deletions(-)

and it's all in flux (we are in the middle of the development cycle), 
so i dont think it would be a good idea for you to pull those bits 
into the powerpc tree.

Maybe Steve could do the following trick: create a Linus -git based 
branch that uses the new APIs but marks ppc's ftrace as "depends 0" in 
the powerpc Kconfig. (the new ftrace.c wont build)

You could pull that tree into the powerpc tree and everything should 
still work fine in PPC - sans ftrace.

In tip/tracing we'd merge it too (these commits will never be 
rebased), and we'd also remove the depends 0 from the powerpc Kconfig. 
That sole change wont conflict with anything powerpc.

It would all play out just fine in linux-next: we'd have both the 
latest powerpc bits and the latest ftrace bits on powerpc. You could 
test the non-ftrace impact of Steve's changes in the powerpc tree as 
well and have it all part of your usual workflow.

The 2.6.29 merge window would be trouble-free as well: since the 
sha1's are the same, any of the trees can be merged upstream without 
having to wait for the other one and without creating conflicts or 
other trouble for the other one.

Hm?

	Ingo