From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, qemu-rust@nongnu.org
Cc: "Zhao Liu" <zhao1.liu@intel.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [PULL 25/41] rust: qom: put class_init together from multiple ClassInitImpl<>
Date: Thu, 2 Jan 2025 18:04:18 +0100 [thread overview]
Message-ID: <daea6757-a67b-45d5-bf2a-807fd9569a70@linaro.org> (raw)
In-Reply-To: <20241219083228.363430-26-pbonzini@redhat.com>
Hi,
On 19/12/24 09:32, Paolo Bonzini wrote:
> Parameterize the implementation of ClassInitImpl so that it is
> possible to call up the chain of implementations, one superclass at
> a time starting at ClassInitImpl<Self::Class>.
>
> In order to avoid having to implement (for example)
> ClassInitImpl<PL011Class>, also remove the dummy PL011Class and
> PL011LuminaryClass structs and specify the same ObjectType::Class as
> the superclass. In the future this default behavior can be handled by
> a procedural macro, by looking at the first field in the struct.
>
> Note that the new trait is safe: the calls are started by
> rust_class_init<>(), which is not public and can convert the class
> pointer to a Rust reference.
>
> Since CLASS_BASE_INIT applies to the type that is being defined,
> and only to it, move it to ObjectImpl.
>
> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> rust/hw/char/pl011/src/device.rs | 19 +----
> rust/qemu-api/src/definitions.rs | 111 ++++++++++++++++++++++++------
> rust/qemu-api/src/device_class.rs | 50 +++++---------
> rust/qemu-api/src/sysbus.rs | 18 ++++-
> rust/qemu-api/tests/tests.rs | 9 +--
> 5 files changed, 127 insertions(+), 80 deletions(-)
> diff --git a/rust/qemu-api/src/device_class.rs b/rust/qemu-api/src/device_class.rs
> index c98f0b2c7da..dcec5488291 100644
> --- a/rust/qemu-api/src/device_class.rs
> +++ b/rust/qemu-api/src/device_class.rs
> -/// # Safety
> -///
> -/// We expect the FFI user of this function to pass a valid pointer that
> -/// can be downcasted to type `DeviceClass`, because `T` implements
> -/// `DeviceImpl`.
> -pub unsafe extern "C" fn rust_device_class_init<T: DeviceImpl>(
> - klass: *mut ObjectClass,
> - _: *mut c_void,
> -) {
> - let mut dc = ::core::ptr::NonNull::new(klass.cast::<DeviceClass>()).unwrap();
> - unsafe {
> - let dc = dc.as_mut();
> +impl<T> ClassInitImpl<DeviceClass> for T
> +where
> + T: DeviceImpl,
> +{
> + fn class_init(dc: &mut DeviceClass) {
> if <T as DeviceImpl>::REALIZE.is_some() {
> dc.realize = Some(rust_realize_fn::<T>);
> }
> if <T as DeviceImpl>::RESET.is_some() {
> - bindings::device_class_set_legacy_reset(dc, Some(rust_reset_fn::<T>));
> + unsafe {
> + bindings::device_class_set_legacy_reset(dc, Some(rust_reset_fn::<T>));
Pre-existing, but since it appears on this patch, Rust device models
should not implement this legacy interface. If a non-Rust parent
implements it, I think we should convert the non-Rust parent before
adding a Rust child. No clue how to check a parent don't implement
this interface in Rust.
Generally, we shouldn't access legacy API from Rust IMHO.
> + }
> }
> if let Some(vmsd) = <T as DeviceImpl>::vmsd() {
> dc.vmsd = vmsd;
> }
> let prop = <T as DeviceImpl>::properties();
> if !prop.is_empty() {
> - bindings::device_class_set_props_n(dc, prop.as_ptr(), prop.len());
> + unsafe {
> + bindings::device_class_set_props_n(dc, prop.as_ptr(), prop.len());
> + }
> }
> }
> }
next prev parent reply other threads:[~2025-01-02 17:05 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 8:31 [PULL 00/41] Rust, qdev, target/i386 changes for 2024-12-19 Paolo Bonzini
2024-12-19 8:31 ` [PULL 01/41] migration: Constify migration_properties Paolo Bonzini
2024-12-19 8:31 ` [PULL 02/41] hw/ide: Constify sysbus_ahci_properties Paolo Bonzini
2024-12-19 8:31 ` [PULL 03/41] target/ppc: Remove empty property list Paolo Bonzini
2024-12-19 8:31 ` [PULL 04/41] target/s390x: Use s390x_cpu_properties for system mode only Paolo Bonzini
2024-12-19 8:31 ` [PULL 05/41] hw/pci-host/astro: Remove empty Property list Paolo Bonzini
2024-12-19 8:31 ` [PULL 06/41] hw/ppc: Only register spapr_nvdimm_properties if CONFIG_LIBPMEM Paolo Bonzini
2024-12-19 8:31 ` [PULL 07/41] hw/tricore: Remove empty Property lists Paolo Bonzini
2024-12-19 8:31 ` [PULL 08/41] hw/s390x: " Paolo Bonzini
2024-12-19 8:31 ` [PULL 09/41] hw/xen: " Paolo Bonzini
2024-12-19 8:31 ` [PULL 10/41] hw/sparc: " Paolo Bonzini
2024-12-19 8:31 ` [PULL 11/41] hw/virtio: " Paolo Bonzini
2024-12-19 8:31 ` [PULL 12/41] include/hw/qdev-core: Detect most empty Property lists at compile time Paolo Bonzini
2024-12-19 8:32 ` [PULL 13/41] hw/core: Introduce device_class_set_props_n Paolo Bonzini
2024-12-19 8:32 ` [PULL 14/41] migration: Use device_class_set_props_n Paolo Bonzini
2024-12-19 8:32 ` [PULL 15/41] hw/scsi/megasas: " Paolo Bonzini
2024-12-19 8:32 ` [PULL 16/41] hw/arm/armsse: " Paolo Bonzini
2024-12-19 8:32 ` [PULL 17/41] rust/qemu-api: " Paolo Bonzini
2024-12-19 8:32 ` [PULL 18/41] hw/core: Replace device_class_set_props with a macro Paolo Bonzini
2024-12-19 8:32 ` [PULL 19/41] target/riscv: Do not abuse DEFINE_PROP_END_OF_LIST Paolo Bonzini
2024-12-19 8:32 ` [PULL 20/41] include/hw/qdev-properties: Remove DEFINE_PROP_END_OF_LIST Paolo Bonzini
2024-12-19 8:32 ` [PULL 21/41] include/hw/qdev-properties: Shrink struct Property Paolo Bonzini
2024-12-19 8:32 ` [PULL 22/41] hw/core/qdev-properties: Constify Property argument to object_field_prop_ptr Paolo Bonzini
2024-12-19 8:32 ` [PULL 23/41] hw/core/qdev-properties: Constify Property argument to PropertyInfo.print Paolo Bonzini
2024-12-19 8:32 ` [PULL 24/41] Constify all opaque Property pointers Paolo Bonzini
2024-12-19 8:32 ` [PULL 25/41] rust: qom: put class_init together from multiple ClassInitImpl<> Paolo Bonzini
2025-01-02 17:04 ` Philippe Mathieu-Daudé [this message]
2025-01-03 9:02 ` Zhao Liu
2025-01-03 8:48 ` Philippe Mathieu-Daudé
2025-01-06 11:53 ` Paolo Bonzini
2025-01-06 13:32 ` Peter Maydell
2025-01-06 15:21 ` Paolo Bonzini
2025-01-07 15:55 ` Zhao Liu
2025-01-07 15:50 ` Philippe Mathieu-Daudé
2025-01-07 16:03 ` Paolo Bonzini
2025-01-07 16:24 ` Philippe Mathieu-Daudé
2025-01-07 16:29 ` Paolo Bonzini
2025-01-07 16:43 ` Philippe Mathieu-Daudé
2024-12-19 8:32 ` [PULL 26/41] rust: qom: add possibility of overriding unparent Paolo Bonzini
2024-12-19 8:32 ` [PULL 27/41] rust: rename qemu-api modules to follow C code a bit more Paolo Bonzini
2024-12-19 8:32 ` [PULL 28/41] rust: re-export C types from qemu-api submodules Paolo Bonzini
2024-12-19 8:32 ` [PULL 29/41] rust: tests: allow writing more than one test Paolo Bonzini
2024-12-19 8:32 ` [PULL 30/41] rust: qom: add casting functionality Paolo Bonzini
2024-12-19 8:32 ` [PULL 31/41] rust: qom: add initial subset of methods on Object Paolo Bonzini
2024-12-19 8:32 ` [PULL 32/41] rust: qemu-api: add a module to wrap functions and zero-sized closures Paolo Bonzini
2024-12-19 8:32 ` [PULL 33/41] kvm: consistently return 0/-errno from kvm_convert_memory Paolo Bonzini
2024-12-19 8:32 ` [PULL 34/41] target/i386: Reset TSCs of parked vCPUs too on VM reset Paolo Bonzini
2024-12-19 8:32 ` [PULL 35/41] rust: pl011: fix declaration of LineControl bits Paolo Bonzini
2024-12-19 8:32 ` [PULL 36/41] rust: pl011: match break logic of C version Paolo Bonzini
2024-12-19 8:32 ` [PULL 37/41] rust: pl011: always use reset() method on registers Paolo Bonzini
2024-12-19 8:32 ` [PULL 38/41] rust: pl011: fix break errors and definition of Data struct Paolo Bonzini
2024-12-19 8:32 ` [PULL 39/41] rust: pl011: extend registers to 32 bits Paolo Bonzini
2024-12-19 8:32 ` [PULL 40/41] rust: pl011: fix migration stream Paolo Bonzini
2024-12-19 8:32 ` [PULL 41/41] rust: pl011: simplify handling of the FIFO enabled bit in LCR Paolo Bonzini
2024-12-19 15:12 ` [PULL 00/41] Rust, qdev, target/i386 changes for 2024-12-19 Richard Henderson
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=daea6757-a67b-45d5-bf2a-807fd9569a70@linaro.org \
--to=philmd@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-rust@nongnu.org \
--cc=zhao1.liu@intel.com \
/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).