On 12/12/24 10:52, Zhao Liu wrote:
On Mon, Dec 09, 2024 at 01:37:10PM +0100, Paolo Bonzini wrote:
Date: Mon, 9 Dec 2024 13:37:10 +0100
From: Paolo Bonzini <pbonz...@redhat.com>
Subject: [PATCH 19/26] rust: rename qemu-api modules to follow C code a bit
more
X-Mailer: git-send-email 2.47.1
A full match would mean calling them qom::object and hw::core::qdev. For now,
keep the names shorter but still a bit easier to find.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
---
rust/hw/char/pl011/src/device.rs | 4 +-
rust/qemu-api-macros/src/lib.rs | 2 +-
rust/qemu-api/meson.build | 5 +-
rust/qemu-api/src/lib.rs | 5 +-
rust/qemu-api/src/module.rs | 43 +++++++++++
rust/qemu-api/src/prelude.rs | 2 +-
.../qemu-api/src/{device_class.rs => qdev.rs} | 4 +-
rust/qemu-api/src/{definitions.rs => qom.rs} | 74 +++++++++----------
rust/qemu-api/src/sysbus.rs | 2 +-
rust/qemu-api/tests/tests.rs | 5 +-
10 files changed, 92 insertions(+), 54 deletions(-)
create mode 100644 rust/qemu-api/src/module.rs
rename rust/qemu-api/src/{device_class.rs => qdev.rs} (97%)
rename rust/qemu-api/src/{definitions.rs => qom.rs} (83%)
--- a/rust/qemu-api/src/definitions.rs
+++ b/rust/qemu-api/src/qom.rs
@@ -2,7 +2,37 @@
// Author(s): Manos Pitsidianakis <manos.pitsidiana...@linaro.org>
// SPDX-License-Identifier: GPL-2.0-or-later
-//! Definitions required by QEMU when registering a device.
+//! Bindings to access QOM functionality from Rust.
+//!
+//! This module provides automatic creation and registration of `TypeInfo`
+//! for classes that are written in Rust, and mapping between Rust traits
+//! and QOM vtables.
+//!
+//! # Structure of a class
+//!
+//! A concrete class only needs a struct holding instance state. The struct
must
+//! implement the [`ObjectType`] and [`IsA`] traits, as well as any `*Impl`
+//! traits provided by its superclasses.
In this commit, this comment is a bit ahead, but I think it's okay.
qom and qdev are both good names. In addition, we can rename the files
of PL011 as well. Perhaps device_class.rs could be merged into device.rs
(and eventually renamed to pl011.rs). I guess you might be planning to
keep it until the cleanup of vmstate and property is done.
Yeah, I don't have any specific plans but memory_ops will certainly go
away. device_class doesn't do much, but keeping it separate is a
reminder for things that are still there to be cleaned up.
As to VMState, there are two parts. One is the vmstate_description
macro, probably it has to be replaced with something else to incorporate
the trampolines for pre_save/post_load/... I haven't looked at it but
it should not be a lot of work.
The second is VMStateFields, for which my idea is to implement a trait
on types to retrieve a basic VMStateField (for example something like
vmstate_uint32 would become an implementation of the VMState trait on
u32). Then you'd write something like "vmstate_of!(Type,
field).with_version_id(2)" (i.e. vmstate_of retrieves the basic field
and fills in the offset, then you apply more changes on top). But that
may take a while, and I think it cannot be done without the
const_refs_to_static feature, which is only stable in 1.83.0.
Paolo
