4 messages, 2 authors, 2015-01-08 · open the first message on its own page
From: Will Deacon <hidden>
Date: 2015-01-08 16:56:08
On Wed, Dec 31, 2014 at 03:21:18PM +0000, Pratyush Anand wrote:
Most of the stuff of kprobes-arm64.c can also be used by uprobes.c. So move all those part to common code area. In the process rename kprobe to probe whereever possible. No functional change.
In which case, can you merge this into the kprobes series (which we haven't merged yet)? Will
From: Pratyush Anand <hidden>
Date: 2015-01-08 17:34:03
On Thursday 08 January 2015 10:25 PM, Will Deacon wrote:
On Wed, Dec 31, 2014 at 03:21:18PM +0000, Pratyush Anand wrote:quoted
Most of the stuff of kprobes-arm64.c can also be used by uprobes.c. So move all those part to common code area. In the process rename kprobe to probe whereever possible. No functional change.In which case, can you merge this into the kprobes series (which we haven't merged yet)?
Yes, thats why these are just RFCs. I will send next version of uprobe only after kprobe patches are accepted into maintainer's tree. ~Pratyush
Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Will Deacon <hidden>
Date: 2015-01-08 17:36:10
On Thu, Jan 08, 2015 at 05:33:08PM +0000, Pratyush Anand wrote:
On Thursday 08 January 2015 10:25 PM, Will Deacon wrote:quoted
On Wed, Dec 31, 2014 at 03:21:18PM +0000, Pratyush Anand wrote:quoted
Most of the stuff of kprobes-arm64.c can also be used by uprobes.c. So move all those part to common code area. In the process rename kprobe to probe whereever possible. No functional change.In which case, can you merge this into the kprobes series (which we haven't merged yet)?Yes, thats why these are just RFCs. I will send next version of uprobe only after kprobe patches are accepted into maintainer's tree.
Ok, but it also makes sense to make kprobes refactoring changes *before* the patches are merged, as that reduces churn in mainline whilst you don't have any other dependencies. Will
From: Pratyush Anand <hidden>
Date: 2015-01-08 17:39:56
On Thursday 08 January 2015 11:06 PM, Will Deacon wrote:
On Thu, Jan 08, 2015 at 05:33:08PM +0000, Pratyush Anand wrote:quoted
On Thursday 08 January 2015 10:25 PM, Will Deacon wrote:quoted
On Wed, Dec 31, 2014 at 03:21:18PM +0000, Pratyush Anand wrote:quoted
Most of the stuff of kprobes-arm64.c can also be used by uprobes.c. So move all those part to common code area. In the process rename kprobe to probe whereever possible. No functional change.In which case, can you merge this into the kprobes series (which we haven't merged yet)?Yes, thats why these are just RFCs. I will send next version of uprobe only after kprobe patches are accepted into maintainer's tree.Ok, but it also makes sense to make kprobes refactoring changes *before* the patches are merged, as that reduces churn in mainline whilst you don't have any other dependencies.
Sure, Sure.. I too expect first two patches to be merged with kprobe series. I just did that to develop my uprobe code. ~Pratyush
Will