Re: [PATCH RFC 0/5] rust: implement tracing

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

On Wed, Aug 6, 2025 at 12:21 PM Daniel P. Berrangé <berrange@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 :|
>