Hello Paolo, On Wed, Aug 6, 2025 at 12:03 PM Paolo Bonzini <[email protected]> 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.
Ack, I look forward to it :) I hope my RFC provides them some inspiration on what things (not) to do. Thanks, > > > 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. > > Paolo > > (*) that's because this tracepoint: > > visit_type_str(void *v, const char *name, char **obj) "v=%p name=%s obj=%p > > incorrectly handles 'char **' as a string. The breakage has been there > since 2016, though probably it's only more recent versions of ust that > actually fail to compile and until then the bug was latent until you > enabled this tracepoint. But it seems unlikely that anyone has used the > ust backend recently. > -- Manos Pitsidianakis Emulation and Virtualization Engineer at Linaro Ltd
