[lttng-dev] [Patch LTTng-ust 6/7] Add the macros to generate the data structures for CTF named enumerations

[mathieu.desnoyers@efficios.com (Mathieu Desnoyers)]

----- Original Message -----
> From: "Stefan Seefeld" <stefan_seefeld@mentor.com>
> To: lttng-dev at lists.lttng.org
> Sent: Thursday, January 30, 2014 8:55:19 PM
> Subject: Re: [lttng-dev] [Patch LTTng-ust 6/7] Add the macros to generate the data structures for CTF named
> enumerations
> 
> On 01/30/2014 08:37 PM, Mathieu Desnoyers wrote:
> > ----- Original Message -----
> >> From: "Genevi?ve Bastien" <gbastien+lttng@versatic.net>
> >> To: lttng-dev at lists.lttng.org
> >> Sent: Friday, January 24, 2014 3:04:44 PM
> >> Subject: [lttng-dev] [Patch LTTng-ust 6/7] Add the macros to generate the
> >> 	data structures for CTF named enumerations
> >>
> >> Fills the macros to initialize the metadata for a tracepoint.
> >>
> >> From this patch on, the named metadata are enabled.
> > Now that I think about it, "named metadata" does not seem to be
> > semantically clear.
> > Perhaps we could change this to "global type declarations" ? Because this
> > is really
> > what it is: type declarations that are in the global scope of the metadata.
> > This applies
> > to all other patches in this series.
> 
> Mathieu,
> 
> I may be misunderstanding what you intend to relabel as "global type
> declarations", but I believe the term is too restrictive.
> I'm following this discussion with interest, as I have another use-case
> for meta-data which might be implementable very much like the named
> enums: constant or "event-static" fields. For example, we may want to
> store numeric values in events that need a (constant) scale factor (a
> unit of measurement), which would be well represented in meta-data, as
> opposed to redundantly inside events.
> And so, while I agree to your characterization of named enumerations as
> type declarations, I'm still looking at the mechanism as enabling the
> storage of named meta-data.

Hi Stefan,

Let's try to make sure I understand your intent here. Let's say we have
an event with a "weight" field (uint32_t). You would like to have
a multiplicative factor (e.g. *1000 for "kg") as a second field, that would
be entirely known from the metadata (pretty much a C literal in the metadata,
so it does not have to be repeated for each event).

There are various ways to do this I imagine: e.g.:

* Using the typing system

event {
  ...
  fields := struct {
    integer { size = 32; signed = false; align = 32; scale = 1000; } weight;
  };
};

* Another way to do this would be to associate a format string with the event:

event {
  ...
  fields := struct {
    integer { size = 32; signed = false; align = 32; } weight;
  };
  format = ("The weight is %u kg.", weight);
};

* Yet another way would be to associate the format string with the struct type:

event {
  ...
  fields := struct {
    integer { size = 32; signed = false; align = 32; } weight;
  } format ("The weight is %u kg.", weight);
};

But I don't see anything there that requires adding any top-level construct
to the CTF metadata. Hence, I am tempted to keep the name "global type declaration"
for the part of metadata located in the "global" section (opposed to within a
trace, env, stream, and event scope). Anyway, all we can declare there are types,
so it makes sense to use this name. If we ever add something to the CTF spec in the
future that is global but is not a type, then we'll have to extend the interfaces
and implementations (which should be expected if we extend the CTF spec).

Thanks,

Mathieu

> 
> 
> Thanks,
>         Stefan
> 
> --
> Stefan Seefeld
> CodeSourcery / Mentor Graphics
> http://www.mentor.com/embedded-software/
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com