Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: Philippe Proulx via lttng-dev <lttng-dev@lists.lttng.org>
To: RADERMACHER Ansgar <Ansgar.RADERMACHER@cea.fr>
Cc: "lttng-dev@lists.lttng.org" <lttng-dev@lists.lttng.org>
Subject: Re: [lttng-dev] [barectf] model.emf.uri
Date: Mon, 1 Feb 2021 08:02:24 -0500	[thread overview]
Message-ID: <CAB4xu_0dP0Hu9pcu7v12c6mjaaTVSrocDZ3f4gJHDge+xzD0jQ@mail.gmail.com> (raw)
In-Reply-To: <386C5D4D5C53C24CBC2C60CAAFD2136A5B4A40A0@EXDAG0-B1.intra.cea.fr>

On Mon, Feb 1, 2021 at 4:39 AM RADERMACHER Ansgar via lttng-dev
<lttng-dev@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@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

  reply	other threads:[~2021-02-01 13:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01  9:12 RADERMACHER Ansgar via lttng-dev
2021-02-01 13:02 ` Philippe Proulx via lttng-dev [this message]
2021-02-05 11:05   ` Ansgar Radermacher 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=CAB4xu_0dP0Hu9pcu7v12c6mjaaTVSrocDZ3f4gJHDge+xzD0jQ@mail.gmail.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=Ansgar.RADERMACHER@cea.fr \
    --cc=eeppeliteloop@gmail.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: link
Be 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