lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: diamon-discuss@lists.linuxfoundation.org
Cc: Jeremie Galarneau <jgalar@efficios.com>,
	lttng-dev@lists.lttng.org, Philippe Proulx <pproulx@efficios.com>,
	Genevieve Bastien <gbastien+lttng@versatic.net>
Subject: [RFC PATCH CTF 3/4] Clarify that timestamp begin/end need to be complete clock values
Date: Tue, 28 Apr 2020 15:12:26 -0400	[thread overview]
Message-ID: <20200428191227.16560-3-mathieu.desnoyers@efficios.com> (raw)
In-Reply-To: <20200428191227.16560-1-mathieu.desnoyers@efficios.com>

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
---
 common-trace-format-specification.md | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/common-trace-format-specification.md b/common-trace-format-specification.md
index 55d0601..5732e92 100644
--- a/common-trace-format-specification.md
+++ b/common-trace-format-specification.md
@@ -837,11 +837,12 @@ TSDL metadata):
     assigned to events contained within the packet. The timestamp at the
     beginning of an event packet is guaranteed to be below or equal the
     timestamp at the end of that event packet. The timestamp at the
-    beginning of an event packet is guaranteed to be above or equal the
-    timestamps at the beginning of any prior packet within the same
-    stream. The timestamp at the end of an event packet is guaranteed to
-    be below or equal the timestamps at the end of any following packet
-    within the same stream. See [Clocks](#spec8) for more detail.
+    beginning of an event packet is guaranteed to be grater than or
+    equal to timestamps at the beginning of any prior packet within the
+    same stream. The timestamp at the end of an event packet is
+    guaranteed to be less than or equal to the timestamps at the end of
+    any following packet within the same stream. See [Clocks](#spec8)
+    for more detail.
   * **Events discarded count**. Snapshot of a per-stream
     free-running counter, counting the number of events discarded that
     were supposed to be written in the stream after the last event in
@@ -1580,7 +1581,8 @@ stream {
 };
 ~~~
 
-For a N-bit integer type referring to a clock, if the integer overflows
+Within the stream event context, event context, and event payload,
+fields of N-bit integer type referring to a clock, if the integer overflows
 compared to the N low order bits of the clock prior value found in the
 same stream, then it is assumed that one, and only one, overflow
 occurred. It is therefore important that events encoding time on a small
@@ -1589,8 +1591,8 @@ N-bit overflow occurs.
 
 In a packet context, clock field names ending with `_begin` and `_end`
 have a special meaning: this refers to the timestamps at, respectively,
-the beginning and the end of each packet.
-
+the beginning and the end of each packet. Those are required to be
+complete representations of the clock value.
 
 ## A. Helper macros
 
-- 
2.11.0

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: diamon-discuss@lists.linuxfoundation.org
Cc: Jeremie Galarneau <jgalar@efficios.com>,
	lttng-dev@lists.lttng.org, Philippe Proulx <pproulx@efficios.com>,
	Genevieve Bastien <gbastien+lttng@versatic.net>
Subject: [lttng-dev] [RFC PATCH CTF 3/4] Clarify that timestamp begin/end need to be complete clock values
Date: Tue, 28 Apr 2020 15:12:26 -0400	[thread overview]
Message-ID: <20200428191227.16560-3-mathieu.desnoyers@efficios.com> (raw)
Message-ID: <20200428191226.VGyZMZbWq5pav8yffvxOzlvx1hW_etSAODG8eNx1Xdg@z> (raw)
In-Reply-To: <20200428191227.16560-1-mathieu.desnoyers@efficios.com>

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
---
 common-trace-format-specification.md | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/common-trace-format-specification.md b/common-trace-format-specification.md
index 55d0601..5732e92 100644
--- a/common-trace-format-specification.md
+++ b/common-trace-format-specification.md
@@ -837,11 +837,12 @@ TSDL metadata):
     assigned to events contained within the packet. The timestamp at the
     beginning of an event packet is guaranteed to be below or equal the
     timestamp at the end of that event packet. The timestamp at the
-    beginning of an event packet is guaranteed to be above or equal the
-    timestamps at the beginning of any prior packet within the same
-    stream. The timestamp at the end of an event packet is guaranteed to
-    be below or equal the timestamps at the end of any following packet
-    within the same stream. See [Clocks](#spec8) for more detail.
+    beginning of an event packet is guaranteed to be grater than or
+    equal to timestamps at the beginning of any prior packet within the
+    same stream. The timestamp at the end of an event packet is
+    guaranteed to be less than or equal to the timestamps at the end of
+    any following packet within the same stream. See [Clocks](#spec8)
+    for more detail.
   * **Events discarded count**. Snapshot of a per-stream
     free-running counter, counting the number of events discarded that
     were supposed to be written in the stream after the last event in
@@ -1580,7 +1581,8 @@ stream {
 };
 ~~~
 
-For a N-bit integer type referring to a clock, if the integer overflows
+Within the stream event context, event context, and event payload,
+fields of N-bit integer type referring to a clock, if the integer overflows
 compared to the N low order bits of the clock prior value found in the
 same stream, then it is assumed that one, and only one, overflow
 occurred. It is therefore important that events encoding time on a small
@@ -1589,8 +1591,8 @@ N-bit overflow occurs.
 
 In a packet context, clock field names ending with `_begin` and `_end`
 have a special meaning: this refers to the timestamps at, respectively,
-the beginning and the end of each packet.
-
+the beginning and the end of each packet. Those are required to be
+complete representations of the clock value.
 
 ## A. Helper macros
 
-- 
2.11.0

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

  parent reply	other threads:[~2020-04-28 19:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 19:12 [RFC PATCH CTF 1/4] Clarify that unlisted enumeration values are allowed Mathieu Desnoyers via lttng-dev
2020-04-28 19:12 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2020-04-28 19:12 ` [RFC PATCH CTF 2/4] Clarify monotonicity requirement on timestamp begin Mathieu Desnoyers via lttng-dev
2020-04-28 19:12   ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2020-04-28 19:12 ` Mathieu Desnoyers via lttng-dev [this message]
2020-04-28 19:12   ` [lttng-dev] [RFC PATCH CTF 3/4] Clarify that timestamp begin/end need to be complete clock values Mathieu Desnoyers via lttng-dev
2020-04-28 19:12 ` [RFC PATCH CTF 4/4] Use the formulation "less than or equal to" rather than "below or equal" Mathieu Desnoyers via lttng-dev
2020-04-28 19:12   ` [lttng-dev] " Mathieu Desnoyers via lttng-dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200428191227.16560-3-mathieu.desnoyers@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=diamon-discuss@lists.linuxfoundation.org \
    --cc=gbastien+lttng@versatic.net \
    --cc=jgalar@efficios.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=pproulx@efficios.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).