[ltt-dev] [UST RELEASE]ust 0.13

[Stefan Hajnoczi]

On Fri, May 20, 2011 at 9:35 PM, Mathieu Desnoyers
<compudj at krystal.dyndns.org> wrote:
> * 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.

Okay, that is great.

Stefan