Hi Carlo, > > > This leads to, as always, whats is the end goal here? > > This is the context: I'm tracing a Linux kernel (using LTTng) while in > parallel I'm tracing a process running in a bare-metal OS (running on the > same machine but on different cores using a partitioning hypervisor).
Nice. > > The binary trace data obtained from the bare-metal OS is converted to CTF > using babeltrace in a format resembling LTTng (to be analyzed with > TraceCompass). In both case, babeltrace and tracecompass based analysis should leave the trace merging to the parser/decoder/muxer. There should be no need to merge them in a single CTF trace. The thing that is important is to correlate the clock from both traces to allow the tools to do a proper merge. Then you consume the events and build state etc. How you correlate those clocks depends on the tracing scenario. I would recommend you speak to the Tracecompass devs [1] on how they handle multiple "kernel" traces (linux + converted baremeta) in "experiment" [2] and how clock correlation works [3] on their side. This is if you plan to mostly use Tracecompass for analysis. If you plan to use babeltrace, we can discuss this more as needed. [1] https://www.eclipse.org/tracecompass/#community [2] https://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/Trace-Compass-Main-Features.html#Creating_an_Experiment [3] https://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/Time-offsetting.html#Time_offsetting -- Jonathan Rajotte-Julien EfficiOS _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev