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.
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.
