[ltt-dev] [UST RELEASE]ust 0.13

[Stefan Hajnoczi]

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.

Stefan