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

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|