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