[lttng-dev] [CTF] Dynamic enumerations and state system
Alexandre Montplaisir
alexandre.montplaisir at polymtl.ca
Thu Jan 19 14:24:23 EST 2012
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.
>
> cheers,
> Aaron Spear
>
Cheers,
--
Alexandre Montplaisir
DORSAL lab,
École Polytechnique de Montréal
More information about the lttng-dev
mailing list