On Tue, Jun 10, 2025 at 3:53 PM Marc-André Lureau
<marcandre.lur...@redhat.com> wrote:
> On Thu, Jun 5, 2025 at 2:11 PM Paolo Bonzini <pbonz...@redhat.com> wrote:
>> This is just an extremely minimal extraction from the patches at
>> https://patchew.org/QEMU/20210907121943.3498701-1-marcandre.lur...@redhat.com/,
>> limited to generating structs and enums from the QAPI schema.
>> It does not include them in any crate and does not compile them.
>
> Do you keep an up to date branch for those patches?
I can add them to my rust-next branch but they can in theory just be
applied to upstream/master.
> I fail to understand the advantage of going through Serde to
> deserialize/serialize from C when you can have C types in Rust - having less
> generated code?
It's indeed trading generated Rust code for generic serializers and
deserializers + #[derive(Serializer, Deserializer)]. It's not the
primary reason but the size of your code generator patches was a bit
scary indeed and I don't want to inflict too much review effort on
QAPI maintainers.
But also, I'm not sure that the C types are needed at all for
implementing QAPI commands. The QAPI command generator could have a
directive like 'rust': 'qga::qmp'" directive (or maybe just
'language': 'rust', I don't know) that would generate Rust
marshaling/unmarshaling functions:
pub extern "C" fn qmp_guest_get_host_name(
args: *mut QDict,
ret: *mut *mut QObject,
errp: *mut *mut bindings::Error) {
let args = unsafe { from_qobject::<()>(args) };
match ::qga::qmp::guest_get_host_name(args) {
Ok(ref v) => unsafe { *ret = to_qobject::<GuestHostName>(v); },
Err(err) => unsafe { err.propagate(errp); }
}
}
and this (more specifically from_qobject/to_qobject) could also use
serde, this time to go directly from QObject to Rust and back. A
QObject serializer/deserializer should be easier to write (and very
similar to existing code in serde_json for
https://docs.rs/serde_json/latest/serde_json/enum.Value.html), so you
could reach the stage of your old posting with qapi-gen changes that
are little more than these two patches.
> I also do not fully understand how that would work.
To be honest neither do I entirely. But what I understood is that
Serde is based on a visitor API that is very similar to what we have
in QEMU. See the above serde_json link where it implements Serializer
and Deserializer, and the blog post at
https://ohadravid.github.io/posts/2025-05-serde-reflect/ should be a
good introduction too.
That said: the *possibility* of using Serde is why I started from the
native structs. I'm not wed to it and generating/converting the C
types remains a possibility as well.
Paolo
