On Wed, Jun 12, 2024 at 05:14:56PM +0300, Manos Pitsidianakis wrote:
> On Wed, 12 Jun 2024 15:29, Paolo Bonzini <pbonz...@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.pitsidiana...@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 :|
