Hello Paolo, Bernhard, On Mon, May 12, 2025 at 6:32 PM Paolo Bonzini <pbonz...@redhat.com> wrote: > > Hi, now that GSoC selection is over I'm back. Sorry for the delay; > Tanish Desai will work mostly on tracing, so logging can remain yours. > > On Tue, Apr 8, 2025 at 10:59 PM Bernhard Beschow <shen...@gmail.com> wrote: > > >Currently the #defines contain some holes for "private" mask bits. Turning > > >these into an > > >enum without exposing all publicly, and changing the type of qemu_loglevel > > >for > > >consistency, would result in undefined behavior. Or do you suggest to > > >convert just > > >the public #defines into an enum to expose them to Rust, and keep the rest > > >of > > >the C API including the type of qemu_loglevel as is? > > Yes, only in Rust. > > > >There are surely several tradeoffs and/or cleanups possible here, but > > >that's way beyond for > > >what I wanted to achieve -- which is closing a gap between C and Rust. My > > >main goal is just > > >to get my feet wet with Rust. > > I understand, however there is no point in defining an API and then changing > it. > > So we need to answer the questions I wrote a few messages ago, namely: > > - the mapping the LOG_* constants into Rust (e.g. whether to keep the > uppercase SNAKE_CASE or switch to something like Log::GuestError). > > - whether to keep the "qemu" prefix for the API (personal opinion: no) > > I agree with not having macros such as log_guest_error! for now, or > not wrapping functions like qemu_log_trylock/qemu_log_unlock that > would be implemented as RAII (i.e. returning a "guard" object) in > Rust. > > > >>Also, while this is good for now, later on we probably want to > > >>reimplement logging at a lower level via the std::fmt::Write trait. But > > >>that's just for efficiency and your macro is indeed good enough to define > > >>what the API would look like. > > > > > >Can we live with an easy solution then for now? As you suggest below, > > >further abstractions like log_guest_error! can be built on top which > > >further insulates client code from implementation details such as the > > >representation of the mask bits. > > Yes, of course. > > Paolo
There's also the `tracing` framework https://docs.rs/tracing/latest/tracing/ that is quite nice for defining tracing events **and** spans for logs. I find it confusing that it still ties tracing events with log level filters though (info/warn/error/debug/trace). Perhaps this is also a good opportunity to restructure QEMU's logging in general. As was said in other threads about tracing, most log items are essentially traces, except guest_error, unimp and maybe I'm missing a few others. If we align QEMU's general logging to use log levels, we can convert guest error logs to "Error" level logs of type: "guest", and unimp logs to "Error" logs of type "unimplemented". Or, "Warn" instead of "Error". Then, all trace_* items become straightforwardly Trace level log items. Then, all we have to do in the Rust side is implement a `tracing` subscriber that consumes these traces and pushes them into QEMU's C implementation. -- Manos Pitsidianakis Emulation and Virtualization Engineer at Linaro Ltd
