On Mon, 2026-06-01 at 12:59 +0200, Boris Brezillon wrote: > On Mon, 1 Jun 2026 10:36:06 +0000 > Alice Ryhl <[email protected]> wrote: > > > > +}; > > > + > > > +use bindings::ECANCELED; > > > + > > > +use kernel::str::CString; > > > +use kernel::sync::{ > > > + aref::{ > > > + ARef, > > > + AlwaysRefCounted, // > > > + }, > > > + Arc, > > > + ArcBorrow, // > > > +}; > > > + > > > +/// VTable for dma_fence backend_ops callbacks. > > > +// > > > +// Mandatory dma_fence backend_ops are implemented implicitly through > > > +// [`FenceCtx`]. Additional ones shall get implemented on this trait, > > > which then > > > +// shall be demanded for the fence context data. > > > +pub trait FenceCtxOps {} > > > > This empty trait is unused. > > I had initially suggested to add the F type (AKA FenceData) passed > around in multiple places type as an associated type > > pub trait FenceCtxOps { > type FenceData: Send + Sync; > } > > so we don't have to pass both F and C. The reasoning here is that: > > 1. We expect we'll have to define more methods to the FenceCtxOps trait > at some point, so adding it now kinda makes sense. > > 2. In the current design, we've assumed that a Fence can't live/be > created outside of a given context, so there's no world where the > FenceData wouldn't be known by the FenceCtx implementation, and forcing > users to pass F and C around seems needlessly verbose.
I had investigated that, but found that this causes us to write things like DriverFence<T> (where T is the FencCtx generic) and then in the actual implementation use T::FenceData which reads very weird IMO. Because now for reasons a fence's own data are not referred to in its own implementation, but you derive it from the context. I do prefer it in a way where the DriverFence generic does appear in said fence's actual code, on equal rank with the FenceCtx. I suppose that is actually one use case for which PhantomData does exist. P.
