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

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

On Wed, 12 Jun 2024 19:06, "Daniel P. Berrangé" <berrange@redhat.com> wrote:
>On Wed, Jun 12, 2024 at 05:14:56PM +0300, Manos Pitsidianakis wrote:
>> On Wed, 12 Jun 2024 15:29, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> > I think this is extremely useful to show where we could go in the task
>> > of creating more idiomatic bindings.
>> > 
>> > On Tue, Jun 11, 2024 at 12:34 PM Manos Pitsidianakis
>> > <manos.pitsidianakis@linaro.org> wrote:
>> > > +pub const PL011_ARM_INFO: TypeInfo = TypeInfo {
>> > > +    name: TYPE_PL011.as_ptr(),
>> > > +    parent: TYPE_SYS_BUS_DEVICE.as_ptr(),
>> > > +    instance_size: core::mem::size_of::<PL011State>(),
>> > > +    instance_align: core::mem::align_of::<PL011State>(),
>> > > +    instance_init: Some(pl011_init),
>> > > +    instance_post_init: None,
>> > > +    instance_finalize: None,
>> > > +    abstract_: false,
>> > > +    class_size: 0,
>> > > +    class_init: Some(pl011_class_init),
>> > > +    class_base_init: None,
>> > > +    class_data: core::ptr::null_mut(),
>> > > +    interfaces: core::ptr::null_mut(),
>> > > +};
>> > 
>> > QOM is certainly a major part of what we need to do for idiomatic
>> > bindings. This series includes both using QOM objects (chardev) and
>> > defining them.
>> > 
>> > For using QOM objects, there is only one strategy that we need to
>> > implement for both Chardev and DeviceState/SysBusDevice which is nice.
>> > We can probably take inspiration from glib-rs, see for example
>> > - https://docs.rs/glib/latest/glib/object/trait.Cast.html
>> > - https://docs.rs/glib/latest/glib/object/trait.ObjectType.html
>> > - https://docs.rs/glib/latest/glib/object/struct.ObjectRef.html
>> 
>> 
>> There was consensus in the community call that we won't be writing Rust APIs
>> for internal C QEMU interfaces; or at least, that's not the goal
>
>I think that is over-stating things. This was only mentioned in passing
>and my feeling was that we didn't have that detailed of a discussion
>because at this stage such a discussion is a bit like putting the cart
>before the horse.
>
>While the initial focus might be to just consume a Rust API that is a
>1:1 mapping of the C API, I expect that over time we'll end up writing
>various higher level Rust wrappers around the C API. If we didn't do that,
>then in effect we'd be making ourselves write psuedo-C code in Rust,
>undermining many of the benefits we could get.
>

In any case, it is out of scope for this RFC. Introducing wrappers would 
be a gradual process.

Thanks,
Manos