From: Bernhard Beschow <shentey@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
qemu-rust@nongnu.org
Subject: Re: [PATCH 1/2] rust/qemu-api: Add initial logging support based on C API
Date: Tue, 08 Apr 2025 20:58:56 +0000 [thread overview]
Message-ID: <CABC6E67-C4C7-481F-BB96-BF60957D7A84@gmail.com> (raw)
In-Reply-To: <540905F9-7DF7-436F-905C-A7F225F5E156@gmail.com>
Am 1. April 2025 10:51:06 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>
>
>Am 31. März 2025 09:53:41 UTC schrieb Paolo Bonzini <pbonzini@redhat.com>:
>>On 3/30/25 22:58, Bernhard Beschow wrote:
>>> A qemu_log_mask!() macro is provided which expects similar arguments as the C
>>> version. However, the formatting works as one would expect from Rust.
>>>
>>> To maximize code reuse the macro is just a thin wrapper around qemu_log().
>>> Also, just the bare minimum of logging masks is provided which should suffice
>>> for the current use case of Rust in QEMU.
>>
>>It's probably better to use an enum for this. One possibility is also to change the #defines to a C enum, and see which enum translation of the several allowed by bindgen is best.
>
>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?
>
>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.
>
>>
>>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.
Ping
>
>> Right now I have a project for GSoC that will look at that, and the student can look into it later on.
>
>Whoops, I didn't intend to spoil the project.
>
>>
>>This means answering the following two questions:
>>
>>- the mapping the LOG_* constants into Rust
>>
>>- whether to keep the "qemu" prefix for the API (personal opinion: no)
>>
>>- whether it makes sense to add more macros such as log_guest_error! or log_unimp! for the most common LOG_* values
>>
>>> +#[macro_export]
>>> +macro_rules! qemu_log_mask {
>>> + ($mask:expr, $fmt:expr $(, $args:expr)*) => {{
>>
>>Looking at https://doc.rust-lang.org/std/macro.write.html they just use $($arg:tt)* for what is passed to format_args! (or in your case format!), so we can do the same here too. The main advantage is that it allows giving a trailing comma to qemu_log_mask!.
>
>Easy to fix. Before proceeding I'd like to see a solution for the topic above.
>
>Best regards,
>Bernhard
>
>>
>>Paolo
>>
>>> + if unsafe {
>>> + (::qemu_api::bindings::qemu_loglevel & ($mask as std::os::raw::c_int)) != 0
>>> + } {
>>> + let formatted_string = format!($fmt, $($args),*);
>>> + let c_string = std::ffi::CString::new(formatted_string).unwrap();
>>> +
>>> + unsafe {
>>> + ::qemu_api::bindings::qemu_log(c_string.as_ptr());
>>> + }
>>> + }
>>> + }};
>>> +}
>>
next prev parent reply other threads:[~2025-04-08 20:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-30 20:58 [PATCH 0/2] Initial logging support for Rust Bernhard Beschow
2025-03-30 20:58 ` [PATCH 1/2] rust/qemu-api: Add initial logging support based on C API Bernhard Beschow
2025-03-31 9:53 ` Paolo Bonzini
2025-04-01 10:51 ` Bernhard Beschow
2025-04-08 20:58 ` Bernhard Beschow [this message]
2025-05-12 15:32 ` Paolo Bonzini
2025-05-19 8:13 ` Manos Pitsidianakis
2025-05-20 9:57 ` Paolo Bonzini
2025-06-10 20:51 ` Bernhard Beschow
2025-03-30 20:58 ` [PATCH 2/2] rust/hw/char/pl011/src/device: Implement logging Bernhard Beschow
2025-03-31 9:18 ` Daniel P. Berrangé
2025-04-02 9:33 ` Bernhard Beschow
2025-04-02 13:27 ` Daniel P. Berrangé
2025-04-03 9:46 ` Bernhard Beschow
2025-05-02 16:48 ` Peter Maydell
2025-05-08 17:14 ` Daniel P. Berrangé
2025-05-12 10:45 ` Peter Maydell
2025-04-02 14:13 ` BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABC6E67-C4C7-481F-BB96-BF60957D7A84@gmail.com \
--to=shentey@gmail.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-rust@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).