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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0811190650460.20272@gandalf.stny.rr.com>
Date:	Wed, 19 Nov 2008 07:10:02 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Paul Mackerras <paulus@...ba.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linuxppc-dev@...abs.org
Subject: Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC

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

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