Messages in this thread | | | Date | Thu, 4 Jun 2009 21:15:00 +0530 | From | "K.Prasad" <> | Subject | Re: [PATCH 11/12] hw-breakpoints: ftrace plugin for kernel symbol tracing using HW Breakpoint interfaces |
| |
On Wed, Jun 03, 2009 at 02:38:12AM +0200, Frederic Weisbecker wrote: > On Tue, Jun 02, 2009 at 04:12:08PM -0700, David Daney wrote: > > Frederic Weisbecker wrote: > >> From: K.Prasad <prasad@linux.vnet.ibm.com>
> > I hate to sound like a broken record, but could some one explain to me > > again why it is a good idea to design a new API that requires processor > > specific #ifdefs to be sprinkled all around generic kernel code? > > > > Back in: > > http://lkml.org/lkml/2008/12/4/329 > > and > > http://lkml.org/lkml/2009/5/21/189 > > > > I raised doubts about this hw-breakpoint thing being generic and the > > responses made think that the processor specific portions would be > > isolated in the processor specific parts of the kernel. I now see that > > I was wrong. > > > > When we add sparc, MIPS, ppc... Support it would be nice to not have to > > add all our own #ifdefs to this, but instead have a generic interface > > that will not need changes. > > > > David Daney > > I was discussing about it with Prasad few hours ago :) > > The fact is that archs support the hardware breakpoints in > very different ways each. > Some of them support read breakpoint, others not (x86). > Some support addresses range, others (x86). > > But still it would be nice to gather the most common > breakpoints operations through a real generic wrapper > that relies on arch specific implmentation in > background. > > Such as setting very simple x/w/r breakpoints... > > Well Prasad and Alan Stern could tell more about it, > I wait for their answer. > > Anyway it's a fairly new Api that can still evolve. > The basis are set but can still be improved and more high level > and generic things can still be implemented. >
I think this concern can be partially addressed, atleast as far as the breakpoint length is concerned. I've added my comments in the response to David Daney here: http://lkml.org/lkml/2009/6/4/303.
Hope that the changes proposed there is acceptable to the community.
Thanks, K.Prasad
| |