@@ -6,10 +6,13 @@
use std::ffi::CStr;
+pub use bindings::{DeviceClass, DeviceState, Property};
+
use crate::{
- bindings::{self, DeviceClass, DeviceState, Error, ObjectClass, Property, VMStateDescription},
+ bindings::{self, Error},
prelude::*,
- qom::ClassInitImpl,
+ qom::{ClassInitImpl, ObjectClass},
+ vmstate::VMStateDescription,
zeroable::Zeroable,
};
@@ -36,7 +36,9 @@
use std::{ffi::CStr, os::raw::c_void};
-use crate::bindings::{self, Object, ObjectClass, TypeInfo};
+pub use bindings::{Object, ObjectClass};
+
+use crate::bindings::{self, TypeInfo};
unsafe extern "C" fn rust_instance_init<T: ObjectImpl>(obj: *mut Object) {
// SAFETY: obj is an instance of T, since rust_instance_init<T>
@@ -161,8 +163,8 @@ pub trait ObjectImpl: ObjectType + ClassInitImpl<Self::Class> {
///
/// Each struct will implement this trait with `T` equal to each
/// superclass. For example, a device should implement at least
-/// `ClassInitImpl<`[`DeviceClass`](crate::bindings::DeviceClass)`>` and
-/// `ClassInitImpl<`[`ObjectClass`](crate::bindings::ObjectClass)`>`.
+/// `ClassInitImpl<`[`DeviceClass`](crate::qdev::DeviceClass)`>` and
+/// `ClassInitImpl<`[`ObjectClass`]`>`.
///
/// Fortunately, this is almost never necessary. Instead, the Rust
/// implementation of methods will usually come from a trait like
@@ -193,7 +195,7 @@ pub trait ClassInitImpl<T> {
///
/// The virtual method implementations usually come from another
/// trait, for example [`DeviceImpl`](crate::qdev::DeviceImpl)
- /// when `T` is [`DeviceClass`](crate::bindings::DeviceClass).
+ /// when `T` is [`DeviceClass`](crate::qdev::DeviceClass).
///
/// On entry, `klass`'s parent class is initialized, while the other fields
/// are all zero; it is therefore assumed that all fields in `T` can be
@@ -7,10 +7,11 @@
pub use bindings::{SysBusDevice, SysBusDeviceClass};
use crate::{
- bindings::{self, DeviceClass},
+ bindings,
cell::bql_locked,
irq::InterruptSource,
prelude::*,
+ qdev::DeviceClass,
qom::ClassInitImpl,
};
@@ -10,6 +10,8 @@
//! [`vmstate_fields`](crate::vmstate_fields) are meant to be used when
//! declaring a device model state struct.
+pub use crate::bindings::VMStateDescription;
+
#[doc(alias = "VMSTATE_UNUSED_BUFFER")]
#[macro_export]
macro_rules! vmstate_unused_buffer {
@@ -328,7 +330,7 @@ macro_rules! vmstate_fields {
}
/// A transparent wrapper type for the `subsections` field of
-/// [`VMStateDescription`](crate::bindings::VMStateDescription).
+/// [`VMStateDescription`].
///
/// This is necessary to be able to declare subsection descriptions as statics,
/// because the only way to implement `Sync` for a foreign type (and `*const`
@@ -342,9 +344,8 @@ macro_rules! vmstate_fields {
unsafe impl Sync for VMStateSubsectionsWrapper {}
-/// Helper macro to declare a list of subsections
-/// ([`VMStateDescription`](`crate::bindings::VMStateDescription`)) into a
-/// static and return a pointer to the array of pointers it created.
+/// Helper macro to declare a list of subsections ([`VMStateDescription`])
+/// into a static and return a pointer to the array of pointers it created.
#[macro_export]
macro_rules! vmstate_subsections {
($($subsection:expr),*$(,)*) => {{
@@ -8,8 +8,9 @@
bindings::*,
c_str, declare_properties, define_property,
prelude::*,
- qdev::DeviceImpl,
+ qdev::{DeviceImpl, DeviceState, Property},
qom::ObjectImpl,
+ vmstate::VMStateDescription,
zeroable::Zeroable,
};
Long term we do not want device code to use "bindings" at all, so make it possible to get the relevant types from the other modules of qemu-api. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- rust/qemu-api/src/qdev.rs | 7 +++++-- rust/qemu-api/src/qom.rs | 10 ++++++---- rust/qemu-api/src/sysbus.rs | 3 ++- rust/qemu-api/src/vmstate.rs | 9 +++++---- rust/qemu-api/tests/tests.rs | 3 ++- 5 files changed, 20 insertions(+), 12 deletions(-)