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
next prev parent 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