This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linux Trace terminology - feedback requested





systemtap-owner@sourceware.org wrote on 18/05/2006 23:22:48:

> Hi all,  please forgive the massive cross-post.
>
> I'm working on coordinating some collaboration between some of the major
> tracing systems in Linux, and as a first step I'm working on some
terminology
> definitions.  This is just to see what people call different things, and
is a
> precursor to putting together a taxonomy of features and attributes for
the
> different tracers.
>
> Here is my first attempt:
>
>  * event - an instruction location or system state at a specific point in
time

tracepoint is the location that as been chosen for tracing. It may be
active or inactive.

event is the "firing" of the tracepoint, which generally generates event
data.

event data that is recorded is trace data.


>  * event data - information related to an event
>     * ie. In some trace systesm, event data size can vary depending
> on the event.
>  * capture - the act of recording event information
>  * trace point - a location in the traced software, where an event
> is "emitted"
>  * trace buffer - location where trace data is stored at time of capture
>  * trace log - location where trace data is stored long-term

For binary tracing "log" is generally replaced by "file"

>  * configuration interface - the API or mechanism used to configure
> the tracing engine
>  * control interface - the API or mechanism used to control the tracing
engine
>  * transfer interface - the API or mechanism used to move the trace data
from
>    kernel to user space
>  * trace time - the time when the trace is active
>     * ie The trace buffer may be accessed at trace time, that is,
> while the trace is active.
>  * post-processing - manipulation of the trace data after the trace
> is collected

after then entire tracing episode has ended? I.e post mortem so to speak?


>  * configuration - the set of constraints which determine what
> events are collected
>    and how they are processed in a trace
>  * static tracepoint - a trace point statically compiled into the
> software being traced
>  * dynamic tracepoint - a trace point dynamically added to the
> software being traced

Need to define tracepoint for that definition to work :-)

>  * aggregation - updating statistics or other analytical
> information, based on trace events
>      * ie. SystemTap can do aggregation at trace time, while KFT and
LTTng do
>        aggregation during post-processing (mostly).
>  * filters - criteria used to limit the events that are processed or
captured

There are also data filters that operate following each trace event before
the event data is recorded in the trace buffer.

>  * triggers - criteria used to start and stop tracing automatically
>
> Does your tracing system use different terms for any of the above?
> If so, what are they?
>
> Are there any other important terms I am missing?
>
> Your feedback is really appreciated.
>
> Thanks,
>  -- Tim
>


regards,

Richard J M



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]