* [ltt-dev] [RFC] UST instrumentation API @ 2011-04-13 20:59 Mathieu Desnoyers 2011-04-14 14:53 ` David Goulet 0 siblings, 1 reply; 9+ messages in thread From: Mathieu Desnoyers @ 2011-04-13 20:59 UTC (permalink / raw) OK, so I took care of most of the instrumentation API, but some questions need discussion. * Tracepoints: - Currently handled: #include <ust/tracepoint.h> tracepoint(name, ...) register_tracepoint(name, ...) unregister_tracepoint(name, ...) TRACEPOINT_LIB - Questions/suggestions: About: DECLARE_TRACE() DEFINE_TRACE() -> 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. TRACE_EVENT() could be the macro replacing these, but I would recommend using a name like "TRACEPOINT_TEMPLATE()", which is what it really is. TP_PARAMS() TP_PROTO() TP_ARGS() I recommend to merge all these into "TP_PARAMS()". Through the "TRACEPOINT_TEMPLATE()" macro, these will all become internal anyway, so not exposed to the users. 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() Feedback is welcome, Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 2011-04-13 20:59 [ltt-dev] [RFC] UST instrumentation API Mathieu Desnoyers @ 2011-04-14 14:53 ` David Goulet 2011-04-14 19:02 ` Nils Carlson 0 siblings, 1 reply; 9+ messages in thread From: David Goulet @ 2011-04-14 14:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 2011-04-14 14:53 ` David Goulet @ 2011-04-14 19:02 ` Nils Carlson 2011-04-14 19:28 ` Mathieu Desnoyers 0 siblings, 1 reply; 9+ messages in thread From: Nils Carlson @ 2011-04-14 19:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 2011-04-14 19:02 ` Nils Carlson @ 2011-04-14 19:28 ` Mathieu Desnoyers 2011-04-19 21:56 ` Mathieu Desnoyers 0 siblings, 1 reply; 9+ messages in thread From: Mathieu Desnoyers @ 2011-04-14 19:28 UTC (permalink / raw) * Nils Carlson (nils.carlson at ludd.ltu.se) wrote: > > 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. In TRACE_EVENT, the probe code generation is only done if "CREATE_TRACE_POINTS" is defined before including the instrumentation header. This is necessary to make sure we don't generate duplicated probe code when including the header in multiple objects. We'd have to ensure that this "define" is also standardized, as it is part of the API. >> >>> >>> 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. I'd like to keep something close to "tracepoint", especially since we now use "tracepoint(name, ...)" as instrumentation API. I don't see much need to make the "event" declaration an entirely different API; this seems more confusing than anything else. It needed to be that way in the kernel to handle the transition, but here, in UST, we can design it properly. I'd prefer to keep "ust_" and "UST_" only for ust-lib specific APIs, which is not the case for this one. So maybe TRACEPOINT_EVENT() ? and while we are there, the #define that would control definition of tracepoint callbacks could be: #define TRACEPOINT_DEFINE (not sure if the preprocessor #define vs action of "defining" an object might not confuse users though) > >> >>> >>> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 2011-04-14 19:28 ` Mathieu Desnoyers @ 2011-04-19 21:56 ` Mathieu Desnoyers 2011-04-20 18:03 ` Nils Carlson 0 siblings, 1 reply; 9+ messages in thread From: Mathieu Desnoyers @ 2011-04-19 21:56 UTC (permalink / raw) * Mathieu Desnoyers (mathieu.desnoyers at efficios.com) wrote: > * Nils Carlson (nils.carlson at ludd.ltu.se) wrote: > > > > 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. > > In TRACE_EVENT, the probe code generation is only done if > "CREATE_TRACE_POINTS" is defined before including the instrumentation > header. This is necessary to make sure we don't generate duplicated > probe code when including the header in multiple objects. > > We'd have to ensure that this "define" is also standardized, as it is > part of the API. > > >> > >>> > >>> 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. > > I'd like to keep something close to "tracepoint", especially since we > now use "tracepoint(name, ...)" as instrumentation API. I don't see much > need to make the "event" declaration an entirely different API; this > seems more confusing than anything else. It needed to be that way in the > kernel to handle the transition, but here, in UST, we can design it > properly. > > I'd prefer to keep "ust_" and "UST_" only for ust-lib specific APIs, > which is not the case for this one. > > So maybe > > TRACEPOINT_EVENT() ? > > and while we are there, the #define that would control definition of > tracepoint callbacks could be: > > #define TRACEPOINT_DEFINE > > (not sure if the preprocessor #define vs action of "defining" an object > might not confuse users though) 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. 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 2011-04-19 21:56 ` Mathieu Desnoyers @ 2011-04-20 18:03 ` Nils Carlson 2011-04-20 18:03 ` Nils Carlson ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Nils Carlson @ 2011-04-20 18:03 UTC (permalink / raw) 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.... :-) TRACEPOINT_CREATE would be what exactly? Afraid I got a bit lost... /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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20110420/8b834a8c/attachment.htm> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 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 2 siblings, 0 replies; 9+ messages in thread From: Nils Carlson @ 2011-04-20 18:03 UTC (permalink / raw) 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.... :-) TRACEPOINT_CREATE would be what exactly? Afraid I got a bit lost... /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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110420/8b834a8c/attachment-0003.htm> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 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 2 siblings, 0 replies; 9+ messages in thread From: Nils Carlson @ 2011-04-20 18:03 UTC (permalink / raw) 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.... :-) TRACEPOINT_CREATE would be what exactly? Afraid I got a bit lost... /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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110420/8b834a8c/attachment-0002.htm> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [ltt-dev] [RFC] UST instrumentation API 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 2 siblings, 0 replies; 9+ messages in thread From: Mathieu Desnoyers @ 2011-04-20 18:10 UTC (permalink / raw) * 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-04-20 18:10 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-04-13 20:59 [ltt-dev] [RFC] UST instrumentation API Mathieu Desnoyers 2011-04-14 14:53 ` David Goulet 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox