[ltt-dev] [RFC] UST instrumentation API
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Wed Apr 20 14:10:18 EDT 2011
* Nils Carlson (nils.carlson at ludd.ltu.se) wrote:
>
> On Apr 19, 2011, at 11:56 PM, Mathieu Desnoyers wrote:
>>
>> How about:
>>
>> "TRACEPOINT_EVENT()" and "#define TRACEPOINT_CREATE" ?
>>
>> Ideally, I'd like to settle this API and release a UST 0.13 this week,
>> so people who want to start instrumenting their code can use the new
>> Markers API while we move to the TRACEPOINT_EVENT infrastructure.
>>
>
> Tracepoint event sounds good... you sort of connect tracepoints with
> events then.... :-)
OK :)
>
> TRACEPOINT_CREATE would be what exactly? Afraid I got a bit lost...
If an application has many objects, some of them calling tracepoint(),
but only one of them needed to actually create the tracepoint callbacks,
then we would have:
myobja.c:
#include <mytracepoints.h>
void fcta()
{
tracepoint(name, ...);
}
myobjb.c:
#include <mytracepoints.h>
void fctb()
{
tracepoint(name, ...);
}
myobj_tracepoint.c: (contains the tracepoint callbacks)
#define TRACEPOINT_CREATE
#include <mytracepoints.h>
So I'm not sure if "TRACEPOINT_CREATE" is clear enough. What I mean to
say is that if this is defined, then the header that describes the
TRACEPOINT_EVENT() will generate the callback (probe) code when
included. So maybe:
#define TRACEPOINT_CREATE_PROBES
would be more self-explanatory ?
Thanks,
Mathieu
>
> /Nils
>
>> Thanks,
>>
>> Mathieu
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> UST Markers (main API members):
>>>>>>
>>>>>> #include<ust/marker.h>
>>>>>>
>>>>>> ust_marker(name, "fmt", ...)
>>>>>> UST_MARKER_NOARGS
>>>>>> GET_UST_MARKER()
>>>>>> DEFINE_UST_MARKER(name, ...)
>>>>>> ust_marker_probe_unregister()
>>>>>> ust_marker_probe_register()
>>>>>> ust_marker_synchronize_unregister()
>>>>>> UST_MARKER_LIB
>>>>>>
>>>>>> Will be eventually phased-out with the new
>>>>>> TRACEPOINT_TEMPLATE() and
>>>>>> CTF:
>>>>>> DEFINE_UST_MARKER_TP()
>>>>>> ust_marker_tp()
>>>>>>
>>>>>
>>>>> No problem. Simpler is better and this API will be UST specific so
>>>>> rtfm at that point :).
>>>>
>>>> Just one question, these are UST internal right? I mean, not to be
>>>> confused with the ustctl functions?
>>>
>>> Not sure I understand your question. But the "ust_marker()" is an API
>>> exposed to application willing to do ad-hoc tracing relying directly
>>> on
>>> UST. These application libraries using ust_marker() would have to
>>> define
>>> UST_MARKER_LIB. UST_MARKER_NOARGS is also needed. For the rest, I
>>> agree
>>> that it's more UST-internal.
>>>
>>> Thanks,
>>>
>>> Mathieu
>>>
>>>>
>>>> /Nils
>>>>
>>>>>
>>>>> Thanks
>>>>> David
>>>>>
>>>>>> Feedback is welcome,
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Mathieu
>>>>>>
>>>>>
>>>>> --
>>>>> David Goulet
>>>>> LTTng project, DORSAL Lab.
>>>>>
>>>>> PGP/GPG : 1024D/16BD8563
>>>>> BE3C 672B 9331 9796 291A 14C6 4AF7 C14B 16BD 8563
>>>>>
>>>>> _______________________________________________
>>>>> ltt-dev mailing list
>>>>> ltt-dev at lists.casi.polymtl.ca
>>>>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>>>
>>>
>>> --
>>> Mathieu Desnoyers
>>> Operating System Efficiency R&D Consultant
>>> EfficiOS Inc.
>>> http://www.efficios.com
>>
>> --
>> Mathieu Desnoyers
>> Operating System Efficiency R&D Consultant
>> EfficiOS Inc.
>> http://www.efficios.com
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list