Am 12. Mai 2025 15:32:08 UTC schrieb Paolo Bonzini <pbonz...@redhat.com>: >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) Sorry for the long delay, the imx8mp desired my attention. Paolo, I tried both of your suggestions and found them to be convincing enough that I sent a v2: <https://lore.kernel.org/qemu-devel/20250610202110.2243-1-shen...@gmail.com/T/#t> Best regards, Bernhard > >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 >
