motorhead/qemu
1
0
Fork 0
mirror of https://github.com/Motorhead1991/qemu.git synced 2025-07-27 04:13:53 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

rust: qom: fix TODO about zeroability of classes

Browse source 
The proposed suggestion is not correct.  First it is not necessary for
*all* classes to be Zeroable, only for Rust-defined ones; classes
defined in C never implement ObjectImpl.

Second, the parent class field need not be Zeroable.  For example,
ChardevClass's chr_write and chr_be_event fields cannot be NULL,
therefore ChardevClass cannot be Zeroable.  However, char_class_init()
initializes them, therefore ChardevClass could be subclassed by Rust code.

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit is contained in:
Paolo Bonzini 2025-05-02 17:58:54 +02:00
parent 0823837224
commit 3a1c694d74
1 changed files with 4 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

7
rust/qemu-api/src/qom.rs
View file

@ -534,9 +534,10 @@ pub trait ObjectImpl: ObjectType + IsA<Object> {
/// While `klass`'s parent class is initialized on entry, the other fields
/// are all zero; it is therefore assumed that all fields in `T` can be
/// zeroed, otherwise it would not be possible to provide the class as a
/// `&mut T`. TODO: add a bound of [`Zeroable`](crate::zeroable::Zeroable)
/// to T; this is more easily done once Zeroable does not require a manual
/// implementation (Rust 1.75.0).
/// `&mut T`. TODO: it may be possible to add an unsafe trait that checks
/// that all fields *after the parent class* (but not the parent class
/// itself) are Zeroable. This unsafe trait can be added via a derive
/// macro.
const CLASS_INIT: fn(&mut Self::Class);
}