Philippe Proulx On Tue, Oct 25, 2016 at 2:27 PM, Philippe Proulx <ppro...@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 _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev