On Mon, 2026-06-01 at 12:59 +0200, Boris Brezillon wrote:
On Mon, 1 Jun 2026 10:36:06 +0000 Alice Ryhl aliceryhl@google.com 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:
- We expect we'll have to define more methods to the FenceCtxOps trait
at some point, so adding it now kinda makes sense.
- 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.