From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Fri, 4 Nov 2011 15:31:32 -0400
Subject: [ltt-dev] [RFC] UST Tracepoint API Changes
In-Reply-To: <4EB4194E.9080700@ericsson.com>
References: <20111102140027.GA29033@Krystal> <4EB4194E.9080700@ericsson.com>
Message-ID: <20111104193132.GA19722@Krystal>

* 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