From 1f39128cab7920d0ead8c9059479ba68acc65f1e Mon Sep 17 00:00:00 2001 From: pmf Date: Mon, 2 Jun 2008 22:34:44 +0000 Subject: [PATCH] format.html: convert to XHTML 1.0 Strict git-svn-id: http://ltt.polymtl.ca/svn@2937 04897980-b3bd-0310-b5e0-8ef037075253 --- ltt/branches/poly/doc/developer/format.html | 108 ++++++++++++-------- 1 file changed, 65 insertions(+), 43 deletions(-) diff --git a/ltt/branches/poly/doc/developer/format.html b/ltt/branches/poly/doc/developer/format.html index e19b5d19..94546661 100644 --- a/ltt/branches/poly/doc/developer/format.html +++ b/ltt/branches/poly/doc/developer/format.html @@ -1,26 +1,31 @@ - - + + + The LTTng trace format - + +

The LTTng trace format

-Last update: 2008/05/23 +

+Last update: 2008/06/02 +

This document describes the LTTng trace format. It should be useful mainly to developers who code the LTTng tracer or the traceread LTTV library, as this library offers all the necessary abstractions on top of the raw trace data. +

A trace is contained in a directory tree. To send a trace remotely, the directory tree may be tar-gzipped. The trace foo, placed in the home directory of user john, /home/john, would have the following contents: +


+
 $ cd /home/john
 $ tree foo
 foo/
@@ -41,16 +46,17 @@ foo/
 |-- cpu_1
 `-- cpu_...
 
-
+

The root directory contains a tracefile for each cpu, numbered from 0, in .trace format. A uniprocessor thus only contains the file cpu_0. A multi-processor with some unused (possibly hotplug) CPU slots may have some unused CPU numbers. For instance an 8 way SMP board with 6 CPUs randomly installed may produce tracefiles named 0, 1, 2, 4, 6, 7. +

The files in the control directory also follow the .trace format and are also per cpu. The "facilities" files only contain "core" marker_id, marker_format and time_heartbeat events. The first two are used to describe the @@ -60,16 +66,21 @@ creations and exit. The interest of placing such subsequent events in control trace files instead of (or in addition to) in the per cpu trace files is that they may be accessed more quickly/conveniently and that they may be kept even when the per cpu files are overwritten in "flight recorder mode". +

Trace format

Each tracefile is divided into equal size blocks with a header at the beginning of the block. Events are packed sequentially in the block starting right after the block header. -

+ +

Each block consists of : -


+
+
+
 block start/end header
 trace header
 event 1 header
@@ -78,11 +89,11 @@ event 2 header
 event 2 variable length data
 ....
 padding
-
+

The block start/end header


+
 begin
 	* the beginning of buffer information
 	uint64 cycle_count
@@ -99,13 +110,13 @@ uint32 lost_size
 	* number of bytes of padding at the end of the buffer.
 uint32 buf_size
 	* size of the sub-buffer.
-
+

The trace header


+
 uint32 magic_number
 	* 0x00D6B7ED, used to check the trace byte order vs host byte order.
 uint32 arch_type
@@ -152,18 +163,20 @@ start_time
 		clock frequency).
 	uint32 seconds
 	uint32 nanoseconds
-
+

Event header

Event headers differ according to the following conditions : does the traced system have a heartbeat timer? Is tracing alignment activated? +

Event header : -


+
+
 { uint32 timestamp
 	or
 	uint64 timestamp }
@@ -177,24 +190,26 @@ uint8 event_id
 	* Numerical ID of the event inside the facility.
 uint16 event_size
 	* Size of the variable length data that follows this header.
-
+

Event header alignment +

If trace alignment is activated (alignment), the event header is aligned. In addition, padding is automatically added after the event header so the variable length data is automatically aligned on the architecture size. +

- - + + -- 2.34.1