Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC

Steven Rostedt
2008-11-19T12:13:57Z

On Wed, 19 Nov 2008, Ingo Molnar wrote:
>
> 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)

There's only two generic commits that need to be added for the PowerPC
code to work.

ftrace: pass module struct to arch dynamic ftrace functions
ftrace: allow NULL pointers in mcount_loc

I've already ported them to mainline to test PowerPC there.
Paul could use these two versions and keep ftrace in a separate branch in
his tree. This way all the PowerPC code will be there, and actually can be
tested. They may still hit the same bugs that we have fixed in tip, but
those should all be minor, since any major bug is already in mainline or
on its way.

>
> 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?

If Paul uses the ported two generic commits, then he would need to keep
that in a separate branch that will never go upstream. He could pull in
the other PowerPC patches and do as you said, keep the depend off.

I can make two branches that Paul could pull from. One would have this
code disabled in the config, and just be the PowerPC port. Although, we
would need to figure out the best way to keep it disabled. Disable it
after the patches? The patches themselve enable it.

And then I could make another branch with the back port of the two commits
that Paul would never push upstream. This would allow for the PowerPC guys
to test the code in their tree without waiting for it. We just need to
trust that Paul will not push those commits ;-)

Actually, I can change the subject of those commits to have at the
beginning:

NOT FOR UPSTREAM ftrace: ....

What do you guys think?

-- Steve