Driver Tracing Infrastructure
From TracingWiki
The Driver Tracing Interface, DTI, was initially designed to enable driver developers to log events in a circular flight-recording buffer. The typical usage model consists in extracting and analyzing the buffer content after a system crash, trying to pinpoint the source of the problem.
The Driver Tracing Interface enables passing debug data (per-CPU buffering) into user space using the existing Relay file system. The DTI API is architecture independent, and it is usable in both user and interrupt contexts. A relay buffer is created for every CPU, and each buffer is subdivided into equally sized sub-buffers. These sub-buffers are filled in a circular fashion. A user space program can consume a sub-buffer only when full, and therefore changes its state to consumed. If no consumed sub-buffers are available, the one containing the oldest data is overwritten.
The DTI Kernel API can be used to register new traces, set the corresponding sub-buffer size, write a formatted string or a buffer to the trace and set the trace level (e.g. debug level form 0 to 6). The trace level is used to select which records to keep.
The driver writer needs to register a new trace by specifying its name and the subbuffer size. This will generate a trace handle that can be used to log events. Binary tracing, printk-style logging and mixed tracing are supported but it is up to the user to interpret the outcome. For each registered trace, the files data0, data1 ... data[max_cpus – 1] are created in the mounted debug filesystem. The content of each event record is as follows:
struct dti_even {
__u16 len;
__u64 time;
char data[0];
}
A user supplied trace formatting tool is provided to extract, sort and format the events from each per-CPU data file. Retrieving trace data from a crash dump is also possible by first locating the address of a special string stored in the trace structure, and then manipulating this address to locate another basic structure from which the buffers are retrieved. A major characteristic of DTI is that it provides early logging in the kernel, from the beginning of the start_kernel() init code.
The device drivers constitute the largest portion of the Linux kernel source code. Many drivers or subsystems need to be traced for performance analysis, troubleshooting and debugging. Already some of these subsystems come with ad hoc tracers for events like wireless connections or SCSI disks commands. The DTI project has not been very active lately. However, with the inclusion of the Kernel Markers, there is now a mechanism in place to instrument the various device drivers.
