Re: [RFC PATCH v2 3/5] rust: add PL011 device model

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

On Thu, 13 Jun 2024 10:56, Paolo Bonzini <pbonzini@redhat.com> wrote:
>Il gio 13 giu 2024, 09:13 Daniel P. Berrangé <berrange@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.pitsidianakis@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