+
+#include <ltt/ltt-private.h>
+
+/* A trace is associated with a tracing session run on a single, possibly
+ multi-cpu, system. It is defined as a pathname to a directory containing
+ all the relevant trace files. All the tracefiles for a trace were
+ generated in a single system for the same time period by the same
+ trace daemon. They simply contain different events. Typically one file
+ contains the important events (process creations and registering tracing
+ facilities) for all CPUs, and one file for each CPU contains all the
+ events for that CPU. All the tracefiles within the same trace directory
+ then use the exact same id numbers for event types.
+
+ A tracefile (ltt_tracefile) contains a list of events (ltt_event) sorted
+ by time for each CPU; events from different CPUs may be slightly out of
+ order, especially using the (possibly drifting) cycle counters as
+ time unit.
+
+ A facility is a list of event types (ltt_eventtype), declared in a special
+ .event file. An associated checksum differentiates different facilities
+ which would have the same name but a different content (e.g., different
+ versions).
+
+ The list of facilities (and associated checksum) used in a tracefile
+ must be known in order to properly decode the contained events. An event
+ is usually stored in the trace to denote each different "facility used".
+ While many facilities may be present when the trace starts, new
+ facilities may be introduced later as kernel modules are loaded.
+ This is fine as long as the "facility used" event precedes any event
+ described in that facility.
+
+ Event types (ltt_eventtype) refer to data types (ltt_type) describing
+ their content. The data types supported are integer and unsigned integer
+ (of various length), enumerations (a special form of unsigned integer),
+ floating point (of various length), fixed size arrays, sequence
+ (variable sized arrays), structures and null terminated strings.
+ The elements of arrays and sequences, and the data members for
+ structures, may be of any nested data type (ltt_type).
+
+ An ltt_field is a special object to denote a specific, possibly nested,
+ field within an event type. Suppose an event type socket_connect is a
+ structure containing two data membes, source and destination, of type
+ socket_address. Type socket_address contains two unsigned integer
+ data members, ip and port. An ltt_field is different from a data type
+ structure member since it can denote a specific nested field, like the
+ source port, and store associated access information (byte offset within
+ the event data). The ltt_field objects are tracefile specific since the
+ contained information (byte offsets) may vary with the architecture
+ associated to the tracefile. */
+
+typedef struct _ltt_tracefile ltt_tracefile;
+
+typedef struct _ltt_facility ltt_facility;
+
+typedef struct _ltt_eventtype ltt_eventtype;
+
+typedef struct _ltt_type ltt_type;
+
+typedef struct _ltt_field ltt_field;
+
+typedef struct _ltt_event ltt_event;
+
+
+/* Different types allowed */
+
+typedef enum _ltt_type_enum
+{ LTT_INT, LTT_UINT, LTT_FLOAT, LTT_STRING, LTT_ENUM, LTT_ARRAY,
+ LTT_SEQUENCE, LTT_STRUCT
+} ltt_type_enum;
+
+
+/* Checksums are used to differentiate facilities which have the same name
+ but differ. */
+
+typedef unsigned long ltt_checksum;
+
+
+/* Events are usually stored with the easily obtained CPU clock cycle count,
+ ltt_cycle_count. This can be converted to the real time value, ltt_time,
+ using linear interpolation between regularly sampled values (e.g. a few
+ times per second) of the real time clock with their corresponding
+ cycle count values. */
+
+typedef struct timespec ltt_time;
+
+typedef uint64_t ltt_cycle_count;
+
+
+
+