From: david.goulet@polymtl.ca (David Goulet)
Subject: [ltt-dev] [RFC] UST instrumentation API
Date: Thu, 14 Apr 2011 10:53:23 -0400 [thread overview]
Message-ID: <4DA70A63.6000801@polymtl.ca> (raw)
In-Reply-To: <20110413205908.GA10716@Krystal>
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?
>
> 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...
>
> 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 :).
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
next prev parent reply other threads:[~2011-04-14 14:53 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 [this message]
2011-04-14 19:02 ` Nils Carlson
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=4DA70A63.6000801@polymtl.ca \
--to=david.goulet@polymtl.ca \
/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