Controlling kernel event tracing

The IDE lets you easily configure and start kernel event tracing. But sometimes, you might not have a target connection for controlling tracing. At these times, you can use the tracelogger utility to capture trace data. To further control tracing, your applications can call the kernel event trace API.

Initiating kernel event traces

When you run a kernel event trace from the launch bar, the IDE tells qconn of the initial trace settings and to start capturing event data. The trace settings are based on the UI fields in the log configuration.

You can also run the tracelogger command-line tool on the target. The advantage of this approach is that you can start a trace automatically (i.e., using a script) at a specific operational phase, including during system startup when you can't use the IDE because there's no active target connection. In this case, the trace settings are based on the options given to tracelogger.

Controlling kernel event tracing at runtime

Unlike librcheck or libprofilingS, qconn and tracelogger don't accept signals for requesting common operations such as starting and stopping tracing. For tracelogger, there are a couple of exceptions:

If you start it in ring mode using the -r option, the service doesn't capture events until you send it a SIGINT signal, at which point it flushes the kernel buffers to the log file.
If you run it without specifying a data-capture limit, either with -s to set a time limit or -n to specify a fixed number of buffers to output, the service runs until you explicitly terminate it using Ctrl–C or the SIGKILL signal.

Both qconn and tracelogger use TraceEvent() to control the kernel's event-gathering module. Your applications can make TraceEvent() calls to closely control what event information is captured. For these calls to have any effect, though, the kernel's instrumentation mode must be active.

The best technique is to use the IDE or command line to start a trace before or after you begin running applications that use TraceEvent(). This way, qconn or tracelogger does the tedious work of managing buffers, collecting trace data, and saving the data in the appropriate form, while allowing the applications to choose which events get logged and to start and stop data capturing. Any adjustments made at runtime override any equivalent initial settings defined when the trace was launched.