On Thu, May 19, 2011 at 10:33 PM, Mathieu Desnoyers <[email protected]> wrote: > * Stefan Hajnoczi ([email protected]) wrote: >> On Thu, May 19, 2011 at 2:22 PM, Mathieu Desnoyers >> <[email protected]> wrote: >> > * Nils Carlson ([email protected]) 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
