[ltt-dev] lttng-agent and ust issues

[michael.sills.lavoie@gmail.com (Michael Sills-Lavoie)]

  On 2010-08-20 13:41, Alexandre Montplaisir wrote:
>
>> Hello everyone,
>>
>> [...]
>>
>> In addition to being a counterintuitive way to do things, this is not 
>> the way it
>> works for the kernel provider. This could cause problems for 
>> higher-level tools
>> like the eclipse control plugin, which, I believe, makes no 
>> distinction between
>> a ust trace and a kernel trace.
>
> Afaik, the UI in Eclipse-control shows both "kernel" and "user traces" 
> providers, and they go through different code paths, so the API 
> doesn't necessarily need to be identical for both. Still, as you say, 
> it would make it clear to have them at least similar.
In fact, the Eclipse UI shows both providers, but trust me, there are no 
different code paths in eclipse to control the two different providers. 
It just enumerates the different providers and tries to get information 
about both.

Michael
>
> Good stuff!
>
> Alexandre
>
>> There are already ustcmd functions to alloc and start the trace. 
>> Adding one to
>> only do the setup would help fix the problems with allocTrace,
>> setChannelSubbufNum, setChannelSubbufSize, setupTrace and 
>> writeTraceNetwork. I
>> believe libust is already setup to do this, it just needs to be exposed
>> throught ustcmd.
>>
>> getActiveTraceInfo, getActiveTraces, setChannelEnable, 
>> setChannelOverwrite and
>> getTraces would also need added functionality in ustcmd.
>>
>> I'm not sure about the implications of implementing 
>> stopWriteTraceLocal, as the
>> local tracing is currently done in another process (ustd).
>>
>> setChannelTimer does not set a per-channel timer, but instead uses a 
>> single
>> timer for all channels and for all traces the agent monitors. This 
>> was done as
>> a first step and will probably need to be elaborated a bit.
>>
>> As for the remaining commands, setTraceTransport is not needed, and I 
>> see no
>> obstacle to the implemention of setMarkerEnable.
>>
>> Hopefully these issues can be addressed in the near future, but in 
>> the meantime
>> they are documented in the manual.
>>
>> Alexis
>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev