On Thu, Jan 22, 2026 at 07:43:11PM -0300, Daniel Almeida wrote:
> Hi Alice,
>
> > On 21 Jan 2026, at 08:31, Alice Ryhl <[email protected]> wrote:
> > +/// Represents an `sm_step_unmap` operation that has not yet been
> > completed.
> > +pub struct OpUnmap<'op, T: DriverGpuVm> {
> > + op: &'op bindings::drm_gpuva_op_unmap,
> > + _invariant: PhantomData<*mut &'op mut T>,
>
> Would have been cool to explain why we have a pointer in this PhantomData.
>
> Same elsewhere, IMHO. Helps with maintainability in the future.
>
> (To be honest, I’m not really sure what’s going on here..)
Normally, when you have an OpUnmap<'long, T> Rust will let you convert
that into an OpUnmap<'short, T>, but I don't want that in this case.
Making such coercions impossible means that callers of sm_step_unmap()
cannot return the "wrong" OpUnmapped from the closure because the only
way to get an OpUnmapped with the right lifetime is to call remove() on
the OpUnmap you received.
(Otherwise, it may be possible to return an OpUnmapped from one
sm_step_unmap() call in another sm_step_unmap() call.)
There are various different types one can place in PhantomData to have
this effect. A mutable pointer is one choice. I could also have used:
PhantomData<fn(&'op mut T) -> &'op mut T>
or a few other options.
Alice
