[ltt-dev] [RFC] UST Tracepoint API Changes

[ltt-dev] [RFC] UST Tracepoint API Changes

[Mathieu Desnoyers]

Hi,

Following discussions at LinuxCon, there are two changes I would like to
propose for the TRACEPOINT_EVENT API. Comments are welcome:

1) Change the first argument of TRACEPOINT_EVENT, defined as:

  < [com_company_]project_[component_]event >

  for two arguments, separated by a comma:

  < [com_company_]project[_component] >, < event >

This would be more in line with the Dtrace "provider, event" scheme,
which is already very much in use for instrumentation. This would allow
application developers to make the mapping to dtrace instrumentation
they might already have more easiy.

2) Not sure about the following one: TRACEPOINT_EVENT is quite long to
type in, and so it "tracepoint()", and the upcoming
"tracepoint_printf()". I'm thinking about going for shorter names, but I
also want to try not to get conflicts with existing code out there.
Ideas on a shorter yet explanatory name would be very welcome.

tp_* seems a little bit short and prone to conflicts.
tracep_ sounds too much like ptrace.
tracept_ might be good enough. It's only downside might be to sound like
"trace-pity" when we say it out loud. ;-)

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] [RFC] UST Tracepoint API Changes

[Matthew Khouzam]

On 11-11-02 10:00 AM, Mathieu Desnoyers wrote:
> Hi,
>
> Following discussions at LinuxCon, there are two changes I would like to
> propose for the TRACEPOINT_EVENT API. Comments are welcome:
>
> 1) Change the first argument of TRACEPOINT_EVENT, defined as:
>
>   < [com_company_]project_[component_]event >
>
>   for two arguments, separated by a comma:
>
>   < [com_company_]project[_component] >, < event >
>
> This would be more in line with the Dtrace "provider, event" scheme,
> which is already very much in use for instrumentation. This would allow
> application developers to make the mapping to dtrace instrumentation
> they might already have more easiy.
Basically to illustrate that:
TRACEPOINT_EVENT( com_efficios_babeltrace_reader_openfile, ... )
becomes
TRACEPOINT_EVENT( com_efficios_babeltrace_reader, openfile, ... )
I like it, it's not overly complex and forces people to better think out
their tracepoint names.
>
> 2) Not sure about the following one: TRACEPOINT_EVENT is quite long to
> type in, and so it "tracepoint()", and the upcoming
> "tracepoint_printf()". I'm thinking about going for shorter names, but I
> also want to try not to get conflicts with existing code out there.
> Ideas on a shorter yet explanatory name would be very welcome.
>
> tp_* seems a little bit short and prone to conflicts.
sounds like toilet paper, and it is used a lot with other projects.
> tracep_ sounds too much like ptrace.
also, the p is ambiguous, why not just trace_ at that point?
> tracept_ might be good enough. It's only downside might be to sound like
> "trace-pity" when we say it out loud. ;-)
pt is the unsaid shorthand for point. it would be easily understood by
most IMO. but at this point you are three letters away from tracepoint_
I would suggest going full length and letting those who don't like
typing either the option to use a code completing IDE like eclipse-cdt,
or making macros that make sense to them.
>
> Thanks,
>
> Mathieu
>

[ltt-dev] [RFC] UST Tracepoint API Changes

[Mathieu Desnoyers]

* Matthew Khouzam (matthew.khouzam at ericsson.com) wrote:
> 
> 
> On 11-11-02 10:00 AM, Mathieu Desnoyers wrote:
> > Hi,
> >
> > Following discussions at LinuxCon, there are two changes I would like to
> > propose for the TRACEPOINT_EVENT API. Comments are welcome:
> >
> > 1) Change the first argument of TRACEPOINT_EVENT, defined as:
> >
> >   < [com_company_]project_[component_]event >
> >
> >   for two arguments, separated by a comma:
> >
> >   < [com_company_]project[_component] >, < event >
> >
> > This would be more in line with the Dtrace "provider, event" scheme,
> > which is already very much in use for instrumentation. This would allow
> > application developers to make the mapping to dtrace instrumentation
> > they might already have more easiy.
> Basically to illustrate that:
>   TRACEPOINT_EVENT( com_efficios_babeltrace_reader_openfile, ... )
> becomes
>   TRACEPOINT_EVENT( com_efficios_babeltrace_reader, openfile, ... )
> I like it, it's not overly complex and forces people to better think out
> their tracepoint names.

