On Mon, 2010-01-25 at 00:48 +0530, K.Prasad wrote: > > Some of the benefits of using these generic interfaces include: > - Interoperability with other users of debug register (such as > parallel > kernel requests) i.e. non-exclusive use of debug registers. > - Enables debugging/tracing tools such as perf-events and ftrace to > make > use of debug registers. > - Re-use of common code available in kernel (kernel/hw_breakpoint.c). > > Let me know what you think.
This might have changed but last I looked the "generic" breakpoint interface was still too x86-centric and wasn't capable of expressing some of the features of the BookE debug register set such as the data value compare, the ranged breakpoints, etc... I'd rather have this more dedicated and more complete interface merged for gdb's sake, and in a second step look at unifying. I believe that the generic breakpoint infrastructure should not be the mid-layer. IE. It cannot be made in any clean shape of form, to express all of the subtle features that a given architecture or platform can support and as such would always be inferior to a dedicated one. I can see the interest in exposing some kind of generic API that implements a common subset of breakpoint or watchpoint facilities to generic code such as the event tracer. This could be layered on top of an arch specific mechanism But having the generic mechanism at the core for everybody is another attempt of "make everybody look like x86" which I believe in this case is sub optimal. Again, I might have missed some evolutions of the latest versions of your infrastructure that would make it good enough to fully bridge the gap with our requirements, and I'll let Shaggy decide here what he wants to do. But I will not block his current patches neither if he thinks that they are good enough as is. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
