Marc-André Lureau writes ("Re: [RFC v3 13/32] rust: use vendored-sources"):
> Yes, this is the shim to provide a C ABI QMP handler from Rust. This is where
> all the FFI<->Rust conversion takes place.
>
> The "safe" code is qga/qmp/vcpus.rs. However, there is no
> documentation there, since it's not meant to be the public
> interface. It's documented with the QAPI schema.
Right, thanks. That does look like a PoC of a Rust API. I wanted the
rustdoc output because I find it provides a very uniform and readable
presentation even of an API with no doc comments.
I think maybe a thing I am missing is how you expect this to be used.
Which parts of the system are going to be in Rust. etc.
And that would help explain what "public" means.
I think the answer is probably in this example:
20210907121943.3498701-1-marcandre.lureau@redhat.com/20210907121943.3498701-30-marcandre.lureau@redhat.com/" rel="noreferrer" target="_blank">https://patchew.org/QEMU/20210907121943.3498701-1-marcandre.lureau@redhat.com/20210907121943.3498701-30-marcandre.lureau@redhat.com/
but although my C and Rust are both fine, I don't understand qemu well
enough to make sense of it.
... wait, qga is "qemu guest agent" ?
I think I am sort of seeing this use case now. But presuambly there
are other use cases for this QMP/QAPI type bridge stuff.
Sorry to be asking such stupid questions.
There is no magic wand to introduce Rust code in an existing C code base. You need to glue some C ABI to/from Rust. It's a lot of manual work to properly bind a C API to Rust (it's a project on its own I would say). Typically, FFI bindings can be automated from headers, and high-level Rust bindings are done by hand. Then you want high-level bindings to take advantage of Rust, for idiomatic and safe code. Various internal QEMU API will have to be bound by hand to start using them from Rust. An isolated unit (say a parser, a function) could be rewritten in Rust and a C ABI be provided without much hassle. But in general, code is quickly interdependent, or the amount of stuff to rewrite in one go is large and risky to do it that way.
In the glib/gobject world, the ABI are annotated, and you can automate much of the high-level binding process (which is amazing, given the complexity of the APIs, with objects, async methods, signals, properties, .. various concepts that don't match easily in Rust). To help with this process, they introduced conversion traits (the ToQemu/FromQemu adapted here), common interfaces, to help automate and compose complex types (and their own binding generator).
(Unfortunately) QEMU doesn't use gobject, but it relies heavily on two type systems of its own: QAPI and QOM. QAPI is actually more of an IDL, which translates C from/to JSON/QMP and has commands and signals (and is the protocol used to communicate with qemu or qemu-ga etc). A large part of QEMU are direct users of the QAPI generated types and functions. It is thus a good target to generate bindings automatically. As demonstrated at the end, it allows writing QMP handlers in idiomatic Rust. Since qemu-guest-agent doesn't have a complex internal state (most commands are really independent, they could be different programs..!), I started rewriting some handlers there. It feels relatively straightforward to rewrite in Rust, and we could imagine a complete rewrite of qemu-ga... However, it is less of a waste to focus on critical parts or newly added code instead, imho! Furthermore, the Rust doesn't cover all targets C can currently target, so we must have some care when deciding a language. (you can imagine I would encourage anyone to do it in Rust!)
QOM is the QEMU object system and is spread throughout the code. If there is enough interest for this Rust effort, I plan to look at binding it next (based on my experience working on GObject bindings). I am afraid we are not going to have as friendly bindings as what the GNOME team achieved, but since QOM is a bit simpler, we may find acceptable compromises.
With QOM & QAPI, and manual bindings of internal APIs, I think we could start writing interesting code in Rust, simple devices, external interfaces etc.
Hope that helps clarify a bit the current goals