On 2/10/25 10:59, Zhao Liu wrote:
On Thu, Feb 06, 2025 at 12:15:14PM +0100, Paolo Bonzini wrote:
Date: Thu, 6 Feb 2025 12:15:14 +0100
From: Paolo Bonzini <pbonz...@redhat.com>
Subject: [PATCH] rust: pl011: convert pl011_create to safe Rust
X-Mailer: git-send-email 2.48.1
Not a major change but, as a small but significant step in creating
qdev bindings, show how pl011_create can be written without "unsafe"
calls (apart from converting pointers to references).
This also provides a starting point for creating Error** bindings.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
rust/hw/char/pl011/src/device.rs | 39 ++++++++++++++++----------------
rust/qemu-api/src/sysbus.rs | 34 +++++++++++++++++++++++++---
2 files changed, 50 insertions(+), 23 deletions(-)
...
+ fn realize(&self) {
What about renaming this as "realize_with_sysbus"?
Elsewhere, the device's own realize method is often used to set
DeviceImpl::REALIZE.
I *think* this is not a problem in practice because trait methods are
public (if the trait is in scope) whereas the device's realize method if
private.
I agree that the naming conflict is unfortunate though, if only because
it can cause confusion. I don't know if this can be solved by
procedural macros; for example a #[vtable] attribute that changes
#[qemu_api_macros::vtable]
fn realize(...) {
}
into
const fn REALIZE: ... = Some({
fn realize(...) {
}
realize
}
This way, the REALIZE item would be included in the "impl DeviceImpl for
PL011State" block instead of "impl PL011State". It's always a fine line
between procedural macros cleaning vs. messing things up, which is why
until now I wanted to see what things look like with pure Rust code; but
I guess now it's the time to evaluate this kind of thing.
Adding Junjie since he contributed the initial proc macro infrastructure
and may have opinions on this.
Paolo
