On Thu, 13 Jun 2024 10:56, Paolo Bonzini <pbonz...@redhat.com> wrote:
Il gio 13 giu 2024, 09:13 Daniel P. Berrangé <berra...@redhat.com> ha
scritto:
On Wed, Jun 12, 2024 at 11:27:04PM +0200, Paolo Bonzini wrote:
> Il mer 12 giu 2024, 22:58 Manos Pitsidianakis <
> manos.pitsidiana...@linaro.org> ha scritto:
>
> > In any case, it is out of scope for this RFC. Introducing wrappers
would
> > be a gradual process.
> >
>
> Sure, how would you feel about such bindings being developed on list, and
> maintained in a (somewhat) long-lived experimental branch?
IMHO any higher level binding APIs for Rust should be acceptable in the
main QEMU tree as soon as we accept Rust functionality. They can evolve
in-tree based on the needs of whomever is creating and/or consuming them.
My question is the opposite, should we accept Rust functionality without
proper high level bindings? I am afraid that, if more Rust devices are
contributed, it becomes technical debt to have a mix of idiomatic and C-ish
code. If the answer is no, then this PL011 device has to be developed out
of tree.
Paolo
Getting Rust into QEMU, at least for our team at Linaro, is a long term
commitment, so we will be responsible for preventing and fixing
technical debt. And it will be up to the hypothetical rust maintainers
as well to "keep the garden tidy" so to speak.
To put it another way, I personally plan on making sure any bindings and
any QEMU-ffi idioms that arise are all homogeneous and don't end up
being a burden for the code base.
Your concern is valid, and thank you for raising it. I feel it is
important to figure out how this will be managed, since it's also an
argument for the final say in whether any of this code ends up in the
upstream tree.
Thanks Paolo,
Manos
