On Wed, 12 Jun 2024 19:06, "Daniel P. Berrangé" <berra...@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 <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.
In any case, it is out of scope for this RFC. Introducing wrappers would
be a gradual process.
Thanks,
Manos
