Re: [PATCH 1/2] rust/qemu-api: Add initial logging support based on C API

[Paolo Bonzini <pbonzini@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 <shentey@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