[lttng-dev] Ctf specification on Variants and Enums

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Thu Dec 5 17:33:33 EST 2013

----- Original Message -----
> From: "Matthew Khouzam" <matthew.khouzam at ericsson.com>
> To: lttng-dev at lists.lttng.org
> Sent: Thursday, December 5, 2013 11:19:44 PM
> Subject: [lttng-dev] Ctf specification on Variants and Enums
> Hi,
> In the ctf specifications variants need a tag that is an enum. An enum
> can have identifiers as Strings. The enum can contain strings.
> so if you have an enum:int32{"a","b","c", d} tag;
> and a variant <tag> { int "a"; int "b"... } according to the spec it

you need:

variant <tag> { int a; int b; }

with field names, no double quotes.

> should be fine.
> according to the test cases it fails.
> Please clarify where my logic went astray.
> Also, in reading the spec, there are no guaranties that enums contain
> ANY values of the fields of the variants. I think this is problematic
> enum { a,b,c}
> variant{
> x,y,z} passes.

Yes, it does pass. It will produce errors at stream read if an enum
chosen does not match what is available in the variant. I thought about this
yesterday (being restrictive or accepting in mapping between variant and
enum), and I ended up realizing that some use-cases could re-use the same
enum type with many variants, and we can have extra enum entries used for
other purposes than the variant the enum is used by, so basically, we
cannot really enforce to have a full mapping 1 to 1 without restricting
some usage. Therefore, I went down the road to only check at stream read
if the stream contains enum values that do not map to a variant field, and
error out at that point. Not at metadata parsing.



> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Mathieu Desnoyers
EfficiOS Inc.

More information about the lttng-dev mailing list