Re: Rust in QEMU roadmap

[Stefan Hajnoczi]

On Tue, 26 Nov 2024 at 13:04, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Tracing/logging
> '''''''''''''''
>
> Tracepoints and logging are not supported yet, and no one has started working
> on it.
>
> For tracing, it's not clear to me how much C code can be reused and how
> much Rust code can be automatically generated.  This would be a valid
> Outreachy or Summer of Code project, as it has a limited need for unsafe
> code and a well-defined scope.
>
> A pure-Rust implementation would be interesting, but note that the usage
> of printf-style %-based field formatting is pervasive in the tracing
> subsystem.

The purpose of QEMU's tracing subsystem is to support cross-platform
tracing. Instead of making QEMU code depend on a specific tracer (like
DTrace or LTTng UST) that may not be available across platforms, the
tracing subsystem generates tracer-specific C code for trace events at
compile time. The most straightforward way to expose this to Rust is
to add C functions that invoke each trace event and then call those C
functions from Rust. Tracing is designed to be lightweight and this
approach results in more overhead than in native C tracing though.

A pure Rust solution would be nice, but I'm not sure how to reconcile
that with the purpose of the tracing subsystem, which is to support
the various tracers native to QEMU's host platforms. They are geared
towards C and use low-level techniques to generate low overhead
tracing code.

About format strings, QEMU tracing is not about format strings.
Otherwise logging would just be used instead. Trace event definitions
contain a format string so that tracers that offer human-readable
formatting can use that string. Actual tracing is not about string
formatting though, it's about typed calls to <trace-event>(<arg1>,
<arg2>, ...) where those typed arguments can be captured efficiently
by the tracer (e.g. stored as binary records). Depending on the
tracer, the format string might never be used, be used in a
post-processing step during offline trace file analysis, or at runtime
(like logging).

That's what QEMU's tracing subsystem is today. But it's a low activity
subsystem where things can be changed with less disruption to users
than in most other subsystems. I think it would be nice to look at
what native Rust tracing has to offer ad reconsider some of the
requirements that shaped QEMU's C tracing subsystem. Maybe we can take
a more modern approach.

>
> Logging is a small component of QEMU and it's a good opportunity to define
> a coding style for C code translated to Rust, e.g. how to name enums and
> functions.  My only request is to allow using the same syntax as format!()
> for logging code!
>
> Summary:
>
> * Simple, low priority.
>
> * Anybody wants a small project to learn Rust FFI?