[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] Modeled state in TMF/LTTng
|
> 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.
Exactly, it needs to be easily extensible.
> By having the "state machine" in the trace points themselves, the
> viewers won't need to be updated independently. Want to add a new
> trace point? You can (optionally) also add its relevant state modifications
> at the same time, and the viewers will interpret it correctly.
...
> For example, in a database application, they could specify that this
> event in sets the "connection" attribute to "active", and that other
> event (in the hypothetic close_connection() function) sets the
> attribute to "inactive". Then when you'd open the resulting trace in a viewer,
> you could see in a different color the period when the connection was
> active.
Yes, the question however is if this can be described declaratively (declare which field in a tracepoint change which "path" in the modeled state) or if it needs to be done programmatically (specify small code blocks to be executed when this event is encountered, the code looks up the current modeled state and the tracepoint fields and computes the needed modeled state updates).
