[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[linuxtools-dev] Tmf: a model to support new trace analysis types
|
Hello,
As more and more trace analysis are getting available for TMF, I think
we should have an easier, more modular way to add new analysis.
From my experience with trace synchronization and execution
graph/critical path, an analysis typically has to be implemented (a few
more packages in tmf.core), it provides a view or more (in tmf.ui or the
trace's .ui plugin), sometimes needs a handler for the project view (new
classes in tmf.ui) and the trace needs to know about it (modification of
the trace classes, even the ITmfTrace). tmf.core and tmf.ui are getting
very crowded.
Here's the analysis framework I'd propose to add new analysis:
In tmf.core:
* A new analysis manager that handles the content from the extension
point described below
* Base classes and interfaces for all analysis
* ITmfTrace will have new methods to get all applicable analysis for
a given trace type and execute them when necessary
New extension point "org.eclipse.linuxtools.tmf.core.analysis"
An analysis has
* class: Class that implements this analysis
* tracetype: class of the trace it applies to (default: all traces)
* requires: other analysis modules that are required to run before
this one
* automatic: whether to run this analysis when the trace is opened
(default: false)
* provided views: which views will be available once the analysis is done
* icon: to represent this analysis
The project explorer view could show the analysis like this for example:
- My Project
- Experiments [1]
- SyncExperiment
- Trace 1
- Trace 2
o Analysis: trace synchronization
o Synchronization view
o Synchronization statistics view
- Traces [2]
- Trace 1
o Analysis: Lttng Kernel state system
o Control flow view
o Resources view
o Critical path
o Critical path view
....
In the long run, the actual state system and statistics could be
considered analysis types and be refactored using this framework.
Each new analysis can then be implemented in its own standalone plugin,
with core and ui, which would require only the tmf.core|ui (and the
plugins containing other analysis it requires of course). The main
plugins would not require any analysis modules.
I'd like some feedback on the proposed approach. I know Francis
Giraldeau has been thinking on this problem as well, mostly on the
dependencies between analysis. I think this approach is complementary.
Thanks,
Geneviève Bastien