[lttng-dev] CTF2-BASICATTRS-1.0: Basic CTF 2 user attributes

[Philippe Proulx]

Philippe Proulx
On Tue, Oct 25, 2016 at 2:27 PM, Philippe Proulx <pproulx at efficios.com> wrote:
>
> [[event-record-class-fragment-bua]]
> == Event record class fragment's basic user attributes
>
> .Event record class fragment's basic user attributes mdt:map properties
> [options="header"]
> |===
> |Name |Type |Description |Required? |Default m-value
>
> |`description`
> |mdt:string
> |Textual description of the event record class fragment.
> |Optional
> |No description.
>
> |`name`
> |mdt:string
> |Event record class's name or instrumentation point's name.
> |Optional
> |No name.
>

Should we also put a namespace for the event record class fragment
itself here? I'm talking about an `ns` property as a basic user
attribute, e.g.:

    {
      "fragment": "event-record-class",
      "user-attrs": {
        "diamon.org/ctf/ns/basic": {
          "description": "My favorite event record class.",
          "ns": "lttng.org/ns/ctf/modules",
          "name": "sched_switch",
          "major": 1,
          "minor": 0,
          "patch": 2,
          "log-level": "TRACE_CRIT"
        }
      },
      ...
    }

This could avoid eventual name clashes between tracers, and also allow
different tracers to output the "same" event records. Let me illustrate
both scenarios:

1. Consider this event record class fragment:

       {
         "fragment": "event-record-class",
         "user-attrs": {
           "diamon.org/ctf/ns/basic": {
             "name": "new_msg",
             "major": 1,
             "minor": 1,
             "patch": 3,
             ...
           }
         },
         ...
       }

   Assume that this is produced by LTTng-UST. An analysis reads this
   and is able to know that it's an event record class named `new_msg`,
   version 1.1.

   However, without a namespace, the analysis has to rely on the tracer
   information found in the user attributes of the trace class fragment
   (`producer-id`), which is optional by the way, to make sure that it's
   event record class `new_msg` produced by some known tracer(s).

   This is not super reliable. You should never rely on the producer ID,
   it's just extra information about the origin of the trace. This is
   the equivalent of relying on the `tracer_name` environment entry
   in CTF 1.x.

2. Consider the same event record class fragment as in #1.

   What if multiple tracers can emit the specific events described by
   this class (same name, same version, same meaning). Then every
   analysis needs to know that this and this specific tracer can produce
   this event record class.

   If a future tracer also wants to produce this, then all the analyses
   must be updated to support this new producer.

If you namespace the event record class itself, then you have a solution
for points 1 and 2 above:

1. No need to rely on the producer ID: use the unique event record
   class's namespace (and its name within this namespace) to know its
   meaning.
2. Multiple producers with different producer IDs can write the
   same event record class fragment with a given namespace and name.

The `ns-aliases` trace class fragment basic user attribute could or
could not have an effect on this `ns` attribute. If it does, here's an
example:

    {
      "fragment": "trace-class",
      "user-attrs": {
        "diamon.org/ctf/ns/basic": {
          ...
          "ns-aliases": {
            "basic": "diamon.org/ctf/ns/basic",
            "modules": "lttng.org/ns/ctf/modules"
          },
          ...
        }
      },
      ...
    }

    ...

    {
      "fragment": "event-record-class",
      "user-attrs": {
        "basic": {
          "ns": "modules",
          "name": "sched_switch",
          "major": 1,
          "minor": 0,
          "patch": 2,
          ...
        }
      },
      ...
    }

Thoughts about this?

Philippe Proulx