Re: [PATCH v2 00/16] rust: QObject and QAPI bindings

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Feb 23, 2026 at 04:54:07PM +0100, Paolo Bonzini wrote:
> On 2/23/26 10:53, Daniel P. Berrangé wrote:
> > On Thu, Jan 08, 2026 at 02:10:27PM +0100, Paolo Bonzini wrote:
> > > This adds two related parts of the Rust bindings:
> > > 
> > > - QAPI code generator that creates Rust structs from the JSON
> > >    description.  The structs are *not* ABI compatible with the
> > >    C ones, instead they use native Rust data types.
> > > 
> > > - QObject bindings and (de)serialization support, which can be used to
> > >    convert QObjects to and from QAPI structs.
> > > 
> > > Unfortunately Rust code is not able to use visitors, other than by
> > > creating an intermediate QObject.  This is because of the different
> > > architecture of serde vs. QAPI visitors, and because visitor's
> > > dual-purpose functions, where the same function is used by both input and
> > > output visitors, rely heavily on the structs using the same representation
> > > as the visitor arguments (for example NUL-terminated strings).
> > > 
> > > The serde format implementation was co-authored by me and Marc-André.
> > > Marc-André did all the bug fixing and integration testing.
> > > 
> > > As an example of how this would be used, the marshaling functions for
> > > QMP commands would look like this:
> > 
> > Can you give more of the big picture about what follows this ?  From
> > this example you're showing, are you suggesting that you'll be soon
> > moving QMP command impls from C to Rust ?
> 
> The reasons for Marc-André and I to do this was just as an exploration. The
> patches show a different way to do what he had already tackled in 2022, and
> allow a direct comparison the relative benefits between a more Rust-focused
> approach and a more direct translation of QEMU's C code.
> 
> Marc-André indeed had command implementations in Rust and that would be an
> obvious next step to continue on the QAPI side.  On the other hand, the
> QObject part (without QAPI structs) also works as a step towards more QOM
> integration, especially with respect to properties and backends.  Having a
> full-blown QObject implementation to move around bools is perhaps
> over-engineered, but is also an easy way to make a generic implementation
> that works for all QAPI types.
> 
> The block layer also needs QAPI for option parsing, so Kevin's work on block
> layer bindings would also benefit from having this integration.
> 
> In other words, there is no real big picture from me other than "someone
> needs to do the hard part for others": QOM, QAPI and the build system are
> the three central components from which all other bindings branch out.  Zhao
> and Marc-André have helped a lot with this work, and they also showed how to
> use these hard parts (see Zhao's vm-memory work and Marc-André's GStreamer
> backend), now it's also time for others to try and to take inspiration from
> Rust for improving the C side of things.

I guess the thing I'm wondering about when I ask about the big picture
is to understand tne interoperability implications of this impl approach,
given the starting point that the Rust & C structs are *not* ABI compatible.


If we're anticipating that the Rust usage flows up from a Rust QMP command
handler, then the data is in the Rust struct right from the entry point
and perhaps the interoperability needs are reduced in scope.

If we're anticipating a calls back & forth between C & Rust code, that
directly handle the deserialized structs, then we have an open interop
question. Is the implication that we round-trip via JSON every time we
need to swap between a Rust struct and C struct for a given type ? Or
will we have a direct struct<->struct conversion mechanism ? Or is there
something else entirely ?

I feel a bit lost in how to evaluate this series without seeing some
real world usage, in a way that exposes the possible implications of
the lack of C/Rust ABI compat in the structs.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|