[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/2] rust/qemu-api: Add initial logging support based on C AP
From: |
Paolo Bonzini |
Subject: |
Re: [PATCH 1/2] rust/qemu-api: Add initial logging support based on C API |
Date: |
Mon, 12 May 2025 17:32:08 +0200 |
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
- Re: [PATCH 1/2] rust/qemu-api: Add initial logging support based on C API,
Paolo Bonzini <=