Re: [UST PATCH] Tracepoints: add wrapper tracepoint() macro

[Josh Stone <jistone@redhat.com>]

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