OK. And in terms of UI, we have a few choices, feedback would be
welcome:

lttng enable-event -k provider.event_name
lttng enable-event -k provider/event_name
lttng enable-event -k provider:event_name

This would impact the way the events are shown in babeltrace too.
Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] [RFC] UST Tracepoint API Changes

[Mathieu Desnoyers]

* Matthew Khouzam (matthew.khouzam at ericsson.com) wrote:
> On 11-11-02 10:00 AM, Mathieu Desnoyers wrote:
[...]
> > 2) Not sure about the following one: TRACEPOINT_EVENT is quite long to
> > type in, and so it "tracepoint()", and the upcoming
> > "tracepoint_printf()". I'm thinking about going for shorter names, but I
> > also want to try not to get conflicts with existing code out there.
> > Ideas on a shorter yet explanatory name would be very welcome.
> >
> > tp_* seems a little bit short and prone to conflicts.
> sounds like toilet paper, and it is used a lot with other projects.

agreed.

> > tracep_ sounds too much like ptrace.
> also, the p is ambiguous, why not just trace_ at that point?

yep.

> > tracept_ might be good enough. It's only downside might be to sound like
> > "trace-pity" when we say it out loud. ;-)
> pt is the unsaid shorthand for point. it would be easily understood by
> most IMO. but at this point you are three letters away from tracepoint_
> I would suggest going full length and letting those who don't like
> typing either the option to use a code completing IDE like eclipse-cdt,
> or making macros that make sense to them.

I'm thinking that we could keep:

  TRACEPOINT_EVENT()/tracepoint() for the production-style
instrumentation. It is meant to be well-thought anyway, so it does not
hurt if it takes a bit more time to type in.

For debug-style instrumentation, trace_printf() looks really
interesting, and I don't find matches with google (the first matches are
trace_printk(), in the kernel).

Thoughts ?

Mathieu

> >
> > Thanks,
> >
> > Mathieu
> >
> 
> _______________________________________________
> 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

[ltt-dev] [RFC] UST Tracepoint API Changes

[Matthew Khouzam]

trace_printf sounds great, people already think printf when they have to
debug so this is a natural fit.

On 11-11-05 08:16 AM, Mathieu Desnoyers wrote:
> * Matthew Khouzam (matthew.khouzam at ericsson.com) wrote:
>> On 11-11-02 10:00 AM, Mathieu Desnoyers wrote:
> [...]
>>> 2) Not sure about the following one: TRACEPOINT_EVENT is quite long to
>>> type in, and so it "tracepoint()", and the upcoming
>>> "tracepoint_printf()". I'm thinking about going for shorter names, but I
>>> also want to try not to get conflicts with existing code out there.
>>> Ideas on a shorter yet explanatory name would be very welcome.
>>>
>>> tp_* seems a little bit short and prone to conflicts.
>> sounds like toilet paper, and it is used a lot with other projects.
> agreed.
>
>>> tracep_ sounds too much like ptrace.
>> also, the p is ambiguous, why not just trace_ at that point?
> yep.
>
>>> tracept_ might be good enough. It's only downside might be to sound like
>>> "trace-pity" when we say it out loud. ;-)
>> pt is the unsaid shorthand for point. it would be easily understood by
>> most IMO. but at this point you are three letters away from tracepoint_
>> I would suggest going full length and letting those who don't like
>> typing either the option to use a code completing IDE like eclipse-cdt,
>> or making macros that make sense to them.
> I'm thinking that we could keep:
>
>   TRACEPOINT_EVENT()/tracepoint() for the production-style
> instrumentation. It is meant to be well-thought anyway, so it does not
> hurt if it takes a bit more time to type in.
>
> For debug-style instrumentation, trace_printf() looks really
> interesting, and I don't find matches with google (the first matches are
> trace_printk(), in the kernel).
>
> Thoughts ?
>
> Mathieu
>
>>> Thanks,
>>>
>>> Mathieu
>>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>>