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
