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

[Nils Carlson]

Mathieu Desnoyers wrote:
> * Paul Wögerer (paul_woegerer at mentor.com) wrote:
>   
>> 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.
>>     
>
> Sure, this use-case will be taken care of, the question is "how",
>
>   
>>> 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 );
>>     
>
> Yes, the main difference when passing through the ltt-sessiond daemon is
> that your application would be two things:
>
> a) a trace data producer (hence it links with libust).
> b) a trace controller (hence it links with the new liblttngctl)
>
> So the application can set the marker states, start/stop tracing, spawn
> a consumer daemon, etc, but this is not done directly with a libust API:
> it's done through the ltt-sessiond throught the liblttngctl API, as if
> it was a normal "trace control" application.
>
>   
Well, as libust can be run standalone I don't think there is any reason 
to limit this to having to have lttng-tools installed.

But this patch isn't actually about making a new libustctl command but 
adding direct command access within libust.

But I think we will need this, some applications will want to create 
traces for internal use and going via the sessiond will add quite an 
overhead.

We should try to plan this API out properly though.

/Nils


> Does that make sense ?
>
> Thanks,
>
> Mathieu
>
>   
>> --
>> Thanks,
>> PaulW
>>
>>     
>
>