Re: [linuxtools-dev] Modeled state in TMF/LTTng

["Spear, Aaron" <aaron_spear@xxxxxxxxxx>]

> > I would rather use a generic viewer with the state machine declared
> > into a XML like file. There are few caveat to do it in a generic
way,
> > because there are many types of events. For example,
> kernel.sched_schedule
> > from lttng has prev_pid and next_pid, and hence changes the state of
two
> > processes. It's different than entry/exit event, which affect only
> > the state of one state machine. But it would provides much more
> > flexibility than static machine state definition at compile time!
> 
> Having code does not prevent extensibility. It is possible to have
python
> code or even Java or C code compiled or JIT-compiled and loaded
> dynamically. The real question is what proportion of state updating
events
> can have their state updates defined through simple declarations
versus
> those so complex that code is the better way to go.

In the context of the multi-core association tools working group we had
discussed having defined standard patterns for the state data contained
in events.  So then the metadata defines a known type of state machine
by name of a given type, and then trace analyzers can then have a plugin
mechanism to know what to do with that particular state type.  Very
simple ones would be built in.  For example an integer value occurring
in events that is an enum value that reflects an application/kernel
state is an obvious one.  It could then do a presentation of state vs
time. No matter what your kernel/application you can use that one.
There will then be other ones that are more complex as noted above and
do a bit of non trivial data interpretation.  For those, having a plugin
mechanism of some sort by which the raw event data can be
extracted/adjusted into the schema assumed by an analysis plugin would
be great.  This could enable usage of the same plugins to do Gantt chart
plotting of scheduler information regardless of whether the OS was Linux
or something else.  

So in summary, I envision that we would have sets of known standard
event schemas, and then a way to transform a given type of data into
that schema via a plugin (as Michel mentions, Python, java, whatever).
The tradeoff is that you dumb things down to the least common
denominator, but it is still enormously useful and an infinitely large
step forward from nothing :-).  E.g.

-OS scheduler Gantt chart
-stock presentation of mutexes and lock/unlock calls (maybe even
suspended process/thread lists)
-"analog" value vs. time presentation.  (e.g. could be used to present
number of bytes free in a memory pool with some math on the incoming
events)

For a particular application that has very specify transformation
necessary on the raw event data, of course you can still have a
specialized plugin/presentation.

Regards,
Aaron

--
Aaron Spear | Tools Architect
Mentor Embedded(tm)