From mboxrd@z Thu Jan  1 00:00:00 1970
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Date: Wed, 20 Apr 2011 14:10:18 -0400
Subject: [ltt-dev] [RFC] UST instrumentation API
In-Reply-To: <00251A6D-FE11-49D1-B078-E854C9724D83@ludd.ltu.se>
References: <20110413205908.GA10716@Krystal> <4DA70A63.6000801@polymtl.ca>
	<53CC5900-4A0C-49FD-BC27-EF92039117E3@ludd.ltu.se>
	<20110414192834.GA21756@Krystal> <20110419215635.GA15969@Krystal>
	<00251A6D-FE11-49D1-B078-E854C9724D83@ludd.ltu.se>
Message-ID: <20110420181017.GA6609@Krystal>

* 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