On Fri, May 20, 2011 at 9:35 PM, Mathieu Desnoyers <[email protected]> wrote: > * Mathieu Desnoyers ([email protected]) wrote: >> * Stefan Hajnoczi ([email protected]) wrote: >> > On Fri, May 20, 2011 at 7:24 AM, Stefan Hajnoczi <[email protected]> >> > wrote: >> > > 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. >> > >> > 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
