On 11-01-07 05:50 PM, Michel Dagenais wrote: > The Multi-Core Association is working on a Trace Format Standard. While they > are looking at metadata describing the events (type of events, the type of > their fields...), the idea has been proposed to also document the associated > "modeled state".
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. 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. This is particularly interesting for userspace applications, instrumented with UST for example. We could provide a generic way to define attributes and state changes in the tracepoints, and anyone instrumenting their application could tailor it to their needs. 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. There's better examples in Mathieu's trace format proposition, of which I copied an excerpt below. On 2010-12-09 11:01, Mathieu Desnoyers wrote: > - Optional per-event "current state tracking" information. > > This per-event taxonomy allows automated creation of a state machine that > keeps track of state updates within the taxonomy tree. > > Described in an file-system path-like taxonomy with additional [] > operator which indicates a lookup by value, e.g.: > > * For events in the trace stream updating the current state only based on > information known from the context (either derived from the per-section or > per-event context information): > > E.g., associated with a scheduling change event: > > "cpu[section/cpu]/thread = field/next_pid" > Updates the current value of the current section's cpu "thread" attribute > (e.g. currently running thread). > > E.g., associated with a system call: > > "thread[cpu[section/cpu]/thread]/syscall[field/syscall_id]/id > = field/syscall_id" > > Updates the state value of the current thread "syscall" attribute. > > * For events in the trace stream targeting a path that depends on other > fields into that same event (would be common for full system state dump at > trace start): > > E.g., associated with a thread listing event: > "thread[field/pid]/pid = field/pid" > > E.g., associated with a thread memory maps listing event: > "thread[field/pid]/mmap[field/address]/address = field/address" > "thread[field/pid]/mmap[field/address]/end = field/end" > "thread[field/pid]/mmap[field/address]/flags = field/flags" > "thread[field/pid]/mmap[field/address]/pgoff = field/pgoff" > "thread[field/pid]/mmap[field/address]/inode = field/inode" > > All per-event context information (e.g. repeating the current PID and CPU > for each event) can be represented with this taxonomy, e.g., in the > section description: > > "section/pid = field/pid" > "section/cpu = field/cpu" -- Alexandre Montplaisir DORSAL lab, École Polytechnique de Montréal _______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
