> > 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) _______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
