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
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
