On 11/10/2011 02:58 AM, Frederic Weisbecker wrote: > On Mon, Nov 07, 2011 at 02:45:17PM +0000, Will Deacon wrote: >> Hi Frederic, >> >> On Wed, Nov 02, 2011 at 07:42:04AM +0000, Frederic Weisbecker wrote: >>> On Tue, Nov 01, 2011 at 10:20:04AM -0600, David Ahern wrote: >>>> Right. Originally it could be enabled/disabled. Right now it cannot be, >>>> but I believe Frederic is working on making it configurable again. >>>> >>>> David >>> Yep. Will Deacon is working on making the breakpoints able to process >>> pure arch informations (ie: without beeing forced to use the perf attr >>> as a midlayer to define them). >>> >>> Once we have that I can seperate the breakpoints implementation from perf >>> and make it opt-able. >> How do you foresee kdb fitting into this? I see that currently [on x86] we >> cook up perf_event structures with a specific overflow handler set. If we >> want to move this over to using a completely arch-defined structure, then >> we're going to end up with an overflow handler field in both perf_event >> *and* the arch-specific structure, which doesn't feel right to me. >> >> Of course, if the goal is only to separate ptrace (i.e. user debugging) from >> the perf dependency then we don't need the overflow handler because we'll >> always just send SIGTRAP to the current task. >> >> Any ideas? > I don't know if we want to convert x86/kgdb to use pure arch breakpoints. > If kgdb one day wants to extend this use to generic code, it may be a good > idea to keep the things as is. I don't know, I'm adding Jason in Cc. I think the important part is to share the allocation code (meaning who owns which break point slots). This is why kgdb/kdb allocates the perf structures. The kgdb code will also directly write data to the slots once it has reserved them it would be good to share this code, but it was not shared because it was not usable early enough in the boot cycle on x86. Certainly there are others who could consume the same infrastructure such as kprobes. Jason. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
