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

[Aaron Spear]

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 -----
> From: "Alexandre Montplaisir" <alexandre.montplaisir at polymtl.ca>
> To: "Aaron Spear" <aspear at vmware.com>
> Cc: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>, lttng-dev at lists.lttng.org
> Sent: Thursday, January 19, 2012 12:24:23 PM
> Subject: Re: [lttng-dev] [CTF] Dynamic enumerations and state system
> 
> Hi Aaron,
> 
> On 12-01-17 06:21 PM, Aaron Spear wrote:
> > Hi Mathieu and Alexandre,
> >
> > ----- Original Message -----
> >> From: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> > ...
> >> Good to hear that the state tree is a good container for this kind
> >> of
> >> information. So I'll drop the "dynamic enumerations" from my CTF
> >> roadmap.
> >
> > It does seem though that in any case CTF meta-data must have a
> > standardized way to express that a value is a "state" though
> > right?  (as well as some help for interpretation of the state
> > value).  Take a counting semaphore for instance.  Every OS I have
> > seen has some sort of control block that has an integer that is
> > the count.  Every post or wait increments or decrements the count
> > respectively.  It would be nice if we could describe this for any
> > OS with just annotations on the wait and post events in the CTF
> > meta-data.  Then the analyzer would be able to display the
> > semaphore value at any point in time without knowing anything
> > special about the OS.
> 
> Mathieu correct me if I'm wrong, but I think the "event context" in
> CTF can do just that. It could for example include the new value of the
> counting semaphore as part of the event.
> 
> Some trace formats, like SLOG-2, offer support for both events (1
> timestamp + values) and states that have a duration (so 2 timestamp +
> a "state value") directly in the trace. AFAIUI, CTF only supports
> events, but to which you can add context information.
> 
> 
> 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.  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?

Aaron Spear