On Wed, Aug 6, 2025 at 12:21 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > > 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 > > thereforepar > > 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.
That simplifies things in a major way (printf specifiers are so complex they are turing complete). It'd be trivial to parse and convert into equivalent Rust formatting if you constraint specifiers like you say. > > 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 :| >
