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 :|
