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

[Mathieu Desnoyers]

----- Original Message -----
> From: "Stefan Seefeld" <stefan_seefeld at mentor.com>
> To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> Cc: lttng-dev at lists.lttng.org
> Sent: Monday, February 3, 2014 10:41:14 AM
> Subject: Re: [lttng-dev] [Patch LTTng-ust 6/7] Add the macros to generate the data structures for CTF named
> enumerations
> 
> On 02/03/2014 10:28 AM, Mathieu Desnoyers wrote:
> 
> > 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).
> 
> Right. The analogy with a C literal isn't entirely sufficient, as there
> is a range of situations where in fact "constant" doesn't map to
> compile-time constant in C/C++. Thus...

Can you provide a concrete example of what you envision ? What would
this look like an an "extended" CTF metadata ?

Thanks,

Mathieu

> 
> > There are various ways to do this I imagine: e.g.:
> > 
> > * Using the typing system
> 
> 
> [...]
> 
> ...the typing system can't quite capture values that are immutable
> within a running session, but not quite constant in the sense that they
> can be captured in a type system.
> 
> So perhaps another way to look at it is like a static class member, for
> which storage isn't part of each instance of the class, but rather
> somewhere that's associated with all instances of the class...
> 
> > But I don't see anything there that requires adding any top-level construct
> > to the CTF metadata.
> 
> ...and that "somewhere" would naturally be the metadata section of the
> traces.
> 
> > 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).
> 
> Right. I wasn't arguing so much against the use of "global type
> declaration" for the case of named enums, but merely wanted to point out
> that the mechanism could be extended to cover non-type-related metadata.
> 
> Thanks,
> 		Stefan
> 
> 
> --
> Stefan Seefeld
> CodeSourcery / Mentor Graphics
> http://www.mentor.com/embedded-software/
> 

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