On Thu, Nov 10, 2011 at 06:12:23AM -0600, Jason Wessel wrote: > 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.
Yeah sure, in any case we want to keep the slot allocation/reservation handled in kernel/event/hw_breakpoint.c -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
