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

[Francis Giraldeau <francis.giraldeau@xxxxxxxxxxxxxx>]

On Fri, 2011-01-07 at 22:01 -0500, Alexandre Montplaisir wrote:
> On 11-01-07 05:50 PM, Michel Dagenais wrote:
> > The Multi-Core Association is working on a Trace Format Standard. While they are looking at metadata describing the events (type of events, the type of their fields...), the idea has been proposed to also document the associated "modeled state". 
> 
> I think this is the way to go. Right now the "state updating"
> mechanisms, which convert events in the trace to state changes, reside
> in the viewers (in state.c for LTTV, and StateUpdateHandlers.java for
> TMF). This means that if we add or modify existing tracepoints in LTTng,
> the viewers have to be updated as well.

The problem is that the same event can change the state of multiple
state machines. In lttv, a state is held for CPUs and process. Some
people are using raw events to generate higher level state machine of
the system. I did my own state machine for analysis from only events I
needed. From my point of view, I agree that the state machine should be
declared (a parameter, not code) because multiple of them can be created
for different purpose. This is really the business of viewers and
analyzers, not the tracer itself. 

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!

Good documentation is required to create custom state machines. I faced
this problem when digging into events the first time. There is no
description of events and their fields, that makes it very hard to use
events properly. In the windows world, they are using some kind of
manifest to better document the trace events [1]. The manifest is used
to compile a header file with constants, and would be usable to document
the semantic of events used by a viewer. 

In a distributed case, various versions of the tracer may be running at
the same time. Having not only the version of trace binary format, but
also another version number of trace semantic would be required. For
example, say we added one event in a user space application, then the
format of the trace has not changed from the point of view of
libtraceread, but the semantics may have changed for the state machine.
With this identifier, we can select the right manifest for further
analysis.

Have a nice day, 

Francis

[1] http://msdn.microsoft.com/en-us/library/aa364101%28v=VS.85%29.aspx