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 _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
