On Thu, 2025-12-04 at 11:01 -0500, Philippe Proulx wrote: > On Thu, Dec 4, 2025 at 10:47 AM MOESSBAUER, Felix > <[email protected]> wrote: > > > > Well... This is a more generic question if it is really the job of the > > serializer to fix possible name clashes in the output. Anyways, > > unfortunately LTTng uses this field and does not allow escaping. > > Although I understand the question, I will not take the time to > re-evaluate a design that involves CTF 1.8. I'm currently in a "quick > fixes only" mode for this format, with the sole aim of keeping existing > scenarios working. > > > I would love to switch to CTF2, however we need support for it in > > trace-compass, which AFAIK is not even implemented yet. > > We're currently investigating the status of CTF 2 support in Trace > Compass and what amount of work is remaining. We'll let you know. > > > This is tricky, as we don't really know if the trace is an LTTng trace > > or not. However, we can hide it behind the proposed create-lttng-index > > flag, as it is anyways only needed in combination with an index (I > > still don't know why, but ok...). > > Yes we know. Have a look at make_lttng_trace_path_rel().
I already checked this function, but this is a bit too-strict, as really only adding the index breaks the import. I also want to be able to add the index to non lttng traces (which for instance lack some env metadata) as otherwise the ftrace-to-ctf converter needs to fake the metadata. > > `create-lttng-index` would be another hint, but the trace environment > has been good enough so far. This is easy to implement and works perfectly fine. By that, traces without an lttng index have "_cpu_id" and can be imported in trace- compass. Traces with an lttng index get "cpu_id" and also now import correctly. I hope this solution is acceptable. Anyways, thanks for the quick support. Felix > > Phil -- Siemens AG Linux Expert Center Friedrich-Ludwig-Bauer-Str. 3 85748 Garching, Germany
