On Tue, Feb 25, 2025 at 09:28:52AM +0100, Paolo Bonzini wrote:
> Date: Tue, 25 Feb 2025 09:28:52 +0100
> From: Paolo Bonzini <pbonz...@redhat.com>
> Subject: Re: [PATCH 09/15] rust: irq: wrap IRQState with Opaque<>
>
> On 2/25/25 09:26, Zhao Liu wrote:
> > > +/// An opaque wrapper around [`bindings::IRQState`].
> > > +#[repr(transparent)]
> > > +#[derive(Debug, qemu_api_macros::Wrapper)]
> > > +pub struct IRQState(Opaque<bindings::IRQState>);
> > > +
> > > /// Interrupt sources are used by devices to pass changes to a value
> > > (typically
> > > /// a boolean). The interrupt sink is usually an interrupt controller
> > > or
> > > /// GPIO controller.
> > > @@ -22,8 +28,7 @@
> > > /// method sends a `true` value to the sink. If the guest has to see a
> > > /// different polarity, that change is performed by the board between
> > > the
> > > /// device and the interrupt controller.
> > > -pub type IRQState = bindings::IRQState;
> > > -
> > > +///
> > > /// Interrupts are implemented as a pointer to the interrupt "sink",
> > > which has
> > > /// type [`IRQState`]. A device exposes its source as a QOM link
> > > property using
> > > /// a function such as [`SysBusDeviceMethods::init_irq`], and
> > > @@ -41,7 +46,7 @@ pub struct InterruptSource<T = bool>
> > > where
> > > c_int: From<T>,
> > > {
> > > - cell: BqlCell<*mut IRQState>,
> > > + cell: BqlCell<*mut bindings::IRQState>,
> >
> > Once we've already wrapper IRQState in Opaque<>, should we still use
> > bindings::IRQState?
> >
> > Although InterruptSource just stores a pointer. However, I think we can
> > use wrapped IRQState here instead of the native binding type, since this
> > item is also crossing the FFI boundary. What do you think?
>
> Using the wrapped IRQState would be a bit more code because you have to cast
> the pointer all the time when calling C code. As far as correctness is
> concerned, it does not really matter because as you said it only stores a
> pointer.
Yes, it makes sense. This conversion doesn't block the current patch. The
correctness has been guaranteed.
> However, if needed, InterruptSource could have a function that converts from
> IRQState to Option<&Opaque<irq::IRQState>>. Since the accessor is needed
> anyway, that would be a good place to put the conversion.
Then I understand we still need `assert!(bql_locked())` in assessor as
the doc said: "it is possible to assert in the code that the right lock
is taken, to use it together with a custom lock guard type, or to let C
code take the lock, as appropriate."
