Messages in this thread | | | Date | Tue, 02 Jun 2009 16:12:08 -0700 | From | David Daney <> | Subject | Re: [PATCH 11/12] hw-breakpoints: ftrace plugin for kernel symbol tracing using HW Breakpoint interfaces |
| |
Frederic Weisbecker wrote: > From: K.Prasad <prasad@linux.vnet.ibm.com> > > This patch adds an ftrace plugin to detect and profile memory access over kernel > variables. It uses HW Breakpoint interfaces to 'watch memory addresses. > > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> > --- > kernel/trace/Kconfig | 21 ++ > kernel/trace/Makefile | 1 + > kernel/trace/trace.h | 23 ++ > kernel/trace/trace_ksym.c | 525 +++++++++++++++++++++++++++++++++++++++++ > kernel/trace/trace_selftest.c | 53 ++++ > 5 files changed, 623 insertions(+), 0 deletions(-) > create mode 100644 kernel/trace/trace_ksym.c [...] > + entry->ksym_hbp->info.name = ksymname; > + entry->ksym_hbp->info.type = op; > + entry->ksym_addr = entry->ksym_hbp->info.address = addr; > +#ifdef CONFIG_X86 > + entry->ksym_hbp->info.len = HW_BREAKPOINT_LEN_4; > +#endif
What if the symbol referred to an object of size other than 4? This would clearly be incorrect in that case.
> + entry->ksym_hbp->triggered = (void *)ksym_hbp_handler; > + > + ret = register_kernel_hw_breakpoint(entry->ksym_hbp);
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
| |