[lttng-dev] [CTF] Dynamic enumerations and state system

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
> On 12-01-19 03:16 PM, Aaron Spear wrote:
> > Hi Alexandre,
> >
> > Thanks for the response.  I think you misinterpreted my question a little bit, so I will try to be more clear below:
> >
> > ----- Original Message -----
> >> [...]
> >>
> >>
> >> For LTTng however, we have separated the notion of "state system"
> >> from the trace file itself. We are currently working on implementing this
> >> as a library that can then be used by trace viewers like LTTV. This
> >> library will have input plugins for each trace type, in which we would define
> >> the state information we want to build from a trace. For example, in a 
> >> CTF kernel trace we could assign state changes to the "wait" and "post"
> >> events, which would increment and decrement a value in the model. 
> >> That way the viewer could retrieve the value of the semaphore at any point
> >> in time, even if there is no context information in the trace itself.
> > What I am really asking is how these plugins know how to construct the state from the post and wait events in our semaphore example.  
> 
> Right now yes, it's kind-of-hard-coded into the plugin itself for each
> specific trace type. Mathieu's earlier reply pointed out that there is a
> provision in CTF for defining those state changes straight in the
> events, but we don't have a working prototype that makes use of this (yet?).
> 
> I was just giving the example of how LTTng handles it at the moment, but
> your question was more about CTF itself, my bad.
> 
> > It is my hope that you could have 
> > a DATA DRIVEN plugin that could know how to create the state based on CTF meta-data for the post and wait events that would tell it which attribute to extract for the state (count) and such, as opposed to having a plugin that was hard coded to handle wait and post events for Linux 3.x semaphores.  Of course there has to be sane constraints on what you try to do in a data driven way, but say for example that there is in my application a state that is an enum of 5 values and I set my application up so that there is an event that is stuck in the log with the new value on any state change.  Ideally I just emit some meta-data for this event that says to track the state of the value (which is one of the 5 values always) and at any point in time I can see what the current state is.
> >
> > So, if what I said above is possible, that would mean that CTF would have some way to indicate in the meta-data that an attribute of an event was a state and then optionally a reference to an enum for the states if that is the applicable.  
> >
> > Is that more clear what I am asking?
> 
> I'll let my Mathieu answer to whether this can be done in CTF itself.

Yes, but we will need to augment the CTF specification to support this.

Thanks,

Mathieu

> 
> 
> Cheers,
> 
> -- 
> Alexandre Montplaisir
> DORSAL lab,
> École Polytechnique de Montréal
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com