On 14-02-2023 03:56, Hidenori Kobayashi wrote:
Hi Douglas, On Mon, Feb 13, 2023 at 12:04:36PM +0000, Douglas Raillard wrote:Hi Hidenori,On 13-02-2023 05:17, Hidenori Kobayashi wrote: Hi Douglas, On Fri, Oct 14, 2022 at 04:16:33PM +0100, Douglas Raillard wrote:Hi everyone, The idea of having some Rust interop for libtraceevent was floated during the Tracing Summit that took place this week. The overall work has two scopes: 1. libtraceevent: low-level helpers to decode event formats and binary buffer pages. 2. high level API that e.g. can consume a trace.dat file and expose an iterator API etc. The current discussion is only about #1. The 2nd part of the work has an entirely different set of constraints as it would aim at integrating in the Rust ecosystem as well as possible without trying to replace anything pre-existent.Has anyone actually started working on these?We have, this has been my main focus since around November.I have a Rust tool that parses the output from trace-cmd to infer the internal states of a kernel module. While it serves our needs for now, Steven kindly pointed me to this thread and suggested interacting directly with the tracefs and using the tracefs libraries for parsing. So I'd like to know: - if this discussion reached a consensusYou are the first one to answer on that thread but the twitter poll from Steven was encouraging. At any rate, we need it for LISA [1] so I'm making it happen.- if there is any publicly available work alreadyYes and no: I'm currently developing it as part of LISA but in its own "traceevent" crate, as added by that PR under tools/analysis/traceevent/: https://github.com/ARM-software/lisa/pull/1843Thanks! Let me take a look. Do you intend to keep this inside the LISA project repository? The LISA project per se is interesting, but I feel your work is also valuable for other projects. Is there any chance that this becomes a standalone crate?
Yes, LISA is not necessarily the final location of that piece of code. I've made it as a separate crate from the other Rust bits so it can be split effortlessly when the time comes.
This is very much WIP, so far I got: * A parser for v6 header up to and including the event formats. Since that requires a C parser, it was a large chunk of the total work. * A C interpreter as (somewhat) required for array lengths and mostly for the print fmt args. * a zero-copy I/O layer that can load data from: * existing in-memory buffer * Any type implementing Read + Seek * mmap Adding support for v7 header should be straightforward except for the I/O that might require adjustment depending on how compression is implemented. My current roadmap is: 1. Get to a state where I can share a trace-cmd report equivalent static tool for people to play with on their own data and report issues. 2. Make a serde backend hooked to it since we need it for LISA (assuming performance is good enough) 3. Figure out exactly how it sits in the libtraceevent ecosystem and maintains it in the long run, libtraceevent-style C bindings etc. Note that if and when a serde backend is available, that should bring a conversion to JSON for basically free. Unless I'm sidetracked by urgent things, 1. and 2. should become available in a few months. I expect 3. to happen when I have something concrete to show to the world. [1] LISA: https://github.com/ARM-software/lisaThanks, HidenoriThanks, DouglasThanks, Hidenori
|