[ltt-dev] [UST RELEASE]ust 0.13

Mathieu Desnoyers compudj at krystal.dyndns.org
Fri May 20 16:35:29 EDT 2011


* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> * Stefan Hajnoczi (stefanha at gmail.com) wrote:
> > On Fri, May 20, 2011 at 7:24 AM, Stefan Hajnoczi <stefanha at gmail.com> wrote:
> > > On Thu, May 19, 2011 at 10:33 PM, Mathieu Desnoyers
> > > <compudj at krystal.dyndns.org> wrote:
> > >> * Stefan Hajnoczi (stefanha at gmail.com) wrote:
> > >>> On Thu, May 19, 2011 at 2:22 PM, Mathieu Desnoyers
> > >>> <compudj at krystal.dyndns.org> wrote:
> > >>> > * Nils Carlson (nils.carlson at ericsson.com) wrote:
> > >>> >> Announcing the release of ust 0.13
> > >>> >>
> > >>> >> ChangeLog:
> > >>> >> 2011-05-19 ust 0.13
> > >>> >>         * API CHANGE!!! trace_mark has been deprecated, new ust_maker,
> > >>> >> without
> > >>> >>         channel name. ex. ust_marker(name, <format>, args...)
> > >>> >
> > >>> > Small note: for the deprecation process, we're leaving the old
> > >>> > "trace_mark" macros there for a few UST versions, but they will be
> > >>> > deprecated over time. We might enable compiler warnings in the next
> > >>> > release with the gcc "deprecated" attribute.
> > >>> >
> > >>> >>         * Instrumentation API CHANGE!!! change from
> > >>> >> trace_<name>(args...) to
> > >>> >>         tracepoint(name, args...), register_trace_<name>(...) to
> > >>> >>         register_tracepoint(name, ...) and unregister_trace_<name>(...) to
> > >>> >>         unregister_tracepoint(name, ...)
> > >>> >
> > >>> > As a side-note for this one: by the end of the summer, typical use the
> > >>> > UST instrumentation will be:
> > >>> >
> > >>> > TRACEPOINT_EVENT() for declaration
> > >>> > tracepoint(name, ...) in the code.
> > >>>
> > >>> Has a point been reached where you are declaring the ust API stable?
> > >>>
> > >>> For users it is a problem when the API changes, it should not be
> > >>> necessary to bundle a specific version of ust with an application.
> > >>> Right now using a distro ust-dev package for building applications
> > >>> against is not feasible due to API changes in across versions.
> > >>>
> > >>> I think providing a stable API will increase adoption since
> > >>> distro-provided ust becomes useful and applications can begin to rely
> > >>> on tracing being there and working.
> > >>
> > >> Hi Stefan,
> > >>
> > >> We are in the process of getting there. I'm currently cleaning up the
> > >> exported APIs (it was a mess!) so we narrow down what is exported for
> > >> the whole world to see. In its current state, UST exposes the guts of
> > >> how it works, and that's definitely not good.
> > >>
> > >> But given the TRACEPOINT_EVENT()/tracepoint() interface work is in
> > >> progress (and I want to make sure I get things right before I commit to
> > >> this API being stable), we plan to let people use the ust_marker() API.
> > >> It is less pretty and a bit harder to maintain in the application due to
> > >> lack of central instrumentation header per application, and traces a bit
> > >> more slowly due to dynamic traversal of the format string, but it works
> > >> today. Nils is planning to work on a conversion from ust_marker() to CTF
> > >> that will keep the current API in place over the summer.
> > >>
> > >> If there is anything I can do to help out making the transition easier
> > >> for you, or something I should be aware of, please let me know!
> > >
> > > Thanks for the update, it helps and I will keep my eye out for future
> > > versions as things settle down.
> > 
> > One thing that comes to mind is that a pair of
> > UST_VERSION_MAJOR/UST_VERSION_MINOR #defines in the header files could
> > make it possible for applications to work with several versions of
> > ust.
> > 
> > Perhaps most applications are not like this, but because QEMU tracing
> > abstracts the tracer, it would be possible to check the version
> > constants and (hopefully) adjust accordingly.
> > 
> > Do these version constants already exist or would you be able to add them?
> 
> In the upcoming UST, the headers applications will care about are
> limited to:
> 
> ust/tracepoint.h (and ust/define_trace.h)
> ust/marker.h
> 
> (the rest of tracing will happen under the hood within libust)
> 
> So in that sense, I might be appropriate to add
> 
> TRACEPOINT_VERSION_MAJOR/MINOR
> MARKER_VERSION_MAJOR/MINOR
> 
> to each of these headers. Is that OK with you ?

After some discussions, we finally thought better of it, and propose to
define, in ust/version.h:

#define UST_VERSION_MAJOR	x
#define UST_VERSION_MINOR	y

simpler is better after all.

Thanks,

Mathieu


> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> 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




More information about the lttng-dev mailing list