On Mon, 01 Jun 2026 13:17:27 +0200 Philipp Stanner <[email protected]> wrote:
> 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. Well, I actually think that's a good thing, because DriverFence and FenceCtx are tightly related: FenceCtx<F, C> instantiates and manages DriverFence<F, C> fences, and DriverFenceData<F, C> has an Arc to a FenceCtx<F, C>. > > 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. Question is, can you really have random <F, C> combination or is C dictating which F you'll get attached to the DriverFence? If a given context can't handle more than one type of fence, I don't really see the point of passing both around when one could be directly derived from the other, and since the trait we consider defining for the future is on the FenceCtx (FenceCtxOps), it makes sense to have FenceData defined as an associated type of FenceCtx. > > I suppose that is actually one use case for which PhantomData does > exist. Yeah, I don't, it just feels weird to pass both around, and it doesn't seem to match what we've been doing in other places (drm::Driver, drm::Object, ...).
