[ltt-dev] [UST RELEASE]ust 0.13

[Stefan Hajnoczi]

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?

Stefan