Re: [tracecompass-dev] Trace type vs trace profile

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

This makes a lot of sense since traces can have one type, that is how we
parse it, but many profiles.

Consider that you can have event aggregators, event sources and programs.

Program 1 follows the opentracing api

Program 2 is a finstrumented program

Program 3 is a js program running in chrome

Program 4 is running an OpenGL frontend

Then there's the kernel.

So now, we have
1, 3, and 4 that generate a json trace
1, 2, and the kernel generate a ctf trace

we make an experiment with
1(ctf), 2, 3, 4 and the kernel trace.

The parsers are fine, but how do we know which analyses to assign to
which trace.

That being said, trace profile is ambiguous since traces like LTTng have
profiles already. Maybe we can discuss different names.

I like Capabilities.

So 1 would have "span", "callsite" and "call stack" capabilities
2 would just have "call stack"
3 would have all of one as well as "counter" and "Memory"
4 would have "request"
and kernel would have "kernel" which hopefully will be broken down into
"process/thread" "CPU state", "Run queues", "IO", "Memory", "swapper"...

The "Capabilities" should not be coupled to a file format.
That way we can test with arrays or XML files without having to make
"kernelTraceStubs"...

So I really like this idea, should it be incubating?

Counterthoughts?

Matthew

On 17-10-12 10:34 AM, Geneviève Bastien wrote:
> Hi all,
>
> Here's a topic I've been munching the past months. I think we've reached
> the limits of the concept of "trace type", or at least, it's being used
> for more than it should.
>
> A trace has one and only one "trace type" and analyses are linked to the
> trace type. But that trace type refers more to the trace format, ie how
> to read the trace, while the analyses relate to the content of the
> trace. And the more trace types we have, the more their content overlap
> and analyses from other trace types apply.
>
> To name a few example, an LTTng JUL Trace from a Trace Compass
> application has the same events/fields as a trace-event trace. A
> perf2ctf trace has both kernel and userspace data.
>
> So I'm proposing to add the concept of "trace profile", which will
> correspond to the content of the trace. A trace can have many profiles,
> some profiles can be guessed from the trace type, especially if it has
> pre-defined events. And the user  can add profiles to her trace. The
> analyses would be linked to a profile instead of a trace type.
>
> I'll experiment with it in the incubator, but that concept should
> definitely be in the core.
>
> Thoughts?
>
> Geneviève
>
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev