Messages in this thread |  | | | Date | Tue, 15 Jul 2008 15:08:16 -0400 | | From | Mathieu Desnoyers <> | | Subject | Re: [patch 01/15] Kernel Tracepoints |
| |
* Masami Hiramatsu (mhiramat@redhat.com) wrote: > Hi, > > Peter Zijlstra wrote: > > On Tue, 2008-07-15 at 10:46 -0400, Mathieu Desnoyers wrote: > > > >> Talking about headers, I have noticed that placing headers with the code > >> may not be as clean as I would hope. For instance, the kernel/irq-trace.h > >> header, when included from kernel/irq/handle.c, has to be included with: > >> > >> #include "../irq-trace.h" > >> > >> Which is not _that_ bad, but we we want to instrument the irq handler > >> found in arch/x86/kernel/cpu/mcheck/mce_intel_64.c, including > >> #include "../../../../../kernel/irq-trace.h" makes me go "yeeeek!" > >> > >> How about creating include/trace/irq.h and friends ? > > > > Might as well.. anybody else got opinions? > > I just wonder why DEFINE_TRACE are used in separated headers > instead of include/linux/irq.h directly. > > anyway, #include <trace/XXX.h> is good to me. >
Having these headers all placed nicely together will make it easier for people who are looking for already existing tracepoints to locate them.
It's also worth noting that I am considering deploying a standard set of tracepoints for userspace in a relatively short time frame. e.g. having the ability to add tracepoints to pthread mutexes seems like an interesting thing to have. And that will definitely require those headers to sit somewhere around /usr/include/trace/ or something similar, otherwise trying to locate those tracepoints will be hellish.
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
|  |