On Mon, 01 Jun 2026 13:17:27 +0200 Philipp Stanner phasta@mailbox.org wrote:

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:

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, ...).