Re: [RFC WIP 2/3] rust: sync: Add dma_fence abstractions

[Alice Ryhl <aliceryhl@google.com>]

On Fri, Nov 21, 2025 at 06:03:22PM -0500, Lyude Paul wrote:
> I haven't gone through this fully yet. I meant to today, but I ended up
> needing way more time to explain some of my review comments w/r/t some
> ww_mutex bindings for rust then I was expecting. But I do already have some
> comments worth reading below:
> 
> On Tue, 2025-11-18 at 14:25 +0100, Philipp Stanner wrote:
> > 
> > +
> > +/// Container for driver data which the driver gets back in its callback once the fence gets
> > +/// signalled.
> > +#[pin_data]
> > +pub struct DmaFenceCb<T: DmaFenceCbFunc> {
> > +    /// C struct needed for the backend.
> > +    #[pin]
> > +    inner: Opaque<bindings::dma_fence_cb>,
> > +    /// Driver data.
> > +    #[pin]
> > +    pub data: T,
> 
> It's entirely possible I've just never seen someone do this before but - is
> are we actually able to make pinned members of structs `pub`? I would have
> thought that wouldn't be allowed (especially if `data` was exposed as just
> `T`, since a user could then move it pretty easily and break the pinning
> guarantee).

It should be ok. If `data` is pinned, so is the entire struct meaning
that you cannot obtain a `&mut DmaFenceCb<T>`, so you cannot in turn
obtain a `&mut T`.

Alice