[ltt-dev] [UST PATCH] Request: Make wait_for_buffer_consumption visible

[Paul Wögerer]

Hi Mathieu,

thanks for your reply, see comments below.

On 03/17/2011 02:07 PM, Mathieu Desnoyers wrote:
> * Paul Wögerer (paul_woegerer at mentor.com) wrote:
>> Hi,
>>
>> I'm trying to use LTTng UST as a backend for function call tracing. The
>> following pseudocode shows what we basically to:
>>
>> ustcmd_set_marker_state( "call_trace", call, enter, 1, pid );
>> ustcmd_set_marker_state( "call_trace", call, inside, 1, pid );
>> ustcmd_set_marker_state( "call_trace", call, exit, 1, pid );
>>
>> ustcmd_create_trace( "call_trace", pid );
>> ustcmd_start_trace( "call_trace", pid );
>>
>> ...
>> ... Lots of auto-generated code that makes use of call.enter/inside/exit
>> markers
>> ...
>>
>> ustcmd_stop_trace( "call_trace", pid );
>> ustcmd_destroy_trace( "call_trace", pid );
>>
>> This works very well in general but whenever an executable runs only for
>> a very short amount of time I run into troubles with stopping/destroying
>> my "call_trace" properly.
>>
>> This is caused by the fact that stop/destroy_trace runs before buffer
>> consumption completed on the ust-consumerd side. This is easy to prevent
>> by some code that implements waiting for buffer consumption. Fortunately
>> this is already available in tracectl.c keepalive().
>>
>> The following patch puts the "waiting for buffer consumption" code into
>> its own function and makes it visible externally via ust/ustctl.h. Using
>> function wait_for_buffer_consumption() before stop/destroy_trace solves
>> the problem for me.
>>
>> Please apply the patch from the attachment to the ust trunk to make
>> wait_for_buffer_consumption()available for everyone.
> This brings up two interesting questions:
>
> a) Do we want to expose the ustcmd_* API to applications at this point
>     in the development, given the changes that are coming ? The expected
>     way for an application to use tracing would be to interact with the
>     external app/lib responsible for tracing rather than controlling this
>     internally.

While I think the non-intrusive approach that is currently under 
development is a good thing in terms of usability I also see the 
advantages of having full control where exactly in the sources I want to 
start and stop tracing. This feature of the current version of libust 
should not be abounded. It gives a lot of flexibility that would be 
hardly missed.

It should be possible to have an executable running that is under 
external trace control while at the same time allowing the executable to 
create its own specialized traces based on some conditions that only the 
executable itself knows.

> b) Do we want to *ever* expose the ustcmd_* API ? I'm not so sure,
>     because it drastically changes the way we think about libust.
>     In the upcoming future, my vision is that libust's only API used by
>     the application is trace_event/markers. Everything else should be
>     internal to libust, only presented to the ltt-sessiond through
>     the communication socket. I'm concerned about the fact that
>     supporting more than that will send us deep into both API _and_
>     locking hells.

Would that interface allow me to _dynamically_ declare and use markers 
inside my code as I can do now with ustcmd_set_marker_state ?
For example:

if(do_call_trace)
{
   ustcmd_set_marker_state( "my_trace", call, enter, 1, pid );
   ustcmd_set_marker_state( "my_trace", call, inside, 1, pid );
   ustcmd_set_marker_state( "my_trace", call, exit, 1, pid );
}

if(do_function)
{
   ustcmd_set_marker_state( "my_trace", function, prolog, 1, pid );
   ustcmd_set_marker_state( "my_trace", function, epilog, 1, pid );
}

ustcmd_create_and_start_trace( "my_trace", pid );

--
Thanks,
PaulW