> #[macro_export]
> macro_rules! vmstate_of {
> - ($struct_name:ty, $field_name:ident $([0 .. $num:ident $(*
> $factor:expr)?])? $(,)?) => {
> + ($struct_name:ty, $field_name:ident $([0 .. $num:tt $(*
> $factor:expr)?])? $(,)?) => {
Why change ident to tt?
> $crate::bindings::VMStateField {
> name: ::core::concat!(::core::stringify!($field_name), "\0")
> .as_bytes()
> @@ -109,6 +197,11 @@ macro_rules! vmstate_of {
> $(.num_offset: $crate::offset_of!($struct_name, $num),)?
> // The calls to `call_func_with_field!` are the magic that
> // computes most of the VMStateField from the type of the field.
> + info: $crate::info_enum_to_ref!($crate::call_func_with_field!(
> + $crate::vmstate::vmstate_scalar_type,
> + $struct_name,
> + $field_name
> + )),
> ..$crate::call_func_with_field!(
> $crate::vmstate::vmstate_base,
> $struct_name,
...
> +impl_vmstate_scalar!(vmstate_info_bool, bool);
> +impl_vmstate_scalar!(vmstate_info_int8, i8);
> +impl_vmstate_scalar!(vmstate_info_int16, i16);
> +impl_vmstate_scalar!(vmstate_info_int32, i32);
missed VMS_VARRAY_INT32 :-)
> +impl_vmstate_scalar!(vmstate_info_int64, i64);
> +impl_vmstate_scalar!(vmstate_info_uint8, u8, VMS_VARRAY_UINT8);
> +impl_vmstate_scalar!(vmstate_info_uint16, u16, VMS_VARRAY_UINT16);
> +impl_vmstate_scalar!(vmstate_info_uint32, u32, VMS_VARRAY_UINT32);
If we want to expand in the future (e.g., support vmstate_info_int32_equal
and vmstate_info_int32_le), then introducing new macro variants will be
straightforward. So, fair enough.
> +impl_vmstate_scalar!(vmstate_info_uint64, u64);
What about applying this to "usize" with vmstate_info_uint64?
For array length, I think usize is also used wildly. Maybe we can add
VMS_VARRAY_UINT64 and just treat usize as u64.
> +impl_vmstate_scalar!(vmstate_info_timer, bindings::QEMUTimer);
> +
> // Pointer types using the underlying type's VMState plus VMS_POINTER
>
> macro_rules! impl_vmstate_pointer {
> --
> 2.47.1
Overall, I think it's good; the design idea is coherent.
Reviewed-by: Zhao Liu <zhao1....@intel.com>
