From: Zhao Liu <zhao1.liu@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-rust@nongnu.org, zhao1.liu@intel.com,
junjie.mao@hotmail.com
Subject: Re: [RFC PATCH 5/9] rust: vmstate: implement VMState for scalar types
Date: Wed, 8 Jan 2025 14:45:20 +0800 [thread overview]
Message-ID: <Z34fAFD4d/BVZQkn@intel.com> (raw)
In-Reply-To: <20241231002336.25931-6-pbonzini@redhat.com>
> #[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.liu@intel.com>
next prev parent reply other threads:[~2025-01-08 6:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-31 0:23 [RFC PATCH 0/9] rust: (mostly) type safe VMState Paolo Bonzini
2024-12-31 0:23 ` [RFC PATCH 1/9] rust: vmstate: add new type safe implementation Paolo Bonzini
2025-01-07 8:58 ` Zhao Liu
2025-01-07 12:23 ` Paolo Bonzini
2025-01-07 14:01 ` Zhao Liu
2024-12-31 0:23 ` [RFC PATCH 2/9] rust: vmstate: implement VMState for non-leaf types Paolo Bonzini
2025-01-07 15:43 ` Zhao Liu
2024-12-31 0:23 ` [RFC PATCH 3/9] rust: vmstate: add varray support to vmstate_of! Paolo Bonzini
2025-01-08 3:28 ` Zhao Liu
2025-01-15 10:14 ` Paolo Bonzini
2024-12-31 0:23 ` [RFC PATCH 4/9] rust: vmstate: implement Zeroable for VMStateField Paolo Bonzini
2025-01-06 14:31 ` Zhao Liu
2024-12-31 0:23 ` [RFC PATCH 5/9] rust: vmstate: implement VMState for scalar types Paolo Bonzini
2025-01-08 6:45 ` Zhao Liu [this message]
2025-01-15 13:08 ` Paolo Bonzini
2025-01-16 6:59 ` Zhao Liu
2024-12-31 0:23 ` [RFC PATCH 6/9] rust: vmstate: add public utility macros to implement VMState Paolo Bonzini
2025-01-08 8:15 ` Zhao Liu
2024-12-31 0:23 ` [RFC PATCH 7/9] rust: qemu_api: add vmstate_struct and vmstate_cell Paolo Bonzini
2025-01-07 16:49 ` Paolo Bonzini
2024-12-31 0:23 ` [RFC PATCH 8/9] rust: pl011: switch vmstate to new-style macros Paolo Bonzini
2025-01-08 8:27 ` Zhao Liu
2024-12-31 0:23 ` [RFC PATCH 9/9] rust: vmstate: remove translation of C vmstate macros Paolo Bonzini
2025-01-08 8:40 ` Zhao Liu
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=Z34fAFD4d/BVZQkn@intel.com \
--to=zhao1.liu@intel.com \
--cc=junjie.mao@hotmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-rust@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.