qemu-rust
[Top][All Lists]
Advanced

[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: Bernhard Beschow
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


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());
>>> +            }
>>> +        }
>>> +    }};
>>> +}
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]