On Wed, Aug 06, 2025 at 11:02:53AM +0200, Paolo Bonzini wrote: > On 8/5/25 22:06, Manos Pitsidianakis wrote: > > > If you're thinking this is all rather complicated, you'd be right, > > > which is why for initial feature parity I figured the simplest is > > > likely to just wrap the existing QEMU inline probe function, so > > > Rust doesn't need to know about the different backends... yet... > > It's not too hard to add individual backends (other than dtrace---see > below--and ust which doesn't build for me(*) and I wanted to deprecate). > Tanish is pretty close to being able to post initial work.
If we want to drop some backends that's fine, as IMHO we've got needlessly many there. > > Yes, that indeed makes sense. Generated C trace headers statically > > linked to a standalone trace crate library for each subsystem, that > > rust qemu crates can link to in return is the cleanest solution for > > this approach IMHO, because doing this kind of codegen via macros > > needs interaction with meson to generate the C sources and then run > > bindgen all while compiling this one crate which is a single meson lib > > target. > > > > It might be possible to generate the equivalent of the C code for each > > backend just like this RFC generates only the log backend code, I'll > > take a look out of curiosity... > > > > > FWIW, the original DTrace authors created a Rust crate with native > > > rust integration of dynamic probes. > > > > > > https://github.com/oxidecomputer/usdt > > > > > > I think that (somehow) we probably want to integrate that with QEMU > > > and its tracetool. > > This unfortunately only works for macOS and Solaris. It also has quite a > few dependencies (~25) on other crates. There is also a "probe" crate > (https://github.com/cuviper/probe-rs) that is minimal and (currently) > specific to Linux, which is what I planned to use. > > By the way, while I like the idea of using Rust format strings, there are > parts of tracetool (e.g. format/log_stap.py) that need the printf strings, > and also backends (e.g. backend/syslog.py) that call into libc and therefore > need to use printf format strings. So I think we're stuck. Note, I would describe our format strings as printf-like/light. We certainly do NOT allow the full range of C library formats, because we need to be able to pass the format strings to systemtap, which is likewise merely printf-like. Do don't really do any significant upfront validation on the format specifiers beyond checking for invalid %m and newlines. In practical terms though the only things we can use are %x %u %d %s %p with optional 'l', 'll' or 'z' modifiers and digit precision for the int formats. Anything beyond that will likely fail with systemtap. We ought to move validation for this to the parsing phase to strongly enforce this limited syntax. IOW, in any tracetool format generator for rust, we could fairly easily translate the format string from printf-like to rust style. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
