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
