Re: [linuxtools-dev] TMF: Analysis requirement API

[Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>]

On 14-02-20 10:52 AM, Geneviève Bastien wrote:
>
>
> * The LTTng UST Memory usage analysis is a more tricky (and
> interesting!) case: It has events. Adding the context TID and procname
> will give a more interesting analysis, but the analysis can still do
> something without it.

That's interesting, we could have a distinction in the API  to know
whether a particular requirement is mandatory or not.

> But the user absolutely needs to do
> LD_PRELOAD=something-libc-wrapper.so on the command line. That cannot
> be done automatically from the LTTng control or through the LTTng
> profile (unless I'm mistaken). So that requirement will be a "manual
> intervention by the user".

Right now, we use a shell on the target machine via RSE/SSH, and we call
"lttng" by hand. We could pass those environment variables through. But
I hear there is some MI integration that might be coming eventually ;) 
In that case perhaps options should be added to lttng-tools to expose
the usage of these preloadable libraries (and those options could also
be available through the MI).

All in all, this is something the Control view could handle.

>> Since TMF isn't only LTTng oriented and can be used for many trace
>> types, we didn't want to incline the analysis developer to provide
>> specific type requirements, but let him instead define his type and
>> values related. I understand that our primary analysis source is
>> LTTng, but we don't want to bend the development towards his needs.
>> If analyses are and will be only for LTTng, we might reconsider the
>> generic option.
>> The only compile-time guarantee you have right now is in the *Strings
>> interfaces (LTTngStrings, UstMemoryStrings, etc.). Is the generic way
>> of doing it might be problematic?
> I think the generic String approach is a very good start. It's easier
> and will allow to go all the way to obtaining the LTTng profile for
> the few available analysis to directly generate a trace for them. When
> that proof of concept is done, then it will be time to ask whether
> there is a more compiler-safe way to represent those requirements. But
> it's better to keep it simple for now.

Fair enough. But it should be clear what the 'String' should be, clearly
explained in the Javadoc at least.


Cheers,
Alex