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

[Bernhard Beschow <shentey@gmail.com>]

Am 12. Mai 2025 15:32:08 UTC schrieb 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)

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-shentey@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
>