Hi Douglas, On Tue, Feb 14, 2023 at 10:38:52AM +0000, Douglas Raillard wrote: > 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 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? > > 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. Looking forward to the upcoming announcement! > > > > > 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 >
|