----- Original Message ----- > From: "Steven Rostedt" <rost...@goodmis.org> > To: "Thomas Gleixner" <t...@linutronix.de> > Cc: "LKML" <linux-kernel@vger.kernel.org>, "Jiang Liu" > <jiang....@linux.intel.com>, x...@kernel.org, "Linus Torvalds" > <torva...@linux-foundation.org>, "Andrew Morton" <a...@linux-foundation.org>, > "Bjorn Helgaas" <bhelg...@google.com>, > "Tony Luck" <tony.l...@intel.com>, "Borislav Petkov" <b...@alien8.de>, "Joerg > Roedel" <j...@8bytes.org>, "Marc > Zyngier" <marc.zyng...@arm.com>, "Yinghai Lu" <ying...@kernel.org>, "Alex > Williamson" <alex.william...@redhat.com>, > "Mathieu Desnoyers" <mathieu.desnoy...@efficios.com>, "Frederic Weisbecker" > <fweis...@gmail.com> > Sent: Monday, December 15, 2014 10:52:01 AM > Subject: Re: Status of tip/x86/apic > [...] > > > > I think the above can be solved, so we need to agree on a proper > > set of tracepoints. I came up with the following list: > > > > - trace_irqdomain_create(domain->id, domain->name, ...) > > Is that suppose to be a variable number of args? Tracepoints do not > support a variable length number of args passed in. I guess we could > add that, but it wont be for this merge window. > > I've added Mathieu and Frederic to the Cc list here.
Hi Steven, Let's wait and see if it's really required first. FWIW, at the user-space level in LTTng-UST, we have two distinct ways to do static instrumentation: * tracepoint(): similar to those within the Linux kernel, except that the tracepoint is wrapped in a define, so rather than calling: trace_foo(arg1, arg2); users call: tracepoint(foo, arg1, arg2); Which allows skipping over evaluation of "arg1" and "arg2" even if they have side-effects when the tracepoint is disabled. * tracef(): I also added a "tracef()" macro, provides a programmer interface very similar to printf(), but prints the pretty-printed into the trace buffers. It can be enabled dynamically similarly to tracepoints, but does not have per-site event names attached. They are either all enabled or disabled, and meant mainly for adding temporary debugging trace statements. So far, the feedback I got from end users seemed to split static instrumentation use-cases in two major categories: 1) Instrumentation added into the code base, well structured (tracepoints), meant to be deployed with the application for in-production use. They need to be low-overhead, 2) Very quick (and dirty) instrumentation, meant for one-off use while in development. IOW, a replacement to printf(), with which people are already familiar. Low-overhead still matters, but not as much as it does for (1). This is why we only implemented var arg support in tracef() so far. > > If we do support this (and if it is needed) we could make it use the > bprintf() infrastructure. It already supports just saving a format and > args directly to the the buffer, and a way to print them again. Happy new year :) Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/