From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org> To: Jeremie Galarneau <jeremie.galarneau@efficios.com> Cc: diamon-discuss <diamon-discuss@linuxfoundation.org>, Jeremie Galarneau <jgalar@efficios.com>, lttng-dev <lttng-dev@lists.lttng.org>, Philippe Proulx <pproulx@efficios.com>, Genevieve Bastien <gbastien+lttng@versatic.net> Subject: Re: [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined Date: Fri, 24 Apr 2020 10:05:38 -0400 (EDT) [thread overview] Message-ID: <1018622507.68153.1587737138598.JavaMail.zimbra@efficios.com> (raw) In-Reply-To: <CA+jJMxvqe5sYq3f7kDMthTfiC7oNR1Awok-R2CdKJgRHowuXTA@mail.gmail.com> ----- On Apr 23, 2020, at 6:51 PM, Jeremie Galarneau jeremie.galarneau@efficios.com wrote: > On Thu, 23 Apr 2020 at 16:52, Mathieu Desnoyers > <mathieu.desnoyers@efficios.com> wrote: >> >> From: Geneviève Bastien <gbastien+lttng@versatic.net> >> >> Signed-off-by: Geneviève Bastien <gbastien+lttng@versatic.net> >> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> >> --- >> common-trace-format-specification.md | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/common-trace-format-specification.md >> b/common-trace-format-specification.md >> index fd49e59..f5fea51 100644 >> --- a/common-trace-format-specification.md >> +++ b/common-trace-format-specification.md >> @@ -464,6 +464,9 @@ enum { >> } >> ~~~ >> >> +The mappings in the enumeration type do not have to be exhaustive. >> +Unlisted values are implementation defined. >> + > > This is too vague to be useful knowing that the main rationale for this > change is to allow enums to express some type of bitfield of flags > in the tracer and readers [1]. > > What is the meaning of an unmapped value? This section should at > least describe the correct interpretation of unmapped values as flags > and when it is appropriate to do so. Considering that this is a patchlevel update to CTF, I would not expect that we introduce new features in the specification. Only clarifications to parts of the specification that were unclear. Specifying a new behavior related to unmapped values would fall IMO into the realm of "new feature", and would belong to a CTF 1.9 or CTF 2.0. As we all know, there is a CTF 2.0 in the making, but it does not solve the immediate problem of LTTng 2.12 which produces those unmapped enum values within traces identified as CTF 1.8. Moreover, to add to the problem, Babeltrace 2 has a strict match on CTF 1.8 in the CTF source plugin, and won't accept a CTF 1.9 trace (unlike Babeltrace 1 which would emit a warning about possibly unsupported features, but would accept a 1.9 CTF trace nevertheless). So this is why I am proposing this minimal clarification to the CTF 1.8 specification: that unmapped enum values are implementation defined (rather than saying nothing about them). Considering that tracers can generate this kind of trace data anyway, it's really a consideration that should have been explicitly expressed in the specification from the start and was an involuntary omission. So perhaps we need to state something more than just "implementation defined", but it's unclear what without ending up adding features into a patchlevel update. Thanks, Mathieu > Thanks, > Jérémie > > [1] https://review.lttng.org/c/babeltrace/+/3045 > >> ### 4.2 Compound types >> >> Compound are aggregation of type declarations. Compound types include >> -- >> 2.11.0 >> > > > -- > Jérémie Galarneau > EfficiOS Inc. > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org> To: Jeremie Galarneau <jeremie.galarneau@efficios.com> Cc: diamon-discuss <diamon-discuss@linuxfoundation.org>, Jeremie Galarneau <jgalar@efficios.com>, lttng-dev <lttng-dev@lists.lttng.org>, Philippe Proulx <pproulx@efficios.com>, Genevieve Bastien <gbastien+lttng@versatic.net> Subject: Re: [lttng-dev] [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined Date: Fri, 24 Apr 2020 10:05:38 -0400 (EDT) [thread overview] Message-ID: <1018622507.68153.1587737138598.JavaMail.zimbra@efficios.com> (raw) Message-ID: <20200424140538.fJBiiwrjs2g3aPX1wUlKfmbNAZ-CiitHYRYSTuaMrok@z> (raw) In-Reply-To: <CA+jJMxvqe5sYq3f7kDMthTfiC7oNR1Awok-R2CdKJgRHowuXTA@mail.gmail.com> ----- On Apr 23, 2020, at 6:51 PM, Jeremie Galarneau jeremie.galarneau@efficios.com wrote: > On Thu, 23 Apr 2020 at 16:52, Mathieu Desnoyers > <mathieu.desnoyers@efficios.com> wrote: >> >> From: Geneviève Bastien <gbastien+lttng@versatic.net> >> >> Signed-off-by: Geneviève Bastien <gbastien+lttng@versatic.net> >> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> >> --- >> common-trace-format-specification.md | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/common-trace-format-specification.md >> b/common-trace-format-specification.md >> index fd49e59..f5fea51 100644 >> --- a/common-trace-format-specification.md >> +++ b/common-trace-format-specification.md >> @@ -464,6 +464,9 @@ enum { >> } >> ~~~ >> >> +The mappings in the enumeration type do not have to be exhaustive. >> +Unlisted values are implementation defined. >> + > > This is too vague to be useful knowing that the main rationale for this > change is to allow enums to express some type of bitfield of flags > in the tracer and readers [1]. > > What is the meaning of an unmapped value? This section should at > least describe the correct interpretation of unmapped values as flags > and when it is appropriate to do so. Considering that this is a patchlevel update to CTF, I would not expect that we introduce new features in the specification. Only clarifications to parts of the specification that were unclear. Specifying a new behavior related to unmapped values would fall IMO into the realm of "new feature", and would belong to a CTF 1.9 or CTF 2.0. As we all know, there is a CTF 2.0 in the making, but it does not solve the immediate problem of LTTng 2.12 which produces those unmapped enum values within traces identified as CTF 1.8. Moreover, to add to the problem, Babeltrace 2 has a strict match on CTF 1.8 in the CTF source plugin, and won't accept a CTF 1.9 trace (unlike Babeltrace 1 which would emit a warning about possibly unsupported features, but would accept a 1.9 CTF trace nevertheless). So this is why I am proposing this minimal clarification to the CTF 1.8 specification: that unmapped enum values are implementation defined (rather than saying nothing about them). Considering that tracers can generate this kind of trace data anyway, it's really a consideration that should have been explicitly expressed in the specification from the start and was an involuntary omission. So perhaps we need to state something more than just "implementation defined", but it's unclear what without ending up adding features into a patchlevel update. Thanks, Mathieu > Thanks, > Jérémie > > [1] https://review.lttng.org/c/babeltrace/+/3045 > >> ### 4.2 Compound types >> >> Compound are aggregation of type declarations. Compound types include >> -- >> 2.11.0 >> > > > -- > Jérémie Galarneau > EfficiOS Inc. > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
next prev parent reply other threads:[~2020-04-24 14:05 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-23 20:52 [RFC PATCH CTF 0/3] Common Trace Format Updates (upcoming 1.8.3) Mathieu Desnoyers via lttng-dev 2020-04-23 20:52 ` [RFC PATCH CTF 1/3] Clarify that unlisted enum values are implementation-defined Mathieu Desnoyers via lttng-dev 2020-04-23 22:51 ` Jérémie Galarneau via lttng-dev 2020-04-24 14:05 ` Mathieu Desnoyers via lttng-dev [this message] 2020-04-24 14:05 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev 2020-04-28 18:40 ` Philippe Proulx via lttng-dev 2020-04-28 18:40 ` [lttng-dev] " Philippe Proulx via lttng-dev 2020-04-28 18:51 ` Mathieu Desnoyers via lttng-dev 2020-04-28 18:51 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev 2020-04-29 12:08 ` Mathieu Desnoyers via lttng-dev 2020-04-29 12:08 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev 2020-04-29 16:50 ` Philippe Proulx via lttng-dev 2020-04-29 16:50 ` [lttng-dev] " Philippe Proulx via lttng-dev 2020-04-23 20:52 ` [RFC PATCH CTF 2/3] Clarify monotonicity requirement on timestamp begin Mathieu Desnoyers via lttng-dev 2020-04-28 18:42 ` Philippe Proulx via lttng-dev 2020-04-28 18:42 ` [lttng-dev] " Philippe Proulx via lttng-dev 2020-04-28 18:54 ` Mathieu Desnoyers via lttng-dev 2020-04-28 18:54 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev 2020-04-23 20:52 ` [RFC PATCH CTF 3/3] Clarify that timestamp begin/end need to be complete clock values 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=1018622507.68153.1587737138598.JavaMail.zimbra@efficios.com \ --to=lttng-dev@lists.lttng.org \ --cc=diamon-discuss@linuxfoundation.org \ --cc=gbastien+lttng@versatic.net \ --cc=jeremie.galarneau@efficios.com \ --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: linkBe 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).