On Fri, 2026-02-06 at 11:16 +0100, Danilo Krummrich wrote:
> On Fri Feb 6, 2026 at 10:32 AM CET, Philipp Stanner wrote:
> > Who needs fences from another driver?
>
> When you get VM_BIND and EXEC IOCTLs a driver takes a list of syncobjs the
> submitted job should wait for before execution.
>
> The fences of those syncobjs can be from anywhere, including other DRM
> drivers.
>
> > I think we should go one step back here and question the general
> > design.
> >
> > I only included data: T because it was among the early feedback that
> > this is how you do it in Rust.
> >
> > I was never convinced that it's a good idea. Jobqueue doesn't need the
> > 'data' field. Can anyone think of anyone who would need it?
> >
> > What kind of data would be in there? It seems a driver would store its
> > equivalent of C's
> >
> > struct my_fence {
> > struct dma_fence f;
> > /* other driver data */
> > }
> >
> > which is then accessed in C with container_of.
>
> Your current struct is exactly this pattern:
>
> struct DmaFence<T> {
> inner: Opaque<bindings::dma_fence>,
> ...
> data: T,
> }
>
> So, in Rust you can just write DmaFence<MyData> rather than,
>
> struct my_dma_fence {
> struct dma_fence inner;
> struct my_data data;
> }
>
> > But that data is only ever needed by that very driver.
>
> Exactly, this is the "owned" type that is only ever used by this driver.
>
> > They are *not* a data transfer mechanism. It seems very wrong design-
> > wise to transfer generic data T from one driver to another. That's not
> > a fence's purpose. Another primitive should be used for that.
> >
> > If another driver could touch / consume / see / use the emitter's data:
> > T, that would grossly decouple us from the original dma_fence design.
> > It would be akin to doing a container_of to consume foreign driver
> > data.
>
> Correct, that's why the suggestion here was to have a second type that is only
>
> struct ForeignDmaFence {
> inner: Opaque<bindings::dma_fence>,
> ...,
> /* No data. */
> }
>
> i.e. it does not not provide access to the rest of the allocation, since it is
> private to the owning driver.
>
> This type should also not have methods like signal(), since only the owner of
> the fence should be allowed to signal the fence.
So to be sure, you envision it like that:
let foreign_fence = ForeignDmaFence::new(normal_dma_fence)?;
foreign_fence.register_callback(my_consequences)?;
?
With a foreign_fence taking another reference to bindings::dma_fence I
suppose.
Which would mean that we would need to accept those foreign fences for
jobqueue methods, too.
And what kind of fence do we imagine should
let done_fence = jq.submit_job(job)?;
be?
P.
