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

[Geneviève Bastien <gbastien@xxxxxxxxxxxx>]

Hi Guilliano,

Thanks! I'll add your contribution so far on gerrit to be able to better appreciate it and review it.

On 02/20/2014 10:11 AM, Guilliano Molaire wrote:

Hi Alex,

On 19/02/2014 4:45 PM, Alexandre Montplaisir wrote:

Hi Guilliano,

Interesting project! Indeed, there is already an API for traces to
indicate if they contain specific events (hasEvent(String),
hasAllEvents(String[]),...).[1]  The next step would be to have a way
for an analysis to specify which event types they need, so we can match
the traces and analyses better.

Some questions:
- A "string" requirement is quite generic. What actual types of
requirements do you have in mind? I can see event type (or event name),
but what else? If we can pinpoint a few specific types of requirements,
we could have a couple of methods specifically for those. Having
something too vague or too generic makes it more confusing to use, and
we don't have as much compile-time guarantees.

Even for LTTng it's not just event types unfortunately. I think with the few analysis we already have in TMF, there is enough variety of requirements:

* The LTTng Kernel analysis require a list of events. It's a good start to implement the requirements

* 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. 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".

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.


Cheers,
Geneviève