| [linuxtools-dev] TMF and pluggable state providers |
Hi all, This topic is closely related to the ongoing "New Features in TMF about filters expressions" thread, but I decided it would be rude to hijack the thread. :-) I wanted to mention some work that I have ongoing that seems related to these thoughts and get some feedback. I do intend to contribute the work, so feedback sooner than later on the approach would be nice. My goal was to be able to do a couple of things: 1) display state over time for any sort of object, using data from any trace from which state can be extracted (CTF UST traces, text log files, ...) 2) be able to have a flexible hierarchy for contexts for these states. It would be nice to have different states for different levels 3) have it at least be possible for this to be data driven, so that end users could easily create it. Attached are some screen shots of this working now. One of them is for a simple text log file and shows a hierarchy of DataCenter > Host > VM and then state values are on the VM's only. (I work for VMware, so that hierarchy seemed relevant). The text log uses the built in custom txt trace. The other is actually a trace of Java function calls in an application that were taken using another infrastructure that I cobbled together using InTrace and UST. Both of these leverage new code that I have written derived from the LTTng Control Flow View code. To do this, I had to do the following: 1) I changed the TMF code base so that it was possible to have a plugin contribute a named factory that can be used to create state systems. The base implementation of TmfTrace.buildStateSystem checks to see if there is a property for a given trace that specifies which state system factory to use and creates it using that if so. This is nice because you can still have the state system be a function of the derived trace if you want to (like it is for LTTng currently), but you can also have a state system implementation that works with different traces regardless of the underlying file format. 2) Using the infrastructure above, I built a framework that does data driven state extraction. The idea is that you have some metadata that describes your hierarchy, event types that correspond to context and state changes, and rules for how to extract the new state and context from the events. It uses the TMF abstraction for events, and so it works independent of how the underlying trace is structured which is nice. 3) I have an implementation of the data driven state extraction above that right now is populated using a simple convention whereby the factory looks for an XML file that describes the state data right next to the trace. The right way to do this is to use some nice GUI to either create rules or manually choose which state types you want to use for a given trace, but it works for now. Attached is the XML file used to create the VM trace above so you have some idea of how this works. Again, there are layers to this. In the case of the java function trace I actually have a derived trace type, so for that one the XML file can be in the plugin (or you can hard code it and not bother with the XML) My plans/hopes: -figure out data driven choice in columns in the display. Right now the columns are generic and there are only two of them. User should be able to choose somehow, or it comes with the particular event/state schema. -extend the view so that it can display multiple traces at the same time, whichever traces are open in editors currently and support state display should be able to be aggregated. -Figure out generic way to define rules for defining properties of contexts over time. While strictly speaking this is still "state" of the contexts, it is not state that is displayed via colors or something, but rather it would be simply interesting to know. In my example say that a property of a virtual machine changed during some running state (e.g. the amount of memory allocated to it from the host), it would be great to see the events that correspond to property changes as simple black vertical lines on top of the state, and if I hover over the state for that object, I see all of the name/value properties that are current at that point in time. Perhaps using my data driven approach I could simply push all of these property changes into the state system, e.g. /properties/MyDataCenter/MyHost/MyVM/thePropertyName = thePropertyValue ? comments? Should I contribute this in small chunks? e.g. the changes to add the new extension point for state system factories first (that seems relevant to other efforts as well)? regards, Aaron Spear
Attachment:
state-trace-sample2.log.state-schema.xml
Description: XML document
Attachment:
data-driven-state-display-for-text-log.png
Description: PNG image
Attachment:
data-driven-state-display-of-ctf-java-function-trace.png
Description: PNG image
