[lttng-dev] [barectf] model.emf.uri

[Ansgar Radermacher]

Hi Philippe,

thanks for the response. For the moment, the trace transformation adds 
the model.emf.uri directly to the metadata file after generation with 
barectf. If you point me to the right sources, I might be able to add it 
to barectf (if producing CTF 1.8 traces). Do you know, if other trace 
viewers, notably TraceCompass will continue to support the model.emf.uri 
tag?

Best regards

Ansgar

On 01/02/2021 14:02, Philippe Proulx wrote:
> On Mon, Feb 1, 2021 at 4:39 AM RADERMACHER Ansgar via lttng-dev
> <lttng-dev at lists.lttng.org> wrote:
>> Hello,
>>
>> we're currently working on CTF code instrumentation in the C++ code generation from Papyrus. Unlike in a previous version, we use BareCTF.
>>
>> In this context, the metadata tag "model.emf.uri" can contain the URI of the element to trace. This works fine in TraceCompass, if we manually add the URI to the metadata, as shown below. But I have not been able to add an entry to BareCTF's config.yaml that produces the model.emf.uri in the generated metadata file. Is it possible?
>>
>> I could not find an suitable example in the documentation - I experimented with the "specific-context-field-type", but it also adds a parameter to the generated C code functions which is not what I want.
>>
> Thank you for writing Ansgar.
>
> Although barectf 3 generates tracers which produce CTF 1.8 traces, the
> ultimate goal of the project is to adopt CTF 2. This is why the model
> and vocabulary of its configuration format are very close to what's
> proposed in CTF2-PROP-2.0 [1].
>
> CTF 2 is not released yet as we still need to implement and experiment
> with CTF2-PROP-2.0 in our open-source tools (LTTng, Babeltrace, and
> barectf) before publishing CTF2-SPEC-2.0.
>
> In CTF 2, we decided to remove the EMF URI concept [2]:
>
>> The EMF URI property is removed from the event record class.
>>
>> This Eclipse Modeling Framework property is not common enough for the
>> Common Trace Format.
>>
>> A producer can still write such an URI as an event record class’s user
>> attribute.
> Indeed, we believe this property in CTF 1.8 is too specific to remain a
> part of the core specification of CTF 2.
>
> As the quotation above indicates, the alternative will be to specify the
> EMF URI as a custom event record class user attribute [3], under a
> specific namespace. My guess is that another specification document will
> emerge from some organization to show the exact namespace and user
> attribute name. In barectf 3, it could look like this (event record type
> object):
>
>      my-event:
>        user-attributes:
>          eclipse.org:
>            emf-uri:
> platform:/resource/DemoTrace/DemoTrace.uml#_AVreJm9fEeqJeI8mbLLRcg
>        payload-field-type:
>          class: structure
>          members:
>            - msg: string
>            - id: uint32
>
> Unfortunately, we're currently in a stage of transition from CTF 1.8 to
> CTF 2. We can't add the user attribute feature until CTF2-SPEC-2.0 is
> ratified.
>
> That being said, I can accept that barectf 3 has the EMF URI feature,
> but only when it generates CTF 1.8-producing tracers. I don't have time
> to implement this currently, but I will accept a patch. Tell me if you
> want to do this; I'll give you more details.
>
> BR,
>
> Phil
>
> [1]: https://diamon.org/ctf/files/CTF2-PROP-2.0rA.html
> [2]: https://diamon.org/ctf/files/CTF2-PROP-2.0rA.html#_changes_since_ctf1
> [3]: https://diamon.org/ctf/files/CTF2-PROP-2.0rA.html#user-attrs
>
>> Best regards
>>
>> Ansgar
>>
>>
>> ...
>> event {
>>      stream_id = 0;
>>      id = 1;
>>      name = "state_C1_FirstState_state";
>>      model.emf.uri = "platform:/resource/DemoTrace/DemoTrace.uml#_AVreJm9fEeqJeI8mbLLRcg";
>>      fields := struct {
>>          string {
>>              encoding = UTF8;
>>          } instanceId;
>>      } align(1);
>> };
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> .