Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: nils.carlson@ludd.ltu.se (Nils Carlson)
Subject: [ltt-dev] [RFC] UST instrumentation API
Date: Thu, 14 Apr 2011 21:02:55 +0200	[thread overview]
Message-ID: <53CC5900-4A0C-49FD-BC27-EF92039117E3@ludd.ltu.se> (raw)
In-Reply-To: <4DA70A63.6000801@polymtl.ca>


On Apr 14, 2011, at 4:53 PM, David Goulet wrote:

> Hola,
>
> I like the idea of making thing more simpler and more "namespace  
> oriented" for ust.
>
> On 11-04-13 04:59 PM, Mathieu Desnoyers wrote:
>> OK, so I took care of most of the instrumentation API, but some
>> questions need discussion.
>>
>> ->  given that the API presented to users will be  
>> "TRACE_EVENT()" (which
>> we should rename to something else to eliminate confusion), it might
>> make sense to make both of DECLARE_TRACE and DEFINE_TRACE internal to
>> tracepoints and don't expose them to the users.
>
> If I understand correctly what we want for ust, marker are staying,  
> tracepoint are getting replaced by trace event? So, considering this  
> fact, those two macros (declare_ and define_) should simply be not  
> supported anymore and eventually get rid of them?

This sounds good, though it will mean that we will always generate the  
"TRACE_EVENT" part of the tracepoint, that is, no tracepoints that  
don't generate data... But I think this is fine.
>
>>
>> TRACE_EVENT() could be the macro replacing these, but I would  
>> recommend
>> using a name like "TRACEPOINT_TEMPLATE()", which is what it really  
>> is.
>>
>
> A good concern raised by Steven R. is the fact that "TRACE_EVENT"  
> can and will confuse people with the ones in the kernel (in terms of  
> google search mostly!). So, a name like "TRACEPOINT_TEMPLATE" says  
> to me (normal person, no tracing knowledge, maybe my grand  
> mother!) : this is tracepoint related, nothing to do with trace  
> event and I don't want to modify a template right... (totally  
> confused :P).
>
> So, should it be more "TRACE EVENT" user-space oriented for the name?
>
> UTRACE_EVENT --> confusing with utrace
> UPROBE... --> again, confusing with uprobe...
> UST_TRACE_EVENT --> ust stands for user-space tracing (and not LTTng  
> user-space tracer :P)
>
> ... maybe we need more brainstorm... I'm out of ideas...

What about UST_EVENT ? Though I thought we were going to "share" the  
tracepoints, so this might not be a good name, on the other hand, it  
does sound good: Userspace Trace Event, in fact, I would say that we  
can use this name even if we do share it. Its a good description.

>
>>
>> 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?

/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




  reply	other threads:[~2011-04-14 19:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-13 20:59 Mathieu Desnoyers
2011-04-14 14:53 ` David Goulet
2011-04-14 19:02   ` Nils Carlson [this message]
2011-04-14 19:28     ` Mathieu Desnoyers
2011-04-19 21:56       ` Mathieu Desnoyers
2011-04-20 18:03         ` Nils Carlson
2011-04-20 18:03           ` Nils Carlson
2011-04-20 18:03           ` Nils Carlson
2011-04-20 18:10           ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CC5900-4A0C-49FD-BC27-EF92039117E3@ludd.ltu.se \
    --to=nils.carlson@ludd.ltu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox