On Tue, 26 Nov 2024 at 13:04, Paolo Bonzini <pbonz...@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?