Data_Driven

Data Driven

Here is a list of upcoming specifications for the data-driven XML analyses. The number of '+' at the beginning of each line gives an idea of the complexity / time involved in this item. In each section, items are ordered by priority (at least at the top). ONGOING means somebody is actively working on it, HIGH means it is a high priority and there are plans to work on it. Each item can be further sub-divided if need be.

Features

= ++ StackBar view to show the scenarios ONGOING

• ++ Table viewer to show the states of the scenarios and order them by state durations, etc ONGOING

• ++ XML-defined callstacks DONE

• + Put a scenario view in the builtin XML files so scenario data can be shown in a time graph view. This scenario view will show the states of each scenario in a time graph view.

• + Be able to define time ranges for XML-defined segments from event's data instead of only using the timestamps of the events at the start and end (one single event that contains data about an execution like a start and end time can be the source of a segment)

• +++ Support Regexes and arithmetic operations on state values (numbers and strings) DONE (scripts)

• ++ Add labels and tooltips in XML time graph views ONGOING

• ++ Add parameters to the actions/tests/etc such that an action for example can be reused by many events. For example, let's say we have an action to increment a counter in ''Threads/thread ID/<counter name>''. Event ''a'' can do action ''incrementCounter(cntA)'' and event ''b'' can use the same action with ''incrementCounter(cntB)''. Currently, there needs to be 2 actions defined, one for each counter name.

• +++ It should be possible to save variables outside of the state system to use them later. Some patterns need to save some data to be used later in the scenario. But it does not always make sense to put it in the state system. It needs to live only the time of the scenario and is not necessary for the views or later analysis.

• ++ Support wildcard in queries for stateAttribute. Right now, we need to know the path to the attribute we need to access. Some part of the path can be a query that will use the state value of another known path, but it cannot just take an attribute with a given value. For instance, if we have a path that is ''Threads/<thread id>/some value'' we may want to find for an event the thread id(s) where ''some value'' is ''something''. So we would like to query ''Threads/*/some value = something''

• ++ For XML defined views, we need to specify the ''id'' of an analysis in the header for it to apply, but we may also want to supply a ''class'' attribute, so that the view will apply to any analysis of this class (an example of this would be the scenario view to display for all ''XmlPatternAnalysis'').

• ++ Show builtins analyses in the ''Manage XML analyses'' dialog. Those analyses would not be modifiable, but they could be copied or exported.

• +++ Define analysis requirement for XML analysis, so that analyses are only run when the requirements are met.

• +++ Customize analysis latency analysis views so that it's possible to create user-defined latency views from the XML definition (e.g. define latency types)

• +++ Create trace markers based on XML definition so that it's possible to highlight interesting areas in the views (e.g. time graph views)

• ++ Support XML analysis for experiments so that it's possible to do system wide analysis (e.g. LTTng UST and Kernel traces)

• Support mapping a field value to a color gradient using a linear scale. The min/max value may be obtained from the data itself, specified in the metadata or in the XML model. Use cases: show the processor frequency or density of cache misses according to time. Currently in the case of processor frequency, each frequency must be listed in the XML and assigned a specific state value. Because processor frequencies are specific to a CPU model, the analysis is not portable as it is. More details [http://multivax.blogspot.ca/2014/11/how-linux-changes-cpu-frequency.html here].

UX

• +++ Compilation/execution/versioning (this will allow to support other data-driven languages, like jdesfossez's lttng-analyses syntax) HIGH This item is pre-requisite other UX items and many features as well ONGOING

  • Divide compilation and execution of the XML file. First step would be that the state providers should use objects that do not depend on any org.w3c.* classes.

  • Compilation and validation: Verify the syntax AND semantics of the XML and return errors to the user. If the XML does not validate, there is no analysis module. This phase can be done statically, without a trace associated. For instance, for a pattern, it will verify that all states, actions, tests referred to are defined in the file, etc. This will rule out human errors in the orthograph.

• +++++ Console view or some UI way to show errors in XML file. Click and go to line in file ONGOING

• ++ New -> from template, where we have a list of pre-defined template XML for some common use cases, like callstacks.

• +++++ Graphically create and edit XML analyses that generates the XML file.

• ++++ Debug per event, see what happens (select an event in event viewer -> Run [Name of XML analysis] to this event -> Open a "XML debug" view where execution will be detailed -> Menu: run this event, run to selected event, run)

• +++ Tutorial for the XML. Or make extra documentation in the form of tutorials for newbies to XML, or even oldbies who want to do more cool stuff.

Bugs

• + Final state should be written as null in the state system states. It is not an actual state with duration. HIGH

• + Static analysis of the XML's attribute tree. The ''scenario'' part of the state system can be cleaned up, many attributes are not used and it takes space.

• + Each XML analysis is executed for any custom trace type (Bug 488422)