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 consensus > > You 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 already > > Yes 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/1843 Thanks! 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? > 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/lisa > > > > Thanks, > > Hidenori > > Thanks, > > Douglas Thanks, Hidenori
|