Re: libtracecmd API extensions

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 20 Nov 2025 12:24:18 +0000
"MOESSBAUER, Felix" <felix.moessbauer@siemens.com> wrote:

> Dear Tracers,

Hello!

> 
> while developing a kernel ftrace to Common Trace Format (CTF) converter
> [1], I noticed a couple of aspects of the libtracecmd API I would like
> to discuss. In general, I am VERY happy with the libtracefs,
> libtraceevent and libtracecmd API. These are great libraries which
> really helped to get this implemented easily.
> 
> Trace clocks:
> 
> - Information about the used trace clock is available in the trace.dat,
> however there is no public API to extract it
> - A trace clock (e.g. mono) to world-clock snapshot could be added to
> the trace.dat to more easily align the trace with other traces
> 
> Metadata:
> 
> - some metadata (like uname) is already included in the trace.dat,
> however the APIs to retrieve it are private: tracecmd_get_uname
> - further metadata like a full "uname -a" output and /proc/cmdline
> would be helpful

So, libtracecmd is still very much a work in progress, of something I never
seem to have the time to work on :-p  I don't want to make the mistake I
made with libtraceevent, and have APIs exposed before they are ready. I hate
most of the libtraceevent APIs, but that's because it was ported over to
perf before it was complete, and we got stuck with what we have.

libtracefs was much more planned, and has a better API because of that.

I have lots of ideas for libtracecmd. In fact, the goal is to make
trace-cmd a simple shell of the library, and have every feature of
trace-cmd exposed to other tools. Unfortunately, I just don't have the time
to work on it.

Hence, if you want to add these APIs, I'm more than happy to review any
patches you send my way!

> 
> Event time ranges:
> 
> - it would be good to have an API to get the first and last event
> timestamp per CPU (I'm currently fully walking the events to get that
> data)

Hmm, I could have sworn I implemented something like this in the past.
Perhaps I only did it to my local tree. I have lots of updates to trace-cmd
that haven't made it out to public (simply because they are still in debug
form).

There is a way to iterate backwards:

  tracecmd_iterate_events_reverse()

That would give you the last event without walking all events.

> 
> PS:
> We are also looking into writing a converter in the opposite direction
> (i.e. CTF -> ftrace binary format / trace.dat), but it looks like the
> libtraceevent is a pure parsing library and cannot be used for
> synthesizing. Is this true, or did I miss something?
> 

Yeah, libtraceevent was made to be purely parsing. In fact, there was an
effort to convert it over to flex/bison. But again, time ran out.

That said, if you want to add a feature to create formats, that could
definitely be added.

Cheers,

-- Steve