[ltt-dev] [UST RELEASE]ust 0.13

[Mathieu Desnoyers]

* 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 ?

Thanks,

Mathieu

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