Re: [linuxtools-dev] TMF and pluggable state providers

[Michel Dagenais <michel.dagenais@xxxxxxxxxx>]

> display state over time for any sort of object, using data from any
> trace from which state can be extracted

Yes, in fact you derive values (state or metrics) to be stored in the state tree (and state history database) from events. You thus need expressions to match events and set the state accordingly. The "values" can then be shown over time in different ways: different colors for a few states, or curve / bar or color intensity for a continuous metric.

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

Yes, this is exactly the point of what Florian has posted.

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

The java calls don't show the nesting. When function 2 is called from function 1, no state is shown for function 1; if you want to gather statistics about self + childs, you probably want to have a state for "within a function but not at top level". In the VM case, several seem to be active at a time, presumably because the physical machine has several processors.

> 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) 

XML as file format is a good idea. A GUI for creating this information will indeed be useful. Is a "simple language" syntax for expressing the same thing, as discussed by Florian, also useful? XML or a simple language are simply alternate representations of the same thing, so I don't have a strong opinion on whichever is more useful or should come first.

Your current schema looks limited in the state information it can associate with a "context". You probably get more flexibility (and visibility for debugging) if you base everything on the state tree: objects / contexts are nodes in the tree and various state elements are values in the leaves.

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

Yes, this is the type of things useful for many views. Francis Giraldeau is working on calculating the critical path and then annotating the events and state intervals that form this critical path.

> 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 ?

Yes, I strongly believe that you gain a lot by using the state system. A number of generic services are offered by the state system, including the possibility to view / explore the state tree at any point in time. Florian programmed such a module in a couple of days and will be contributing it.