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

[Alexandre Montplaisir]

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.


Cheers,

-- 
Alexandre Montplaisir
DORSAL lab,
École Polytechnique de Montréal