X-Git-Url: http://git.efficios.com/?p=ctf.git;a=blobdiff_plain;f=common-trace-format-proposal.txt;h=44092732992146fe4cba31edc131ff5980f3a108;hp=fd93760c28e6c408c337912d3206d535b7164eff;hb=f42082879eda3db3ce5b5438a06851a37213ce0f;hpb=689e04b4a08ed27a596bf1b8cd2d3c4b3e5f4a2e

diff --git a/common-trace-format-proposal.txt b/common-trace-format-proposal.txt
index fd93760..4409273 100644
--- a/common-trace-format-proposal.txt
+++ b/common-trace-format-proposal.txt
@@ -99,15 +99,16 @@ types, but must be derived into a type to be usable in an event field.
 
 We define "byte-packed" types as aligned on the byte size, namely 8-bit.
 We define "bit-packed" types as following on the next bit, as defined by the
-"bitfields" section.
+"Integers" section.
 
 All basic types, except bitfields, are either aligned on an architecture-defined
 specific alignment or byte-packed, depending on the architecture preference.
 Architectures providing fast unaligned write byte-packed basic types to save
 space, aligning each type on byte boundaries (8-bit). Architectures with slow
 unaligned writes align types on specific alignment values. If no specific
-alignment is declared for a type nor its parents, it is assumed to be bit-packed
-for bitfields and byte-packed for other types.
+alignment is declared for a type, it is assumed to be bit-packed for
+integers with size not multiple of 8 bits and for gcc bitfields. All
+other types are byte-packed.
 
 Metadata attribute representation of a specific alignment:
 
@@ -270,10 +271,7 @@ this format by having the same start_value and end_value for each element, which
 is in fact a range of size 1. This single-value range is supported without
 repeating the start and end values with the value = string declaration.
 
-If a numeric value is encountered between < >, it represents the integer type
-size used to hold the enumeration, in bits.
-
-enum name <integer_type OR size> {
+enum name <integer_type> {
   somestring          = start_value1 ... end_value1,
   "other string"      = start_value2 ... end_value2,
   yet_another_string,	/* will be assigned to end_value2 + 1 */
@@ -284,7 +282,7 @@ enum name <integer_type OR size> {
 If the values are omitted, the enumeration starts at 0 and increment of 1 for
 each entry:
 
-enum name <32> {
+enum name <unsigned int> {
   ZERO,
   ONE,
   TWO,
@@ -370,7 +368,7 @@ variant name {
 };
 
 struct {
-  enum <integer_type or size> { sel1, sel2, sel3, ... } tag_field;
+  enum <integer_type> { sel1, sel2, sel3, ... } tag_field;
   ...
   variant name <tag_field> v;
 }
@@ -379,7 +377,7 @@ An unnamed variant definition within a structure is expressed by the following
 metadata:
 
 struct {
-  enum <integer_type or size> { sel1, sel2, sel3, ... } tag_field;
+  enum <integer_type> { sel1, sel2, sel3, ... } tag_field;
   ...
   variant <tag_field> {
     field_type sel1;
@@ -761,20 +759,23 @@ contained within the payload. (This follows the ISO/C standard for structures)
 
 7. Metadata
 
-The meta-data is located in a stream named "metadata". It is made of "event
-packets", which each start with an event packet header. The event type within
-the metadata stream have no event header nor event context. Each event only
-contains a null-terminated "string" payload, which is a metadata description
-entry. The events are packed one next to another. Each event packet start with
-an event packet header, which contains, amongst other fields, the magic number
-and trace UUID. The trace UUID is represented as a string of hexadecimal digits
-and dashes "-".
-
-The metadata can be parsed by reading through the metadata strings, skipping
-newlines and null-characters. Type names are made of a single identifier, and
-can be surrounded by prefix/postfix. Text contained within "/*" and "*/", as
-well as within "//" and end of line, are treated as comments. Boolean values can
-be represented as true, TRUE, or 1 for true, and false, FALSE, or 0 for false.
+The meta-data is located in a stream identified by its name: "metadata".
+It is made of "event packets", which each start with an event packet
+header. The event type within the metadata stream have no event header
+nor event context. Each event only contains a null-terminated "string"
+payload, which is a metadata description entry. The events are packed
+one next to another. Each event packet start with an event packet
+header, which contains, amongst other fields, the magic number and trace
+UUID. In the event packet header, the trace UUID is represented as an
+array of bytes. Within the string-based metadata description, the trace
+UUID is represented as a string of hexadecimal digits and dashes "-".
+
+The metadata can be parsed by reading through the metadata strings,
+skipping null-characters. Type names are made of a single identifier,
+and can be surrounded by prefix/postfix. Text contained within "/*" and
+"*/", as well as within "//" and end of line, are treated as comments.
+Boolean values can be represented as true, TRUE, or 1 for true, and
+false, FALSE, or 0 for false.
 
 
 7.1 Declaration vs Definition
@@ -936,7 +937,7 @@ variant name {
   ...
 };
 
-enum name <integer_type or size> {
+enum name <integer_type> {
   ...
 };
 
@@ -953,7 +954,7 @@ variant {
   ...
 }
 
-enum <integer_type or size> {
+enum <integer_type> {
   ...
 }
 
@@ -1334,9 +1335,6 @@ enum-specifier:
 	enum identifier-opt < declaration-specifiers > { enumerator-list }
 	enum identifier-opt < declaration-specifiers > { enumerator-list , }
 	enum identifier < declaration-specifiers >
-	enum identifier-opt < integer-constant > { enumerator-list }
-	enum identifier-opt < integer-constant > { enumerator-list , }
-	enum identifier < integer-constant >
 
 enumerator-list:
 	enumerator