This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [UST PATCH] Tracepoints: add wrapper tracepoint() macro
- From: Josh Stone <jistone at redhat dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Cc: Nils Carlson <nils dot carlson at ericsson dot com>, "ltt-dev at lists dot casi dot polymtl dot ca" <ltt-dev at lists dot casi dot polymtl dot ca>, Steven Rostedt <srostedt at redhat dot com>, Steven Rostedt <rostedt at goodmis dot org>, "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Mon, 11 Apr 2011 14:20:58 -0700
- Subject: Re: [UST PATCH] Tracepoints: add wrapper tracepoint() macro
- References: <20110410231812.GA3432@Krystal> <alpine.DEB.2.00.1104111402310.25638@as68123.uab.ericsson.se> <20110411141423.GA10639@Krystal>
On 04/11/2011 07:14 AM, Mathieu Desnoyers wrote:
> * Nils Carlson (nils.carlson@ericsson.com) wrote:
>> Hi,
>>
>> Again, looks good, but maybe we should prefix with ust_ ?
>
> This is a very important question. The goal of this tracepoint
> instrumentation is to replace the Dtrace instrumentation, which is
> somewhat implementation-driven (fixed number of u32 values AFAIK) by
> something more generic that allows a variable number of arguments.
> Mapping from a generic "tracepoint()" macro to DTrace macros could then
> be done in a compatibility header layer.
I'm not certain about DTrace's implementation, but I doubt that they
limit the args so much. In SystemTap, we permit 0-10 pointers and
integers up to 64-bit, with size and signed-ness maintained.
> So although it makes sense to use a ust_ prefix for all the UST-specific
> APIs, including e.g. probe registration to tracepoints, I'm really not
> convinced that the prefix would be appropriate for the instrumentation
> macros that will be called from the instrumented code.
>
> tracepoint() seems less likely to clash with other namespaces than
> "trace()", while still being generic enough.
>
> I'm open to comments, and especially interested to know what the
> SystemTAP team think about this issue.
I think in most projects where we have added SDT, they use wrapper
macros in their own namespace anyway, e.g. PYTHON_FUNCTION_ENTRY(),
perhaps so they can more easily be defined empty on other platforms. So
IMO it really only matters that your definitions don't conflict, and the
rest will probably be abstracted.
Josh